NVIDIA Launches Open Agent Safety Platform for AI Agents

NVIDIA’s new agent safety platform combines software-based execution boundaries with an optional, hardware-isolated monitoring layer. For developers and architects, the announcement makes permissions, independent enforcement, and auditable activity central to deploying autonomous agents.

NVIDIA announced its Open Agent Safety Platform on September 28, introducing an open software platform and reference system design intended to strengthen security from agent testing through deployment. The offering brings together OpenShell and the Sentry reference design. NVIDIA says Sentry can quarantine agents crossing their boundaries within milliseconds. That timing is a company claim, not an independently verified result reported here. [1]

“Safety and security require full-stack engineering,” NVIDIA founder and CEO Jensen Huang said in the announcement. [1]

For enterprise teams, the development addresses a practical challenge: how to let agents perform useful work while retaining control over the systems and information they can reach.

Why agent safety needs a separate enforcement layer

NVIDIA’s technical explanation argues that an agent cannot be relied upon to fully supervise itself. It describes drift as activity departing from an intended task or operating constraint, potentially triggered by obstacles, ambiguous instructions, or extended attempts to solve a problem. Its reference architecture combines OpenShell on Vera CPUs with Sentry on BlueField-4 DPUs. [2]

The significance for software teams is the separation between an agent’s objective and its authority. “Investigate this production issue” describes a goal. It does not define which database tables may be read, which repositories may be changed, or which external services may receive diagnostic information.

Those permissions need explicit ownership. A model may decide that uploading logs would help solve a problem, but the system still needs an independent rule determining whether that upload is allowed.

This is especially relevant when agents create scripts or invoke unfamiliar tools. Application designers need to reason about the resulting actions, rather than assuming that every action will pass through a familiar user-interface workflow.

OpenShell provides the runtime boundary

NVIDIA’s companion technical walkthrough describes OpenShell 0.1.0 as a runtime that can apply controls around existing agents. Its components divide responsibilities as follows: [3]

Component	Documented responsibility
Gateway	Manages sandbox lifecycles and policies
Supervisor	Checks outbound requests outside the agent workload
Sandbox	Runs the workload with kernel-level filesystem and process restrictions

The walkthrough says configured HTTP, GraphQL, and Model Context Protocol traffic can be inspected at a finer level than simply permitting a destination. That can allow a read operation while blocking a write against the same service. It also describes OCSF audit records and integrations with existing agent tools, including Codex and Claude Code. [3]

The distinction matters for ordinary enterprise workflows. Giving a troubleshooting agent access to a source-control API should not automatically give it permission to modify repositories. An organization may want the same agent to inspect issues and propose changes while keeping actual writes behind a separate approval.

For a C# or ASP.NET Core team, this becomes an infrastructure boundary around the worker or tool-execution environment. Application authorization remains necessary: an allowed API call must still be checked against the user’s business permissions.

Credentials can remain outside the agent workload

The OpenShell project describes endpoint-bound credential handling. The workload can use a placeholder while the enforcement infrastructure supplies the real secret only for an authorized destination. The repository also describes isolated execution and checks on proposed policy changes. [4]

This design can reduce the need to place reusable secrets directly inside an agent’s execution environment. It also changes the questions developers should ask during integration.

Instead of asking only whether an agent can authenticate to a service, teams should establish which destination can receive the credential, which operation can use it, and what happens when the agent requests a different route.

Credential protection and business authorization solve related but different problems. A properly protected credential may still grant excessive permissions at the receiving service. Least-privilege service accounts remain part of the architecture.

Sentry adds monitoring in a separate hardware domain

NVIDIA describes Sentry as an independent monitoring and enforcement layer on BlueField hardware, connected with OpenShell policies through DOCA. In the described Vera Rubin POD topology, BlueField-4 sits on the node’s only route to the model. NVIDIA presents that placement as an observation and intervention point isolated from the host. [2]

“In-silicon monitoring” therefore refers to the hardware-backed placement of these controls. It should not be read as a claim that a chip can infallibly understand an agent’s intent.

Architecturally, separating a workload from its enforcement infrastructure can make it harder for that workload to disable its own controls. However, the deployment must actually route the relevant traffic through the enforcement point.

Teams evaluating such a design should identify alternate model endpoints, local inference paths, background processes, and delegated tasks. Blocking one model connection does not, by itself, establish that every previously launched operation has stopped.

Formal policy checks have a defined scope

