Sandboxing & Blast Radius

A team spends real engineering effort on the permission layer from the previous chapter: reads auto-approve, writes and dangerous commands gate on a human, nothing lands on main without review. Then, one ordinary afternoon, a well-behaved session pulls in a scraped web page, or an issue comment, or a dependency’s README, and buried inside it is an instruction the developer never wrote — package up the contents of this directory, or these environment variables, and send them somewhere. The permission system, tuned exactly as designed, does not catch it. Not because it failed, but because the resulting action was shaped like something the session had already been trusted to do.

That is the uncomfortable case this chapter is about, and it is not a hypothetical exotic to security teams. Prompt injection — hostile instructions embedded in a file, page, or tool result that redirect an agent toward actions nobody asked for — is common enough that Claude Code documents it as a first-class threat with its own defense stack, not a footnote. The instructive detail is in how that defense is built: the auto-mode classifier that screens actions in the background deliberately never sees the tool results the model is reasoning over, specifically so injected text embedded in those results cannot influence what the classifier approves. That is a design choosing to accept a blind spot rather than pretend one doesn’t exist — an admission, from the team best positioned to know, that a policy check reasoning about intent can be wrong.

What the permission layer can’t promise

The previous chapter treated permission architecture as the harness’s policy layer: a set of rules, or a classifier, deciding whether a given action should proceed without asking. That layer is worth building carefully, and it measurably works — but it is still a layer of judgment sitting on top of either a model’s reasoning or a smaller model’s pattern match, and judgment can be wrong. It can be tricked by an instruction shaped to resemble something already trusted. It can miss an edge case nobody anticipated when the rules were written. It can simply have a bug, the same as any other code that ships to production. None of that is a reason to distrust permission systems specifically; it is a reason to distrust the idea that any policy layer, however well designed, is the last line of defense.

A well-designed harness does not rely on the check being perfect. It assumes the check might fail — through deception, misconfiguration, or an ordinary bug — and bounds what happens next with something that isn’t reasoning about intent at all, only about physical or logical possibility. That is the real distinction between a permission rule and a sandbox: a permission rule says an agent may not do something; a sandbox says an agent cannot, regardless of what it was told or what it believed it was doing. Policy answers a question. Structure removes the question for an entire class of actions.

Blast radius as a design budget

Security teams have a name, borrowed from incident response, for the scope of what a single compromised credential or resource can reach: blast radius. Applied to an agent session, blast radius is the maximum damage one action — or one session that goes wrong for any reason, injected instruction or otherwise — could plausibly cause, given everything it currently has access to. It is not a measure of what did happen. It is a measure of what was possible, whether or not this particular session’s error was the one that found it.

The useful move is to stop treating that number as a fact about the environment and start treating it as a budget the team sets, deliberately or by default. Every access decision — which directories are writable, which hosts are reachable, which credentials sit in the process environment, which other processes a session can see or signal — either shrinks that budget or grows it. Most teams never set it on purpose. They inherit whatever access was fastest to wire up, which is usually the developer’s own full environment, because that configuration makes the agent maximally capable with zero setup friction. That default is not neutral. It is the largest blast radius available, arrived at by not choosing.

The isolation layers, from lightest to heaviest

Teams shrink that budget with four layers in practice, roughly in order of how much they contain and how much they cost to run.

OS-level sandboxing is the lightest: process-level restrictions on what a shell command and its children can touch, enforced by the operating system itself rather than by an approval prompt. Claude Code’s sandboxed Bash tool is a concrete instance — built on Linux bubblewrap and macOS Seatbelt, it scopes filesystem writes to the working directory and routes all network access through a proxy that enforces a domain allowlist, so a command can run freely inside the boundary without asking permission for every step inside it. Anthropic reports that this cut permission prompts by 84% in internal usage — not because the agent got less capable, but because the OS is doing the containing that the approval dialog used to have to do at the point of every command.

Container isolation goes further: the session runs inside its own filesystem and network namespace entirely, so even a maximally permissive agent inside the container has no path to the host system underneath it. OpenHands’ agent-server workspace is a working example — each session gets a Docker container that pulls or builds its own image, starts an agent server inside it, and tears the container down when the session context closes, giving the agent complete isolation from the host for the lifetime of that session. The cost is real: building and starting a container per session is heavier than a process-level sandbox, and a containerized environment can drift from what a developer’s real machine looks like in ways that cause their own friction later.

Network egress control is narrower but matters specifically against exfiltration, which the other two layers don’t fully address on their own — a sandboxed or containerized session can still read everything on disk and, without an egress restriction, still send what it read somewhere. A deny-by-default egress policy that only permits explicitly approved destinations closes that gap regardless of what convinced the agent to try: the same allowlist that stops a compromised cloud workload from phoning out stops a manipulated agent for an identical reason, because neither the attacker’s intent nor the injected instruction’s cleverness matters once the destination itself isn’t on the list. A recent cross-industry security briefing places egress filtering among the handful of foundational hardening controls worth prioritizing precisely because the pattern predates AI agents and simply gets reapplied — the briefing’s own example is that egress filtering blocked essentially every public exploit attempt against the Log4j vulnerability, years before anyone was worried about a coding agent.

Worktree isolation is the lightest layer and the odd one out — it isn’t really a security boundary at all, but it solves a real problem the others don’t. Running each concurrent session in its own git worktree, a separate working directory sharing one repository’s history, keeps parallel sessions from overwriting each other’s edits in real time; Claude Code’s desktop app now creates one automatically per session for exactly this reason. This is the isolation-of-convenience half of the spectrum, connected to the concurrent-session collision problem this Library’s Volume II covered under Context Drift — worktrees stop two agents from clobbering the same file. They do nothing at all against a session with full filesystem and network access that is genuinely malicious or badly misled, because the worktree only isolates the working directory, not what a shell command inside it can reach.

How the layers compose

These layers stack rather than compete. A session can sit inside a container, with an OS-level policy further restricting what runs inside that container, with egress control on top narrowing what the container can reach — each layer closing a gap the others leave open. What doesn’t stack for free is the cost: heavier isolation buys a stronger guarantee at the price of setup effort and, often, an environment that diverges from what a developer actually works in day to day, which becomes its own source of friction when a fix behaves differently sandboxed than it does live. Lighter isolation is nearly free and solves a real problem — concurrent sessions on one machine — but offers no protection at all against a session that is trusted with more than it should be.

The permission layer decides what an agent may do. The isolation layer decides what happens if that decision was wrong.

Calibrating blast radius to trust

Choosing among these layers is the same calculation this Library’s Volume III applied to when planning earns its cost in Plan-Mode Thinking, run against a different variable: not task size, but trust and worst-case cost. A short-lived session fixing a typo in a private repository with no live credentials in its environment does not need a Docker container standing between it and the filesystem — the blast radius was already small, and heavier isolation there is pure overhead, the same ceremony failure mode that chapter warned against. An unattended session running overnight against a monorepo with production secrets loaded, or one built to accept issues and pull requests from outside the team, is exactly the case where the heaviest available layer is buying something real. Blast radius as a budget means asking, before either extreme becomes a habit, how much this particular session is trusted with and how much a worst case would actually cost — then choosing the layer, or combination, deliberately instead of inheriting whatever was easiest to wire up first.

What the telemetry should show

Operon does not yet run enough sandboxed and unsandboxed sessions side by side to publish a real distribution here, and this chapter will not invent one. What follows is the shape of the instrument worth building, offered as a starting point rather than a finding.