Blog
Routing isn't governance, and the gap is the opening
OpenRouter, LiteLLM, and Portkey all solve pieces of the LLM gateway problem. Here's the piece none of them solve, and why it's the one a security team actually cares about.
June 18, 2026 · 6 min read
Every team that puts an LLM into production eventually reaches for a gateway. The pitch is always some version of "one base URL, route to the cheapest capable model, see everything that happens." That's a real and valuable job. It's also not the whole job, and the gap between "we route" and "we govern" is where a lot of production AI projects get stuck.
Three tools, three different jobs
OpenRouter and LiteLLM are, at their core, routers: pick a model from a large catalog, normalize the API, send the request. They're excellent at coverage, if you need one of 200 models, one of them probably has it. But neither adds anything to the request itself. There's no guardrail deciding whether this prompt is safe to send. There's no signed record proving what happened. Routing is the entire product.
Portkey went further, it added guardrails and observability on top of routing, which is the right instinct. But Portkey was acquired by Palo Alto Networks and folded into Prisma AIRS, its enterprise security platform. That's a good outcome for Portkey and a hard one for the self-serve developer who turned it on with a credit card: that path is closing, and what's left is being pulled toward enterprise procurement.
So you're left choosing: a router with no governance, or a governance platform with no self-serve on-ramp. Most teams don't have a mesh team or a security procurement cycle on day one. They have a prompt, a bill, and eventually, a security reviewer asking questions.
Why governance can't be bolted on later
The instinct is to add security "once we need it." The problem is that a routing decision and a governance decision are made from the same information, at the same moment, on the same request. If the gateway that routes your request isn't the one screening it for PII, checking agent tool-calls against an allowlist, and signing the outcome into a tamper-evident chain, you end up bolting a second system onto the first, re-instrumenting everything, and hoping the two don't disagree about what actually happened.
That's the thesis behind RemKey: routing and governance aren't two products, they're one decision made twice as carefully. The classifier that sends a request to the cheap tier is the same layer that guards it, signs it, and, on a sample of downroutes, proves the cheaper answer held quality. One base URL, and the review a security team runs at the end is answered by the same trail the routing already produced.
Who each is actually for
- OpenRouter / LiteLLM: you need broad model coverage and you're doing your own governance elsewhere, or you don't need it yet.
- Portkey / Prisma AIRS: you're already inside, or headed toward, an enterprise security platform with the procurement runway to match.
- RemKey: you want routing and governance from the same drop-in endpoint, turned on in about 60 seconds, with a signed trail ready before a reviewer ever asks for one.