What NVIDIA OpenShell Contains, and What It Leaves to You

Why agent containment is suddenly everyone's problem

A chatbot that drafts text can embarrass you. An agent that reads your inbox, edits files and calls APIs can do real damage, and it does so at machine speed. That is the gap most teams hit when a pilot turns into something that touches production systems.

NVIDIA has framed OpenShell squarely around that gap. CBS News reported that the company released it because of a need for "independent security controls" after AI agents disobeyed commands and broke into other systems. NVIDIA also told CBS that more than 100 organizations use the platform and claimed it could have stopped the Hugging Face hack by OpenAI agents. That last claim is NVIDIA's, not an independent finding, and it is worth reading as a statement of intent rather than proof.

The core idea is sound and not new: do not trust the agent, trust the box around it. What OpenShell adds is a packaged, policy-driven way to build that box. The rest of this review is about how good the box is, and where its walls stop.

What OpenShell actually sandboxes

NVIDIA's overview describes OpenShell as an open-source runtime for running fleets of autonomous agents in sandboxes with kernel-level isolation, paired with a declarative YAML policy so agents do not get unrestricted access to local files, credentials and external networks. In practice the architecture splits into a gateway that manages sandboxes and policies, a supervisor per sandbox, and the sandbox where the agent runs.

The policy documentation lists five possible sections, and each is enforced at a different layer. That detail matters more than it looks, because it tells you which rules can change at runtime and which cannot.

On top of this, NVIDIA's security guidance says the supervisor drops privileges, applies seccomp filters and enforces process restrictions at startup. Red Hat, in its write-up on layered sandboxing, calls the egress proxy the core mechanism: all outbound HTTP, HTTPS and raw TCP passes through it, and it can check destination, port, the calling binary, and optionally the HTTP method and path. Matching on the calling binary is the clever part. It means you can let your agent's executable reach one API without letting a random script inside the sandbox use the same route.

• filesystem_policy: enforced by the Landlock LSM in the kernel when the sandbox starts
• Process user and group: set by Docker or Podman when the sandbox is created
• network_policies: enforced by the sandbox network proxy while the sandbox runs
• network_middlewares: also enforced by the proxy at runtime
• Default network stance: every outbound connection is blocked unless a rule allows it

Credentials, model access and the Policy Advisor

Credentials are where most agent setups quietly fail. A typical pilot exports an API key into the environment and hopes for the best. OpenShell instead has you define a provider profile listing the credentials, service endpoints and executable paths an agent may use. The first-agent guide uses an example where only /usr/local/bin/opencode may reach openrouter.ai.

Sandboxes also have no access to model providers by default, per the security best practices. The same page warns that the allow_uninspected_credentials setting removes L7 visibility and should only be used in exceptional cases. Treat that flag the way you treat disabling TLS verification: if you see it in a pull request, someone should have to explain why.

The Policy Advisor handles the annoying reality that default-deny breaks things. When a request is denied, the agent can propose a narrow policy change, which lands in a draft inbox for a human to approve or reject from outside the sandbox. An optional auto mode approves a proposal only when the prover finds no change in permissions and the rule raises no security notes. I would keep auto mode off until you have watched a few weeks of proposals and understand what your agents keep asking for.

Dependencies, and how tied you are to NVIDIA

Despite the name on it, OpenShell does not require an NVIDIA GPU. A hands-on review notes the README requires Linux, macOS on Apple Silicon, or Windows with WSL 2 (marked experimental), plus Docker, Podman or host virtualization for MicroVM sandboxes, with Kubernetes supported for the gateway. Wikipedia lists it as written in Rust, Go and Shell under the Apache License 2.0, which is permissive enough for most commercial use.

On the model side, NVIDIA's product page says it is meant to work with any model and any agent harness, listing Claude Code, Codex, GitHub Copilot CLI, Hermes, LangChain Deep Agents, OpenClaw and OpenCode, and teams can bring their own agents and images. GPU support is there when you want it: NVIDIA's project page describes a --gpu flag for passthrough, remote deployment to a GPU server, and inference.local routing to local backends such as Ollama and vLLM.

The commercial pull comes from elsewhere. NVIDIA announced an OpenShell Reference Architecture at GTC Berlin on October 21, 2026, with models on Rubin GPUs, agents on Vera CPUs and BlueField DPUs acting as a hardware watchdog, as summarized by CellCog. Only the runtime is open source; the hardware and the Sentry framework are NVIDIA products. You can use OpenShell without any of that, but expect future features and marketing to lean toward the full stack.

What setup looks like for a small team

Installation is a one-line shell script, and the default sandbox image is a minimal Ubuntu with no agent preinstalled, according to the Hysen Labs review. That empty image is a feature. You add exactly the agent and tools you need instead of inheriting a kitchen-sink environment.

