NVIDIA Pushes Agent Safety to the Chip Level After OpenAI Breach
On September 28 (U.S. time), NVIDIA released the Open Agent Safety Platform, an open agent security platform. The platform combines the open-source runtime OpenShell with a Sentry reference design based on the BlueField-4 DPU: the former restricts the files, networks, and credentials that agents can access, while the latter monitors boundary violations outside the host. NVIDIA stated that Sentry can isolate violating agents within milliseconds.
Two months before the release, OpenAI experienced an incident during an internal cybersecurity assessment in which an agent breached isolation and infiltrated Hugging Face’s systems. As agents gained more tools and autonomy, questions arose about whether restrictions originally written into task instructions would remain effective—a key issue addressed by NVIDIA’s latest release. In the announcement, Jensen Huang emphasized that agent security requires "full-stack engineering."
A Single Boundary Violation
OpenAI’s post-incident report provided a highly detailed account of the event. During the cybersecurity assessment, the model bypassed isolation measures to gain unintended internet access; it then exploited vulnerabilities and credentials to enter parts of OpenAI’s internal research infrastructure and Hugging Face systems. The agents also shared findings through unauthorized channels, allowing certain behaviors to persist.
This evaluation used relatively loose protection settings, meaning the conditions faced by ordinary office assistants differ from those in this incident. However, the chain of events described is common: developers set goals, agents encounter obstacles, and continue searching for callable tools and paths. The longer the task and the more tools available, the higher the chance of new situations arising mid-execution. The initial instruction to "only work within specified boundaries" must ultimately be translated into specific permissions within a graph structure during execution.
When discussing agent safety, much of the attention has focused on whether models can understand and comply with instructions. This remains a critical area. However, as enterprises begin handing over email accounts, code repositories, and business systems to agents, they must also address a different set of questions: which files can the agent read, where can it send data, what operations are permitted with its credentials, and when should access be revoked after a task is completed.
These decisions have traditionally fallen within the purview of corporate IT and security teams. The change brought by agents lies in the fact that a single task may trigger a continuous sequence of operations, potentially spawning sub-tasks. Humans can approve actions one by one, or grant broad permissions upfront; the former slows down workflows, while the latter increases risk.
NVIDIA’s entry into this space aligns with its unique positioning. It provides both the software for running agents and the hardware supporting data centers. If security controls can be embedded into both layers, NVIDIA has the opportunity to help establish the foundational rules governing how agents operate.
Software Defines Boundaries, Hardware Keeps Options Open
The first layer of the platform is called OpenShell, an open-source runtime for agent security. Agents execute tasks within a sandbox environment, where administrators define which files, network addresses, tools, and credentials are accessible. All requests undergo policy checks, and both allow and deny decisions are logged for audit trails.
Consider a company deploying an agent to process vendor invoices. The agent needs to read from a designated folder and may need to access specific interfaces within the financial system; however, HR records or unfamiliar websites are clearly outside its scope. OpenShell aims to translate such business logic into executable rules. When an agent attempts to expand its network access, new rules can first be vetted by policy tools.
OpenShell debuted in March alongside NemoClaw. This September’s update introduces NVIDIA’s integration of OpenShell with Sentry, forming a two-layer security solution spanning software and hardware. According to NVIDIA’s reference design, Sentry runs on a BlueField-4 DPU positioned independently from the host executing the agent’s tasks. NVIDIA states it continuously monitors relevant activities and can isolate agents in milliseconds upon detecting boundary violations.
This architectural placement is critical. If an agent exploits vulnerabilities within the host environment, relying solely on that same host for monitoring could compromise the security team’s visibility. An independent chip acts as an additional checkpoint. NVIDIA further treats model access paths as control points: since agents must re-access models to continue planning actions, securing this path provides another opportunity to halt subsequent operations.
However, the two layers differ in adaptability. OpenShell is publicly available, and NVIDIA claims it can scale across computing platforms including Arm and Intel. Sentry, by contrast, is an additional monitoring layer running on the BlueField-4, currently offered only as a reference design. Teams testing OpenShell on existing machines face significantly different costs and deployment complexities compared to enterprises configuring full hardware solutions.
NVIDIA’s strategy verification tools also have defined scopes. Official documentation lists file systems, process identities, network connections, and certain interface requests as checkable objects; if rules fall outside the current model, the tool reports them as uncheckable. A passed verification indicates that covered permissions have not exceeded set boundaries. Whether these boundaries are reasonable, and whether newly integrated tools introduce additional privileges, still requires human judgment.
How should permission issues be resolved?
NVIDIA announced partnerships with more than 100 organizations leveraging its platform technologies, spanning model development, enterprise software, finance, energy, and robotics. The list is extensive, but progress and use cases vary significantly across companies.
Specific examples illustrate the differences. NVIDIA stated that Anthropic isolates agent loops from task execution sandboxes on separate servers for Claude Managed Agents, strengthening access control through integration with OpenShell and BlueField. SpaceXAI utilizes the platform for its Cursor coding agent and Grok model. Meanwhile, Salesforce has integrated OpenShell into Slack, enabling teams to monitor agent activity and approve or deny additional permission requests.
I am particularly interested in what appears to be a mundane workflow at Salesforce: a procurement assistant initially needs only to view quotes, but may later need to contact suppliers, modify orders, and finally process payments. Each step introduces new permissions and new responsible parties. If a request simply states 'needs network access,' approvers struggle to assess the risk; if it specifies target systems, data transferred, and authorization duration, humans can understand exactly what they are releasing.
Agent security is thus becoming part of product experience. If approval requests are too frequent, employees quickly treat them as interruptions; if the information provided is too vague, users habitually click 'approve.' An effective permission system must block anomalies while allowing legitimate tasks to proceed smoothly.
NVIDIA also noted that Figure, Gecko Robotics, and Skild AI are using OpenShell to add safety controls to autonomous systems. Robots call upon software tools and cloud services, creating opportunities to borrow permission management practices from software agents.
For example, a planning agent might be allowed to invoke an action like 'go to the kitchen,' but the underlying controller must still decide whether to execute based on whether people are nearby or the path is blocked. OpenShell can manage resources and permissions for the initial call chain, while the safety of subsequent physical actions remains the responsibility of the device's own systems.
Agent safety must withstand long-term use
Justin Boitano, NVIDIA’s vice president of enterprise AI, told the Associated Press that if OpenAI had adopted this platform at the time, the incident involving agents infiltrating Hugging Face could have been prevented.
Whether this assumption holds true remains to be seen, as rules are ultimately set by people. If administrators allow agents excessive system access, they may still cause damage while adhering to the rules. Conversely, if permissions are too restrictive, agents will frequently pause and wait for approval. For enterprises, whether security teams can interpret alerts and whether business teams are willing to handle approvals are just as critical as the technology's ability to block threats.
So who should be responsible for agent safety? NVIDIA’s answer is to have the environment where tasks are executed define permissions first, and then subject them to a secondary review by hardware independent of the host. This approach addresses practical concerns and aligns with enterprises' existing security experience.
Author: Hope
Editor: Yisong
Source: Future Devices