NVIDIA OpenShell: guardrails that sit outside your AI agents

An AI agent is useful because it can act: read files, install packages, call APIs and use your accounts. That is also what makes it risky. If the only thing stopping an agent from emailing a client file to the wrong place is the agent's own judgment, a confused model or a malicious instruction hidden in a web page can override it.

NVIDIA OpenShell takes a different approach. It puts the rules outside the agent. Each agent runs in a sandbox, and a separate, trusted process decides which files it can touch, which programs can reach which servers, and where credentials may be used. The agent can ask for more access; it cannot grant it to itself.

What OpenShell is

NVIDIA introduced OpenShell at GTC 2026 in March as part of its open-source Agent Toolkit. The project describes itself as "the safe, private runtime for autonomous AI agents." It is written mostly in Rust and released under the Apache 2.0 license.

As of October 28, 2026, the GitHub repository shows about 20,400 stars and 2,000 forks, and v0.1.6 shipped on October 27. Stars measure interest, not production use. The project's support matrix says stable releases generally ship weekly, with security fixes for the latest and previous minor versions.

OpenShell is not an agent. Its default sandbox is a minimal Ubuntu image with no agent installed. You bring the agent, such as OpenCode, Claude Code, Codex or your own Python script, and OpenShell governs what it can do.

How the boundary works

The architecture has three main parts:

• Gateway: the control plane. It authenticates people, stores sandbox records and policies, attaches credentials and coordinates sessions.
• Supervisor: the trusted side of each sandbox. It checks every network request against policy, resolves DNS, adds credentials where they are allowed and opens approved connections.
• Sandbox: the side shared with the untrusted agent. It launches the agent, identifies which program made each request and forwards that request to the supervisor. It never decides whether a request is allowed.

The workload has no direct route to the network. On Docker and Podman, the agent's container has networking turned off; on Kubernetes, a NetworkPolicy allows only the supervisor; in a VM, the guest has no network device. Its only path out is an authenticated channel to the supervisor.

A network request follows the same path every time:

1. The agent opens a connection or makes a DNS lookup.
2. The sandbox identifies the real calling program from kernel process data, not from what the agent claims.
3. The supervisor checks the program, destination and, for inspected HTTP APIs, the method and path against policy.
4. If the request is allowed, the supervisor opens the real connection and relays the traffic.

It also fails closed. The agent does not start until the supervisor confirms the boundary, and if the supervisor disconnects, the agent is frozen rather than left running unsupervised.

On Linux, the sandbox uses kernel features for local controls: Landlock restricts which paths the agent can read or write, and seccomp intercepts network operations so they can be checked.

A policy is a written list of what the agent may touch

A sandbox policy is a YAML file covering four things:

Everything not allowed is denied. The default policy, used when you supply none, has no network rules, so all outbound traffic is blocked. Docker and Podman refuse to run an image as root unless the policy sets a non-root user.

Rules are tied to programs, not just destinations. A rule can let Python call a model API while denying the same host to curl or a package installer. That matters because "the agent" is usually many programs, and a prompt injection often works by getting one of them to send data somewhere new.

Agents never see the real API key

The most practical feature for a small business is credential injection. When a sandbox starts, OpenShell replaces each credential in the agent's environment with an opaque placeholder. The agent writes that placeholder into a request header as usual. The supervisor swaps in the real key only when two checks pass:

1. Network policy allows that program to reach that destination.
2. The credential is bound to that host, port and path.

If an agent is tricked into printing its environment, or sends its key to an unapproved server, it leaks a placeholder that is useless outside the sandbox. We covered why stored provider keys are a real risk in the OpenCode breach. OpenShell's design means the agent never holds the key in the first place.

The same mechanism handles local models. The inference guide shows a sandboxed agent calling an Ollama server on the host machine through a declared endpoint, with no credential at all. The model, the agent and the policy can all run on hardware you control.

Approving new access without handing over the keys

Agents frequently need something the policy did not anticipate: a new documentation site, a package registry, an internal API. OpenShell's policy advisor turns a blocked request into a reviewable proposal. The agent explains what it needs, proposes a narrow rule for one program, host and port, and waits. You approve it, or reject it with a reason so the agent can ask for something narrower. Approved network rules apply without restarting the sandbox. The advisor is off by default, and proposals wait for a person unless you turn on automatic approval.

Before a proposal reaches you, the policy prover checks it using an SMT solver, a tool for proving properties of rules. It flags risky changes, such as sending a credential to a new destination, allowing a new HTTP method, or reaching cloud metadata addresses. Any finding blocks automatic approval.

The prover also runs as a standalone openshell-prover command. You can write a boundary policy describing the most access any agent at your company should have, then check that each agent's policy stays inside it:

result: exceeds_boundary
counterexample: filesystem write /tmp

That output is from the project's own documentation: the candidate policy allowed a write the boundary did not.

Limitations to know before you rely on it

• It is early software. The project is at version 0.1.x, and NVIDIA's launch materials said many described features would be offered "on a when-and-if-available basis." Interfaces marked Experimental can change in patch releases.
• The prover does not cover everything. Boundary checks cover files, process identity, Landlock settings, network connections and REST requests. The prover documentation says a policy using GraphQL or MCP rules is reported as uncheckable rather than verified.
• Allowed is not the same as safe. If policy lets an agent write to your CRM, OpenShell will not judge whether a particular update is correct. It limits the blast radius; it does not review the agent's work.
• Platform support varies. Linux and macOS on Apple Silicon (through Docker Desktop) are supported. Windows through WSL 2 is experimental, and native Windows lives on a separate branch.
• Telemetry is on by default. The README says it collects anonymous operational counts, not prompts, credentials or file paths. Turn it off with OPENSHELL_TELEMETRY_ENABLED=false if your policy requires it.
• Configuration is real work. Each agent needs a policy, provider profiles and someone to review proposals. Since v0.1.6, a gateway refuses to start without authentication unless you explicitly opt out for local development.

What this means for a business running agents

OpenShell does not make an agent trustworthy. It makes trust less necessary, which is a more achievable goal. For a firm that wants agents working on client files, three questions are now easier to answer:

• What can this agent reach? It is written down in a policy file you can read and version.
• Can it leak our keys? Not the real ones; it only ever holds placeholders bound to approved endpoints.
• Who approved new access? A person, through a recorded proposal, after an automated risk check.

A reasonable first step is small: run one existing agent workflow in a sandbox with the default deny-all policy, and add rules only as it needs them. The list of rules you end up with is a useful document in itself: an exact account of what that workflow depends on.

Paired with a local model, OpenShell also fits the setup Looski builds for clients: agents and inference on a machine in your office, with the network boundary under your control. The agent can still call an approved cloud service when a task needs one. That call becomes a recorded decision rather than something the agent does by default.