TL;DR: Framing isolation as a change in trust model clarifies why microVM or userspace kernel boundary is the load-bearing decision when running untrusted agent

When an engineering team deploys an AI agent that executes model-directed code on a production host, the platform lead faces a stark question: what does our system need to trust? The answer shapes the entire security posture. Historically, running untrusted code meant trusting the host kernel to sanitize every system call, every memory access, and every interaction with devices. A single kernel bug-like the Dirty Cow privilege escalation bug, which allowed an attacker to gain control over a page of kernel memory by racing threads on a file in /proc-can collapse that trust. The shift toward microVMs and userspace kernel sandboxes changes the equation: the host no longer needs to trust the workload, only the thin virtualization boundary. That boundary becomes the load-bearing decision, not a feature toggle or a set of tool permissions.

The Trust Boundary Before MicroVMs

Before microVMs and userspace kernels, running untrusted code meant relying almost entirely on the operating system’s System API. The System API includes all the standard interfaces an application uses-system calls, traps, files, sockets, namespaces-everything derived from low-level kernel interactions. As gVisor’s security model explains (https://gvisor.dev/docs/architecture_guide/security/), this API is expansive and, despite being designed for application use, is a frequent source of exploitable bugs. Kernels and hypervisors, often written in C, are prone to race conditions and memory errors. An attacker, with nothing more than the ability to invoke the right system calls and control thread timing, can exploit flaws like Dirty Cow to cross from user space into kernel space, gaining full system access. The System ABI-execution paths not part of the intended API-and side channels further expand the attack surface. In this model, the platform must trust every line of kernel code that could be reached by the workload. For a team running agent code of unknown provenance, that trust is brittle and broad.

How MicroVMs Redraw the Line

A microVM, like Firecracker (https://firecracker-microvm.github.io/), and a userspace kernel sandbox, like gVisor, both reduce the attack surface by inserting a dedicated boundary between the untrusted code and the host. Instead of the workload directly calling the host kernel, it interacts with a minimal, purpose-built kernel inside a sandbox. Firecracker gives each microVM its own guest kernel and a stripped-down device model-just the emulated devices needed to run a single process-so that even if the guest kernel is compromised, the attack remains confined. gVisor achieves a similar result by running a kernel (the Sentry) as a user-space process on the host, coupled with a separate file proxy (the Gofer). In gVisor’s architecture (https://gvisor.dev/docs/architecture_guide/intro/), the Sentry handles system calls in the sandbox, and the Gofer provides file access via SCM_RIGHTS, so that even host-native files are mediated and can be shared across sandboxes without exposing the host’s file system directly. Both approaches mean the host no longer needs to trust the code running inside.

What Changes in Practice: A Look at gVisor and Firecracker

The resource model of a typical sandbox illustrates the operational shift. In gVisor’s resource model (https://gvisor.dev/docs/architecture_guide/intro/), the sandbox appears to the host as an opaque process, just like a virtual machine. Processes inside the sandbox do not manifest as host-level processes; inspecting them requires entering the sandbox. Networking runs an independent network stack, so the host sees only packets on the wire. Files can be backed by in-sandbox file systems-a tmpfs mount at /tmp or /dev/shm, for example-that allocate memory directly from the sandbox, accounted against sandbox-specific limits. Threads in the sandbox are modeled as goroutines, not host threads. This design means the host assigns memory and CPU to the sandbox as a whole, and the sandbox internally multiplexes resources, yielding them back when idle. The platform team can set resource limits that apply to the entire untrusted payload without needing to trust the payload’s own resource management. Firecracker takes this further by eliminating the host kernel’s visibility into the guest entirely, using KVM to create a hardware boundary. In both cases, the traditional attack surface of the System API is replaced by a narrow interface: for gVisor, the Sentry’s limited set of system call implementations; for Firecracker, the virtio-based device model and the KVM API. The platform’s trust now rests on a codebase orders of magnitude smaller than a full Linux kernel.

The Operational Choice: Trust the Boundary, Not the Workload

Defense-in-depth principles, as gVisor’s security model notes, remain essential; no single layer is perfect. Side channels-covert information leakage through resource contention-still exist and require monitoring. But the platform’s responsibility shifts from auditing every possible kernel exploit path to hardening the sandbox boundary itself. This is the load-bearing decision: invest in a microVM or userspace kernel proven to resist the classes of attack that routinely compromise monolithic kernels. It allows platform leads to safely host third-party agents, run user-submitted code, or deploy experimental AI tooling without risking the underlying infrastructure. The change is not a feature toggle-it is a fundamental re-architecture of trust.

Frequently Asked Questions

Q: How does a microVM differ from a traditional container in terms of trust?

A: A traditional container shares the host kernel, so the host must trust all kernel code accessible through the container’s system calls. A microVM has its own guest kernel and a minimal device model, so the host need only trust the virtualization layer (KVM and the microVM’s VMM), not the kernel running inside the container.

Q: Is a userspace kernel like gVisor as secure as a hardware-backed microVM?

A: gVisor’s security model is designed to provide defense-in-depth and reduce the attack surface by implementing a narrower set of system call handlers. It does not rely on hardware virtualization but on software isolation. Whether it is “as secure” depends on the threat model; both approaches shrink the trusted computing base dramatically compared to a full host kernel.

Q: Can side-channel attacks still compromise a microVM or sandbox?

A: Yes. Side channels-such as cache timing or resource contention-remain possible across isolation boundaries. Both gVisor and Firecracker acknowledge these vectors and recommend additional monitoring, but the primary goal is to eliminate the larger, more common attack surface of the System API and kernel bugs.

Q: What is the performance overhead of adding a microVM boundary?

A: Because microVMs and userspace kernels are designed to be lightweight-Firecracker boots in tens of milliseconds, and gVisor uses goroutines for fast context switching-the overhead is often lower than full virtualization. Resource delegation to the host allows the sandbox to scale up and down with the workload, minimizing idle cost.

Further Reading