Why your microVM sandbox solves a particular problem very well, but not the agent security problem.
And why its important we outline the difference
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.
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.
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.
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.
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.
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.
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.
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.
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 block devices and whole disk images - you attach a disk, the guest owns it. That’s an all-or-nothing grain. There’s no natural way to say “this workload may read src/ but not secrets/, may open a socket to api.github.com but nothing else, may write to the project directory but treat ~/.aws as off-limits.” That sentence isn’t expressible at the hypervisor layer, because the hypervisor isn’t watching file opens or outbound connections. It’s watching a virtual machine.
An agent sandbox should work in exactly that grain, because that grain is the problem. The interesting decisions are per-path and per-host: which files, which directories, which domains, which syscalls. That’s not a refinement of what a microVM does - it’s a different layer entirely. You enforce it by mediating the operations the process attempts (the file it tries to open, the host it tries to reach), not by virtualizing the hardware underneath it.
Why “just use a VM” keeps getting suggested anyway
Because for the escape problem, it’s the right answer, and the escape problem is real in some setups. If you’re running genuinely adversarial code, or multiple untrusting users’ workloads on one host, you want that guest/host boundary. But the real threat from Agents is not just detonating malicious code or releasing a hackers payload, it can of course be that, but it’s also something far more sublime - intent. At present, a lot of the damage being caused by agents, is often with good intent - the coding agent who deletes the production database or POSTs private information into a GitHub repository, has not be purposed to do so by nefarious forces - it just happened to predict tokens in the sequence that resulted in the database being deleted.
So the honest version of this whole argument: these layers compose. Put the agent in a microVM and constrain its capabilities inside that VM. The microVM handles “don’t escape to the host.” A capability sandbox like nono.sh handles “you can access x, but not y, when z is true.”
What the capability boundary actually looks like
Concretely, the agent-containment layer is doing things a hypervisor never attempts:
Per-path file decisions. The repo is readable; ~/.ssh and ~/.aws are not - even though every one of those paths is sitting on the same filesystem the agent can see.
Per-host network decisions. Outbound connections go to an allow-listed set of domains; everything else is refused at the point the connection is attempted, not after a packet capture tells you it happened.
Credentials the agent never holds. The agent makes an authenticated API call without the real key ever entering its memory - a token stands in, and the real credential is substituted after the request leaves the sandboxed process.
An audit trail the agent can’t write. A log produced by the process you don’t trust is a story that process tells about itself. The decisions worth recording - what it opened, what it reached for, what was denied - have to be recorded by something outside the agent, or they’re worthless the moment the agent misbehaves.
None of that is virtualization. All of it is the actual agent threat model. A microVM gives you a strong wall around the room. It says nothing about what the agent does with everything you had to leave in the room with it.
So if you’re running agents, ask which problem you’re actually solving. If it’s “keep untrusted machines off my host,” a microVM is the right tool and you should use it. If it’s “this agent runs as me and I need to bound what it can touch in sometimes complex policy that needs to compose “ - which, for most people wiring an agent into their own production environment, is the real worry - then the microVM isn’t the answer to that question. It’s the answer to a different one.
Use both where both apply. Just don’t let the boot-time-in-milliseconds feeling convince you the containment problem is solved. The agent is still in the room with your keys.
nono is an open-source, kernel-level sandbox for coding agents - per-path file, socket, env var, per-tool fine grained kernel based isolation control nono.sh