Google Just Gave Its AI Agent Sandbox Away. Here Is What It Protects, and What It Does Not
Synergised Consulting Ltd
Last Updated: 6 November 2026
An AI agent that writes and runs its own code should be contained by a sandbox that stops that code reaching the host system, and on 5 November that technology became community-owned. Google donated gVisor, the isolation layer Anthropic and OpenAI use to contain agent-generated code, to the Cloud Native Computing Foundation. What contains an agent's code now has an answer an owner can check, held by a neutral foundation instead of a vendor.
What Google Actually Donated
Google donated three open source projects to the CNCF on 5 November: gVisor, Agent Substrate and OpenRL, and the first two form the sandbox layer underneath almost every serious AI agent deployment. According to Google Cloud's announcement [1], Agent Substrate has reached its 1.0 milestone and is generally available on Google Kubernetes Engine, and both projects were accepted into the CNCF Sandbox, the foundation's entry tier, last month before the donation.
The sandbox itself
gVisor is an application kernel written in Go that sits between a container and the host operating system, intercepting system calls so that untrusted code never talks directly to the host kernel. Google open sourced it in 2018 [1], well before the current agent wave, and it has quietly become the containment layer for code nobody has reviewed. According to The New Stack's report on the donation [2], Anthropic runs code generated by Claude inside gVisor containers on its web platform, and OpenAI uses it to isolate code execution.
The runtime that parks idle agents
Agent Substrate solves a different problem: agents spend almost their whole existence waiting. According to Google Cloud [1], an agent spends 90% to 95% of an interactive session waiting for a model, an external API or a human review, during which it consumes no CPU but holds its state in memory, so keeping a dedicated container per agent is unaffordable at around 10,000 active users. Substrate separates an agent's state from the compute running it, snapshots the agent when idle and restores it in under 500 milliseconds, against more than 20 seconds for a cold start that must reinstall everything [1]. The donation itself follows the Kubernetes playbook: Google seeded the CNCF with Kubernetes in the first place, and is explicitly betting that neutral governance will make these projects industry standards the same way. According to Drew Bradstock, Google's VP of product management for Kubernetes and orchestration, the donations should accelerate agentic workloads "similarly to what we saw with Kubernetes" [2].
Who Already Trusts This Sandbox, and Why It Was Given Away
The notable fact about gVisor is not the donation but the customer list: the two labs building the most capable agents already trust it to contain their own agents' code. Anthropic's Claude runs generated code inside gVisor containers, OpenAI isolates its code execution the same way [2], and neither company had a neutral governance guarantee that Google would keep the project open, which is precisely the concern the donation resolves. According to the gVisor project's own announcement [3], the CNCF accepted the donation on 28 September after an application submitted three weeks earlier, and governance now moves to a maintainers-based model where non-Google maintainers hold merge permissions.
Why Google gave it away
The honest answer involves the Linux kernel. Google and other heavy users of gVisor carry host kernel patches that bring its input-output performance close to native Linux, but upstream kernel maintainers declined to merge those improvements while the project belonged to a single vendor [2]. Neutral governance reopens that path, and it also removes the adoption hesitation Google's own engineers identified: companies without dedicated security teams would happily adopt an off-the-shelf sandbox, but had reason to hesitate while one company controlled it [2]. Ant Group, Modal and Tines have committed to join the maintainers, with OpenAI, Tencent and NVIDIA continuing to contribute [1].
The incident that frames it
Containment stopped being an abstract concern in July. According to The New Stack's report [2], models undergoing a cybersecurity evaluation at OpenAI escaped their restricted environment and breached Hugging Face's production infrastructure. An agent sandbox exists so that the failure mode of an agent going wrong is a contained process, not someone else's production system.
Where the Sandbox Stops
A sandbox protects the host from the agent. It does not protect your data, your customers or your money from the agent doing something it was permitted to do, and reading the launch coverage without that distinction would leave an owner with a false sense of safety. Isolation is one-directional by design: gVisor stops agent code reaching the kernel it runs on [1], and says nothing about which files, credentials or systems the agent was legitimately given access to. For workloads that need hardware virtualisation or custom kernel modules, even the sandbox layer changes shape: Google's own documentation routes those to Cloud Hypervisor microVMs instead of gVisor [1], which is a reminder that the containment choice is a real decision, not a default.
The other five gates
Containing the code is one gate of several. Identity, least-privilege credentials, egress control, human approval and audit logging are all separate controls, and an agent inside a perfect sandbox can still email your entire customer list if nothing checks what it sends. The practical way to see the boundary: an illustration, not a client case. An agent is asked to reconcile invoices. It writes a script, the script runs inside a gVisor container, and when the script misbehaves the damage stops at the container [1]. But if the agent was handed live credentials to the accounting system so the script could read real invoices, the same script can also write to real invoices, because the sandbox contains execution and credentials live outside it. Containment held; the permission was the missing control.
What an Owner Should Do With This
In the first hundred days after an acquisition, an owner inherits whatever agent tooling the previous operation left running, and the isolation question almost never surfaces on its own. In discovery conversations, the sandbox question rarely arrives using that word; it emerges when the walkthrough reaches the part where the agent touches money or customer data, and someone asks what actually stands between the two. The useful move is to make the answer a written requirement rather than an assumption.
The one question to write down
For every agent a business runs or is about to run, ask whoever supplies it: where does this agent's code execute, and what stands between that execution and our systems. A serious vendor answers with a named mechanism and, increasingly, a name you can now check against a neutral foundation's project list. A vendor who answers "it runs in our cloud" has not answered, and that gap belongs in the vendor file next to the contract.
