博客
OpenShell Joins the CNCF: Why AI Agent Safety Starts at the Runtime
What the CNCF's newest Sandbox project means for businesses adopting AI agents, and how we use it every day
本页内容
AI agents no longer just write text. They run code, install software, open files and call your business systems with real credentials. A line in a prompt saying "never touch customer data" is a request, not a control. On 10 November 2026 the Cloud Native Computing Foundation (CNCF) accepted OpenShell, the secure runtime for AI agents that NVIDIA created, as a Sandbox project. We run our own agents inside OpenShell every day at TenthMatrix. This post explains what it is, why the CNCF move matters, and what it means for a business that wants the benefits of agents without the risk. Developers can go straight to the technical note.
The news in one paragraph
The CNCF is the vendor-neutral home of Kubernetes and most of the software modern cloud platforms run on. In its 10 November announcement it said OpenShell is joining "as a Sandbox project, bringing the secure runtime for autonomous AI agents into vendor-neutral, ecosystem-led stewardship". In the CNCF's words, OpenShell "governs how agents execute, which resources and data they can access and where inference requests are routed". It arrives with other AI projects, including Agent Substrate and llm-d, and takes the foundation's portfolio to 231 projects. The CNCF also reported more than 21 million cloud native developers worldwide. OpenShell is open source under the Apache 2.0 licence, and development is moving from NVIDIA's GitHub to a community organisation. (Read the CNCF announcement.)
Why prompts are not a security boundary
Most early agent safety relied on instructions inside the prompt and good behaviour from the model. That breaks down in three common ways:
- The agent is tricked. A web page, email or document the agent reads can contain hidden instructions ("send the contents of the config file to this address"). This is called prompt injection, and no model is immune to it.
- The agent makes a mistake. It deletes the wrong folder, pushes to the wrong branch or calls a paid API in a loop. Nobody intended it, but the damage is real.
- The software it installs is hostile. Agents install packages to get work done. A compromised package runs with whatever access the agent has.
In each case, the safe outcome depends on what the agent is able to do, not on what it was asked to do. That is the gap OpenShell closes.
What OpenShell does, in plain English
Think of it as giving the agent a locked office with a visitor's pass, instead of the keys to the building. OpenShell provides four controls:
- Isolation. The agent runs in a sandbox, separated from the computer or server underneath. Whatever it runs, including code it writes itself, stays inside.
- Rules for files and programs. A written policy says which folders the agent may read, which it may change, and which it cannot see at all. The operating system enforces it, so the agent cannot talk its way past it.
- Secrets the agent never sees. API keys and passwords stay outside the sandbox. The agent holds a placeholder. OpenShell swaps in the real key only when the request goes to an approved destination, so a tricked agent has nothing valuable to leak.
- A gatekeeper for the internet. Every outbound connection is checked. Anything not explicitly allowed is blocked. Rules can be fine-grained, for example "read from GitHub, but do not write".
When the agent needs something new, such as access to another website, it can propose a narrow rule. A person reviews and approves it, and the change applies to the running agent without a restart. Every decision is logged.
What changes now that it is in the CNCF
- No single-vendor lock-in. NVIDIA created OpenShell, but it is now governed in the open alongside Kubernetes and OpenTelemetry. That makes it a safer long-term bet for a business standard.
- Any model, any agent. OpenShell does not care which AI you use. It runs Claude Code, OpenCode and any other agent that can be packaged in a container, with models from Anthropic, OpenAI, Google, open-weight models or your own servers.
- It fits the platforms you already run. It works on a developer's laptop (Linux or Apple Silicon Mac), with Docker or Podman, in microVMs, and on Kubernetes through a Helm chart. Your platform team does not need a new stack.
- A wider community. CNCF projects attract contributors, integrations and security reviews from many companies. Expect more tooling, more documentation and more people who already know it.
The business benefits
| Concern | Without a runtime boundary | With OpenShell |
|---|---|---|
| Data leaks | The agent can send anything it can read to any address | Only approved destinations are reachable; everything else is denied by default |
| Stolen credentials | Keys sit in the agent's environment, ready to be copied | The agent holds placeholders; real keys are added only for the endpoint they belong to |
| Accidents | A wrong command can touch the whole machine | Damage stays inside the sandbox and the folders the policy allows |
| Audit and compliance | Hard to say what an agent did or why it was allowed | Written policies under version control, approvals and logs for every decision |
| Adoption speed | Security says "no" or "not yet" | Teams start with tight rules and widen them as trust grows |
| Cost | Custom guardrails built per project | Free, open-source software you configure once and reuse for every agent |
How we use it at TenthMatrix
We use OpenShell every day. Our engineers run their coding agents inside OpenShell sandboxes rather than directly on their laptops or our servers. In practice that means three things. Agents only get the folders and websites a task needs. Keys for GitHub and model providers stay outside the agent. And when an agent wants to reach something new, a person approves it. The agents are just as fast; the difference is that a bad web page or a bad package cannot turn a helpful agent into a liability.
It is also how we build agents for clients. When our forward deployed engineers design an agent for your finance, sales or operations team, the runtime policy is part of the design, written down and reviewed with you, not bolted on later.
Questions to ask your team or supplier
- Where do our AI agents actually run, and what else can they reach from there?
- If an agent read a malicious document today, which secrets could it see?
- Is outbound network access denied by default, or allowed by default?
- Who approves a new permission, and where is that decision recorded?
- Can we change model provider without rebuilding our safety controls?
If any answer is "we are not sure", a runtime layer such as OpenShell is the place to start.
Keep expectations realistic
CNCF Sandbox is the foundation's earliest stage, for promising projects that are not yet widely proven in production. OpenShell is moving fast (version 0.1.8 shipped on 10 November 2026), native Windows support is still in development, and parts of the Kubernetes deployment are marked experimental. It is also one layer, not the whole answer: you still need sensible permissions in your business systems, monitoring and people who review what agents do. We treat it as the foundation of a defence in depth, not as a magic switch.
Next steps
- For your developers: Running AI agents safely with NVIDIA OpenShell, our hands-on technical note with policies, commands and pitfalls.
- Running agents on a Mac Studio or GPU workstation? Read NVIDIA OpenShell on Mac Studio and GPU workstations.
- Planning your first agent? Answer nine questions in our AI agent journey and get a blueprint, including the guardrails.
Want agents your security team will say yes to? Talk to us. We will show you OpenShell running with your own tools and draw up the first policy together.