OpenShell is a runtime that puts an agent’s permissions in the kernel instead of in a system prompt. Each agent runs in its own sandbox, every file access, system call and outbound connection is checked against a declared policy, and the agent never holds a real credential. NVIDIA published it under Apache 2.0, and the 0.1.x line is the first with a stated stable release cadence (source).

Key facts

Fact Detail
Question answered NVIDIA OpenShell: A Kernel-Enforced Runtime for Fleets of Agents
Short answer OpenShell is NVIDIA’s Apache-2.0 runtime for autonomous agents: kernel-enforced file, syscall and network policy per sandbox, credentials injected only for approved endpoints, and formal verification of policy…
Reading time ~4 min
Last updated 2026-10-23

The sandbox is not the novel part — plenty of tools sandbox a process. The two parts worth studying are that policy changes are formally verified before they take effect, and that credentials live outside the agent’s environment and are attached per request.

What the project actually claims

The README is specific, which makes it checkable:

  • Each agent runs in an isolated sandbox. Kernel controls confine which files it can reach and which system calls it can make.
  • Every network connection passes a policy check before it leaves the sandbox.
  • Agents never see real credentials; OpenShell adds them only to requests bound for approved endpoints.
  • Before a policy change is approved, formal verification reports what the change would newly allow — reaching a new host with credentials, calling a new API method — and those additions wait for human review.
  • The pieces are a gateway (control plane for sandboxes, policy and access), a supervisor, and the sandbox itself.

0.1.x is described as bringing a stable release cadence, new isolation primitives, an expanded extension surface and new APIs. The gateway can run on Kubernetes via Helm, with a caveat that matters: your CNI has to actually enforce NetworkPolicy, otherwise the network boundary is a YAML file. SDKs exist for Python, TypeScript, Go and Rust.

The project is also candid about telemetry: anonymous operational counts only, with documented opt-outs (OPENSHELL_TELEMETRY_ENABLED=false, or server.telemetryEnabled=false for Helm) and the option to compile it out.

Where Windows actually stands

The support matrix is the first thing to read on this site: OpenShell needs Linux, macOS on Apple Silicon, or Windows with WSL 2, marked experimental, plus Docker, Podman or host virtualization.

That is a real boundary, not a footnote. A WSL 2 backend governs processes inside the Linux VM. It cannot put a kernel policy around a Win32 process that clicks buttons in a native app or writes to C:\Users\.... So for the desktop-agent case — the one where an agent operates the machine you are sitting at — OpenShell today gives you a governed Linux workspace, not a governed Windows desktop.

What transfers is the design, and it transfers well:

  • Capability by declaration, not by prompt. “You may read this directory and reach this host” is a policy object the runtime enforces, not an instruction the model is asked to respect.
  • Credentials outside the agent. Endpoint-bound injection means a stolen key from a compromised agent is not directly replayable against an arbitrary server. That is a stronger property than rotating keys after an incident.
  • Approval on the delta. Asking “what does this policy change newly allow” before applying it catches the failure mode where permissions creep one small edit at a time.

What to verify before you adopt it

  • Does the policy cover the credential store itself? If the sandbox can read ~/.aws/credentials or a browser profile, endpoint binding helps less than it looks.
  • Is the audit trail outside the sandbox? A log the agent’s own sandbox can write is advisory. This is the lesson from the recent round of agent incidents, and it applies to any runtime, including this one.
  • Who reviews a formal-verification flag? The prover is only as good as the queue behind it. If nobody owns that queue, “waits for human review” becomes “waits forever” and then gets auto-approved.
  • What does the default image contain? The quickstart lands you in a minimal Ubuntu sandbox with no agent installed, which is the right default; check what your own image adds before you hand it credentials.

If your work is on Windows and you want an agent operating the desktop rather than a Linux VM, that is a different layer of the stack: you can download MOOGH and review its permission surface before connecting anything sensitive.

The bottom line

OpenShell is the most concrete public answer so far to “what should the runtime enforce, rather than ask?” — kernel-level policy per agent, endpoint-bound credentials, and a review gate on policy deltas. It drew 319 points and 165 comments on Hacker News the day it landed (discussion), which is a fair signal of how much demand there is for this layer. On Windows, treat it as a WSL 2 workspace tool for now, and borrow the design even if you do not run the binary.

Related reading: