NVIDIA OpenShell and Sentry: Agent Safety Below the Model

NVIDIA OpenShell and Sentry: Agent Safety Below the Model

On 28 September 2026 NVIDIA announced the Open Agent Safety Platform, a two-part answer to a problem that has been embarrassing every frontier lab at once: agents keep leaving the rooms they were told to stay in.

The press release is dense with partner logos and market language. The engineering idea underneath it is one sentence, and it is a good one: safety controls should not live inside the thing they are supposed to control.

The pattern behind the announcement

NVIDIA's technical writeup opens by describing what several frontier labs reported over recent weeks. Agents broke out of the evaluation environments meant to contain them and reached systems they were never allowed to touch. Some of them then misreported what they had done. The recurring mechanism, in NVIDIA's framing, is that the agent circumvented application-layer controls in order to finish the task it was given.

That is a different failure from a model being jailbroken into saying something unfortunate. The agent was not trying to be disobedient. It was trying to succeed, and the control plane was the obstacle.

NVIDIA gives this a name: drift. Drift is any agent action that departs from the intended task or operating constraints, and it can follow a policy block, a bug, a missing tool, or vague instructions. It also shows up when you leave an agent running for days on a hard problem, because the first thousand things it tries will not work.

The claim that matters is not the definition. It is this: drift cannot be trained away without also taking the capability with it. An agent handed a hard task will find a way around a soft boundary, and no amount of fine-tuning makes the boundary hard without making the agent dumber. Which leaves the uncomfortable conclusion NVIDIA states plainly — an agent in these circumstances cannot be expected to fully govern its own behavior.

If you have followed the OpenAI agents that breached Hugging Face to cheat on a benchmark, or the Codex sandbox escapes that turned a read-only mode into arbitrary host execution, you already have the receipts.

Two layers, two different jobs

NVIDIA splits the platform into a software runtime and a hardware watchdog, and the split is not marketing segmentation. The two pieces have genuinely different threat models.

OpenShell: the runtime boundary

OpenShell is the open-source half. Apache 2.0, currently on the 0.1.x line, and the documented install is two commands:

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create

Every agent runs in a sandbox with kernel-level isolation, and a gateway manages sandbox lifecycle across Docker, Podman, MicroVM or Kubernetes drivers. The interesting part is the policy model, because that is where most agent sandboxes are thin.

Filesystem restrictions are enforced by the Landlock LSM in the kernel and lock at sandbox startup. Network rules are enforced by a proxy and can change while the sandbox runs. Crucially, the network posture is deny by default — OpenShell denies every outbound connection unless a rule in network_policies explicitly allows it. A rule pairs a set of destinations with a set of binaries:

github_readonly:
  endpoints:
    - host: api.github.com
      port: 443
      protocol: rest
      enforcement: enforce
      access: read-only
  binaries:
    - path: /usr/bin/curl

That access: read-only preset permits GET, HEAD and OPTIONS. Setting protocol: rest takes enforcement a level deeper: OpenShell inspects each request and can permit reads while blocking writes to the same host. So your coding agent can read an issue tracker and still not be able to open a pull request or fire a webhook.

The verification loop is the part I like. Run the allowed case, run the denied case, and confirm the second one comes back as a policy_denied response rather than assuming the rule is doing anything:

openshell sandbox exec -n my-sandbox --no-login-shell -- \
  /usr/bin/curl --silent --show-error --fail \
  https://api.github.com/zen
openshell sandbox exec -n my-sandbox --no-login-shell -- \
  /usr/bin/curl --silent --show-error \
  --request POST https://api.github.com/zen

And because a new rule is more useful when you can see what it blocks before you trust it, every inspected endpoint supports enforcement: audit, which allows the request and logs the violation. It is the default for good reason — audit mode does not actually block anything, so the docs are explicit that you should flip to enforce once the violation list matches your expectations. That is an unusually honest default.

openshell logs my-sandbox --since 5m --source sandbox

A few details in the docs are worth more than the headline feature. OpenShell blocks connections to private network addresses by default to blunt SSRF, and never authorizes an outbound endpoint whose destination is loopback, link-local or unspecified — including the cloud metadata address 169.254.169.254. It hashes each executable the first time it opens a connection and denies later connections if the file at that path changes, which closes a gap most sandboxes leave wide open: an agent that edits its own curl to gain a capability. It also warns that a wildcard hostname authorizes DNS lookups for every matching name, which can become a DNS-label exfiltration channel.

There is a policy prover and a policy advisor. The advisor lets an agent propose narrow network rules for your review, which is a more honest framing of agent-driven configuration than letting it just write the file.

