Inside NVIDIA OpenShell: Zero-Trust Runtime Security for Autonomous AI Agents

NVIDIA OpenShell explained: how zero-trust sandboxes, provable policy, and a privacy router keep AI coding agents secure at the kernel level.

Inside NVIDIA OpenShell Zero-Trust Runtime Security for Autonomous AI Agents

This post is a technical walkthrough of NVIDIA OpenShell, an open-source runtime that runs AI coding agents in isolated, policy-governed sandboxes. We will review the architecture, including the gateway that holds your credentials, the sandbox that contains each agent, the Policy Prover that verifies what an agent can and cannot do, and the Privacy Router that decides where inference runs.

By the end, you will have a model of how the parts fit together, why the security controls sit where they do, and how to spin it up on your own machine.

Reference here.

The two ideas that shaped OpenShell

OpenShell exists because software is moving into an agent world, and an agent-native stack does not look like the stack we built for humans. Two ideas drive the whole design.

The first is that agents are long-running and stateful. They hold sessions, accumulate context, spawn sub-agents, and persist work across hours or days. Bolting that behavior onto tooling built for short-lived human sessions produces the exact friction every developer already feels: approve this, approve that, approve the next thing.

The second is that agent tooling has to run at machine speed. A human waits patiently for a build. An agent burning tokens and wall-clock time on every permission check does not, and the cost compounds. Every millisecond of latency ripples across a fan-out of agents working in parallel.

Put those together, and the target becomes a trusted runtime: something secure by design, so you can hand real capability to an autonomous agent and still reason precisely about what it can reach. The agents are already useful. The environment you can trust them in has been the missing piece.

Zero trust, and why the blast radius is one sandbox

OpenShell is zero-trust by default. Nothing is permissive out of the box. Every sandbox starts fully closed, and the agent earns access only as it is explicitly granted. If you have read Microsoft’s framing of the model, this is the same “never trust, always verify” posture applied to a new kind of workload. Microsoft’s Zero Trust overview is a good companion, and the full URL is in the references.

The decision that carries the most weight is where credentials live. In OpenShell, the agent never holds secrets, tokens, or keys. When an agent needs to authenticate to a service, the gateway that sits outside the sandbox holds those credentials and uses them on the agent’s behalf. The agent gets the result of an authenticated call, never the key that made it.

This is the answer to prompt injection, the defining vulnerability of the agent era. If an attacker slips a malicious instruction into content the agent reads, and the agent holds no secrets in the first place, there is nothing to exfiltrate. The sandbox becomes the blast radius, and the blast radius is exactly one sandbox. It is the same shift we made going from stateful monolithic virtual machines to container-based microservices on Kubernetes: once you can treat workloads as cattle rather than pets, they get far easier to govern. Agents get the same treatment.

The most important architectural move is where enforcement happens. Most agent controls today live at the model layer, inside the probabilistic loop, expressed as instructions and system prompts. Instructions can be argued with. OpenShell pushes governance down to the infrastructure and kernel layer, out of the agent’s reach, where it is deterministic. An agent cannot reason its way around a boundary it cannot see or touch.

In practice, that means Landlock for filesystem access control below standard UNIX permissions, and seccomp for syscall filtering, the same kernel primitives that harden production container runtimes, pointed at agent execution.

The architecture: gateway, sandboxes, and sub-agent isolation

OpenShell is a runtime, entirely open source under Apache 2.0, with its roadmap and architecture published in the open.

Under the hood it is written primarily in Rust and runs as a lightweight K3s cluster inside a single container, so you do not need to stand up Kubernetes to try it. A few primitives do the real work.

Here is the shape of it:

The gateway is the control plane. It sits outside every sandbox, holds the credentials and tokens, and mediates every interaction. Each agent gets a session, but no path to leak anything beyond it.

The sandbox is the unit of isolation. Every agent, every sub-agent, and every piece of tooling runs in its own dedicated sandbox. When an agent spawns sub-agents, each lands in its own sandbox, and they communicate across a controlled boundary instead of sharing a process space.

Here is the part worth dwelling on. In the familiar Copilot or Claude Code model, the agent runs outside the sandbox and executes code within it, with governance residing in the tool. In OpenShell, the agent itself runs inside the sandbox, and every input and output crossing that boundary is enforced by the runtime. The payoff is portability: one policy language governs any agent you run, whether it is Copilot, Codex, Claude Code, or something you wrote yourself. The control point moves out of the agent and becomes uniform across your fleet.

