Executive Summary
Google donated gVisor, Agent Substrate and OpenRL to the CNCF Sandbox on 5 November, and shipped Agent Substrate 1.0 on GKE the same day. The governance change is the smaller half. The larger half is one sentence Google volunteered inside the gVisor section, saying that sandbox providers, itself included, all carry host kernel patches that bring gVisor I/O close to native Linux, and that upstream maintainers declined to merge them while a single vendor owned the project.
That re-prices every gVisor throughput number an operator has read. Isolation was the portable promise. I/O was not, because it lived in a patch set that traveled with the operator instead of the code. Sandbox-level governance is the precondition for closing that gap, not the closure of it, and a kernel merge outlasts a foundation announcement.
The sandbox boundary is what gVisor sells. The throughput decides whether you can afford to switch it on.
On 5 November Google moved gVisor, Agent Substrate and OpenRL into the CNCF Sandbox. Three projects changing hands is an ordinary week in open source. The sentence that matters sits in the middle of the gVisor section of that announcement, where Google says every sandbox provider, itself included, carries host kernel patches that pull gVisor I/O close to native Linux, and that upstream maintainers declined to merge them while one vendor owned the project.
Read it twice. Isolation was the neutral promise. I/O throughput was not.
Interception is the mechanism, and it costs you
gVisor puts a second kernel in front of the host kernel. It is written in Go, it runs in userspace, and it catches every application system call so generated code never reaches the real kernel. That is the right boundary for agent workloads, which execute shell commands and unreviewed packages for a living. Open sourced in 2018, it sits under GKE Sandbox and Cloud Run, and Google says it runs millions of sandboxes a day.
The cost is structural. Every syscall takes an extra hop through software, which is why gVisor performance reads so differently from one machine to the next. The correction was never upstream. It was a patch set each operator applied to its own host kernel and shipped in its own node image.
A patched node image is not a product feature
Here is the trap for anyone who reads a benchmark and then runs the software themselves. You adopt gVisor on the strength of a published I/O figure. You install it on ordinary nodes. You get the isolation guarantee in full, plus whatever I/O your kernel gives you, which is not the number in the chart.
That is not a knock on the project. Performance claims routinely describe an environment as much as a codebase. The trouble is that the gap is invisible from outside. Nothing in the repository tells you your node is missing a patch the reference deployment carries, and nothing in the benchmark tells you the reference deployment added one.
Google lists Anthropic, OpenAI, Modal, Snowflake, Ant Group and Tencent among teams using it to contain execution. Each runs infrastructure it controls, so each can make that trade. A platform team standing up a sandbox layer on managed nodes cannot, which is the team a portable isolation layer is supposed to serve.
Neutral governance buys the chance to fix it
The donation earns its keep here. Google’s argument is that one vendor could not merge kernel changes and that neutral ownership opens the path. gVisor sits in Sandbox and is on a path toward Incubation, with Ant Group, Modal and Tines joining as maintainers while OpenAI, Tencent and NVIDIA keep contributing. Credible sequencing. It is also the opening of a process measured in kernel releases rather than weeks, and the Sandbox application is its first step, not its last.
The rest of the stack is further along. Agent Substrate 1.0 is generally available on GKE, with Google claiming ten times the density of a Pod per agent, restore under 500 milliseconds and more than 500 suspend and resume activations per second. OpenRL was a research preview in February and now runs plain Python post-training loops on Kubernetes dynamic resource allocation. Those are Google’s numbers too, published without independent replication.
So measure before you standardize. Run gVisor on the kernel you actually ship, against the workload you actually run, and compare it with a microVM boundary on the same hardware. If the delta is acceptable, isolation is close to free. If it is not, you have learned something no foundation announcement can tell you, and you learned it before the architecture review rather than after.
Three questions for your own platform team. Which kernel are our sandboxed nodes running, and who patches it. Do we hold a throughput figure for the sandbox boundary that came off our own hardware. And when the isolation layer does get faster, what in our design was built around the assumption that it stays slow.
Related reading. Google shipped an agent runtime for a million idle sandboxes set out the Substrate design. NVIDIA put the agent’s security outside the agent makes the same argument about where the boundary belongs.
Get the next one before it is old news
Independent analysis of cloud-native infrastructure, Kubernetes and data center economics. No vendor spin.