Rules in the Prompt Are Not a Boundary: Enforce Agent Policy Outside the Agent

Most agents ship with their rules in the system prompt. You are a helpful assistant. Never send customer data outside the company. Always ask before deleting anything. Then the team hopes the model follows them, and most of the time it does.

The security review does not ask whether the model usually follows them. It asks whether you can prove the agent cannot send data out. A sentence in a prompt is not an answer to that question, and no amount of better wording turns it into one.

The model is the wrong layer to enforce its own rules

A language model produces the most likely continuation of everything in its context. The rules are part of that context, and so is every web page the agent reads, every tool result it processes and every ticket a customer wrote. When one of those carries an instruction that contradicts the system prompt, the model weighs the two. Sometimes the injected one wins. That is not a bug that a newer model fixes; it is what a model is.

So the question is not how to word the rule. It is where the rule runs. If it runs inside the process that reads untrusted text, it can be talked out of. If it runs outside that process, there is nobody to talk to.

Out-of-process enforcement

The pattern is old in operating systems and new in agents: the thing that enforces the policy is not the thing being policed. Sam Witteveen’s walkthrough of NVIDIA OpenShell shows it cleanly. A supervisor starts before the agent, prepares the sandbox, loads the policy and then launches the agent as a restricted child process. When the agent opens a connection, writes a file or calls a model, the supervisor checks the request against the policy before it reaches anything real.

The consequence is the one that matters for a review: if the agent is fully compromised, by a jailbreak or an injected page, the policy still holds, because the policy was never inside the thing that got compromised.

I run my own coding agent this way. It launches into an OpenShell sandbox, works on a staged copy of the repository, and its output reaches the real project only through a separate gate. None of those boundaries is a sentence in a prompt.

What the enforcer has to own

An agent touches the world through four doors. A policy that leaves one of them to the prompt leaves it open.

Network, denied by default. Nothing leaves the sandbox unless the destination is on an allowlist: the search API, the model endpoint, the one system the agent works in. Everything else is blocked outside the agent’s reach, so it cannot argue its way to a new domain.

Files, with no host mounts. The agent reads and writes a workspace of its own. Home directories, SSH keys and environment files are not mounted, so a whole class of credential theft has nothing to steal. In OpenShell the filesystem part of the policy is fixed when the sandbox starts; changing it means recreating the sandbox, by design.

Model calls through one local endpoint. The agent talks to a managed address inside the sandbox, and the supervisor decides where each call actually goes. The provider key is never in the agent’s view, and switching between a local and a hosted model is a routing change, not a code change.

Credentials injected at runtime, never kept on disk. Keys arrive when the sandbox is provisioned, travel only along the paths the policy names, and leave nothing behind. Whoever compromises the agent gets a running process, not a folder of keys.

The answer your security review can read

The policy is a file in a repository. It goes through a pull request, has a diff and a reviewer, and anyone who wants to know what the agent can reach reads it. When compliance asks whether the agent can send data externally, the answer is not a demo and not a promise about the model. It is the network section of that file, with deny as the default and a short list of named destinations.

That is also why the harness and the model can change without a new review. OpenShell runs the same runtime under different agent loops and different models; the policy does not care which one is on top, because it never asked the agent for anything.

Where this boundary stops

A sandbox decides what the agent can reach. It does not decide whether a write the agent was allowed to make should land. An agent with a permitted connection to your CRM can still update the wrong customer, and an agent allowed to send email can still send the wrong one. Those are the next boundaries, and they sit in the same place, outside the model: a person’s tap before every write that leaves the building, a split by reversibility with the previous value on every record, and a match the agent cannot make on a guess.

The test for each rule your agents follow today is the same one question: if the model decided to ignore it, what would stop it? Where the answer is “nothing, it is in the prompt”, that rule is the first thing to move. The self-check walks through the twelve places to look.