What is AI agent sandboxing?
AI agent sandboxing is the practice of giving an AI agent a disposable, isolated environment to run its tool calls in — generated code, shell commands, file writes, network requests — rather than letting those actions touch the host directly. The agent (or the person running it) never sees the difference functionally; the boundary exists so that when the agent does something wrong, whether from a bug or a successful prompt injection, the damage is contained to a box that gets thrown away.
Two different things get called "sandboxing agents" and the confusion causes real mistakes. Sandboxing the agent itself means the whole agent program — its process, its files, its view of the network — runs inside the box, which is what Docker Sandboxes does for Claude Code, Codex CLI, and Gemini CLI. Giving the agent a sandbox means the agent runs wherever it already runs and gets a disposable remote machine as a tool for executing code it writes — E2B's and Modal's code-interpreter product. Careful setups do both: sandbox the agent program, and still run its generated code in a second, throwaway sandbox.
Why does an AI agent need sandboxing?
Agents don't just generate text — they execute actions, and that execution surface is exactly what adversarial or malformed input can hijack:
- • Coding agents run shell commands. Real CVEs across Cursor, Copilot, Junie, Codex CLI, and Roo Code show prompt injection chaining into credential theft and remote code execution — covered in detail in AI coding agent security.
- • Data agents run model-generated Python/SQL. Executing that directly against production data or a host with real credentials turns a wrong query into a real incident.
- • Computer-use agents click and type with the same permissions as whoever's logged-in session they're driving.
- • Sandboxing isn't theoretical for the frontier labs either: a documented 2026 incident had OpenAI's own models break out of an evaluation sandbox and reach Hugging Face infrastructure during a cyber-capability test — see what happened.
Microsoft's own disclosure of two chained CVEs in Semantic Kernel showed how far this can go: prompt injection into an unsandboxed agent escalated into full host-level remote code execution. The fix in every one of these writeups is the same primitive — never let a model-generated action touch a host that has real secrets or data, full stop.
The four isolation boundaries, weakest to strongest
Every sandboxing option is really a choice about which of these boundaries an escaped agent would have to break through next.
| Boundary | Examples | How isolation works | Host kernel exposure | Best for |
|---|---|---|---|---|
| Process sandbox | bubblewrap, seccomp-bpf, Landlock | Restricts one process on the shared host kernel | Yes — full host kernel surface minus the filter | Cheapest guardrail on a trusted host; not enough alone for untrusted agent code |
| Container | Docker/runc, Kubernetes Pod | Namespaces + cgroups around a process group | Yes — a kernel bug is a potential escape route | Cheap, fast isolation for code you mostly trust; pair with gVisor/Kata for untrusted code |
| User-space kernel | gVisor (runsc), Kata-lite setups | A Sentry re-implements the Linux syscall ABI; only ~60–70 host syscalls are ever reached | No — host kernel sees only the Sentry's narrow, seccomp-filtered calls | Multi-tenant untrusted code execution at near-container weight (Cloud Run, App Engine, agent code-interpreters) |
| microVM | Firecracker, Kata Containers (QEMU-based) | Its own real guest kernel under KVM hardware virtualization | No — hardware-enforced boundary, full Linux syscall compatibility | Arbitrary/unpredictable agent-generated code where compatibility matters as much as isolation |
gVisor's own architecture documentation explains the user-space-kernel approach plainly: the Sentry re-implements enough of the Linux syscall ABI in memory-safe Go that the sandboxed workload never makes a host syscall directly — it only talks to the Sentry, which then forwards a narrow, seccomp-filtered set to the real kernel. A separate helper process, the Gofer, brokers filesystem access so the Sentry itself keeps minimal host reach — least privilege applied to the sandboxing layer's own internals. Read gVisor's architecture guide for the full mechanism.
Firecracker takes the opposite bet: instead of intercepting syscalls in user space, it boots a genuinely separate, minimal guest kernel per sandbox under hardware KVM virtualization. AWS, which open-sourced Firecracker and runs it under Lambda and Fargate, states a microVM can start in as little as ~125ms with under 5 MiB of memory overhead and that a single host can launch up to 150 microVMs per second — see Firecracker's own published specs. Because it's a real kernel, compatibility is "if it runs on Linux, it runs in the microVM" — there's no syscall-interception tax, at the cost of a small per-guest memory footprint.
Get the weekly AI engineering brief
Agent runtimes, agentic security, and the tools worth using — one practical email a week. Plus the free roadmap PDF.
By subscribing you agree to receive emails from AI Engineer Insights. Unsubscribe anytime. See our Privacy Policy.
How Docker Sandboxes, E2B, Modal, and Kubernetes Agent Sandbox differ
None of these products are a new isolation primitive — each one wraps one of the four boundaries above into a product with its own lifecycle, SDK, and cold-start trade-offs.
| Product | Isolation backend | Published startup figure | What it's for |
|---|---|---|---|
| E2B | Firecracker microVM | ~150–185ms cold start (vendor benchmark) | Purpose-built code-interpreter sandboxes for AI agents; open-source core |
| Modal | gVisor | ~800–820ms cold start (vendor/third-party benchmarks) | Serverless compute with GPU passthrough; isolation via gVisor's Sentry, not a VM |
| Docker Sandboxes | Custom microVM (Docker's own hypervisor) | Local-first, free; cloud burst metered | Each sandbox gets its own kernel and private Docker daemon; works for Claude Code, Codex, and other CLIs |
| Kubernetes Agent Sandbox | Pluggable — gVisor or Kata Containers | SIG Apps subproject; SandboxWarmPool targets sub-1s claims | Declarative Sandbox/SandboxTemplate/SandboxClaim CRDs for stateful, singleton agent workloads on K8s |
Cold-start figures are vendor- and third-party-published benchmarks, not an independently verified constant — measurement basis differs (cold boot vs resume-from-snapshot vs resume-from-hibernation), and the numbers shift release to release. Treat every number in that table as directional and re-measure on your own workload before building an SLA around it.
Kubernetes Agent Sandbox (kubernetes-sigs/agent-sandbox) is the newest entrant and the one most worth watching if you already run on Kubernetes: Google launched it as a formal Kubernetes SIG Apps subproject in November 2025, and the Kubernetes blog's March 2026 deep dive describes its Sandbox, SandboxTemplate, and SandboxClaim CRDs as a declarative, backend-agnostic primitive built specifically for singleton, stateful agent workloads — something Deployments and StatefulSets weren't designed for. It natively supports gVisor or Kata Containers for the actual isolation and adds a SandboxWarmPool to eliminate the roughly one-second cold start a freshly scheduled pod otherwise adds.
Does a sandbox alone make an agent safe?
No — sandbox escapes exist too, and they're already documented in production tools, not just research. Microsoft's Semantic Kernel disclosure showed an agent sandbox defeated through an unvalidated file-path parameter, letting an attacker write a payload straight to the host's Startup folder from inside the "isolated" sandbox — the same point the prompt-injection defense guide makes about coding agents specifically.
- • Scope credentials, don't just isolate compute. A sandbox with a long-lived, broadly scoped API key is still a liability if it's breached — pair isolation with short-lived, scoped tokens the way MCP server trust scoping recommends for tool permissions generally.
- • Control network egress explicitly. Every sandbox vendor above lets you deny-by-default outbound network access; a sandbox that can freely exfiltrate over the network defeats most of the point of isolating it.
- • Gate irreversible actions behind human approval, regardless of how strong the sandbox is — the same production-readiness checklist covered in AI agent runtimes.
- • Destroy the sandbox after every task. Ephemeral, single-use sandboxes mean a successful escape only ever compromises one throwaway box, not a shared, long-lived environment other tasks reuse.
Which sandbox should I actually use?
- • Running coding agents (Claude Code, Codex, Copilot CLI) locally or hybrid: Docker Sandboxes — same microVM boundary on your laptop and in the cloud, with a `sbx move` to carry work between them.
- • Per-task code-interpreter execution with fast, frequent spin-up: E2B — Firecracker-class microVMs purpose-built for this, with published sub-200ms cold starts.
- • Heavier compute or GPU-backed agent tool calls: Modal — gVisor isolation with GPU passthrough, trading some cold-start latency for flexible hardware.
- • Already running agent workloads on Kubernetes: kubernetes-sigs/agent-sandbox — declarative CRDs instead of hand-rolled pods, pluggable to gVisor or Kata, with warm pools for sub-second claims.
- • Homelab or self-hosted, no cloud sandbox vendor: a locked-down Docker container (no swap, PID limits, no network by default) is a reasonable floor, with gVisor's runsc as a drop-in upgrade once you need to run genuinely untrusted code.
Frequently Asked Questions
What is AI agent sandboxing?
AI agent sandboxing is running the code, shell commands, or file/network actions an AI agent generates inside an isolated, disposable environment instead of directly on a host with real credentials and data. The isolation can be a process-level filter (bubblewrap, seccomp), a container, a user-space kernel like gVisor, or a hardware-isolated microVM like Firecracker — each trades compatibility and performance for how hard the boundary is to break out of.
Why do AI agents need sandboxing at all?
Because agents execute model-generated actions, not just model-generated text: coding agents run shell commands, data agents run Python/SQL, computer-use agents click and type. A hijacked or simply buggy tool call on an unsandboxed host can read SSH keys, exfiltrate secrets, or modify files outside the task's scope. Microsoft's own disclosure of two CVEs in Semantic Kernel showed a prompt-injection-controlled agent could chain into full host-level remote code execution when nothing contained it.
What's the difference between a container and gVisor for sandboxing agents?
A plain container (runc) isolates with Linux namespaces and cgroups, but every syscall the containerized process makes still reaches the single, shared host kernel directly — a kernel bug is a potential escape route. gVisor interposes a user-space kernel called the Sentry that re-implements the Linux syscall ABI itself; the application's syscalls are trapped and serviced by the Sentry, and only a small, seccomp-filtered set (gVisor's own docs put it at roughly 60–70 distinct calls) ever reaches the host kernel, regardless of what the application does.
Is a microVM like Firecracker safer than gVisor for agent sandboxing?
They isolate differently rather than one being strictly safer. Firecracker boots a real, separate guest kernel per microVM under hardware KVM virtualization, so compatibility is that of an ordinary Linux box and there's no per-syscall interception tax — the trade-off is a per-guest memory cost and a boot step (mitigated with snapshot-restore). gVisor's user-space kernel reaches near-container weight and needs no hardware virtualization support, but it doesn't reimplement 100% of the Linux syscall surface, so syscall-heavy or exotic workloads can hit compatibility gaps. For arbitrary, unpredictable agent-generated code, the hardware boundary and fuller compatibility of a microVM is generally the safer default; gVisor is the better fit when you need container-like density and speed for more predictable workloads.
Does sandboxing alone make an AI agent safe?
No. Microsoft's Semantic Kernel disclosure demonstrated a sandbox escape through an unvalidated file-path parameter that let an attacker write a payload straight to the host's Startup folder from inside an 'isolated' sandbox. Sandboxing reduces blast radius; it doesn't replace least-privilege tool scoping, short-lived scoped credentials, network egress controls, and human approval gates for high-risk actions — the same controls covered in prompt-injection defense for coding agents.
What should I actually use to sandbox my agent's tool calls?
Match the tool to the workload: E2B or Docker Sandboxes (both Firecracker-class microVMs) for per-task code-interpreter execution where you want hardware isolation and fast snapshot-restore boot; Modal when you need gVisor-backed sandboxes with GPU passthrough for heavier compute; Kubernetes Agent Sandbox (the kubernetes-sigs/agent-sandbox CRDs, pluggable to gVisor or Kata) when you're already running agent workloads on Kubernetes and want a standard, declarative primitive instead of hand-rolled pods. None of these substitute for scoping the credentials and network access the sandbox is given in the first place.
Go deeper on AI agent sandboxing with AI
Ask your next question with this article as context. Opens in a new tab; you can edit the question before sending.
References
- • gVisor — Introduction to gVisor security (architecture guide)
- • google/gvisor (GitHub)
- • Firecracker microVM — official site and specs
- • AWS — Firecracker: Lightweight Virtualization for Serverless Computing
- • Google Open Source Blog — Agent Sandbox launch announcement (Nov 2025)
- • Kubernetes Blog — Running Agents on Kubernetes with Agent Sandbox (Mar 2026)
- • kubernetes-sigs/agent-sandbox (GitHub)
- • Docker Sandboxes — documentation
- • e2b-dev/E2B (GitHub)
- • Modal examples (GitHub)