Sandboxing: Isolate the Agent by Construction, Because an Instruction Is Only a Request

Sandboxing means a compromised or runaway agent cannot harm the host, the other tasks running beside it, or production. The single principle that gets you there is to isolate by construction, not by instruction: a capability you removed is a control, and a rule you put in the prompt is only a request the model is free to ignore. The Replit incident is the clean proof. An AI agent ran destructive commands against a live production database after its operator "explicitly told it eleven times in ALL CAPS not to do this," wiping records for more than 1,200 executives and roughly 1,190 companies (incident writeup). The model read the instruction and deleted anyway.

Agent code is untrusted by construction. The model wrote it, and a prompt injection may have steered the model into writing something hostile. So the question the environment has to answer is not whether the agent misbehaves but what holds when it does. An SRE practitioner states the trap plainly: "If you give the power to perform destructive actions, you can only hope that it won't perform them. Even guardrails do not give you 100 percent of certainty" (r/sre, community sentiment, June 2026). Hope is not a boundary. Removed capability is.

Pick the tier by what you lose if it fails

Isolation runs on a spectrum, from a syscall policy on a shared kernel to a dedicated VM that shares nothing at runtime. Each step down the table shrinks what a compromised agent can reach, at the cost of heavier provisioning. Pick the tier by how much you are willing to lose if the boundary fails, then read the published evidence below for where each one holds.

The names are not interchangeable, and treating them as one word is its own failure mode. A devops practitioner who wrote a sandboxing deep-dive put it directly: "people throw around the word 'sandbox' like all isolation layers are equal when they really are not. The difference between containers, gVisor, microVMs, and Wasm matters a lot once AI agents start executing real code" (r/devops, community sentiment, May 2026).

Isolate filesystem and network together, or neither holds

Whatever tier you choose, the filesystem boundary and the network boundary only work as a pair. Anthropic states the mechanism plainly: "Without network isolation, a compromised agent could exfiltrate sensitive files like SSH keys; without filesystem isolation, a compromised agent could easily escape the sandbox and gain network access" (Claude Code sandboxing). Their implementation allows writes only inside the working directory and routes all traffic through a proxy outside the sandbox that enforces a domain allowlist, and the restrictions cover subprocesses too, not just the agent's direct calls. Build both at once or you have built a sandbox with a hole. The network half is its own chapter: egress control sets the proxy and the allowlist default.

In Anthropic's internal usage, sandboxing reduced permission prompts by 84%, because a bounded agent can be allowed to act freely inside the boundary instead of asking per command. Cursor reports the same shape of result from the other direction: its sandboxed local agents "stop 40% less often than unsandboxed ones" (Cursor, Feb 2026). Isolation is what makes autonomy affordable; see approval fatigue for the failure mode it prevents.

What to isolate: filesystem, network, credentials, tasks

A sandbox is not only a wall around the host. The boundary has to cover everything model-generated code can touch that another tenant or the operator would not want changed.

• Filesystem. Read and write confined to the working directory; sensitive paths (SSH keys, host config) unreachable. The agent should get a private, ephemeral filesystem whose writes do not persist after the run unless you snapshot them (Fly.io).
• Network. Outbound traffic deny-by-default through a proxy outside the sandbox, allowlisting only the hosts the task needs. Detailed in egress control.
• Credentials. Tokens held outside the sandbox, never reachable from where generated code runs. The synthesis of every credential-theft incident in the corpus is one line: the only credential an agent cannot leak is the one that was never reachable. Detailed in credentials and secrets.
• Other tenants. Each task gets its own box, so two agents do not collide and one agent's compromise does not reach another's work.

That last item is the one teams routinely under-build, because git is not the hard part. A practitioner running parallel agents: "Worktrees solve the git layer but shared dirs (~/.config, /tmp, process namespaces) still collide. The real fix is per-agent containers or at minimum explicit TMPDIR/HOME overrides per agent. Anything less just moves the collision point downstream" (r/cursor, community sentiment, March 2026). The boundary that keeps parallel tasks from colliding is one environment per task.

Make the box ephemeral: one per task, destroyed after

The unit of isolation is one task, not one agent or one machine. A fresh box per run is what makes "kill it" a complete recovery story instead of a partial one. A security practitioner names the implicit plan most teams already have: "the default plan I have been seeing for 'what if the AI agent misbehaves' is some version of 'kill the agent.' That's fine for sandboxes" (r/cybersecurity, community sentiment, May 2026). Killing the agent is only fine when the agent lives in a disposable box that holds no irreplaceable state and no other task's data. Per-task ephemerality is what makes that true.

The throughput teams run exactly this way. Stripe runs each unattended minion in a pre-warmed devbox spun up in 10 seconds, "isolated from production resources and the internet, so we can run minions on devboxes without human permission checks." Because the box is quarantined, "any mistakes an agent might make are confined to the limited blast radius of one devbox," which is why Stripe can run the agent with full permissions and skip confirmation prompts (Stripe case study). Ephemerality also buys reproducibility, the basis versioned images builds on; where the box runs is placement.

OS primitives are the single-user tier

