Delivering and securing AI agents in AI factories: F5 for the NVIDIA OpenShell Reference Architecture for safe AI agents

Kunal AnandChief Product Officer | F5

Consider a hypothetical scenario: an agent in an AI factory retrieves a document. Buried in it is a hidden instruction the user never intended the agent to execute. The agent follows it: opens a connection, calls a tool over Model Context Protocol (MCP), pulls a record nobody asked for, and sends it somewhere nobody approved. The guardrail that should have caught this was a sidecar in the same container, so the agent switched it off first. The log was under the agent's control, so the event was never recorded. Elapsed time: under a second. Nobody saw it, because nothing on the path could.

That is not an exotic failure. It is the default one wherever the controls live next to the agent, in the same trust domain, where a compromised or misled agent can disable them, route around them, or edit the evidence. Put simply: the agent cannot police the agent.

The F5 Application Delivery and Security Platform delivers and secures every app and API. AI agents are next, and they behave differently: an agent calls models, invokes tools over MCP, talks to other agents, and reaches APIs inside the factory and beyond it. To deliver value, agents need controlled access to models, tools, APIs, and data beyond their sandbox, and those interactions have to stay subject to enforceable policy. The NVIDIA OpenShell Reference Architecture, which NVIDIA is introducing at NVIDIA GTC Berlin, is built around exactly that. It puts the agent's runtime permissions, hardware enforcement, and inference on three tiers of NVIDIA hardware, and it leaves room for partners on the path between them. The clearest way to show who does what is to follow a request out of the sandbox.

What the NVIDIA OpenShell Reference Architecture does

The reference architecture starts from the premise that the agent is untrusted, and it separates the hardware accordingly.

Within the NVIDIA OpenShell Reference Architecture for safe AI agents, NVIDIA OpenShell runs on NVIDIA Vera CPUs and governs the agent’s runtime permissions. Its supervisor evaluates outbound requests, applies granular controls to configured HTTP, GraphQL, and MCP traffic, protects credentials, and records each policy decision. The agent runs in a sandbox. The supervisor that governs it does not.

NVIDIA Sentry adds an independent hardware monitoring and enforcement layer on NVIDIA BlueField-4 DPUs, in an isolated security domain the agent cannot reach or modify: threat detection, request and response inspection, agent governance, and containment measured in milliseconds. NVIDIA Sentry is an optional layer, and in NVIDIA Vera Rubin systems it sits on the path to the models.

NVIDIA Vera Rubin NVL72 infrastructure runs the models the agents call. So the architecture already decides whether an agent may act, and it already watches what the agent does, from infrastructure the agent cannot touch. F5 complements those controls with content inspection built for AI traffic, red teaming, and application delivery, building on our collaboration with NVIDIA on agent cybersecurity.

What OpenShell and NVIDIA Sentry decide

OpenShell knows which agent made a request, under which policy, and whether the destination and the method are allowed. For added protection, NVIDIA Sentry runs on NVIDIA BlueField-4 using NVIDIA DOCA to independently monitor agents, enforce policy in silicon, and quarantine agents within milliseconds. Between them, the question of whether the agent may act is answered outside the agent's control. That is the point of the design.

Runtime permissions, behavioral monitoring, and AI-specific content inspection provide complementary layers of protection. F5 adds inspection of supported prompts, model responses, and tool calls for prompt injection, jailbreaks, and sensitive data exposure, complementing OpenShell’s runtime governance and NVIDIA Sentry’s continuous behavioral monitoring and hardware-isolated policy enforcement.

F5 inspects what the agent sends and receives

F5 AI Guardrails inspects supported traffic routed to it from the enforcement path, including prompts, model responses, and tool calls carried over protocols OpenShell controls. It does three things with what it finds. It blocks prompt injection, jailbreaks, and tool calls outside policy. It redacts sensitive data before it leaves. It audits every decision into the session record. Its verdicts and telemetry are available to OpenShell and NVIDIA Sentry, so a blocked request can become an agent-level decision, up to containment, under the operator's policy. Because interception happens on the enforcement path and not inside the agent's container, the agent cannot disable Guardrails or route around it. There is no sidecar to switch off.

F5 AI Red Team keeps the guardrails honest. It attacks the agents and models through the same path a user would take, private and public alike, and what it finds becomes guardrail policy, so defenses keep pace with the agents they govern.

Governing an agent also means proving what it did. The F5 control plane holds the session record: user, prompt context, tool calls, approved parameters. OpenShell holds its policy decisions. NVIDIA Sentry holds the system record: file access, kernel calls, DPU packet metrics. Correlated, those records give one timeline of what the model intended, what the agent attempted, and what the agent did, from sources the agent could not touch.

The F5 AI Security Platform control plane and AI Red Team run inside the factory on the server side. The production inference models that agents call run on NVIDIA Vera Rubin NVL72, and AI Red Team also uses GPU resources for security testing. AI Guardrails require only an Arm CPU, so it can run on NVIDIA Vera and BlueField-4. The two reference architectures below show where each piece sits.

Two F5 reference architectures on NVIDIA OpenShell

