Why AI Agent Sandboxes Deserve a Fresh Look

If you’re only running your own services that are constrained by CI/CD pipelines and security baselines, traditional containers are already a very mature production tool. But AI agents flip the problem around: they dynamically generate commands based on context, download dependencies, execute scripts, modify files, and may even spin up new containers. The execution target is no longer a stable, auditable, pre-packaged workload — it’s a continuously changing, not fully predictable piece of code.

So when discussing AI agent sandboxes, the core question isn’t “are containers secure?” but rather “where do you draw the isolation boundary, and what capabilities must exist inside that boundary?” The closer the boundary is to the application layer, the faster startup is and the lower the compatibility cost — but the more you rely on the host kernel and policy configuration. The closer the boundary is to hardware virtualization, the stronger the isolation, but the higher the cost, scheduling complexity, and operational overhead.

By mid-2026, several fairly clear technical approaches have emerged in this space: hardened containers, microVMs, gVisor, fine-grained policy layers, and managed sandbox platforms.

AI Sandboxes Are More Than a Command Line

In early discussions of agent sandboxes, many people assumed the problem being solved was “the LLM generated some code — where should it run?” That question certainly matters, but it only covers a fraction of what an agent can do.

A real agent doesn’t stay in the terminal. It might clone a repository with shell commands, then log into a backend system through a browser, download a CSV file, clean the data with Python, open LibreOffice or a browser to preview results, and finally upload the file to another web form. For a human, this is a continuous workflow on a single computer. For an agent, it requires the sandbox to provide a file system, network, browser state, GUI desktop, and command line — all within the same controlled environment.

This is why AI agent sandbox requirements are higher than those of traditional code-execution sandboxes. They must not only prevent untrusted code from escaping, but also prevent an agent from being manipulated by external content while browsing the web, reading documents, or operating desktop applications. Browser pages, PDFs, emails, web forms, issue comments, and README files can all become vectors for prompt injection.

This is also why agent sandboxes are evolving from “securely executing a piece of code” toward “providing a temporary, observable, constrained, and recyclable computer.”

The Container Approach: Hardening on a Shared Kernel

The first category is Docker/OCI containers. The basic idea is to keep using the shared-host-kernel container model while reducing the attack surface through seccomp, AppArmor/SELinux, read-only root filesystems, dropping unnecessary Linux capabilities, user namespaces, and rootless mode.

The advantages of this approach are clear:

  • Mature ecosystem: Docker, containerd, and Kubernetes are all built around it;
  • Complete toolchains for images, caching, networking, logging, monitoring, and deployment;
  • Fast startup and low resource overhead;
  • High engineering cost-effectiveness for trusted first-party services, internally controlled CI, and development environment reproduction.

Its limitations are equally clear: containers do not have an isolated kernel. Processes inside a container still access the same host Linux kernel through system calls. Docker’s own security documentation lists kernel namespaces, cgroups, daemon attack surfaces, configuration gaps, and kernel hardening as core container security concerns.

As a result, containers are well suited for “engineering isolation of trusted workloads,” but should not be used alone as a “strong untrusted code boundary.” Once your threat model becomes “an agent may generate malicious code, third-party scripts may actively attempt to escape, and multiple tenants must not trust each other,” you can no longer rely solely on container configuration as your last line of defense. Containers still have a role, but they function more as a foundational packaging layer than as a final security boundary.

The MicroVM Approach: Pushing the Boundary to Hardware Virtualization

The second category is microVMs. Representative technologies include AWS Firecracker, Kata Containers, Cloud Hypervisor, and the execution platforms built around them.

The core idea of microVMs is: don’t let untrusted code share the host kernel directly. Instead, give each workload a lightweight virtual machine. This VM has its own guest Linux kernel, and the host and guest are separated by hardware virtualization mechanisms such as KVM, Hypervisor.framework, or Windows Hypervisor Platform. Even if the guest kernel is compromised, an attacker must still cross additional boundaries — the VMM, virtio devices, vsock, file sharing, credential proxies, and more — before affecting the host.

Firecracker is the most representative project in this category. It was built by AWS for multi-tenant serverless scenarios like Lambda and Fargate. Its official characteristics are: KVM-based, minimal device model, designed for function and container workloads, capable of starting user-mode code in as little as 125ms, with per-microVM memory overhead under 5 MiB.

