If you are building infrastructure for AI agents, you have inherited a brutally specific set of requirements. Every agent has to be strongly isolated from every other tenant. It has to start fast — ideally in single-digit milliseconds. And you need a lot of them: not tens or hundreds, but potentially millions for a single product.

Before you can satisfy any of that, you have to make one decision that quietly determines everything downstream: which isolation primitive do you actually run the workload in? It sounds like an implementation detail. It is not. It is the decision that shows up later as either a security incident or an eye-watering cloud bill.

And the industry’s vocabulary here is a mess. “Sandbox,” “container,” “microVM,” and “isolate” get thrown around as if they were interchangeable. They are not. They sit at wildly different points on the spectrum of security, performance and density.

A field guide to isolation primitives

Every isolation primitive is, in a nutshell, an answer to the same question: where do we draw the boundary between your code and everyone else’s? Push the boundary down toward the hardware and you get strong isolation but more weight. Push it up into shared software and you get speed and density, but the wall between tenants gets thinner — and thinner walls crack. Here are the primitives that actually matter, drawn as the layered stacks they really are.

• Virtual machine (VM). A full guest OS and your app, running on virtual hardware. The boundary is enforced by the CPU itself (VT-x / AMD-V) and policed by a tiny hypervisor: a thin software layer sitting directly between hardware and operating systems, allowing multiple OS instances to share the same physical machine (e.g., KVM, Xen, etc). This is the strongest commodity isolation we have. The classic complaint — heavy and slow to boot — is real, and it is exactly the constraint the rest of our work removes.
• microVM. A VM launched by a deliberately minimal Virtual Machine Monitor (VMM): a lightweight control layer that creates, runs and manages VMs — with Firecracker being the canonical one (in fact, the term “microVM” was coined by Firecracker to mean any VM launched by it). microVMs have the same hardware-enforced boundary as a VM, but with a stripped-down device model that boots faster and uses far less memory per instance. More on the “micro” misnomer below.
• Container. A process (or group of them) isolated with kernel features — namespaces, cgroups, seccomp. There is no guest kernel: every container on a host shares the host’s kernel. Brilliant for packaging and density. The boundary, however, is software, and it is enormous.
• Runtime isolation (isolates, JVM, …). Multiple tenants share one language runtime process — V8 isolates, a JVM, a Wasm host — separated only by the runtime’s own logic. The thinnest wall on the list, and the fastest to spin up. Wonderful for latency; precarious for multi-tenant security.
• …and the nesting dolls. Because none of the lighter options isolate well enough on their own, the industry stacks them: containers inside VMs (e.g., AWS ECS/Fargate), and — yes — isolates inside containers inside VMs. Each layer adds latency, memory and operational complexity to compensate for the layer above it not being trustworthy by itself.

So what, exactly, is a “microVM”?

Here is the part that trips everyone up. A microVM is just a VM launched with a minimalist Virtual Machine Monitor (VMM); initially the term was coined to mean VMs launched with Firecracker, these days I’ve also seen it used in conjunction with Intel Cloud Hypervisor. The “micro” refers to the VMM’s footprint — its lean device model and host-side memory overhead — not to the size of whatever you run inside.

This leads to the counterintuitive situation whereby you can take a 10 GB Ubuntu image, boot it under Firecracker, and by the industry’s own definition you are now running a “microVM.” Arguably there’s little “micro” about it…but I digress.

Why VMs? It comes down to the Trusted Computing Base

All the diagrams in the world don’t settle a security argument. This number does. The Trusted Computing Base (TCB) is the set of components a system’s security actually depends on — the code that, if it has a bug, can compromise everything.

“The trusted computing base (TCB) […] is the set of […] components that are critical to its security, in the sense that bugs or vulnerabilities occurring inside the TCB might jeopardize the security properties of the entire system. […] In order to reduce costs and security risks, the TCB should therefore be kept as small as possible.”

— Wikipedia, Trusted computing base

Keep that last clause in mind — as small as possible — and then look at what each primitive actually asks you to trust.

TCB / attack surface, to scale (lines of code you must trust):

• Virtual machine — ~250k lines (the hypervisor, e.g. KVM)
• Container — ~40M lines (container runtime + the entire host kernel)
• Isolate — ~47M lines (language runtime, e.g. V8/Node + the entire host kernel)

Look at the gap. A VM’s security boundary is the hypervisor: on the order of 200,000–250,000 lines. A container shares the host’s Linux kernel, so its boundary is ~40 million lines of C that every tenant on the machine can potentially reach through syscalls. An isolate stacks a language runtime on top of that kernel — ~47 million lines. That is more than two orders of magnitude more code standing between one tenant and the next. Note that these numbers are certainly rough, but I think paint a clear picture.

So as a (hopefully) fun exercise, what would you say the TCB is for a scenario showing an application inside an isolate inside a container inside a VM? (Yeah, I know, who in their right mind would do that??)

Perhaps counter-intuitively, the answer is just the hypervisor — the same ~250k lines as a plain VM. Everything above it — the container runtime, the guest kernel, the app — runs inside a VM. A container escape there only lands the attacker in their own VM; the hardware boundary between that VM and the host (or any other tenant) is never crossed. That is precisely why the big clouds wrap containers in VMs in the first place: to leverage the hypervisor’s relatively small TCB and contain a vulnerability’s blast radius.

