What a microVM Is, and Why Agent Sessions Run in One

A microVM is a virtual machine stripped down to the minimum needed to run a single workload: its own guest kernel, its own memory, and a small fixed set of virtual devices. It keeps the hardware-enforced isolation of a full VM and drops the generality, so it boots in a fraction of the time.

Container, VM, microVM — the three get used as if they were interchangeable, and they are not. The difference decides how much of your host an untrusted process can reach, how fast you can start it, and what it costs you to keep running. This is the plain version: what a microVM is, how it gets fast, and what it takes from you in return.

What is a microVM?

Start with what a classic virtual machine does. It emulates a whole computer — firmware, a broad set of virtual hardware, a boot sequence, the works. That generality is the point when you run arbitrary operating systems with unpredictable hardware expectations. It is also expensive: slow boot, large memory footprint, wide emulated device surface.

A microVM keeps the one property you actually wanted from the VM — a real, hardware-enforced virtualization boundary — and throws out nearly everything else. It exposes a small, fixed set of virtual devices, skips legacy hardware emulation, and boots a minimal guest kernel directly. What remains is a genuine virtual machine sized for exactly one workload.

The best-known implementation is Firecracker, an open-source virtual machine monitor written in Rust, originally built at AWS to back Lambda and Fargate and released under Apache-2.0. Firecracker runs on KVM, the virtualization layer built into the Linux kernel, which in turn relies on the CPU's virtualization extensions — Intel VT-x, AMD-V/SVM. It deliberately implements a minimal device model: fewer emulated devices means less code between the guest and the host, and less to bring up at boot.

Two properties carry everything below, so state them plainly.

The boundary is enforced by hardware. Separation between guest and host comes from KVM and the CPU, not from a shared operating-system kernel that both sides are trusting to behave. For code inside to reach the host it has to break the guest kernel and defeat the virtualization boundary underneath it.

The footprint is small. A minimal device model, a minimal guest, no general-purpose boot path. This is why microVMs became the substrate for serverless platforms: a hard boundary between many small, untrusted workloads, cheap enough to run one per workload.

So a microVM is not "a lighter container" and not "a faster VM." It is a real VM with the generality cut away. If the comparison you care about is the one against containers, we wrote that up separately as microVM vs container isolation.

Why boot time is measured in milliseconds

Everyone repeats the milliseconds claim. Almost nobody says where the milliseconds come from. There is no trick: three things a microVM does not do, and one it can.

It skips firmware entirely. No BIOS or UEFI, no bootloader, no bus walk to discover what hardware exists. The VMM loads an uncompressed kernel image straight into guest memory, sets the registers, and jumps to the entry point. Much of a classic VM's startup is code whose only job is to work out what machine it is on. A microVM already knows.

It has almost nothing to emulate. A handful of virtio devices — a block device, a network interface, a serial console — and little beyond. Each one must be created, wired up and probed by the guest at boot, so a short list is a short boot. The minimalism that shrinks the attack surface shrinks the startup path: the security argument and the speed argument are the same argument.

The guest is built for the job. A minimal kernel configuration and a small userspace, not a general-purpose distribution running a full init sequence with services nobody asked for.

And memory state can come from a file. This is the part usually left out. A running VM can be captured as two artifacts: a memory file holding guest RAM, and a compact state file holding vCPU registers, interrupt controller state and the state of each emulated device. Restoring it does not require reading that memory file into RAM first. The VMM can map it and let pages fault in on demand — with userfaultfd, the Linux facility for resolving page faults in userspace, the guest starts immediately and each page arrives when first touched, so latency tracks the working set rather than the configured RAM. And because the memory image is a file, several microVMs can start from the same one, sharing unmodified pages and copying only where they diverge.

