How Every Major Tech Company Is Sandboxing AI Agents Differently

The sandbox wars are here. Every company building AI agents that execute code has to answer the same question: where does that code run? The answer matters because a single prompt injection can turn your agent into an attacker with access to your database credentials, your API keys, and your production infrastructure.

Over the past few months I have been studying sandbox architectures across the industry, from raw Linux kernel primitives up through containers, microVMs, unikernels, and V8 isolates. What I have found is that there is no consensus. Every major player is making a different architectural bet, each optimized for their specific use case, and each with tradeoffs that the marketing pages do not always make obvious.

This is a breakdown of how the industry is actually sandboxing AI agents in production, organized by isolation technology, who is using what, why they chose it, and where each approach breaks down.

The Fundamental Problem

When an AI agent can write and run code at runtime, it can do anything the execution environment allows. Read files. Open network connections. Install packages. Access environment variables. If that execution environment is your backend server, the agent has your secrets.

Every sandbox architecture is an answer to the same question: how do you give an agent the ability to execute code while preventing it from accessing anything it should not? The approaches differ on four axes: isolation strength (how hard is it to escape), startup speed (how fast can you spin one up), resource cost (how much memory and CPU per sandbox), and flexibility (what languages and tools can run inside).

No architecture wins on all four. That is why the landscape is fragmenting.

MicroVMs: Hardware Isolation Without the VM Overhead

Who uses this: E2B (Firecracker), Fly.io Sprites (Firecracker), AWS Lambda (Firecracker), Vercel Sandboxes (Firecracker)

MicroVMs are stripped-down virtual machines that boot a minimal guest kernel with only the devices and drivers needed for a specific workload. The key innovation is the Virtual Machine Monitor (VMM). Instead of emulating a full PC like QEMU does (over 1.4 million lines of C), microVM monitors like Firecracker emulate only a handful of devices and nothing else. Firecracker’s VMM is about 50,000 lines of Rust.

The isolation is hardware-enforced. Each sandbox gets its own kernel, its own filesystem, its own network stack. A vulnerability in one sandbox’s kernel cannot affect another sandbox or the host because there is no shared kernel. Container escape techniques that exploit kernel vulnerabilities are irrelevant here.

E2B built their entire platform around this. Every code execution gets its own Firecracker microVM. Cold starts hit around 150 milliseconds. They went from 40,000 sandboxes per month in early 2024 to over 15 million per month by early 2025, and about half the Fortune 500 uses them. The tradeoffs: sessions cap at 24 hours, there are no granular egress controls for restricting outbound network access, and scaling past a few hundred concurrent sandboxes means operating their control plane yourself.

Fly.io Sprites use the same Firecracker foundation but with a fundamentally different philosophy. CEO Kurt Mackey’s argument: “Ephemeral sandboxes are obsolete. Claude doesn’t want a stateless container. Claude wants a computer.” Sprites persist. Each one gets a 100GB NVMe filesystem that survives between sessions. They idle when inactive (billing stops), but the data stays. The killer feature is checkpoint and restore, you can snapshot the entire disk state in about 300 milliseconds and roll back if the agent breaks something. Creation takes 1 to 12 seconds. A four-hour Claude Code session costs about $0.44.

The tradeoff between E2B and Sprites captures a core tension in the space: ephemeral vs. stateful. E2B assumes agents should start fresh every time, which is the cleanest security model because nothing persists and nothing can accumulate. Sprites assume agents need continuity, which is more practical for coding workflows but means you inherit the complexity of managing long-lived state.

Security strengths: Strongest isolation available short of a full VM. Each sandbox has a dedicated kernel. The VMM attack surface is minimal (Firecracker is ~50K lines of Rust vs. QEMU’s 1.4M lines of C).

Security gaps: MicroVMs protect against kernel-level exploits, but they do not solve the credential exposure problem on their own. If your agent needs API tokens to do its work, those tokens are inside the VM. A compromised agent can still exfiltrate them if outbound network access is not locked down. E2B does not offer granular egress policies. Sprites run on isolated networks where nothing can connect directly, but the agent still has outbound access.

