When enterprises start deploying AI workloads, they typically go looking for a dedicated AI gateway. F5 thinks that's the wrong instinct — and they have a straightforward argument for why.
About 50% of NGINX deployments already sit in front of Kubernetes clusters. When AI workloads land in those same clusters, NGINX is already there. It's already trusted. It's already in the traffic path. The question F5 is answering with its NGINX AI gateway strategy isn't "how do we build something new?" It's "why would you add something when what you need is already running?"
Shawn Wormke, SVP of Product Management at F5, put it plainly during AppWorld 2026 in Las Vegas: "It doesn't require people to change. And I think that's the biggest differentiator."
That's the bet. And for developer and platform teams who have spent years standardizing on NGINX, it's worth understanding what that actually means in practice.
What MCP Traffic Is Revealing
One of the more significant things coming out of F5's NGINX work isn't a feature — it's what visibility into MCP traffic is showing enterprises about their own environments.
MCP, the Model Context Protocol, is the emerging standard for how AI agents communicate with tools, APIs, and data sources. When NGINX parses MCP metadata, it gives operations teams a view into AI activity that most enterprises didn't know they were missing.
What they're finding is that more AI is already running than anyone realized. More sensitive data is being accessed. More shadow AI is operating in the background. The visibility problem turns out to be bigger than the security problem — and you can't address the second until you've solved the first.
For platform teams, this is a meaningful shift. The same proxy that handles your web traffic can now surface what your AI agents are actually doing, who they're talking to, and what data they're touching. No new tooling required. No rearchitecting the stack.
NGINX MCP visibility is now generally available in NGINX Open Source. Enterprise support is available through NGINX Plus.
The AI Gateway Argument
The case for a separate AI gateway usually goes something like this: AI traffic is different, AI models need specialized routing, and purpose-built tools handle it better than general-purpose infrastructure.
F5's counter-argument is operational. A dedicated AI gateway means another tool to deploy, another vendor to manage, another configuration surface to maintain, and another potential point of failure between your users and your models. If NGINX is already handling traffic management, TLS termination, and load balancing for the applications sitting next to your AI workloads, adding a separate gateway layer creates complexity without adding capability.
The argument gets sharper when you look at where enterprises actually are in their AI deployments. Wormke was direct about this at AppWorld: the narrative about enterprise AI adoption doesn't always match reality. "If you read everything on the internet about AI, you think all of these customers are doing all this stuff. But the reality is, some are. A lot of enterprises are just trying to figure it out."
For the majority of organizations still in early deployment stages, the last thing they need is infrastructure sprawl. NGINX as an AI gateway works because it's already there.
What NGINX Handles in the AI Traffic Path
Within F5's ADSP platform, NGINX addresses several specific problems in the AI traffic path.
Routing and load balancing for AI model endpoints works the same way it works for any application — with the addition of LLM-specific routing logic that can direct requests based on model type, token budget, or other AI-specific parameters.
Rate limiting and quota enforcement matter more with AI workloads than with traditional applications because token costs are real and variable. NGINX can enforce limits at the gateway layer before requests ever reach the model.
Observability via MCP parsing gives teams visibility into agent behavior — what actions agents are taking, what tools they're calling, and what data they're accessing. This is genuinely new capability. Traditional application observability doesn't capture the semantic content of AI interactions. MCP visibility does.
Security controls apply the same WAF and bot defense capabilities that already protect your web applications to AI traffic — including protection against prompt injection and model abuse.
The Rollout Sequence
F5 is sequencing the NGINX AI gateway capabilities based on where they see the most immediate customer pain. Automated certificate management is first — operationally unglamorous, but a real friction point for teams managing certificates across large NGINX deployments. AI-specific capabilities build on top of that foundation.
The broader NGINX roadmap runs through 2026 and into 2027 as part of F5's ADSP platform expansion. BIG-IP got F5 Insight first. NGINX and Distributed Cloud follow as the platform matures.
For developer and platform teams already running NGINX, the practical implication is straightforward: the infrastructure you have is being extended to handle AI workloads without requiring you to replace it or work around it. That's a different kind of product story than most of what gets announced at conferences. It's not about adding something new. It's about making what you already trust more capable.
And in a period when most engineering teams are already managing more complexity than they'd like, that distinction matters.