Lead · Core path · 7 chapters
Sandbox design
Isolation boundaries, egress network policy (the concrete form of 7.3's third leg), filesystem scoping, per-execution credentials, resource caps, snapshot and rollback
A sandbox that leaks credentials, network access, or durable state turns prompt injection into an incident; the boundaries must be tested rather than assumed.
Read these first
What you will know
Compare containers, gVisor, and microVMs against a stated threat model, resource-cap strategy, and latency budget
Kernel exposure, device access, noisy-neighbor behavior, and cold-start cost vary substantially, so the cheapest isolation is not always adequate.
Configure default-deny egress and prove it holds
Default-deny egress is the concrete implementation of removing the trifecta's third leg.
Scope a filesystem so an escape attempt fails
Filesystem scoping stops a sandboxed process reading things it was never meant to.
Inject credentials per execution rather than baking them in
Per-execution credentials mean a compromise is bounded to one run rather than to the service.
Roll back a workspace after a run and verify nothing persisted
Snapshot and rollback make a bad run recoverable rather than permanent, but they do not undo external API calls or data already exfiltrated.
Chapters
- 1
Containers, gVisor and microVMs
A container with a tuned seccomp profile, gVisor, and a Firecracker microVM per execution are not three points on one quality scale. The container shares the host kernel, so one kernel bug crosses a line the other two would have held, while the microVM pays a cold start that a workload of forty executions a second cannot absorb. Tie the choice to a stated threat model, resource caps and a latency budget rather than to strength, and know that at high throughput the microVM you actually get is a pooled one.
- 2
Shared namespaces and warm pools
Separating browser-automation sessions by directory and per-session profile inside one container keeps cold start under 100ms and leaves every session's cookies and tokens readable by the code next to them, because a directory is a label and the namespaces are shared. The same reasoning bites the strongest technology: microVMs at high throughput require a pool, a pool means reuse, and reuse reintroduces the shared state the microVM was bought to remove. Track sharing per resource — which principals can name it, over what window.
- 3
Testing default-deny egress
A default-deny egress policy is a claim about behaviour, and the only evidence for it is an attempt that fails. Eight things leak past a policy that is exactly as written — IPv6 gaps, the window before the CNI programs rules, DNS, an allowlisted host that carries data, SNI confusion, link-local metadata, sidecars and a neighbouring pod — so the mechanism that counts is a canary suite run inside the real image on every change, with the verdict coming from outside. Pinning the registry by IP range is looser than pinning by hostname.
- 4
Filesystem scoping
Mounting the workspace at /workspace does not make the filesystem scoped. The property to establish is that nothing outside the scope resolves from inside: no host path mounted for convenience, no volume shared with another run, no symlink the collector dereferences on the host, no cache directory inherited from the image. Build the scope with a user namespace, an overlay and nosuid/nodev/noexec, then attack it, since an escape attempt that fails is the only evidence the boundary exists.
- 5
Secret managers and per-execution credentials
A warehouse credential baked into a sandbox image is readable by anyone who can pull the image, and moving it into a secret manager fetched at container start is not the redesign — it is still one credential per container, valid for every execution and every customer that worker serves. Minting a token per execution, scoped by a session policy to one table and one tenant and revoked when the run ends, is what bounds a compromise to the run that was compromised. The scope must come from the request context, never from the model.
- 6
Snapshot and rollback
Snapshotting a workspace before a run and rolling back afterwards undoes local state: files, installed packages, anything cached on disk. If the run POSTed data to an outside endpoint and opened a pull request, both stand and neither is recoverable, because a compensating action is a new event rather than the erasure of an old one. Rollback is a recovery mechanism rather than a containment one, verification has to look wider than the snapshotted subtree, and destroying the instance is often the better default.
- 7
Signing off a warm pool
Multi-tenant customer code against customer data at a 300ms p95 rules out a microVM per execution, so pooling warm instances is the right shape with all the risk hidden in one word. A reset that restores the filesystem but not kernel state, open sockets, the guest page cache or an environment variable is a boundary in name only. Write the three-sentence threat model, put the reset ladder on the page with the level you actually implement, and name the seven proofs and their owners before signing.
External resources
- Choose a sandbox environment - Claude Code Docscode.claude.com
Official isolation options: filesystem scope, network egress, per-run boundaries
- Cordon: Semantic Transactions for Tool-Using LLM Agentsarxiv.org
Task-scoped isolation, authority mediation, staged effects, lineage tracking and rollback for tool-using agents.
- Making Claude Code more secure and autonomous with sandboxinganthropic.com
Why egress policy is the hard leg, and how the boundaries were chosen
- Containers Don't Make Your AI Agent SafeWeb Dev Simplified
Where Docker isolation ends and microVM/gVisor boundaries start
- Run Untrusted Agent Code with LangSmith Sandboxes | Interrupt 26LangChain
Production sandbox setup: per-execution creds, resource caps, snapshots