Nvidia Open Agent Safety Platform: OpenShell Is Free to Adopt, Sentry Is Not, and Neither Is Your Evidence Yet

On 28 September 2026 Nvidia announced the Open Agent Safety Platform, built with more than 100 partners that include Anthropic, Cisco, CrowdStrike, Microsoft, Salesforce, JPMorganChase and SpaceXAI. It has two parts. OpenShell is an open source runtime, released under an Apache license, that puts an agent inside a sandbox and enforces operator defined permissions. Sentry is a hardware reference design that runs on Nvidia BlueField-4 DPUs as an out of band watchdog and promises millisecond scale containment when an agent steps outside its limits. The pitch is that agent safety should be enforced by something the agent cannot talk its way past.

The two halves are very different for a small or mid sized team, so treat them separately. OpenShell is available to anyone today, runs on both x86 and Arm, and its code is public. Sentry is, for now, available only on Nvidia hardware, and reporting on the launch notes there are few details about what its detection and containment actually do. If you are not buying Nvidia servers, the decision in front of you is about OpenShell and about the pattern behind it, not about Sentry.

The pattern is the useful part. In OpenShell an agent lives in a sandbox and has no network path except through a supervisor. The supervisor checks each request against a written policy, can hold provider credentials so the agent never sees them, and lets an agent ask for more network access that a human can approve or refuse. Salesforce has wired this approval step into Slack so a team can watch what agents are doing and answer permission requests in the channel. That is the same idea we argued for in our piece on loopjacking and human approval binding: an approval only counts if the system, not the agent, enforces it.

Map it to the controls auditors already ask about. Credential isolation and a mediated network path are evidence for ISO 27001 Annex A access control and network security controls, and for SOC 2 CC6.1 to CC6.3 on logical access. A written policy per agent is a least privilege record. Approval requests and their outcomes are a change and access log. If you run agents today with a long lived API key in an environment variable and open outbound access, a sandbox with a supervisor closes the gap that our coverage of coding agent plugins and Git config attacks kept finding.

A runtime does not give you a control by itself, and this is where teams will overclaim. A policy file that nobody reviews is not least privilege. An approval channel that people click through is not oversight. Under ISO 42001 you still need the agent in your AI system inventory with an owner, a purpose and a recorded risk assessment, and OpenShell does not write that for you. Vanta, Drata and the other automation platforms will pull configuration and logs if you connect them, but they cannot tell whether the policy matches what the agent is supposed to do.

The fail closed question matters more than the feature list. Ask what happens when the supervisor is down, when the policy fails to parse, or when an agent requests access nobody is awake to approve. A runtime that defaults to open on failure is a convenience layer, not a control. Test it deliberately: kill the supervisor in a non production environment and record what the agent can reach. Keep that test result, because it is the kind of operating evidence a SOC 2 Type II auditor or an ISO 27001 certification body can sample.

Be careful with the partner list as a trust signal. More than 100 organisations joining a launch tells you the idea has momentum, not that each of them has deployed it in production, and reporting notes that AMD, Google, Intel, OpenAI and Meta are not on it. Your coding agents may run on a vendor that is outside the platform entirely. Check whether the agents you actually use can run inside an OpenShell sandbox or whether you would be wrapping them yourself, and treat that integration work as a project with an owner and a date, not a line on a roadmap.

The EU AI Act angle is indirect but real. Article 15 expects robustness and cybersecurity for high risk systems, and technical records under Annex IV need to show how you control a system in operation. A sandbox policy and an approval log are concrete answers to a regulator asking how you constrain an autonomous system. They are not a conformity route on their own, and a platform announcement is not a harmonised standard. Use our AI governance pages and the ISO 42001 hub to place runtime enforcement inside a management system rather than treating it as the whole programme.

A short list for this week. Inventory every agent that holds credentials or can reach the network, and note which ones use a shared key. Pick one low risk agent and run it inside OpenShell in a test environment, with a written policy and an approval route that goes to a named person. Kill the supervisor and record what happens. Decide whether the approval log feeds your existing access review evidence. Skip Sentry unless you already buy Nvidia server hardware, and revisit it when its detection claims come with documentation you can check.