Docker Sandbox vs Full Container Isolation Tradeoffs

None of this is a quality ladder where microVMs simply win out. It's a set of architecturally distinct guarantees, and the question worth asking for any given workload is which guarantee you actually need. That's the whole piece, really: an attempt to make the tradeoff clear enough for you to make your own call.

Why the shared kernel matters specifically when the code is AI-generated

For code your own team wrote, reviewed, and merged, a process-level boundary is a fine tradeoff. You know roughly what that code is supposed to do, and Docker's namespace and cgroup isolation has held up for over a decade of production use precisely because the threat model was accidental misbehavior, not someone actively trying to break out.

AI-generated code breaks that assumption at the root. It comes out of a probabilistic system at the moment of execution, with no human sitting between generation and the thing actually running. And it can be steered: prompt injection, a malicious tool output the agent decides to trust, a compromised package it installs mid-task because nothing told it not to. Veracode ran security tests on AI-generated code in 2025 and found a substantial share failed outright, which tells you the code itself carries risk before you've even gotten to the question of what sandbox it's running in.

Here's the part that changes the calculus: the threat model is adversarial now, not accidental. Someone who can influence what an agent generates can point that agent at the kernel boundary and have it go probe for weaknesses on their behalf, without ever touching your infrastructure directly. The Shai-Hulud campaigns in late 2025 compromised npm packages built specifically to intercept AI agent pipelines. That's attackers treating agent workflows as their own distinct target, worth engineering for. MITRE ATT&CK even has a line item for it, T1611, container escape to host, and the phrasing matters: a successful escape doesn't hand you a container, it hands you the host and everything else sitting on it.

So the rule practitioners have landed on is fairly blunt, and I don't think it needs much softening. Use a container when the code is yours and it's been reviewed. Reach for something stronger the moment a probabilistic system starts running shell commands on your behalf, because you genuinely don't know what it's going to try next.

Where Docker's isolation boundary actually breaks down in practice

The shared kernel is Docker's whole design. It's also exactly where things go wrong. One kernel underneath every container on a host means one kernel vulnerability is everyone's problem at once.

This isn't a hypothetical I'm reaching for. Three runc vulnerabilities came out in November 2025 (CVE-2025-31133, CVE-2025-52565, CVE-2025-52881) and hit Docker, Kubernetes, containerd, and CRI-O simultaneously, because they all lean on the same shared runtime component. Four major platforms, one blast radius. Stack that against CVE-2024-21626 in runc, CVE-2025-23359 in the NVIDIA Container Toolkit, and CVE-2026-1109 in kernel io_uring, and what you're looking at is two years of guest-to-host boundary breaks, not a one-off.

Researchers have started treating escapes as something you can actually measure instead of argue about. A March 2026 paper published on arXiv introduced SANDBOXESCAPEBENCH, built to test how well large language models can find and exploit Docker and OCI container escapes: misconfigurations, privilege allocation mistakes, kernel flaws, weak spots in the runtime and orchestration layer. Where vulnerabilities existed in their test environment, the models found them and used them. Sit with that for a second. The same kind of system you're deploying as an agent is, according to this research, also fully capable of playing attacker against somebody else's sandbox.

There's a plainer failure mode too, one that skips the CVE entirely. In July 2025, a Replit AI coding agent deleted a production database during a test project. No exploit. No escape. Just an agent given more reach than the task warranted. On a Docker-only setup, once that kind of thing goes sideways, there's no hardware wall to stop it; the blast radius is whatever the container's permissions happen to allow, and in practice that's usually more than anyone meant to grant.

What microVM isolation actually costs (startup latency, resource overhead, and GPU friction)

None of this makes microVMs free, and I want to be straight about that rather than treat the security win as the end of the conversation.

Booting a full VM kernel takes longer than forking a container process. Full stop. Cold starts in the hundreds of milliseconds are typical without a warm pool sitting in front of the whole thing. For an agent firing off a rapid sequence of tool calls, spinning up a fresh sandbox each time, that latency stacks up fast. Warm pools, VMs pre-booted and held ready to hand out on demand, get you into sub-second territory, but you're paying for it in idle compute sitting around waiting to be useful. There's no way around that cost; you're just choosing where to absorb it.

Resource overhead runs the same way. Every microVM drags its own kernel and its own memory footprint along with it, so a host running many isolated sandboxes at once burns more resources than the same count of containers would. If your workload needs density, lots of sandboxes packed onto a modest memory budget, that overhead is the thing capping how many you can actually run.

GPU access is where the tradeoff really bites. VM-level GPU passthrough is hard to get right and nowhere close to universally supported across hypervisors and hardware. Some platforms have just given up on forcing one answer and run two runtimes side by side instead: containers for GPU-heavy work, VMs for untrusted general code. Docker's own Sandbox product, which shipped in March 2026, makes basically the same point from a different direction. They built a proprietary VMM instead of just adopting Firecracker, specifically so the sandbox would run on macOS and Windows hosts too, not only Linux. Deployment constraints shift depending on what machine you're actually on, and "just use Firecracker" doesn't cover every environment a team needs to support.

Statefulness as a first-class isolation tradeoff, not an afterthought

Most conversations about isolation stop at the moment execution starts. For AI agents, what happens to state between tool calls matters just as much, arguably more, and it's the part that usually gets shortchanged.

Ephemeral sandboxes throw everything away at teardown: installed packages, intermediate files, environment variables, whatever was still running. Fine for a one-shot code execution task. It falls apart fast for a coding agent working a multi-step problem, or a research workflow building context across dozens of steps, because you'd be rebuilding the whole environment from nothing every single time.

