When a FLAG Should Stop the Agent
A FLAG verdict records risk without interrupting work. Human approval halts the action until a named reviewer decides. Choosing between them is a risk decision, not a technical one.
Every guardrail rule resolves to one of three verdicts: ALLOW, FLAG, or BLOCK. The interesting decisions live in the middle.
What FLAG does by default
A FLAG verdict marks the action as notable and writes it to the record. The action still proceeds. This is the right setting when you want visibility into a pattern before you decide whether it is actually a problem.
What changes with approval required
Set requires_approval on a rule and a FLAG stops being passive. The action is held in the approval queue, and a named reviewer approves or rejects it. The reviewer identity is derived server side from the authenticated session, so the decision cannot be attributed to someone who did not make it.
The question is not "is this risky". The question is "would we accept this action happening while nobody was looking".
A practical split
- Approval on: prompt injection detection and PII exposure by default; extend to other high-stakes rule types as needed
- Approval off: rate limiting, output length, repetition detection, and other rules that describe hygiene rather than harm
New Prompt Injection and PII rules now default to requiring approval. Existing rules keep whatever setting they already had, so turning this on does not retroactively change the behaviour of a running deployment.
The cost you are trading against
Approval adds latency measured in human minutes, not milliseconds. Applied to the wrong rule it turns a governance layer into a queue nobody drains. Applied to the right rule it is the only control that puts a person's name against a decision before it happens.
See the Product page for the full verdict model.