Skip to main content
Early access. This feature is in early access, which means it’s undergoing ongoing testing and development while we gather feedback, validate functionality, and improve outputs. Contact the C1 Support team if you’d like to try it out or share feedback.
Everything on this page lives under AI > Guardrails. The General tab holds guardrails, hooks, and tool gates; the Settings tab holds the untrusted content judge. The order below is deliberate: create the guardrail, bind it, then author rules in Observe mode and promote them to Enforce once you’ve seen what they catch on real traffic.

​
Step 1: Create a guardrail

Start from AI > Guardrails, where every guardrail you create is listed alongside its bindings, rules, hooks, and tool gates.
1
Go to AI > Guardrails and click Create guardrail.
2
Enter a Name (required, up to 128 characters) and optionally a Description (up to 1024 characters).
3
Set Applies to — Agent or Gateway. Choose deliberately: it determines which risk signals your rules can read, and which selector the guardrail appears in when you bind it.
4
Click Create guardrail. C1 creates it and opens its detail page.
A new guardrail has no rules, so it matches nothing yet. Bind it first (Step 2), then add rules (Step 3) — that way the first rule you author is live in Observe mode immediately and starts producing signal.
To rename a guardrail or change its description or surface later, click Edit on the Details card on its detail page.

​
Step 2: Bind the guardrail

A guardrail does nothing until it’s bound. This is the step people skip — a carefully authored cascade that was never bound is evaluated on exactly zero calls.
Where you bind depends on the surface the guardrail applies to.

​
Agent surface

For a tenant-wide default across your C1AI agents:
1
Go to AI > Guardrails.
2
Under Default C1AI Guardrail policy, open the dropdown — it reads No default guardrail selected until you set one.
3
Pick your guardrail.
To override the default for one agent, open that agent from AI > Agents, go to its Guardrails tab, and select a guardrail there. Choosing Use the default agent guardrail clears the override.
Only guardrails whose Applies to is Agent appear in these dropdowns. The match is exact — a guardrail left at the legacy Any surface value appears in neither selector.

​
Gateway surface

For external AI clients connecting through the C1 Gateway:
1
Go to AI > C1 Gateway > Settings.
2
Under Default C1 Gateway Guardrail policy, select your guardrail.
The guardrail is now bound and evaluated on every call to that surface — but with no rules yet, it matches nothing.

​
Step 3: Author a rule

A guardrail’s cascade is empty until you add rules to it. Each rule you create is appended to the bottom of the cascade, so order them deliberately (see Order the cascade below).
1
On the guardrail’s detail page, click New guardrail rule.
2
Enter a Name and optional Description. Name it for the behavior it prevents — this string is what you’ll be reading in audit logs later.
3
Enter a Condition (CEL). Leave it empty to match every tool call. Available variables:For example, to match the untrusted-content exfiltration pattern:
4
Choose an Action:
  • Block — deny the call immediately. Gates and hooks are skipped, and the hook/gate pickers disappear from the form.
  • Evaluate hooks — run the gates and hooks you select below, and let their outcome decide.
5
If you chose Evaluate hooks, select what this rule dispatches:Only hooks and gates with Managed by guardrails turned on appear in these lists, and each picker only offers hooks whose event matches it. If something you expect is missing, that’s why — see Step 5.Pre-output hooks behave differently from the other three: a rule only takes effect on the outgoing response if it uses Evaluate hooks and selects at least one pre-output hook. A Block rule never applies to outgoing responses. See Pre-output hooks.
6
Set Mode to Observe for now. (Enforce applies the outcome; Disabled skips the rule.)
7
Optionally enter a Deny reason (up to 256 characters). It’s shown to the caller when this rule denies a call, so write it for whoever hits it — a bare “policy violation” leaves the agent’s user with nothing to act on.
8
Click Create.
The rule is appended to the bottom of the cascade in Observe mode, where it logs matches without blocking anything.

​
Order the cascade

