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 under Governance → Guardrails in the sidebar (/guardrails, admins only). Fill in the new-guardrail row and click Save new guardrail. Existing guardrails appear as locked rows at the top of every policy’s capability grid.
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 a “Permission denied” error with reasondenied_by_guardrail. 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 role selector scopes a guardrail to a specific role:
- admins only — only admins are affected.
- members only — only members are affected. Admins still go through.
- applies to all roles — applies to everyone.
Concrete example: “members never see PII”
A common compliance pattern:
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 - Role: members only
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.
tag:piirules need the PII redaction beta. Personal-data governance is an Enterprise beta. Until it’s switched on for your organisation, a rule that targetstag:piiis ignored, so this guardrail would not deny anything. Ask us to enable the beta, or target the PII scopes directly in the meantime.
What gets audited
Calls denied by a guardrail are logged on the Audit Log → Actions tab as denied, with reason denied_by_guardrail.