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 ▸ Agent Builder ▸ Guard Rails (/studio/.../agent_builder/guard_rail). 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.

Under the hood. A guard rail is stored as the GuardRail entity; at agent-build time the orchestrator resolves each attached guard rail’s instruction text and appends it to the agent’s instructions, then adds one “apply all guardrail rules to the final answer” instruction on top. See “How a guard rail runs” below — this detail matters for setting expectations.

The Guard Rails page

Studio ▸ Agent Builder ▸ Guard Rails is the standard Agent Builder 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                   │
│   [Private]   ← debug mode only          ││                                        │
│                                          ││  Description                           │
│   No Internal Pricing                    ││    Keep the agent answering only HR…   │
│   Never disclose internal price lists    ││                                        │
│                                          ││  Access Level   ← debug mode only      │
│   Formal Tone                            ││    Private                             │
│   Always answer in formal British…       ││                                        │
│                                          ││  Instructions                          │
│ … (Load More appears at ≥1000 rules)     ││    You answer ONLY questions about the │
│                                          ││    company HR handbook. If asked about │
│                    [ + Guard Rail ]      ││    anything else, politely decline.    │
└──────────────────────────────────────────┘└────────────────────────────────────────┘

Left — list. Each row shows the guard rail’s name and description (clamped). In debug mode only, a Private / Public access chip appears. 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 appears only past 1000 rules.
Right — detail panel. A read-only projection of the selected guard rail: Name, Description, Access Level (debug only), 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 you have permission) 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.	Needs the `Add Guard Rail` permission, or it’s hidden.
⋮ action menu	Per-rule actions on the selected guard rail.	See next table.

Action	What it does	Notes
Publish	Pushes this guard rail to the Guard Rails Hub to share/install elsewhere.	See Hubs & solutions.
Edit	Reopens the dialog in edit mode.	Needs the `Edit Guard Rail` permission.
Delete (red)	Confirms, then removes the guard rail.	Needs the `Delete Guard Rail` permission. 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.
Access Level	—	Shows Private (project-only) vs Public (library) scope.	Read-only, and only visible in debug mode when editing. New guard rails default to Private.
Instruction	Yes	The policy itself — the natural-language rule the agent must follow. This is the whole point of the object.	Expandable textarea. Supports the global-variable placeholder menu — insert `{{scope.X}}` tokens to reference project variables.
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.

Coming soon / by design — the richer guard-rail model. 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). In the current build a guard rail is only a name + description + a single instruction. There is no input/output toggle, no condition builder, and no per-violation action selector on the screen — those are not shipped. Author guard rails as plain-language policy text today.

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.
Access Level is fixed at create. The Private↔Public choice isn’t editable in this dialog (it’s a read-only display in debug mode). Treat new guard rails as Private to the project.
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 ▸ Agent Builder ▸ 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 under Guard rails.
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.

Under the hood. On the legacy agent layout this same section is labelled Guard Rails Configuration on the main form; on the new builder it lives on the Governance tab alongside Approvals. Both write the same list of guard-rail references onto the agent. Adding/removing here is RBAC-gated (Add Guard Rail In Agent / …In Multi Agent).

How a guard rail runs (briefly)

When the agent is built for a run, the orchestrator:

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” orchestrator instruction.
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.

Built a guard rail your other projects need? The detail panel’s ⋮ ▸ Publish pushes it to the Guard Rails Hub, and other projects install it like any shared object — governance policy travels as reusable structure. Full publish/install workflow is in Hubs & solutions.

Try it yourself

Add an output topic-boundary to an HR assistant so it stays on subject:

Go to Studio ▸ Agent Builder ▸ Guard Rails and 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 under Guard rails, 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 ▸ Agent Builder ▸ Guard Rails and attached to agents for governance.
The create/edit dialog has exactly four meaningful fields: Name (req), Description (req, ≤200), Access Level (read-only, debug-only), 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 to the Hub for reuse across projects.
The “type / input-vs-output / condition / action-on-violation” model is not shipped — guard rails are plain-language policy text today.

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.