Laid over NVIDIA's three tiers: AI Guardrails on Vera, applied to the agent harness inside OpenShell; AI Guardrails again on NVIDIA BlueField-4, out of the agent's blast radius, with the data plane when the factory needs it; the control plane and AI Red Team on Vera Rubin NVL72 with the models. That gives two reference architectures. Both are built on the NVIDIA OpenShell Reference Architecture, both use the same policy and the same control plane, and the difference is what sits in the agent's path.

Reference architecture 1: F5 AI Guardrails with NVIDIA OpenShell and NVIDIA Sentry

For the operator running the NVIDIA stack as designed. F5 AI Guardrails runs in two places under one policy: on NVIDIA Vera, applied to the agent harness inside OpenShell, and on the BlueField-4 DPU integrated into NVIDIA Sentry, where the agent cannot reach it. The first catches what the agent sends as it sends it. The second is the one the agent cannot switch off. Guardrails blocks, redacts, and audits the supported traffic routed to it, and on BlueField its verdicts are available to NVIDIA Sentry for instant agent containment. No additional hardware is required. An NVIDIA Cloud Partner standardizing on the NVIDIA stack gets content inspection without changing anything else.

Reference architecture 1. F5 AI Guardrails on the agent harness in OpenShell and inside NVIDIA Sentry on BlueField-4. One policy, out of the agent's blast radius.

For higher scale and enterprise-grade delivery. F5 BIG-IP Next for Kubernetes runs on the NVIDIA BlueField-4 DPU alongside NVIDIA Sentry, or on host CPU, as the factory's data plane, and F5 AI Guardrails runs inside it under the same policy. NVIDIA Sentry does the basic enforcement; BIG-IP Next for Kubernetes carries the traffic. BIG-IP Next for Kubernetes routes and load balances agent and application traffic across model instances on Vera Rubin NVL72, integrating with NVIDIA Dynamo. It isolates tenants, scales and secures Model Context Protocol (MCP) connections, governs token usage per tenant, and gives the operator one view across tenants and models. BIG-IP Next for Kubernetes also applies the operator’s external egress policies to traffic routed through it, complementing OpenShell’s runtime access controls and NVIDIA Sentry’s infrastructure policy enforcement.

Reference architecture 2. Proposed F5 application delivery and content inspection deployment complementing NVIDIA OpenShell and NVIDIA Sentry. Deployment topology is subject to product validation.

The choice is the operator's. Bring AI Guardrails to OpenShell and NVIDIA Sentry, or add BIG-IP Next for Kubernetes with AI Guardrails inside it. Policy and control plane are the same in both. The second adds tenant isolation, egress control, and traffic management for the whole factory.

One number, kept separate from the security architecture because it was measured separately. In The Tolly Group testing of BIG-IP Next for Kubernetes on NVIDIA BlueField-3 DPUs (report #226104, published March 2026), BIG-IP Next for Kubernetes delivered 40% higher token throughput than the tested baseline, with the data path offloaded from host CPUs. That is a measurement of BIG-IP Next for Kubernetes’ data plane on its own. It does not include the inspection functions described here. In AI, performance is economics.

Security that stays in the factory

In a fully self-hosted deployment, F5 security processing and audit records remain within the operator's environment: the control plane and Red Team on the server side with the models, inspection on Vera and BlueField-4. Access to external models and services remains governed by enterprise policy; the public destinations are in the diagram for a reason. Keeping every prompt and response inside the AI factory also requires locally hosted destinations and restrictions on external egress. The architecture makes that possible. The operator's policy decides whether it happens, and BIG-IP Next for Kubernetes that egress policy is enforced.

The agentic era did not create a new security requirement so much as move the most important control point to the agent's egress, onto infrastructure the agent cannot touch. F5 has spent three decades on exactly that kind of path. On the NVIDIA OpenShell Reference Architecture, it is a path the agent cannot talk its way around.

To learn more, I encourage you to visit our F5 AI Security Platform, F5 AI Guardrails, F5 AI Red Team, and F5 BIG-IP Next for Kubernetes webpages.

About the Author

Kunal AnandChief Product Officer | F5

Kunal Anand leads the F5 product organization as Chief Product Officer. Responsible for product vision, strategy, and execution, he ensures development of breakthrough solutions that solve critical challenges and create exceptional experiences for customers. In his previous role as Chief Technology and AI Officer, Kunal charted the company’s technology and AI strategy and vision. Prior to F5, Kunal held the dual role of Chief Technology Officer and Chief Information Security Officer at Imperva. His journey to Imperva began in 2018 with the acquisition of Prevoty, an application security startup he co-founded in 2013. Before joining Prevoty, he was the Director of Technology at BBC Worldwide. Kunal has a deep history of innovation and technical expertise, and has held roles leading security, data, technology, and engineering teams at Gravity, MySpace, and the NASA Jet Propulsion Lab. Kunal has over 15 years of experience in AI and machine learning, ranging from model training, employing AI-driven algorithms to enhance products, and designing and implementing AI architectures. Kunal holds a Bachelor of Science degree in computer science from Babson College.

More blogs by Kunal Anand