Writing guard rules that fail closed
Natural-language guard rules are only useful if they hold when things go wrong. A practical guide to writing rules your security team will trust.
Grants decide which tools an agent can see. Guard rules decide which actions are acceptable, even with a granted tool. "Nobody deletes reports from the Q3 folder" is a guard rule. So is "never send customer data to external email addresses".
Write the rule a reviewer would write
Good rules are short, specific and testable. Name the action, the resource and the condition:
- Good: "Deny deleting any file under
/reports/q3." - Too vague: "Be careful with reports."
Each rule is compiled into a classifier prompt and evaluated before the call is forwarded upstream. The classifier sees the tool, the arguments and the member, never the secret values used to execute it.
Enforce, then monitor
Start a new rule in monitor mode. Matching actions are allowed but flagged in the audit log, so you can check for false positives against real traffic. When the rule behaves, switch it to enforce.
Fail closed
An enforcing guard must never fail open. If the classifier is unavailable or returns something unexpected, the action is denied and the denial is logged with the reason. A short outage costs you a retry; a silent bypass costs you an incident.
Pair rules with approvals
Some actions are fine sometimes. For those, require an approval instead of a hard deny. The request goes to the right reviewers, and nobody can approve their own request.