TL;DR: When agents run untrusted code, isolation controls spread. Compare shared-kernel containers, userspace sandboxes, microVMs to limit blast radius.

A microVM, such as those booted by Firecracker, gives each untrusted workload its own kernel and a minimal device model, so a compromise stays inside the guest rather than reaching the host. That’s a fundamentally different proposition from the shared-kernel container model, where a single kernel exploit can give an attacker root on the host and access to every other container. Even userspace-kernel sandboxes like gVisor narrow the attack surface, but they still sit above a shared host kernel. This article contrasts the three approaches and explains why microVM isolation is rewriting the rules for containing agent-driven code execution.

Understanding Blast Radius in Agent Code Execution

In any system that runs untrusted code, the blast radius is the set of resources a successful attacker can reach from the point of compromise. With agent workflows, an AI model might instruct an agent to download and execute a script, call an external API, or run a third-party tool. If that code is malicious or simply buggy, the damage depends on what the execution environment shares with the rest of the host.

Shared-kernel containers keep the blast radius wide. A container’s process runs in a namespace but still uses the host’s kernel directly. Any vulnerability in that kernel, or in the container runtime itself, can be leveraged to escape the namespace and gain host-level privileges. That means one agent’s bad payload could compromise every other container on the node, steal secrets, or pivot to the wider infrastructure. For a multi-tenant deployment or a platform that runs multiple customer agents, this is an unacceptable concentration of risk.

Shared-Kernel Containers: The Risk of Wide Blast Radius

Standard container runtimes like runc are fast and efficient, but they deliberately share the host kernel. This design choice prioritizes density and startup time over strong isolation. While Linux capabilities, seccomp filters, and AppArmor profiles can reduce what a container can do, they cannot eliminate the risk of kernel exploits. If an attacker finds a zero-day in the kernel’s network stack, all containers on that host are immediately at risk.

For agents running code, the threat model is especially acute. A model may generate an unpredictable sequence of system calls, perhaps including exotic ioctls or filesystem operations. Hardening the kernel helps, but it’s a continual cat-and-mouse game. The fundamental problem remains: the blast radius is the entire host kernel, and a single misstep can cascade.

Userspace-Kernel Sandboxes: A Tighter, But Still Shared, Boundary

A userspace-kernel sandbox like gVisor narrows the gap by inserting an intermediary. Instead of letting the container talk directly to the host kernel’s system call interface, gVisor’s sentry process intercepts all syscalls and implements a user-space kernel that handles them. Moreover, gVisor implements a reduced set of system calls, shrinking the attack surface dramatically.

However, the host kernel remains in the trust boundary. The sentry itself relies on the host kernel to enforce its own process isolation. A vulnerability in the host kernel could still allow an attacker who owns the sentry to escape. The blast radius is tighter than plain containers, compromise does not automatically grant root on the host, but it is not as confined as a hardware-virtualized microVM where the guest kernel and the host kernel are entirely separate entities managed by a VMM.

MicroVMs: Per-Workload Kernel Isolation

MicroVMs use hardware-assisted virtualization to give each workload its own kernel. Firecracker, an open source VMM from AWS, exemplifies this approach. By excluding unnecessary device models and guest functionality, Firecracker minimizes the attack surface that a guest kernel can target. If an agent’s code compromises the guest kernel, it is still trapped inside the VM. To reach the host, the attacker would need a further exploit in the VMM or the KVM subsystem, which are small, well-audited codebases compared to the full Linux kernel.

This isolation model transforms the blast radius. Even on a multi-tenant host, one agent’s breach is contained to its own microVM. Secrets accessible to that VM (mounted filesystems, environment variables) may be exposed, but other VMs and the host remain untouched. The overhead, compared to running a standard container, is modest; Firecracker’s team reports that the achievable container density should be comparable to kernel-based runtimes without the isolation compromise. For platform and security leads reasoning about containment rather than just permissions, microVMs offer a hard, hardware-enforced boundary that simply does not exist in the other models.

Operational Trade-offs: Performance, Density, and Startup Time

Choosing a microVM introduces different operational characteristics. Each microVM needs its own kernel image and memory allocation, which increases per-workload overhead relative to a shared-kernel container. However, Firecracker’s design focuses on keeping that overhead low. It boots with a single vCPU by default and supports memory ballooning, so unused RAM can be reclaimed. Startup times remain fast enough for many serverless and container orchestration use cases. Integration projects like Kata Containers and firecracker-containerd bring this isolation model deeper into existing container ecosystems, making it practical to bin-pack disparate workloads on the same metal while preserving strong isolation.

For teams already running Kubernetes, the operational impact is a mix of additional resource planning and updated runtime configuration. The benefit is a dramatic reduction in the blast radius for every untrusted agent. When a model-directed payload goes wrong, the incident stays small, and the mean time to recovery drops because you are only restoring a single microVM, not rebuilding a compromised host.

When to Choose Which Isolation Model

The right choice depends on your threat model and your tolerance for leftover risk. For internal tools where all code is vetted and the blast radius is already limited by trusted inputs, shared-kernel containers may still be acceptable. For multi-tenant platforms or any scenario where an agent runs third-party or AI-generated code, a userspace sandbox like gVisor provides a useful middle ground, better than nothing, but not a hardware guarantee. MicroVMs represent the strongest isolation short of dedicating physical hardware to each tenant. They are especially compelling when regulatory requirements or contractual obligations demand demonstrable separation between workloads.

In practice, many teams adopt a layered strategy: containers for trusted workloads, gVisor for semi-trusted ones, and microVMs for the truly untrusted agent-driven code. This graduated approach optimizes resource efficiency while keeping the blast radius tight where it matters most.

Frequently Asked Questions

Q: Does a microVM eliminate all risks from agent code execution?

No. A compromised guest kernel can still exfiltrate data accessible inside the VM, such as mounted secrets or network-accessible services. It can also attempt a breakout by exploiting the VMM or the hardware virtualization layer, though the attack surface is much smaller than that of a full Linux kernel. Defense-in-depth is still required.

Q: How does Firecracker compare to full virtual machines like QEMU/KVM?

Firecracker is a purpose-built VMM that strips away emulated devices (no VGA, no USB, no BIOS) to provide only the absolute essentials. This results in a faster startup, lower memory overhead, and a smaller trusted computing base. A full QEMU-based VM would offer similar isolation but with a larger attack surface and higher resource consumption.

Q: Can I run my existing Docker containers inside a microVM?

Yes. Projects like Kata Containers and firecracker-containerd allow you to launch OCI-compatible container images inside a microVM. The container’s root filesystem is packaged as a disk image or bind-mounted via the microVM’s kernel, preserving compatibility.

Q: What is the main performance penalty compared to runc?

The main overhead is the extra memory consumed by the guest kernel and the VMM process. CPU performance is near-native thanks to hardware virtualization support. Startup time is longer than a simple container but still measured in tens to low hundreds of milliseconds.

Further Reading