OpenShell splits policy into four domains, and the static versus dynamic distinction is a performance and safety choice. Filesystem and process rules are locked at sandbox creation and cannot change while the agent runs, which is what makes them trustworthy. Network and inference rules are hot-reloadable on a live sandbox, which is what keeps the runtime fast. That hot reload matters more than it sounds. In a traditional container you would restart the whole sandbox to change a policy and eat the latency. OpenShell reloads policy in place, so an agent never stalls waiting for a boundary to shift.

Credentials are handled through providers: named credential bundles injected into a sandbox as environment variables at creation. They never touch the sandbox filesystem, and the agent never enumerates them. And because the sandbox boundary is pluggable, OpenShell exposes drivers. At launch you pick the isolation perimeter you want underneath (Docker, Podman, a MicroVM through something like Firecracker, hardened containers, trusted computing, or Kubernetes sandboxing), and OpenShell enforces its runtime on top of whatever you chose.

The Policy Prover: proving what an agent can still do

This is the component that makes OpenShell more than a sandbox. Most policy engines answer one question: is this specific action allowed? OpenShell’s Policy Prover answers a harder and more useful one: if I enforce this policy, what can this agent still do?

The approach takes OPA and Rego, the standard policy languages many teams already write in, and describes the policy in formal logic. If you have worked with formal verification and SMT solvers, you know where this goes. Instead of an if-statement that checks whether the agent can reach the internet or write to a repository, the Prover constructs a mathematical proof about the policy’s consequences. The lineage traces back to a field that Microsoft Research helped define through the Z3 solver.

Why does a proof beat a check? Because of what OpenShell is guarding against. The industry’s current answer to reducing human approvals is to put another trusted agent in the loop to review each sandbox change, the auto-approver pattern showing up around Codex and managed agents for Claude. The problem is structural: a reviewing agent is probabilistic, and anything probabilistic can be fooled, exactly like a person can. The Policy Prover cannot be fooled, provided the logical description of the policy is correct. If a change opens a new hole, say granting write access to a new GitHub repository, no prompt is clever enough to make the Prover fail to see it. It sees the expansion and flags it, every time.

The second reason it works in practice is speed, which loops straight back to the machine-speed idea. Stacking a reviewing agent on every call doubles your token cost and your latency. The Prover runs in single-digit milliseconds, fast enough that the expensive second-level review often is not needed at all. Security that is close to free is security teams will actually leave switched on.

The Privacy Router: keeping PII local while borrowing global compute

The Privacy Router is where OpenShell’s roots show. The team behind it previously built Gretel, a synthetic data company later acquired by NVIDIA, and the router borrows heavily from that work, including differential privacy research that Microsoft also contributed to.

Traditional isolation (gVisor, hardened containers, MicroVMs) reduces attack surface by adding layers between a process and the kernel. Useful, but agentic behavior is a different animal that shows up in ways process isolation was never designed for. The Privacy Router isolates the behavior itself by deciding where inference is allowed to go, based on what is in the query. Three cases make it concrete.

First, an agent needs to run inference on data full of personally identifiable information. The router detects the PII and routes the query to a local model, so the sensitive data never leaves the environment.

Second, an agent needs multi-turn reasoning and orchestration that only a frontier model delivers, and the router sees no PII in the request. It lets the query route out.

Third, and most interesting, is the combination. The router uses smaller local models and differentially private, fine-tuned models with low epsilon values to synthetically rewrite the query, preserving its utility while stripping the PII. The rewritten query goes out to a frontier model, reasons, and returns, and the environment rehydrates the result with the original context. You keep context and PII local while still borrowing global compute. For any team that wants frontier-model capability but cannot let regulated data leave its perimeter, this is the pattern that unlocks it.

Pattern one: GitHub as a persistence layer for a fleet of agents

OpenShell ships a reference example that answers a real operational question. Ephemeral agents are great: they spin up, do a job, and spin down. But if they are ephemeral, how do they communicate, and where do they store results? For durable artifacts and audit trails, OpenShell’s answer is GitHub itself.

The example follows a classic map-reduce, or fan-out, pattern. OpenShell fires up five sandboxes, each with a coding agent (Copilot or Codex) working an independent task.

