Sandboxes for AI Agents: The Landscape, the Options, and How to Choose

The agent thinks; the sandbox executes. This piece breaks the 2026 sandbox market into four tracks—specialized hosted platforms, cloud-vendor offerings, local agent isolation, and open-source self-hosting—explains what really separates containers, gVisor, Kata, and microVMs, why hourly rates are not comparable across vendors, how well-known agent products actually build this layer, and ends with selection and security checklists you can use directly.

Conclusions First

1. A sandbox is not an agent framework; it is the agent's "execution computer." The agent handles thinking and decisions; the sandbox confines code, shell, files, processes, and network inside a controlled environment.
2. By 2026 the market has settled into four competing tracks:
   • Specialized hosted platforms: E2B, Daytona, Runloop, Blaxel, Fly.io Sprites, CodeSandbox SDK;
   • Cloud vendors and developer platforms: Modal, Vercel Sandbox, Cloudflare Sandbox SDK, AWS AgentCore, GKE/Cloud Run Sandboxes, Azure Dynamic Sessions, CoreWeave;
   • Local agent isolation: Docker Sandboxes, Anthropic Sandbox Runtime, plus the OS sandboxes shipped inside Codex, Claude Code, and DeepSeek Harness;
   • Open-source self-hosting: E2B, OpenSandbox, Tencent CubeSandbox, Kimi AgentENV, BoxLite, NVIDIA OpenShell, Kubernetes Agent Sandbox, Microsandbox, AIO Sandbox—composed with Firecracker (started and open-sourced by AWS), gVisor (started and open-sourced by Google), or Kata Containers (a community project hosted by the OpenInfra Foundation).
3. For a new team, E2B is the safest general-purpose starting point. If you need a long-lived "work computer," look first at Sprites, Blaxel, Daytona, and Runloop. Inside an existing cloud ecosystem, prefer that ecosystem's native offering. If you need GPUs, start with Modal, Northflank, or Daytona.
4. Do not treat an ordinary Docker container as a security sandbox. Containers share the host kernel. Facing public users or LLM-generated untrusted code, add at least gVisor (Google) or Kata Containers (OpenInfra Foundation community); for higher risk, use a microVM such as Firecracker (AWS), or a lightweight VM with Hyper-V (Microsoft) isolation.
5. You must separate agent harness from sandbox. Codex, Claude Code, Pi, and DeepSeek Harness are harnesses responsible for the loop, the context, and tool calls; E2B, Sprites, CubeSandbox, and the like are the execution isolation layer. One product can ship a lightweight local sandbox and also route tool execution to a remote microVM.
6. Real security is more than "no escapes": you also have to solve network exfiltration, secret leakage, and resource abuse. A microVM mainly addresses the first of the three.

1. Core Concepts and Isolation Mechanisms

A common architecture looks like this:

User request
   ↓
Agent Runtime (model calls, planning, tool selection, session state)
   ↓ Sandbox API
Control plane (create, pause, snapshot, destroy, quota, audit)
   ↓
Isolated execution environment (shell / files / processes / browser / desktop)
   ├─ Filesystem and snapshots
   ├─ Network egress policy
   ├─ Secret proxy / short-lived credentials
   └─ CPU, memory, disk, timeout limits
   ↓
Isolation substrate (container / gVisor / Kata / microVM)

A sandbox has to answer at least six questions:

• Isolation boundary: a process, a container, a user-space kernel, or an independent microVM kernel?
• State model: destroyed after one use, or able to pause, resume, snapshot, and fork?
• Network model: full internet access by default, or deny-by-default with per-domain/CIDR allowlisting?
• Secret model: do real keys ever enter the sandbox? Can a proxy inject them only as a request leaves the sandbox?
• Resource model: are CPU, memory, disk, process count, and maximum runtime bounded?
• Return model: does the agent deliver stdout, files, a patch, a Git branch, a web preview, or a full snapshot?

The point that gets confused most often: the harness decides "what to do," the sandbox constrains "what can be done and where"; containers, gVisor, Kata, and microVMs are the isolation substrates a sandbox can choose from.

1.1 What Actually Separates the Isolation Mechanisms

"Strength" here is only the usual architectural order of magnitude, not a security certification. A "strongly isolated" platform with a wide-open network, bare secrets, and no patching can easily be less secure overall than a carefully configured lightweight option.

Unfamiliar terms are defined in Appendix A.

2. The Current Landscape

2.1 Specialized Hosted and General-Purpose Platforms

2.2 Cloud Vendors and Developer Platforms

On adoption: at most three vendor- or customer-disclosed reference cases are listed per option; "—" only means there is not yet a sufficiently clear independent production disclosure. "Uses AgentCore" also does not necessarily mean using its Code Interpreter.

