What is a microVM?

A microVM is a lightweight virtual machine that boots in milliseconds and uses a minimal device model, combining the strong hardware-level isolation of a traditional VM with the speed and density of a container. MicroVMs are used to run untrusted or multi-tenant workloads, including AI agents, with a security boundary that containers alone do not provide. Unlike full VMs, microVMs strip the device model down to only what the workload needs, which keeps both boot time and memory overhead low.

MicroVM vs container

Containers share the host kernel. That shared boundary is efficient, but it means a kernel exploit or privilege escalation can cross from one container into the host or into neighboring workloads. A microVM runs its own guest kernel behind a hypervisor, so the isolation boundary is enforced at the hardware virtualization layer.

The key differences:

• Isolation layer: Containers rely on Linux namespaces and cgroups. MicroVMs rely on a hypervisor (KVM or similar) and a separate guest kernel.
• Attack surface: A container breakout can reach the host kernel directly. A microVM attacker must first escape the guest kernel, then defeat the hypervisor.
• Boot time: Full VMs take seconds to minutes. MicroVMs (Firecracker, for example) boot in under 125ms, which is fast enough for on-demand workloads.
• Memory overhead: A microVM adds roughly 5MB of overhead per instance, compared to near-zero for a container process.

For workloads where the tenant or the code is untrusted, the stronger boundary of a microVM is the appropriate default, not an optional hardening step.

Why microVMs matter for AI agents

Autonomous agents that execute code, run shell commands, or call external APIs in production environments are a different class of workload than a stateless API handler. If the agent takes an unexpected action or is manipulated through its inputs, the damage it can do depends entirely on what its execution environment allows.

Running agent actions inside a microVM gives sandbox grants real enforcement. The boundary is not a software policy that a sufficiently privileged process can override. It is a kernel-level wall: the guest kernel inside the microVM cannot reach the host kernel without going through the hypervisor.

Concretely, this means:

• Scoped execution: The agent's filesystem, network, and device access is limited to what is mounted into the microVM at launch.
• Time-bounded: The microVM can be destroyed after the agent task completes, with no persistent state carrying over.
• Revocable: Because each microVM is isolated, a misbehaving agent can be terminated without affecting other workloads on the same host.

This maps directly to the sandbox grant model described in the Runtime Policy Patterns. A sandbox grant is only as strong as the enforcement layer beneath it. MicroVMs provide that layer. NOFire AI evaluates sandbox grant policies against the actual execution environment, including whether agent workloads run in appropriately isolated runtimes.

Common microVM technologies

Firecracker is the most widely deployed microVM monitor. Built by AWS and open-source under Apache 2.0, it powers AWS Lambda and AWS Fargate. Firecracker uses KVM and exposes only a minimal device model: a network device, a block device, and a serial port. Nothing else. That constraint is intentional: fewer devices means less attack surface.

Cloud Hypervisor is an alternative open-source microVM monitor developed under the Linux Foundation's Confidential Computing Consortium. It supports a slightly broader device model than Firecracker and is designed for cloud-native workloads.

urunc is a container runtime shim that integrates microVM execution with Kubernetes via containerd. Instead of running a pod in a standard runc container, urunc launches the pod inside a microVM (Firecracker or another backend). From Kubernetes' perspective, the pod is a pod. The isolation boundary underneath it is a hypervisor.

These technologies are not mutually exclusive. A platform team might run Firecracker as the VM monitor with urunc as the Kubernetes integration layer.

Performance considerations

The performance argument against microVMs is largely historical. Early virtual machine overhead was significant enough to make per-request VM instantiation impractical. MicroVM design specifically addresses that constraint.

Firecracker boots in under 125ms with approximately 5MB of memory overhead per VM. For a workload that runs for several seconds, 125ms of startup time is marginal. For agent tasks that run for minutes, it is negligible.

The tradeoffs that remain are real but narrow:

• Cold start sensitivity: If your workload must respond within tens of milliseconds from a cold state, a microVM adds latency that a container does not. Snapshot-and-restore techniques (Firecracker supports VM snapshots) can reduce this to single-digit milliseconds for warm paths.
• Density: A microVM requires its own guest kernel in memory. At very high container densities, the per-VM overhead accumulates. In practice, most AI agent workloads run at densities where this is not the binding constraint.
• Tooling maturity: MicroVM debugging and observability tooling is less mature than the container ecosystem. This gap is narrowing as adoption grows.

For multi-tenant or agent workloads where the security boundary matters, the performance cost of a microVM is small relative to the isolation benefit. The right comparison is not "microVM vs container at equal security." It is "microVM vs the operational cost of a security incident caused by insufficient isolation."

See the Runtime Policy Patterns to go deeper on how sandbox grants, execution boundaries, and policy enforcement work together in practice.