Performance Overhead Benchmarks Across Sandbox Technologies

Sandboxing AI agents comes down to one tradeoff: how safely the code runs versus how fast, cheap, and stateful that execution can be. Four isolation tiers are in active production use in 2026, plain containers, gVisor, microVMs, and WebAssembly, and each buys its security boundary at a measurable cost in startup time, memory, or throughput. The choice between them is practical. It's an engineering decision with a bill at the end of the month, and picking wrong shows up as either a security incident or a margin that quietly disappears.

Why does this matter more now than it did two years ago? What's running inside the sandbox has changed. Traditional application code has a fixed, auditable instruction set someone wrote and reviewed. An AI agent generates its own Python at runtime, installs whatever package it decides it needs, and opens file descriptors based on a prompt a user typed five seconds ago. Once an agent writes and runs its own code, the shared kernel underneath a standard container stops being background plumbing. It becomes the attack surface itself.

The vulnerability record backs this up. CVE-2024-21626 in runc is a container escape bug in a runtime deployed at wide scale, and CVE-2025-59528, which scored a full 10.0 on CVSS and hit Flowise, is a critical remote-code-execution vulnerability in an AI agent platform deployed at wide scale. Most escapes, worth pausing on this, don't come from some exotic zero-day. They come from misconfiguration: privileged containers, mounts that expose more of the host than anyone intended. That makes the exposure structural rather than a patching problem, baked into how shared-kernel isolation works in the first place.

OWASP's AIVSS framework assigns a 9.4 CVSS v4.0 score to the scenario where an LLM-based agent gets manipulated into running attacker-supplied code through its own interpreter tool, about as direct a threat model as sandboxing gets. And the ground keeps moving: frontier model performance on apprentice-level cybersecurity tasks went from under 10% in late 2023 and early 2024 to roughly 50% in 2025. A sandbox architecture calibrated to what models could do in 2023 is being asked to hold against what they can do now. That's a different problem entirely.

Underneath all of this sits the confused deputy problem. An LLM acting as a trusted process inherits whatever authority that process has: database credentials, network reach, filesystem permissions. Standard role-based access control has no way to tell a legitimate request from one a prompt injection just planted. This isn't theoretical. The Replit incident, where an agent deleted a production database, and the Postmark MCP case, where a BCC injection quietly exfiltrated email, both show what the blast radius looks like once ambient authority meets an adversarial prompt. Escalating capability, structural exposure, and a widening gap between agent authority and agent trustworthiness: that combination is why engineering teams have landed on a genuine spread of isolation technologies instead of one default choice.

The isolation strata available in 2026 and what each one gives up to achieve its security boundary

Picture a ladder. Each rung buys a stronger security guarantee and costs something specific to get there. No tier is correct in general, only correct for a given workload, and reaching for the strongest one by default is its own kind of mistake. It just moves the cost from a security column into a latency and memory column.

Plain containers, Docker and runc, sit at the bottom. They rely on Linux namespaces and cgroups, and every container on the box shares the same host kernel. Memory overhead runs about 5 to 10 MB per instance, cold start lands around 200 milliseconds, and the security model is exactly as strong as its weakest patch: one unpatched kernel CVE compromises everything running on that host. Fine for trusted code in a single-tenant setup, or for prototyping. Wrong for multi-tenant AI agent workloads where the code itself is untrusted by design, and treating it as good enough there is the single most common mistake teams make with this stack.

gVisor comes next. Google's user-space kernel intercepts syscalls through a process called Sentry before they ever touch the real host kernel, with the Sentry component restricting its own host interactions to around 68 allowlisted syscalls out of the 350-plus that exist in Linux. It covers roughly 70 to 80% of Linux syscall behavior, so some things (systemd, Docker-in-Docker, certain networking setups) simply don't work, or fall back to something slower. The cost shows up as 10 to 30% overhead on I/O-heavy workloads, with broader startup-plus-runtime overhead landing in the 20 to 50% range versus a plain container.

