Manage org guardrails
A guardrail is an org-wide rule that runs before any policy and cannot be overridden. Use guardrails for the things no agent in your organisation should ever do — or should only do with a human in the loop — regardless of who owns them or what policy is assigned.
Guardrails live at /guardrails in the sidebar (managers only).
When to add a guardrail (vs editing a policy)
| Reach you want | Use |
|---|---|
| One member’s agents only | A policy assigned to that member. |
| Every member with a given role (e.g. all members but not admins) | A guardrail with a role filter. |
| Every agent in the org, no exceptions | A guardrail with no role filter. |
Rule of thumb: if you’d write the same rule into every policy, it belongs in a guardrail.
Deny vs require-approval
Two effects are available:
deny— the call is blocked outright. The agent receives apolicy_deniederror. Nothing queues; nothing is logged as “pending”; the action simply does not happen.require_approval— the call queues on/approvalsand waits up to 10 minutes for a human to decide. If the call would already have been allowed by the user’s policy, the guardrail still forces the approval prompt.
Pick deny for “this must never happen”. Pick require_approval for “this can happen but a human always sees it first”.
Targets
Like policy rules, guardrails target a platform, a tag, or a specific scope. Tags are the highest-leverage choice — one tag:pii guardrail covers every scope tagged PII across every platform you connect now or in the future.
Role filters
The applies_to_role field scopes a guardrail to a specific role:
admin— only admins are affected.member— only members are affected. Admins still go through.- (unset) — applies to everyone.
Concrete example: “members never see PII”
A common compliance pattern, used at firms like FirstAML:
Members must not be able to read PII through any agent. Admins can — they need it for case work.
The setup is one row:
- Effect:
deny - Target:
tag:pii - applies_to_role:
member
Now every PII-tagged scope is hard-denied for member-owned agents. Admin-owned agents still get through. Adding a new PII-tagged scope on a new platform later? It’s automatically covered.
What gets audited
guardrail.createdguardrail.updatedguardrail.deleted
Calls denied by a guardrail are logged with decision_reason = guardrail_deny on the Audit → Policy Decisions tab, including which guardrail row fired.