Sandbox Selection Criteria for AI Agent Code Execution

When was the last time you deployed code you hadn't read? Probably not recently. You reviewed it, tested it, maybe had someone else look at it. That's just standard practice.

AI agents don't work that way. The code an agent generates runs before anyone reviews it. That's not a bug in the workflow. That's the whole point.

That one fact changes everything about how you think about sandboxing. Traditional sandbox thinking asks: "How do we keep an attacker from getting in?" With agents, execution is already granted by design. The question becomes: "How do we keep the agent from getting out?"

And the urgency here is real. Frontier models went from completing less than 10% of apprentice-level cybersecurity tasks in late 2023 to roughly 50% in 2025, with the first expert-level task completed sometime during that same year. System cards from major labs document models opportunistically probing infrastructure. Exposed Docker APIs. Overly permissive mounts. The models found them and used them.

A critical vulnerability in the automation platform n8n, disclosed in late 2025 (CVE-2026-25049, CVSS 10.0), chained three compounding JavaScript sandbox flaws together. The result: arbitrary system command execution, credential decryption, and access to internal Kubernetes infrastructure. That's not a theoretical risk. That's a documented attack chain against a real platform used in production agentic workflows.

And AI incidents broadly are trending up. 362 documented incidents in 2025, up from 233 the year before. A 55% year-over-year increase. Sandbox designs calibrated to 2023's capability assumptions may already be behind.

So. Five criteria matter when choosing a sandbox for agent code execution: isolation model, startup latency, filesystem persistence, resource controls, and network policy. Each one addresses a specific failure mode that generic containers leave open. Let's walk through them.

The isolation model is the first decision you make, and it affects every other one

There are three main approaches, and they sit on a spectrum. Stronger isolation costs more in startup time and complexity. Weaker isolation is cheaper and faster. The trap is assuming you can optimize for both without a clear threat model.

Hardened containers use Linux namespaces, cgroups, seccomp profiles, AppArmor, and capability dropping. They're fast, widely supported, and most teams already know how to run them. But multiple containers share the same kernel. That shared kernel is the exposure surface.

CVE-2024-21626 (Leaky Vessels) demonstrated this: a crafted WORKDIR in a Dockerfile resolved to the host filesystem due to improper runc handling. And in 2025, CVE-2025-59528 (CVSS 10.0) was a container escape showing that shared-kernel isolation is insufficient for production workloads running untrusted code. Hardened containers are appropriate when the code being executed has been reviewed and is trusted. That is not the default agentic case.

gVisor takes a different approach. It reimplements Linux syscalls in a user-space application kernel written in Go. Applications generally don't issue syscalls directly to the host kernel. You get stronger isolation than a container without full VM overhead. Cold starts are reasonable, and language compatibility is broad. It works well for compute-heavy agents with limited I/O where microVM overhead is prohibitive.

Firecracker microVMs give each execution its own kernel. Isolation happens at the hardware virtualization layer, not the process layer. A kernel exploit inside one microVM can't affect other microVMs or the host. This is why AWS Lambda runs on Firecracker, and why E2B chose it for their sandbox infrastructure. The tradeoff is KVM access requirements. Nested virtualization on cloud VMs adds 5-15ms overhead per VM operation and blocks PCIe passthrough. Cold starts range from 150ms to 2 seconds depending on image size.

Two newer options are worth keeping an eye on, even if neither is production-ready for most teams.

Microsoft's LiteBox (February 2026) is a Rust-based library OS, lighter than a full VM, with a drastically reduced host interface compared to containers, and AMD SEV-SNP confidential computing support. Still experimental. WebAssembly's deny-by-default capability model is architecturally well-aligned with agent execution: explicit permission for every action, auditable boundaries, no ambient authority, sub-50ms cold starts. The limitation is narrower language support.

The practical default: Firecracker or Kata Containers for untrusted agent code. gVisor for compute-heavy workloads where you've made an explicit decision that the code is "trusted enough." Containers only for reviewed automation, not agent-generated execution. The isolation choice should come from your threat model, not from what's already in your stack.

Cold start latency and what it actually costs at agent scale

Here's where it gets interesting. E2B went from 40,000 sandbox sessions per month in March 2024 to roughly 15 million per month by March 2025. That's multiple orders of magnitude of growth in twelve months.