MicroVMs sit above that. Firecracker, Kata Containers, and newer entrants like CubeSandbox run full hardware virtualization, and each sandbox gets its own guest kernel, so escaping one means a VM escape, an order of magnitude harder to pull off than a container escape. Firecracker boots in 60 to 150 milliseconds, strips out the BIOS, PCI bus, and most of the ACPI layer, and runs on roughly 50,000 lines of Rust that AWS has hardened at Lambda scale. Kata Containers wraps multiple VMMs, Firecracker, Cloud Hypervisor, QEMU, inside a container-orchestration-friendly runtime, which adds an operational layer and a longer cold start, 150 to 300 milliseconds depending on configuration. CubeSandbox, a Tencent project released in April 2026, built its own hardware-virtualization VMM in Rust specifically for AI agent workloads, with a pre-created resource pool, copy-on-write snapshot cloning, and eBPF-based network isolation. Cold start comes in under 60 milliseconds, and memory overhead per instance drops under 5 MB by cloning from template snapshots instead of booting a fresh guest kernel every time.

WebAssembly sits at the top of the ladder as the odd one out, trading coverage rather than speed for safety. WASM sandboxes start in microseconds, hold no elevated privileges by default, and get no filesystem, network, or environment access unless the host explicitly grants it. Runtimes include WasmEdge and wasmtime for server-side WASI execution, plus V8's isolate-based model for JavaScript and WebAssembly together. C extension support is still catching up. TensorFlow isn't fully supported in most server-side WASM runtimes, and while NumPy and Pandas exist in Pyodide-based browser WASM, they're limited outside that context. WASM suits pure-Python, stateless, lightweight tasks well. Anyone reaching for it as a default runtime for a data-science agent is going to hit that wall fast.

Two more entries round out the picture. Microsoft's LiteBox, announced in February 2026, is a Rust-based Library OS running on AMD SEV-SNP confidential computing, lighter than a VM with a much smaller host interface, though it's still experimental and lacks anything like Firecracker's production track record. Google's Agent Sandbox, launched at KubeCon NA 2025 as a Kubernetes SIG Apps subproject under CNCF, gives teams a declarative API for managing isolated, stateful sandbox pods. It defaults to gVisor but supports Kata Containers too, and its SandboxWarmPool custom resource keeps pods pre-warmed to push cold start under one second.

Startup latency: what the cold-start numbers actually measure and where hidden costs compound

Line the tiers up by cold start and the ladder looks almost too clean: plain containers around 200 milliseconds, gVisor adding relatively little on top since there's no VM boot involved, Firecracker at 60 to 150 milliseconds, Kata at 150 to 300, CubeVM under 60 milliseconds cold with a P99 of 137 milliseconds at 50 concurrent requests and a 25-millisecond resume from a standby snapshot.

But those headline numbers hide something that must be called out directly. Firecracker's jailer, the process isolation layer meant to constrain what the VMM itself can do, can inflate startup latency by as much as 263% under certain configurations, turning what should be a 125-millisecond boot into something that stretches into multiple seconds. That detail rarely shows up in vendor comparison tables, which tend to quote the best-case number rather than the jailer-constrained one. So the question worth asking of any cold-start figure is how fast, but not only that. It's measured under what jailer config, and at what concurrency.

Why does this matter beyond the benchmark chart? Agent workloads don't make one cold start. They make dozens. A coding agent chaining five sequential tool calls at two seconds of cold start apiece has already burned ten seconds before a single line of actual work happens. Even the leaner end, 150 milliseconds per cold start across three sequential calls, adds up to 450 milliseconds of pure overhead sitting in front of the task. Terminal-Bench data puts this in perspective: a median turn duration of 3.34 seconds and roughly 117 expected turns per task means infrastructure latency compounds across hundreds of turns, not just the handful most benchmarks bother to measure.

Warm pools are the industry's answer to this, and they work, but they're not free. Google's Agent Sandbox warm pool mechanism and similar vendor architectures can push effective cold-start latency under a second even for the microVM tier. Idle capacity sitting ready to be claimed still costs memory and money, though, so the "cold start" number on a vendor's homepage often means something narrower than it sounds: time-to-first-byte from an already-warm host, not time-to-interactive for a brand-new workload arriving under real concurrent load. CubeSandbox's 137-millisecond P99 at 50 concurrent requests is the more honest figure, because it describes fifty things wanting a sandbox at the same moment, closer to what a production agent platform actually faces than a single best-case boot.

