AI Agent Sandboxes: What They Are and How to Choose One

An AI agent sandbox is a piece of isolated compute with a lifecycle attached to a conversation. That's the whole idea. Everything else — the SDKs, the snapshot APIs, the per-second billing — is machinery for making that sentence true cheaply.

I'm Ajay Kumar, an infrastructure engineer with 14 years in this. Disclosure up front: I built one of the platforms in this post — PandaStack, an Apache-2.0 Firecracker microVM sandbox platform, solo over about six months. I've tried to describe it the way I'd describe a competitor, and I'll tell you plainly where it loses. It loses in at least three places, and I name them below. Nothing here ranks PandaStack first, because for most of the situations at the end of this post it isn't the right answer.

What I do have is that I implemented every layer described here — the network allocation, the snapshot restore path, the scheduler, the egress rules, the billing meters. So when I say a property is hard, it's because I have the scar.

What a sandbox actually is at the systems level

Strip the marketing and a sandbox is four things bound together:

1. A guest execution context — a process tree with its own filesystem view. Depending on the vendor, that's a Linux namespace set, a gVisor Sentry, or a full guest kernel on KVM.
2. A boundary between that context and the host. This is the part people mean when they say "sandbox," and it's the part that varies most.
3. An addressable identity with a lifecycle you control over an API: create, exec, read a file, pause, fork, delete. A container you docker run on your own box is not a sandbox in this sense, because there's no control plane in front of it doing admission, scheduling, and cleanup.
4. A state policy — what survives when nobody's looking. This is where most production surprises live.

A container runtime gives you (1) and part of (2). A sandbox platform is mostly the cost of (3) and (4).

Why agents need one, specifically

Three properties of agent workloads make a sandbox non-optional, and they're not the ones people usually cite.

The code is generated, not reviewed. Not "possibly malicious" in the classic threat-model sense — the model isn't attacking you. It's that nobody has read this code, it was written for a goal rather than for your environment, and it will happily rm -rf a path it hallucinated, install a package whose postinstall script does something, or loop forever on a retry. Untrusted is the right posture even when the intent is benign.

Blast radius is your whole product. A single agent run that consumes host resources or reaches something it shouldn't doesn't fail one request — it takes out whatever else shares that boundary. If you're multi-tenant, that's other people's data.

Agents are stateful across turns, and this is the one that surprises teams. Turn 3 does pip install pandas. Turn 9 imports it. If the sandbox is a fresh container per tool call, turn 9 fails and the model gets a confusing error, retries, reinstalls, burns tokens, and eventually gives up in a way that looks like a model quality problem. It isn't. It's an infrastructure choice leaking into your eval scores. The whole snapshot/pause/resume industry exists because of this one behaviour.

Anatomy of a sandbox create

Here's what actually happens between the API call and code running, using my own path because it's the one I can give you honest per-stage numbers for. PandaStack does snapshot-restore on every create — there's no warm pool of idle VMs — and this is the measured p50 breakdown on my production fleet:

Stage	~ms
Allocate a pre-built network slot (netns + veth + tap)	1
Patch the tap device into the namespace	6
Reflink the rootfs (copy-on-write clone)	4
fork+exec the Firecracker process	25
POST /snapshot/load — map the memory image	80
Resume the vCPUs	6
Probe TCP until the guest answers	40
Insert the metadata row (async)	6

That's 179ms p50, 203ms p99, clock stopped when the guest actually answers on a socket. Two things in that table matter more than the total.

First, the network slot is pre-allocated. Doing ip netns add + ip link add + iptables rules cold costs about 100ms — more than half the budget. I keep a pool of pre-built slots so create only patches a MAC address. That's an implementation detail nobody advertises, and it's most of why the number is what it is (the full stage-by-stage teardown is here, and the networking internals are documented).

Second, the 80ms snapshot load is not a boot. Nothing runs init. A memory image is mapped MAP_PRIVATE and the guest resumes mid-life with page faults served lazily. A cold boot of the same template is ~3s on the same hardware. Every vendor's "cold start" number depends entirely on which of those two things they're doing and where they stop the clock, which is why the creation-time column in every comparison matrix spans three orders of magnitude. That spread is definitional, not performance.

The four properties that decide it

1. Isolation

The question is: what does one bug in the guest buy an attacker?

Shared-kernel containers mean one Linux kernel bug is a host compromise. gVisor puts a userspace kernel in the way, so the guest reaches the host through a deliberately narrow syscall surface — much better, at the cost of long-tail compatibility gaps you discover from user bug reports. microVMs give the tenant their own kernel on KVM; the attacker needs a VMM or KVM bug, not a Linux one.