Each agent writes its notes to exactly one file in a GitHub repository, which by design makes overlapping, destructive writes impossible. A separate synthesis agent then reads across all of those notes and combines them into a single result. Concurrency is built in, so you can restart a sandbox as many times as you like without agents stomping on each other’s work.

Two details carry the security story. First, the GitHub policy is a scoped OPA and Rego policy tied to a single agent execution, granting access only to specific REST endpoints. If the agent needs more, it has to negotiate for it. Second, the agent never sees the GitHub credentials. The gateway manages them at the supervisor level, and the terminal interface visibly hides them from the agent. That developer-facing terminal, styled after tools like k9s, lets you watch each isolated sandbox coordinate in real time and reason about what every agent is doing.

For higher-rate, agent-to-agent coordination, Google’s A2A protocol is a natural complement. The takeaway is simple: use fast protocols for live coordination, and use GitHub when you want a durable, auditable record of what the agents actually did.

Pattern two: an agent that negotiates its own permissions

This is the pattern that turns OpenShell from a sandbox into a governance system.

The setup: a Codex agent starts with read-only access to GitHub and is told to write to a repository. Watch what happens. The agent tries the write. OpenShell blocks it at the boundary. Instead of a dead end, the runtime hands the agent an explanation for the denial and a pointer to a local skill it can use. The agent uses that skill to enumerate the sandbox policies it is allowed to see, works out what it is missing, and drafts a proposal to extend its own policy with a network rule granting access to that specific repository endpoint.

This is where zero trust and negotiation meet. Because every global policy your organization allows is made visible to the agent inside the sandbox, the agent can reason about what it needs and ask for precisely that, and no more. But the request is never granted blindly. Agents are good at chaining capabilities into unintended paths, so the Policy Prover runs against the proposal first and checks for any accidental exfiltration route the change might open. In the reference run it finds one item, that the change expands the agent’s credential scope, judges it acceptable against the rules, auto-approves it, hot-reloads the policy, and lets the write through. Every step is logged.

Those logs use OCSF, the Open Cybersecurity Schema Framework, so the audit trail drops straight into Splunk, Datadog, or whatever your security team already runs. You can trace the exact sequence: write attempted, write denied, proposal authored, gateway approved, policy reloaded, write succeeded.

Now scale it. Once you are running millions of sandboxes, even a one percent human-approval rate becomes thousands of prompts a day. The stated goal is to remove roughly 90 percent of the approvals a workflow would normally require, ideally collapsing a whole task down to one or two human sign-offs. And the ceiling is never the agent’s to raise. Central IT and security teams define the global maximum, the agent negotiates only within it, and the moment a request exceeds that ceiling, a person has to approve. Because enforcement lives at the kernel and infrastructure layer, that ceiling sits out of the agent’s reach, where it cannot be bypassed, overridden, or reasoned around.

The Microsoft angle: Windows, WSL, and GitHub Copilot

At Microsoft Build 2026, Microsoft announced that OpenShell is coming to Windows on top of its new execution and containment primitives, and that it is now integrated into GitHub Copilot. On Windows the integration rides on Microsoft eXecution Containers (MXC), a cross-platform, policy-driven execution layer that Windows and the Windows Subsystem for Linux enforce at runtime. OpenShell is one component of a broader Windows Agent Runtime, and it reaches Linux-first agent toolchains through WSL.

The conceptual overlap with Microsoft’s platform is tight, and it is worth mapping out. OpenShell’s “agent holds no secrets” design is the same instinct behind Microsoft Entra Agent ID, where each agent gets a scoped identity and authenticates to downstream systems without embedding credentials in prompts or code. OpenShell’s per-sandbox blast radius mirrors the isolation model in Azure’s Foundry Agent Service, where hosted agents run in VM-isolated sandboxes. And OpenShell’s zero-trust default is a direct application of the principles in Microsoft’s Zero Trust guidance for developers. The references include the exact Microsoft Learn pages for each, so you can line the two models up side by side.

The distribution story shows how fast this is moving. OpenShell is being embedded across Windows native and WSL, Azure, GitHub, Ubuntu through Canonical, Red Hat OpenShift, and Docker, with partners exploring running their own agents inside it for trust.

How to try it today

