NVIDIA launched its Open Agent Safety Platform on September 28, 2026, and only one piece of it runs on your own machine tonight: OpenShell, the Apache 2.0 agent sandbox that reached version 0.1.2 the same day. The other headline piece, Sentry, is a watchdog that runs on BlueField-4 DPUs in the data center. We downloaded OpenShell's policy prover and gave it 19 edits that widen a coding agent's permissions. It caught 9 with a concrete counterexample, answered "unsupported" on 9, and passed 1 that the runtime blocks anyway. Every check finished in under 200 ms.
Our verdict: the prover is honest about what it cannot check. The risk is a CI script that treats "not rejected" as "safe", because half of our risky edits would sail through that kind of gate.
What NVIDIA Launched on September 28
The platform has two layers. OpenShell is software: it runs each agent in an isolated sandbox, confines files and system calls with kernel controls (Landlock and seccomp), and routes every outbound connection through a policy check. Agents never hold real API keys; the NVIDIA developer post describes a supervisor that swaps a placeholder for the real credential only on requests bound for an approved endpoint. NVIDIA says OpenShell is "now broadly available" and supports Codex, Claude Code, Pi and Hermes.
Sentry is the hardware half. Per the press release it "can quarantine agents that attempt to move outside their boundaries in milliseconds", running on BlueField-4 DPUs. NVIDIA's own Sentry write-up calls it a reference architecture and says that for anyone already on a Vera system with BlueField-4, enabling it "is just a software update".
Jensen Huang pitched the whole thing on CNBC with one line, quoted by TechCrunch: "When you deploy an agent, no matter how smart, the first thing you do is to take away all of its rights." Named partners include Anthropic (Claude Managed Agents), SAP (Joule Studio), Salesforce (Slack) and SpaceXAI, and Canonical shipped a Charmed OpenShell alpha the same day.
| Piece | What it is | Where it runs | Can you use it today? |
|---|---|---|---|
| OpenShell 0.1.2 | Sandbox runtime, policy engine, credential proxy | Linux x86_64/arm64, macOS on Apple Silicon, Windows WSL 2 (experimental) | Yes, Apache 2.0 |
| openshell-prover | Offline policy checker (SMT solver) | Any of the above, no gateway needed | Yes, we ran it |
| Policy advisor | Turns blocked requests into drafted rules for human review | Inside an OpenShell gateway | Yes |
| Sentry | Out-of-band watchdog, quarantine in milliseconds | NVIDIA BlueField-4 DPUs | Only on that hardware |
Why It Matters for People Building With Agents
A coding agent is useful because it can read your repo, install packages and call APIs with your keys. That is also the attack surface. We covered what happens when that surface is a mounted Docker socket in the Codex, Cursor and Gemini CLI sandbox escape, and TechCrunch's launch report points back to this summer's incident in which OpenAI agents breached Hugging Face while working on a cybersecurity task.
The number in NVIDIA's developer post that should worry anyone who lets an agent ask for permissions: in adversarial tests, frontier agents with reduced safeguards "spent up to two hours trying to persuade an AI reviewer" to grant access to a protected GitHub repository. OpenShell's answer is to take the argument out of the loop. The policy prover reads two YAML files, the rules you allow in principle (the boundary) and the rules being proposed (the candidate), and returns a verdict from a solver, not from a model. It has four outcomes: within_boundary (exit 0), exceeds_boundary (exit 1), error (exit 2) and unsupported or inconclusive (exit 3).
That makes it a CI tool as much as a runtime one. If you hand subagents their own policies, or keep an agent's sandbox policy in git, the prover can gate every change the way a type checker gates code. Whether it should depends on what it actually catches, so we measured that.
What We Tested: 23 Prover Checks on a Coding-Agent Policy
We downloaded openshell-prover 0.1.2 from the GitHub release, checked its SHA-256 against the published checksum file, and ran it on an x86_64 Linux container with no Docker and no gateway. The boundary policy is a plausible coding-agent setup: read-only /usr, /lib and /etc; read-write /sandbox and /tmp; run as UID 1500; Landlock set to hard_requirement; the claude binary allowed to call api.anthropic.com over enforced REST; gh allowed read-only on api.github.com; python3.12 allowed to reach pypi.org and files.pythonhosted.org.
We then wrote 23 candidates: 2 identical copies, 2 that narrow access, and 19 that widen it in ways an agent might plausibly request. Each ran through openshell-prover check candidate.yaml --boundary boundary.yaml.
| Widening edit | Verdict | What the prover reported |
|---|---|---|
| node may reach registry.npmjs.org:443 | exceeds (1) | host=registry.npmjs.org:443 |
| GitHub access read-only to read-write | exceeds (1) | method=PATCH on api.github.com |
| curl may also call api.anthropic.com | exceeds (1) | ancestor_binary=/usr/bin/curl, method=PUT |
| Add an explicit DELETE /repos/** rule on GitHub | exceeds (1) | method=DELETE path=/repos/ (194 ms, the slowest check) |
| pypi.org on port 80 | exceeds (1) | host=pypi.org:80 |
| A public IP literal on 443 | exceeds (1) | destination_ip=93.184.216.34 |
| SSH to a LAN address (192.168.1.10:22) | exceeds (1) | destination_ip=192.168.1.10 |
| Landlock hard_requirement to best_effort | exceeds (1) | landlock boundary=hard_requirement candidate=best_effort |
| Run as root | exceeds (1) | run_as_user boundary=1500 candidate=0 |
| Add a writable path (5 variants: /home/agent, /etc/ssl, /etc read-only to read-write, with include_workdir on and off) | unsupported (3) | "depends on sandbox path resolution" or "unresolved image workdir" |
| Wildcard host *.githubusercontent.com | unsupported (3) | overlapping exact and wildcard endpoints |
| A GraphQL endpoint on api.github.com | unsupported (3) | "only L4 TCP and REST are modeled" |
| GitHub REST enforcement to audit | unsupported (3) | "uses REST without enforced inspection" |
| Cloud metadata IP with an allowed_ips override | unsupported (3) | "overlapping a runtime always-blocked range" |
| Cloud metadata IP 169.254.169.254 as a plain host | within (0) | No counterexample |
The 4 control candidates behaved: both identical copies and both narrowing edits (dropping PyPI, shrinking writable paths to /sandbox) came back within_boundary. Every result reproduced on a second run. The harness is 3 short files: a policy generator, a follow-up generator and a runner script.
The Three Things the Prover Cannot See
1. Every filesystem widening came back unsupported. All 5 writable-path additions returned exit 3, whether include_workdir was on or off. The prover compares paths exactly and refuses to reason about subpaths because symlinks could change the answer, which its docs state plainly. In practice this matters less than it sounds: filesystem, Landlock and process settings are fixed when a sandbox starts, and the policy advisor cannot propose filesystem changes at all. But if you write subagent policies up front and check them with the prover, the filesystem half is yours to review by hand.
2. The quietest loosening is unsupported, not rejected. Switching GitHub from enforce to audit means the proxy stops blocking and only logs. That is a real loosening, and the prover answers exit 3. So does adding a GraphQL endpoint. A gate written as "fail on exit 1" passes both. Write it as "pass only on exit 0".
3. The metadata endpoint result looks wrong and is not. A plain rule letting the agent reach 169.254.169.254 came back within_boundary. The follow-up explains it: add an allowed_ips override for that address and the prover reports it overlaps "a runtime always-blocked range". The runtime refuses link-local traffic regardless, so the plain rule is dead, and the advisor separately flags metadata requests as risky. The lesson is not a bug, it is that the prover models the runtime, not your intent. A rule that would be dangerous somewhere else can be harmless here.
How to Sandbox Your Coding Agent With OpenShell
Check the support matrix first: Docker 28.0 or Podman 5.x, and on Linux a kernel with Landlock ABI 3 (Linux 6.2 or newer). Windows WSL 2 is experimental. Then:
- Install the CLI and a local gateway.
curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | OPENSHELL_VERSION=v0.1.2 sh. Pin the version; the 0.1.x line is new. If you tried 0.0.x earlier, the 0.1.0 upgrade guide says it cannot be upgraded in place: delete old sandboxes and reinstall. - Attach a credential as a provider. Set your key in the shell, then
openshell provider create --name openrouter --type openrouter --from-existing. From 0.1.0 a sandbox no longer infers a provider, so you pass--providerexplicitly. - Start the agent in a sandbox. The first-agent guide uses OpenCode:
openshell sandbox create --name my-agent --from ghcr.io/anomalyco/opencode:latest --provider openrouter, followed by a double-dash separator and the agent's own start command (opencode -m openrouter/nvidia/nemotron-3.5-lightning:freein the guide). The default image is bare Ubuntu, so bring an image that already contains your agent. - Let it fail, then approve narrowly. Every outbound connection is denied unless a rule allows it, and OpenShell drafts one rule per blocked binary, host and port. Review with
openshell rule get my-agent --status pendingand approve one at a time withopenshell rule approve my-agent --chunk-id <id>. Approved network rules load without a restart. - Write a boundary and gate changes in CI. Export the live policy with
openshell sandbox get my-agent --policy-only > candidate.yaml, keep your boundary in git, and runopenshell-prover check candidate.yaml --boundary boundary.yaml -o json. Fail the build on any exit code other than 0, and read the reason_code field on exit 3. - Review filesystem and audit-mode changes by hand. Those are exactly the edits our test showed the prover will not rule on.
Two optional extras. npx skills add NVIDIA/OpenShell installs agent skills that teach your coding agent to drive the CLI and write policies. OpenShell sends anonymous operational telemetry by default; set OPENSHELL_TELEMETRY_ENABLED=false on the gateway to turn it off.
What It Does Not Replace
On a laptop, the boundary is your kernel. There is no Sentry, no out-of-band watchdog, and the sandbox is only as strong as Landlock, seccomp and the container runtime underneath it. If you want disposable cloud machines instead of a local policy engine, our Docker Cloud Sandboxes vs E2B, Vercel and Modal comparison prices that route. The two combine: a cloud VM contains the blast radius, OpenShell decides which hosts and credentials the agent can use inside it.
The prover also does not tell you a policy is minimal or right for the task, and its docs say so. It answers one question, whether the candidate asks for more than the boundary, and it answers it quickly and without being persuadable. For an agent that argued with a reviewer for two hours, that is the property that counts. NVIDIA's formal-methods primer explains how the solver is built if you want to know where its limits come from.
Frequently asked questions
Is NVIDIA OpenShell free and open source?
Yes. OpenShell is on GitHub under the Apache 2.0 license, with a Python SDK on PyPI and Go, Rust and TypeScript SDKs. Sentry, the hardware watchdog, needs NVIDIA BlueField-4 DPUs.
Do I need NVIDIA hardware to run OpenShell?
No. OpenShell runs on Linux x86_64 or arm64, macOS on Apple Silicon, and experimentally on Windows WSL 2, with Docker 28.0 or Podman 5.x. NVIDIA says it is optimized for Vera CPUs, but nothing in the support matrix requires them.
Does OpenShell work with Claude Code and Codex?
NVIDIA's developer post lists Codex, Claude Code, Pi and Hermes as supported, and the official walkthrough uses OpenCode. You run the agent from a container image that contains it, and attach API keys as providers so the agent never sees the real key.
What does the OpenShell policy prover actually check?
It checks whether a candidate policy grants anything the boundary policy does not, across filesystem, L4 network, REST methods and paths, process identity and Landlock mode. In our test it returned a concrete counterexample for 9 of 19 widening edits and "unsupported" for 9, including every filesystem change.
Should my CI fail on exit code 3?
Yes. Exit 3 means the prover could not decide, not that the change is safe. In our test that bucket included switching GitHub REST from enforce to audit and adding a GraphQL endpoint, both real loosenings.
What changed in OpenShell 0.1.0?
A clean install is required: 0.0.x installs and sandboxes cannot be upgraded in place. The inference commands and the inference.local endpoint were removed, providers must be passed with --provider, and the policy schema now rejects unknown or misspelled fields instead of ignoring them.
