Why your microVM sandbox solves a particular problem very well, but not the agent security problem.
decodebytes
SubscribeSign in
Why your microVM sandbox solves a particular problem very well, but not the agent security problem.<br>And why its important we outline the difference
Luke Hinds<br>Jun 21, 2026
Share
Putting a coding agent inside a microVM feels like the responsible move. It boots in milliseconds, it’s isolated from the host, and when a npm install postinstall hook starts poking around the filesystem, the instinct is to call it contained, as it very much is - but contained is actually what matters least for the thing most people are most worried about.<br>Right now microVM and an agent sandbox have become conflated terms - like they are the same kind of thing, maybe they are to some of us, but positioning them so is leaving a good 80% of the current concerns agents bring - off the table.<br>Different strokes, for different hosts
A microVM gives you a guest/host boundary . The question it answers is: can code running inside this virtual machine break out and affect the host or other tenants? The threat model is a hostile guest trying to escape its virtualized hardware - escalating through the kernel, the device emulation layer, or the hypervisor itself. MicroVMs are very good at this. It’s why they underpin serverless platforms where you’re packing thousands of mutually distrustful workloads onto shared hardware. The boundary is between machines and its as strong as it gets - I honestly am a big fan, and can nerd out on firecracker , gVisor if given the time.<br>But , and its a big but - an agent sandbox requires a capability boundary . The question it answers and problem it solves is different: this code runs as me , with my credentials, my SSH keys, my filesystem, my cloud tokens - so the threat isn’t escape, it already has its coffers on the good stuff. The agent isn’t trying to break out of anything. It’s running exactly where you put it, with exactly the privileges you have, and the danger is everything it can legitimately reach while doing so is fair game.<br>These are not the same question. And here’s the part that trips people up: putting the agent in a microVM answers the first question without touching the second.<br>What the microVM doesn’t see
Drop your agent into a freshly booted microVM and you still have to give it something to work on. Your repo. Often some credentials, because the agent needs to push a branch or call an API and many different powerful CLI tools and their configuration files, secrets and highy granular varied capability. An agent might need git so it can push, and git requires ssh as a transport, which in turn has access to ~./ssh keys. The moment you mount those in, they’re inside the boundary with the agent.<br>The hypervisor has no opinion about any of it, and why should it, it was not built to deal with that as a problem. It isolates the VM from the host; it does not arbitrate what a process inside the VM. To the microVM, “the agent reads your repo” and “the agent reads the .env next to your repo and exfiltrates it to a webhook” are the same kind of event - ordinary file access by the workload it’s hosting. Both happen entirely within the guest. Nothing escaped. The boundary was never breaking free of, because the data was already on the inside.<br>This is the core mismatch. A microVM is built to stop a machine from escaping. The agent threat is mostly not escape - it’s a trusted-by-default process, delegated with authority (to be useful in a role) with access it was handed to act sometimes on behalf of a human, but mostly as a service. A prompt injection that convinces the agent to curl your AWS credentials to an attacker doesn’t escape anything. A compromised dependency’s install hook reading ~/.ssh/id_rsa doesn’t escape anything. They operate comfortably inside the box you built, because you had to put the valuable things in the box for the agent to do its job.
And most of the time there’s no attacker involved at all . The damage a coding agent does is rarely malicious. It doesn’t drop the production database or paste a secret into a public issue because it has decided to cause harm — it does those things because it misread the task, took an overconfident shortcut, or followed a plausible-looking instruction somewhere it shouldn’t have, and then it explains what went wrong in a calm, apologetic summary after the fact. The failure mode is a capable, well-meaning process making a confident mistake with real access and real credentials. That is a different shape of problem from the hostile-guest model a microVM is designed around, and it’s the far more common one. The boundary you need isn’t one that assumes the workload is trying to break out; it’s one that limits the blast radius when a trusted workload simply gets it wrong.<br>Granularity is the whole point
The deeper issue is what unit of isolation each tool works in. A microVM isolates a machine. Its native vocabulary is...