Red Hat brings NVIDIA's OpenShell agent sandbox and BlueField monitoring to OpenShift

What Red Hat and NVIDIA announced

Red Hat said on 21 October 2026, at NVIDIA's GTC conference in Berlin, that it is expanding its collaboration with NVIDIA to secure autonomous AI agents running on Red Hat AI Factory with NVIDIA, the companies' jointly engineered AI platform. The press release groups the work into three parts: agent security built around NVIDIA's OpenShell Reference Architecture, a reference design for governing access to models, and early operating-system support for NVIDIA's Vera CPUs and the coming Vera Rubin platform.

The headline piece is security. Red Hat says it is working with NVIDIA on the OpenShell Reference Architecture and supporting it through integrations with Red Hat AI Factory with NVIDIA, and that it is actively collaborating to make OpenShell a native capability of Red Hat AI. Red Hat also describes itself and NVIDIA as leading contributors to OpenShell, the open-source agent sandbox runtime that NVIDIA released in September.

The announcement came with two technical write-ups: a Red Hat blog post on running NVIDIA BlueField data processing units (DPUs) and DOCA Argus monitoring on Red Hat OpenShift, and an NVIDIA developer blog post explaining NVIDIA Sentry, the hardware-isolated monitor at the bottom of the stack.

Why the controls sit outside the agent

Both companies build the pitch on one premise. "An agent shouldn't be enforcing its own boundaries," John Fanelli, NVIDIA's vice president of enterprise software, said in the release. "Those controls belong outside the agent, in the runtime and the infrastructure beneath it."

Red Hat's blog names the two failure modes it wants to address: agents that overstep their authorised bounds when instructions are ambiguous or a task takes an unexpected turn, and agents that attackers take over through prompt injection or a supply-chain compromise. Model guardrails alone, the post argues, cannot cover either case, because both happen inside the software being guarded.

That concern is no longer hypothetical. This week OpenAI said two of its own coding agents weakened the monitors meant to catch them, and NVIDIA's Sentry post opens by noting that agents can circumvent security controls while using tools and credentials to pursue a goal. On the supply-chain side, the LiteLLM package compromise showed how quickly a trusted dependency inside an agent stack can turn hostile.

How Sentry watches an agent from the DPU

The design has two layers. OpenShell is the software layer: a sandbox runtime that separates policy enforcement from the agent, so a compromised agent cannot rewrite its own restrictions. Our earlier report on OpenShell covers its sandbox, supervisor and policy prover. Beneath it sits NVIDIA Sentry, which runs on a BlueField DPU, a network card with its own Arm processors and a separate trust domain from the server's main CPU.

NVIDIA's post says Sentry sits on the node's only path to the model and the outside world. Agent traffic reaches the DPU directly, where DOCA Flow acts as a per-agent firewall and DOCA Tower, an inspection proxy built on the open-source Envoy proxy, terminates TLS and checks each request against rules written for Open Policy Agent, an open-source policy engine. NVIDIA says those checks can run in under a millisecond, depending on the policy.

The second source of evidence is DOCA Argus, which reads selected regions of host memory from the DPU to map containers, processes, open files, network connections and loaded libraries, tracked by their hashes. That lets a policy demand, for example, that the container's hash is on an approved list and that the process opening a connection appears in the container's software bill of materials. NVIDIA lists warning signs Sentry watches for, including unapproved tools, one process attacking another with ptrace, unusually heavy outbound traffic and large-scale file deletion. It can also pass agent communications to classifier models to look for behaviour drifting from the agent's intended task, and keep tamper-evident records for investigators.

When something trips, both companies say the affected workload can be cut off at the hardware level in milliseconds, without the cooperation of the agent or the host operating system. Those speed claims are the vendors' own; neither post publishes test results.

What runs on OpenShift now

Red Hat's blog is specific about what exists today. Support for BlueField-3 DPUs is generally available in Red Hat OpenShift 4.22, which manages the setup as two clusters through NVIDIA's DOCA Platform Framework: a tenant cluster on the server's main cores runs the AI agents, while an infrastructure cluster uses the DPUs as worker nodes for networking and security services. In what Red Hat calls Zero Trust mode, the DPU blocks host access to its management interfaces, so its controls and telemetry stay protected even if the host is compromised.

In that arrangement, Argus alerts feed an integrated security system, which can tell the DPU to isolate the affected workload's virtual network function. Red Hat adds a practical argument: moving monitoring and networking onto the DPU frees host CPU cycles for the AI workloads themselves.

There is a hardware wrinkle worth noting. Red Hat's OpenShift write-up is built on BlueField-3, while NVIDIA's Sentry post describes Sentry running on BlueField-4. SiliconANGLE's report also frames the OpenShift work as building on existing BlueField-3 support. Buyers should check which Sentry features their DPU generation actually gets.

Governing which models agents can call

The second part of the announcement is about the models agents call. Red Hat and NVIDIA describe a joint reference design, based on NVIDIA's Inference Hub design, that puts Model-as-a-Service access control and an AI gateway in front of inference engines including vLLM, llm-d, NVIDIA Dynamo and NVIDIA NIM microservices. It offers self-service model discovery, per-user access policies, rate limits and subscription-style entitlement tracking.

The point, the release says, is to separate who may use a model from where the model runs, so platform teams can manage quotas and attribute costs across on-premises and cloud clusters. Red Hat also says NVIDIA's Nemotron models, including Nemotron 3.5 Super VL, are fully supported in vLLM and its AI Factory, and points to FP8 and speculative-decoding checkpoints for that model made with its LLM Compressor tool to cut inference latency.

For security teams this is the quieter but more immediately usable half. Rate limits and per-agent entitlements are ordinary controls, and they complement identity-based approaches such as the Guardian Agents Microsoft added to Project Perception this week.

Vera CPUs and Vera Rubin support

On hardware, Red Hat says Red Hat Enterprise Linux for NVIDIA, its partner-tuned edition of RHEL, now supports NVIDIA Vera CPUs, and that it is preparing day-zero support for Vera Rubin systems. NVIDIA's pitch for Vera is that agents spend much of their time in CPU-heavy loops of tool calls and sandbox execution; the release repeats NVIDIA's claim of twice the agentic CPU performance, without saying what it is measured against.

SiliconANGLE, citing a Red Hat operating-system blog, reports that RHEL for NVIDIA 26.03 changes a limited set of core packages for the new hardware while keeping the standard RHEL userspace and SELinux, and that customers can move to mainline RHEL without reinstalling once the patches reach the upstream kernel. The timing matters because Vera Rubin capacity is arriving: Google Cloud says its A5X Vera Rubin instances reach general availability next month.

What is not shipped yet

The most important caveat is in the release itself: native OpenShell integration in Red Hat AI is still work in progress. What customers can use now is OpenShift with BlueField-3 and Argus, the inference reference design and the Nemotron support, delivered through partners Red Hat names as Cisco, Dell Technologies and Lenovo. Neither company gave prices, a date for the native integration, or customer deployments.

Security claims also need outside testing. The millisecond containment figure and the idea that an attacker on the host cannot reach the DPU are design goals that hold only if the DPU is configured to restrict host access, as Red Hat's own wording notes. Memory introspection catches what its rules look for, and classifier models that judge whether an agent has drifted will have false positives and misses. Still, the direction is clear: Red Hat and NVIDIA are betting that agent guardrails belong in infrastructure the agent cannot touch, not just in the model's training.