Skip to content
Update4 min read

NVIDIA OpenShell: A Deny-by-Default Runtime for Autonomous AI Agents

NVIDIA OpenShell is an open source runtime that puts a hard boundary around autonomous AI agents. Each agent runs in a sandbox where nothing is permitted by default. You declare what it may touch in a policy, and OpenShell enforces that policy from outside the agent's own process. The current release is v0.1.2, published on September 28, 2026.

The short version

OpenShell
WhatA sandbox runtime and control plane for AI agents
DefaultDeny: no file, system call or network access unless a policy grants it
LicenceApache 2.0
Latest releasev0.1.2, September 28, 2026
Runs onDocker, Podman, Kubernetes through Helm
HostsLinux, macOS on Apple Silicon, Windows with WSL 2 (experimental)
AgentsClaude Code, Codex, GitHub Copilot CLI, OpenCode, LangChain Deep Agents and others
SDKsPython, TypeScript, Go, Rust

It is not an agent framework. It does not replace the agent you already run; it decides what that agent is allowed to reach.

How a request leaves the sandbox

An agent is useful when it can read files, install packages, call APIs and use credentials. Each of those is also how an agent does damage when it is wrong or has been manipulated. OpenShell's answer is to take the decision away from the agent.

Trace05 stops

One outbound request from a sandboxed agent.

  1. AGENT.CALLAgent actsThe agent runs in a sandbox with no direct network access.
  2. POLICY.CHECKSupervisor checksOutside the sandbox, the request is matched against policy: binary, destination, method and path.
  3. CRED.INJECTCredentials addedReal credentials are attached only to requests bound for approved endpoints.
  4. TOOL.RESULTRequest sentThe call goes out. A denied one stops at the check.
  5. AUDIT.LOGDecision loggedEvery allow and every deny is recorded.
The check happens outside the agent's process, so the agent cannot talk its way past it.

Two parts of that design stand out.

The agent never holds real credentials. OpenShell adds them to a request only when it is headed somewhere approved. An agent that has been tricked by a prompt injection has no API key to leak.

Policy changes are checked before they apply. A component called the policy prover uses formal verification to flag risky new access a change would grant, such as reaching a new host with credentials, so that change waits for a person to review it.

Trying it

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demo

The installer sets up the CLI and a local gateway. The default sandbox is a minimal Ubuntu image with no agent in it; NVIDIA's guide walks through running a real one. On Kubernetes, the gateway installs through Helm, and your CNI has to enforce NetworkPolicy.

One thing to check before you roll it out: OpenShell collects anonymous telemetry by default. It can be switched off with OPENSHELL_TELEMETRY_ENABLED=false on the gateway.

Where this fits

Guardrails inside the model and the prompt lower the odds that an agent tries something it should not. They do not bound what happens when it tries anyway. A runtime like this is the other half: it limits what the agent can reach regardless of what it decides.

That is the principle we work to on every system: give agents controlled authority, not unrestricted access. Least-privilege tool access, sandboxing, runtime isolation, approval gates and audit logs are the controls, whichever product enforces them. OpenShell packages several of them into one open runtime.

It does not cover everything. A sandbox does not decide which actions need a human approval, does not test your agent against injection attempts, and does not tell you whether the policy you wrote is the right one for your business. Those remain design work, and they are what AI agent security is about.

We have not put OpenShell into a production system. It is at version 0.1, so treat it as something to evaluate now and standardise on once the APIs settle.

Sources

Related.