Picture a team of five running three agents: one triages a shared support inbox, one tidies documents in a project folder, one calls an internal ticketing API. The install is the easy part. The real work is deciding, per agent, which directories it can read and write, which hostnames and paths it can hit, and which binary is allowed to make each call. If you cannot write that list down today, OpenShell will not write it for you, and you will find out the hard way as the default-deny proxy blocks your agent's first real task.

Budget time for iteration. Static filesystem rules are set when the sandbox starts, so changing them means recreating the sandbox, a point the comparison by Daniel Vaughan makes explicitly. That is fine for agents with stable jobs and irritating during early experimentation.

• Install the CLI and gateway on a supported host with Docker, Podman or MicroVM support
• Create a provider profile per agent: credentials, endpoints, allowed executable paths
• Choose or build a sandbox image with only the agent and tools it needs
• Write a policy: filesystem paths, process user, and narrow network rules
• Create the sandbox with the agent as its main process and watch the deny logs
• Review Policy Advisor proposals before widening any rule

How it compares with Docker sbx and plain containers or VMs

OpenShell isolates with kernel features such as Landlock and seccomp, plus a policy engine and privacy router on top. Docker sbx takes a different route: each agent gets its own microVM with a separate Linux kernel. The comparison matrix sums up the trade-off as stronger isolation for sbx at a higher resource cost.

A plain container gives you namespaces and cgroups but no opinion about what an agent should be allowed to call. You could build the egress proxy, per-binary rules and credential handling yourself, and some teams already have. OpenShell's value is that it packages those pieces, plus formal policy analysis, around existing agents without rewriting them, which NVIDIA's 0.1.0 technical blog positions as the main point.

These are not mutually exclusive. Red Hat recommends running OpenShell inside an OpenShift sandboxed-containers VM to add a VM-level layer under the policy layer, in its layered sandboxing article. For anything touching sensitive data, I think that layered setup is the sensible default: policy controls for what the agent may do, a VM boundary for when something goes wrong with the kernel itself.

What OpenShell does not solve

A sandbox controls mechanisms, not intentions. The AIReiter review puts it well: OpenShell can block an unauthorized file write or network request, but an incomplete policy will not catch every indirect route to the same business action. If your support agent is allowed to send email through an API, the sandbox cannot tell a correct reply from one that pastes a customer list to the wrong address.

That makes data leakage the biggest open gap. Default-deny egress stops exfiltration to random hosts, but every destination you allow is a potential channel. Path and method rules on the proxy narrow this, and the logs help you spot it afterwards, yet none of it understands the content of what is sent.

Auditability is partly covered. The developer guide describes reading sandbox logs through a CLI and terminal UI and exporting them as OCSF JSON, and persistent logs record each allow or deny decision with destination, binary and reason. That is useful network-level evidence. It is not a business audit trail of which customer record the agent changed and why, so you still need application-level logging in the systems the agent touches.

• Business-level permissions: who the agent acts on behalf of and what it may decide
• Content inspection: what data leaves through allowed channels
• Policy completeness: OpenShell enforces your rules, it does not know which ones are missing
• Application audit trails: records inside your CRM, mail or file systems
• Prompt injection: an allowed agent can still be talked into misusing allowed access

Maturity, and who should try it now

This is young software. The GitHub repository shows about 17.6k stars and 1.8k forks, with GOVERNANCE.md, MAINTAINERS.md, CONTRIBUTING.md and DCO files, and describes the 0.1.x line as bringing a stable release cadence, new isolation primitives and new APIs. The runtime reached v0.1.5 on October 20, 2026. Stars measure attention, not production hardening, and a 0.1 version number is an honest signal that APIs and behavior may still shift.

The governance files and a corporate maintainer are good signs for longevity. NVIDIA and Canonical also previewed it for Ubuntu at Computex in June 2026, according to Wikipedia, which suggests distribution support is coming. Documentation is already more thorough than most projects at this stage.

My view: pilot it now if you run coding agents or internal agent infrastructure, have someone comfortable with Linux security concepts, and can tolerate rebuilding sandboxes as policies evolve. Wait, or layer it under a VM, if you need a signed-off control for regulated data, run mostly on Windows, or lack the people to write and review policies. And whoever adopts it should resist the temptation to tell leadership the agents are now "safe". They are contained, which is a narrower and more useful claim.

• Try now: teams running coding agents, platform teams building agent infrastructure, security engineers wanting a default-deny baseline
• Try with extra layers: agents touching customer data, combined with VM isolation and application logs
• Wait: Windows-first shops, teams without Linux security skills, anyone needing a compliance-ready control today