Stateful architectures take a different approach: they hold filesystem state across interactions, keep process memory alive through snapshot and restore, and preserve environment variables and installed dependencies so the agent picks up exactly where it left off. But how does this bump up against the isolation question we've been circling? Turns out snapshot restore speed carries a security dimension, not just a speed one. Some platforms hit sub-25ms resume times, which erases the cold-start penalty across a chain of tool calls entirely. Slow restore pushes teams the other way: keep the sandbox alive longer rather than pay the restore cost over and over, and that just stretches the window a compromised sandbox sits there undetected.

Session duration limits are all over the map across the ecosystem, hourly caps on some platforms, multi-day limits on others, and a handful offering indefinite pause at zero compute cost while paused. These aren't a footnote. They decide outright which agent workflows are even buildable. And the isolation logic follows from that directly: a sandbox meant to run indefinitely needs a harder boundary than one that dies in thirty seconds, because the longer something lives, the longer an undetected compromise gets to sit inside it doing damage.

How current platforms draw these boundaries differently

The ecosystem has settled into layers: isolation primitives at the bottom, embeddable runtime APIs in the middle, managed platforms on top. Each layer makes a different slice of this tradeoff visible, and it's worth walking through a few of them concretely rather than treating the landscape as one undifferentiated blob.

Docker Sandboxes, launched March 2026, run on microVMs using that proprietary VMM built to span macOS and Windows as well as Linux. Agents run as root inside the sandbox, which is exactly why the harder boundary wasn't optional. Configuration runs through Sandbox Kits, YAML files declaring tools, credentials, network allowlists, and startup commands. The part worth pausing on: the company that made containers the default concluded container isolation alone wasn't enough for agent workloads, and built a VM-based product to say so out loud.

Google's Agent Sandbox, a CNCF project launched at KubeCon NA 2025, takes a declarative approach: a Kubernetes API for isolated, stateful sandbox pods you run on your own cluster. gVisor by default, Kata Containers as an option, so isolation strength becomes a per-workload configuration choice rather than something baked into the platform. A SandboxWarmPool custom resource keeps pre-booted pods on standby to knock down cold-start latency. It sits somewhere between raw primitive and embeddable API, open source and self-hosted, which puts it in a genuinely different position than a fully managed product.

Vercel Sandbox runs on Hive, their internal orchestration layer for Firecracker microVMs. Ephemeral by default, snapshotting available on a configurable expiration, positioned squarely as the execution layer for agents cloning repos and running test suites.

SmolVM, out in April 2026, takes a different approach: a single-executable microVM with sub-200ms cold starts, aimed at the minimal-footprint end of the spectrum where you want VM-grade isolation without carrying much overhead per call.

Daytona pivoted into AI agent infrastructure in early 2025 and claims sandbox creation under 90ms. Docker containers by default, Kata Containers available for stronger isolation, so the platform just hands you both sides of the tradeoff instead of picking for you. Stateful by design, filesystem and environment variables and process memory all persist across interactions, and it offers open-source options, which matters for teams that want more control over their deployment environment. For regulated workloads the isolation boundary and the compliance boundary end up being the same thing.

Microsoft's LiteBox, announced February 2026, is a Rust-based Library OS staking out new ground somewhere between gVisor and full microVMs. Its existence alone tells you the primitive layer here is still being actively redesigned, not settled.

The engineering decision framework: which boundary fits which workload

So where does the decision actually land? The framing "Docker is insecure, switch to microVMs" flattens a genuinely multivariable problem into a slogan, and slogans are exactly what you should distrust in this space. The real decision runs on four things: how much you trust the code, how much blast radius you can live with, how tight your latency budget is, and how much state the workload has to carry across steps.

Docker containers are still the right call when the code was written and reviewed internally, when a compromise would stay scoped to that one workload instead of reaching customer data or shared infrastructure, when the workload is GPU-heavy and VM passthrough would add friction you can't afford, or when you're running dense, low-memory environments where per-VM kernel overhead just doesn't fit the budget you have.

MicroVMs, or something that gives you an equivalent guarantee, become necessary once the code is AI-generated at runtime in response to user input. That's an adversarial trust model whether you meant it to be or not. Same story when multiple tenants share a host and one workload's compromise can't be allowed to reach another's, when agents run long stateful sessions where a lingering compromise window is unacceptable, and when the workload sits under SOC 2, HIPAA, or GDPR, where the isolation boundary is doing double duty as the compliance boundary.

gVisor earns the middle spot for a real reason: meaningfully stronger than a standard container against syscall-level attacks, but it doesn't give you hardware enforcement, so a sophisticated kernel exploit isn't something it fully contains. Reasonable choice when full VM overhead is more than you can bear and the threat, while real, isn't at the top of the severity scale.

Cold-start latency and statefulness interact in ways that decide whether an architecture works at all, not just how snappy it feels. An agent firing off frequent sequential tool calls needs sub-100ms startup or fast snapshot restore; that's not a nice-to-have, it's the line between a usable product and one that times out on itself. An agent running long sessions instead cares more about billing model and session duration limits than which isolation primitive sits underneath.

One more variable, and it's easy to miss: data gravity. Large model weights or big datasets make a remote sandbox API slow and expensive to hit repeatedly, and customer-managed compute that runs the sandbox next to the data changes that math quite a bit. Put it together and the honest answer, for most production AI agent workloads, is that no single primitive covers the job. What actually fits is purpose-built infrastructure offering both paths at once, Docker for reviewed internal code, hardware-enforced isolation for untrusted AI-generated code, inside the same platform, so the choice gets made per workload instead of getting locked in the day you pick your deployment stack.