A watchdog can block a route, not judge a goal
An AI agent reads a bug report, edits code, and tries to finish the repair. Now imagine that the report contains an instruction to upload private files to an unfamiliar server. The agent might mistake that instruction for part of its job. A security system has a more concrete decision to make: can this process read those files, and can it send anything to that destination?
That is the useful way to understand NVIDIA’s Open Agent Safety Platform. Announced on September 28, 2026, it combines OpenShell, a software runtime, with Sentry, an optional watchdog in a separate hardware environment. NVIDIA says Sentry can quarantine agents in milliseconds when they leave their permitted boundary. That is a vendor claim about the design, not evidence that every harmful action in every deployment will be caught.
The distinction matters because a blocked connection and a bad decision are different problems. A guard can enforce the first without understanding the second.
OpenShell controls the workspace
OpenShell’s documentation describes several boundaries: files, network connections, process privileges, and access to provider credentials. File and process controls are established when the sandbox is created; network permissions can change while it runs.
Think of the sandbox as the agent’s workroom. The agent may choose its next step, but that choice does not grant it a larger set of keys. A coding task can have access to its project without gaining access to every document on the host.
NVIDIA’s runtime walkthrough separates three components. The gateway manages sandboxes and policies. The sandbox runs the workload with operating-system restrictions. An external supervisor checks outbound requests, and the sandbox’s network route goes through it. The controls also apply to child processes the agent launches.
The walkthrough demonstrates an important difference between destination access and operation access. Its example first blocks outbound networking, then permits a read request to GitHub’s REST API while rejecting a POST to the same endpoint. For inspected, configured protocols, reaching a service need not mean being allowed to perform every operation there.
As in the MCP connection model, describing an available capability is different from deciding that it should be used. These are permissions over observable actions. They are not a promise that the agent will always choose sensible actions inside its allowed workspace.
Keeping a credential outside the agent
Credentials add another boundary. In the same walkthrough, the workload uses a placeholder rather than receiving the real provider key. The supervisor checks policy and credential binding, substitutes the actual credential outside the workload, and sends the request to an authorized endpoint.
This protects against directly copying that key out of the agent’s environment. It does not make the authorized service harmless. If a permitted operation can publish sensitive information, keeping the key hidden does not remove that operation’s consequences.
Imagine a repair agent that can post to a team channel. Hiding its posting credential helps prevent credential theft. It still needs a rule about what it may post, or review before a sensitive publication. The two protections answer different questions.
Permission changes need their own scrutiny
A blocked agent may need legitimate extra access. The current Policy Advisor documentation says the advisor is disabled by default. When enabled, it lets the agent propose network rules; proposals wait for review by default. It does not let those proposals change filesystem or process restrictions.
Automatic approval is an explicit option. The documentation warns that new public destinations without applicable provider credentials may pass its risk checks. Turning that option on therefore changes the practical boundary: some new internet access can be granted without a person reviewing it.
For our imagined repair task, “I need another service” is not enough information. A reviewer needs to know the destination, operation, and task reason. An exception should be assessed as additional authority, even when the agent describes it as a small step toward finishing the job.
What the separate hardware adds
Sentry’s proposed role is to move another enforcement layer beyond the agent’s host environment. It runs on BlueField-4, a data processing unit used for infrastructure work, with NVIDIA’s DOCA software connecting policy, identity, and records of agent activity.
In NVIDIA’s Vera Rubin POD reference design, BlueField-4 sits on the node’s only path to the model. That gives the separate system a place to observe interactions and interrupt further model access. NVIDIA describes Sentry as an optional layer alongside OpenShell.
The security value is separation. A compromised workload should not gain control of a guard simply because both run inside the same environment. The usefulness of that separation still depends on which routes the installation actually puts under the guard’s control.
This is a reference architecture with particular infrastructure requirements. Installing an ordinary NVIDIA graphics card does not, by itself, create that monitored route for every application on a computer.
A policy proof has a defined scope
OpenShell also includes a prover that checks permissions against a separately written boundary. The Policy Prover documentation makes its limits unusually concrete. A passing boundary check means that modeled permissions do not exceed the boundary policy. It does not mean the boundary is appropriate for the task or that a running sandbox enforces it.
The current boundary model covers filesystem access, process identity, Landlock settings, network connections, and REST requests. Other request protocols, including GraphQL and MCP, return an unsupported result for this check. Some comparisons are also unsupported when they require knowledge the prover lacks, such as what a filesystem symlink points to.
An inconclusive or unsupported result is not a successful proof. Nor are the advisor’s proposal risk check and the prover’s boundary check interchangeable: they ask different questions.
Keep three checks separate:
| Check | What remains outside it |
|---|---|
| Is the written boundary appropriate for this task? | A prover cannot choose the right authority for you |
| Do modeled permissions stay inside that boundary? | A passing comparison does not demonstrate runtime enforcement |
| Does the running setup enforce the policy on the relevant route? | A working restriction does not establish that every allowed action is sensible |
A perfectly checked permission to read an entire shared drive can still be far too broad for repairing one bug.
Where harmful actions can still fit inside the rules
OWASP’s prompt-injection guidance describes indirect injections through external material such as websites and files. It recommends limiting privileges and requiring human approval for high-risk actions. Those measures reduce what an influenced agent can do; they do not establish that every unwanted instruction has been recognized.
Return to the malicious bug report. If private files are unreadable and the destination is blocked, its requested upload has two barriers. But suppose the agent is allowed to read the confidential document and post to an approved team channel. An inappropriate disclosure could pass both checks. That example is a reasoning problem within granted authority, rather than a forbidden network destination.
A separate service also needs attention. The guard’s existence says little about a tool that has its own credentials and a route outside the monitored system. Our account of the OpenAI sandbox incident explores why permitted dependencies matter to containment.
Finally, stopping an agent limits subsequent actions. It cannot make a message already received unseen. For the millisecond claim to be useful operational evidence, testing needs to distinguish detection time, intervention time, missed violations, and legitimate work blocked. The practical question is therefore specific: which action is stopped, on which route, under which policy, before what consequence? That is a much stronger basis for trust than the presence of a watchdog alone.
