One successful injection equals handing over all credentials
Putting APTI keys in environment variables has been the default move for server-side engineering over the past two decades. On September 28, 2026, NVIDIA released its Open Agent Safety Platform, turning this default practice into a forbidden zone in the agent era. The platform consists of two components: the open-source software OpenShell (Apache 2.0, GitHub repository NVIDIA/OpenShell), and a reference system design called Sentry—the latter runs on a BlueField-4 DPU (Data Processing Unit) and acts as an out-of-band watchdog monitoring agents on the main CPU, with NVIDIA claiming it can isolate runaway agents in milliseconds.
Repository status: Implemented in Rust, with crates divided into modules including core, supervisor, credential-gateway, policy-engine, and egress-gateway; 18.2k stars, 1,852 commits; stable version 0.1.x with approximately one release every three weeks. The high commit frequency combined with the three-week release cycle points to one conclusion—this runtime is still in rapid formation, and production adopters should budget for potential interface changes.
The design logic of OpenShell can be distilled into one principle: since agent behavior is unpredictable, narrow its scope of reach and move authorization decisions from the model context into the kernel. The competitive focus of agent runtimes thus shifts—from “how well-behaved the model is” to “how far an overreach can go.”
Credentials go to the gateway, not into context
The daily work of autonomous agents involves executing shell commands, writing files, and making network requests, with credentials typically stored in environment variables, configuration files, or .env files. A single successful prompt injection, or even just one model misjudgment, could allow an agent to act with all credentials. The blast radius equals the set of permissions it’s been granted, so narrowing permissions narrows the blast radius. This is the starting point of all OpenShell’s design.
Prompt-level safeguards lack enforcement against adversarial inputs. System prompt constraints rely on model compliance—all an attacker needs to do is make the model change its mind. Kernel-level permission boundaries ignore the model’s intentions and directly reject system calls. The difference between safeguards and boundaries lies in the enforcer: one depends on the model’s cooperation, the other on the kernel.
Figure: Screenshot of OpenShell command line interface running, where agent actions only execute after passing policy checks. Source: OpenShell official repository documentation
Kernel-level enforcement is the first key mechanism. Policies take effect at the kernel layer, independent of runtime libraries or container configurations; every action by an agent within its boundary must pass a policy check. Containers solve process isolation and image distribution, while OpenShell addresses another question: whether each access to credentials, files, and networks during agent execution is authorized.
The credential gateway is the second key mechanism. APTI keys and tokens are held by the credential gateway and injected during outbound requests; credentials never enter the agent’s context or land in its file system. Compared to the conventional practice of “putting keys in .env”, the potential leakage surface is reduced from the entire machine to a single gateway component. Models can be deceived, but a deceived model doesn’t hold the keys.
Outbound traffic is similarly controlled: the egress gateway allows traffic only to whitelisted destinations, with everything else unreachable. The file system and network targets expose only the directories and addresses that the agent should see.
Figure: OpenShell architecture—agent, supervisor, credential gateway, policy engine, and egress gateway as separate modules, with credentials and policy decisions made outside the agent context. Source: OpenShell official repository docs/images
Policy changes must pass formal verification before taking effect
A single incorrect policy creates a vulnerability. OpenShield blocks policy changes behind formal verification: new policies must pass formal verification before taking effect to confirm their semantics match expectations. This step is rare in similar sandbox tools—most solutions remain in a state where policies are code that takes effect immediately after changes.
The supervisor component handles agent creation, monitoring, and termination, forming a lifecycle management layer. The SDK covers Python, TypeScript, Go, and Rust, with Kubernetes deployment via Helm, providing a complete path for engineering integration.
Formal verification has its limits: it protects against “incorrectly written policies” but doesn’t solve “correctly but overly narrow policies.” If policies are too narrow, the agent can’t function, and operational pressure will push people to relax rules. Once intent is relaxed, even strict verification only precisely executes a lenient intent. Security responsibility shifts from the code layer to the policy author, and policies themselves become new audit objects.
Figure: Sandbox enforcement points—policies take effect at boundaries for file system, network, credentials, and outbound traffic, with each boundary corresponding to a separate component. Source: OpenShell official repository docs/images
Watchdog moves to BlueField-4 DPU with millisecond-level isolation
The Sentry reference design moves the watchdog out of the host machine. It runs on a BlueField-4 DPU, providing out-of-band monitoring of agents on the main CPU, with NVIDIA claiming it can isolate runaway agents in milliseconds. In the demo environment, Vera CPU also participated in the operation.
Out-of-band is the key to this design. In-band monitoring shares the same kernel and trust domain with the monitored object—if the host is compromised, the monitoring is also compromised. The DPU has independent computing power and network paths, so even if an agent on the main CPU goes rogue, it can’t reach the watchdog itself. Isolation actions happen in milliseconds, narrowing the window for malicious activity—provided the DPU-side firmware and software stack hold, making the watchdog itself a new high-value attack target.
The official press release lists 12 industry partners and integrators, establishing a complete ecosystem. cloud providers and security vendors. NVIDIA’s ecosystem position is straightforward: it wants “running agents in bounded runtimes” to become the default deploymentform , just as hypervisors did for virtual machines.
The 0.1.x version number is more honest than “broadly available”
The version number first delivers a reality check. OpenShell is currently at stable version 0.1.x, releasing approximately every three weeks, yet the official wording is “now broadly available.” The three-week release cycle itself is a signal: interfaces and semantics are still changing, and production adopters should budget for migration costs. The space for judgment is left to users between “broadly available” and 0.1.x.
The second reality check: the sandbox narrows the blast radius but doesn’t eliminate vulnerabilities.nate risk. The kernel enforcement layer, credential gateway, and policy engine themselves become new trust bases—their failure means boundaryfallo . The attack surface shifts location but doesn’t decrease in volume—what needs auditing expands from “agent applications” to “sandbox runtimes.”
The debate over approaches is still undecided. Anthropic’s Claude Managed Agents chooses managed execution, while NVIDIA opts for infrastructure control. and othermanaged platforms build sandboxes into cloud services, freeing users from setting their own boundaries; OpenShell follows a self-hosted, auditable route. The prerequisites for these two approaches differ: teams that require data to stay within their domain and need audit trails will choose the latter, while teams without dedicated operations capabilities will find managed services much more convenient. The choice is determined by compliance requirements and operational capabilities—both approaches have their valid scenarios.
Software is free, hardware is still for sale
The business math must be clear. OpenShell is distributed under Apache 2.0, lowering the compliance threshold for agent deployment; the Sentry reference design is tied to BlueField-4 DPU and Vera CPU. Software is distributed freely, while security hardware is priced per unit—replaying the old CUDA playbook: ecosystem tools are free, computing power costs money. The sandbox runtime itself doesn’t generate revenue—where the boundary runs on hardware is where the money is made.
This approach also makes sense for users: choosing OpenShell gets you auditable boundaries and a clear hardware procurement list, while choosing a managed platform gets you operational convenience. The two delivery models each calculate their own accounts—the open source license alone doesn’t reveal the structure of the entire business.
Returning to the dividing line at the beginning. Prompt safeguards control what the model says, while kernel boundaries control what processes can do; the former depends on model compliance, the latter on policy correctness. After NVIDIA released both the open-source runtime and DPU watchdog, the focus of agent security has shifted from “making models obedient” to “limiting how far overreaches can go.” Whether models will go rogue remains unknown, but how far processes can travel is now measurable and auditable—this is the real innovation in the September 28 announcement, and the part that the 0.1.x version number hasn’t yet delivered.
Reference links:
- NVIDIA Official Press Release
- OpenShell Official Repository README
- OpenShell Architecture Documentation
