OpenShell and Sentry occupy different parts of NVIDIA’s agent-safety stack

NVIDIA’s agent-safety platform does not put every control in the same execution environment. OpenShell is the runtime and sandbox. Sentry is a reference design for an out-of-band watchdog that NVIDIA says runs on BlueField-4 DPUs, monitors policy from an isolated trust domain, and quarantines boundary violations (NVIDIA announcement).

That arrangement gives the two components different operational roles and infrastructure requirements. It does not establish that either one will detect or contain a violation in a particular deployment.

SecurityWeek also describes OpenShell and Sentry as the platform’s two principal components. Its report identifies OpenShell as an open-source runtime that sandboxes agents and enforces policy, identifies Sentry as a separate hardware-based watchdog on BlueField-4 DPUs, and reports that OpenShell 0.1.0 is broadly available (SecurityWeek report). Availability is not operating evidence: the report supplies no deployment results for the sandbox, watchdog, or quarantine path.

Start with the deployment topology

A buyer first needs to know which of the two components is actually included in the proposed system.

An OpenShell review can identify the runtime boundary, policy-enforcement point, and resources reachable by the sandboxed agent. A configured denial test can then show whether a prohibited action is blocked and whether the attempt leaves a usable record. That result would describe the tested configuration, not every OpenShell deployment.

A Sentry review requires additional topology. NVIDIA ties the design to BlueField-4 hardware and an isolated trust domain. The deployment diagram therefore needs to show where the DPU sits, which path it monitors, and how the watchdog remains distinct from the runtime it observes. The supplied sources do not address packaging, pricing, or compatibility, so they cannot establish whether a buyer can add Sentry to an arbitrary OpenShell installation.

This creates an asymmetric evaluation. A team may be able to examine OpenShell’s runtime behavior without deploying the Sentry topology described by NVIDIA. Evaluating Sentry, however, entails examining that hardware placement and its relationship to the monitored runtime.

Follow one prohibited action through both components

The most informative exercise is a single prohibited action observed from two locations.

At the runtime, the exercise can record the effective OpenShell policy, the enforcement decision, the resulting agent state, and any retained evidence. At the watchdog, it can record whether the same action is visible, whether it is classified as a boundary violation, and what occurs when quarantine is attempted.

A second run can impair the agent runtime while leaving the proposed monitoring path in place. The purpose is to determine whether the watchdog remains available and whether quarantine creates the intended result or an unacceptable failure mode. NVIDIA describes independent monitoring and quarantine, but the supplied evidence does not establish detectable violation classes, response timing, coverage, or behavior during partial failure.

These exercises answer narrower questions than “Is the platform safe?” They show how a specific policy, runtime configuration, hardware placement, and failure condition behave together. Different results are possible at each point: the runtime could block an action that the watchdog never observes, or the watchdog could detect an event without producing the intended containment outcome. Those are proposed evaluation cases, not reported NVIDIA results.

Decide what the extra trust domain contributes

Sentry’s relevant architectural proposition is that monitoring occurs outside the runtime being monitored. The procurement question is what that separation contributes in the buyer’s actual topology.

The answer should come from observed behavior under normal operation and partial failure. It should also identify which component produced each record and which team owns the response. Without that evidence, “isolated,” “independent,” and “quarantine” remain descriptions of the announced design rather than demonstrated outcomes for the deployment.

OpenShell and Sentry should therefore enter approval with different acceptance conditions. OpenShell needs evidence for configured policy and runtime enforcement. Sentry needs evidence for hardware placement, continued observation, and quarantine behavior. Teams can bring one representative prohibited action and one partial-failure scenario into a bounded build review, then decide whether the separate watchdog justifies its additional infrastructure.