What NVIDIA actually announced
On September 28, NVIDIA announced its Open Agent Safety Platform, combining OpenShell software with the Sentry reference system design. NVIDIA describes OpenShell as a runtime policy boundary and Sentry as an outside-the-environment monitor on BlueField-4 DPUs, able to quarantine boundary violations in milliseconds. That speed is a vendor claim, not an independently verified result for your deployment. The broader design idea is worth understanding: enforce limits around an agent's actions as well as asking the model to behave correctly.
Source: NVIDIA Launches Open Agent Safety Platform to Secure Agents From Testing to Deployment · 2026-09-28
Instructions and enforcement do different jobs
An instruction tells an agent what it should do. An enforced boundary limits what it can do. In an illustrative document-processing workflow, the instruction may say to summarize an uploaded file. The runtime should still restrict access to unrelated directories, block unnecessary network destinations, and prevent the process from acquiring broader credentials. These controls remain useful when an input document contains hostile instructions or the agent makes an unexpected decision. A careful prompt is part of the design, but it cannot substitute for actual limits on tools, data, and execution.
Separate the monitor's authority
A monitoring system is more useful when the workload it observes cannot casually rewrite or disable it. That does not mean every small business needs specialized hardware. It means asking the supplier where the enforcement sits and what can alter its policy. Review whether logs survive a failed task, whether alerts reach an accountable owner, and whether the stop mechanism is tested. The business question is practical: if the agent leaves its authorized path, can someone detect that departure and contain it before the consequences spread?
Containment needs a recovery plan
Stopping a suspicious task is only the first step. Determine what happens to partially written files, queued messages, temporary credentials, and customer requests waiting on the workflow. Preserve enough evidence to explain the event, then resume through a controlled process. A halted agent should not automatically restart the same unsafe sequence indefinitely. Assign responsibility for reviewing the incident and deciding whether to retry, narrow the task, or route it to a person. Recovery instructions turn a technical control into something the operations team can actually use.
Ask for the right test evidence
Procurement should examine ordinary mistakes and deliberate misuse without treating a broad security claim as a guarantee. Request a demonstration of a blocked unauthorized action, an alert, and a recovery. Use an isolated test with non-sensitive examples. Verify that the system distinguishes an allowed tool call from one that crosses a boundary. Check how the control behaves when a dependency fails or a policy changes. These observations are more informative than a diagram alone because they show whether the claimed boundary survives the conditions your workflow is likely to encounter.
Match control to consequence
A read-only research assistant and an agent with payment or deployment access need different levels of protection. Map the worst credible outcome for each workflow, then choose controls proportionate to that consequence. Begin with restricted tools and explicit approval for important actions. Add stronger isolation and monitoring where the evidence and threat model justify them. NVIDIA's announcement is a useful signal that runtime containment is becoming a product category. The immediate business takeaway is simpler: an agent's permissions, stop mechanism, and recovery path belong in the acceptance criteria from the start.