Academy · Platform · Agents
Guard rails
In one line. A guard rail is a named, reusable policy — a short piece of instruction text — you author once in Studio and attach to any agent to keep it on-topic and safe. You’ll be able to. Create a reusable guard rail, attach it to an agent’s Governance tab, and reason about what it does (and doesn’t) enforce. Where this lives.
Studio > Agents > Agent Toolkit > Guard Rails. You attach them from any agent’s Governance tab.
Why it matters
An agent you ship to end-users will be asked things you never anticipated — off-topic questions, attempts to make it say something unsafe, requests that should produce a particular shape of answer. Governance is how you keep a configured agent inside the lines without rewriting its instructions every time.
A guard rail is the platform’s reusable unit of governance: a named policy — a short piece of instruction text — that you author once and attach to as many agents as you like. “Stay strictly on the subject of company HR policy.” “Never reveal internal pricing.” “Always answer in formal British English.” Each is a guard rail you write once and reuse.
Authoring them in one place (the Guard Rails page) instead of burying them in each agent’s persona has three payoffs: reuse (one rule, many agents), consistency (every agent enforces the same wording), and auditability (a reviewer can read your governance policies as a list, not hunt through prompts). The wider policy side of governance — beyond per-agent rules — is covered in G3.
How the rules reach the agent. Each rule you attach is added to the agent’s own instructions before it runs, with one final instruction telling it to apply all of them to its answer. That is why the wording of a rule matters as much as a persona’s — see “How a guard rail runs” below.
The Guard Rails page
Studio > Agents > Agent Toolkit > Guard Rails is the familiar two-pane shell: a list of your guard rails on the left, a read-only detail panel on the right, and a dialog for create/edit.
┌ Guard Rails ─────────[ sort ⇅ ][ search ]┐┌ <selected guard rail name> ──────[ ⋮ ]┐
│ ││ │
│ ● On-Topic: HR Only ││ Name │
│ Keep the agent answering only HR… ││ On-Topic: HR Only │
│ ││ │
│ No Internal Pricing ││ Description │
│ Never disclose internal price lists ││ Keep the agent answering only HR… │
│ ││ │
│ Formal Tone ││ Instructions │
│ Always answer in formal British… ││ You answer ONLY questions about the │
│ ││ company HR handbook. If asked about │
│ … (Load More appears at ≥1000 rules) ││ anything else, politely decline. │
│ ││ │
│ [ + Guard Rail ] ││ │
└──────────────────────────────────────────┘└────────────────────────────────────────┘
- Left — list. Each row shows the guard rail’s name and description (clamped). The header carries a sort toggle (date ⇄ A-Z) and a search icon that reveals a search field (filters on name + description). A + Guard Rail button sits in the footer; a Load More button turns up only once the project holds 1000 rules or more.
- Right — detail panel. A read-only projection of the selected guard rail: Name, Description and Instructions (the policy text, shown pre-wrapped). Its header carries the ⋮ action menu.
- Empty state. With no rules, the list shows “No Guard Rails found in the project” and (if your access allows creating them) an inline + Guard Rail button. A search with no hits shows “No Guard Rails found matching your search”.
What every control does
| Control | What it does | Notes |
|---|---|---|
| Sort toggle (⇅) | Switches the list between newest-first and A→Z. | Pure view state. |
| Search | Reveals a field; filters the list by name or description. | Close [x] clears it. |
| + Guard Rail (footer / empty-state) | Opens the create dialog. | Shown only if your access allows it — if it’s missing, ask your administrator. |
| ⋮ action menu | Per-rule actions on the selected guard rail. | See next table. |
The ⋮ action menu (on the selected rule)
| Action | What it does | Notes |
|---|---|---|
| Publish | Shares this guard rail beyond the project so other projects can reuse it. | See Hubs & solutions. |
| Edit | Reopens the dialog in edit mode. | Shown only if your access allows it — if it’s missing, ask your administrator. |
| Delete (red) | Confirms, then removes the guard rail. | Shown only if your access allows it. Detaching from agents is your job — see “Behaviours to know”. |
The create / edit dialog
Click + Guard Rail (or Edit) to open the dialog. It is short — a guard rail is just a named instruction — and every field is below.
| Field | Required | What it does | Notes |
|---|---|---|---|
| Name | Yes | The label you’ll pick from on an agent’s Governance tab. | Make it action-describing: “On-Topic: HR Only”. |
| Description | Yes | A one-line summary for the list and detail panel. | Max 200 characters. |
| Instruction | Yes | The policy itself — the natural-language rule the agent must follow. This is the whole point of the object. | Expandable textarea with a variable menu — pick a variable defined for the project and it drops a {{variable-name}} token into your text, resolved when the agent runs. |
| Cancel / Save | Update | — | Discards / persists. | Save is disabled while the form is invalid or saving. Label is Save when creating, Update when editing. There is no autosave. |
Tip — write the instruction as a direct order to the agent. It is pasted verbatim into the agent’s instructions, so phrase it the way you’d phrase a persona rule: “You answer ONLY questions about the company HR handbook. If asked about anything else, politely say you can only help with HR topics.” Be explicit about both the boundary and the fallback behaviour when the boundary is hit.
What a guard rail is not. You may expect a guard rail to have a type, an input-vs-output switch, a structured rule/condition, or an action-on-violation (block / rewrite / warn). It has none of those. A guard rail is a name, a description and one instruction — there is no condition builder and no block/rewrite/warn setting. Write them as plain-language policy.
Behaviours to know
- Realtime sync. The list reloads in place when a guard rail is created/updated/deleted elsewhere (another tab, a teammate, an automation) — no manual refresh.
- Save is explicit. No autosave; the dialog persists only on Save / Update, and only when valid.
- New guard rails are private to this project. You cannot change that here; to let another project reuse a rule, use ⋮ ▸ Publish.
- Deleting doesn’t detach. Removing a guard rail does not walk back through agents that referenced it — re-check those agents’ Governance tabs.
Attaching a guard rail to an agent
A guard rail does nothing until an agent references it. You wire that on the agent itself, not here.
Open Studio > Agents > Agent Toolkit > Agents, edit an agent, and go to the Governance tab (recap in A3 · Your first agent). Its Guard rails section is the attach point:
- Click + Add guard rail.
- Pick one or more of your authored guard rails from the picker.
- Each selected rule appears as a shield chip with a remove (×). The empty state is a dashed placeholder.
- Save Agent (footer). The attachment is part of the agent’s saved config.
You may see a different label. On an older agent layout this same section reads Guard Rails Configuration on the main form rather than sitting on the Governance tab alongside Approvals. Either way you are editing the same list of rules on the agent.
How a guard rail runs (briefly)
When the agent is prepared for a run, the platform:
- Fetches the instruction text of every guard rail attached to the agent.
- Appends each one to the agent’s instructions, then adds a single “apply all these rules to the final answer, return one clean result” instruction on top.
- The agent then runs its normal loop (model ⇄ tools) with those rules now part of its standing instructions.
Watch out — enforcement is advisory, not a hard filter. A guard rail is prompt-level guidance: 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 (Governance ▸ Approvals, A3) plus a tightly-scoped knowledge base.
Governance best practices
- One rule, one concern. A guard rail per concern (topic boundary, tone, a forbidden disclosure) reads better and reuses better than one giant rule.
- Name for the picker. You’ll choose these by name on the Governance tab — “No Internal Pricing” beats “GR-2”.
- State the boundary and the fallback. “Only answer X; if asked anything else, politely decline” — don’t leave the off-path behaviour to chance.
- Reuse across agents. Author once; attach the same rule everywhere it applies. Edit it once and every agent inherits the change on its next run.
- Don’t rely on a guard rail to block. Pair safety-critical rules with a human-approval step.
- Keep them on-topic with knowledge scope. A topic-boundary guard rail works best alongside a narrow Knowledge collection (D1) so the agent has little off-topic material to draw on anyway.
Sharing beyond the project
Built a guard rail your other projects need? The detail panel’s ⋮ ▸ Publish shares it beyond this project, so governance policy travels as reusable structure instead of being retyped. How shared material is browsed and installed is covered in Hubs & solutions.
Try it yourself
Add an output topic-boundary to an HR assistant so it stays on subject:
- Go to
Studio > Agents > Agent Toolkit > Guard Railsand click + Guard Rail. - Name:
On-Topic: HR Only. - Description:
Keep the agent answering only HR-handbook questions.(≤200 chars.) - Instruction:
You answer ONLY questions about the company HR handbook (leave, benefits, conduct, payroll policy). If the user asks about anything else — coding, news, general trivia, other departments — politely reply that you can only help with HR topics and invite an HR question.
- Save. Confirm it shows in the list and that its detail panel renders your instruction.
- Go to
Agents, edit your HR assistant, open the Governance tab, click + Add guard rail, select On-Topic: HR Only, and Save Agent. - In the Playground, ask an off-topic question (“write me a Python script”). The agent should decline and steer you back to HR. (If it doesn’t, sharpen the instruction’s wording — it’s prompt-level steering.)
Recap
- A guard rail is a reusable, named policy — a single instruction — authored at
Studio > Agents > Agent Toolkit > Guard Railsand attached to agents for governance. - The create/edit dialog has exactly three fields: Name (req), Description (req, ≤200), and Instruction (req, the policy, supports
{{variables}}). - You attach guard rails on an agent’s Governance tab (+ Add → shield chips); they’re saved as part of the agent’s config.
- At run time each rule’s text is appended to the agent’s instructions — enforcement is advisory steering, not a hard output filter, so pair safety-critical rules with human approval.
- Guard rails can be published for reuse beyond the project they were written in.
- There is no “type / input-vs-output / condition / action-on-violation” model — guard rails are plain-language policy text.
Where to go next
- LLMs & services — the models that power your agents (and the services that extend them).
- Your first agent — the Governance tab in full context, alongside Approvals.
- Governance policies — the platform-wide policy side of governance, beyond per-agent guard rails.
- Hubs & solutions — publish and install guard rails (and everything else) across projects.
Prefer learning inside the product? The same academy lives in the platform's Learn menu — every screen links to the chapter that explains it.
See the platform live