An OpenAI engineer's argument: every agent sandbox ends at micro VMs — skip two years of grief.
From fork() to Fleet: Designing an Agent Sandbox Cloud — Abhishek Bhardwaj, OpenAI · Abhishek Bhardwaj
44 min total·Actually worth watching closely: ~20 min·3 must-watch clips
- 0:12 – 5:37Skim
Where sandboxes come from: the training loop itself has to run code
It starts with verifiable rewards in RL: the model gives a response, an outer harness executes code on its behalf, a grader judges right or wrong, and the loop backprops and changes the weights. The tool-calling ability that comes out of training needs the same execution environment waiting for it on the product side.
Sandboxes are not a need that shows up at product time — they already exist the moment you start training. The two sides are symmetric.
The slide is a flow diagram of the training loop; a glance at the arrows is enough, since the narration stands on its own.▶ Jump to 0:12Speaker · Abhishek Bhardwaj - 5:41 – 12:00Listen
Research wants throughput, product wants latency — and the crudest approach
Splitting the two sides: research runs many, many loops in parallel and optimizes for throughput, while product loses users if it is a second too slow and optimizes for latency; reliability and security give way on neither side. Then the plainest solution of all: fork and exec the code directly.
Don't treat security as a single goal: there are two things to stop — getting root, and executing in the kernel, and the second is catastrophic.
Mostly spoken argument, with one slide in the middle listing the attack surface; skipping the visuals costs you nothing.▶ Jump to 5:41Speaker · Abhishek Bhardwaj - 12:03 – 18:13Watch
What containers and gVisor get right, and where they fall short
Containers break down into two kernel primitives: namespaces for isolation, cgroups for capping how much a set of processes can consume — exactly the fix for the noisy neighbor who forks in a while loop and brings the whole machine down. But the kernel is still shared, so one kernel exploit goes straight through; gVisor moves the kernel interface into user space, and a two-step chain still reaches the host kernel.
A shared kernel is a shared fate — and newer models keep getting better at chaining several exploits into one.
The speaker points at the screen and says 'in this diagram you can see,' and gVisor's user-space kernel and file system proxy are drawn as a layered structure too; skip the visuals and you lose the backbone of the whole argument.▶ Jump to 12:03Speaker · Abhishek Bhardwaj - 18:18 – 23:09Skim
Hardware virtualization: root inside the VM still can't touch the host
The guarantee sits at the CPU level: the guest kernel runs at the top privilege level but in a restricted mode, while the host kernel and the hypervisor run in another mode, so the guest's top privilege only counts inside the guest. From there it goes further down: the VMM turns out to be just a user-space process working through an interface the kernel exposes.
This is the only approach that delivers 'untrusted code executes in the kernel and the host is still protected' — the landing point of the whole talk.
The privilege level comparison diagram is worth stopping for (one of the must-see moments), but for the later part on how device access exits to the host, the narration alone is enough.▶ Jump to 18:18Speaker · Abhishek Bhardwaj - 23:13 – 30:15Watch
The rise of micro VMs and their three costs
From 2023 a batch of Rust-written VMMs replaced the long-accumulated cruft of the old one; memory safety plus jailing each device makes a second gate of security, and 'micro' refers to the small footprint and fast boot. The costs are stated plainly too: mode-switch overhead, memory that can only be reclaimed passively, and GPU passthrough that cannot be shared across tenants.
In use it comes down to a set of APIs — start a process, create, boot. Less mysterious than it sounds.
This section lands on concrete interface calls and parameters (how the kernel, root file system, CPU and memory get passed in), so what is on screen is something you can copy.▶ Jump to 23:13Speaker · Abhishek Bhardwaj - 30:15 – 38:34Listen
Persistence: from fear of losing the task to forking out to explore
Tasks are getting longer and more complicated (the speaker's own record running Codex is three days), and agents will move off laptops back to running persistently in the cloud. With checkpoint and restore, a task survives infrastructure failure; going further, the outer harness can save state, explore a few solutions in parallel and backtrack. Then it returns to first principles on disk: the file system maps files to logical blocks, so packing up only the blocks that changed is enough.
The real value of snapshots is not disaster recovery — it is turning a multi-day task into a search tree you can backtrack through.
The first half is pure motivation; the second half on block mapping is walked through verbally, layer by layer, so you can follow it while doing something else.▶ Jump to 30:15Speaker · Abhishek Bhardwaj - 38:41 – 44:14Watch
Down to engineering: incremental snapshots, your own block storage, lineage-aware scheduling
A route you can follow directly: a copy-on-write layer plus an interface that tells you which blocks changed, with the diff uploaded asynchronously. For always-on persistence, don't go through a network file system — build your own global tiered cache on object storage and hand it to the sandbox as a block device. Finally, three paths to low-latency creation and the scheduling strategy.
The scheduler scores and routes by how much of the needed snapshot lineage each node already has cached — snapshotting and orchestration working together is what buys you fast creation.
The two architecture diagrams here (the cache path, and node selection scored by snapshot lineage) carry the highest information density and are the hardest to reconstruct by ear.▶ Jump to 38:41Speaker · Abhishek Bhardwaj