Sandboxes and the Blast Radius

Permissions decide whether a command asks first. The sandbox decides what a command can reach once it runs. The blast radius is everything the worst command the agent could run would reach: files, credentials, networks, data, money.

You set the blast radius before the first session, and you set it by naming that worst command and making sure the environment cannot carry it far. Relying on the agent not to run it is not a control. Relying on yourself to notice in time is a weak one, as the previous page showed. Taking the reach away holds no matter what the agent decides or what you approve.

Blast Radius, Defined

The blast radius of an environment is the set of things one command could damage or expose from where the agent runs. On a developer laptop it is large. It includes the home directory and every other project in it, every stored credential (the cloud account login, the SSH keys, the token for the package registry), the company network, and any database a configuration file points at.

In a container that has the repository mounted and nothing else, the blast radius is the repository, and the repository has an undo. The agent, the model and the task are identical in both cases. What differs is the answer to "what could go wrong?", and only the environment changed it.

The Worst-Command Exercise

For each place you run the agent, write down the worst commands it could plausibly run there and what each would reach. Do it before the first session, and do it with specific commands, not categories. For a Cragmoor laptop the list starts like this.

The right-hand column is the point of the exercise. Each fix removes the command's reach instead of relying on the agent not to run it. A deny rule on force-pushes is worth having too, but the stronger control is an environment from which a push cannot authenticate, because then it does not matter how the command was spelled or who approved it.

Containers

The simplest sandbox is a container with the repository mounted and nothing else. The agent runs inside it, so the home directory, the keys and the other projects are not hidden from it; they are simply absent. How containers work is the subject of Docker Deep Dive. The policy here is about what goes in: the code, the toolchain for your language, a local test database that the test command starts, and nothing that authenticates to anything real.

A container is only as good as what you put in it. The most common mistake is mounting the home directory, or the cloud configuration folder, "so the tools work". That gives the container a laptop's blast radius in a smaller box. If a task needs something from outside, give it that one thing, scoped to the task, rather than the directory it lives in.

Make the container part of the repository. A container definition committed alongside the code, describing the toolchain, the test database and nothing else, means every engineer and every agent works in the same environment, and a change to that environment goes through review like any other change. Many editors can open a project directly inside such a definition. Cloud agents build their environments from a similar file, which is one more reason to keep it short and deliberate.

No Production Credentials

The agent's environment holds no credential that reaches production or shared data. Tests use the local database the test command starts, not a shared one. Without a credential, the command fails however it is spelled and whoever approves it, which no rule and no instruction can promise.

Staging is not an exception. At Cragmoor the staging database holds a copy of real member data, refreshed every week, so a staging credential exposes real people's names and bookings. A credential's risk is what it reaches, not what the environment it points at is called. Chapter 12 applies the same rule, least privilege, to the tokens a team gives agents that work on its behalf.

Limited Network

Outbound network access should allow the package registry and the documentation the task needs, and nothing else by default. A network the agent cannot reach is a place it cannot send your code to and cannot fetch instructions from. Both matter: Chapter 12 shows how text the agent fetches can carry instructions, and an open network is how an instruction to send a file somewhere gets carried out.

At Cragmoor the allow-list is short: the package registry for each language the team uses, the documentation site of the main framework, and the shared repository for fetching. Everything else is refused. When a task genuinely needs a new destination, someone adds it on purpose, in a reviewed change, rather than the agent finding out whether it can reach it.

As of 2026 some agents offer a sandbox of their own, with a filesystem boundary and a network allow-list that starts empty. Use it if yours has one, and read what it covers. One widely used design, for example, restricts where commands can write but still lets them read most of the machine by default, including credential files, unless you deny those paths explicitly.

What a Sandbox Does Not Do

A sandbox contains damage. It does not make a change right. A sandboxed agent still writes a wrong diff, and you can still merge it, and then the bug runs in production with production's reach. The refund change, made in the tidiest container imaginable, can still refund the wrong amount to every member.

The sandbox, the permissions, reading and tests are four controls for four different failures. The sandbox bounds what a bad command can damage. Permissions spend your attention where it is needed. Reading the diff, Chapter 6, catches the change that is wrong. Tests, Chapter 8, catch the behaviour that broke. None of them substitutes for another.