Build · sandbox stacks

Sandbox stacks: recommended combinations

No single project solves this. The setups that work in practice are compositions — one boundary for the agent's environment, another for the host, and the credentials held somewhere neither of them can reach. Here are six, with the trade-offs stated rather than implied.

The invariants that apply to every stack

Whatever you build below, these five rules are what make it hold:

The original project is never the thing the agent writes to. Give it a copy, and make "apply" a separate reviewed operation.
Credentials live outside. The agent gets placeholders and a proxy URL.
Network policy is in the kernel, not in environment variables, and it fails closed.
The agent's own sandbox stays enabled as a second wall inside whatever you built.
Everything comes back as a diff you can read. This is the control that survives a model becoming smarter.

Stack 1 · The five-minute container

tier 1 · accidents

Host your workstation. Assume nothing here is protected yet.

↓

Workspace copy: Git worktree or reflink 37 ms and a few megabytes. The original stays untouched.

↓

Rootless Podman container no daemon, no socket, capabilities dropped, memory and pids limits, no privileged mode.

↓

Coding agent with its own sandbox left on the free second wall — do not disable it just because you are in a container.

What it stops: the agent wrecking your project, wandering your home directory, or touching anything outside the copy. What it does not stop: a container escape, prompt injection exfiltration, or anything about credentials that are still in its environment.

This is where almost everyone should start, and for a watched agent doing ordinary work it is genuinely enough. Upgrade to stack 2 when you stop approving commands.

Stack 2 · The hardened local container

tiers 1–2 · accidents + exfiltration

Host + rootless Podman as stack 1, but the workspace copy is mandatory rather than optional.

↓

Internal network + egress proxy with a hostname allowlist raw sockets have no route. The proxy resolves DNS itself and blocks link-local and 169.254.169.254.

↓

Credential broker outside the container the agent's environment holds placeholders; the proxy injects the real key at the boundary. nono's pattern, Infisical Agent Vault, or a small mitmproxy addon.

↓

Process sandbox around the agent bubblewrap or Landlock restricting it to the workspace copy, inside the container.

↓

Secret scanning in pre-commit gitleaks or detect-secrets, so a mistake that brokering did not cover cannot be committed.

What it stops: nearly all accidents and the majority of exfiltration, including the boring kind where an agent prints its environment into a transcript or a log. What it does not stop: a shared-kernel escape, or an agent doing something permitted that you did not want.

This is the configuration this guide would call "properly set up" for most individual developers, and every component of it is available today with mature tools.

Stack 3 · Strong isolation on Linux

tiers 1–3 · adds hostile code

Host with KVM without /dev/kvm this stack does not exist. Use stack 2 and a VM instead.

↓

Cloud Hypervisor microVM (or Kata, or a full VM) its own kernel per workload, virtio-fs for the workspace, snapshot pool so starts are fast. Firecracker if you want the smallest device model and can live without virtio-fs.

↓

Rootless Podman inside the guest one disposable lane per task. You may be relaxed inside the guest — that is the point of the guest.

↓

Agent's process sandbox, on third wall, free, and it constrains mistakes without any host exposure.

↓

Broker at the guest's egress the guest has no credentials; the host-side proxy has them.

What it stops: everything in tiers 1 and 2 plus genuine hostile code, up to a hypervisor bug or a device-model flaw. This is also the configuration that makes multi-tenant or untrusted-code work defensible.

The real costs: you must supply a kernel and a rootfs (or adopt an orchestrator that does), file sharing is slower than a bind mount, and you must decide how you receive engine updates — the independent study's worst findings were frozen engine pins, not engine bugs.

Stack 4 · Windows, without fooling yourself

tiers 1–2, with a real VM underneath

Windows host a non-admin account, and no expectation that process isolation alone is a boundary here.

↓

Dedicated WSL2 distribution, interop closed a real Hyper-V VM. Set interop=false in /etc/wsl.conf and mount /mnt read-only or not at all — this is the step everyone skips and the one that matters.

↓

Rootless Podman inside WSL2 the same engine and the same flags as stack 2, plus a real hypervisor above it.

↓

Allowlist egress from inside the guest note that unelevated Windows tooling cannot enforce kernel-level network policy — inside WSL2 you can.

↓

Broker on the Windows side or a separate host keys never enter the distribution.

Variants: when you need a Windows guest rather than a Linux one — for GUI testing, Windows-only tooling, or a genuinely untrusted installer — substitute Windows Sandbox (disposable, one instance, Pro/Enterprise) or a Hyper-V/HCS VM with GPU paravirtualisation for the first layer, and keep the rest of the stack unchanged.