Roughly where the market sits: E2B, Vercel Sandbox, Fly.io Machines, CodeSandbox/Together and Blaxel are microVM-based (Blaxel states Firecracker with a separate kernel per sandbox, though at least one third-party tracker lists the hypervisor as undisclosed). Modal documents its compute as "containerized and virtualized using gVisor." Google's Agent Sandbox on GKE defaults to gVisor with Kata as an option. Northflank lets you pick Kata or gVisor per workload. Cloudflare's Sandbox SDK runs Cloudflare Containers orchestrated from a Worker. Daytona markets containers with dedicated kernel/filesystem/network stack, plus VM and Windows classes. AWS describes AgentCore Code Interpreter as a per-session microVM — that one I'd verify against AWS's own page before betting on it; my sourcing is secondary.

If you want the long version of this trade-off, I wrote a whole post on choosing between containers, gVisor and microVMs. The short version: pick on syscall compatibility first, because it eliminates candidates fastest.

2. Boot latency — but measure the right thing

Ask three questions of any published number. Is it a cold boot or a snapshot restore? Does it include network setup and image pull, or start after those? Does the clock stop when the VMM returns, or when the guest answers?

The three answers can move the same platform by an order of magnitude. A 179ms create and a 3s create can be the same system on different paths.

The number that actually matters for agents isn't create latency at all. It's resume latency, because in a healthy product most sandboxes exist already and are asleep. My wake path is ~1.2s; it used to be 14s, and the gap was entirely engineering rather than physics.

3. Persistence

This is where I'd spend your evaluation time. The spectrum:

• Ephemeral. AWS AgentCore is session-scoped (reported ~8h cap) with no snapshot or fork primitive — you externalise state to S3 or a separate memory service.
• Filesystem persistence. Volumes, PVCs, mounted buckets. Northflank's model is this: persistent volumes and databases rather than a VM checkpoint API. Cloudflare offers R2/S3/GCS bucket mounts.
• Full checkpoint. Filesystem and memory. E2B's pause() saves both, and their docs say paused sandboxes are kept until you kill them. Vercel made persistent sandboxes the default — state auto-saves on stop. Fly.io suspends via a Firecracker snapshot capturing registers, memory and open file handles. CodeSandbox/Together supports memory snapshots plus fork from a live VM. Blaxel hibernates to standby indefinitely with filesystem and memory intact.
• Fork. Branching a running machine into two. This is the one I think is underrated for agents — it lets you speculatively explore several tool-use paths from one expensive setup state. Same-host copy-on-write fork on my fleet is 400–750ms.

The trap: defaults. E2B's docs say the default timeout will kill a sandbox unless you set onTimeout: 'pause'. Modal documents a short default sandbox timeout, configurable up to 24h. Cloudflare documents that sandboxes sleep after an idle window and, without a snapshot, the disk resets to the image. All three are documented, reasonable designs. All three will lose your state in staging while you're not looking. Read the timeout and sleep semantics before the isolation section.

And a warning from my own docs being wrong: a fork or restore does not preserve what you assume. Running processes, open file handles and unflushed writes are exactly what a naive mental model gets wrong. Test what survives before you build a feature on it. My snapshot-restore internals doc spells out what does and doesn't come back.

4. Egress control

The most-skipped property, and the one that got me. A free-tier signup on my fleet was mining cryptocurrency 27 minutes after I opened it. Isolation held perfectly — the microVM boundary did exactly its job — and it changed nothing, because containment isn't an abuse control. I now block mining-pool protocols at egress, and that's a floor, not a ceiling.

What to ask: can I set a default-deny egress policy with an allowlist? Are DNS lookups controlled (exfiltration over DNS is real — third-party research reported DNS-exfiltration paths against AgentCore, with AWS publishing hardening guidance)? Is outbound traffic metered, and does that meter become a bill? Google's Agent Sandbox ships default-deny Kubernetes NetworkPolicy. Vercel includes an egress firewall on their free plan per their changelog. Blaxel offers egress networking controls. If a vendor has nothing to say here, that's the answer.

The landscape

Grouped by isolation model, not ranked. Every cell comes from the vendor's own documentation or pricing page as of publication; where I could only source a claim secondhand the cell says so, and where a vendor's self-description is the only source I've written "states" or "claimed" rather than presenting it as verified. Pricing described by shape only — no rates, because they move faster than this post will.

