Concepts / runtime
Sandboxes changing
Code execution sandboxes for agents · E2B, Daytona, Modal, Cloudflare, Vercel, and others
- Type
- practice · vendor landscape
- Published
- Reviewed
What it is
An agent that writes code will run code, and code the model wrote is untrusted. A sandbox gives it a place to do that without reaching your production systems. Every serious agent runtime has one, either built in (Managed Agents, Claude Code) or supplied by a provider.
How to choose
The dimensions that matter:
- Isolation: microVMs (Firecracker, used by E2B and Modal) give hardware-level separation. Containers (Daytona’s default, Cloudflare Sandboxes, Vercel Sandbox) share the host kernel and are lighter but weaker against a hostile workload.
- Cold start: from tens of milliseconds to seconds. Matters when every tool call spins up a box.
- Persistence: does the filesystem survive between sessions? Daytona leans persistent. Cloudflare starts fresh and expects state to live elsewhere.
- Network policy: can you restrict egress? This is your main defense against data exfiltration after a prompt injection.
- Pricing model: per-second compute versus a platform fee. GPU availability if you need it.
When to use it
Any time the agent executes something. The only question is which one, and the answer usually follows your existing cloud.
Watch out for
- “Sandboxed” is not a security guarantee. Check the isolation type before running someone else’s code.
- Long-lived sandboxes accumulate secrets. Rotate or recreate them.
Related
- Managed Agents Claude Managed Agents
- Prompt injection & guardrails Prompt injection and agent guardrails
- Human-in-the-loop Human-in-the-loop approvals