Kata Containers takes a different path: it is not a VMM, but rather a runtime orchestration layer that plugs lightweight VMs into the container ecosystem. Kubernetes still sees what looks like a normal Pod or container, but underneath, VM-level isolation can be provided by Cloud Hypervisor, Firecracker, or QEMU. Cloud Hypervisor leans toward modern cloud workloads, while Kata leans toward keeping Kubernetes/OCI workflows intact.

This approach can be summarized in one sentence: when workloads are genuinely untrusted, correctly hardening thousands of container configurations may be harder than simply starting a lightweight virtual machine.

This is why AI agents, online code execution, third-party CI, and multi-tenant development environments keep returning to microVMs. It’s not because microVMs have no vulnerabilities, but because the isolation boundary is clearer: inside, you can give the agent root, sudo, a Docker daemon, a package manager, and a full development environment; outside, the virtualization boundary limits the consequences.

Docker Sandboxes is a very typical new example. It targets coding agents like Claude Code, Codex, Copilot, Cursor, Gemini, Kiro, and OpenCode. Each sandbox has its own microVM, Docker daemon, file system, and network. Docker’s documentation and blog emphasize that it does not use Firecracker, but rather a proprietary VMM: Apple Hypervisor.framework on macOS, Windows Hypervisor Platform on Windows, and KVM on Linux. This means Firecracker’s 125ms and 5 MiB figures are Firecracker’s own metrics and cannot be directly applied to Docker Sandboxes.

The gVisor Approach: Placing a User-Space Kernel Between Applications and the Host Kernel

The third category is gVisor. Developed by Google, it sits between traditional containers and full virtual machines.

gVisor’s core component is called Sentry — think of it as an “application kernel” running in user space. When an application makes a system call, instead of going directly to the host kernel, it is intercepted by gVisor, and Sentry handles most Linux system calls, memory management, file system, network stack, process management, and signal handling in user space. gVisor’s runsc implements the OCI runtime specification, so it can integrate with Docker and Kubernetes workflows.

The advantages of this model are:

  • No need to start a full guest kernel for each workload;
  • Generally lighter for short-lived tasks;
  • Easier to deploy in environments where nested virtualization is not available;
  • For CPU-bound tasks with infrequent system calls, runtime overhead is typically small;
  • Reduces the host kernel attack surface more than ordinary containers, since workload system calls are not passed through to the host directly.

The trade-offs appear mainly in compatibility and I/O paths. gVisor must re-implement the Linux system interface, so not all syscalls, /proc, or /sys behaviors are fully consistent. The official documentation explicitly notes that file I/O is typically the most affected performance item, and network performance is typically the second concern, since gVisor defaults to its own user-space network stack and prioritizes security over maximum throughput.

gVisor is therefore well suited for scenarios where you need stronger isolation than containers but don’t necessarily require a separate guest kernel per task; you value startup speed, resource density, Kubernetes integration, and lower operational friction; and your workload’s syscall compatibility and I/O performance have already been tested.

Modal is a typical user of this approach. Modal’s documentation states that Sandboxes are built on gVisor. At the same time, Modal has begun offering VM Sandboxes in beta, allowing sandboxes to run on a full VM with a real Linux kernel. This change also reflects a practical reality: gVisor and microVMs are not competing to replace each other — platforms combine them based on workload compatibility, isolation strength, and performance requirements.

The Policy Layer Approach: Constrain What the Agent Can Do Without Replacing the Kernel

The fourth category does not rush to replace a kernel layer. Instead, it focuses on capability control, using native OS mechanisms and proxy layers to constrain agents:

  • Landlock for declarative restrictions on file system access;
  • seccomp to limit which system calls a process can make;
  • AppArmor/SELinux for mandatory access control;
  • OPA or custom network proxies for domain name, IP, HTTP method, and request path policies;
  • Shell wrappers, tool wrappers, MCP proxies, or agent harnesses to control command execution, credential flow, and reasoning routing.

The advantage of this approach is low deployment friction. You can wrap it around existing CLI agents like Claude Code, Codex, Copilot, and OpenCode without rebuilding the entire execution environment. It is very appealing for local development machines, single-user workflows, internal tools, and low-concurrency agent scenarios.

But its boundaries must also be understood clearly: a policy layer is not a virtualization boundary. Its effectiveness depends on coverage. If even one exit point — file access, network access, shell, editor, browser, MCP tools, subprocesses, or container sockets — is not included in the policy, the agent may find a way around it.