OpenShell includes policy analysis, but the boundaries of that analysis are important. The standalone policy-prover documentation says it checks a composed candidate policy against an operator-supplied boundary. A passing result compares the configuration under documented assumptions; it does not attest that a running sandbox has installed the restrictions. Unsupported or inconclusive checks have distinct outcomes. [5]

This is useful evidence for permission review, but it is not proof that an agent can never cause harm.

An organization can write a policy that is internally consistent and still grants too much access. Likewise, an authorized action can be harmful in its business context. A support agent might be allowed to issue a refund, while a separate application rule should limit refund amounts or repeated refunds.

The practical implication is to combine policy checks with runtime validation and business rules. Each should have a clear responsibility.

IBM and Cisco describe complementary integrations

IBM says its Agent Identity offering, currently in Public Preview, and HashiCorp Vault integrate with OpenShell. It also describes work involving IBM Fusion, BlueField-4, and Red Hat OpenShift. IBM frames identity, delegated authority, credentials, and auditability as necessary parts of agent governance. [6]

Cisco describes collaboration spanning AI Defense, Hypershield, agent identity and access, observability, and Splunk. Its stated approach connects agent activity with signals from the wider enterprise rather than treating a sandbox as the whole security environment. [7]

These are partner-described integrations and initiatives. Their inclusion in an announcement should not be treated as evidence that every configuration is generally available or already validated in a customer environment.

For architects, the ecosystem involvement points to a broader integration requirement. The incident-response team needs to connect an agent action with an identity, a policy decision, and a downstream service event. A sandbox log alone may not tell the complete story.

What developers should test first

The following are practical evaluation recommendations, rather than claims about results demonstrated by NVIDIA.

Start with a narrowly scoped workflow, such as reading a repository and preparing a proposed patch. Define allowed files, outbound services, model endpoints, credentials, and write operations before adding more autonomy.

Then test both the intended workflow and plausible deviations:

Evaluation	Question to answer
Unauthorized destination	Is an attempted outbound request blocked and recorded?
Alternate tool	Does the same restriction hold when generated code makes the request?
Child process	Do controls cover subprocesses launched by the agent?
Credential misuse	Can authentication material be redirected to another endpoint?
Permission expansion	Who approves new access, and what evidence do they see?
Quarantine	Which processes and connections stop, and which may continue?
Recovery	Can work resume without duplicating external actions?

For multi-agent applications, also test the combined permissions of cooperating agents. Individually narrow access can become broader when one agent passes data or tasks to another.

Record false positives and workflow failures as carefully as successful blocks. Controls that frequently interrupt legitimate work need refinement; silently broadening permissions can erase the intended protection.

What the announcement does not establish

The platform should not be described as eliminating prompt injection, guaranteeing safe autonomous behavior, or replacing application security reviews.

Containment limits available actions. It does not automatically establish whether an allowed action is correct. Audit records support investigation but need correlation, retention policies, and operational review. Model traces can help explain an event without being a complete or guaranteed account of its causes.

Performance must also be tested in the actual deployment. For agent workloads, measure task completion time, denied requests, approval delays, infrastructure overhead, and recovery behavior. A fast containment claim alone does not describe the overall developer experience.

Availability and adoption

NVIDIA says OpenShell is broadly available and directs developers to its documentation and GitHub resources. The announcement describes Sentry as a reference system design and cautions that products and features are at different stages of availability. Software adoption and deployment of the complete hardware-backed design should therefore be evaluated separately. [1]

The announcement’s importance is the focus it places on independently enforced permissions. As agents gain more tools and longer-running assignments, enterprises need evidence of what those agents were allowed to do, what they attempted, and how the system responded.

For developers, that means designing the execution boundary alongside the agent workflow. For architects, it means assigning ownership across application logic, identity, runtime controls, infrastructure, and incident response.

Frequently asked questions

What is NVIDIA Open Agent Safety Platform?

It is NVIDIA’s announced software platform and reference design for governing agent execution. Its components include the OpenShell runtime and the Sentry monitoring design. [1]

How do OpenShell and Sentry differ?

OpenShell governs agent execution through runtime controls. Sentry adds an optional monitoring and enforcement layer in a separate BlueField-based hardware domain. [2]

Does policy verification prove an agent is safe?

No. The documented prover checks specified policy relationships under defined assumptions. Correct deployment and appropriate business permissions still require validation. [5]

Does this replace model guardrails?

It adds a different layer of protection. Model behavior, application authorization, execution restrictions, and infrastructure controls address different failure modes.

What should a team evaluate before adopting it?

Check supported environments, permission coverage, credential handling, audit integration, performance, and actual quarantine behavior. Use a representative workflow with intentionally unauthorized actions.