NVIDIA OpenShell and Sentry: Where Agent Controls Run

NVIDIA’s Open Agent Safety Platform puts controls outside the agent’s own reasoning loop. OpenShell governs runtime access; Sentry adds a separate hardware monitoring layer in the reference design. The useful question for a team is which boundary its actual deployment enforces, and what evidence shows that the boundary holds.

Written October 1, 2026 and dated September 28, 2026, using September 28 announcements. Implementation documentation was checked October 1 and is identified in the runtime section.

NVIDIA’s September 28 announcement describes an open software platform and reference system design. It says OpenShell is broadly available and describes Sentry operating on BlueField-4 DPUs alongside OpenShell on Vera CPUs. Open-source OpenShell can be extended to other compute platforms; that does not make every hardware configuration equivalent.

The press release names an Anthropic Managed Agents integration and Salesforce’s Slack-based activity, audit and permission-review integration. These are vendor-described integrations, not evidence that every customer already has a turnkey deployment. The Linux Foundation governs the Open Secure AI Alliance described in the release; do not transfer that governance claim to every component of NVIDIA’s product.

The dated OpenShell technical walkthrough separates three components: a gateway manages sandboxes and policies, a supervisor checks outbound requests, and a sandbox constrains filesystem and process activity. In that design, outbound network traffic passes through the supervisor. This is a concrete enforcement model, rather than an instruction asking an agent to stay inside its task.

The current OpenShell overview, checked October 1, describes filesystem restrictions using Landlock, approved network destinations, unprivileged processes and seccomp restrictions, plus provider-scoped credential handling. Filesystem and process restrictions are fixed when a sandbox is created; network policy can change at runtime. Treat these as version-specific implementation details to verify against the installed build.

NVIDIA’s Sentry technical description places the watchdog in a separate trust domain on BlueField-4, using DOCA capabilities to inspect activity and enforce policy. The design aims to preserve monitoring and containment outside the software environment running the agent. The announcement’s claim that an agent can be quarantined in milliseconds is a vendor claim; we have not reproduced that measurement.

For procurement, ask what actually sits on the path to the model and external tools. A diagram showing an independent monitor is not enough if a workload can use another credential, host or route beyond it. Record the covered paths, unsupported paths and the action triggered by a policy violation. A deployment that only uses OpenShell should not be described as having every property of the Sentry hardware design.

NVIDIA describes a policy prover that checks modeled permissions against an operator-defined boundary. That can help identify a path left open by a seemingly narrow rule. It does not prove that every vulnerability in the operating system, agent tools or surrounding infrastructure has been eliminated. The result is only as relevant as the modeled controls and the deployment that implements them.

Start with the task’s required reads, writes and external calls. Give each permission an owner and a reason. If the task asks for broader access, evaluate the resulting authority rather than the persuasiveness of the explanation. Preserve the old policy and an audit trail so an unexpected outcome can be traced to a specific change.

Our agent runtime comparison helps map isolation choices, while the DNS incident analysis illustrates why an overlooked outbound path deserves its own check. Those sources complement a pilot; they do not certify this platform.

Measure whether the agent can finish the intended job under the restricted policy. Record blocked legitimate work as well as unexpected access. A pilot that blocks everything may be contained but unusable; a pilot that succeeds only after broad exemptions has not established the boundary you planned. Use those results to refine a small permission set.

Before production, confirm the supported software/hardware combination and recovery procedure with the responsible infrastructure team. Keep authority proportional to the task while the system’s behavior becomes familiar. Digital Applied’s AI transformation service helps define these pilots and their acceptance criteria.

The platform puts controls outside the agent’s reasoning, and the guide’s sections exist because a deployment can inherit the announcement’s properties on paper while enforcing only some of them. The illustrative pilots below each assume one layer they do not have. They are design examples drawn from the announcement’s and documentation’s own distinctions, not deployments we have run.

Each pilot would have produced a passing demonstration and an unverified boundary. The record in the next section writes the enforced paths down first and keeps the evidence for each.

The guide asks a team to map the deployment, exercise expected denials with disposable inputs, assign the stop path and expand only after the policy can be explained, and a record per pilot holds all of it. The deployment: host, runtime, tools, model path and credentials, with the layers actually in place named as OpenShell, Sentry or neither. The boundary: the filesystem paths, network destinations and process restrictions the policy allows, and the version of the installed build they were verified against, since the documentation describes version-specific details. The checks: each harmless attempt outside the boundary, with the denial and the evidence that nothing changed. The uncovered paths: any credential, host or route beyond the enforced layers, written down rather than assumed away. The work: whether the agent finished the intended task under the restricted policy, with blocked legitimate work recorded beside unexpected access. The stop path: who can change policy, triage alerts and recover, and the interrupted run that tested it. And the decision, with the permission set refined rather than exempted.

An illustrative record for a document-processing agent reads: deployment, OpenShell on the team’s own Linux hosts, no Sentry, one model endpoint and one storage credential; boundary, two allowed paths and three approved destinations under the installed build; checks, a disposable file outside the paths and an unapproved test destination, both denied, with the file confirmed unchanged; uncovered paths, a reporting tool that used its own token, now removed from the pilot; work, the task finished with one blocked legitimate read, which was added to the policy with an owner and a reason; stop path, an interrupted run recovered by the named operator; decision, a second task class on the same hosts before any hardware layer is discussed.

The record is also what keeps the vendor’s claims attributed. Millisecond quarantine and the integrations named in the release belong to NVIDIA’s statements; the record holds what the team’s own deployment denied, allowed and recovered from, which is the part a procurement reviewer can check.