Sandboxing AI agents: Building a microVM<br>Metadata<br>authorNikhil Unni<br>published2026-07-09<br>read_time9 min

On this page

Tags<br>engramssoftware-factoriesai-agentssandboxingfirecrackermicrovms

Sandboxing AI agents: Building a microVM<br>Your AI agent is about to run rm -rf and curl | sh. Let's build a microVM for it to run in, directly in your browser.

Why an AI agent needs a sandbox

An AI coding agent is, by design, a thing that runs commands you didn’t write.

The security implications are horrifying! Exploits can be as “mild” as rm -rf / up to<br>hijacking your employee credentials. Despite strides in recent frontier models where<br>complete slipups are rarer, the agent is still a black box — and impressionable to prompt injection<br>from the outside world.

Typically, coding agents deal with this in two ways:

Explicitly ask the user if the command or class of command is safe to run, every time it wants to run something

Have the user upfront allowlist commands or classes of commands.

Both approaches are non-starters for a true software factory, where<br>we want to scale out to thousands of agents, with as little human intervention as possible.

There is a combinatorial explosion in the space of all possible commands (up to length n), and a similarly<br>massive space of all “good” and bad” commands (if that’s even well defined) such that we cannot possibly<br>allow / deny a flat set of commands up front.

note Newer approaches, like Claude Code’s “auto mode” purport to solve this problem with a secondary classifier that decides<br>if a command is safe to run, before actually running it.

While this is a step in the right direction in terms of user experience, it is<br>still a black box. From a security standpoint this is no better posture than --dangerously-skip-permissions,<br>as it can still non-deterministically run “bad” commands.

The solution at scale is to give each agent its own sandbox: a real throwaway Linux box it can wreck, with<br>strict egress policies to prevent exfiltration. Treat each agent as potentially adversarial and eliminate<br>the blast radius completely by completely limiting what I/O it is permitted to do:

If it wants to run rm -rf /, by all means go ahead

If there’s a supply chain attack in NPM, that’s fine — it literally cannot pull new packages

Firecracker and MicroVMs

The agent runs untrusted commands, so the sandbox has one job: contain the blast radius. Your<br>options:

A container shares the host kernel. A kernel bug or a --privileged slip and the agent<br>is loose on the host — and on every other agent’s files. Fine for code you trust; wrong<br>threat model for code an LLM just wrote.

A cloud VM isolates hard, but boots in tens of seconds and bills you for every idle<br>minute. You can’t spin one up per agent-task and stay solvent.

A microVM is the middle path: a stripped-down VM with a minimal device model that boots<br>in ~125 ms, isolated by the same hardware virtualization a full VM uses. It’s what<br>Firecracker — the engine under AWS Lambda — was built for.

Firecracker is a virtual machine monitor (VMM) that is extremely lightweight, and what many<br>platforms, including our own software factory, engrams, use to cheaply spin up microVM sandboxes<br>at scale.

It uses Linux KVM, an open source kernel module that exposes the hardware virtualization features of<br>modern CPUs to user space.

Where Firecracker shines over hypervisors like QEMU is that it has a minimal device model, and does not emulate a full PC.<br>It only exposes the devices that are necessary to run a Linux guest, such as a virtual CPU, memory, and a few essential devices like a serial console and network interface.

This allows Firecracker to run microVMs with minimal overhead and very fast boot times,<br>making it ideal for quickly spinning up and tearing down microVMs.

Let’s build a microVM

A major motivation for building engrams for us is understanding every moving part of software factories<br>deeply.

While engrams uses Firecracker directly, as it’s production hardened and secure, I wanted to understand how it<br>actually worked under the hood, so that it feels less like magic, and wanted to share those learnings with you all.

This presented a bit of a pedagogical challenge for me, as viewers at home may not have machines with KVM enabled<br>machines to follow along with the code snippets.

So embedded in this article is a live playground that runs a Linux kernel on a software CPU, with toy KVM implementation<br>to illustrate the concepts. Each snippet is editable + runnable, so roll up your sleeves and let’s get virtualizing!

sandbox — microVM · v86 ▶ Boot the microVM idle

host<br>A real Linux kernel + ext4 rootfs, booted in your browser via a software CPU<br>(v86).

note Everything in this post runs live, right here. It’s a real Linux kernel on a software CPU<br>(the v86 emulator) — you can boot it, type in<br>it, and compile C in it. It’s genuinely Linux; it just isn’t hardware-isolated the way the<br>real thing is.

By the end, the whole sandbox reduces to four moving...