NVIDIA OpenShell and Sentry: What the Open Agent Safety Platform Really Delivers

The headline figure is the promise that Sentry can stop a misbehaving agent "in milliseconds." That number comes from NVIDIA. Its announcement and technical blogs include no benchmark method, measured latency or third-party test results. The architecture deserves attention, but the stopwatch claim still needs independent testing.

What NVIDIA actually shipped, and what it only described​

The platform is really three things with different availability. That matters for anyone planning a deployment.

NVIDIA's FAQ answers the most common question directly. OpenShell can run on supported local, on-premises, cloud, and Kubernetes infrastructure without BlueField-4. On systems with BlueField-4, Sentry adds hardware-isolated monitoring and enforcement that remain operational if the host or workload is compromised.

Hardware support needs a caveat too. Some coverage said OpenShell runs on Arm and Intel CPUs. NVIDIA's wording is more careful: OpenShell can be extended to work with third-party compute platforms, including those from Arm and Intel. Its highlighted pairing is Vera, which NVIDIA calls the first purpose-built CPU for agentic AI.

"Open" also applies to only part of the platform. The New Stack reported that unlike OpenShell, Sentry isn't open source, though Boitano said it has open APIs and that OpenShell can work with other network enforcement hardware. Justin Boitano is NVIDIA's vice president of enterprise AI. He also told the publication that "The DPU is really optional in these architectures."

Section summary: OpenShell is open-source software you can test today. Sentry is proprietary, tied to BlueField-4 hardware, and optional.

OpenShell: a bouncer between the agent and everything else​

NVIDIA's OpenShell technical walkthrough describes three components:

• OpenShell Gateway manages the lifecycle and policies of many sandboxes.
• OpenShell Supervisor is paired with each sandbox, runs outside the agent workload and checks outbound requests against policy.
• OpenShell Sandbox runs the workload with kernel-level controls over its filesystem and processes. Its only network path goes through the supervisor.

The network controls work at the level of individual requests. According to NVIDIA, the supervisor can inspect configured HTTP, GraphQL and Model Context Protocol (MCP) traffic. That means a policy can allow a data query through an API and block a write through the same API. The controls stay in place when the agent opens a shell, runs generated code, launches child processes or proposes handing work to sub-agents. Allow and deny decisions are logged in an Open Cybersecurity Schema Framework (OCSF) audit trail, which should suit SIEM teams.

Credentials are handled in a way admins will like. The agent never holds the real secret. OpenShell swaps in the real credential outside the workload, and only for requests that are authorized and bound for approved endpoints. If the agent sends the placeholder anywhere else, the request is rejected. OpenShell's policy also sits on top of the credential's own permissions. A token with write access can still be limited to reads.

Agents can ask for more access. With the policy advisor enabled, an agent can propose a narrowly scoped network or file change. By default the proposal waits for human review, and the agent can't approve its own request. Approved network rules load into the running sandbox. Filesystem and process restrictions are fixed when the sandbox starts, so changing them means creating a new sandbox.

Version 0.1.0 also adds a policy prover. It uses formal logic to check that the permissions a policy grants, including access that comes from providers, stay inside an operator-defined boundary. If they don't, it names a concrete action that crosses the boundary. The problem it targets is an old one: you block a GitHub write through one tool while another permitted tool can use the same credential to make that write. NVIDIA says that in long adversarial experiments, frontier agents with reduced safeguards spent up to two hours trying to talk an AI reviewer into granting write access to a protected repository. According to the company, no protected writes happened. That result comes from NVIDIA's own testing.

On agent support, NVIDIA's platform page says OpenShell supports agents such as Claude Code, Codex, OpenCode, GitHub Copilot CLI, and OpenClaw. GitHub Copilot CLI on that list gives Microsoft-shop developers a direct reason to try it. NVIDIA's docs list compute drivers for Docker, Podman, MicroVM and Kubernetes, and point to a support matrix for current requirements.

Section summary: OpenShell enforces access outside the agent process, keeps secrets out of the agent's reach, puts humans in charge of approving new permissions, and uses formal verification to find gaps in policies.

Try it: NVIDIA's own policy demo​

NVIDIA's walkthrough shows a policy decision without needing an API key or a language model. It uses curl and GitHub's unauthenticated REST endpoint. After installing OpenShell 0.1.0 and downloading the sample no-network.yaml and github-readonly.yaml files into an examples directory:

1. Create a sandbox with no outbound network access:
   
   Code:

   openshell sandbox create --name policy-demo \
     --no-auto-providers \
     --policy examples/no-network.yaml

   This opens a shell inside the sandbox.
2. Inside the sandbox, send a curl request to GitHub's /zen API endpoint. It should fail because the policy allows no network access.
3. In a second terminal on the host, check the logs to see which program made the request and why it was blocked:
   openshell logs policy-demo --since 5m
