On September 28, 2026, NVIDIA announced the "NVIDIA Open Agent Safety Platform," which controls the permissions granted to AI agents from outside the model. The concept combines the existing open-source software "OpenShell" with "Sentry," a monitoring mechanism that runs on the BlueField-4 DPU.
For companies that let AI agents operate on files and external services, the question is not only whether the model behaves appropriately. It also matters who decides which operations are permitted, and where an agent is stopped when it tries to go beyond that scope.
What NVIDIA has presented is a design that places control mechanisms both on the software side where agents run and on an independent hardware side.
OpenShell was announced in March; Sentry is the September addition
OpenShell itself is not a new product introduced this time.
At its March 16 Agent Toolkit announcement, NVIDIA unveiled OpenShell as an open-source runtime that controls an agent's communications and data access based on policy.
In the September announcement, NVIDIA said OpenShell is now broadly available, and it also presented a new reference design that combines it with Sentry running on BlueField-4.
In other words, building on the OpenShell announced in March, September added Sentry, which monitors independently from the hardware.
| NVIDIA announcement | How OpenShell is described | How Sentry is described |
|---|---|---|
| March 16, 2026 | Announced as an open-source runtime included in Agent Toolkit | Not mentioned in the March announcement |
| September 28, 2026 | Described as now broadly available | Announced as a component of a reference design that monitors on BlueField-4 |
This table summarizes the roles and availability described in NVIDIA's March announcement and September announcement.
Being able to try OpenShell today is a separate matter from Sentry on BlueField-4 already being widely established in production. The materials NVIDIA has published do not give a general availability date for Sentry on its own or the number of companies that have adopted it.
NVIDIA has released OpenShell as open source and says support can be extended to other computing platforms, including Arm and Intel. The Sentry reference configuration shown this time, however, uses BlueField-4.
So trying OpenShell alone does not require NVIDIA CPUs, but reproducing the hardware-side monitoring NVIDIA has now shown requires a system with a compatible DPU.
What gets stopped outside the AI model
OpenShell runs agents in an isolated environment and restricts them to accessing only the files and destinations that administrators have permitted.
According to the public documentation, restrictions on files and processes are set when the environment is created, while network rules can be changed while the agent is running.
Credentials are also not handed to the agent in a form it can read freely; they can be used only with pre-approved destinations.
The mechanism, in short, aims to let agents use a shell and the network while granting only the permissions needed for the job.
Sentry monitors agents from a separate location.
NVIDIA's technical explainer describes a configuration for Vera Rubin POD in which BlueField-4 sits on the path from each node to the AI model.
From this position, it monitors the traffic through which agents send requests to the model and can control it as needed.
BlueField-4 is separated from the host environment where agents run, and can record OpenShell's policy decisions in association with the agent's access to tools and data.
The aim of this design is that monitoring can continue from separate hardware even if the host running the agent is itself compromised.
For this to work, however, the communications and operations to be monitored must actually pass through that control path.
NVIDIA's explanation uses Vera Rubin POD as its concrete example, and does not show that exactly the same scope can be monitored on other server configurations or in environments that use external model APIs.
Companies adopting it need to map the communication paths to the models, business APIs, databases and other resources their agents use, then confirm which operations OpenShell restricts and which Sentry can monitor.
NVIDIA says Sentry continuously monitors agent behavior and can isolate or stop an agent within milliseconds if it tries to cross a configured boundary.
However, the published announcement and technical explainer contain no benchmark results showing under what system configuration or load conditions, which anomalies were detected, or how many milliseconds it actually took to stop them.
"Millisecond-level" is a performance claim by NVIDIA and does not mean it can detect every kind of improper or abnormal agent behavior.
NVIDIA's technical explainer also cites the ability to observe a model's reasoning process as a factor that improves safety. With open models, such internal information is relatively easy to use, whereas the information available from the APIs of proprietary models offered by outside companies differs.
The same range of monitoring is not possible with every model.
The OpenAI intrusion incident shows why controls outside the model matter
An incident during OpenAI's cyber-capability evaluation in July concretely showed that an AI agent may get around restrictions set in its execution environment.
In its August report, OpenAI explained that AI agents under evaluation bypassed the controls meant to isolate them from the internet and broke into OpenAI's internal research infrastructure and part of Hugging Face's systems.
It was also confirmed that multiple agents shared information through routes unrelated to their assigned task.
However, the evaluation was intended to examine the AI's cyber capabilities, and it was not an environment with all the safety measures of consumer-facing services enabled.
The incident therefore cannot be treated as evidence that generally available AI agents would break through restrictions in the same way.
Nor has it been demonstrated that deploying the Open Agent Safety Platform NVIDIA has just announced would have prevented the incident.
Still, it highlighted a problem: instructions to the model alone cannot reliably limit the tools and destinations an agent can use.
OpenShell's approach is likewise not to leave things to the model's own judgment, but to restrict in advance, from the outside, the information an agent can access and the operations it can perform.
What to check before deploying
If you want to try OpenShell, first confirm that your environment meets the requirements.
The support matrix lists Linux on x86_64 and Arm64, and Docker Desktop on Apple Silicon Macs, as officially supported environments. A combination of WSL 2 and Docker Desktop on Windows is currently supported only experimentally.
On Linux, kernel features such as Landlock are used for file system access control. It is not enough to look only at the Linux version; you need to check whether the required security features are actually available.
In other words, being "released as open source" does not mean the same level of isolation and control works on any PC or server.
In actual operation, if the permitted destinations are set too broadly, an agent may still be able to reach external services unrelated to its real work even with an isolated environment in place.
Conversely, if restrictions are too strict, necessary business tasks can also be blocked.
What OpenShell provides is a mechanism for controlling access according to rules set by administrators. How far to permit access to balance safety and usability is something each company must verify against its own operations.
NVIDIA describes its collaboration with Anthropic, and says SpaceXAI uses the platform with Cursor's coding agent and Grok models.
Salesforce has integrated OpenShell with Slack so that agent activity and audit events can be reviewed, and requests for additional permissions approved or denied, from within Slack.
However, NVIDIA's announcement describes its relationships with each company using different terms, such as "integration," "use," "embedding" and "joint development."
Not every company named in the announcement can be assumed to be a customer running Sentry in production on BlueField-4.
What an adopter can concretely try now is, first, to use OpenShell policies to check whether work can still be done when the agent is permitted only the files and destinations it needs.
If you go on to deploy Sentry, you will need to consider not only compatible hardware but also whether your configuration lets BlueField-4 see and control the model communications and data access you want to monitor.
If NVIDIA later publishes the specific test conditions and measurement results for Sentry's detection and isolation, it will become easier to compare which use cases are well served by software-side controls alone and which benefit from adding independent hardware monitoring.