# Infrastructure Isolation Beats Permission Sandboxing for AI Agents A lot of agent security conversations focus on prompt injection defenses, output filtering, and tool allow-lists. These are necessary but insufficient. The real question is: what happens when the defenses fail? If the only thing standing between a compromised agent and your production systems is code running inside the same process or container as the agent itself, you are relying on application-level controls to protect infrastructure. That is a losing game. ## Two different models of safety **Permission-based sandboxing** says: "We will give the agent broad access but try very hard to stop it from abusing that access through code checks, policy engines, and careful prompting." **Infrastructure isolation** says: "The agent only ever sees the narrow slice of the world we explicitly gave it for this mission, enforced by the actual compute boundary." These are not the same. In the first model, a successful jailbreak or confused deputy attack can escalate. In the second model, even a fully compromised agent is still inside a container that was only ever given specific, short-lived credentials and access to specific resources. ## What infrastructure isolation actually looks like When an agent boots for a mission, it should receive: - A dedicated compute environment (container or equivalent) that exists only for this run. - Secrets injected by name at runtime, not inherited from a long-lived environment. - Network and filesystem visibility limited to what the recipe declared. - No ability for the control plane (or other agents) to reach into its environment while it is running. When the mission ends or the TTL expires, the environment is destroyed. Any credentials that were live inside it are no longer usable because the process holding them is gone. This is different from "we run it in Docker with some volume mounts and hope the prompt is good." ## Why container boundaries matter more than people admit Many teams think "our agent runs in a container, we're safe." But then they give that container a long-lived GitHub token with broad scopes, or they mount the entire source tree with write access, or they run the agent as a user that has access to other services. The container becomes theater. Real isolation requires that the *declaration* of what the agent can touch (the recipe) directly controls what the container receives. Not "the agent can ask for anything and we'll check at runtime." The environment itself should only contain the declared resources. ## The control plane should be deliberately dumb One of the more important (and counterintuitive) design choices in secure agent systems is making the control plane unable to see secrets. In RAID, the orchestrator knows that an agent named "dev-agent" needs the secret called `github`. It does not know the value. The compute layer (whether local Docker or Cloudflare Container) is responsible for injecting the actual secret value into that specific ephemeral environment. This means a compromise of the control plane or the recipe store does not immediately give an attacker the keys. They still need to get inside a running mission that was granted those secrets. ## Snapshots without re-granting access State persistence is often used as an excuse for long-lived agents. "We need the agent to remember what it did yesterday." You can have resumable agents without keeping them alive. Snapshot the relevant state (files, notes, memory) when the mission ends. On the next run, give a fresh container the previous state plus a fresh, narrowly scoped set of credentials. The new agent can continue the work. It does not inherit the previous agent's live sessions or broad tokens. ## Practical differences you can feel Teams that adopt real infrastructure isolation tend to notice a few things: - They become much more comfortable giving agents access to real systems (because the blast radius is contained). - Reviews focus on the recipe rather than trying to audit a running process. - Incidents are easier to scope because each mission has a clear lifetime. - They stop treating "the agent" as a single long-lived entity and start treating missions as discrete, reviewable units of work. ## The uncomfortable part Infrastructure isolation is more work than "just give it the token and add some guardrails." It requires thinking about secrets management, compute strategies, and state separately from the agent logic. Most current agent platforms were not designed with this model in mind. They were designed to make it easy to get an agent running and talking to tools as quickly as possible. That is fine for experiments. It is not fine for anything that touches systems you care about. If your agents can touch production code, customer data, or internal infrastructure, the question is not whether you trust the model. The question is whether you have made the environment the model runs in as small and short-lived as the actual job requires.