A bigger TCB is not a stylistic preference. It is a bigger target, and a bigger probability that something in there is exploitable.

Theory? No — reality

You could read all of the above as an abstract argument about line counts. It isn’t. That 40-million-line shared kernel gets escaped from, in public, on a schedule. “Container escape” is not an exotic, nation-state-only event — it is a recurring class of CVE, and recently the cadence has picked up sharply. Here is a slice of just the last couple of years — and note the last one: by mid-2026, the most serious of these stopped being theoretical:

• CVE-2024-21626 — Leaky Vessels: container escape in runc and BuildKit gives access to the host filesystem.
• CVE-2024-1753 — Buildah / Podman build allows containers to mount host files, enabling escape at build time.
• CVE-2024-0132 — NVIDIA Container Toolkit TOCTOU vulnerability gives a container access to the host filesystem.
• CVE-2025-9074 — Docker Desktop privilege escalation and host filesystem access.
• CVE-2025-23266 — NVIDIAScape: NVIDIA Container Toolkit flaw leading to privilege escalation — a 3-line Dockerfile, CVSS 9.0.
• CVE-2025-31133 — runc masked-path race: an attacker replaces /dev/null with a symlink and tricks runc into bind-mounting arbitrary host paths.
• CVE-2025-52565 — runc /dev/console mount: insufficient validation allows write access to procfs before security protections activate.
• CVE-2025-52881 — runc procfs write-redirect: race with shared mounts redirects writes to arbitrary /proc files, bypassing LSM labels — full breakout. Actively exploited in the wild by mid-2026.
• CVE-2025-38617 — Linux kernel packet-socket use-after-free: only needs CAP_NET_RAW (obtainable via user namespaces) for a full container escape.

And this is not a 2024 phenomenon that someone will eventually “fix.” Container escapes have been a steady feature of the landscape for the better part of a decade, and the rate is trending the wrong way as namespaces, runtimes and GPU toolkits keep accreting features. Plotted by year, the trend doesn’t break in 2026, it hardens: the November-2025 runc trio (CVE-2025-31133 / -52565 / -52881) moved from disclosure to confirmed in-the-wild exploitation, affecting Docker, containerd and every major managed Kubernetes service. Escapes never stopped, 2024–2025 brought a fresh surge, and by 2026 the worst of them are being exploited for real.

None of this means containers are bad. They are an outstanding packaging and distribution technology — we love the OCI ecosystem, and we build on it directly. The point is narrower and more important: a shared-kernel container was never architected to be a hard multi-tenant security boundary, and the CVE record keeps proving it. So, bluntly: containers don’t contain.

Isolates go a step further in the wrong direction. They share not just the kernel but a single language-runtime process, so a bug in V8 or the host runtime is a bug in your tenant wall. Faster still, thinner still — and so, just as bluntly: isolates don’t isolate.

The verdict

Strip away the marketing and one primitive is left standing for hostile, multi-tenant workloads — the kind every AI-agent platform, and frankly any workload, should be now running. The virtual machine has a hardware-enforced boundary and a TCB two orders of magnitude smaller than its rivals. For isolation, it remains the gold standard in the cloud. A microVM is simply that same guarantee with a leaner VMM.

• VMs & microVMs — Hardware boundary, ~250k-line TCB. The right default when tenants don’t trust each other.
• Containers & isolates — Great for packaging and single-tenant speed; a soft boundary you patch forever for multi-tenancy.

There is, of course, a catch — the reason the industry reached for containers and isolates in the first place. The conventional VM is heavy: hundreds of megabytes, seconds to cold-boot, tens to maybe a hundred per server. For millisecond-scale, scale-to-zero, million-instance workloads, that is a non-starter. So people traded isolation away to get speed and density.

That trade is a false choice — and we have been saying so, with data, for the better part of a decade. Back in 2017, well before “microVM” was a marketing term, our team published My VM is Lighter (and Safer) than your Container at SOSP, the top operating systems conference in the world.

With the paper we set out to disprove the idea that VMs are fundamentally slow and clunky, and that containers were the fast and secure silver bullet — a hot take back then, much less so today. Our prototype booted a minimal VM in roughly 4 ms, against about 150 ms for a Docker container on the same machine — all without surrendering the hardware boundary. The “isolation versus efficiency” tradeoff many treat as a law of nature simply isn’t one.

So when we say the VM is the right primitive, it isn’t a vendor talking point we backed into — it’s a position we argued in peer-reviewed venues years before agent sandboxes made the question urgent.

The whole thrust of our work — from that research to the platform we ship today — is to keep the VM’s hardware isolation while beating containers and isolates at their own game: single-digit-millisecond cold starts, automatic scale-to-zero, and 1M+ VMs on a single off-the-shelf server. How we actually pull that off is the subject of the next post.

Notes & references

• Based on a talk given at AI Council SF, May 2026 (segment 1:22–8:13). Cold-start figures are representative ballparks for minimal guests and vary by configuration.
• TCB line counts are order-of-magnitude estimates: KVM ~200k–250k LoC; the Linux kernel tree ~40M LoC; Linux + V8/Node ~47M LoC.
• Container-escape CVE list compiled from public trackers including the container breakout vulnerabilities reference and the NVD. The timeline is a curated selection of notable, demonstrated escapes — not an exhaustive count.
• TCB definition quoted from Wikipedia, Trusted computing base.