Google said on November 5, 2026 that it is handing three of its open source projects to the Cloud Native Computing Foundation: the gVisor sandbox runtime, the Agent Substrate session platform and the OpenRL training framework. All three were admitted to the CNCF Sandbox in October, and each is now going through onboarding with community maintainers and separate build infrastructure.
At the same time, Agent Substrate hit version 1.0 and became generally available as a managed offering on Google Kubernetes Engine. For developers who run AI agents or untrusted code on Kubernetes, the move puts a widely used isolation layer under neutral governance, and gVisor is already on a path toward CNCF Incubation.
What Google Announced
The announcement covers a stack of three projects that Google describes as open infrastructure for autonomous agents. Each one handles a different part of running agents at scale on any Kubernetes cluster, across CPUs, GPUs or TPUs.
- gVisor: a sandbox that isolates generated or untrusted code from the host Linux kernel.
- Agent Substrate: a platform that separates long-running agent sessions from the compute they use, now at 1.0 and GA on GKE.
- OpenRL: a self-hosted framework for reinforcement learning post-training written as plain Python loops on Kubernetes.
Google also points to llm-d, a distributed inference project already in the CNCF that recently reached 1.0, as a companion piece for OpenRL workloads.
Why gVisor Matters Most for Developers
gVisor is an application kernel written in Go. It sits between a container and the host operating system and handles system calls in user space, so code inside the sandbox never talks to the host kernel directly.
Google released gVisor as open source in 2018, and it already runs beneath both Cloud Run and GKE Sandbox. Google lists Anthropic, OpenAI, Modal, Snowflake, Ant Group and Tencent among the outside users that run execution sandboxes on it.
Google highlights three traits that suit agent fleets:
- Memory grows and shrinks with the workload, instead of being reserved up front as with a virtual machine, so more sandboxes fit on each node.
- It supports GPUs, TPUs and checkpoint and restore, so a sandbox can use accelerators and be paused when idle.
- It does not need nested virtualization, so it deploys the same way on any cloud or local Linux machine.
The governance change has a concrete technical goal. Google says providers that run gVisor all keep host kernel patches that bring its I/O speed close to native Linux, but kernel maintainers would not merge them while one vendor owned the project.
Under the CNCF, Google expects those changes to go upstream. Ant Group, Modal and Tines have also agreed to become maintainers.
Agent Substrate 1.0 on GKE
Agent Substrate targets a cost problem with agents: they spend much of their time waiting on a model, an API or a person, and a container kept alive during those waits wastes memory and CPU. The platform stores an idle agent as a snapshot and brings it back in under 500 milliseconds.
It is built from three parts. Actors keep an agent's memory, files and identity; Workers are reusable sandboxes taken from a warm pool in Kubernetes; Gateways control traffic in and out and inject secrets so keys stay out of the agent's environment.
Google reports that the 1.0 release handles millions of sandboxes at ten times the density of standard containers and over 500 suspend and resume operations per second. Isolation can come from gVisor or Cloud Hypervisor microVMs, and it runs standard OCI containers.
OpenRL for Training on Kubernetes
OpenRL began as a research preview in February 2026, and Google says it is donating the project early on purpose. It runs reinforcement learning post-training loops in Python and offers an API compatible with Tinker, so existing tinker-cookbook recipes run without changes.
The framework uses Kubernetes Dynamic Resource Allocation to split a shared pool of accelerators between sampling and training. Google says Gemma and Qwen models are validated, LoRA and full fine-tuning are supported, and TPU support is on the roadmap.
What It Means for Developers
If you let an AI agent, a CI job or a user run code you did not write, a plain container is a weak boundary because it shares the host kernel. gVisor is one of the most proven ways to close that gap, and CNCF ownership makes it a safer long-term bet for teams that avoid single-vendor tools.
The planned kernel work is worth watching. I/O-heavy workloads, such as builds or database clients that read many files, have been the usual pain point with gVisor, and upstream changes could reduce that overhead for everyone rather than only for large cloud providers.
Agent Substrate is more specialized. It is most useful for teams running many long-lived agents with idle gaps, where suspending sessions saves money. If you are mapping out the skills involved in this kind of work, our AI roadmap for developers gives a broader picture.
How to Get Started
gVisor can be tried today on any Linux machine as a container runtime, and GKE users can turn on GKE Sandbox for node pools that run untrusted workloads. Start with a test workload and measure file and network performance before moving production jobs.
Agent Substrate on GKE is available now, while the open source projects are documented on their own sites and tracked through CNCF Sandbox issues. Google plans more sessions on the stack at KubeCon + CloudNativeCon North America in Salt Lake City from November 9 to 12.
Conclusion
Google's donation puts gVisor, Agent Substrate and OpenRL under CNCF governance, with Agent Substrate reaching 1.0 and GA on GKE. The most immediate win for developers is gVisor, whose move to neutral ownership could finally bring its kernel speedups into upstream Linux and make sandboxing untrusted code cheaper on any cluster.
Sources
- Google Cloud Blog: Powering open infrastructure for autonomous agents
- The New Stack: Why Google is giving away gVisor
See my articles more often when you search Google.
