Autonomous AI agents are moving out of demos and into production. They file tickets, move money, query databases, call outside services and run code on company infrastructure. That is exactly what makes them useful — and exactly what makes them dangerous. An agent that misunderstands a request, follows a poisoned instruction buried in a document, or simply takes an unexpected shortcut can do real damage before a human notices.
On November 10, 2026, NVIDIA took a significant step toward answering that problem in the open. At KubeCon + CloudNativeCon North America in Salt Lake City, the company announced it is contributing OpenShell, its open-source runtime for securing and governing autonomous AI agents, to the Cloud Native Computing Foundation (CNCF), where it will live as a Sandbox project. The move puts the guardrails for agentic AI under neutral, community governance — and it arrives at the moment enterprises need them most.
What Is OpenShell?
OpenShell is a runtime that sits between an AI agent and everything the agent can touch. Instead of trusting the model to behave, it enforces deterministic controls on what the agent is allowed to do as it uses tools, reaches inference services and executes workloads. In NVIDIA’s framing, the point is enforcement outside the agent, inside the infrastructure the agent runs on — because a safety rule that lives only inside a model’s prompt can be talked around, ignored or forgotten.
The project is not new. NVIDIA says hundreds of organizations have already put OpenShell to use, and the runtime has attracted tens of thousands of contributions in less than a year since launch. What is new is the governance: the project is moving from NVIDIA’s GitHub repository to a neutral organization, ai-openshell, under the CNCF, with a public RFC process, the CNCF Code of Conduct and an explicit vendor-neutrality commitment. Core contributors from NVIDIA, Red Hat, Docker and Canonical have worked on OpenShell since its inception, and that multi-vendor backing is part of why the CNCF accepted it.
The runtime is licensed under Apache 2.0, which means organizations can use it, modify it and build commercial products on top of it without paying NVIDIA a license fee.
How OpenShell Keeps Agents on a Leash
OpenShell’s core idea is simple: an agent should only be able to do what policy explicitly allows, and policy should be enforced by the system, not by the agent’s good intentions. Three mechanisms make that work.
First, isolation. OpenShell runs agents in kernel-isolated sandboxes, so an agent’s actions are contained even if the agent itself is compromised or misled. A rogue tool call cannot escape into the host system, read files it was never granted, or reach a network it was never told about.
Second, declarative policy. Teams write rules in YAML that spell out what an agent may access: which filesystems, which networks, which processes and which provider credentials. The policy is a configuration file a security team can review, version and audit — not a paragraph in a system prompt that drifts every time someone edits it.
Third, supervision. OpenShell’s supervisor feature checks every action an agent takes before it executes, giving teams a choke point where a dangerous step can be blocked or sent to a human for approval. Ecosystem vendors are already building on this hook: Bedrock Data, for example, has added data-loss-prevention controls for OpenShell that screen what data an agent can exfiltrate, first released in September.
Crucially, OpenShell is designed to plug into what an organization already runs — its own compute, inference providers, credential storage and monitoring tools — rather than demanding a rip-and-replace of the stack. Teams can adopt it incrementally and swap components in and out through defined extension points for providers, compute, governance and approval workflows, policy enforcement, isolation and credential management.
Cedar Policies: Rules Agents Cannot Talk Their Way Around
One of the most consequential details in the announcement is the policy language OpenShell is adopting: Cedar, itself a CNCF project. Cedar was built for authorization decisions — expressing, in a precise and auditable form, who (or what) is allowed to do which action on which resource, under which conditions.
Why does the choice of language matter? Because agent security fails in predictable ways when rules are written in plain English. Natural-language instructions are ambiguous, they interact with each other in unexpected ways, and a clever prompt injection can reinterpret them. A formal policy language like Cedar gives security teams rules that mean exactly one thing, can be tested automatically, and can be proven to deny the things they are supposed to deny.
The CNCF highlighted this as an example of its projects building on one another — an agent runtime adopting an authorization language from the same foundation. For teams evaluating OpenShell, the Cedar adoption is also a practical signal: policies written once can be reasoned about, shared as patterns and reused across teams, instead of living as folklore in each team’s prompt library.
Why Handing OpenShell to the CNCF Matters
A security control is only as trustworthy as its governance. If one vendor owns the runtime that decides what every enterprise agent may do, every other vendor and every security team has to take that vendor’s word for it. Moving OpenShell into the CNCF changes the trust model: the project is now governed by the organizations building it into their products, and security professionals worldwide can inspect, audit and improve the code.
Red Hat’s chief technology officer, Chris Wright, put it directly in the announcement: “Open source is the foundation of enterprise trust. As agents become part of cloud native infrastructure, the controls around them need to be open, auditable, and built together with the ecosystem.”
The CNCF is the same foundation that hosts Kubernetes, which makes the move a natural fit. Agents are becoming part of cloud-native infrastructure, and the layer that governs them now sits alongside the projects that already run that infrastructure. The CNCF says working groups and special interest groups will form around integrated components and cross-cutting topics such as observability, and it is inviting contributions in areas including extension implementations, policy and governance patterns, isolation and platform coverage across Linux, macOS and Kubernetes, observability aligned with OpenTelemetry, and packaging with reproducible builds, SBOMs and signing.
For the industry, the message is that agent governance is becoming shared infrastructure rather than a proprietary feature. That matters because the alternative — every vendor shipping its own incompatible guardrails — would leave security teams stitching together a patchwork that no one can audit end to end.
OpenShell, Agent Substrate and the DSX AI Factory Tools
The OpenShell contribution was not NVIDIA’s only announcement at KubeCon. The company also said it is contributing to Agent Substrate, a Google-originated open-source framework for operating long-running agent workloads at scale on Kubernetes, which has also been accepted into the CNCF Sandbox. NVIDIA is making Agent Substrate work with its Dynamo inference software and KAI Scheduler for shared cluster resource allocation, and NVIDIA and Google are collaborating to integrate OpenShell with Agent Substrate so that agent governance can travel across cloud and on-premises systems.
Think of the two projects as complementary halves: Agent Substrate handles the operational problem of running large numbers of long-lived agents without dedicating resources to every session, while OpenShell handles the security problem of what those agents are allowed to do once they are running. Together they sketch the shape of an open, vendor-neutral agent platform — the kind of thing enterprises have been waiting for before they let agents loose on production systems.
NVIDIA also released three open-source components for its DSX AI Factory Platform: NVIDIA Kubernetes Engine, NVIDIA Kubernetes Recipes and NVIDIA Snapshot, all in public preview under Apache 2.0. They cover managed Kubernetes on GPU infrastructure, cluster recipes and inference recovery — the plumbing that lets organizations run AI factories without building every layer themselves.
The thread connecting these announcements is NVIDIA’s deepening open-source commitment: rather than keeping agent infrastructure proprietary, the company is handing the security layer to a neutral foundation and building the operational layers in the open.
What This Means for Teams Running Agents in Production
The OpenShell announcement lands in a week when agent governance is clearly the industry’s preoccupation. Commvault and Zscaler’s partnership to govern and roll back rogue AI agents pairs Zscaler’s security-for-AI controls with Commvault’s recovery tools, so a harmful agent action can be undone, not just blocked. Cisco’s AI Defense work on red-teaming agentic systems attacks the same problem from the testing side, probing agents for weaknesses before attackers do. And DeepMind’s formal verification of Signal’s encryption protocol shows verification techniques maturing fast enough to be applied to real, widely used software. OpenShell fits the same pattern: the industry is building the safety layer for agents in the open, piece by piece.
For a team already running agents, the practical takeaways are straightforward. First, treat agent permissions as infrastructure policy, not prompt engineering — declarative, versioned, auditable rules beat instructions the model can reinterpret. Second, sandboxing is not optional: kernel-level isolation is what keeps a compromised agent from becoming a compromised network. Third, pick governance tooling you can inspect. An open runtime under CNCF governance can be audited by your own security team, which a black-box vendor control cannot.
The timing also matters for the model side of the equation. As cheaper agent models arrive — Meta’s Muse Ember model, built for repetitive agent work, is one example — the cost of running agents falls, and the number of agents in production rises. More agents doing more work means more surface area for mistakes, which is exactly why the governance layer needs to be in place now rather than after the first big incident.
Teams do not need to wait for the CNCF transition to finish to start evaluating OpenShell. The code remains available during the move to the ai-openshell organization, and the project’s extension points mean a pilot can start with one team, one workload and one set of policies, then expand.
What Is Still Unfinished
Honesty requires noting what the announcement does not settle. The transition to the ai-openshell organization is still underway, with code, issues and pull requests remaining at NVIDIA’s repository during the move. Sandbox status is the CNCF’s earliest stage: the project must still earn its way toward incubation with reproducible builds, conformance tests, security reviews and broader platform coverage. The new DSX components — NVIDIA Kubernetes Engine, NVIDIA Kubernetes Recipes and NVIDIA Snapshot — are public previews, not finished products.
None of that diminishes the announcement. Open source has a well-worn path from sandbox to production, and the breadth of the contributor base — NVIDIA, Red Hat, Docker, Canonical and hundreds of adopting organizations — gives OpenShell a stronger start than most Sandbox projects get. But teams planning a rollout should treat the next few months as an evaluation window, not a finish line.
Frequently Asked Questions
What is NVIDIA OpenShell?
OpenShell is an open-source runtime for securing and governing autonomous AI agents. It applies deterministic, policy-based controls to what agents can do as they use tools, access inference services and execute workloads, running them in kernel-isolated sandboxes with declarative YAML policies.
Why did NVIDIA give OpenShell to the CNCF?
To place the project under neutral, community governance. As a CNCF Sandbox project, OpenShell is governed by the organizations building it into their products and can be inspected, audited and improved by security professionals worldwide, instead of being controlled by a single vendor.
What policy language does OpenShell use?
OpenShell is adopting Cedar, another CNCF project, as its policy language. Cedar is designed for authorization decisions and gives teams precise, testable, auditable rules for what agents may do.
Is OpenShell free to use?
Yes. OpenShell is licensed under Apache 2.0, so organizations can use, modify and build commercial products on it without paying a license fee.
How does OpenShell relate to Agent Substrate?
Agent Substrate, a Google-originated CNCF Sandbox project, handles operating long-running agent workloads at scale on Kubernetes. OpenShell handles securing and governing those agents. NVIDIA and Google are collaborating to integrate the two so governance travels across cloud and on-premises systems.
Sources
- CNCF, “Welcoming OpenShell to the CNCF: Open Governance to Secure Agentic AI,” November 10, 2026: https://www.cncf.io/blog/2026/11/10/welcoming-openshell-to-the-cncf-open-governance-to-secure-agentic-ai/
- NVIDIA Blog, “NVIDIA Expands Open Source Commitment With OpenShell Donation and New AI Infrastructure,” November 10, 2026: https://blogs.nvidia.com/blog/open-source-openshell-infrastructure/
- Unite.ai, “NVIDIA Donates OpenShell to CNCF and Adds Open-Source AI Factory Tools,” November 10, 2026: https://www.unite.ai/nvidia-donates-openshell-to-cncf-and-adds-open-source-ai-factory-tools/