Platform	Isolation	Where it runs	State across turns	Billing shape
E2B	Firecracker microVM	OSS infra (Apache-2.0) + hosted; self-host via Terraform, GCP stable / AWS beta	pause() saves filesystem and memory; paused kept until killed	Per-second vCPU/RAM/storage over tiers; free Hobby tier
Vercel Sandbox	Firecracker microVM	Hosted (SDK public); AWS BYOC reported in private beta, unconfirmed	Persistent by default, auto-saves on stop; Drives (beta) for attached storage	Active-CPU + provisioned memory + snapshot storage; available on free Hobby
Fly.io Machines / Sprites	Firecracker microVM	Hosted	Suspend = FC snapshot (registers, memory, file handles); Sprites adds non-expiring checkpoints	Per-second while started; stopped machines pay storage only
CodeSandbox SDK / Together Code Sandbox	Firecracker microVM	Hosted; migrating to Together AI — confirm the product name before you commit	Memory snapshots, fork/clone from a live VM, git-versioned filesystem	VM credits per hour; plan tiers gate concurrent VMs
Runloop	microVM on a custom bare-metal hypervisor (VM + container layers)	Hosted; VPC deployment for regulated workloads	Suspend/resume, git-style disk snapshots, Blueprints as reusable images	Free tier + paid Pro over usage meters; storage metered separately
Blaxel	microVM (vendor states Firecracker; one tracker says undisclosed)	Hosted; dedicated via custom plans	Hibernate to standby indefinitely, filesystem + memory restored	Pure usage, no base subscription; standby not billed as compute
AWS Bedrock AgentCore Code Interpreter	Per-session microVM (medium confidence — verify with AWS)	Hosted AWS only	Ephemeral, ~8h session cap, no snapshot/fork; externalise to S3	Per-second vCPU-time + memory dimension; memory bills while idle
PandaStack	Firecracker microVM, snapshot-restore on every create	Apache-2.0 core, self-host on Linux KVM / AWS / GCP; hosted cloud	Snapshots, CoW fork trees, hibernate/wake, named persistent volumes	Active CPU + working-set memory + storage; egress not billed
Modal Sandboxes	gVisor	Hosted only, no self-host or BYOC	Filesystem snapshots saved as Images + memory snapshots; 24h max sandbox life	Per-second by CPU cycle; explicit "never pay for idle" framing
Google Agent Sandbox (GKE)	gVisor default, Kata optional; default-deny NetworkPolicy	OSS controller (Kubernetes SIG subproject) + managed GKE add-on	GKE Pod snapshots for pause/resume; warm pools for fast allocation	Add-on reportedly at no extra charge — verify; you pay standard GKE
Northflank	Kata or gVisor, selectable per workload	Hosted + BYOC into AWS, GCP, Azure, Oracle, Civo or bare metal	Persistent volumes and databases; no memory-snapshot/fork API found	Per-second across vCPU/memory/GPU/disk/egress; genuine free tier
Cloudflare Sandbox SDK	Cloudflare Containers, driven from Workers/Durable Objects	Hosted runtime; SDK is open source	Disk snapshots; sleeps after configurable idle, wakes on request. No snapshot = disk resets to image	Active CPU at 10ms granularity + provisioned memory/disk; requires paid Workers
Daytona	Container (VM and Windows classes also offered)	Hosted only — went closed source June 2026; OSS repo public but unmaintained	Stateful environment snapshots; VM class documents stop/archive/pause/fork/volumes	Per-second vCPU/memory/storage; free credits on signup
Microsandbox	microVM via libkrun, local-first, embeddable as a child process	Apache-2.0 self-host; managed cloud in closed beta	Snapshot claimed, but beta software — verify semantics hands-on	Free self-hosted; no published cloud pricing yet
OpenSandbox	Pluggable — containers by default, gVisor / Kata / Firecracker opt-in	Apache-2.0, self-hosted only, no managed service	Volumes and PVCs; pause/resume claimed by third parties but unverified in the repo	Free software, you pay your own infrastructure

Two entries deserve a flag beyond the table. Daytona published in June 2026 that its production codebase moved closed source and the public repo would no longer be maintained — several 2026 comparison articles still list it as open source, and that is stale. CodeSandbox/Together is genuinely mid-rename; the npm package is still @codesandbox/sdk while docs describe migration to the Together platform.

Where PandaStack loses

Since I built it, the useful thing I can tell you is where it's the wrong pick.

E2B is more transparent as an open-source project than mine is. They publish their infrastructure repo with its development history intact, so you can audit how it was actually built. PandaStack's public repo is a squashed, curated cut — about a dozen commits on main — which means you cannot judge upstream activity or velocity from it, and the public cut lags the hosted product and excludes SDK and billing components. If "I can read the actual history" matters to you, that's a real difference and it's not in my favour. E2B also has a more mature code-interpreter layer.

