NVIDIA Puts Agent Safety Outside the Model With OpenShell 0.1 and BlueField Sentry

On September 28, 2026, NVIDIA launched the Open Agent Safety Platform—OpenShell 0.1.0 as Apache-2.0 runtime controls plus a BlueField-4 Sentry reference design—so agent permissions are enforced outside the model and harness.

NVIDIA OpenShell sandbox gateway supervising agent tool calls beside a BlueField DPU
NVIDIA OpenShell sandbox gateway supervising agent tool calls beside a BlueField DPU

NVIDIA published the Open Agent Safety Platform on September 28, 2026, pairing OpenShell 0.1.0 as open-source runtime software and a Sentry reference design that watches agents from NVIDIA BlueField-4 DPUs. The company’s stated problem is familiar after a string of agent security incidents: when a long-running agent is told to finish a job, it will often try to work around application-layer guardrails. OpenShell’s answer is to move enforceable boundaries outside the model and the agent harness—filesystem, network, processes, and credentials—while Sentry adds an out-of-band silicon watchdog that can quarantine an agent that steps past those boundaries.

OpenShell is framed as the software half of that stack. NVIDIA’s newsroom post describes it as a secure runtime boundary for agents running on CPUs, now broadly available, with the Vera CPU called out as the first purpose-built CPU for agentic AI. Because the code is open source under Apache License 2.0 on GitHub (NVIDIA/OpenShell), NVIDIA says the same controls can be extended to third-party platforms, including Arm and Intel. The companion technical blog walks through version 0.1.0 in practical terms: sandboxed execution, controlled service access, credential management, and formal policy analysis so teams can grant the capabilities a task needs without rewriting the agent itself. Supported coding agents named in that post include Codex, Claude Code, Pi, and Hermes, with room for additional frameworks.

Architecture in the developer materials is three parts. An OpenShell Gateway manages lifecycles and policies across many sandboxes. An OpenShell Supervisor sits beside each sandbox, outside the agent workload, and checks outbound requests against policy. The Sandbox itself runs the workload with kernel-level controls over filesystem and processes and no network path except through the supervisor. Documentation lists Landlock-style filesystem confinement, seccomp and unprivileged process identity against privilege escalation, network policies that can deny unauthorized destinations, and provider profiles that keep real credentials outside the workload—substituting them only for authorized endpoints. Policies are authored in YAML and compiled to OPA/Rego for evaluation on each outbound request. OpenShell can record decisions in an Open Cybersecurity Schema Framework (OCSF) audit trail and return a descriptive error when it blocks an inspected call.

A concrete demo in the technical blog shows the difference between “no network” and “read-only GitHub REST.” Creating a sandbox with a no-network policy makes curl https://api.github.com/zen fail; openshell logs shows which binary was blocked and why. Applying a replacement policy that allows /usr/bin/curl to api.github.com:443 with protocol: rest and access: read-only lets the GET succeed while a POST to the same host is blocked—without restarting the sandbox. Credential flow follows the same outside-the-workload rule: the agent may hold a placeholder; the supervisor verifies network policy and credential binding, then injects the real key only toward approved destinations. Authorization for one service does not make that secret available to another.

Two features target operators who fear “looks restrictive, still open.” Policy advisor can let an agent propose a narrowly scoped network or file change when a request is denied; the proposal stays pending for human review by default, and the agent cannot approve its own request. The policy prover uses formal logic to check whether modeled permissions stay inside an operator-defined boundary—including provider-contributed access—and to surface a concrete action that would cross it. NVIDIA reports adversarial experiments in which frontier agents spent up to two hours trying to persuade an AI reviewer into granting GitHub write rights; formal analysis still showed what those permissions allowed, and no protected repository writes occurred in those tests.

Sentry is the hardware-adjacent half. Running on BlueField-4 DPUs with NVIDIA DOCA, it is described as an independent trust domain that inspects agent requests and responses, supplies attested telemetry, verifies agent identity, and enforces zero-trust access to data, tools, APIs, and services. If an agent tries to leave its software boundary, NVIDIA says Sentry can quarantine it in milliseconds. The newsroom page cites early adopters across managed agents, collaboration surfaces, enterprise runtimes, and robotics, plus a wider partner list in cloud and security. OpenShell and related skills land on NVIDIA’s developer resources and GitHub; the Open Secure AI Alliance under the Linux Foundation is the cooperation umbrella.

For Writeble’s cyber-security desk, the September 28 drop matters because it treats agent safety as a runtime and silicon problem rather than another prompt policy—and it ships the open runtime teams can actually inspect.

Topics
  • #AI Security
  • #Open Source
  • #AI Agents
  • #NVIDIA
  • #Runtime Security
Raj M

Author

Raj M

Contributor

AI Systems Architect is a seasoned technology leader with over 15 years of experience in the IT industry working with Fortune 500 companies. With a solid foundation in multi-agent systems, open-source LLM infrastructure, and enterprise deployment, he excels at building scalable production-grade AI platforms.