Skip to main content
blacklist_policy decides what happens when the captured face matches an entry on a blocklist. Applies to every transaction type that captures a face.
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.

​
Fields

​
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.
​
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.

​
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.