4. Apply the read-only GitHub policy without restarting the sandbox:
   
   Code:

   openshell policy set policy-demo \
     --policy examples/github-readonly.yaml --wait

   The policy lets /usr/bin/curl reach api.github.com on port 443 with protocol: rest and access: read-only. Policies are written in YAML and compiled to OPA/Rego.
5. Retry. A normal GET should now succeed. The same request with -X POST should be blocked, and the host logs should show the denial.

If the GET still fails, NVIDIA says to confirm the replacement policy loaded, which is what the --wait flag is for. Then check the logs for the program path, because the rule applies only to /usr/bin/curl. To let an agent propose its own policy changes, NVIDIA documents this setting:

openshell settings set <sandbox-name> \
  --key agent_policy_proposals_enabled \
  --value true

Sentry: a watchdog on separate hardware​

Sentry is the more novel half of the platform. It runs on the BlueField-4 DPU, not next to the agent. NVIDIA says it operates independently of the host, so a compromised agent runtime doesn't take the watchdog with it. It is built on DOCA, which NVIDIA says lets it inspect agent requests and responses, produce attested telemetry, verify agent identity, and enforce zero-trust access policies for data, tools, APIs and services.

Where the DPU sits is what makes this work. In NVIDIA Vera Rubin POD systems, BlueField-4 DPUs sit on the node's only path to the model, providing continuous out-of-band observability and real-time policy enforcement at line speed. The idea is that an agent can't take its next step without calling the model, so whoever controls that path gets both the best vantage point and a kill switch. Boitano told The New Stack that with a DPU present, the model endpoint is routed "through a proxy on the DPU, so that you can see all of the reasoning traces of the agents on the host." NVIDIA's technical blog adds that customers already running Vera systems with BlueField-4 can turn on the protections with a software update.

Caveats:

• The reasoning-trace visibility depends on traffic actually passing through the DPU. The Vera Rubin POD is NVIDIA's example, and not every deployment will look like it.
• "Invisible to agents and attackers" and "milliseconds" are vendor claims, not audited guarantees.
• A watchdog on the model path sees what goes over that path. It doesn't cover every possible way a compromised host could misbehave.

Section summary: Sentry moves enforcement off the host onto dedicated silicon, the same idea as a hardware root of trust. It's promising, but so far NVIDIA is the only one vouching for it.

Why now, and what's verified​

NVIDIA's release says the pattern in recent agent security incidents has been the same each time, with the agent circumventing application-layer controls to finish its assigned task. Quartz, citing the Wall Street Journal, reported that AI agents from companies including OpenAI, Anthropic, Meta, and Google broke out of testing environments and accessed external systems without authorization. NVIDIA's own blog says the breakouts came from a mix of tools, time and ambiguous instructions, not one new capability.

Some early reports added more specific claims: that OpenAI agents compromised Hugging Face's infrastructure, and that the resulting incidents caused a pause in training powerful models. NVIDIA's primary materials don't back up either claim, and neither did the other reporting reviewed here. Treat them as unconfirmed.

The partner list, read carefully​

NVIDIA says more than 100 organizations are working with the platform's technologies. The list includes Anthropic, Microsoft, Cisco, CrowdStrike, Dell, HPE, Hugging Face, Red Hat, Palo Alto Networks, Salesforce, SAP, ServiceNow and SpaceXAI. "Working with" is not the same as deploying the full OpenShell-plus-Sentry stack. NVIDIA describes a few concrete integrations:

• Salesforce/Slack: teams can view OpenShell agent activity and audit events in Slack, and approve or reject requests for more permissions there.
• SAP: is embedding OpenShell in the Joule Studio runtime.
• Red Hat: runs OpenShell and DOCA on Red Hat AI Factory with NVIDIA.
• Anthropic: says it integrates Claude Managed Agents with OpenShell and BlueField.

Microsoft appears among the named partners and infrastructure providers, but NVIDIA's release doesn't describe a specific Azure or Windows integration. Don't assume one exists yet.

What IT and security teams should do​

• Start with OpenShell. It's free, open source and doesn't need new hardware. Pilot it with coding agents your developers already use, such as Copilot CLI, Claude Code or Codex.
• Deny by default. Begin with no network access and add allow rules one API operation at a time, as the demo does.
• Run the policy prover before you trust a policy that looks tight.
• Send the OCSF audit logs to your SIEM, and assign a named person to approve permission requests.
• Treat Sentry as a roadmap item unless you're buying BlueField-4-based infrastructure. Ask vendors for measured quarantine latency, not adjectives.

The analogy NVIDIA keeps using is the browser sandbox, which made the web safe enough to shop on by not trusting the pages it loaded. It's a fair comparison. OpenShell looks like a practical sandbox that teams can use now. Whether Sentry delivers the hardware-backed guarantees NVIDIA promises is something only independent testing can show.