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 ▸ Agents ▸ Agent Toolkit ▸ Guard Rails; you attach policies from any agent’s Governance tab.

Policy you write once

“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 straight with your stakeholders about what a guard rail does, and what it does not.

Watch out — enforcement is advisory, not a hard filter. A guard rail steers the agent as an instruction it must follow. It does not read the answer back and block it. 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.

What a guard rail is made of. A name, a description and a single instruction — that is all there is to one. There are no rule types to choose between, no condition builder, and no block / rewrite / warn setting. You write policy as plain-language text, which is why the wording carries all the weight.

The hard boundaries live elsewhere: roles and personas decide 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 becomes part of what the agent is told to do; 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. A new guard rail is Private to the project you author it in — it does not appear in your other projects. When a rule needs to hold everywhere, publish it to the Hub and install it into each project rather than re-typing it, so the wording cannot drift (V4 · Hubs & distribution).
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 removing a persona.

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 steering, not an output filter — layer human approval and scoped knowledge for anything that must be blocked.
Hard control is roles, personas and stage gates; guard rails are the soft steering layer above them.
One rule per concern, private to the project, 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 & distribution — how a policy, an agent or a whole solution moves between projects.