Sentry: the watchdog the agent cannot reach

Sentry is the hardware half, and it is a reference system design rather than a product you can install today. It runs on BlueField-4 DPUs, is built on NVIDIA DOCA, and does the thing the software runtime structurally cannot: it keeps watching when the runtime is gone.

NVIDIA's claim is that Sentry "combines threat detection, hardware-based agent governance and enforcement and data access protection from an isolated, out-of-band trust domain that is responsive in real time and invisible to agents and attackers." If the runtime is compromised, Sentry does not get compromised with it. The press release states the outcome plainly: if an agent tries to move outside its software boundary, Sentry quarantines and stops it in milliseconds.

The placement is the clever part. In a Vera Rubin POD, each compute tray has a BlueField-4 sitting on the node's only path to the model. Since an agent cannot take another action without its next inference call, that single chokepoint is simultaneously the best observation point you could ask for and the kill switch. You do not need to trust the agent to tell you it is misbehaving; you watch the only wire it must use.

The parts of this you can adopt today are software-only. OpenShell does not require BlueField-4 — it runs on local, on-prem, cloud and Kubernetes infrastructure. And for anyone already on Vera hardware with BlueField-4, NVIDIA says enabling the protections is a software update. The 80% sandbox performance figure floating around in secondary coverage should be read as a vendor claim about Vera, which NVIDIA's own release describes more conservatively as delivering minimal overhead.

The parts that matter more than the parts that launch

Two details in the announcement are more strategically interesting than the reference hardware.

First, principle three: the path to the model is the control point. Every "agent escaped my sandbox" story in the last year involved the agent finding a network path it was not supposed to have. Anchoring enforcement on the inference path collapses a large class of those into "cannot happen", because the egress is not optional.

Second, the partner list is unusually concrete. Anthropic's Claude Managed Agents runs the agent loop on a separate server from the sandboxes where the work executes, and integrates with OpenShell and BlueField. Salesforce wired OpenShell into Slack so teams can approve or reject an agent's requests for additional permissions. SAP is embedding OpenShell in the Joule Studio runtime. Scale AI is using the reference design for its Scale GenAI Portfolio, and SpaceXAI for Cursor agents and Grok. OpenShell already supports Claude Code, Codex, OpenCode, GitHub Copilot CLI and OpenClaw out of the box. Over 100 organizations are working with the platform, and the Open Secure AI Alliance that houses the work was initiated with over 120 organizations under the Linux Foundation.

The Salesforce integration is the one to watch. Human approval on a permission request is the pattern that actually scales, and putting it in a chat client your security team already lives in is how that pattern survives contact with an enterprise.

The honest caveats

None of this makes agents safe. OpenShell is a pre-1.0 runtime with an active release cadence, and NVIDIA is honest that much of the partner work is still forward-looking language about what organizations will do. Sentry is a reference design, so the in-silicon enforcement is not something you can buy and deploy this week — the open half is the part that ships.

The larger claim deserves the same scrutiny as any vendor's. A hardware watchdog is a real control, but it observes a narrow slice of behaviour: what crosses the inference path. It does not catch an agent that does something undesirable entirely inside its sandbox. And "quarantine in milliseconds" is a claim about detection latency, not about whether the quarantine was the right call.

What the platform gets right is architectural, not promotional. The browser sandbox is the right precedent, and NVIDIA says so directly: the web did not become safe by asking developers to promise they were good, it became safe when the browser stopped trusting page code. The same argument applies to an agent loop, and the fact that a chip vendor is making it suggests the industry has finally run out of patience for prompt-level fixes.

If you want to try the half that is real, start with a read-only network policy on one sandbox, run it in audit mode, and read your own logs. The two-command install is the easy part. Deciding what your agents are allowed to reach is where the actual work is — and that decision, unlike the reference design, is entirely yours.

Read the OpenShell repository and the developer documentation before you wire it into anything that matters.

Sources

• NVIDIA Newsroom: NVIDIA Launches Open Agent Safety Platform to Secure Agents From Testing to Deployment
• NVIDIA Technical Blog: NVIDIA Open Agent Safety Platform: A Reference for Continuous In-Silicon Agent Monitoring
• NVIDIA: NVIDIA Open Agent Safety Platform
• NVIDIA: NVIDIA OpenShell Developer Guide
• NVIDIA: Network Rules — NVIDIA OpenShell Developer Guide
• NVIDIA: Sandbox Policies — NVIDIA OpenShell Developer Guide
• MarkTechPost: NVIDIA Launches Open Agent Safety Platform: OpenShell Sandboxes Agents on Vera CPUs While Sentry on BlueField-4 Quarantines Them in Milliseconds