Joe Poyner, callsign OKC Joe, will tell you an AI gateway pays for itself, and his math holds up. But the money is the least interesting reason to run one. That same box that routes your cheap work to a cheaper model is the one place you can stop 40 engineers, a dozen agents, and four providers’ worth of API keys from scattering across .env files, Slack threads, and CI logs, one careless commit away from an expensive Monday.  

Full disclosure: Joe and I argue about almost everything, Star Wars versus Star Trek included. The AI gateway is one of the rare things we agree on, so I read his piece nodding along, right up to the point where a security professional has to keep going. 

Last stop on the financial train 

Joe built his whole case around a central hub that routes cheap, high-volume work to something like GLM-5.2 and saves the frontier model for the quarter of the work that needs it. Smart. But there’s a security risk to consider as well that doesn’t get nearly enough airtime: what happens when the credentials connecting your engineers to all those models get loose. 

An exposed API or license key isn’t a hypothetical. IBM’s own breach research puts the average cost of an incident involving compromised credentials at $4.81 million GitGuardian scanned nearly two billion public GitHub commits and found more than 28 million secrets pushed into public repos in a single year.. When Google’s own Gemini keys started leaking through client-side code, researchers found close to 3,000 of them sitting exposed, and it didn’t stay theoretical for long. One developer watched a stolen key rack up $82,314 in charges in about 48 hours.  

Now picture that same risk at Blank Label Software (Joe’s hypothetical company) and apply it across the 40 engineers, a dozen coding agents, and three or four model providers, each with its own key floating around in .env files, Slack messages, code, cache, and CI pipelines. A gateway certainly collapses that sprawl into one place and with the right platform, it can even abstract and ultimately protect direct access to those credentials. Your engineers and their agents never need to touch a provider key directly. You get the routing and cost benefits Joe described, and you get rid of the 40+ key spider web. Virtual, revocable keys, scoped and rotated at the control point, not hard-coded into every workflow. 

Guardrails: Cheaper to run once, in one place

Here’s where I have to gently push past Joe’s “the model doesn’t really matter” comfort level, because it’s true right up until the guardrail conversation starts. 

You need guardrails regardless of whose logo is on the model. Foreign or domestic, open-weight or frontier, the core problem is the same: you can’t hand an AI system the keys to take direct, unsupervised action against your infrastructure. Independent testing keeps proving this out. Qualys ran DeepSeek-R1 through 885 jailbreak attempts across 18 attack types and watched it fail 58% of them. Cisco and the University of Pennsylvania went further and jailbroke DeepSeek-R1 on every single prompt they tried. 

That’s the headline risk with foreign models specifically, but let’s be honest about the rest of the sentence Joe’s post already conceded: prompt injection isn’t a foreign problem, it’s an agent problem. Anthropic and OpenAI have both published their own research catching their models gaming test suites when it was easier than doing the work honestly. The difference with the foreign open-weight models isn’t that the flaw is unique to them. It is that, on average, the safety training underneath is thinner, so the same attack lands more often. Either way, the fix isn’t to avoid one country’s models. The fix is a policy layer that inspects every prompt and every tool call before it reaches any model, and blocks or sanitizes the ones that look like an attack or potentially sensitive data going out. The same enforcement point regardless of which provider is on the other end. 

Building that inspection logic once, at the gateway, and having it apply to every model you route through, is dramatically cheaper than trying to bolt guardrails onto every individual agent, every individual integration, and every individual model API separately. Do the guardrail work one time, at the one place all your AI traffic already should be passing through anyway. 

The idea of a central AI gateway isn’t a fringe opinion anymore. It is where the industry is standardizing. CrowdStrike made this explicit in June, extending Falcon AI Detection and Response across a list of AI gateway partners (Databricks, Google Cloud, LiteLLM, Microsoft Azure, and, notably, JetStream Security) specifically to give enterprises one place to inspect prompts before they reach a model and to block or rewrite risky responses in real time. Anthropic itself created the Model Context Protocol specification that most of this tooling governs. The company that makes the frontier model Joe’s whole cost argument is built around is also the one that standardized the plumbing everyone now agrees needs a control point in front of it. When the model vendor, the endpoint security vendor, and the data platform vendors all converge on “put a gateway in front of it,” that’s not marketing alignment. That’s the industry admitting the model layer alone was never going to be the place you enforce governance or security. 

A Hard pivot: MCP security and Shadow AI 

Everything above assumes you know what’s actually talking to your models. Increasingly, companies don’t…especially our own Blank Label Software. 

Model Context Protocol has become the default way agents reach out and touch your databases, your file systems, and your internal APIs, and it’s being adopted faster than most security teams can track it. Gravitee surveyed 750 CIOs, CTOs, and engineering leaders across the US and UK and found that 47% of the roughly 3 million AI agents those companies had already deployed weren’t being actively monitored or secured. Eighty-eight percent of those same organizations said they’d already experienced, or suspected, an AI-agent-related security or privacy incident in the past year (Gravitee CIO/CTO survey, February 2026, via Zuplo). Wallarm’s threat research counted 315 MCP-related vulnerabilities published in 2025 alone, a category that grew 270% in a single quarter, and traced a top 10 breach directly back to a path-traversal flaw in an exposed MCP server that handed attackers a foothold in production AI infrastructure, according to that same Zupio piece.  

This is Shadow IT wearing a new coat. An engineer wires up an MCP server to Slack or a database over a weekend using a CoWork automation because it solved a problem; nobody from security ever reviews it, and now there’s an unlogged, unauthenticated bridge sitting between a language model and a system that was never supposed to be internet-reachable. OWASP has already given this its own category in the MCP Top 10: rogue and shadow servers, tool shadowing, where a malicious server impersonates a legitimate one and hijacks what the agent thinks it’s calling, and straightforward data exfiltration through tools nobody vetted. 

The fix looks exactly like the fix for everything else in this post: route MCP traffic through the same governed control point you’re already using for models, so every connection gets authenticated, authorized, and inspected before an agent gets to act on it, instead of every team standing up its own unmonitored bridge to production. One gateway. One inventory. One place your security team can actually see what your AI is allowed to touch. 

Bringing it home

Joe’s math on the savings is sound, and I’m not here to argue with it (for once). I’m just here to point out that the same architectural decision that pays for itself in his ledger is the one thing standing between “we have full visibility and control over every model our company touches” and “we have 40 engineers, a dozen agents, and no idea what any of them can actually reach.” Run the numbers Joe’s way. Build the gateway my way. Do both, and you’ve got the rare case where the cost argument and the security argument point at exactly the same. 
 
Since Joe showed his cards, I will show mine. That control point, the one place you route for cost and lock down for safety, is what we build at JetStream. The routing and virtual keys live in JetStream AI Hub™ and JetStream Key Broker™, giving access to the JetStream Verified MCP™ catalog that governs the MCP problem above at the same control point. Joe kept his how-to vendor-neutral, and so will I. Stand it up with LiteLLM and be happy. But if you would rather it come governed, now you know where we sit. 

Now, about Star Wars versus Star Trek… that one’s not getting solved with a gateway.