For one developer's machine, the lightest tier is enough. Anthropic's bubblewrap/Seatbelt approach runs "without the overhead of spinning up and managing a container," confining the bash tool and any subprocess it spawns, and Anthropic open-sourced the runtime. It is the right tool where the agent and the user already share a kernel and the worst case is one laptop. Practitioners reach for the same idea even before a vendor ships it: one runs Claude Code "in a separate Unix account on my Mac, with permissions on my own home directory locked down," while noting the honest limit, that source-code exfiltration is still possible (r/ClaudeCode, community sentiment, June 2026).

But for Claude Code on the web, Anthropic's own hosted product, the design changes. Each session executes in an isolated cloud sandbox, and sensitive credentials such as git credentials and signing keys are "never inside the sandbox with Claude Code." A proxy holds the real token, verifies a scoped credential from inside the sandbox, and checks that a push targets the configured branch before forwarding to GitHub (Claude Code sandboxing). When the workload goes multi-tenant and hosted, the boundary hardens and the secrets leave the boundary entirely, the pattern credentials and secrets generalizes.

The container platform itself reached past containers

Kubernetes Agent Sandbox, developed under SIG Apps and announced on the Kubernetes blog in March 2026, is the strongest tell in the corpus. The project defines agents as "isolated, stateful, singleton workloads" and introduces a Sandbox CRD rather than asking teams to string together a StatefulSet of size 1, a headless Service, and a PersistentVolumeClaim per agent, which it calls "an operational nightmare" at scale (Kubernetes blog). And on isolation, the project whose substrate is the container does not default to it: the Sandbox resource natively supports gVisor and Kata Containers, "the necessary kernel and network isolation required for multi-tenant, untrusted execution."

The cost of the harder boundary is startup latency, and the project prices it explicitly: starting a new pod adds about a second, so a SandboxWarmPool keeps pre-provisioned sandboxes ready and a SandboxClaim hands one over already warm. Idle sandboxes scale to zero and resume where they left off. The warm-pool pattern is the answer to the latency objection at every tier: pre-provision the box so per-task ephemerality does not cost the user a cold start.

The multi-tenant end is a VM per sandbox

Fly.io's Sprites give each sandbox its own VM with dedicated CPU, memory, networking, and a private filesystem: "no shared runtime, no noisy neighbors, and no persistent state unless you explicitly snapshot it." They start in under a second and bill per second of actual consumption, which makes one-VM-per-run economical rather than extravagant. Fly names the qualifying workload directly: "untrusted or user-supplied code" that needs "hardware-level isolation to prevent the code from affecting the host or other tenants" (Fly.io).

This is also how the managed-sandbox option appears, where you rent the isolation primitive instead of operating it. Ramp built its Inspect background agent on Modal, running each session in a sandboxed Modal VM bundling the full service stack (Vite, Postgres, Redis, Temporal, RabbitMQ) with filesystem snapshots rebuilt every 30 minutes. Ramp's head of applied AI, Rahul Sengottuvelu: "It would have been really hard to build Inspect without Modal. A lot of the complexity is hidden behind just being able to spin up sandboxes very quickly with a lot of services and data" (Modal case study, Feb 19, 2026). Wallfacer (disclosure: the sponsor of this guide) lands at the same tier, booting a fresh Firecracker or Tart VM pair per session from a versioned snapshot. The snapshot-and-restore model buys reproducibility, the property versioned images builds on, and per-VM isolation is what makes one environment per task safe to parallelize.

The heuristic: container for trusted code, VM for the rest

Map the tier to the threat, not to fashion.

• OS-level policy when the agent runs on one trusted developer's machine and the worst case is that one laptop. Cheapest, no container to manage, and it still cut Anthropic's permission prompts 84%.
• A plain container when the code is yours and reasonably trusted, you control its inputs, and you mainly need resource limits and a clean working directory, not a defense against hostile syscalls. Run it rootless: a community note is that a dev container "can isolate the impact only to the container, as long as it runs in rootless mode" (r/ExperiencedDevs, community sentiment, via enrichment).
• A hardened runtime (gVisor or Kata) or a microVM/VM when the code is model-generated from inputs you do not fully control, or the box is multi-tenant. This is the common middle-to-high tier for shared agent infrastructure, and it is where all three teams who publish their choices land for untrusted, multi-tenant execution.
• A managed sandbox (Fly, Modal, or similar) when you want VM-grade isolation and fast per-task boot without operating the substrate yourself. You rent the hard part, which Ramp says is most of the complexity.

The boundary contains the breach, not the injection

Isolation bounds what an attack can reach. It does not close the attack. Fly is candid about the limits: a sandbox cannot stop prompt injection arriving through data the agent legitimately reads, cannot make a non-deterministic model deterministic, and only covers the scenarios you test (Fly.io). Anthropic's design assumes injection will happen and contains the blast radius instead, stating that "even a successful prompt injection is fully isolated" so "a compromised Claude Code can't steal your SSH keys, or phone home to an attacker's server" (Claude Code sandboxing). The mechanism a sandbox cannot stop, an agent that reads attacker-controlled data, then acts with privilege, then has a path out, is the lethal trifecta, and the casebook of real incidents shows it firing in production.

One gap, stated plainly: none of the three primary sources publishes escape rates or a head-to-head security benchmark across the tiers. The convergence on VMs for multi-tenant agent code is consistent architectural judgment from teams who run this in production, not a measured comparison. The corpus is silent on how often each boundary has actually been breached.