Memory and per-instance overhead at the scale AI agent platforms actually run

Per-instance memory looks like a rounding error until it gets multiplied by however many sandboxes a platform runs concurrently. Then it becomes a hard ceiling on how much a single node can hold. Plain containers sit at 5 to 10 MB per instance. gVisor adds a dedicated Sentry process per sandbox, pushing overhead meaningfully above the plain-container baseline. Firecracker ranges 5 to 50 MB depending on guest kernel and rootfs size, landing around 30 to 50 MB in practice for code execution workloads. CubeSandbox's copy-on-write approach, forking from template snapshots instead of booting fresh, gets under 5 MB per instance, a substantial reduction against Firecracker-based setups.

That gap isn't academic. CubeVM's architecture reportedly supports over 2,000 sandboxes on a single node, and that density number says something a lot of teams miss when comparing tiers purely on security grounds. Per-instance memory overhead is a hidden cost that never appears as a line item on a cost sheet. It's a hard constraint on how many concurrent agents a node can actually serve.

Scale the math out and the tradeoff sharpens. Firecracker's roughly 5 MB of added overhead per instance over plain containers translates, at thousands of concurrent instances, into something like a 10 to 20% cost increase versus a container-only deployment. That premium buys protection against the kind of multi-tenant breach that costs a lot more than the infrastructure bill ever would, so it's worth paying in almost every multi-tenant case. Published production figures back this up: over 2 million isolated workloads processed monthly on infrastructure using Kata Containers and gVisor, which says the overhead math, while real, is manageable at genuine production scale rather than a theoretical concern that only shows up in a lab benchmark.

For teams running enough volume, above roughly 500 sandbox-hours a month, self-hosting the hypervisor layer on bare-metal GPU instances starts to make sense despite the operational lift of running that stack directly. Per-execution cost can drop 60 to 80% at that volume, which flips the overhead conversation on its head: what looks expensive at small scale reverses once usage crosses that threshold.

CPU and I/O throughput: where isolation overhead is sharpest and what workload type determines the impact

Not every workload feels isolation overhead the same way, and this is where gVisor and microVMs really part ways. gVisor works by intercepting every syscall in user space, so I/O-intensive workloads pay the steepest tax: 10 to 30% slower than an unisolated equivalent. CPU-bound work barely touches the syscall path once it's running, so gVisor's overhead there shrinks toward something close to negligible.

Firecracker takes a different route. Its virtio device model, virtio-net for networking and virtio-block for storage, delivers close to native throughput for I/O once the VM has booted, since the isolation boundary sits at the hardware virtualization layer rather than intercepting every individual syscall. That makes Firecracker the better fit when an agent is doing heavy file operations or network calls, and it's a good part of why the two technologies don't really compete head to head. They serve different workload shapes, and picking one because it "won" a generic benchmark misses the point entirely.

For CPU-bound tasks, pure computation, inference against a model already loaded into memory, the gap between gVisor and Firecracker narrows considerably. Neither pays much of a tax when the workload isn't touching the kernel boundary often, so defaulting to the heavier isolation tier out of caution alone deserves a second look rather than an automatic yes.

The syscall coverage gap is also a correctness question before it's a speed question. gVisor's 70-to-80% syscall coverage means an application that reaches into the uncovered 20 to 30%, certain networking features, Docker-in-Docker, systemd, doesn't just run slower. It fails outright, or silently falls back to a degraded path. Worth checking against a given agent's actual dependency list before throughput even enters the conversation, since a fast sandbox that silently drops a feature is worse than a slow one that works.

On the hardening side, G-Fuzz, published in IEEE Transactions on Dependable and Secure Computing across January and February of 2024 and deployed industrially at Ant Group, achieved as much as a 131x speedup over Syzkaller when fuzzing general targets. That kind of active fuzzing effort against gVisor's syscall surface matters for anyone weighing it as a multi-tenant isolation layer: the attack surface is actually being tested, not just assumed safe because the syscall list is short.

As for WASM, its near-zero syscall overhead sounds like the answer to all of this, right up until the workload needs NumPy, Pandas, or TensorFlow in a server-side context. Throughput stops mattering the moment the workload can't run at all, and that disqualifies WASM for a large share of real agent tasks today, whatever its theoretical performance ceiling looks like on paper.

