Guardrails
A checkpoint between an agent and its model provider that records every exchange and, when you choose, lets your own rules stop one.
An agent's most consequential traffic is its conversation with its model: the instructions it is given, the tool calls it decides to make, and the results it reads back. The guardrail sits on that conversation.
What it is
The guardrail is a local proxy that runs beside the agent. The agent is pointed at it instead of at its model provider, and the proxy forwards the conversation. On the way through it does two separate things:
- It records. Every exchange that passes through it is written to the run's session recording. This is on by default, needs no rules, and stops nothing.
- It judges — if you attach a plugin. For each request and each successful response it asks your
plugin for a decision:
allow,blockorerror. Whether ablockactually stops the call depends on the mode — see Observe and enforce.
The proxy never rewrites a message: it forwards the original bytes unchanged, or it stops the call. There is no redaction in flight and no retry around the guardrail.
Two kinds of traffic pass through without being judged, and are still recorded: an error reply from the model provider, and requests that only list the provider's models or check that it is up.
What a plugin receives
A plugin's manifest declares how much it is given:
- digests only — for each item its id, kind, digest and size, and no content; or
- leased text — the content of each item, within the byte ceilings the manifest declares. An exchange over the ceiling is not handed to the plugin; an item over the per-item ceiling is left out.
The items, for a conversation with Claude, are: the system prompt and the messages; the tool definitions and each tool call — the tool's name and its input; the tool results; the model's thinking and its server-side tool use. Images are passed as empty items.
Where it applies
The same plugin can judge four moments, each with its own mode. The manifest lists the stages the plugin answers; a hand-off or ingress stage it does not list is not asked, and a model stage it does not list is treated as a plugin failure:
| stage | what is judged |
|---|---|
model.request | what the agent sends to its model |
model.response | what the model sends back |
spawn.handoff | the prompt, brief and files handed to an agent before it starts |
bridge.ingress | the files each arriving commit touches, as it reaches the bridge |
Your rules, not ours
Saphan Studio ships no judging rules of its own. The rules live in the plugin you attach — any executable that speaks the plugin protocol. One adapter ships with the product: it forwards the text to an NVIDIA NeMo Guardrails service you operate. See Configuring.
⚠ A plugin given leased text sees the conversation, and nothing in the product stops a plugin from sending it elsewhere — the NeMo adapter does exactly that, by design. Choose and pin a plugin with the same care as any component that handles your source code and prompts.
In this section
| page | for |
|---|---|
| Configuring | turning it on, pinning a plugin, the settings |
| Observe and enforce | the two modes, the signed act that arms enforcement, what the agent and the record see |
| Coverage | which agents and which kinds of machine it covers |
| Limits | what it does not do |