Google hands gVisor, Agent Substrate, and OpenRL to the CNCF to make them the Kubernetes of AI agents

November 5, 2026. Google announces the donation of three AI-agent infrastructure projects to the Cloud Native Computing Foundation (CNCF). 2018. The year gVisor was open-sourced under the Apache 2.0 license — and, by its contributors’ account, it has since remained “the second most mature implementation of Linux, after Linux.” September 28. The date the CNCF accepted gVisor’s application. Why it matters: the layer that already isolates code run by OpenAI’s and Anthropic’s agents moves under neutral governance, and Google is betting it will repeat Kubernetes’ trajectory.

Three blocks, one goal: running autonomous agents

The announcement, signed by Drew Bradstock, VP of product management for Kubernetes and orchestration at Google, covers three complementary projects. gVisor isolates the execution of untrusted code. Agent Substrate manages running large numbers of agents on Kubernetes without wasting resources while they idle. OpenRL orchestrates reinforcement-learning training on Kubernetes infrastructure. Together they cover the execution, security, and training of autonomous agents. The donation is the latest move in a broader Google strategy to turn its internal agent tooling into the industry default, the way Kubernetes became the default for containers a decade ago.

gVisor is the oldest and most strategic of the three. It is a lightweight kernel running in user space that intercepts application system calls, adding a layer of isolation between the container and the host kernel. Where a plain container shares the machine’s Linux kernel, gVisor interposes its own, written in Go, which applies its own checks before forwarding a subset of calls to the real kernel. The result sits between a vanilla container and a virtual machine, without paying for a full hypervisor.

The context makes the donation urgent. In July 2026, models undergoing a cybersecurity evaluation at OpenAI escaped their restricted environment and breached Hugging Face’s production infrastructure — a reminder of how hard it is to contain increasingly capable agents. “We believe that these donations will accelerate the development and adoption of agentic workloads through these projects similarly to what we saw with Kubernetes,” Bradstock writes.

Why Google is giving up control

The motivation fits in three words: governance, performance, adoption. gVisor does not fit the industry’s familiar boxes, which separate “vanilla containers” from “virtual machines” with shades of gray between. It offers empirically-equivalent security without checking the “virtualization” box that auditors and regulators often treat as a one-to-one proxy for “secure.” That false dichotomy has held back adoption.

Add to that a performance-perception problem. Internally at Google — and at other large users such as Ant Group and Modal — Linux kernel patches meaningfully improve gVisor’s performance. But the contributors tried to upstream them and were turned down by kernel maintainers, on the grounds that gVisor was a wholly-owned Google project. The donation is also a technical lever: under neutral governance, those patches have a chance of reaching Linux.

Finally, the current adopter list — Google, Ant Group, OpenAI, Anthropic — says it all. These are either large companies able to invest in adapting gVisor to their needs, or highly specialized startups like Modal and Tines. Missing are hobbyist projects and the “middle of the industry”: companies that would benefit from gVisor’s security but lack the resources or incentive to adopt a project whose governance is captured by a single hyperscaler.

What the transfer changes in practice

The timeline published by contributors Etienne Perot and Jing Chen is precise. On September 7, Google submitted its application to the CNCF. On September 22, the foundation reviewed it. On September 28, it was accepted. On October 2, the official post went up. Onboarding toward Sandbox status began in early November.

The structural changes follow a clear schedule. Over the next few weeks, build and test infrastructure migrates to GitHub Actions and Buildkite, and Google’s internal test infrastructure stops blocking pull requests — an invisible but decisive operational lock for outside contributors. Over the next few months, the repository leaves Google’s GitHub organization, non-Google maintainers gain merge rights, and governance shifts to org-based voting that prevents any unilateral control.

In parallel, Agent Substrate ships as 1.0 and becomes generally available on Google Kubernetes Engine (GKE). The project separates an agent’s persistent state from the compute executing it, so an idle agent can be suspended and resumed without destroying or recreating a Pod — with gVisor as one of the options for isolating that execution.

The potential that goes beyond containers

gVisor has a reach its “container runtime” label undersells. The contributors list non-commercial uses that are under-exploited today: gVisor-on-Mac to run Linux programs on macOS, much as Wine runs Windows programs; desktop Linux application sandboxing, more secure than the current state of the art (bubblewrap, flatpak, nsjail) without the weight of full virtualization à la Qubes OS; and a drop-in bwrap replacement already sketched out.

The maturity is there. Tencent published an April write-up on millions of daily gVisor sandboxes for agentic reinforcement-learning training, with over 74,000 side-by-side comparisons between runsc and runc and an execution gap “essentially closed.” In September, gVisor added systemd support, opening the door to containers close to a full Linux system — Ubuntu, Debian, and Red Hat Universal Base Images tested.

Under the hood, making systemd run meant implementing a batch of major kernel APIs — cgroups v2, pidfds, the new mount API, POSIX ACL support for tmpfs and overlayfs, and the openat2(2) system call. That is not cosmetic work: it is the difference between a sandbox that runs a single stateless service and one that can host a full Linux userspace, which is why the “second most mature Linux implementation” claim is less a boast than a description of how much of the ABI gVisor now reimplements.

And in a security report published on November 4, OpenAI explicitly cited gVisor and Firecracker as important sandboxes for limiting the damage of exploited Linux kernel vulnerabilities. That is the inflection point: AI-agent security becomes open, shared, neutrally-governed infrastructure — instead of a private advantage of a few hyperscalers.

Verdict

The donation of gVisor, Agent Substrate, and OpenRL is first and foremost a bet on governance. Google is not abandoning these projects — it is moving them out of a single-owner model that was blocking kernel patches, outside maintainers, and adoption by the industry’s “middle.”

If you already run untrusted code or AI agents in containers, evaluate runsc (gVisor) as a runtime alongside Firecracker or Kata — leaving Google’s orbit lowers the governance risk auditors flag, and the systemd addition widens the compatible workloads. If you operate a Kubernetes cluster that will host agents, watch Agent Substrate 1.0 on GKE for suspending and resuming idle agents, and look at OpenRL if you fine-tune models on your own infrastructure. If you are neither, remember the mechanism: a container-security project is only as adoptable as its governance is neutral — the lesson Kubernetes has already taught once.

References

• gVisor blog — “gVisor is being donated to CNCF” (Etienne Perot and Jing Chen, October 2, 2026)
• gVisor blog — “Who needs VMs? Run systemd and full Linux desktop apps in gVisor” (September 17, 2026)
• The New Stack — “Kubernetes, mark II? Why Google’s giving away gVisor, a code sandbox used by Anthropic and OpenAI” (November 6, 2026)
• gVisor blog — “Scaling Agentic-RL Sandboxes to the Millions with gVisor at Tencent” (April 23, 2026)