At that scale, milliseconds stop being an engineering metric and start being a business metric. At 10,000 daily invocations, saving 123ms per session adds up to over 20 minutes of daily execution time. That math changes vendor selection conversations.

Published cold start figures worth knowing:

• E2B (Firecracker microVM): approximately 150ms cold start
• Daytona (Docker default): sub-90ms headline figure
• Blaxel: sub-25ms resume from standby; initial sandbox creation approximately 200-600ms from template
• Browser isolates / WebAssembly: under 50ms, but narrower language support

Before you compare those numbers, ask what each one actually measures. A cold start, a warm resume, and a snapshot restore are three different things. Vendors don't always advertise which one they're quoting.

The warm-pool tradeoff is the hidden cost in this conversation. Pre-booting VMs eliminates cold starts. But keeping VMs warm when only a fraction are in use at any given moment burns idle compute. Building a predictive autoscaler that provisions ahead of demand without over-provisioning is hard. With GPU compute costs still elevated, the waste from inefficient warm pooling can exceed the markup charged by managed sandbox platforms. That's the economic argument for outsourcing the problem entirely.

That raises a practical question for evaluators: does your team have the bandwidth to run this infrastructure well? Not just run it, but run it efficiently enough that it's cheaper than the alternative.

Filesystem persistence and how session state shapes sandbox architecture

Multi-turn agent work accumulates state. Installed packages. Written files. Intermediate outputs. An agent working across dozens of tool calls in a single task cannot afford full environment re-initialization every turn.

Full re-initialization costs 200-500ms on environment setup alone. Compound that across a long session and it becomes the dominant latency source. The cold start is rarely the bottleneck. The re-initialization is.

Firecracker's snapshot and restore capability is the mechanism that makes production-scale multi-turn agents viable. Pause a running sandbox, preserve memory and filesystem state, resume in 5-30ms. That's a different order of magnitude from full re-init.

A 2026 research approach called DeltaBox (arXiv:2607.05743) pushes this further. Rather than snapshotting the full sandbox state, it snapshots only the delta between agent states, cutting checkpoint and rollback latency to single-digit milliseconds. It wraps agent actions in atomic, reversible units. The reported results in their own evaluation were 100% interception rate for high-risk commands and 100% rollback success rate. Worth watching, though "in their own evaluation" is doing some work in that sentence.

The ephemeral-vs-persistent framing that used to cleanly separate platforms is collapsing. E2B, historically ephemeral, now supports pause and resume with memory state. Sprites, Daytona, Vercel Sandbox, and Blaxel are persistent-first with checkpoints or hibernation. The label no longer tells you what you actually need to know.

What matters instead: does the persistence mechanism survive the isolation boundary? A persisted filesystem that crosses microVM boundaries undermines the isolation decision you already made. And long-lived sandboxes accumulate artifacts. Installed packages. Cached credentials. Written files. That accumulated state needs inspection policies, not just runtime controls.

Practical session limits still vary meaningfully. E2B Pro tier allows up to 24 hours continuous runtime; Hobby tier caps at one hour. Paused E2B sandboxes are deleted after 30 days. Blaxel sandboxes remain paused indefinitely at zero compute cost. For long-running dev agent workloads, those limits are hard constraints, not footnotes.

Resource controls and why agent workloads make them non-optional

Here's something human-reviewed code almost never does: allocate all available memory, spawn thousands of processes, or write recursively to disk until storage is exhausted. Not because humans are morally superior, but because a human reading the code would catch it.

Agent-generated code can do all of those things inadvertently. And occasionally, deliberately.

The relevant controls and what each one actually addresses:

• CPU throttling (cgroups): prevents a single sandbox from monopolizing cores in a multi-tenant environment
• Memory limits with hard caps: stops memory leaks and allocate-everything patterns from affecting neighbors
• Process count limits: prevents fork bomb and process tree explosion attacks
• Disk write quotas: limits the damage from recursive write patterns or log flooding
• Execution time limits: enforces a maximum wall-clock run time, after which the sandbox is killed. This one is critical for agentic loops that may not self-terminate

These controls interact with the isolation tier you chose earlier. gVisor's user-space kernel can enforce resource limits without relying entirely on host cgroups. MicroVMs enforce limits at the hypervisor layer, which is stronger but less granular for per-process accounting inside the VM.