One note on the numbers, one on us. The Firecracker authors published theirs in Firecracker: Lightweight Virtualization for Serverless Applications (NSDI '20): 146 ms at the 99th percentile for a pre-configured Firecracker microVM — one vCPU, 256 MB of memory, a minimal kernel and root filesystem, timed from forking the VMM process to the guest kernel forking its init, 500 samples on AWS hardware. Those are their measurements on their machines, not a benchmark of our platform, and the real figure depends on hardware, memory backend and working set. And pausing a running session to resume it later is on our roadmap, not in production: the mechanics above explain why fast start is achievable, they are not a feature you can call today.

microVM vs traditional VM

If a microVM is a virtual machine, why not just use an ordinary one? Because a classic VM charges you for generality you do not need. Same class of isolation, very different bill.

The row that matters is the first one. A microVM does not weaken the isolation to buy the speed — the boundary is the same mechanism the classic VM uses, and the same one your cloud provider already bets its own multi-tenancy on. What gets removed is the emulated hardware platform around it, and everything else in the table follows from that one decision. The same paper puts a number on that removal: around 3 MB of memory overhead per Firecracker microVM against around 131 MB for QEMU, measured per microVM and independent of the memory configured for the guest.

The corollary: a microVM is a bad fit whenever the generality was the point. Run a desktop OS, an application that expects a particular device, or a system you cannot rebuild for a minimal kernel, and the classic VM is doing something the microVM deliberately cannot.

What a microVM costs you

Most write-ups tell you what microVMs give you. Here is what they take.

Memory overhead, per workload. Every microVM carries its own guest kernel and its own VMM process. A container is a process on a kernel already running and already paid for. The monitor's own share of that is small — around 3 MB per microVM in the paper's measurement — but the guest kernel is charged on top of it, once per workload, and it never amortizes: a hundred microVMs means a hundred resident kernels.

No shared page cache. This is the cost people discover late. Containers on one host share the host's page cache: a language runtime read by ten containers is cached once. Ten microVMs have ten guest kernels and therefore ten page caches, so the same bytes are held ten times over. The boundary that stops one workload observing another also stops them sharing anything useful for free, and memory is where that shows up first.

Cold start is milliseconds, not microseconds. Fast compared to a VM is still slow compared to starting a process. There is a kernel to boot and a userspace to bring up, per workload, every time. If your pattern is one short invocation per request, you pay it repeatedly — which is why so much engineering effort here goes into not cold-starting at all.

Density and operations. Fewer workloads fit on a host at the same RAM budget. And you now own a guest kernel: configuring, patching and tracking it is work a shared-kernel setup hands to the host operator.

None of this argues against microVMs. It is the price of the boundary, worth stating because this is a trade and not an upgrade. For first-party code you trust, a container is usually the right answer — we compared that path directly in our write-up on Docker sandboxing. The calculus changes when the code is not yours.

Why microVMs fit autonomous agents

Autonomous coding agents are close to a worst case for a shared-kernel model, which is what makes them worth the price above.

The code is effectively untrusted. An agent generates code and runs it, installs packages, makes tool calls, often with nobody watching each step. Even a well-behaved agent can be steered by a prompt injection hidden in a file, a web page or a dependency it pulled in. You are not primarily defending against a malicious user; you are defending against unpredictable behaviour from software nobody wrote line by line. A boundary that assumes the workload might turn hostile is the correct default, and a per-workload hardware boundary is that default.

The tenancy is real. Different projects, different customers, different trust levels on shared infrastructure — "which kernel are they sharing" becomes the whole question. With one microVM per session they share no kernel at all.

The economics run the other way from serverless. Serverless functions live for milliseconds, so per-invocation start cost and memory overhead dominate and every millisecond is fought over. An agent session runs for minutes or hours. The same overhead, amortized over that span, is close to noise — the microVM tax is cheapest exactly where the isolation matters most. That is the inversion worth noticing: the workload that most needs the boundary can most easily afford it.

Isolation is necessary and not sufficient. A microVM stops code from escaping to the host. It does nothing on its own about exfiltration. A compromised agent that can reach the open network will send your data out through a connection nobody blocked, and the hypervisor does not filter packets — that is a separate control on a separate layer. Credentials are the same story: a hardware boundary around the process says nothing about how a secret reaches the workload inside it, which is its own design decision on its own layer. Treat the microVM as the foundation, not the building.

Where ainclave fits

At ainclave, one microVM per agent session is the design, not a configuration option — a Firecracker microVM on KVM, its own guest kernel, never a shared container. Untrusted agent code is confined by hardware rather than by a kernel shared with other tenants.

That boundary is the base layer. On top of it, egress is deny-default and enforced on the host datapath rather than inside the guest, filesystem policy and the syscall filter are fixed when the session is created — that seccomp filter is a targeted set of blocks rather than a full allowlist, a limit we would rather name than leave implied — and credentials are stored as vault references. The full stack, including the parts that are not finished and the limits we are not going to hide, is written up in how the boundary is enforced — including the open one. Proxy-bound credentials — the model key you bring, source-control tokens, tokens for remote MCP endpoints — reach the agent process only as placeholders: the environment variable inside the guest carries a reference, the real bearer token is substituted on the outbound request, and only the destination server sees it. What is not enforced today is a process boundary between the agent and the proxy inside the guest, and we say that rather than let the mechanism sound finished.

If one microVM per session is the boundary you are weighing for your own agents, we would rather hear the requirement than assume it. The design partner programme is where a small number of teams work that out with us.

Last updated: 5 August 2026.