On November 10, Salt Lake City, KubeCon North America. Nvidia donated OpenShell to the CNCF Sandbox—an isolated runtime for agents, under the Apache 2.0 license. Five days earlier, Google donated three projects together: Agent Substrate, gVisor, and OpenRL.
Four things, not one of them is a model. Three are cages, one is a training ground—none of them produce intelligence; they only govern where intelligence runs and what it can touch.
Brandon Royal, a product manager at Google Cloud responsible for AI agents and infrastructure, was blunt on stage: any agent needs to be fully isolated, whether it is accessing tools, operating a computer, or opening a browser—"no exceptions." He framed this as a billing problem—agents do nothing 90% to 95% of the time, waiting for the model to respond or for a human to click that approval. The CPU and memory occupied while waiting all cost money.
Putting these two things together, one can see the foundation that enterprise AI truly changed this year: the locus of governance has shifted from an approval button in an application to a sandbox in the cluster.
1. Two donations in one week, and the cage became a public facility
Google's three projects were announced as donated to the CNCF Sandbox on November 5, having been accepted a month earlier. Version 1.0 of Agent Substrate is already generally available on GKE, and Google's own Gemini Managed Agents runs on it.
Nvidia's OpenShell came five days later, announced on-site at KubeCon on November 10. It is a kernel-isolation sandbox; policies are written in declarative YAML, governing four types of access: file system, network, process, and model provider credentials; credentials are injected only in requests sent to approved endpoints; before policy changes are approved, formal verification is run first to see whether they would grant new high-risk permissions.
NVIDIA's stated position is: hundreds of organizations have used it, and in under a year it has received tens of thousands of contributions. The project is being moved to the ai-openshell organization; during the migration, the code and issues remain under the NVIDIA name.
| Project | Donor and Time | Permission | What to solve | Current Status |
|---|---|---|---|---|
| Agent Substrate | Google, 11-05 | Open source | Stateful Runtime: Decoupling Sessions from Compute | 1.0 is now GA on GKE |
| gVisor | Google, 11-05 | Open source | User-mode kernel sandbox | Accepted into the CNCF Sandbox |
| OpenRL | Google, 11-05 | Open source | Reinforcement learning post-training on K8s | Preview starting in February |
| OpenShell | NVIDIA, 11-10 | Apache 2.0 | Kernel isolation + policy + credential control | Move to ai-openshell |
What these two donations have in common is that they turn how agents are contained from a product feature of one company into a public asset hosted by a foundation. The implication for procurement is direct: in the past, you could only add a confirmation step in the ERP approval flow; now you can require suppliers to explain which runtime their agents run on, what layer the isolation reaches, and who changes the policies.
II. Spending 95% of the time waiting—what you're waiting for is money
The assumption of traditional containers is 'once started, keep working.' A scheduler designed for website backends struggles with agent-style workloads: it may spend only half a second executing a command, and then more than 90% of the time waiting for the model to reply, waiting for human approval, waiting for the next tool to return, while still holding a half-modified state and unable to be shut down arbitrarily.
If you do not shut it down, resources stay occupied the whole time; if you shut it down, state is lost and you have to start over next time. Most teams' approach is to leave headroom, and that headroom is the bill.
Agent Substrate's solution isn't complicated: separate the "agent session" from the "compute that does the work." Keep a small pool of warm worker nodes in the cluster; when an agent is idle, snapshot it along with its memory and filesystem state, persist it to disk, and release the node; when it needs to continue, restore it back.
Idle session recovery time (according to Google, GKE production environment); container density increased 10x under the same mechanism
There is an easily overlooked causal chain here: the more thorough the isolation, the more expensive the cold start; the more expensive the cold start, the fewer people dare to do isolation. Therefore, "isolation" and "billing" have never been two separate problems; they are two sides of the same architectural decision. Google Cloud recently also launched the Agent Compute Engine, making agent hosting a separate product slot—this shows that agents are being treated as a new type of workload, rather than "an application with an API."
III. Credentials Do Not Enter the Sandbox: Four Layers of Defense, Four Questions
Google senior engineer Benjamin Elder put it more concretely: all traffic passes through a network layer that enforces policy and identifies identity, and the agent cannot touch anything that has not been explicitly authorized; credentials are not given to the sandbox—"do not expose credentials to the sandbox, and do not let the agent touch credentials"; decisions should be made outside the sandbox, and credentials are injected on the link.
This sentence is worth copying down and pasting on the wall of the architecture review. Prompt injection is dangerous not because the model can be "deceived," but because after being deceived it has credentials, network access, and write permissions in hand. Take the credentials out of the sandbox, and the attack surface degrades from "a key that can open the door" to "a window through which things can only be passed through a designated door crack."
| defense line | What does this line of defense guard against? | How should this batch of projects be done? | What should CIOs ask vendors |
|---|---|---|---|
| Identity | Who is calling | Network layer identifies identity and enforces policies | Does the agent have an independent identity, and can it be disabled separately? |
| Credentials | The key is read and taken out | Credentials do not enter the sandbox; they are injected in the link. | What credentials can it obtain, where is the injection point, and who can modify it? |
| Strategy | Unauthorized actions, policies quietly relaxed | Declarative YAML, formal verification before changes | Who can change the strategy, who approves it after the change, and is there a verification record? |
| Session | State residue, cross-environment drift | Idle snapshots persisted to disk, restored on demand | Where sessions are stored, how long they are retained, whether they cross borders, and how to clear them |
Why emphasize “verification before change”? Because the checks agents perform on themselves are basically useless. The November 5 daily of “The Way of Open Source” cited two studies, which contained two figures: when agents were asked to predict defects they themselves introduced, the miss rate ranged from 6.13% to 24.53%; when they were asked to judge whether they had done it correctly, the accuracy was only 53%. The daily’s conclusion was very restrained—self-checking helps very little, and the value of verification comes from “not itself”.
Don't treat a preview as usable.OpenRL only entered research preview in February this year; Agent Substrate's API is still changing, GPU support is being rebuilt around Kubernetes dynamic resource allocation, and some Dynamo integrations remain experimental; Nvidia's concurrently published NVKE / NVKR are explicitly marked public preview and not recommended for production. Using them for architecture validation is fine; putting them into an SLA is premature.
The significance of this passage for a CIO is: what you review is not 'whether the agent is smart,' but 'who can change the policy, and who verifies it after changes.' This and the requirement in ERP that write operations must be manually confirmed are two layers of the same problem—the application layer governs 'whether this transaction needs a human nod,' while the runtime layer governs 'whether it can touch this interface at all.'
IV. Why Donate Rather Than Sell
The reason Google gave for the donation is more worth reading than the technical details. For gVisor to make I/O close to native Linux, it needs a series of host kernel patches; but while the project was "owned by a single vendor," upstream Linux maintainers refused to merge these patches. After it was donated to the foundation, Ant Group, Modal, and Tines joined as maintainers.
"The Way of Open Source" made this point very clearly in its November 7 daily issue: this is not because of "believing in openness," but because "ownership blocks merging"—for the same piece of code, once the ownership attribution changes, the cost of collaboration comes down.
This statement also holds true for teams in China working on domestic IT innovation and open-source selection: a project having an open-source license does not mean its key capabilities can be shared across the ecosystem. The license addresses 'whether it can be used'; governance structure addresses 'whether it can be modified together.'
The two performance numbers disclosed at the same time are also worth noting, but be clear about who measured them: on Harvey's legal agent benchmark (24 practice areas), OpenRL raised Gemma 4's accuracy from about 50% with supervised fine-tuning to 70%; llm-d 1.0 uses prefix-cache-aware routing to raise the KV cache hit rate from 35% to 70%, and reduces median time to first token for multi-turn agent workloads by 70% to 85%. Both numbers come from Google's own production workloads and are vendor-reported figures, so they cannot be used directly as your baseline.
Three things not to mix up: open source is not free (operations, upgrades, and compliance verification all cost money); preview is not the same as usable (APIs will change); vendor benchmark scores are not your workload (your prompt lengths, tool counts, and concurrency patterns are all different).
Three Points for CIOs
First, put the runtime into the procurement and acceptance checklist. Don't just ask "which models are supported and what scenarios can it handle"; ask four things: at which layer isolation happens, whether credentials go into the sandbox, who can change policies, and where session state is stored. If you can't answer even one of these four questions, the system is still stuck at the demo stage.
Second, treat "policy changes" as change management, not configuration modification.Who can change, who approves, how to verify after the change, and how long rollback takes—these four items go into the CAB process. A single relaxation of a runtime policy carries the same order of risk as opening a permission group in ERP, but it usually does not go through the same approval.
Third, use external verification, not self-checking. Tests that an agent adds for itself hardly change the escape rate. Truly effective verification comes from another set of permissions, another person, another pipeline.
Go back to the metaphor from the beginning. The cage was open-sourced this week—the materials, blueprints, and lock cylinders are all laid out on the table, and anyone can take them and use them. But the key is not in the blueprints—it is in your policy change process, your credential management, and your audit logs.
Sources: Google Cloud Blog 'Open infrastructure for autonomous agents comes to CNCF' and Google Open Source Blog 'Sandboxing untrusted AI agents at scale' (2026-11-05, including Agent Substrate 1.0 GA on GKE, gVisor and OpenRL donations, and Gemini Managed Agents running on it); CNCF Sandbox acceptance (2026-10, one month earlier than the donation announcement); NVIDIA announced at KubeCon + CloudNativeCon North America (Salt Lake City, 2026-11-09 to 12) the donation of OpenShell to CNCF Sandbox (2026-11-10, Apache 2.0, declarative YAML policies, credentials injected only into approved endpoints, formal verification of policy changes, migration to ai-openshell); Unite.AI 'NVIDIA Donates OpenShell to CNCF and Adds Open-Source AI Factory Tools' (2026-11-10); AI Frontier Post 'Google Cloud's open AI-native Kubernetes stack' (2026-11-10, including llm-d 1.0 and OpenRL benchmark data); 'The Way of Open Source' daily (2026-11-07, including donation motivations, maintainer list, and Foresight-SWE and BOBA data); on-site KubeCon remarks relayed via a NetEase Hao technical report (2026-11-11).
Data basis note: The 500 ms recovery, 10x container density, KV cache hit rate and first-token latency, and Gemma 4 benchmark improvements are all Google's own claims, measured on its own production workloads, and not third-party audited; OpenShell's “hundreds of organizations, tens of thousands of contributions” are NVIDIA's own claims; OpenRL remains a research preview, NVKE / NVKR are public previews, and the vendor does not recommend production use.
Zhongdi Information (Zodioo) · Enterprise Digitalization Observations · 2026-11-12
