# Sandboxing AI-Generated Code: E2B vs Modal vs Daytona vs Vercel Sandbox

> Where should agent-written code run? The four sandbox platforms compared — isolation models, persistence, economics — plus the design rules that keep execution safe.

Agent-written code needs somewhere safe to run, and four platforms own the category: E2B (the code-interpreter specialist with open Apache-2.0 infra and desktop VMs), Daytona (sub-90ms startup, multi-OS, AGPL self-host), Modal (sandboxes inside a full serverless GPU platform), and Vercel Sandbox (Firecracker microVMs native to the Vercel ecosystem).

The moment agents could write code, the question became *where it runs* — because generated code is **untrusted input that executes**. The answer that won: give every agent a disposable computer. Four platforms industrialized that answer, and they're more alike on safety than their marketing suggests — which moves the real decision elsewhere.

## The short list

| Platform | Pick it for | Posture |
| --- | --- | --- |
| [E2B](/tools/e2b) | Agent-native code interpreters, desktop VMs | The specialist (Apache-2.0 infra) |
| [Daytona](/tools/daytona) | Sub-90ms starts, Windows/Android, self-host | The speed & breadth play (AGPL) |
| [Modal](/tools/modal) | Sandboxes + serverless GPUs in one platform | The compute platform |
| [Vercel Sandbox](/tools/vercel-sandbox) | Vercel-ecosystem products | The native integration |

## What actually differs

**Isolation: table stakes.** Firecracker microVMs (E2B, Vercel) or equivalent kernel-level isolation (Daytona's dedicated kernels, Modal's secure containers) — own filesystem, own network, no path to your environment. Nobody competitive ships less; stop comparing here.

**Ergonomics and ecosystem: the real fight.** [E2B](/tools/e2b)'s SDKs speak agent natively (`run_code` with rich outputs, charts included) and its production infra is open source — plus Desktop Sandboxes for [computer-use](/glossary/computer-use) agents. [Daytona](/tools/daytona) leads on spin-up latency (sub-90ms claimed) and is alone on Windows/Android sandboxes. [Modal](/tools/modal)'s sandboxes live inside a serverless platform — one vendor for execution *and* GPU inference and batch. [Vercel Sandbox](/tools/vercel-sandbox) inherits your Vercel project's auth, billing, and idioms — if v0 and the AI SDK are your stack, it's *right there*.

**Persistence: the sleeper.** All four now do stateful sandboxes — E2B's pause/resume, Daytona's snapshots and volumes, Vercel's persistent-by-default snapshots, Modal's reattach-by-ID — which upgrades the category from "run this snippet" to **long-running agent workspaces** that survive between sessions.

**Economics: shapes, not prices.** Per-second metering everywhere, with different free tiers (E2B and Daytona credits, Vercel's monthly Hobby allotment, Modal's monthly plan credits) and different self-host outs (E2B Apache-2.0, Daytona AGPL). Idle-but-running sandboxes bill on most meters — lifecycle hygiene is a cost control.

## The rules that keep it safe

A sandbox contains the blast; configuration decides the radius. (1) **Egress is policy** — default-deny or allowlist network from the sandbox; exfiltration is the attack that isolation alone doesn't stop. (2) **No ambient secrets** — inject the single scoped credential a task needs, never your env. (3) **Budget everything** — timeouts, CPU/memory caps, and step limits turn runaway generation into a bounded bill. (4) **Treat outputs as untrusted too** — results feed back into the model; [injection](/glossary/prompt-injection) can ride return values. (5) **Log execution** — what ran, what it touched: your audit trail when something weird happens. This is [guardrails](/glossary/guardrails) discipline applied to the execution layer — and item one on the [agentic security checklist](/guides/ai-safety/owasp-agentic-top-10).

---

_Source: https://agentscamp.com/guides/advanced/sandboxing-ai-generated-code — Guide on AgentsCamp._