Containers and gVisor: The Pragmatic Middle Ground

Who uses this: Daytona (Docker containers), Modal (gVisor), Google Agent Sandbox (gVisor on GKE)

Standard containers (Docker, containerd) share the host’s Linux kernel and use namespaces, cgroups, and seccomp to create the illusion of isolation. They boot in 1 to 5 seconds, use relatively little memory, and have a massive ecosystem. The risk is the shared kernel. A kernel vulnerability can break out of any container on the host. Docker’s default seccomp profile blocks about 44 of the 300+ available syscalls, but the attack surface is still much larger than a hypervisor.

Daytona went all-in on containers for speed. They pivoted from development environments to AI agent infrastructure in early 2025 and now claim sub-90 millisecond cold starts, the fastest sandbox creation in the market. They use Docker containers by default, with optional Kata Containers for enhanced isolation. In February 2026 they raised a $24M Series A to expand the platform.

The tradeoff is direct: Docker containers share the host kernel. For trusted code from your own pipelines, this is fine. For truly untrusted AI-generated code from unknown users, the isolation is weaker than microVMs. A kernel exploit inside one container can compromise every other container on that host.

Modal took a different path with gVisor, Google’s user-space kernel. gVisor intercepts system calls from the sandboxed process and handles them in a user-space kernel written in Go, so the sandboxed code never talks to the real host kernel directly. This is stronger than standard containers but not as strong as a dedicated VM kernel. Think of it as a middle layer: the syscall interception reduces the host kernel attack surface dramatically, but the isolation boundary is software-enforced rather than hardware-enforced.

Modal is optimized for the Python ML ecosystem. Sandboxes run on gVisor, environments are defined dynamically in code at runtime (no pre-built templates), and the platform spans inference, training, batch processing, and sandboxes under one roof. They can scale to very high concurrency.

Google’s Agent Sandbox on GKE also uses gVisor, which makes sense given that Google developed it. It is an open-source project that deploys as a controller on your Kubernetes cluster, providing process, storage, and network isolation for AI-generated code.

Security strengths: gVisor eliminates the shared-kernel risk of standard containers by reimplementing the kernel in user-space. A vulnerability in the real Linux kernel cannot be exploited from inside a gVisor sandbox because the sandboxed process never talks to it. Container-based approaches (including gVisor) are faster and lighter than microVMs.

Security gaps: gVisor’s isolation is software-enforced. A bug in gVisor itself (the user-space kernel implementation) could be exploitable. Standard Docker containers without gVisor are insufficient for untrusted code. Modal only offers gVisor, no microVM option for teams that need hardware-level isolation. Daytona’s default Docker isolation is the weakest of any major sandbox provider for untrusted workloads.

Unikernels: Browser Use and the Control Plane Pattern

Who uses this: Browser Use (Unikraft micro-VMs)

Browser Use took the most architecturally distinct approach in the space. Instead of isolating just the code execution, they moved their entire agent loop into a Unikraft micro-VM. The agent itself runs in a sandbox with zero secrets. It talks to the outside world exclusively through a control plane that holds all the credentials.

A unikernel compiles the application and only the OS library components it needs into a single bootable image. There is no general-purpose kernel. No shell. No SSH daemon. No package manager. The application IS the kernel. The attack surface is extremely small because there is nothing in the image except what the application needs.

The sandbox receives only three environment variables: a session token, the control plane URL, and a session ID. No AWS keys, no database credentials, no API tokens. After the agent reads these into Python variables, they are deleted from os.environ. If the agent inspects the environment, those variables are gone. The token is useless outside the sandbox’s network because the VM sits in a private VPC with no permissions other than talking to the control plane.

