PASS / MASK / BLOCK; Topic verdicts are 2-state — PASS or BLOCK.
PASS
No rule matched (or only
PASSING rules did). Content continues unchanged.MASK
(PII only) Sensitive spans are replaced with mask tokens. The Guardian returns the masked content.
BLOCK
A blocking rule or unsafe topic matched. The request is stopped and nothing is sent onward.
The overall action is the highest severity
A response has a rootaction and a per-item breakdown. The root action is the most severe action across everything detected, combining PII and Topic results: BLOCK > MASK > PASS. So a single blocking match makes the whole request BLOCK, even if other parts would only be masked.
What it looks like (real responses)
MASK — PII matched and was replaced;processed_content holds the masked text. Mask tokens follow the format [<MASK_WORD>_<n>], numbered per category (1-based, in document order, and value-stable — the same original value gets the same number, so two different names become [PERSON_NAME_1] and [PERSON_NAME_2]). The original behind each token is exposed as matched_text, which is what unmaskOutput uses to restore it:
processed_content is null:
For the full field reference (PII vs. Topic
detected_items), see Response format.Where you see actions
- API Developers read
actionfrom the Guard API response. - Account Admins see every action as a trace in Opticon monitoring, tagged
PASS/MASK/BLOCK. - Desktop Agent users experience MASK/BLOCK transparently as they use AI tools.