Snapshot, checkpoint, and restore overhead in stateful agent workflows

Agents doing test-time tree search or reinforcement learning need something containers were never built for: high-frequency checkpoint and rollback of complete sandbox state, meaning files, process memory, open file descriptors, not just a saved session cookie.

CRIU, Checkpoint/Restore In Userspace, is the standard tool for this. It freezes a running container and captures file descriptor state, memory maps, process credentials, and the actual contents of memory pages. Under high concurrency, though, CRIU-based checkpoint latency can stretch into tens of seconds, a figure measured on AWS c6id.32xlarge instances with local NVMe storage. That's workable for migration or disaster recovery, where a checkpoint happens occasionally. It's far too slow for an agent branching through dozens of speculative execution paths, where a checkpoint might need to happen every few seconds. Using CRIU raw in that setting is a mismatch between the tool and the job.

Research published in 2026 (arXiv 2605.22781) under the name DeltaBox starts from a simple observation: consecutive checkpoints in an agent's execution look a lot alike. Rather than duplicating full state each time, DeltaBox captures only the delta between one checkpoint and the next. Its DeltaCR component runs an asynchronous CRIU incremental dump to tmpfs at the same time as a template-creating fork, so the combined latency mostly hides inside the window where the LLM is already busy running inference. Restoring from that template takes low single-digit milliseconds, and if the template happens to have been evicted, DeltaCR falls back to CRIU's lazy-pages restore, at around 8 milliseconds. A separate Network Proxy Daemon keeps the agent's live LLM connection alive during the checkpoint itself, so from the user's side there's no visible pause at all.

A related approach, TClone, splits the problem into two pieces: fast branch creation using copy-on-write sharing, and durable state capture handled asynchronously and separately. CubeSandbox's CubeCoW engine applies similar logic, delivering checkpoints in the hundred-millisecond range by forking new instances from template snapshots rather than freezing and serializing full state each time, unlike CRIU's synchronous save-and-restore model. The vendor describes this as a kind of time-travel debugging for agents, letting a session roll back to any prior checkpoint on demand.

What this means for choosing an isolation tier: microVMs have snapshot and restore built into their architecture from the ground up. gVisor's checkpoint story runs through external CRIU integration rather than anything native. Plain containers offer no state isolation at all. Checkpoint fidelity is bounded by whichever isolation tier sits underneath it, and that's worth weighing before performance-per-checkpoint even enters the conversation. No amount of clever delta-encoding fixes a tier that never supported state capture in the first place.

How the platforms engineering teams are actually deploying compare on these dimensions

One documented production configuration runs on Docker with Kata Containers as an optional layer, posting cold starts around 90 milliseconds (27 milliseconds when optimized) with no cap on concurrent sessions. It supports GPU acceleration across H100, H200, and RTX hardware, ships open source, and allows customer-managed compute (BYOC) alongside SOC 2, HIPAA, and GDPR compliance. Docker-native compatibility means existing container tooling carries over without needing to be rebuilt for a new runtime, which matters for teams that already have a CI/CD pipeline built around standard container images and don't want to re-architect it just to add isolation.

The broader lesson across every platform covered here is the one the four-tier framework points to from the start, and it should be stated rather than hedged: there is no universally correct choice, only a correct choice for a given agent's actual behavior, and picking the strongest tier by default is a bad habit dressed up as caution. An agent running lightweight, stateless, pure-Python transformations can lean on WASM's microsecond startup without ever missing the C-extension support it doesn't need. An agent doing heavy file I/O or making dozens of sequential tool calls gets more out of Firecracker's near-native I/O throughput than out of gVisor's syscall interception tax. And an agent doing speculative tree search, branching and rolling back state at high frequency, needs a microVM tier with native copy-on-write snapshot support, because CRIU's tens-of-seconds checkpoint latency under load simply can't keep pace with how often that kind of agent needs to save its state.

The number that should anchor any of these decisions is measured under production conditions, not the cold-start figure on a vendor's homepage. It's the one measured under real concurrency, at the checkpoint frequency an agent's actual workflow demands, against the specific mix of syscalls that workload actually makes. Everything else is a benchmark run on a workload that isn't the one being shipped.