NVIDIA OpenShell
NVIDIA OpenShell is an open source runtime that runs AI agents inside isolated sandboxes and enforces declared policies on their file access, system calls, network connections, credentials and model calls. It is early software: NVIDIA called it an early preview in May 2026, and the docs are at version 0.1.2.12
Also known as OpenShell, OpenShell runtime
At a glance
- What is it?
- OpenShell is an Apache-2.0 open source runtime from NVIDIA for running autonomous AI agents under control. Each agent runs in its own sandbox, and a supervisor outside the sandbox decides, based on a YAML policy, which files, processes, network destinations and credentials the agent may use. NVIDIA announced it in March 2026 as part of NVIDIA Agent Toolkit. Its status is early: NVIDIA's 31 May 2026 announcement says it is available in early preview, and the current documentation (v0.1.2) describes the 0.1.x line as having a stable release cadence, with stable builds intended for production use within the support matrix.456
- What does it do?
- OpenShell starts an agent such as Claude Code, Codex, GitHub Copilot CLI, OpenCode, OpenClaw or a custom agent inside a sandbox with no direct network access. File access is limited with Landlock, risky system calls and privilege escalation are blocked with seccomp and an unprivileged identity, and every outbound connection or DNS lookup is passed to a supervisor that checks it against policy at the level of program, destination, method and path. The agent never holds real credentials: OpenShell inserts them only into requests to endpoints a provider profile allows. Network rules can change at runtime, a policy prover uses formal verification to flag risky new access before it is approved, and every allow and deny decision is logged.124
- Who needs it?
- Developers who let agents write files, install packages, call APIs or run for long periods, and the platform and security teams who must let those agents work without handing them broad access to hosts, networks, secrets or model endpoints. NVIDIA names coding agents, private enterprise development with self-hosted models, and audit of policy files kept under version control as typical uses.12
- What does it need?46
- Linux (Debian or Ubuntu on amd64 or arm64), macOS on Apple Silicon with Docker Desktop, or Windows with WSL 2 and Docker Desktop (experimental)
- Docker, Podman or host virtualization; for Kubernetes, a cluster whose CNI enforces NetworkPolicy
- A Linux kernel with Landlock ABI 3 or newer (Linux 6.2 or later) and the required seccomp features; kernels older than 5.19 run in a reduced legacy read-only mode
- Credentials for the model providers and services the agent should be allowed to use
- What it is not
- OpenShell is not an agent framework or harness; it sits underneath them. It is not just a container sandbox either: it adds credential brokering, policy-controlled egress, inference routing and audit logs on top of Docker, Podman, Kubernetes or VM isolation. It does not replace identity providers, secret stores, observability or governance tools, which stay in place around it. NVIDIA's May 2026 announcement calls it an early preview, and we recommend treating it as an early, fast-moving project, with weekly stable releases and security fixes only for the latest two minor versions.16
Availability and licensing. OpenShell is open source under the Apache 2.0 license on GitHub (NVIDIA/OpenShell). NVIDIA's 31 May 2026 announcement describes it as available in early preview; the documentation is at v0.1.2 and publishes dev, pre-release and stable builds, with stable builds intended for production use within the support matrix. OpenShell collects anonymous operational telemetry by default, which can be switched off.4
The problem it solves
An agent earns its keep by working with files, packages, APIs and secrets, yet that same reach lets a misled or compromised agent upload source code, read SSH keys, send data to an unapproved model provider or escalate privileges. Instructions inside the model prompt cannot reliably stop this, because the model itself can be manipulated.
OpenShell moves the controls outside the agent process. The sandbox, the supervisor and the policy decide what is allowed, independently of what the agent reasons or claims, and the record of each decision is kept for review.12
How it works
NVIDIA's architecture documentation describes these parts:
- Gateway: the control plane. It authenticates users, manages sandbox lifecycles, stores state, attaches providers and delivers policy and settings. It also runs the policy prover.
- Compute runtime: Docker, Podman, Kubernetes or a VM. It creates the sandbox and the supervisor, connects them over a private channel and builds a network fence so the workload can only reach the supervisor.
- Sandbox: lives inside the boundary with the agent, owns its processes, identifies which program makes each request and forwards TCP and DNS operations.
- Supervisor: the trusted side. It checks each request against policy, adds credentials where allowed, resolves DNS and opens approved connections.
Policies are YAML files with filesystem, process and network rules. Filesystem and process rules are fixed when a sandbox is created, while network rules can be reloaded at runtime. Provider profiles tie a credential to the hosts, paths and programs allowed to use it, so an agent calling a model API sees only a placeholder. Logs can be read with the CLI or exported as OCSF JSON. SDKs exist for Python, TypeScript, Go and Rust.24789
Diagram as a list
Applications & solutions
- Developer or operator (CLI, SDK)Creates sandboxes, edits policies and reviews access requestsConnects to Gateway (control plane)
- Sandbox with the agent (Claude Code, Codex, OpenCode, custom)Runs the agent unprivileged and forwards its TCP and DNS operationsConnects to Supervisor
Inference & runtime software
- Model endpoints (self-hosted or cloud)Receive only the model calls that provider profiles allow
Operations & orchestration
- Gateway (control plane)Authenticates users, manages sandboxes, delivers policy and credentialsConnects to Policy prover, Compute runtime (Docker, Podman, Kubernetes, VM), Supervisor
- Policy proverFormally checks proposed network rules for risky new access
- SupervisorChecks each request against policy, adds credentials and opens approved connectionsConnects to Model endpoints (self-hosted or cloud), External APIs and services
Accelerated computing
- Compute runtime (Docker, Podman, Kubernetes, VM)Creates the sandbox and supervisor and builds the network fenceConnects to Sandbox with the agent (Claude Code, Codex, OpenCode, custom), Supervisor
Networking, power & facilities
- External APIs and servicesReached only through approved destinations
Capabilities
Kernel-level sandboxing67
Each agent runs unprivileged in its own sandbox; Landlock limits file access and seccomp blocks privilege escalation and unsafe system calls.
Why it matters: Protects local secrets and the host even when the agent misbehaves.
Limits: Requires specific Linux kernel features; launch fails closed if they are missing.
Policy-controlled network egress7
Every connection and DNS lookup goes through the supervisor and is checked by program, destination, method and path.
Why it matters: Stops uploads to unapproved hosts and limits API use to what policy allows.
Limits: Policies must be written and maintained; overly broad rules weaken the protection.
Credential brokering2
Agents see placeholder credentials; the real value is inserted only into requests to endpoints a provider profile authorizes.
Why it matters: Keeps API keys and tokens out of the agent's reach.
Limits: New environment variables need a new process; providers must be configured per sandbox.
Formal policy verification7
A policy prover checks proposed network rules and flags new credentialed reach, new HTTP methods or cloud metadata access before approval.
Why it matters: Risky policy changes wait for a human instead of being approved automatically.
Limits: It checks policy changes, not the correctness of the agent's work.
Inference routing for model calls110
Model provider access is granted through provider profiles and attachments, so an agent can call self-hosted or cloud model endpoints that policy allows.
Why it matters: Lets teams decide which models each sandbox may use.
Limits: Only endpoints defined in the profile are reachable; other providers are blocked.
Audit logs and observability19
Allow and deny decisions are logged and can be exported as OCSF JSON records.
Why it matters: Gives security teams a reviewable record of what each agent tried to do.
Limits: NVIDIA describes the JSON export as meant for SIEM integration and compliance archival in systems you run.
Multiple runtimes16
Runs on Docker, Podman, Kubernetes through a Helm chart, and a MicroVM runtime: the product page FAQ calls the VM runtime experimental, while the v0.1.2 support matrix lists MicroVM as supported for VM-backed sandboxes.
Why it matters: The same policy can be applied on a laptop, on premises or in the cloud.
Limits: Windows support through WSL 2 is experimental, and runtimes differ in supported features.
Practical use cases
Developers want to run coding agents on real repositories without exposing SSH keys, cloud credentials or the whole network.
- Approach
- Run Claude Code, Codex, OpenCode or GitHub Copilot CLI inside an OpenShell sandbox with file and network access limited by policy.
- Role of NVIDIA OpenShell
- OpenShell enforces the boundary and brokers credentials such as GitHub push access.
- Data, infrastructure and skills
- A supported host and kernel, Docker or Podman, and a policy for the repository and services the agent needs.
- Type of benefit
- Reduced security risk
- Caveats
- Early-stage software; policies need review as the agent asks for new access.
- First step
- Follow the Run Your First Agent guide with a test repository.
Sources 2
An enterprise wants agents to use only self-hosted or approved model endpoints while handling sensitive context.
- Approach
- Attach provider profiles that allow only the approved model endpoints to selected sandboxes.
- Role of NVIDIA OpenShell
- OpenShell restricts model traffic and keeps API keys away from the agent.
- Data, infrastructure and skills
- Approved model endpoints and provider profiles for each of them.
- Type of benefit
- Data control
- Caveats
- Every new provider requires a reviewed profile.
- First step
- Import the NVIDIA example provider profile, narrow it, and attach it to one sandbox.
Sources 2
Security and compliance teams need a reviewable record of what agents may do and what they attempted.
- Approach
- Keep policy YAML under version control and export OpenShell decision logs as OCSF JSON to existing monitoring.
- Role of NVIDIA OpenShell
- OpenShell provides the policy-as-code layer and the audit trail.
- Data, infrastructure and skills
- A log pipeline and a review process for policy changes.
- Type of benefit
- Auditability
- Caveats
- OpenShell does not replace identity, secret management or governance tools.
- First step
- Export logs from one sandbox and confirm that allow and deny records reach your monitoring system.
Sources 2
Works with
Optional integration
- NVIDIA DGXNVIDIA states OpenShell runs on DGX Spark and DGX Station.
Complementary tools
- NVIDIA BioNeMoOpenShell is listed among the core pieces of the BioNeMo Agent Toolkit.
- NVIDIA BlueFieldNVIDIA's Open Agent Safety Platform combines OpenShell with NVIDIA Sentry and BlueField-4 in-silicon enforcement.
Same family
- NVIDIA NemotronBoth are part of NVIDIA Agent Toolkit, according to NVIDIA's March 2026 announcement.
- NVIDIA cuOptNVIDIA lists cuOpt as an open skill in NVIDIA Agent Toolkit alongside the OpenShell runtime.
Relationship labels follow NVIDIA's documentation. "Alternative approaches" does not mean one is better: each profile says when it fits.
Getting started
Check the host4
Use Linux with kernel 6.2 or later (Landlock ABI 3), macOS on Apple Silicon with Docker Desktop, or WSL 2 (experimental), and install Docker or Podman.
Check: The host is listed as supported in the OpenShell support matrix.
Install the CLI and local gateway4
Run the install script from the NVIDIA/OpenShell repository, then create a first sandbox with openshell sandbox create.
Check: A sandbox starts from the default minimal Ubuntu image, which has no agent installed.
Run a first agent4
Follow the Run Your First Agent guide, which starts OpenCode with a no-cost model from OpenRouter and walks through approving access the agent requests.
Check: The agent works inside the sandbox and access requests appear for approval.
Write a network policy2
Use the First Network Policy tutorial to allow only the destinations your agent needs.
Check: A request to a host that is not in the policy is denied and the denial appears in the logs.
Attach a model provider10
Lint and import a provider profile, create a provider from it and attach it to the sandbox.
Check: The agent reaches the allowed model endpoint while its environment shows only a placeholder for the API key.
Official resources
Could this technology help you?
Describe your project to the Solution Architect. It starts with NVIDIA OpenShell as context but recommends independently, including when you do not need it.
Sources
Each statement above links to the source it comes from. Labels say who reported it.
- NVIDIA OpenShell (opens in a new tab)
- NVIDIA OpenShell documentation: overview (v0.1.2) (opens in a new tab)
- NVIDIA newsroom: Enterprise Software Leaders Build AI Agents With NVIDIA, 31 May 2026 (opens in a new tab)
- NVIDIA/OpenShell GitHub repository (README) (opens in a new tab)
- NVIDIA newsroom: NVIDIA Agent Toolkit announcement, 16 March 2026 (opens in a new tab)
- OpenShell documentation: support matrix (opens in a new tab)
- NVIDIA OpenShell documentation: architecture (opens in a new tab)
- OpenShell documentation: accessing logs (opens in a new tab)
- OpenShell documentation: OCSF JSON export (opens in a new tab)
- NVIDIA OpenShell documentation: inference (opens in a new tab)
Thank you. Your correction was sent.
The editors check it against the sources. If you left an email address, they may reply about it.