> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chmodlab.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Blacklist policy

> React to a face that matches an entry on an internal or global blocklist.

`blacklist_policy` decides what happens when the captured face matches an entry on a
blocklist.

Applies to every transaction type that captures a face.

```json lines theme={null}
{
  "blacklist_policy": {
    "on_internal_face_blacklist_match": "REJECT",
    "on_global_face_blacklist_match": "REJECT"
  }
}
```

<Note>
  These policies are accepted and validated by the API but are **not enforced yet** — the
  analysis engine does not currently evaluate blocklists, so no blacklist issue is emitted
  regardless of what you configure.

  You can set them today so the intent is recorded and your configuration is ready when
  enforcement ships. **Do not count them as active protection in the meantime.**
</Note>

## Fields

<ParamField body="on_internal_face_blacklist_match" type="string" default="REJECT">
  The face matches an entry on **your organization's own** blocklist — people you have
  blocked, maintained by you.

  Emits `INTERNAL_FACE_BLACKLIST_MATCH`. Takes `REJECT`, `WARN` or `IGNORE`.
</ParamField>

<ParamField body="on_global_face_blacklist_match" type="string" default="REJECT">
  The face matches an entry on the **platform-wide** blocklist maintained by chmod across
  all accounts.

  Emits `GLOBAL_FACE_BLACKLIST_MATCH`. Takes `REJECT`, `WARN` or `IGNORE`.
</ParamField>

## Why the issues carry no details

Neither issue includes `details`. A blocklist match tells you the face is on a list — not
which entry it matched, when it was added, or why.

That is deliberate. Returning the reason would let anyone with API access probe the list
and learn what gets someone added to it, which is exactly the information that makes a
blocklist easy to evade. The reason lives in your own records for the internal list, and
with chmod for the global one.

## Choosing an action

`WARN` is worth considering for the global list when you first enable it: a match on a
list you do not maintain is worth seeing in your review queue before it starts rejecting
your users automatically. Once you have watched it against real traffic and you trust the
rate, move it to `REJECT`.

For your internal list, `REJECT` is usually right from the start — you put those entries
there yourself.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.