The policy layer is therefore better described as “behavioral guardrails” and a “least-privilege framework.” It can significantly reduce the risk of accidental operations and data leaks, and it can be layered on top of containers, gVisor, or microVMs. But if you’re facing actively adversarial multi-tenant untrusted code, it should not be your only isolation layer.

The Platform Approach: Delegating Underlying Isolation to Managed Sandboxes

The fifth category is managed sandbox services. Instead of building Firecracker, Kata, gVisor, network isolation, snapshots, logging, image caching, and scheduling systems yourself, you create sandboxes directly through an API or SDK.

Several representative products exist:

  • E2B targets AI agent applications, with an underlying emphasis on Firecracker microVMs. Its official description states that each sandbox can run for up to 24 hours and provides an SDK, file system, terminal, browser, templates, and BYOC/self-hosting capabilities. It suits teams building agent applications who want to quickly get an execution environment that feels like “a temporary cloud computer.”
  • Modal excels at Python, batch processing, serverless compute, GPU workloads, and autoscaling. Its Sandboxes default to gVisor and support timeouts up to 24 hours; VM Sandboxes in beta can give workloads a real Linux kernel. It suits teams already operating in the Modal ecosystem for compute tasks, or whose agent tasks are tightly coupled with Python, data, or model inference.
  • Daytona emphasizes composable computers for AI agents. Its official documentation describes dedicated kernels, file systems, network stacks, vCPUs, RAM, and disk, with startup times under 90ms and OCI/Docker compatibility. Note that the underlying isolation details vary by deployment configuration and should be verified against official documentation — it should not be casually dismissed as “just a Docker container.”
  • Northflank leans toward a more platform-oriented, multi-runtime approach. Its published materials describe using Kata Containers + Cloud Hypervisor as the primary microVM isolation mechanism, gVisor in appropriate scenarios, and Firecracker where a minimal device model is needed. It suits teams wanting Kubernetes/OCI workflows without maintaining Kata, VMM, RuntimeClass, networking, and scheduling details themselves.

The benefit of managed platforms is speed; the downside is accepting platform boundaries: session duration, network policies, data residency, auditing, BYOC, GPU support, cold start times, image caching, cost models, and vendor lock-in all become part of the selection decision.

From Shell to Browser and Desktop

Expanding the scope of what an agent operates on reveals another dimension of classification.

The first type is browser sandboxes. Platforms like Browserbase provide cloud-based browsers that agents control through Playwright, Puppeteer, Selenium, CDP, or higher-level browser agent frameworks to open pages, click buttons, fill forms, and extract data. This suits pure web tasks: searching, form submission, booking, scraping, logging into backends, and handling SaaS pages with no API. It is not a full OS desktop, but it is not completely invisible either — Browserbase offers a Live View that lets humans watch the browser session in real time and click, type, scroll, or take over when needed.

The second type is desktop sandboxes. Solutions like E2B Desktop provide Ubuntu, XFCE, VNC/noVNC, screenshots, and mouse and keyboard control. The agent no longer just operates on the DOM — it sees the screen, clicks the mouse, and types, just like a human. This suits real GUI workflows involving Office suites, IDEs, image editing tools, file managers, and browser downloads/uploads. The E2B Desktop template is an example: Ubuntu 22.04 + XFCE + VNC, preloaded with LibreOffice, a text editor, a file manager, and desktop automation tools like xdotool and scrot.

The third type is all-in-one agent runtimes. Projects like AIO Sandbox and Agent-Sandbox attempt to combine shell, file system, browser CDP, VNC, VSCode Server, Jupyter, and MCP tools into a single environment. They solve the problem of “passing files between multiple single-purpose sandboxes”: instead of shuttling intermediate artifacts between a code sandbox, a browser sandbox, and a desktop sandbox, the agent completes its task in a single controlled workspace.

But this approach also raises the bar. The more capabilities exist in one environment, the more complex the permission combinations become. Untrusted web content seen by the browser may manipulate the agent into making shell calls; files generated by the shell may be opened by desktop applications; credentials stored from a desktop login session may be indirectly leveraged by a web task. For this reason, browser and desktop sandboxes must treat network egress filtering, credential isolation, human confirmation, operation logging, and session replay as default capabilities — not optional enhancements.

