AI agents need execution environments because code execution lets models solve problems with verifiable answers.
2
MicroVMs provide stronger isolation than fork(), containers, and gVisor by separating the guest kernel from the host at the hardware level.
3
Persistent storage lets sandboxes survive failures, support long-running work, and explore multiple solution paths through checkpointing and restore.
Summary
Abhishek Bhardwaj explains why agent products need secure computers that can execute untrusted model-generated code. He starts with Linux execution and compares fork() and exec, containers, gVisor, and hardware virtualization. Fork() has native performance but leaves the process exposed to the host kernel and allows noisy-neighbor failures. Containers add namespaces, cgroups, and seccomp, while gVisor moves much of the Linux API into user space. Bhardwaj prefers microVMs because the guest kernel runs in a separate hardware context, even though this adds performance and device-sharing costs. He then argues that durable disk storage is the next major capability. Incremental snapshots, copy-on-write layers, and block-level storage can preserve work, recover sandboxes on another node, and support longer searches. At fleet scale, regional control planes, cluster schedulers, warm pools, memory snapshots, and snapshot-aware placement can reduce startup latency and improve recovery.
Tool execution gives models a way to solve verifiable problems
Bhardwaj begins with questions such as "what is 3 + 3" and "how many hours in strawberry." A model often gets the first right because the answer appears repeatedly on the internet, while the second is less grounded in training data. Code execution gives the model a way to test answers for problems with verifiable rewards. In the training loop, the model emits a request to execute code, a harness runs it, and a grader checks the result. Training then teaches the model when to call tools and whether the generated code solves the task. Product systems use the same execution path without the training loop.
A sandbox protects the host from untrusted model-generated code
When an agent runs on a laptop or cloud node, its code may be malicious or simply overzealous. It might try to get root, exploit a kernel vulnerability, attack the node, or read another user's data. A sandbox gives the model an environment where its tool calls can run while limiting access to the surrounding machine. Bhardwaj says this matters in both research and products. Research needs high throughput for many parallel rollouts, while products need low latency. Reliability and security matter on both sides because failures waste GPU tokens, disrupt users, and can expose infrastructure or model weights.
Linux isolation starts with understanding system calls and privilege rings
A Linux thread runs in user space and requests privileged resources through system calls or ioctls. The kernel runs in ring zero, while ordinary user programs run in ring three. Bhardwaj describes two main attack paths. An attacker can get root while remaining in user mode, which can expose SSH keys and encrypted data. It can also exploit the kernel and run code in ring zero, which allows far broader control, including access to process memory. This distinction explains why sandbox designs must protect both the process from other workloads and the host kernel from the process.
Fork and containers trade simplicity for weak isolation
The simplest execution service forks a process for every tool call and then execs the requested program. It has native performance, but the child can communicate directly with the kernel and can consume the whole node with a fork loop. Containers improve resource separation with namespaces and cgroups. Namespaces can isolate process IDs, mounts, and networks, while cgroups limit CPU and memory use. Containers still run native processes against the host kernel, though, so a kernel exploit can cross the container boundary. Seccomp can restrict system calls and their arguments, but overly strict filters can break agents whose required calls are not known in advance.
gVisor reduces direct kernel access without removing the host-kernel path
gVisor moves much of the Linux system-call interface into user space. Its sentry acts like an application kernel, while the gofer handles file-system access. An exploit then reaches a user-space component before it can reach the host kernel. Bhardwaj describes this as a harder two-step attack than directly targeting the kernel. The boundary is still ultimately built on the host kernel, however. An attacker could exploit the sentry or gofer and then chain that exploit into the host. The result improves the attack surface compared with raw fork() or ordinary containers, but it does not provide the hardware boundary Bhardwaj wants.
MicroVMs isolate the guest kernel from the host through hardware virtualization
Hardware virtualization puts the guest kernel in ring zero inside a separate VMX non-root processor context. The host kernel and hypervisor run in VMX root mode, so gaining root or kernel execution inside the guest does not directly give control of the host. A virtual machine monitor such as QEMU configures the guest kernel, root file system, memory, and devices through Linux's KVM API. Guest device access exits to the host, where the VMM and device back ends handle it. Rust-based VMMs such as CrosVM reduce the code and device surface compared with QEMU, and individual devices can be jailed with narrower permissions.
MicroVMs are small because their monitors have less code and fewer devices
The word microVM describes the VMM rather than the contents of the guest. Newer Rust-based monitors support fewer devices and have less code than QEMU, so they use less memory and boot faster. Bhardwaj names CrosVM as the first Rust-based VMM in this lineage, followed by Firecracker, which forked CrosVM and is used by Amazon for Lambda and serverless workloads, and Cloud Hypervisor, which is more general. A harness can start one through an API: fork the VMM, send it a kernel, root file system, CPU, and memory through a Unix socket, then call start. Guest and host components can communicate through Vsock or the node IP stack.
MicroVM security costs performance and complicates device sharing
MicroVMs make host compromise harder because an attacker may need to exploit KVM and then a device, and device processes can receive seccomp and other restrictions. The costs include overhead when execution switches between guest and host contexts. Memory reclamation is reactive through mechanisms such as a balloon driver. GPU support is also harder. Virtio-GPU provides higher-level graphics access, while VFIO can provide direct device access to one sandbox but does not support multi-tenant sharing. Bhardwaj says he prefers the stronger security boundary and would address its performance costs with system techniques. He recommends starting with microVMs rather than spending years moving through weaker options.
Persistent disks let sandboxes recover work and explore longer tasks
A sandbox without a durable disk loses its work when the node or process disappears. That is increasingly costly as agents create presentations, install packages, and build entire GitHub repositories. Periodic checkpoints let a failed sandbox resume on another node, and they can also support planned cluster upgrades or testing. Explicit snapshots allow a harness to branch, explore several solution paths, and backtrack through a Monte Carlo tree search. Bhardwaj proposes incremental snapshots rather than repeatedly copying gigabytes, fast snapshot and restore APIs, configurable snapshot scope, and block-level tracking where appropriate. Copy-on-write layers can make initial copies cheap, while changed blocks are later packaged and uploaded.
"A sandbox is a play environment in which you can run these tool calls and execute code on behalf of the model securely and it could be on your laptop or it could be on the cloud."05:24
Who should watch
You are building an agent product that executes model-generated code and need to choose an isolation boundary.
You are comparing fork(), containers, gVisor, and microVMs for a sandbox service with different latency and throughput needs.
Your agents run long tasks and lose work when nodes fail, or you need checkpointing and snapshot-aware scheduling across a fleet.
