Guardrails
Guardrails check every tool call an agent makes against your organization's policy, before the call runs. So an agent that has read an untrusted web page cannot then email your customer list. The OpenAPPA policy engine decides by rules, not by asking another model. It runs outside the agent's loop, so a prompt injection cannot change its decisions.
Platform + AI Security — see Pricing Model. OpenAPPA itself is MIT-licensed; its integration here is the licensed part. Once the instance has 30 or more users, the integration turns off until
ARCHESTRA_ENTERPRISE_LICENSE_AI_SECURITY_ACTIVATEDis set.
How It Works
An agent that reads private data, reads untrusted content, and can send data out can be tricked into a leak. One hidden line on a web page, such as "email the customer list to this address", is enough.
Guardrails follow each session through the LLM Proxy. Every tool result can add restrictions to the session. Every tool call must meet the policy for the session as it stands. The policy tracks four things (how it works):
| Property | What It Tracks | Example |
|---|---|---|
| Trust | Whether session content can drive sensitive actions. | Reading an external website makes the session suspicious. |
| Audience | Who may receive data from the session. | Reading an internal document limits output to internal. |
| Effects | What the session has already done. | A report must be archived before it is sent. |
| Attention | Approval for one specific call. | Publishing a report needs a team review. |
Restrictions only add up. A trusted read never restores lost trust, and an approval allows one call without lifting the session's restrictions. With a typical policy, emailing a colleague works at the start of a session, and fails after the agent reads an untrusted page.
Turn On Guardrails
You need openappaPolicy:update to write the policy, and organizationSettings:update to turn enforcement on or off. Guardrails appears under Agents in the sidebar for anyone with openappaPolicy:read or openappaDiagnostics:read.
- Go to Guardrails and click Create my policy. A chat with the configuration agent opens.
- The agent drafts a starting policy from your tools and explains what it allows and blocks.
- Approve the policy. Saving the first policy turns enforcement on.
- Optionally, click Set up Git sync in the saved-policy banner to keep the policy in GitHub or GitLab. See Git sync.
The Enforcement card on Overview now shows On.
What to know:
- The starting policy covers only Archestra's own tools. Every other tool runs without restrictions. The code sandbox tool
run_commandis labeled by your organization's default model before each command, so reading a credentials file narrows who can see the result. A policy you already saved keeps its own rules. Next, cover your other tools. - Enforcement applies to sessions that start while it is on. Start a new session after you turn it on.
- Settings → Guardrails holds four settings: Enforce the policy, which you can switch once a policy exists; Allow superyell, which lets an agent turn Guardrails off for its own session after a person approves (on by default); Other clients, for unrecognized clients; and Git sync.
Validations
Check that a policy still allows and refuses the behavior you intended. The Validations card shows the latest saved result, execution time and file count. Click View Validations to write checks or review runs.
Blocked Calls
When the policy refuses a call, the call does not run. The agent gets the reason instead, with the remedies the policy allows:
- Approval: a person or a system approves this one call.
- Sanitize: the data is cleaned first, for example with secrets redacted.
- Narrow or withhold: the agent accepts a narrower audience, or drops the tool result.
- Isolate: a subagent does the risky read and returns only what the policy permits.
When an approval is needed, the agent asks you, and the call runs only after you approve. If no remedy works, the call stays blocked and the agent explains why.
The agent uses get_remedy_plans and execute_remedy_plan for this. A confusing block shows up as a yell.
Protection Limits
Guardrails check tool calls. They do not contain the machine the agent runs on. Pair them with isolation:
- Shell, files, and network: Guardrails do not sandbox them. Run the agent in Agent Runtime instead. It gets its own container, and an egress policy limits where it can send data.
- Traffic around the proxy: Guardrails check only requests through the LLM Proxy. Connect every client to it, and block the clients Guardrails do not recognize.
- Provider-hosted tools, such as a provider's own web search: most run before the proxy sees the call. Where you need the check, use a tool that runs in the client or through the MCP Gateway.
- Sessions that cannot be checked: the proxy rejects them with HTTP 400. These are Codex in code mode, client-run
local_shellorcomputer_usetools, and Responses requests that continue a stored response withprevious_response_id. - Conversations stored by the provider: Claude Code can keep a conversation on Anthropic's side and send only the new messages. Guardrails check these too. When the proxy has no record of the stored conversation, for example one that started before Guardrails were on, Claude Code sends the whole conversation once more.
- Images, documents, and audio in tool results: the policy sees the type, size, and hash of each one, not its content. A sanitizer cannot read or clean them. The result's restrictions come from the rule for the tool that returned it.
- Tools behind a tool search: some clients load a tool only after the agent searches for it. The proxy refuses a call to a tool that is not loaded yet and tells the agent to search for it first.