The sandbox held and it did not help

The sandbox held and it did not help

One failure survives everything above, and it is the one worth designing against explicitly.

The agent runs in a perfect sandbox. No credentials, no network, ephemeral, destroyed on exit. It writes code. The code is harmless inside the box, because nothing in the box matters.

Then the code leaves. It goes into a branch, a pull request, a build artifact, a migration file. Later it runs somewhere that does have credentials, network and persistence, executed by a CI system that trusts its own repository.

The sandbox contained the execution and did nothing about the artifact, which was the part with a future. An attacker who can influence what an agent writes does not need to escape anything. They only need to be patient, and CI will do the rest with far more authority than the agent ever had.

The answer is that agent-authored artifacts are tainted until a human has read them, and the place that gets enforced is the pipeline rather than the sandbox. Branch protection that a bot cannot satisfy alone. Review required, by a person, on anything an agent produced. No auto-merge on agent branches, whatever the test suite says.

This is the seam between this chapter and chapter 13, and it is where the two threat models meet.

The shell case

An agent with a terminal on a developer machine is a different product with a different threat model, and it is worth being direct about it.

That machine has credentials. It has SSH keys, cloud CLI sessions, a package manager, network access to internal services, and a git remote with push rights. None of the four properties hold and most of them cannot be made to hold without making the tool useless, because reaching those things is the entire point.

What is available is narrower and still worth doing. Require approval for irreversible commands, which is chapter 14, with the class judged on irreversibility rather than a blocklist of command names. Keep production credentials off the machine entirely rather than trusting a prompt to avoid them, which is what would have stopped Replit. Log every command with its provenance so that chapter 17 has something to read.

Do not pretend this configuration is contained. Say plainly that it is a trusted tool on a trusted machine, and spend the effort on reducing what that machine can reach.

What this costs

Latency, mostly. Creating and destroying an isolated environment per task adds seconds, and for an interactive coding agent seconds are expensive. Warm pools help and reintroduce exactly the state-reuse problem the ephemerality rule exists to prevent, so pool the runtime and never the filesystem.

The second cost is developer experience, and it is the one that kills implementations. No network means no package installs, which breaks half of what people wanted the agent to do. The allowlisted registry proxy is the answer and somebody has to build and run it.

The third is that some teams will decline all of this for their internal coding agents, on the grounds that the machine is trusted and the friction is not worth it. That is a defensible position for a tool with no untrusted input. It stops being defensible the moment the agent reads a pull request from outside the team, and the transition usually happens without anyone noticing.

Chapter 12 turns to the state that outlives a single task, and the injection that waits.

Sources for this chapter

The four properties, the SandboxSpec type and the argument for making credentials unrepresentable in it, the rule that sandbox output returns tainted, and the position on shell-access agents are the author's. The September 2026 advisory counts were taken by this book directly from GitHub's public API; the script and full output are in assets/replication/. The 28-of-53 figure remains secondary-sourced (UNVERIFIED-CLAIMS.md #11). The claim that containers are adequate for most threat models is a judgement, not a measured result, and readers with a nation-state threat model should disregard it.