Modal is a better answer if you need more than sandboxes. It's a general serverless compute platform with GPU. PandaStack has no GPU story. If your agent needs to run a model as well as run code, one platform beats two.

Northflank wins on BYOC. Deploying into your own AWS/GCP/Azure/Oracle/Civo account, with per-workload selectable Kata or gVisor, is a stronger enterprise story than "here's the Apache-2.0 source, run it yourself." Self-hostable and BYOC are not the same product.

There's also a bus factor of one, and 300-odd organisations is not a large number.

Do you even need one?

Sometimes a container is fine. Honestly ask:

Skip the sandbox if the code is first-party and templated (the model fills parameters, it doesn't author programs); or it's a short pure-JS/TS transform with no filesystem or subprocess needs (isolates are dramatically cheaper and a hypervisor would be embarrassing); or you're single-tenant and internal, where the worst case is you break your own staging; or every tool call is genuinely independent, so there's no cross-turn state to preserve.

What a sandbox costs you is not nothing. A microVM has a memory floor — my templates bake 1–4 GiB depending on the workload, and RAM is the binding constraint on density, not any slot limit (the ceiling is 16,384 sandboxes per host on the network side; you will run out of memory first, and by a wide margin). You add a control plane, a scheduler, a failure mode where the sandbox is up but the guest isn't answering, and either an ops burden or a vendor. If your threat model is "unreviewed but cooperative code from my own team," a hardened container with seccomp and a default-deny network policy is a legitimate engineering answer and I won't argue with it.

The line I'd draw: the moment untrusted code and multi-tenancy appear in the same sentence, you need the boundary. Before that, you might just need a container with the network turned off.

Failure modes that bite in production

The ones I've actually hit, not the theoretical ones:

• Sleep/timeout defaults ate your state. Covered above. It's the number one support-ticket shape in this category.
• Guest clock freeze after restore. A restored VM resumes with the wall clock from snapshot time. TLS handshakes then fail with certificate-validity errors that look like a networking bug. You must re-sync the clock on every restore, resume and wake. This cost me an incident.
• Fork doesn't preserve what the docs said. Mine didn't. A smoke test proved my own documentation wrong about processes and open file handles.
• Cross-host restore is a download. Same-host fork is a reflink; cross-host means pulling a multi-GB memory image before you can resume. Streaming memory on demand fixes it, but it's real work.
• Cache-driven false negatives in scheduling. My scheduler cached agent leases; roughly 12% of lease lookups returned 503 for hosts that were perfectly healthy. Never trust a cache for a negative answer.
• Egress is a product surface, not a checkbox. See the mining incident.

What I'd pick, for what

• Prototyping an agent that runs Python, want it working this afternoon: E2B. Purpose-built, good SDKs, code-interpreter layer, free tier, and you can self-host later if it works out.
• Already deployed on Vercel or Cloudflare: their native sandbox primitive. The integration is worth more than any isolation-model argument, and both have real snapshot stories now.
• You need GPU and general compute alongside sandboxes: Modal. One platform, gVisor is a reasonable boundary for most non-hostile workloads.
• You're a Kubernetes shop: Google's Agent Sandbox on GKE. Kubernetes-native, gVisor by default with Kata available, warm pools, default-deny networking.
• Compliance says it must run in your own cloud account: Northflank BYOC, or Runloop's VPC deployment for regulated workloads.
• You're building agent evals and need reproducible branching: Runloop (Blueprints and benchmark harnesses) or anything with real fork — CodeSandbox/Together and PandaStack both fork from a live VM.
• You want to own the whole stack and run Firecracker yourself: the honest options are PandaStack, Microsandbox (local-first, but beta — verify snapshot semantics before relying on them), or OpenSandbox (pluggable runtimes, very active, but treat the pause/resume claim as unverified). Pick based on whether you want a control plane or a library.

If you want the same fifteen platforms judged as products rather than as systems, I wrote a fuller roundup with per-vendor profiles. If you'd rather work bottom-up from the runtime, the six runtimes and who runs each covers what the isolation choice hands you. And if you're already past the sandbox question, the other four layers an agent needs is where teams get stuck next.

If I'm being useful rather than promotional: most teams reading this should start with E2B or their existing platform's primitive, and only reach for self-hosted Firecracker when the per-sandbox economics or the isolation requirements make it worth owning a hypervisor. That decision took me six months to earn. It shouldn't be your first one.

---

Ajay Kumar is an infrastructure engineer with 14 years of experience and the creator of PandaStack, Riff and PandaFlow. He is available for infrastructure consulting — microVM platforms, Firecracker, multi-tenant isolation — at linkedin.com/in/ajay-kumar-devops.