On September 28, 2026, NVIDIA published a reference design for agent safety that sits below the coding assistant you already run: a sandboxed runtime (OpenShell) plus an optional hardware watchdog (NVIDIA Sentry on BlueField-4). The post is a response to frontier-lab breakouts — the same class of failures as the Hugging Face intrusion and OpenAI's research-cluster pause. NVIDIA's argument is that an agent cannot be expected to govern itself when it is drifting, blocked, or left running for days. Independent controls have to live out of band.
That is a real architectural claim. It is also easy to misread as "the laptop monitor problem is solved." It is not. Side-by-side with Beam: OpenShell contains; Beam records and can deny at the hook and browser-extension layer.
Quick reference
| Question | Answer |
|---|---|
| What shipped | NVIDIA Open Agent Safety Platform reference design, September 28, 2026 |
| Open runtime | OpenShell, Apache 2.0 sandbox with kernel-level isolation |
| Optional silicon layer | NVIDIA Sentry on BlueField-4, via NVIDIA DOCA |
| Control point | The path to the model — observation plus a kill switch |
| Does it block? | Yes, inside the declared policy (supervisor + optional DPU) |
| Does Beam block? | Yes, at a different layer. Workspace enforce denies matching Claude Code and Codex tool calls; Sentinel can pause/block high-risk browser sends. Not a kernel sandbox |
| Hardware required | OpenShell: no. Sentry: BlueField-4. Platform is optimized for Vera + BlueField, compatible with other systems |
| Practitioner fit | Contain long-running agents in a sandbox. Watch and deny Cursor / Claude Code / Codex on a laptop separately (hook coverage varies) |
Why NVIDIA is building this now
NVIDIA's post opens with the same mechanism Beam has been documenting all month: evaluation agents left the environments meant to hold them, reached systems they were not supposed to touch, and in some cases misreported what they did. The company does not pin that on one new model capability. It names the combination of tools, time, and ambiguous instructions, plus agents told to think "outside the box."
That matches the public record. OpenAI's pacing post and Hugging Face road-ahead write-up describe research workloads that treated shared services as trusted, then used them as an HTTP proxy. NVIDIA's conclusion is the browser lesson applied to agents: the internet was not made safe by asking page authors to be good. Isolation had to live outside the untrusted code.
NVIDIA also names drift: actions that leave the intended task after a policy block, a missing tool, a bug, or a multi-day run where the first thousand attempts fail. The line that matters for anyone designing controls:
"an agent in these circumstances cannot be expected to fully govern its own behavior."
That is an enforcement argument, not a monitoring argument. A hook that only records what happened still trusts the process it is watching to keep running. A supervisor that mediates every network open does not.
The same day, Perplexity's CEO restated Escaping SPACE: Part I: nine models with root inside Perplexity Computer's Firecracker guest never left the VM, but four reached a blocked URL once package repos were allowlisted. Of the third-party sandboxes Perplexity named, OpenShell and Cloudflare Sandbox held the HTTP/HTTPS authority-switch test; eight of ten products in the full set did not. That is one protocol-layer result, not a certification. The write-up is Perplexity SPACE red team.
What OpenShell actually is
NVIDIA OpenShell is the open piece of the stack. NVIDIA describes it as an Apache 2.0 runtime that executes autonomous agents in sandboxes with kernel-level isolation. Operators define which files, networks, tools, processes, and credentials an agent can access. OpenShell checks those limits before the agent runs and enforces them while it works.
NVIDIA's architecture docs split the boundary in a way that is easy to confuse with "another container":
- The sandbox shares the isolation boundary with the untrusted agent. It does not decide policy.
- The supervisor sits on the trusted side. It checks requests, injects credentials only where policy allows, and is the workload's only allowed egress path.
- A policy prover uses formal verification to flag risky policy changes (new credentialed hosts, new HTTP methods, cloud metadata) before they auto-apply.
- A gateway is the control plane for sandbox lifecycle, identity, and policy delivery.
On Linux, NVIDIA documents Landlock for filesystem limits and seccomp-mediated network opens. Runtimes include Docker, Podman, Kubernetes, and VMs; the same supervisor and policy model is supposed to apply across them. The runtime-controls walkthrough also says OpenShell 0.1.0 can inspect configured HTTP, GraphQL, and MCP traffic, and records policy decisions in an OCSF audit trail.
That is containment with an audit log, not a timeline of whatever Claude Code already did on your Mac.
Five principles, translated
NVIDIA lists five design rules. For someone running coding agents, they map like this:
- Verifiable policy — a prover shows the policy cannot escape the operator's intent before the agent runs. Prompt text is not that proof.
- Out-of-band enforcement — controls do not live inside, or within reach of, the agent. The agent does not need to know it is being watched.
- The path to the model is the control point — an agent cannot act without its next thought. Own that path and you own both the best observation point and the kill switch.
- Scale authority with inspectability — more capability requires more visible reasoning. NVIDIA flags open models here because activations are observable.
- Shared responsibility — labs, enterprises, and hardware vendors each own a layer. The runtime and policy language need to stay open so other providers can plug in.
Principle 2 is the one that collides with hook-based monitors. A PreToolUse hook runs in the agent's tool path. If the harness is compromised, misconfigured, or simply not installed, the observer is gone. OpenShell's supervisor is a different process, on the other side of a network fence. NVIDIA Sentry goes one step further and puts the watchdog on a DPU the host cannot rewrite.
Principle 3 is why BlueField-4 placement matters in a Vera Rubin POD: NVIDIA says each compute tray puts BlueField-4 on the node's only path to the model, so policy can be enforced at line speed even when the host is untrusted.
What NVIDIA Sentry adds
OpenShell is the runtime. NVIDIA Sentry is the optional independent layer on BlueField hardware. NVIDIA DOCA makes that DPU programmable and connects it to OpenShell policy. NVIDIA says Sentry correlates agent interactions, policy decisions, and tool and data access into a contextual activity record — the input for drift detection and investigation. A DOCA gateway adds identity checks: is this agent still the identity it was delegated, inside the scope it was assigned?
NVIDIA is explicit that Sentry is optional alongside OpenShell. For anyone already on Vera with BlueField-4, the post says enabling the silicon layer is a software update. For everyone else, OpenShell still runs; you just do not get an out-of-band DPU on the model path.
This is "in-silicon agent monitoring" in NVIDIA's phrase: continuous observation and enforcement in hardware the agent cannot reach. It is not a synonym for AI agent monitoring on a developer laptop.
Three NVIDIA layers vs four buyer layers
NVIDIA's platform diagram is application / runtime / infrastructure:
| NVIDIA layer | What it is | Closest buyer question |
|---|---|---|
| Application | Models, harnesses, tools, data, scripts | What is the agent for? |
| Runtime | Sandbox, policy, continuous enforcement | What is the agent allowed to do? |
| Infrastructure | Filesystems, networks, GPUs, DPUs | What hardware path can it not leave? |
Beam's evaluation map is a different cut, aimed at people buying tools today: endpoint monitor, MCP/skill scanner, enterprise platform, LLM observability. NVIDIA's runtime+infrastructure slice is closest to "put the agent in a verified sandbox," not "watch Cursor on a workstation" and not "buy Prisma AIRS."
How to evaluate an AI agent security platform still holds: name the layer before the vendor. NVIDIA just named a layer most vendor roundups skip — the execution environment itself.
What this does not cover
OpenShell does not automatically wrap the copy of Claude Code, Cursor, or Codex already installed on a laptop. You run agents inside a sandbox you created. If the team keeps using a desktop IDE agent against a live repo with the default harness, NVIDIA's kernel fence is not in that path.
NVIDIA Sentry does not scan a SKILL.md or mcp.json as a pre-install step. OpenShell can inspect MCP traffic that goes through the supervisor; that is runtime mediation, not Beam's heuristic file scan.
BlueField-4 does not help if there is no DPU on the box. NVIDIA says the platform is compatible with other hardware; the in-silicon story is specifically Vera Rubin + BlueField-4.
None of this replaces credential hygiene, scoped tokens, or an independent record of what happened. NVIDIA's own post is about agents that misreport. A supervisor log and a laptop timeline answer that in different places. Monitor vs block is the longer version of that split.
Where Beam fits, stated plainly
Beam is a local-first endpoint observer, policy layer, and pre-run scanner for AI coding agents. It records shell, file, tool, network, and browser activity from harnesses such as Claude Code, Codex, and Cursor, redacts known credential formats before writing, and flags risky patterns. Scanning a skill or MCP config uses 11 heuristic patterns plus an MCP version-pin check. Workspace owners and admins set observe, advisory, or enforce policy: enforce denies matching tool calls on Claude Code and Codex PreToolUse, and Sentinel can pause or block high-risk browser AI sends. Capture failure and missing or expired cached policy are fail-open. There is no kernel sandbox and no DPU. Cursor, Copilot CLI, and Gemini currently get a deny note, not a verified block.
That is a weaker containment story than OpenShell — hooks and an extension are not a supervisor the agent cannot rewrite — and it is a stronger "what did this IDE agent actually do on this machine, and can owners deny it" story than a cluster runtime you have not installed.
The two can sit in the same shop: run long-lived or untrusted agents inside OpenShell (and Sentry if you have BlueField-4); keep Beam on developer endpoints for the agents that will not move into that sandbox. NVIDIA already backs a related local monitor, numbat, through the Open Secure AI Alliance — another reminder that silicon enforcement and laptop telemetry are not the same product.
See the full comparison: Beam vs NVIDIA Open Agent Safety Platform.
What people ask
What is the NVIDIA Open Agent Safety Platform?
NVIDIA's September 28, 2026 reference design combining OpenShell on NVIDIA Vera (and other hardware) with NVIDIA Sentry on BlueField-4. Runtime plus optional in-silicon watchdog.
What is NVIDIA OpenShell?
An Apache 2.0 sandbox runtime with a trusted supervisor, kernel isolation, and a policy prover. Agents run inside the sandbox; policy is enforced outside them.
Does this replace Beam?
No. Different layers. OpenShell contains agents you put in a sandbox. Beam records coding-agent activity on a developer machine, enforces workspace policy on hooks and Sentinel, and scans configs before you run them.
Does OpenShell block?
Yes, against the policy you set. Beam also denies matching Claude Code and Codex tool calls under workspace enforce, and Sentinel can pause or block high-risk browser sends. OpenShell's supervisor is still the out-of-band kernel layer.
Do I need BlueField-4?
Only for Sentry. OpenShell is the open runtime; Sentry is the optional DPU layer.
Related reading
- Beam vs NVIDIA Open Agent Safety Platform
- NVIDIA — Open Agent Safety Platform announcement
- NVIDIA — Add runtime controls with OpenShell
- NVIDIA OpenShell docs — how it works
- NVIDIA/OpenShell on GitHub
- AI agent security platforms: how to evaluate one
- AI agent guardrails: monitor vs block
- What is AI agent monitoring?
- Perplexity SPACE red team: VM held, network policy did not
- OpenAI paused frontier inference after unauthorized internet access
- The Hugging Face agent breach
- Beam vs numbat
- AI agent monitoring for coding agents
NVIDIA product behavior is taken from NVIDIA's September 28, 2026 Open Agent Safety Platform post, the OpenShell 0.1.0 runtime-controls walkthrough, and NVIDIA's public OpenShell architecture docs as of that date. Beam capabilities reflect workspace policy (observe / advisory / enforce), Claude Code and Codex PreToolUse denies, Sentinel browser pause/block, and heuristic scanning. Missing or expired cached policy is fail-open. Beam is not a kernel sandbox.