Every external operation routes through the control plane. Need to call an LLM? The sandbox sends only the new messages. The control plane reconstructs the full conversation from its database and forwards the complete context to the provider. Need to upload a file to S3? The sandbox asks the control plane for presigned URLs, uploads directly to S3, and never holds an AWS credential.

This is what Browser Use calls “Pattern 2: Isolate the Agent.” Pattern 1 (isolate the tool) keeps the agent on your infrastructure and sandboxes only the dangerous operations. Pattern 2 puts the entire agent in a sandbox and mediates everything through the control plane. The agent becomes disposable. No secrets to steal, no state to preserve.

Unikraft gives them scale-to-zero out of the box. When a sandbox is idle, the VM suspends. When the next request comes in, it resumes. They distribute sandboxes across multiple metros to prevent single-metro bottlenecks.

Security strengths: The cleanest security model of any approach I have studied. The agent literally has nothing worth stealing. The control plane pattern means credentials never enter the sandbox. Unikernels have the smallest possible attack surface because the image contains only what the application needs.

Security gaps: Complexity. You are running three services instead of one: the sandbox, the control plane, and the backend that coordinates them. Every operation has an extra network hop. Unikernel ecosystems are small and fragmented. Debugging is harder because there is no shell to SSH into. If the control plane goes down, every sandbox is dead.

V8 Isolates: Cloudflare Dynamic Workers

Who uses this: Cloudflare Dynamic Workers, Cloudflare Workers (general), Deno Deploy, Shopify Oxygen

Cloudflare announced Dynamic Workers today. V8 isolates are a fundamentally different approach to sandboxing. Instead of running a full operating system (VM or container), an isolate is a lightweight execution context inside the V8 JavaScript engine. Each isolate gets its own heap, its own global scope, and its own compiled code. But multiple isolates share a process, the same V8 engine instance, and the same native code for built-in APIs.

The numbers are dramatic: a few milliseconds to start versus hundreds for a container or microVM. A few megabytes of memory versus hundreds. Cloudflare claims 100x faster and 10–100x more memory efficient than containers. There are no concurrency limits and no creation rate limits. You could handle a million requests per second where every single request loads a separate sandbox.

Because isolates are so lightweight, Cloudflare can spin up a fresh one for every single request, run one snippet of code, then throw it away. No warm pools. No reuse. That is the ideal security model for short-lived executions.

Dynamic Workers also introduce a capability-based security model. Your main Worker loads a Dynamic Worker with AI-generated code, passes in only the specific API bindings the agent should have access to, and can block all outbound network access. The agent code calls your APIs through typed RPC bridges and never touches your credentials. Cloudflare also supports HTTP filtering for credential injection: when the agent makes an outbound request, your Worker can intercept it and attach auth headers, so the agent never sees the actual tokens.

Cloudflare is pushing the idea that agents should write code against typed TypeScript APIs rather than making sequential tool calls through MCP or OpenAPI. Their side-by-side comparison shows a TypeScript interface using far fewer tokens than the equivalent OpenAPI spec. The agent writes a single function that chains multiple API calls, runs it in an isolate, and returns the result. Only the output, not every intermediate step, ends up in the context window.

Security strengths: Near-zero cost per sandbox means you never reuse sandboxes, which eliminates cross-task contamination. Capability-based security model is clean: the agent only has access to the specific bindings you pass in. No filesystem, no environment variables, no shell. Cloudflare has nearly a decade of experience hardening their isolate platform, including custom second-layer sandboxes, hardware memory protection keys (Intel MPK), dynamic cordoning based on risk assessment, and V8 security patches deployed to production within hours.

Security gaps: V8 isolates are a more complex attack surface than hardware VMs. V8 bugs are more common than hypervisor bugs, though Cloudflare’s defense-in-depth layers mitigate this significantly. The biggest limitation is language: JavaScript, TypeScript, and WebAssembly only. No Python. No shell commands. No filesystem. If your agent needs to install numpy or compile Rust, you need a container or VM. Cloudflare’s counterargument is that the code is being written by AI, not humans, and LLMs are fluent in JavaScript. That is true, but it limits what the agent can actually do inside the sandbox.

