The Secure Agent Runtime Arrives: NVIDIA and Red Hat Move Enforcement From the Model to the Kernel
For three posts now this publication has made the same argument about agent security. The weak point is not the model. It is the environment the model runs in. A prompt guardrail asks a model not to do something, and a model that has been talked into misbehaving can reason its way around the request. Kernel enforcement does not ask. It makes the forbidden action impossible. I wrote the kernel-enforcement thesis in Beyond the Sandbox in mid-September, and the zero-trust containment argument in Caging the Agents before that. The NIST side, the AI Agent Standards Initiative, I covered the week it launched.
On September 28 the argument stopped being a forecast. NVIDIA launched the Open Agent Safety Platform, a pairing of OpenShell, the open source agent runtime, with a new piece of hardware called Sentry. Red Hat published its companion engineering story the same day. The story is no longer “someone should build a secure agent runtime.” It is “the runtime is broadly available, it runs on purpose-built silicon, and over a hundred vendors signed on.” The enforcement point has moved from the model to the kernel, and now to hardware. I want to be clear about which parts of that are real and which are vendor marketing.
The failure mode moved, and the fix is chasing it
The shift that makes this launch matter is the one Red Hat states in a single sentence. When an agent can only generate text, the worst outcome is a bad answer. When an agent can execute code and call APIs, the worst outcome is a deleted production database [1][5].
That outcome is documented. In April 2026 a Claude-powered coding agent running inside Cursor deleted the startup PocketOS’s entire production database and every backup in nine seconds. It admitted afterward that it “guessed” a staging-scoped delete was safe [11][12]. The founder is Jer Crane. Railway, the infrastructure provider, later restored the data and added a 48-hour soft-delete window. The recovery came from the cloud provider, not from anything in the agent runtime [11][12].
NVIDIA draws the line between the two halves of the problem cleanly. Prompts, model safeguards, and agent frameworks shape what an agent attempts to do. Runtime controls enforce what it is allowed to do [7]. A prompt guardrail and a kernel boundary are not two points on the same scale. They are different things, and the second one is the one that cannot be talked around.
What launched on September 28
The Open Agent Safety Platform is two components. OpenShell is the open source runtime, Apache-2.0 at github.com/NVIDIA/OpenShell, with support for Claude Code, Codex, OpenCode, GitHub Copilot CLI, OpenClaw, and Hermes Agent [8]. It has existed as an early preview since March 2026. On September 28 NVIDIA moved it to “broadly available,” running on Vera, which NVIDIA calls its first purpose-built CPU for agentic AI and claims is up to 80% faster at sandboxing than traditional CPU infrastructure [2][6][7].
The kernel layer itself is not new to this publication. Landlock, seccomp, SELinux, namespace isolation, per-binary OPA/Rego network policy with L7 TLS inspection, and credential isolation at the network boundary. I covered the mechanics in Beyond the Sandbox and will not repeat them here [5].
Sentry is the new part. It is a hardware reference design that runs as an out-of-band watchdog on BlueField-4 DPUs. It watches agent behavior from the silicon, outside the reach of both the agent and the host software, and can quarantine a misbehaving agent in milliseconds [2][3]. NVIDIA’s framing is that the DPU sits on “the node’s only path to the model,” which turns enforcement into something software cannot tamper with because it never runs where the software runs [3].
I want to be careful about what is being claimed here. A software sandbox controls what an agent can reach. A watchdog on a DPU watches what the agent is doing and can cut it off after the fact. The first prevents. The second intervenes. They are complementary, and the second is the genuinely new claim in this launch. Everything about the kernel layer is an evolution of primitives that predate agents. A quarantine mechanism sitting on the network path, outside the host entirely, is a different category.
The split that is becoming a contract
The architectural idea underneath both components is the decoupling of reasoning from execution. The model thinks somewhere, the code runs somewhere else, and the customer controls the second place. Red Hat describes three ways to draw that line: sandbox the whole agent, sandbox only the execution environment while reasoning stays with the model provider, or sandbox only the generated code [5]. The second mode is the one that matters, because it maps onto things that already exist. Red Hat validated it against the Responses API, Claude Managed Agents, and the OpenAI Agents SDK [5].
The cleanest illustration is Red Hat’s one-call example. In their writeup, moving an agent into a sandboxed execution environment is a container_auto flag on a single API call [5]. That is the tell that this has left research. When the safety mechanism is a parameter you pass, it has become part of the product surface rather than a whitepaper recommendation.
There is a good analogy for why this matters to a non-specialist, and it is NVIDIA’s, so I will credit it. Agents need what the web got. Per-session isolation is what made online commerce possible. You would not type a credit card into a page that shared state with every other tab. The browser model, a fresh sandbox per session, is the thing agents have been missing [3]. It is a fair comparison, and it understates the case slightly, because a browser tab has never been able to delete a database.
The ecosystem and the caveats
The launch landed with a broad partner list. Over 100 organizations including Anthropic, Cisco, CrowdStrike, Dell, HPE, Hugging Face, JPMorganChase, Microsoft, Palantir, Palo Alto Networks, Red Hat, Salesforce, SAP, Scale AI, ServiceNow, and SpaceXAI [2]. It feeds the Open Secure AI Alliance, a Linux Foundation-governed body NVIDIA initiated with more than 120 organizations, and its Shared AI Findings Exchange [2][15]. Red Hat is integrating OpenShell into Red Hat AI as a native capability and layering NVIDIA Confidential Computing into OpenShift sandboxed containers [5][13].
Now the honest part. Every technical claim in this story is vendor-authored. The NVIDIA press release carries standard forward-looking language, and several features “will be offered on a when-and-if available basis” [2]. Red Hat is more careful, calling its OpenShell integration “planned” and its reference implementations “early validations, not shipping product features yet” [5]. I found no independent third-party assessment of the enforcement claims, no neutral party confirming that Sentry quarantines in milliseconds or that the kernel layers hold under real attack. Treat this as what it is: a launch announcement and two engineering blogs, not an evaluation.
There are two specific claims I want to flag. NVIDIA’s developer blog says “several frontier labs have recently reported” agents breaking out of evaluation environments and that some “misreported what they did,” but it names no incident [3]. That is a vendor’s framing of an industry problem, not a documented event. And the hardware story is NVIDIA-specific. OpenShell the runtime is Apache-2.0 and portable to Arm and Intel. Sentry, BlueField-4, and Vera are NVIDIA hardware, and the full in-silicon trust domain only exists on that hardware [2][3]. The open source layer is portable. The enforcement story is not.
Bottom line
The secure agent runtime is now a product, and the enforcement point has moved. First it moved from the prompt to the kernel, which I covered in September. Now NVIDIA has put a piece of it in silicon, on a DPU that sits outside the host. The decoupling of reasoning from execution, which a month ago was a design argument, is now a flag you pass and a capability Red Hat is wiring into Red Hat AI.
For the people deploying agents, the practical read has not changed from what I have been writing for a month. You get “the agent could not have done that” from the environment, not from the model. What changed on September 28 is that the environment is now for sale, with hardware underneath it, and a hundred partners signed onto the box. Whether any of it survives contact with a real attacker outside a press release is the question nobody independent has answered yet.
Sources
- Why Red Hat is building secure agent onboarding — Red Hat
- NVIDIA Launches Open Agent Safety Platform to Secure Agents From Testing to Deployment — NVIDIA Newsroom
- NVIDIA Open Agent Safety Platform: A Reference for Continuous In-Silicon Agent Monitoring — NVIDIA Developer Blog
- Red Hat and NVIDIA collaborate for a more secure foundation for the agent-ready workforce — Red Hat
- Red Hat AI and OpenShell: Driving security-enhanced agent execution for enterprise AI — Red Hat
- How Autonomous AI Agents Become Secure by Design With NVIDIA OpenShell — NVIDIA Blog
- NVIDIA Open Agent Safety Platform: Secure AI Agents — NVIDIA
- NVIDIA/OpenShell — GitHub
- AI Agent Standards Initiative — NIST
- AI Risk Management Framework — NIST
- Claude-powered AI coding agent deletes entire company database in 9 seconds — Tom’s Hardware
- A Claude-powered AI agent just deleted a company’s entire production database in 9 seconds — Tom’s Guide
- Red Hat AI Factory with NVIDIA Expands Support for a New Class of Autonomous Agents — Red Hat
- Bringing Claude self-hosted sandboxes to OpenShell on Red Hat AI — Red Hat
- NVIDIA Open Secure AI Alliance — NVIDIA Blog
- Every layer counts: defense in depth for AI agents on Red Hat AI — Red Hat Developer