Standards — applied when an agent is created
Create agent on the Fleet screen opens a four-step flow — What should it do, Definition, Standards pack, Review & create — and the third step applies your organization’s standards pack automatically. The point is that a new agent cannot quietly ship without an owner, a budget, or grading, because those are not steps somebody has to remember.
Each standard fills in as the step loads, and the pack is scored out of seven — 7/7 when
everything applies. The last step restates it as a standards scorecard next to the agent
summary, and that is what you confirm before creating.
Every standard except Docs carries a Waive switch. Waiving one drops the score — 7/7 becomes
6/7 — and the row shows Waived in place of its value rather than disappearing. The governance
value here is legibility, not enforcement: an agent with a waiver is fine, an agent whose waiver
nobody can see is not.
Guardrails — enforced at the action boundary
A guardrail is a rule you configure that decides whether a specific action may proceed. It is evaluated outside the agent: an agent cannot skip a guardrail, because the check does not run in the agent’s own process. It runs at the boundary the agent’s traffic has to cross. You author them under Standards & Guardrails, which lists your rules on a Policies tab with Add policy to create one, and their decision trail on an Activity tab. Each rule is filtered by the action it takes — Blocking, Hold for approval, Redacting, or Alert only.The five gates
A guardrail stands at one gate, and the gate is fixed for the life of the rule.What a guardrail does on a match
Every outcome is recorded either way, so a guardrail always produces an activity trail whether it
intervened or not. The Activity tab is that trail: when, which agent, the outcome, the rule that
decided, and the action it was deciding about.
Redaction reads differently in each direction. On the way in — a tool result, a model answer — the
agent can see that something was removed and reason about it. On the way out the agent composed
the text and is not shown the rewrite, so it may go on to interpret a reply to a question it did not
actually ask. When the agent needs to act on what comes back, block is the honest choice.
Who a rule covers
Target a guardrail at explicit agents, or at a label bag the calling agent’s own labels must contain. Labels are the durable option: a rule scoped toenv = production keeps covering the right
agents as the fleet changes.
Matching a call
The authoring form is a picker rather than a syntax. It lists the tools your workspace actually has, grouped by server, so you are choosing from reality instead of guessing at tool names. A glob pattern is available as an alternative — a selection covers the tools that exist now, a pattern covers the ones that arrive later — and the form reports how many of your current tools a pattern matches. You can also condition on a tool’s arguments, chosen from the real argument names of the tools you picked, and on named value classes — a payment card number, a cloud access key — which match a kind of value rather than a string you had to write yourself.Test a rule before it is live
A draft rule can be backtested against recorded traffic, so you see what it would have done before it does it. That is what makes it reasonable to write a blocking rule against production: backtesting shows how the rule would have affected the recorded traffic you tested it against, rather than leaving you to discover it live.Which one to reach for
Next steps
Approvals
When the right answer is a human decision rather than a rule.
Roles & permissions
The permission layer a guardrail sits on top of.
Audit log
Where guardrail decisions are recorded.
Data handling & redaction
What is masked without any rule at all.