Rules evaluate top to bottom, first match wins. Click Manage guardrail rules to reorder them with the move controls, or to edit and delete individual rules.
Put narrow rules above broad ones. A catch-all rule with an empty condition matches every call, so anything below it is unreachable.
Each rule renders as an IF / THEN card showing its condition and its action and mode chips, so you can read the cascade top-down without opening each rule.

​
Step 4: Add a tool gate for approval

A tool gate turns a matching call into an approval request instead of a failure.
1
In the Tool gates section on AI > Guardrails, click New tool gate.
2
Enter a Name (1–100 characters) and optional Description.
3
Pick a Grant policy — this determines who approves and how. Required.
4
Enter a Filter (CEL expression). Gate filters read a different variable set than guardrail rules — the call’s identity and target rather than the risk axes. The field’s helper text names ctx.tool_name and ctx.tool_input; see the full list.
5
Set Priority (0–1000, lower matches first) and leave Enabled on.
6
Turn Managed by guardrails on so this gate only fires when a rule selects it, then click Create.
7
Go back to your rule and select the gate under Tool gates.
If a rule selects more than one tool gate, they don’t all apply — only the first gate whose filter matches runs, and its grant policy decides the call. Order is enabled-first, then ascending Priority, then oldest first, across the gates your rule selected plus every gate with Managed by guardrails off. Give the gate whose approver should win the lower priority number. See Only the first matching gate runs.
Leaving Managed by guardrails off means the gate evaluates on every matching call independently of any guardrail. That’s sometimes what you want — a blanket approval requirement — but it makes the gate invisible to your rule cascade.

​
Step 5: Attach hooks

Hooks do the inspection and rewriting. Create them in the Hooks section of AI > Guardrails — see Tool call hooks for the full field reference and the built-in patterns. To make a hook selectable by a guardrail rule, turn on its Managed by guardrails toggle, either in the hook form or directly from the toggle column in the hooks table.
Hooks are fail-closed: if a hook errors, times out, or its filter expression fails to evaluate, the call is denied. A hook selected by an Enforce-mode rule can therefore block traffic because it’s broken, not because it matched. Check the recorded status rather than assuming a denial means the guardrail worked.

​
Step 6: Promote from Observe to Enforce

Until you do this, a rule in Observe is a reporting mechanism, not a control.
1
Leave the rule in Observe and run real traffic through it.
2
Review what it would have caught — see Where to find Observe results below.
3
Check both directions: rules that would have fired on calls you consider legitimate (too broad), and risky calls that matched nothing (too narrow).
4
Edit the rule and set Mode to Enforce.
Because an Observe match falls through to the next rule, you can safely stage a whole cascade in Observe and promote it rule by rule.

​
Where to find Observe results

Every rule that matches a call — enforcing or observing — writes an event to the C1 system log. There is no per-guardrail activity view in C1, so the system log is where you read Observe results.
C1 does not surface these events in the admin UI, and nothing notifies you when an Observe rule would have fired. To read them you need a system log exporter configured to your SIEM or data source. Set that up before you start an Observe rollout, or the traffic you were staging against passes unrecorded from your point of view.
In the exported OCSF events, guardrail decisions carry: To count what a rule would have caught, filter on activity_name = "guardrail_decision" plus would_have_fired = true and your policy_rule_id.
Observe records are written at informational severity — only an actual block is raised above that. A severity filter tuned to warnings and above will exclude exactly the records you’re staging against.
System log events are retained for 365 days by default.

​
Step 7: Configure the untrusted content judge

The judge produces the ctx.untrusted_content signal. It’s on by default and needs no setup — but you can turn it off.
1
Go to AI > Guardrails and open the Settings tab.
2
Under Untrusted content judge, click Edit and toggle it.
Turning the judge off doesn’t just stop the scoring — ctx.untrusted_content then always evaluates as low risk. Any rule that gates on it silently stops matching, so a cascade that looks correct is no longer protecting anything. Leave it on unless you have a specific reason, and if you do turn it off, disable the rules that depend on it rather than leaving them in place.

​
Delete a guardrail

Open the guardrail and click Delete in the top bar. The confirmation dialog names the guardrail and warns the deletion can’t be undone. Any binding that pointed at it stops applying.

​
Next steps