3. Why You Cannot Compare on "Per Hour" Alone

Vendors use at least four different billing models:

1. Billed on provisioned resources for as long as the sandbox is alive: E2B, Daytona, Runloop, CodeSandbox, Northflank, Railway. While the agent waits on the model or the network, you usually still pay for memory and CPU.
2. CPU billed on active usage only, memory on wall clock or peak: Vercel, Cloudflare, AWS AgentCore. Usually cheaper for I/O-heavy agents.
3. Billed on actual/active resources with automatic idle-to-zero: Sprites, Blaxel; suited to long-lived agents with a low duty cycle.
4. Billed on max(requested, actual) resources: Modal. Setting the request too high wastes money outright.

Hourly rates under different models cannot be ranked directly. For budgeting, use:

Total cost = base plan
           + creation/build charges
           + active CPU
           + wall-clock memory
           + hot/cold disk and snapshots
           + image storage
           + network egress and static IP/gateway
           + concurrency scaling charges
           + ancillary resources: logs, Durable Objects, object storage

4. Open-Source Self-Hosted Options

4.1 Self-Hosting Comparison

Open source and self-hostable can mean a complete multi-tenant platform or merely an embeddable single-machine runtime. The table below separates deployment shape, entry point, and complexity to make them comparable. "Deployment complexity" is a relative assessment based on prerequisites, component count, and production operational requirements—not an official rating from any project.

Whichever route you take, the gap between "I can start my first sandbox" and "this can carry untrusted production traffic" still has to be filled in: API authentication and TLS, deny-by-default egress, a secret broker, resource and concurrency quotas, image supply chain, audit logs, data/snapshot backup, version upgrades and rollback, plus real escape and exfiltration testing. A successful one-click install is not production readiness.

5. How Well-Known Agent Products Build This

This section applies the layered framework from part 1 to concrete products, focusing on harness, execution isolation, state, and public adoption.

5.1 Product Comparison

These products fall into three implementation routes:

1. Local harness + OS sandbox: Codex CLI, Claude Code, DeepSeek Harness. Fast to start and natural to use, but still sharing the host kernel—good for "protecting the developer's machine," not for strong multi-tenant hosting of strangers' code.
2. Hosted harness + a cloud environment per task: Codex Cloud, Claude Code Web, Manus, Notion Workers. The control plane owns the session, the execution plane is one container or microVM per task, and Git, network, and secrets are governed through a proxy.
3. Harness decoupled from sandbox: Pi + Sprites, Open SWE + Daytona, Devin Outposts, Managed Agents. The tool protocol is the seam, so the execution location can be swapped without rewriting the agent loop—the most common direction for enterprise-owned compute and BYOC.

6. Choosing by Scenario

Building a First Demo

• First choice: E2B Hobby. Simple API, plenty of documentation and integrations, and self-hostable later.
• If you care more about fast creation, long-lived workspaces, or Windows/GPU: Daytona—accepting that the production platform is now closed source.
• For a coding agent on your own machine: Docker Sandboxes first; the OS sandboxes shipped with Codex/Claude/DeepSeek are a lighter option, as long as you understand they are not microVMs.
• If you only ever run your own trusted scripts, local Docker is a fine start; do not point it at untrusted public code.

Data Analysis / Code Interpreter

• General purpose: E2B.
• AWS enterprises: AgentCore Code Interpreter.
• GPU, Jupyter, batch Python: Modal.
• Agent already inside Cloud Run: Cloud Run Sandboxes.
• Azure ecosystem: Dynamic Sessions; watch the one-hour minimum billing granularity.

Coding Agents / Devin-Style Products

• One-off tasks at high concurrency: E2B, Daytona, Vercel.
• Keeping an environment around to resume after PR comments: Sprites, Runloop, Blaxel, Daytona.
• Bringing your own benchmark/eval: Runloop.
• Also hosting APIs, databases, and GPUs: Northflank.

RL, Evaluation, and Large-Scale Fan-Out

• Hosted: E2B, Runloop, Modal; Modal/Northflank/Daytona when GPUs are needed.
• Self-hosted general platform: OpenSandbox, CubeSandbox, or Kubernetes Agent Sandbox + gVisor/Kata/Firecracker.
• Self-hosted for training specifically: Kimi AgentENV; CoreWeave customers can look straight at CoreWeave Sandboxes.
• The capability that matters is not how fast a single sandbox starts, but template caching, snapshot forking, concurrency quotas, bulk creation rate, failure reclamation, and observability.

Browser / Computer Use

