Policy & guard rails

In one line. A guard rail is a named policy — a short piece of instruction text you author once and attach to as many agents as you like; this page is the governance discipline around them, and A8 · Guard rails is the mechanics. You’ll be able to. Decide what belongs in a policy, scope it correctly, and set a review rhythm — with an honest view of what enforcement means today. Where this lives. Studio ▸ Agent Builder ▸ Guard Rails; you attach policies from any agent’s Governance tab.

Policy as a first-class object

“Stay strictly on the subject of company HR policy.” “Never reveal internal pricing.” “Always answer in formal British English.” Each of those is a guard rail: one rule, written once, reused everywhere.

Authoring policies in one place — instead of burying them in each agent’s persona prompt — buys three things:

Reuse. One rule, many agents.
Consistency. Every agent enforces the same wording, not five paraphrases of it.
Auditability. A reviewer can read your governance policies as a list, not hunt through prompts. Treat the Guard Rails page as your policy register: the place someone checks what rules your agents operate under.

What enforcement means today

Be honest with yourself and your stakeholders about the mechanism.

Watch out — enforcement is advisory, not a hard filter. A guard rail is prompt-level guidance: at agent-build time its instruction text is appended to the agent’s instructions. It strongly steers the model, but the platform does not independently read the model’s output back and block it if a rule is broken. A capable model will respect a clear instruction; treat guard rails as governance you can rely on for steering, not as a guaranteed gate. For anything that must be blocked, layer it: a clear guard rail plus a human-approval step plus a tightly-scoped knowledge base.

By design, today. There is no rule type, no input-vs-output switch, no structured condition builder, and no action-on-violation (block / rewrite / warn) in the current build. A guard rail is a name + description + a single instruction — author policy as plain-language text.

The hard boundaries on this platform live elsewhere: RBAC decides who can see and do what (G1 · Access & roles), and lifecycle stage gates decide who signs off before work leaves a stage (D3 · Taxonomy, lifecycle, tags & events). Guard rails are the soft layer on top of that hard layer — use each for what it is.

Writing policy that works

One rule, one concern. A guard rail per concern — topic boundary, tone, a forbidden disclosure — reads better and reuses better than one giant rule.
Write it like an instruction, not a mission statement. The text goes straight into the agent’s instructions; vague aspiration steers nothing.
Don’t rely on a guard rail to block. Pair safety-critical rules with a human-approval step (G2 · Human-in-the-loop).
Shrink the temptation. A topic-boundary rule works best alongside a narrow Knowledge collection, so the agent has little off-topic material to draw on anyway.

Scope and review cadence

Scope: private by default. New guard rails are Private to the project. A policy your other projects need can be published to the Guard Rails Hub and installed elsewhere, so governance travels as reusable structure (V4 · Hubs & solutions).
Apply across agents deliberately. A guard rail does nothing until an agent references it — attaching the same rule to every agent in scope is what turns a sentence into policy. Wire it on each agent’s Governance tab.
Review the register, not just the agents. Because policies live as one list, a periodic read-through of the Guard Rails page is a cheap governance review: is every rule still true, still worded tightly, still attached where it should be?
Deleting doesn’t detach. Removing a guard rail does not walk back through the agents that referenced it — re-check those agents’ Governance tabs after a delete, the same discipline as re-checking stage gates after deleting a role.

Recap

A guard rail = a named, reusable policy authored once and attached to many agents; the Guard Rails page is your auditable policy register.
Enforcement today is advisory prompt-appending, not an output filter — layer human approval and scoped knowledge for anything that must be blocked.
Hard control is RBAC and stage gates; guard rails are the soft steering layer above them.
One rule per concern, private by default, publish to the Hub for cross-project reuse, and re-check attachments after deletes.

Where to go next

A8 · Guard rails — the full mechanics: the authoring page, every control, and how a rule runs.
G2 · Human-in-the-loop — the approval step that turns advisory policy into a real gate.
G1 · Access & roles — the hard-enforcement layer underneath.
V4 · Hubs & solutions — publishing a policy for reuse across projects.