Every agent framework eventually reaches the same moment: the model wants to run code. A shell command, a Python snippet, a package install. And the moment you allow that, you have a security problem that is not theoretical, because the input to that code is a language model's output, and the model's input is whatever a user typed or a web page contained.
The usual first answer is a container. It is fast, it is familiar, and it is the wrong boundary for this threat model, for a reason that has nothing to do with containers being badly built. A container isolates namespaces, not the kernel. An agent that finds a kernel bug is not contained, it is escalated.
So teams move to microVMs, and then discover the second problem: cold start. The isolation you need costs latency you did not budget for.
Part One: What the boundary actually costs
Published numbers from the Firecracker project put microVM boot at around 125 milliseconds, and that is with a minimal device model and a purpose-built VMM. A general-purpose VM boot is measured in seconds to tens of seconds. A warm container start is single-digit milliseconds; a cold container start with an image pull can be hundreds.
The interesting number is the snapshot path. Restoring a pre-booted microVM from a memory snapshot lands around 140 milliseconds end to end including the API call, and most of that is orchestration overhead rather than kernel boot. That is the number that makes microVMs viable for interactive agents, because 140 milliseconds is below the threshold where a user notices.
But cold start is only half the cost. The other half is density, and density is where the economics live.
Part Two: The density arithmetic
On a host with one terabyte of usable memory, running 512 MB sandboxes with 15% headroom, you can fit roughly 1,600 sandboxes if the per-sandbox overhead is 55 MB, and roughly 620 if the overhead is 130 MB. Containers, with 8 MB of overhead, get you past 900 before the arithmetic becomes about CPU rather than memory.
The gap between 620 and 1,600 is the difference between a sandbox costing 1.6 cents an hour and 0.6 cents an hour on the same hardware. For a product that runs one sandbox per agent session and charges per session, that is the entire gross margin.
Two things move you toward the good end of that range. First, snapshot pools: keep a set of pre-restored microVMs ready, and hand one out on demand. The memory is shared through page cache, so the marginal cost per pooled sandbox is small. Second, keep the guest image minimal — no package manager, no shell you do not need, a single static binary as the entrypoint. Every megabyte of guest image is a megabyte you pay for on every restore.
Part Three: What people get wrong
Three mistakes show up repeatedly.
Treating the sandbox as a place to install things. The moment an agent runs pip install, your minimal image becomes a general-purpose image, your boot time triples, and your attack surface includes a package registry you do not control. Pin dependencies into the image at build time, and give the agent a fixed tool surface.
Sharing a sandbox across sessions for speed. Reuse feels efficient until one session leaves state behind that another session can read. Sandboxes are cheap; cross-tenant data leakage is not.
Forgetting the network. The most common escape route from a sandbox is not a kernel bug, it is the sandbox calling out to a metadata endpoint or an internal service. Egress policy belongs in the sandbox design, not in a later security review.
Part Four: The three-tier answer
In practice, the right design has three tiers, and you route by trust rather than by convenience.
Tier one is a warm container, used for code you wrote and the model merely parameterises. Template rendering, arithmetic, format conversion. No arbitrary execution, so no isolation boundary beyond the process.
Tier two is a microVM with a snapshot pool, used for model-authored code. This is the default for anything that runs a command. Restore in ~150 ms, one session per sandbox, no reuse.
Tier three is a dedicated VM or a separate account, used for anything that touches credentials, the filesystem outside the sandbox, or the network beyond an allowlist. Slow, rare, and the only tier allowed to hold a secret.
The routing rule is the important part. Most teams build one tier and then argue about whether it is safe enough for everything, which is a question with no answer.
Part Five: The cost model that survives contact
Build the model per thousand sessions, not per sandbox. A session that runs for ninety seconds on a tier-two sandbox costs the restore plus ninety seconds of a 1/32 vCPU share plus its memory share. At the numbers above that lands under a tenth of a cent, which is smaller than the token cost of the model call that generated the code.
That comparison is the whole argument. Sandbox isolation is cheap relative to inference, and teams that skip it are optimising a line item that is already noise. The expensive failure is not the extra 130 MB of overhead, it is the incident where an agent with network access and a shared filesystem did something you cannot walk back.
The pattern generalises beyond agents. Every system that executes input it did not author faces the same trade: a fast boundary that shares a kernel, or a slower boundary that does not. The correct answer is not a religion about containers versus VMs, it is a policy that routes by trust and a cold-start budget that makes the safe option the default one.
SOL: HCqPmPJM3NVtS6YrmVaTZYnuP8XZ2PFgQZKT94VK1LkS
Creating this takes real effort — thank you for the support.
