send_email is harmless until the agent has just read a support ticket written by a stranger and is holding customer records. Access profiles can’t express that; they only know whether the tool is reachable. A guardrail can, because it evaluates the combination at call time.
What you can do with guardrails
- Gate on risk combinations, not just tool identity: write rules over private-data sensitivity, untrusted-content exposure, and exfiltration capability
- Require approval mid-call: attach tool gates so a matching call pauses for a human decision instead of failing
- Redact and inspect payloads: attach hooks that rewrite inputs, outputs, or the assistant’s outgoing response
- Roll out safely: run any rule in Observe mode to log what it would have done before it denies anything
- Bind per surface: apply one guardrail to your C1AI agents and a different one to external clients on the gateway
Key concepts
The three risk signals
Every guardrail rule is a CEL expression over the same small set of variables. Three of them are the risk axes C1 scores per call, eachLOW, MEDIUM, or HIGH:
Plus
ctx.tool_name, for name-based matching.
The reason this framing exists is that each axis alone is usually fine and the combination is what’s dangerous — an agent holding private data, exposed to untrusted content, and able to exfiltrate is the “lethal trifecta.” Writing rules on the combination is the point of guardrails.
ctx.untrusted_content is only populated on the Agent surface, because the judge runs inside a C1AI session. A rule written against it on a Gateway guardrail won’t behave as you expect. See Enforcement surfaces.How a rule decides
Rules are evaluated top to bottom, first match wins. A rule with no condition matches every call, which makes it useful as a catch-all at the bottom of a cascade. Each matching rule has an action:- Block — deny the call immediately. No gates or hooks run.
- Evaluate hooks — run the tool gates and hooks this rule selects, and let their outcome decide the call.
Where guardrails apply
A guardrail declares which surface it applies to, and a binding attaches it to a target on that surface.
A guardrail targets one surface or the other — you pick Agent or Gateway when you create it, and it only appears in that surface’s binding selector. To cover both, create one guardrail per surface.
Guardrails, tool gates, and hooks
These three are easy to conflate. The distinction is what each one does to a call:
A guardrail rule invokes hooks and gates; never the reverse. On a single tool call the order is fixed:
guardrail rule match → tool gate → pre-tool hooks → tool executes → post-tool hooks
A
Block rule short-circuits before any gate or hook runs. A gate that requests approval short-circuits before any hook runs.
Pre-output hooks are a separate stage on a separate path. They run when the assistant’s own response is about to be delivered, with no tool call involved — the last point at which you can stop something on its way out. They behave differently enough from the tool-call stages that they have their own section in the reference.
Both hooks and tool gates carry a Managed by guardrails toggle that decides whether they participate in this cascade at all:
- Off (default) — the hook or gate always evaluates, on every matching call, regardless of guardrails.
- On — it only evaluates when a guardrail rule explicitly selects it.
This is the single most common source of surprise. A hook you created before adopting guardrails has Managed by guardrails off, so it keeps firing on every call even when no guardrail selects it. Turning it on hands control of that hook to your rule cascade.
Key use cases for guardrails
Freeze exfiltration after the agent reads untrusted content
The indirect prompt-injection pattern behind published attacks like EchoLeak and CamoLeak: an agent reads attacker-controlled text, then is steered into sending data out. A rule matching elevatedctx.untrusted_content and elevated ctx.exfiltration blocks that combination while leaving each capability independently available.
Require approval for the lethal trifecta
Rather than blocking, route the risky combination to a human: a rule that matches all three axes being elevated and selects a tool gate, so the call pauses for approval under a grant policy you choose.Keep your crown jewels inside the boundary
A rule matching the highestctx.private_data level against a high-exfiltration call, blocking regardless of which tool is involved. Because it’s written on the data-sensitivity axis rather than a tool allowlist, it covers tools you haven’t onboarded yet.
Strip secrets and PII from tool output
Attach the Secrets masking and PII field redaction hooks to a rule so matching values are removed from output before the agent’s context ever sees them.Approve destructive actions without blocking the agent
A tool gate filtered to destructive operations turnsdelete/drop/terminate-shaped calls into approval requests instead of failures, so the agent stays useful and a human owns the irreversible step.
Catch a leak on the way out, after every tool call has passed
The tool-call stages check each call in isolation. But an agent can assemble something from several individually-innocuous calls and put it in its reply — and by then no tool is involved, so no pre-tool or post-tool hook will see it. A pre-output rule inspects the outgoing response itself: withhold it entirely on a matching risk class with Block output, or strip non-allowlisted URLs and markdown images with Link filter to close the markdown-image exfiltration channel. This is the natural companion to the untrusted-content rules above — it’s the last checkpoint before the response reaches a person.Where to go from here
- Ready to set one up? See Configure agent guardrails.
- Need the rule fields, CEL variables, and evaluation order? See the Agent guardrails reference.
- Configuring the hooks a rule selects? See Tool call hooks.
- Governing which tools are reachable in the first place? See Govern tools and toolsets.