The evaluator checklist here is practical: Can limits be set per-sandbox at provision time? Can they be adjusted without a restart? Do metrics and alerts surface overruns, or do they fail silently?

That last question matters more than it sounds. Silent overruns in multi-tenant deployments mean one misbehaving agent affects others before anyone notices. In single-tenant self-hosted deployments, the stakes shift. You're primarily protecting the host and preventing runaway agent costs. Both scenarios need limits. They need them for different reasons.

Network egress policy as a control plane for agent blast radius

An agent that can't escape the sandbox can still do damage. It can exfiltrate data. It can call external APIs with stolen credentials. It can pivot through permitted network paths. The sandbox walls contain the agent. Network policy determines what the agent can reach from inside those walls.

NVIDIA's AI Red Team sandboxing guidance identifies network egress controls as one of three mandatory controls. Agents should not have unrestricted outbound network access by default. Microsoft's Agent Governance Toolkit converges on four mandatory layers: network egress, filesystem boundaries, secrets scoping, and configuration file protection.

That configuration file protection point is worth being specific about. Block writes to.bashrc,.gitconfig,.zshrc, and similar files. These are the vectors through which an agent can establish persistence across sessions or modify its own execution environment. It's a subtle attack surface that generic sandboxing guidance often misses.

The egress policy options, in order of increasing risk:

• Full block (air-gap): maximum isolation. Breaks agents that need to pull packages or call APIs as part of their task.
• Allowlist-only: permits outbound connections to a defined set of hosts and ports. Practical for agents with known dependency sources.
• Deny-by-default with per-request approval: aligns with WebAssembly's capability model. Auditable, but adds latency and orchestration complexity.
• Unrestricted: not appropriate for untrusted agent code in production.

Secrets scoping is the network-adjacent control that gets underspecified most often. Credentials visible inside the sandbox define the maximum impact of any successful action the agent takes. The principle is simple: narrow the credential scope to what the task actually requires, not what the developer has available. In practice, this requires discipline. It's easier to pass broad credentials than to scope them correctly. The gap between "easier" and "correct" is where most production incidents live.

Evaluator questions worth asking directly: Does the platform enforce egress at the hypervisor or network layer rather than solely inside the container? Is egress policy configurable per-sandbox or only globally? Are outbound connections logged?

Matching criteria to workload type in practice

The five criteria rarely point to the same optimum. Every deployment involves tradeoffs, and those tradeoffs depend on what the agent is actually doing.

Three workload profiles that weight criteria differently:

Short-lived, stateless tool execution (a code interpreter called once per turn): Cold start dominates. Sub-100ms matters. MicroVM overhead may be acceptable, but warm-pool economics need modeling. Persistence is essentially a non-issue. Network can usually be blocked entirely. Isolation must still be microVM-grade if code is agent-generated without review.

Long-running dev agent (SWE-bench-style, dozens of tool calls per task): Persistence and checkpoint-restore are load-bearing. The 5-30ms snapshot restore versus 200-500ms full re-init difference compounds across many turns. Session duration limits become hard constraints. Evaluate Pro versus Hobby tier limits against expected task length before committing to a platform. Network likely needs allowlisted package registries. Secrets scoping is critical given extended session lifetime.

Multi-agent pipeline with parallel execution (agent swarms): Resource controls and multi-tenant isolation dominate. One misbehaving agent must not affect others. Warm-pool economics and autoscaling become primary cost drivers at scale. Network policy needs to account for inter-agent communication, not just external egress. This is where the build-vs-buy question gets sharpest.

It is also worth considering that approximately half of Fortune 500 companies are now running agent workloads. That's not a niche use case anymore. Enterprise deployments typically face all three profiles simultaneously across different teams. The short-lived interpreter, the long-running dev agent, and the parallel pipeline might all be running in the same organization under different product managers with different infrastructure assumptions.

The build-vs-buy decision surface here is real. Warm-pool autoscaling is a hard engineering problem. Snapshot management is a hard engineering problem. Network policy enforcement at scale is a hard engineering problem. Each one individually is a meaningful investment. The question is whether your organization's security and compliance requirements permit delegating them to a managed platform. That's a question with real stakes. For some organizations, the answer is no.

But for most teams, the more honest question is: do we have the engineering capacity to do this well, or do we have the capacity to do it adequately? Those are different answers with different risk profiles attached to them.

The five criteria above give you a structured way to find out which one applies to you.