OS-Level Primitives: Anthropic’s Sandbox Runtime

Who uses this: Anthropic Claude Code (bubblewrap on Linux, Seatbelt on macOS)

Anthropic took a fundamentally different approach with Claude Code. Instead of running the agent in a remote sandbox service, they built OS-level sandboxing directly into the CLI tool. On Linux, it uses bubblewrap (the same tool Flatpak uses for desktop app sandboxing). On macOS, it uses Apple’s Seatbelt framework. Both enforce filesystem and network isolation at the operating system level.

The architecture works differently than the cloud sandbox providers. Claude Code runs on your machine, in your terminal, with your filesystem. The sandbox restricts what bash commands and their child processes can access. Filesystem isolation ensures Claude can only read and write to specific directories. Network isolation routes all traffic through proxy servers on the host and blocks everything not on the allowlist. On Linux, the network namespace is removed entirely, so all traffic must go through the proxies listening on Unix sockets bind-mounted into the sandbox. Seccomp BPF filters block Unix domain socket creation at the syscall level.

Anthropic says this reduces permission prompts by 84%. Instead of approving every bash command, you define sandbox rules upfront and Claude works freely within those boundaries.

For Claude Code on the web, the architecture is different. Each session runs in an isolated cloud sandbox where Claude has full access to its environment. Credentials like git tokens and signing keys are never inside the sandbox. Git interactions route through a custom proxy that validates authentication, branch names, and repository destinations before attaching the real tokens.

Anthropic open-sourced the sandbox runtime as an npm package for other agent builders to use.

Security strengths: No cloud dependency. Works on your local machine. Uses battle-tested OS primitives (bubblewrap has been securing Flatpak apps for years, Seatbelt secures every iOS app). The dual filesystem + network isolation model is well-designed: you need both or neither is effective. Open-sourced for the community.

Security gaps: On macOS, Apple patches sandbox bypasses regularly, and Anthropic warns not to treat any isolation layer as unbreakable. The sandbox isolates bash subprocesses, but Claude Code itself runs with your user permissions. Read restrictions matter as much as write restrictions: an agent that can read ~/.ssh and reach the network can exfiltrate your keys. The Linux implementation has an enableWeakerNestedSandbox mode for Docker environments that significantly reduces security. And fundamentally, this is process-level isolation, not VM-level. A kernel exploit could escape it.

The Tradeoffs Nobody Talks About

Across all of these approaches, there are tensions that keep showing up. The marketing pages highlight the strengths. These are the parts they leave out.

Ephemeral vs. stateful is a philosophical divide, not just a technical one. E2B and Cloudflare bet on ephemeral: create a sandbox, run code, destroy it. Nothing persists, nothing leaks, cleanest security model. Fly.io Sprites bet on stateful: agents need continuity, installing packages every session is wasteful, persistent environments are more practical. Both are right for different workloads. But the security implications run deeper than most people realize. A stateful sandbox that has been running for weeks accumulates state that an attacker could leverage: cached credentials, installed packages with known vulnerabilities, log files with sensitive data, dependency drift that introduces supply chain risk. An ephemeral sandbox that destroys itself after every execution eliminates all of that by default. The counterargument from the stateful camp is equally valid though. If your agent has to rebuild its entire environment every time it starts, you are burning compute, burning time, and burning money on work that does not produce value. For coding agents working on real codebases, installing node_modules from scratch every session is not just slow, it is architecturally wasteful.

