container-isolated sandbox runtimes for AI agent workloads

AI agents run code nobody has read. That's the plain fact behind every design decision covered here: when an agent writes a Python script, installs a package, or calls a shell command mid-task, no human has reviewed that code before it hits a runtime. This piece walks through what that shift breaks in the standard container model, which isolation primitives actually hold up against it, and how the platform landscape has organized itself around the answer over the past year or so.

What container escape actually looks like: the attack surface in concrete terms

Start with a fact that surprises people who haven't worked with the runtime layer directly: containers were never designed to contain untrusted code. Docker's default runtime, runc, gives processes their own view of the filesystem, network, and process tree through Linux namespaces, and it limits resource use through cgroups. What it does not do is separate the container from the host kernel. Every container on a given host makes syscalls into the same kernel, running the same code, sharing the same bugs. That distinction, process isolation versus kernel isolation, is the entire subject of this piece, so it deserves sitting with before moving on.

CVE-2024-21626, nicknamed "Leaky Vessels," shows exactly what happens when that assumption gets exploited. A file descriptor leak in runc let a malicious container gain a way to reach the host filesystem, breaking out of the very boundary runc exists to enforce. No amount of application-level hardening stops this, because the flaw sits in the runtime itself, below the layer where seccomp profiles or AppArmor policies operate.

Langflow's CVE-2025-3248 shows a different failure mode entirely, one specific to agent tooling. The platform's code validation endpoint ran user-supplied Python through Python's own exec() function, with no authentication required to reach it. That scored a 9.8 on the CVSS scale, about as severe as a vulnerability gets, and the relevant agency added it to a catalogue of confirmed real-world exploits on May 5, 2025, confirming it wasn't theoretical. Someone, somewhere, was already exploiting it in the wild.

Then there's the Snowflake Cortex Code CLI disclosure from March 16, 2026 (the fix had shipped as version 1.0.25 on February 28, ahead of public disclosure). This one didn't rely on a memory bug or a missing auth check. It combined indirect prompt injection with weak command validation, letting AI-generated instructions slip past the human-in-the-loop approval step, escape sandbox mode, and reach cached credentials. Three incidents surfaced three different vectors, including a runtime-level file descriptor leak, a direct code execution endpoint, and a prompt-injection chain that talked its way past approval logic. The attack surface for agent infrastructure spans many things. It's layered, and each layer fails differently.

All three stem from what security researchers call the confused deputy problem. An LLM acting inside an authorized process inherits every ambient permission that process holds. Traditional role-based access control can't catch this, because RBAC checks who you are, not what you're actually trying to do. A prompt injection needs only to exploit the system as designed, not find a bug in it. It just needs to convince the agent, which already holds valid credentials, to use them somewhere they weren't meant to go. That's a much lower bar than exploiting a memory corruption vulnerability, and it's part of why agent security looks so different from traditional application security.

One more wrinkle: agents don't just execute risky code, they sometimes write it. Reporting on LLM-generated code patches has found that in roughly 9.5% of cases, the patch fixes the original bug while introducing a new vulnerability in the process. The agent's own output becomes a recurring source of exposure, not just a one-time risk at execution. Across every scenario here, the common thread is the same: the execution environment held more access than the task actually needed. Sandboxing exists to close that gap, applying least-privilege enforcement at the layer where code actually runs.

The isolation stack: what microVMs, gVisor, and hardened containers each enforce and what they don't

Compare the isolation options along three axes: how strong the boundary is, how long the sandbox takes to start, and what class of attack it actually stops. No single option wins on all three, which is exactly why the landscape has fragmented into several distinct approaches rather than converging on one winner.

Hardened containers, meaning Docker with seccomp profiles, AppArmor, and rootless configuration layered on top, still share the host kernel underneath all that hardening. Narrowing the syscall surface reduces risk, it doesn't remove the shared boundary. This approach fits trusted, vetted code running in single-tenant setups. It is a boundary too weak to trust for AI-generated code running alongside other tenants' workloads. What it does offer is speed: startup measured in milliseconds and very high density per host, which explains why teams reach for plain containers first, before the requirements of untrusted execution force a rethink.

gVisor takes a different approach: instead of hardening the syscall path to the host kernel, it intercepts every syscall in user space through a component called Sentry, and the workload never touches the host kernel directly. Where a plain container might expose hundreds of syscalls to the kernel, gVisor passes through a minimal, vetted subset. That puts gVisor's isolation somewhere between a container and a full VM: a kernel exploit that targets a syscall gVisor doesn't implement simply can't reach it, but a bug in gVisor's own implementation of the syscalls it does support remains a real risk. I/O-heavy workloads pay a noticeable overhead penalty under gVisor, worth knowing before putting a filesystem-intensive agent on it. GPU access considerations differ from full hardware virtualization, which can matter for ML-heavy agent workloads.