Browser sandboxes are an adjacent but distinct submarket: beyond code isolation, they have to manage Chrome, cookies/profiles, Playwright/CDP, VNC/screenshots, and anti-bot problems. Look at E2B Desktop, Daytona Computer Use, Runloop Browser/Computer, AWS AgentCore Browser, and AIO Sandbox. If your agent only drives web pages, a dedicated browser platform such as Browserbase is usually a better fit than a general-purpose Linux sandbox.

Strict Compliance, VPC, or On-Prem

• Fast hosted/BYOC: E2B Enterprise, Northflank BYOC, Daytona Customer-Managed Compute.
• Genuine self-control: OpenSandbox, CubeSandbox, OpenShell, or Kubernetes Agent Sandbox with gVisor/Kata/Firecracker underneath; BoxLite for single-machine embedding.
• AWS/GCP/Azure-native teams should consider AgentCore, GKE Agent Sandbox, and Azure Dynamic Sessions first—one fewer IAM, audit, and network stack to maintain.

7. The Easiest Security Mistakes to Make

A sandbox has to cover at least three lines of defense simultaneously:

1. No escape: the agent must not read the host, kill host processes, or affect other tenants. This relies on microVM/gVisor/Kata, kernel patching, and layered isolation.
2. No exfiltration or privilege abuse: even without an escape, reachable data must not be sent to arbitrary domains. This relies on deny-by-default networking, domain/CIDR allowlists, private networking, a secret broker, and short-lived credentials.
3. No resource abuse: fork bombs, mining, unbounded downloads, filling the disk, and billing attacks. This relies on cgroup/VM quotas, process limits, disk quotas, timeouts, concurrency caps, and budget alerts.

A minimum pre-launch checklist:

• No internet by default; allow domains dynamically per task and forbid arbitrary outbound TCP/UDP.
• Never hand production API keys to the agent as environment variables; use proxy injection, short-lived tokens, or least-privilege accounts.
• One sandbox per user/task; never let multiple untrusted tenants share a writable filesystem.
• Set caps on CPU, RAM, disk, PIDs, file size, execution time, concurrency, and creation rate.
• Treat snapshots, templates, and uploaded files as untrusted input; enforce the same policy after a restore.
• Keep audit logs for commands, network, file changes, secret usage, and lifecycle events.
• Require authentication on port previews by default; share links should be short-lived, not public by default.
• Regularly test escapes, malicious package installs, DNS/HTTP exfiltration, fork bombs, filling the disk, and policy retention across pause/resume.

8. How to Run Your Own PoC Evaluation

Do not just compare vendor-claimed cold starts. Use your own workload, repeat each vendor at least 30 times, and record P50/P95:

1. Empty sandbox creation through the first command completing;
2. Creating from a custom template and installing dependencies;
3. Cloning a mid-sized repository, running tests, starting a dev server;
4. Pause/resume, snapshot/fork, failure retry;
5. Creation success rate and rate limiting at 100 and 1,000 concurrent;
6. The actual bill when the agent spends 90% of its time waiting on the model;
7. Whether the default network, secret injection, and port exposure are safe;
8. Idempotency when the API disconnects, the process keeps running, and the control plane retries;
9. Whether data residency, logging, deletion, and snapshot retention meet compliance requirements;
10. The same monthly workload with plan fees, storage, egress, concurrency, and ancillary services all included.

9. Final Recommendations

Absent existing constraints, narrow the field in this order:

1. Fix the trust level first: trusted internal code can use containers; untrusted user/LLM code needs gVisor/Kata/microVM; strong multi-tenancy should prefer microVMs.
2. Then the state model: ephemeral for second-scale tasks; pause/resume + snapshot/fork for coding and research agents; idle-to-zero + persistent disk for long-lived services.
3. Then the deployment model: SaaS first for small teams; cloud-native for teams that already run a cloud platform; BYOC/self-hosting once regulation, data residency, or cost scale justify it.
4. Compare prices last: use your real active-CPU ratio plus snapshot and network costs; never rank hourly rates that come from different billing models.

Notes on the Data

• All prices come from public vendor pages and may change by region, contract, resource type, and time; options without an independent public price are explicitly marked as preview or contact-sales rather than guessed at.
• "Startup speed" is as claimed by the vendor under inconsistent test conditions, and this article does not rank on it.
• The star snapshot is from 2026-09-01. Stars indicate attention only and do not equal security, activity, or production maturity. Daytona still has over 70,000 stars, but its production code has been closed source since June 2026; DeepSeek Harness's 200,000+ stars do not make its local process sandbox equivalent to a strongly isolated cloud platform.
• "Open source" is used strictly: a self-hostable full data plane and control plane is not the same thing as publishing only an SDK, CLI, or examples.

Appendix A: Core Terminology