A very instructive security lesson applies here. Shortly after Anthropic released Claude Computer Use in public beta, security researcher Johann Rehberger demonstrated the “ZombAIs” attack: while Claude was browsing a page containing hidden prompt injection, it was manipulated into downloading a binary, executing chmod +x, running it, and connecting to the attacker’s C2 server. This example shows that the risk with browser/desktop agents is not only “the agent generated malicious code” — it also includes “external content manipulates the agent into using permissions it already has.”

For browser and desktop sandboxes, therefore, microVM/VM isolation only solves part of the host isolation problem. To reach production readiness, you must also layer in network egress allowlists/denylists, credential isolation, download file quarantine, human confirmation for high-risk actions, audit logs, and session replay. Platforms like E2B already offer domain- and CIDR-based egress controls; Anthropic’s Computer Use documentation explicitly advises developers to isolate sensitive data and actions and limit prompt injection risks.

A More Grounded Framework for Making Decisions

Placing these approaches on a spectrum, you can first reason about isolation boundaries:

  • Hardened containers: closest to existing engineering systems, suitable for trusted first-party code and internally controlled workloads;
  • Policy layers: easiest to wrap around existing agent CLIs, suitable for local development and low-cost permission governance;
  • gVisor: a middle ground between the container ecosystem and stronger isolation, suitable for workloads where syscall compatibility is manageable, and where startup speed and resource density matter;
  • MicroVMs: the clearest boundary, suitable for untrusted code, multi-tenant scenarios, third-party scripts, and high-risk agent execution;
  • Managed platforms: hand off underlying complexity, suitable for quickly building agent products or teams that don’t want to build sandbox infrastructure themselves.

You should also select based on what the agent needs to operate on:

  • Only running commands and code: a code sandbox is sufficient to frame the problem; focus on containers, gVisor, microVMs, and network egress control.
  • Needs to browse web pages, log into backends, fill forms, and scrape: a browser sandbox is more direct; focus on Playwright/CDP, session persistence, proxying, CAPTCHAs, human takeover, and replay.
  • Needs to operate real desktop applications: a desktop sandbox is more appropriate; focus on VNC/noVNC, screenshot quality, mouse/keyboard control, file upload/download, and human takeover.
  • Needs a mixed pipeline of code, browser, files, and desktop: an all-in-one agent runtime is more natural; focus on shared file systems, tool permission boundaries, auditing, and environment recycling.
  • Your own trusted services, internally controlled CI: prioritize hardened containers.
  • Forked PRs, third-party scripts, LLM-generated code, multi-tenant execution: prioritize microVMs or gVisor.
  • Making existing CLI agents like Claude Code, Codex, or Copilot run more safely on a local machine: a policy layer or ready-made packaging like Docker Sandboxes is more direct.
  • Running agent tasks in the cloud with long duration, concurrency, and auditability: look at managed platforms like E2B, Modal, Daytona, Northflank, and Browserbase.
  • Workload heavily depends on Docker daemon, package managers, kernel features, or low-level syscalls: microVMs are often simpler.
  • Workload consists of short tasks, is CPU-bound, and has conventional Linux syscall dependencies: gVisor is often lighter.
  • The team lacks the capacity to maintain KVM, VMM, guest kernels, network isolation, and image caching: do not casually attempt to build a microVM platform in-house.

This field has no single winner. gVisor hasn’t won. MicroVMs haven’t won. They answer different questions. MicroVMs are defined by “hardware virtualization boundary” and “strongly untrusted workloads.” gVisor is defined by “user-space kernel,” “lighter container ecosystem integration,” and “reducing host kernel exposure.” Browser and desktop sandboxes are defined by “letting agents operate real application interfaces.” Policy layers are defined by “constraining agent behavior.” Managed platforms are defined by “build less infrastructure, ship products faster.”

Real selection decisions should not begin with technology names — they should begin with the threat model:

Are you trying to prevent an agent from accidentally deleting local files, or are you trying to prevent a malicious tenant from escaping to the host machine? Are you running your own code, or code submitted by users? Do you need a Docker daemon? Do you need browser login sessions? Do you need real desktop applications? Do you need a GPU? Do you need sub-100ms startup, or can you tolerate a few seconds? Do you need a single development machine, or tens of thousands of concurrent sandboxes per day? Is network egress fully open, default-deny, or on a per-domain allowlist?

The answers to these questions matter more than “which is more advanced — containers, gVisor, or Firecracker?”

References