OpenShell debuted in alpha at NVIDIA GTC in March 2026 and is maturing toward beta. It stays Apache 2.0, and the long-term intent is to donate it to the CNCF or the Linux Foundation, which would put its governance in neutral hands, the same path that gave us Kubernetes. Active work is focused on the drivers model (more sandboxing perimeters like Firecracker MicroVMs and Kubernetes sandboxing) and on hardening the negotiation loop.

It is early software: single-player, one developer, one environment, one gateway, with rough edges. But it runs today. You install it, point it at Docker, Podman, a MicroVM, or Kubernetes, and drop a coding agent in with one command:

openshell sandbox create -- claude   # or codex, copilot, opencode

Any of those agents runs unmodified inside the sandbox, governed by declarative YAML policy that you can version in your repository and reload on the fly. If you want to pressure-test the ideas in this post, that is the fastest way in.

Final Thoughts

We have spent time focused on what agents can do, hooks, gates, prompts, and guardrails, and much less on where they do it. Instructions live inside the agent, and anything inside the agent can be talked out of. OpenShell moves the boundary outside the agent and down to the kernel, where the agent cannot see it, cannot reach it, and cannot argue with it.

That single relocation is what makes everything else click. The gateway keeps secrets away from a workload that might get injected. The Policy Prover replaces a hopeful review with a mathematical one. The Privacy Router lets sensitive data stay home while the agent still borrows a frontier model’s reasoning. And the negotiation loop lets agents ask for exactly the access they need, inside a ceiling a person set, so the number of approvals a human has to click drops sharply without giving anything away.

The best part is that none of this asks you to change your agent. Copilot, Codex, and Claude Code run unmodified, and the whole thing is open source and installable right now. If you have been holding autonomous agents at arm’s length because you could not answer the question “what exactly can this reach,” OpenShell gives you a clean, auditable way to answer it. That is a solid place to start building.

References

NVIDIA OpenShell, GitHub repository: https://github.com/NVIDIA/OpenShell

NVIDIA OpenShell Community edition, GitHub repository: https://github.com/NVIDIA/OpenShell-Community

NVIDIA Technical Blog, “Run Autonomous, Self-Evolving Agents More Safely with NVIDIA OpenShell”: https://developer.nvidia.com/blog/run-autonomous-self-evolving-agents-more-safely-with-nvidia-openshell/

NVIDIA Blog, “NVIDIA Partners With Microsoft on Unified Stack for Agentic AI Deployment”: https://blogs.nvidia.com/blog/microsoft-build-windows-local-cloud-devices/

Microsoft Windows Developer Blog, “Windows platform security for AI agents” (MXC and OpenShell on Windows): https://blogs.windows.com/windowsdeveloper/2026/06/02/windows-platform-security-for-ai-agents/

Microsoft Learn, Zero Trust as a security foundation: https://learn.microsoft.com/en-us/security/zero-trust/zero-trust-overview?WT.mc_id=AZ-MVP-5000671

Microsoft Learn, Develop using Zero Trust principles: https://learn.microsoft.com/en-us/security/zero-trust/develop/overview?WT.mc_id=AZ-MVP-5000671

Microsoft Learn, Zero Trust security in Azure: https://learn.microsoft.com/en-us/azure/security/fundamentals/zero-trust?WT.mc_id=AZ-MVP-5000671

Microsoft Learn, Windows Subsystem for Linux documentation: https://learn.microsoft.com/en-us/windows/wsl/?WT.mc_id=AZ-MVP-5000671

Microsoft Learn, What is Windows Subsystem for Linux: https://learn.microsoft.com/en-us/windows/wsl/about?WT.mc_id=AZ-MVP-5000671

Microsoft Learn, Agent identity concepts in Microsoft Foundry (Entra Agent ID): https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/agent-identity?WT.mc_id=AZ-MVP-5000671

Microsoft Learn, What is Microsoft Foundry Agent Service: https://learn.microsoft.com/en-us/azure/foundry/agents/overview?WT.mc_id=AZ-MVP-5000671

Microsoft Learn, Govern and secure AI agents across the organization (Cloud Adoption Framework): https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/governance-security-across-organization?WT.mc_id=AZ-MVP-5000671

Microsoft Learn, Governing agent identities with Microsoft Entra ID Governance: https://learn.microsoft.com/en-us/entra/id-governance/agent-id-governance-overview?WT.mc_id=AZ-MVP-5000671

*-Dave R.*