# What NVIDIA OpenShell Adds to Agent Sandboxes

Canonical: https://www.kartikaydhar.com/blog/nvidia-openshell-agent-sandbox
Published: 2026-10-24T03:14:03.746976+00:00
Updated: 2026-10-24T02:45:32.047822+00:00
Category: AI & LLM

NVIDIA OpenShell is an open-source Rust runtime that sandboxes AI agents and enforces YAML policy at the kernel. Here is how it works and what it locks down.

NVIDIA OpenShell is an open-source runtime for fleets of autonomous AI agents. You declare what each agent can touch in a YAML policy, and the runtime enforces that policy outside the agent process.

## What is NVIDIA OpenShell?

OpenShell is written in Rust and licensed under Apache 2.0. NVIDIA announced it on March 16, 2026 as part of the NVIDIA Agent Toolkit. The project lives at github.com/NVIDIA/OpenShell, with about 18,850 GitHub stars at the time of writing. Docs at docs.nvidia.com/openshell cover v0.1.5.

In NVIDIA's words, agents are most useful when they can read files, install packages, call APIs and use credentials, and OpenShell gives them that access without unrestricted reach into your data, secrets or network. A system prompt can ask an agent to behave; OpenShell can deny the action when it does not.

Image: Diagram of how OpenShell enforces a request: the agent asks inside the sandbox, the supervisor checks YAML policy on the trusted side, then the request is allowed and relayed or denied and logged

## How does OpenShell enforce policy?

OpenShell splits work across a gateway, a supervisor and a sandbox. The gateway manages sandbox lifecycle, policy and access. Creating a sandbox starts a workload and a separate supervisor, builds the isolation boundary, and keeps a protected channel between them.

The agent runs inside the sandbox. On Linux it uses one non-root identity. Landlock limits filesystem access. Seccomp stages network operations so every TCP open and DNS lookup goes to the supervisor first. The sandbox identifies which program made the request. The supervisor checks policy, adds credentials only when allowed, and opens the real connection if the request passes. If the supervisor disconnects, the sandbox freezes the agent.

Before a policy change is approved, a policy prover can flag risky new access, such as a new host with credentials or a new API method, so those changes wait for human review. The prover also ships as openshell-prover for CI.

Image: Diagram of OpenShell sandbox policy layers: filesystem via Landlock, process limits, default-deny network rules, and provider credentials injected only for approved endpoints

## What does a sandbox policy control?

A policy file sets version: 1. OpenShell denies anything the policy does not allow.

- Filesystem. Paths the sandbox may read or write. Enforced by the Landlock LSM and locked at sandbox startup.
- Process. User and group for sandbox processes, plus syscall limits that block privilege escalation. Also fixed at creation.
- Network. Default deny. Rules can name a host, port, binary and request shape, including read-only HTTP methods such as GET. Network rules and middleware can change while the sandbox runs.
- Provider credentials. Agents never see real secrets. OpenShell injects them only into requests bound for approved endpoints.

NVIDIA's docs map these controls to common threats: uploads to unapproved hosts, theft of local secrets, calls to unapproved model providers, and privilege escalation.

network_policies:
  github_api:
  - host: api.github.com
    port: 443
    protocol: rest
    access: read-only
  - path: /usr/bin/curl

That example comes from NVIDIA's first-network-policy tutorial. With access: read-only, GET can pass while POST is denied on the same host.

## Where can you run it?

Supported hosts are Linux on amd64 and arm64, and macOS on Apple Silicon. Windows with WSL 2 is experimental. Sandbox runtimes include Docker, Podman, Kubernetes and MicroVM. The Linux boundary needs Landlock ABI 3 or newer and the seccomp features OpenShell probes at launch; failed checks stop the workload.

A quick local start from the README:

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

There are SDKs for Python, TypeScript, Go and Rust, plus a Helm chart for Kubernetes. OpenShell also ships Agent Skills that teach a coding agent to drive the CLI and write policies (npx skills add NVIDIA/OpenShell). That sits beside the Agent Skills standard in Agent Skills Joins the Agentic AI Foundation and the harness themes in What YC's QM Teaches About Rolling Out AI Agents.

## Frequently asked questions

### Is OpenShell only for NVIDIA GPUs?

No. The public docs describe it as a runtime for sandboxed agents with Docker, Podman, Kubernetes or MicroVM. GPUs are optional for sandbox images that need them; the isolation story is about files, processes, network and credentials.

### Can an agent change its own policy?

Network rules can reload while a sandbox runs, and agents can propose narrow network rules through the policy advisor, but OpenShell's design keeps approval and enforcement outside the agent. Risky changes flagged by the prover wait for human review.

### Does OpenShell collect telemetry?

Yes, anonymous operational counts by default. NVIDIA says it does not collect sandbox names, hostnames, file paths, prompts, credentials, provider or model names, or user content. You can disable it with OPENSHELL_TELEMETRY_ENABLED=false, or compile telemetry out.

### What license is it under?

Apache License 2.0.

## Sources

- NVIDIA/OpenShell on GitHub
- OpenShell overview (NVIDIA docs)
- OpenShell architecture
- Sandbox policies overview
- Support matrix
- Write your first sandbox network policy
- NVIDIA Agent Toolkit announcement (March 16, 2026)
- Run Autonomous Agents More Safely with OpenShell (NVIDIA Technical Blog)