Firecracker microVMs push the boundary further still. Each workload gets its own lightweight VM, running its own Linux kernel inside KVM, so an attacker has to escape the guest kernel and then the hypervisor, not just one layer. Device emulation is deliberately minimal, keeping per-VM overhead under 5 MiB, and a single host can provision up to 150 of these VMs per second. Cold boot is around 125ms, and snapshot-restore, pausing a VM and resuming it later, can bring a sandbox back in the single-digit-to-low-double-digit millisecond range. This is the primitive underneath AWS Lambda and similar multi-tenant services, and it currently offers the strongest isolation of the three approaches for running code nobody trusts. The snapshot-restore capability turns out to matter for agents specifically, since it means pausing mid-task and resuming later without losing whatever state was in progress.

Kata Containers takes those VM-level guarantees and wraps them in ordinary container tooling. It orchestrates VMMs, Firecracker, Cloud Hypervisor, or QEMU, underneath, so Kubernetes sees a normal container while the workload actually runs inside a full VM. Boot time is around 200ms, and it integrates through Kubernetes' RuntimeClass mechanism, so existing Kubernetes workflows don't need restructuring. That combination, VM isolation without giving up container-native tooling, makes Kata a natural fit for regulated industries running production Kubernetes clusters.

WebAssembly and V8 isolates take a fundamentally different route. WASI 0.2 shipped with a stable Component Model, and WASI 0.3 has now landed with native async support, aimed either at JavaScript-specific tooling through V8 isolates or polyglot, capability-controlled tool execution through Wasm. The advantage is fine-grained capability control: an agent's tool can be granted exactly the I/O access it declares and nothing more. The tradeoff is that Wasm is a specialized environment rather than a general-purpose Linux environment, so it limits which languages and runtimes can run inside it. It's a strong fit for narrow, well-defined tool calls, less so for an agent that needs to shell out and run arbitrary system commands.

Read across all four options and a pattern emerges: isolation strength and operational flexibility trade against each other in ways that depend entirely on what the workload actually needs, which is exactly why the choice has to start with the threat model rather than a general preference for "more secure."

Cold-start latency as a first-class design constraint, not a footnote

Agent workflows run in sequence. A task with several tool calls means several separate moments where a sandbox has to spin up before anything can execute, and that latency compounds fast. Across 15 sequential tool calls, a 2-second cold start on each one adds up to 30 seconds of pure waiting before any actual work happens. Bring that startup time under 100 milliseconds instead, and the same 15-step workflow finishes in under 2 seconds. That's not a marginal optimization, that's the difference between an agent that feels instant and one that feels broken.

Research from Zylos.ai in 2026 lays out where different approaches land on this spectrum. Pre-provisioned pools, where sandboxes sit warm and ready before a request arrives, run under 90 milliseconds. Firecracker's cold start runs around 150 milliseconds. Kata Containers and other microVM setups run around 200 milliseconds. Standard Docker-based approaches, meanwhile, run 1 to 3 seconds, an order of magnitude slower than the fastest tier.

That gap explains why pre-warming has become its own engineering discipline rather than a nice-to-have. WarmPools, part of the kubernetes-sigs/agent-sandbox project, keep pods provisioned and idle so a request never has to wait through a cold boot. Firecracker's snapshot-restore mechanism, resuming a paused VM in 5 to 30 milliseconds, does something similar from a different angle: instead of avoiding the cold start, it avoids needing one at all for a sandbox that already exists.

The isolation tiers offering the strongest security guarantees, Kata and full microVMs, also carry the longest cold starts. Teams get to pick, more or less, from three options: accept the latency as a cost of doing business, invest engineering time in warm pools to hide it, or drop down to a lower isolation tier and accept more risk in exchange for speed. Snapshot-restore complicates that tradeoff in a useful way, since a paused microVM resuming in single-digit-to-low-double-digit milliseconds gets close to container-speed startup while keeping hardware-level isolation intact. Anyone speccing an agent runtime needs to model latency across the entire workflow, not sandbox by sandbox, or the isolation tier that looks fine in a single benchmark will fall apart once it's chained fifteen calls deep.

Statefulness as an isolation requirement, not just a convenience feature

Kubernetes Pods and Deployments were built for stateless, replicated services, the kind where any instance can handle any request and nothing is lost if one gets killed and replaced. Agents don't work that way. An agent is a stateful singleton: it needs a stable identity across an entire task, storage that survives between steps, and lifecycle controls fine-grained enough to pause and resume a specific session rather than just scaling a replica count up or down.

Tear a sandbox down after every tool call, and the agent has to rebuild its entire context from scratch on the next one. That's wasted latency at best. At worst, on long-running tasks, it's a source of outright correctness failures, since context that isn't preserved is context the agent has to reconstruct, imperfectly, from whatever traces got logged.

