Google donates gVisor, used by Anthropic and OpenAI, to CNCF

Google is handing three of its agent infrastructure projects, gVisor, Agent Substrate and OpenRL, to the Cloud Native Computing Foundation (CNCF), according to a November 5 Google Cloud blog post. Of the three, only Agent Substrate ships as a production release, at 1.0 and generally available on GKE. gVisor’s near-native I/O still depends on host kernel patches that upstream Linux maintainers declined while Google owned the project, and OpenRL started as a research preview in February.

Teams running agents on Kubernetes can use Agent Substrate as a managed capability on GKE or deploy the open-source code on any cluster. Either way, the isolation boundary can be Cloud Hypervisor microVMs or gVisor, and switching between them doesn’t change how agent lifecycles are managed. Agent Substrate runs standard OCI containers, so ADK agents, stateful coding environments and productivity agents work with it out of the box. For teams that want microVMs through an API and no clusters to manage, Google points to Agent Compute Engine, its Titanium microVM service, which was announced in October with a preview due on Google Cloud later this year.

What Agent Substrate does with idle agents

Agent Substrate is built around the fact that agents spend most of their time waiting. They run code for a few seconds, then sit idle while a model reasons, an external API answers or a human responds. In plain Kubernetes, giving every active agent its own Pod ties up memory and CPU during those pauses. It also leaves the control plane tracking millions of persistent objects it was never designed to hold, and binds each agent’s identity to its Pod.

Agent Substrate splits the agent from the compute underneath. Actors hold each agent’s memory, files and identity. Workers are reusable sandboxes drawn from a warm Kubernetes pool. Gateways enforce inbound and outbound access control and inject secrets based on the Actor’s identity, so sensitive keys stay out of the agent’s environment. When an agent pauses, its memory and files are snapshotted to storage and the Worker goes straight back to the pool. When the next request arrives, the Actor is restored onto any free Worker in under 500 milliseconds.

Google’s figures for the 1.0 release are production workloads across millions of sandboxes, 10x the density of standard container runtimes, and more than 500 suspend and resume activations per second. Public development started in May 2026, and the project now has more than 100 contributors. Nous Research is building Hermes Enterprise on it, it already powers the CNCF project kagent, and SPIRITT runs its agent workspace product on Agent Substrate on GKE. Tamir Magen, SPIRITT’s CEO, said the service gives the company “the density to run every customer’s agents economically at scale.”

Why gVisor needed a neutral owner

gVisor puts a lightweight application kernel, written in Go, between the container and the host. It intercepts the application’s system calls and handles them in userspace, so untrusted code never talks to the host kernel directly. That matters for agent fleets because ordinary containers share one host kernel with everything else on the node, and agents routinely run generated shell commands and unreviewed packages. Unlike VMs that reserve a fixed block of RAM, gVisor keeps the container process model, so memory grows and shrinks with the workload. It supports GPUs, TPUs and checkpoint/restore natively, and it doesn’t need nested virtualization, which is why Northflank uses it to sandbox GPU workloads where nested virtualization isn’t available.

Google open-sourced gVisor in 2018, and it now runs millions of sandboxes a day under GKE Sandbox and Cloud Run. Modal and Snowflake run their execution sandboxes on it, and Ant Group and Tencent run it in production at scale. Anthropic runs code generated by Claude inside gVisor containers on its web platform, The New Stack reports, while OpenAI uses it to isolate code execution.

The kernel patches are the practical reason for the move. Sandbox providers, Google included, all carry host kernel patches that bring gVisor’s I/O performance close to native Linux. Upstream maintainers declined to merge them while a single vendor owned the project, and CNCF governance only opens the path to upstreaming them. Until those patches land, near-native performance is still something each provider has to patch in itself. That is the long-running cost of the design: InfoQ‘s 2018 launch coverage noted that gVisor may perform poorly on system-call-heavy workloads, and that some system calls and arguments were unsupported, so not every application would run inside it.

The maintainer list is widening. Ant Group, Modal and Tines have committed to join gVisor’s maintainers, and OpenAI, Tencent and NVIDIA will keep contributing. gVisor is also on a path toward CNCF Incubation, the foundation’s next maturity level after Sandbox.

OpenRL, donated early

OpenRL runs self-hosted reinforcement learning post-training loops in plain Python on Kubernetes. The loop is written with four primitives (sample, forward_backward, optim_step and save_state) through a Tinker-compatible API, while weights and data stay on your own cluster. Existing tinker-cookbook recipes run unchanged, with both LoRA adapters and full-parameter fine-tuning. OpenRL partitions the accelerator pool through Kubernetes Dynamic Resource Allocation, uses PyTorch/AutoModel for training and vLLM for sampling, and has Gemma and Qwen validated out of the box. TPU support is still on the roadmap.

Paired with llm-d, the CNCF distributed inference project that recently reached 1.0, OpenRL routes multiturn rollouts to samplers that already hold matching KV cache prefixes. It also time-slices the same physical GPUs between sampling and training, which otherwise take turns and leave one set of chips idle. Google says it is bringing OpenRL to the CNCF early on purpose, so that accelerator makers, inference engines and model builders can shape the design before it hardens. That leaves the newest layer of the stack only nine months past its first preview.

The security backdrop

The donation lands as worries grow about agents that run code and reach outside systems. In July, models undergoing a cybersecurity evaluation at OpenAI escaped their restricted environment and breached Hugging Face’s production infrastructure, according to The New Stack. In a security report published on November 4, OpenAI cited sandboxes such as gVisor and Firecracker as important for limiting the damage from exploited Linux kernel vulnerabilities.

Drew Bradstock, Google’s VP of product management for Kubernetes and orchestration and the author of the post, is betting on the Kubernetes playbook. “We believe that these donations will accelerate the development and adoption of agentic workloads through these projects similarly to what we saw with Kubernetes,” he wrote.

Google’s post says the three projects were accepted into the CNCF Sandbox last month. The New Stack dates gVisor’s acceptance to late September, with Google announcing its plans a few days later and gVisor’s onboarding starting the week before Thursday’s announcement. All three projects are now going through Sandbox onboarding with community maintainers and independent build infrastructure.