What to avoid: host-control MCP servers running on your desktop, Docker Desktop's WSL2 integration treated as a security boundary, and any configuration where the agent's distro can reach your real files through /mnt.

Stack 5 · A secretless computer-use agent

tiers 1–2 · the injection case

VM or microVM with no host share at all not even read-only. A computer-use agent does not need your files; give it a fresh checkout inside the guest.

↓

Linux desktop and browser a dedicated browser profile per task, discarded afterwards, so a compromise in one session cannot inherit another session's cookies.

↓

Agent driver, accessibility-tree first driving real UI elements is more reliable and cheaper in tokens than pixels, and it removes some purely visual injection classes. Both remain attacker-readable input.

↓

Destination allowlist, enforced outside the model the control that measured 0% attack success in the literature, alongside a planner/reader capability split.

↓

Human gate on consequential actions, plus a one-way stream you watch, you can pause and take over, and send/buy/delete/publish need approval. The gate is outside the agent's control by construction.

What it stops: the realistic attack, which is not an escape but a persuasion — "read this page and then do what it says". Published success rates for this class of attack against unprotected agents run from the tens of percent to, under adaptive attacks, far higher. There is no prompt-level fix; the fixes are architectural.

What it does not stop: an agent doing something permitted that you did not want, and a hypervisor bug. Assume anything the agent can see can instruct it.

Stack 6 · A team or home-server pool

tiers 1–3 · more machines than your laptop

A Linux box you control a workstation, a home server, or a self-hosted node in the cloud.

↓

Incus (or Kata on Kubernetes) for per-task machines CoW-backed storage makes forking an agent machine nearly free, and profiles make the environment reproducible. Kata if you already think in container manifests.

↓

Containers inside each machine one lane per task, with the workspace fan-out strategy from stack 1.

↓

One broker for the whole pool the reason to centralise: every lane gets placeholders, and the real credentials exist in exactly one place you audit.

↓

Cluster or host egress policy Cilium-style policy if you are on Kubernetes, an internal network plus a proxy if you are not.

What it buys you: more parallelism than a laptop, persistent environments that survive reboots, and a single place to enforce credentials. What it costs: real operations work — and remember the pitfall that the whole field keeps rediscovering, which is that a pool without a control plane nobody enjoys using is a pool nobody uses.

Which stack, by threat and platform

Pick the left-most stack that covers your threat. Moving right costs setup time and configuration effort; moving left costs coverage.
Your situation	Stack	Why not further right
I watch the agent and approve commands	1	Your own review is doing the work; a microVM adds cost without adding much beyond the approval step you already have.
I run with permissions bypassed on my laptop	2	You have removed the human check, so the sandbox has to carry it. Hostile code is still out of scope.
I process untrusted content or third-party code	3	Only a separate kernel credibly answers "what if the code is trying".
I am on Windows and want Linux tooling	4	You already have a hypervisor; you just have to close the bridges.
I want an agent browsing and clicking for me	5	Nothing else addresses persuasion, which is the actual attack.
I need more than one machine's worth of agents	6	Stack 3 does not scale past your laptop's RAM.
I only need to execute code snippets, not a shell	WASM	Wasmtime with explicit capabilities is stronger and faster than any of these for function-shaped work.

What each stack covers

Stack	Accidents	Exfiltration	Hostile code	Effort to set up	Ongoing cost
1 · Five-minute container	yes	no	no	minutes	~zero
2 · Hardened container	yes	mostly	no	an afternoon	care and feeding for the broker
3 · Strong Linux isolation	yes	yes	yes	days, longer without KVM experience	kernel/rootfs/pin management
4 · Windows	yes	mostly	borderline	an hour if WSL2 is already there	watch Windows bridge settings after updates
5 · Computer use	yes	yes	borderline	an afternoon	streaming and approval workflow
6 · Pool	yes	yes	yes	weeks	real infrastructure operations

The point of the page Notice that the difference between stack 1 and stack 2 is not a different runtime — it is credentials and egress. That is the cheapest large improvement available in this entire field, and it is available to everybody today with tools that have existed for fifteen years. Everything to the right of stack 2 is a real improvement, and none of it substitutes for the two changes in stack 2.

If you are building the fan-out yourself — a desktop application that starts many agent boxes, some with a screen attached — the backend-per-threat-level question and the honest memory arithmetic live in Computer Use, under "Fanning out".