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.
Editorial note: Prepared October 1 as a September 28, 2026 dispatch, using September 28 announcements. Implementation documentation was checked October 1 and is identified in the runtime section.
- 01Two layers have different jobsOpenShell is runtime software; Sentry is an out-of-band watchdog in the reference system design.
- 02Keep vendor claims attributedMillisecond quarantine and performance claims are NVIDIA’s statements, not results from our testing.
- 03Adopt through a bounded pilotVerify supported infrastructure, policy coverage, denial logs and the stop path before expanding access.
01 — The evidenceWhat NVIDIA announced on September 28
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.
| Layer | Vendor-described role | Buyer question |
|---|---|---|
| OpenShell | Runtime access policy outside the agent workload. | Which controls are enforced on the selected host? |
| Sentry | Independent monitoring and containment on BlueField-4. | What hardware and reference-design elements are required? |
| Operator | Approves authority and handles incidents. | Who can change policy, stop tasks and restore service? |
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.
02 — Practical implicationsWhat the runtime boundary is designed to restrict
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.
| Boundary | A harmless pilot check | Evidence to retain |
|---|---|---|
| Filesystem | Attempt access to a disposable file outside allowed paths. | Denial and confirmation the file was unchanged. |
| Network | Request an unapproved test endpoint. | Policy decision and absence of an unexpected connection. |
| Credentials | Inspect what the workload receives and can use. | Redacted evidence of intended scope; no secret in logs. |
| Policy change | Request one narrowly defined expansion. | Who approved it, which rule changed and its resulting reach. |
03 — Practical implicationsWhat the separate hardware layer adds
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.
Neither the launch announcement nor this guide proves that a specific historical breach would have been prevented. That counterfactual depends on the exact workload, configuration, available paths and enforcement behavior.
04 — Practical implicationsPolicy analysis still needs a correct model
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.
05 — Practical implicationsA practical adoption sequence
Map the deployment
List host, runtime, tools, model path and credentials before selecting enforcement layers.
Use disposable inputs
Exercise useful tasks and expected denials, including an interrupted run.
Assign the stop path
Make policy changes, alert triage and recovery accountable to named operators.
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.
Verify the boundary your deployment actually uses
Select a bounded task, document the enforced paths and retain evidence of both successful work and denied access. Expand only after the team can explain the policy, operate the stop mechanism and recover from a failed run.