NVIDIA OpenShell ships now, while Sentry remains a reference design
NVIDIA has paired a released agent sandbox with a BlueField watchdog design. Teams can test OpenShell now, but Sentry still needs product evidence.
NVIDIA announced its Open Agent Safety Platform at 09:00 UTC on 28 September 2026. The announcement brings together two controls at different stages: OpenShell, a released open-source runtime that can be tested now, and Sentry, a hardware-backed watchdog presented as part of a reference system design.
Teams deciding how to contain agents that can run code, call external services and keep working for long periods need to keep those release states separate. NVIDIA’s announcement describes Sentry stopping an agent in milliseconds, but provides no standalone Sentry release, availability date or independent measurements. OpenShell has a public repository, versioned binaries, current documentation and a stated production support boundary. The evidence for the two components is not equivalent.
What is available now
NVIDIA’s launch announcement calls OpenShell “broadly available”. The stronger evidence is in the release trail. GitHub lists OpenShell v0.1.2 as the latest stable release, published at 03:58 UTC on 28 September, with packaged command-line, gateway, policy-prover, sandbox and supervisor artefacts. The same day’s technical guide describes the 0.1 series rather than a private preview.
The support matrix says stable releases are intended for production use within the configurations it lists. Linux on x86-64 and Arm64 is supported. Apple Silicon Macs are supported through Docker Desktop. Windows on WSL2 with Docker Desktop is experimental. Docker, rootless Podman, Kubernetes and a MicroVM runtime are listed as supported compute paths, subject to their stated prerequisites.
The release is enough to begin an evaluation, but it does not establish that OpenShell will contain every agent or fit every host. The sandbox relies on specific Linux kernel facilities, including Landlock and seccomp behaviour, and on a supported runtime delivering the trusted sandbox component separately from the agent image. A team must verify that its real deployment matches those assumptions.
Index Us did not install or test OpenShell for this article. The conclusions here come from the published release artefacts, documentation and independent reporting.
The useful control is outside the agent
OpenShell’s architecture addresses a recurring weakness in agent systems: instructions inside the same process are not a dependable permission boundary. An agent can start a shell, generate code or launch a child process. If the only rule is another instruction in its prompt, the agent and the rule still share the same decision-making path.
NVIDIA’s technical description divides the system into a gateway, a supervisor paired with each sandbox, and the sandboxed workload. The workload has no network path except through the supervisor. The supervisor can inspect configured HTTP, GraphQL and Model Context Protocol traffic, allowing a read while denying a write against the same service. Filesystem and process restrictions sit at the kernel boundary.
Credential handling follows the same separation. The agent uses a placeholder while the supervisor substitutes the real credential only for an authorised endpoint. The receiving service still applies the permissions on that credential, so OpenShell is an additional control rather than a replacement for narrow API scopes.
By default, the policy workflow also keeps permission escalation outside the running agent. An agent can propose a new network or file rule after a denial, but the proposal remains pending for human review and the agent cannot approve its own request. The policy prover can then check whether the modelled permissions fit an operator-defined boundary.
“Modelled” is the important limit. Formal analysis can establish properties of the policy and routes represented in its model. It does not show that an omitted service, parser bug, runtime failure or incorrectly scoped external credential is harmless. Teams still need adversarial tests and failure handling around the enforcement layer.
Sentry is a different procurement decision
NVIDIA documents the second component, Sentry, separately from the OpenShell package. It is described as an out-of-band watchdog running on BlueField-4 data processing units. The company says DOCA software lets it inspect requests and responses, verify agent identity, produce attested telemetry and quarantine an agent in milliseconds when it crosses a boundary.
Those are vendor claims for a reference system design. The announcement’s availability section links to OpenShell software and skills. It does not link to a Sentry repository, binary, supported-product matrix, price, release date or reproducible test. It also contains NVIDIA’s general warning that some described products and features may remain at different stages and be offered only if and when available.
Independent reports reinforce the need to keep this boundary visible. CNBC described Sentry as part of a reference design that partners are expected to turn into market offerings. WIRED reported that the hardware layer is intended for BlueField and noted that the extent of adoption across NVIDIA’s long partner list was unclear. Neither report provides an independent containment test or validates the millisecond figure.
Hardware compatibility alone does not establish that a tested Sentry control has been deployed. A procurement brief should name the component, hardware generation, software version, enforcement path, supported agent runtime and delivery date. It should also state whether a partner product detects, blocks or merely records a boundary crossing.
How to evaluate OpenShell without borrowing Sentry’s claims
Start with one bounded workflow and a current stable OpenShell release. Give it a narrow credential and a policy that permits the required reads while denying writes. Then test the boundary through each route the agent can use: direct API calls, shell commands, generated code, child processes and any delegated sub-agent.
The evidence record should include:
- the OpenShell and runtime versions, host platform and kernel prerequisites;
- the policy, credential scopes and services reachable through the supervisor;
- allowed and denied requests, including the audit event for each decision;
- behaviour when the supervisor, gateway or upstream service is unavailable;
- the process for reviewing proposed permission changes; and
- any route that the policy prover does not model.
Run the same task without the expected service, with a write-capable credential behind a read-only rule, and with a child process attempting the denied action. These tests should establish whether the external control continues to hold when the workload changes tactics.
If a vendor later offers Sentry, test that separately. Ask what signal causes quarantine, where enforcement occurs, what happens to in-flight work, how false positives are recovered and whether the control still operates when the host or agent misreports its state. Require results on the proposed hardware and workload rather than accepting the reference design’s response-time claim as a service-level guarantee.
The decision now
OpenShell gives teams a concrete control to investigate: versioned software that places network, credential, filesystem and process policy outside an agent workload. This moves the boundary away from instructions that ask a model to observe its own limits.
The wider platform announcement goes further than the currently inspectable evidence. Sentry may become a useful independent enforcement layer, especially for fleets whose agents share infrastructure. Today, its published status is a reference system design tied to BlueField-4, not a generally downloadable control with public performance evidence.
Teams can evaluate OpenShell now on a non-production workflow. Sentry belongs in a separate procurement column until a specific implementation, supported configuration and independently checked result exist.
Sources
- NVIDIA — Open Agent Safety Platform announcement
- NVIDIA Technical Blog — Add Runtime Controls to AI Agents with OpenShell
- NVIDIA OpenShell — v0.1.2 release
- NVIDIA OpenShell — support matrix
- CNBC — Nvidia releases software platform to stop AI agents from misbehaving
- WIRED — Nvidia's Answer to Rogue Agents Is an Open-Source AI Security System
Last reviewed: . See our editorial policy for how we test, source and correct our work.