Google Announces Donation of gVisor, Agent Substrate and OpenRL to the CNCF, Now in Sandbox Onboarding, as Agent Substrate 1.0 Reaches GA on GKE

Overview

Google said on November 5, 2026 that it is donating three open source projects that started at Google, gVisor, Agent Substrate and OpenRL, to the Cloud Native Computing Foundation (CNCF), and that Agent Substrate has reached 1.0 and is generally available on Google Kubernetes Engine (GKE), according to a Google Cloud blog post by Drew Bradstock, VP Product Management, Orchestration & Kubernetes. The post says each project “is now working through CNCF Sandbox onboarding”, and gVisor “is on a path toward Incubation”. The New Stack reported that Google is donating the projects in the hope they become industry standards, “just as Kubernetes did for containers”.

What the projects do

Google’s post describes gVisor as “a lightweight application kernel written in Go” that handles application system calls in userspace so untrusted code does not talk directly to the host kernel. Agent Substrate separates an agent’s state from the compute that runs it: per the post, Actors hold each agent’s memory, files and identity, Workers are reusable sandboxes drawn from a warm Kubernetes pool, and Gateways enforce access control and inject secrets. Users can choose “Cloud Hypervisor microVMs or gVisor” as the isolation boundary. The post says OpenRL brings “a clean, self-hosted Python post-training loop directly to your Kubernetes cluster”.

The performance figures are Google’s own. The post says Agent Substrate restores idle agents “in under 500 milliseconds”, runs “millions of sandboxes at 10x container density” and performs “more than 500 suspend and resume activations per second”. It does not state the hardware or workload behind them.

The Agent Substrate v1.0.0 release on GitHub was published at 23:55 UTC on 2026-11-05, by the release record’s timestamp. Its notes include a Breaking Changes section that, among other entries, lists renaming the --cordon-control-plane flag to --cordon-system-infra-components and removing the unused public MintActorCertificate API.

Dated sequence

Dates below come from the cited records and are UTC where taken from GitHub timestamps.

• 2026-09-07: gVisor’s CNCF Sandbox application was filed as issue 521, by the issue’s creation timestamp.
• 2026-09-28: a bot comment on each of the three Sandbox issues, gVisor, Agent Substrate and OpenRL, reports that the vote passed, with 8 binding votes in favour and none against.
• October: The New Stack says Google publicly announced its plans for gVisor a few days after the late-September acceptance.
• 2026-10-20: bot comments on the Agent Substrate and OpenRL issues say onboarding issues were created for them.
• 2026-10-28: the same comment appears on the gVisor issue.
• 2026-11-05: Google’s announcement and the Agent Substrate 1.0 release.
• 2026-11-09 to 2026-11-12: Google’s post lists sessions and a booth on the three projects at KubeCon + CloudNativeCon North America in Salt Lake City.

Google’s post says the projects were accepted “last month”. For a post dated November 5 that reads as October, whereas the GitHub records above show the votes closing on September 28 and onboarding starting in October. None of the cited sources says why the post words it that way, so the Herald reports both.

Why Google says it is donating

Google’s post says sandboxed infrastructure providers, including Google, carry host kernel patches that bring gVisor’s I/O performance close to native Linux, but that upstream Linux maintainers “declined to merge them while the project was owned by a single vendor”. It says neutral governance “opens the path to upstreaming those kernel optimizations”.

LWN’s account is narrower and older. Its July 29, 2022 report by Jonathan Corbet covered one gVisor-related proposal, a patch series from Andrei Vagin adding a KVM hypercall that lets a guest kernel run a system call directly on the host. LWN recorded objections on technical grounds: Thomas Gleixner complained that the series “exposes a magic kernel syscall interface to random driver writers”, and KVM maintainer Paolo Bonzini’s largest objection was the lack of address translation between guest and host. LWN’s text does not give vendor ownership as a reason for the objections, and The New Stack notes that such interactions do not focus on Google’s ownership as a reason. None of the cited sources says whether that series is among the patches Google’s post means, so the two accounts are left side by side.

On governance, The New Stack reports that gVisor contributors Etienne Perot and Jing Chen outlined plans to move development and testing infrastructure outside Google, give external maintainers merge permission, and adopt a model that prevents any single company from exercising unilateral control. Google’s post says Ant Group, Modal and Tines “have committed to join gVisor’s maintainers”, with OpenAI, Tencent and NVIDIA continuing their contributions. For Agent Substrate, a 2026-10-15 comment on the project’s Sandbox application asked about the contribution agreement and said the project then enforced Google’s CLA. The v1.0.0 notes list a change titled “docs: require DCO sign-off instead of the Google CLA”, whose pull request was merged on 2026-10-27. No cited source links the two.

Who uses gVisor

Google’s post says gVisor runs “millions of sandboxes every day underneath GKE Sandbox and Cloud Run” and that outside Google, Anthropic and OpenAI use it to contain code execution, Modal and Snowflake run their execution sandboxes on it, and Ant Group and Tencent run it in production at scale. The New Stack adds that OpenAI’s security report, published November 4, cites sandboxes such as gVisor and Firecracker as important for limiting the damage from exploited Linux kernel vulnerabilities; the report itself says sandboxes and isolation approaches like those two “are important for limiting the blast radius of exploited vulnerabilities”. The Herald previously reported on GKE Sandbox’s microVM type reaching general availability, a sandbox type that article compared with gVisor.

What we don’t know

• The hardware and workload behind Google’s density and restore-time figures are not stated in the post.
• Google’s post and The New Stack do not identify the kernel patches Google says were declined, or when.
• The cited sources do not say when the planned changes to gVisor’s build infrastructure and governance will be complete; Google’s post says only that each project is working through onboarding.