Three things need to hold for stateful isolation to actually work. First, a persistent filesystem inside the sandbox boundary, one that doesn't leak state out to other sandboxes but does survive from one agent step to the next. Second, session identity: when the agent returns to its sandbox, it needs to be the same logical environment, not a fresh clone that happens to look similar. Third, snapshot-based suspend-and-resume, so the agent picks back up exactly where it left off, in-memory state included, without re-running steps it already completed.

Firecracker's snapshot-restore, resuming in the 5-to-30-millisecond window Northflank documents for snapshot-restore, is what makes indefinite-duration stateful agents practical without giving up isolation to get there. A sandbox that leaks state between sessions, through a shared volume, a cached credential, leftover files on disk, undermines isolation even when the kernel boundary itself is airtight. Teardown has to be deterministic and complete, or the strongest kernel-level guarantees in the world don't matter.

That has a real consequence for how these systems scale. Horizontal scaling for agents doesn't mean spinning up more copies of a stateless handler the way a web service would. It means supporting more concurrent sessions, and each session holds open connections to an LLM, carries complex in-memory state, and can consume a meaningful chunk of memory on its own, independent of every other session running alongside it. Scaling an agent fleet is closer to scaling a database than scaling a stateless API, and the infrastructure underneath has to be built with that in mind.

How the platform landscape operationalizes these isolation choices in 2025–2026

Once the primitives are clear, reading platform marketing gets a lot easier, because "isolated" stops being a marketing word and starts being a specific, checkable claim: is the runtime underneath gVisor, Firecracker, or a hardened container, and does the vendor state this directly?

On the Kubernetes side, Google's GKE Agent Sandbox, introduced at KubeCon in November 2025, adds a new CRD and Operator for running stateful, isolated agent workloads through a declarative Kubernetes API. It's built on gVisor by default, with Kata Containers available as an option for teams that want full VM-backed isolation instead. The underlying project, kubernetes-sigs/agent-sandbox, is backend-agnostic, supporting both gVisor and Kata, and GKE offers it at no extra charge beyond standard GKE resource pricing. That same upstream project, launched at KubeCon Atlanta, introduces the Sandbox CRD as a new primitive in Kubernetes itself, along with WarmPools for pre-warmed pods, configurable shutdown timing, and a Python SDK. It's already usable in production, and its existence, alongside Google's, is itself a signal: the Kubernetes community has more or less agreed that the standard Pod abstraction doesn't fit agent workloads, and rather than forcing agents into it, the ecosystem is building a new primitive around them.

Cloud-managed sandboxes have moved fast too. Azure Container Apps Sandboxes entered public preview on June 2, 2026, under the resource type Microsoft.App/SandboxGroups, offering per-sandbox microVM isolation, sub-second startup, snapshot-based suspend-and-resume, OCI image support, network egress controls, managed identities, and scale-to-zero billing. It pairs with a policy-enforcement toolkit for host-side rule enforcement, and a public-preview compose feature for agents lets teams declare models, agents, and tools in one compose file, with native integration into an identity service and a cloud resource management platform. Amazon's Bedrock AgentCore, generally available since October 2025, takes a framework-agnostic approach, running LangGraph, CrewAI, LlamaIndex, Google's ADK, OpenAI's Agents SDK, and Strands Agents on infrastructure built around deterministic policy enforcement.

A separate tier of dedicated sandbox platforms has grown up alongside the hyperscaler offerings. Northflank runs microVM isolation through Kata Containers and gVisor, with GPU options up to H100, H200, and B200, bundled into a fuller platform that also covers databases, APIs, and CI/CD, at what it lists as the lowest published CPU rate among surveyed platforms. Vercel Sandbox went generally available on January 30, 2026, running on Firecracker microVMs with session state management aimed at agent workflows, support for up to 2,000 concurrent sandboxes on its Pro tier, and active-CPU billing at $0.128 per vCPU-hour, a cost structure that rewards spiky agent traffic and penalizes sandboxes left idle but hot. Fly.io's Sprites, launched January 2026, also offer microVM-based isolation, persistent by default with 100GB of NVMe storage per sandbox, and the product argues directly against the ephemeral model, on the grounds that rebuilding state from scratch wastes latency the agent didn't need to lose. Cloudflare Sandbox, launched April 2026, offers persistent isolated Linux environments with active-CPU pricing and snapshot-based session recovery, aimed at teams already running on Cloudflare Workers. Microsandbox takes the self-hosted route: microVM isolation through libkrun, sub-200ms startup, built for teams that want full control over untrusted code execution without depending on a managed service.

Read across this landscape and the throughline from the earlier sections holds: every platform here is making the same tradeoff, choosing a point on the spectrum between isolation strength, cold-start latency, and statefulness, and the right choice depends entirely on the workload sitting on top of it. An agent running short, bursty tool calls has different needs than one holding a long-running session open for hours. The primitives, gVisor, Firecracker, Kata, hardened containers, Wasm, haven't converged on one winner because the problem itself doesn't have one answer. What's changed, over the past year or so, is that the infrastructure to make that choice deliberately, rather than by default, now actually exists.