Isolation strength is not binary, it is a spectrum with real gaps at every level. Standard Docker containers share the host kernel, so a kernel vulnerability in one container can escape to the host and compromise every other container on the machine. gVisor intercepts syscalls in user-space, which dramatically reduces the host kernel attack surface, but a bug in gVisor itself (the user-space kernel implementation) becomes the new escape vector. MicroVMs provide hardware-level isolation with dedicated kernels, but they do not solve the credential exposure problem. If the agent needs API tokens to function, those tokens are inside the VM. A compromised agent can still exfiltrate them if outbound network access is not locked down. V8 isolates are software-isolated with no filesystem or shell, which is a tight sandbox, but V8 bugs are more common than hypervisor bugs because the V8 engine is a far more complex codebase. Cloudflare mitigates this with layers of defense-in-depth (hardware memory protection keys, dynamic cordoning, custom second-layer sandboxes), but the underlying attack surface is still larger than a simple hypervisor. Even Anthropic’s OS-level sandboxing in Claude Code has a known limitation: on macOS, Apple patches Seatbelt bypasses regularly, and the Linux bubblewrap implementation has a weaker mode for Docker environments that significantly reduces isolation.

Read access is as dangerous as write access, but most sandboxes focus on writes. The conversation around sandboxing tends to center on preventing the agent from modifying things it should not: deleting files, overwriting configs, installing backdoors. But reading is just as dangerous. An agent that can read ~/.ssh/id_rsa and has outbound network access can exfiltrate your SSH keys. An agent that can read .env files can steal API tokens. An agent that can read /proc on a Linux host can discover information about other processes. Effective sandboxing requires restricting read access to sensitive directories as aggressively as write access. Anthropic’s Claude Code sandboxing explicitly calls this out in their documentation. Browser Use solves it entirely by never putting credentials in the sandbox in the first place. But most container-based approaches mount more of the host filesystem than they need to, and bind mounts are the primary attack vector in practice.

Egress control is the missing feature across almost the entire market. Even if your sandbox has perfect filesystem isolation, a compromised agent can still phone home if it has unrestricted outbound network access. It can send your data to an external server. It can download additional payloads. It can establish reverse shells. Surprisingly few sandbox providers offer granular egress controls. E2B has no outbound filtering at all. Daytona does not offer network policies by default. Modal provides tunneling and some egress controls but they are not the default. Cloudflare Dynamic Workers handle this well because you can set globalOutbound to null and block all outbound, or intercept every HTTP request and decide whether to allow it. Browser Use solves it architecturally because the sandbox sits in a private VPC that can only talk to the control plane. But for the majority of the market, a compromised sandbox with internet access is a compromised sandbox that can exfiltrate your data.

Isolate the tool vs. isolate the agent is not just a security decision, it is an operational one. Most providers (E2B, Modal, Cloudflare, Daytona, Anthropic) implement Pattern 1: the agent runs on your infrastructure, only the dangerous code execution runs in a sandbox. Browser Use is the only major provider implementing Pattern 2: the entire agent runs in a sandbox with zero secrets, and everything goes through a control plane. Pattern 2 is the stronger security model because the agent never has credentials to steal. But Pattern 2 means running three services instead of one. It means every LLM call, every file upload, every API interaction routes through the control plane. It means if the control plane goes down, every sandbox is dead. For teams with strong DevOps practices, this is manageable. For a startup shipping fast, Pattern 1 with a well-configured sandbox is the pragmatic choice.

The cost model matters more than people admit. E2B charges per sandbox-second. Fly.io Sprites charge per CPU-hour and memory-hour with zero cost when idle. Cloudflare charges $0.002 per unique Dynamic Worker loaded per day (waived during beta) plus standard CPU and invocation pricing. Modal charges separately for CPU, GPU, and RAM. These pricing models incentivize very different architectural patterns. Per-second billing incentivizes short, fast executions. Per-CPU-hour with idle savings incentivizes persistent environments that sleep between uses. Per-invocation pricing incentivizes batching work into fewer, larger sandbox sessions. When you are running millions of agent executions per month, the difference between these models can be tens of thousands of dollars. And the pricing model you optimize for shapes the security model you end up with, because cost pressure pushes teams to reuse sandboxes, extend session limits, and skip the clean ephemeral approach in favor of warm pools.