The AI gateway market in 2026: three products, one name

Three products wearing one name

The category was named by companies that already owned a proxy, so the label describes a shape rather than a job. As of September 2026, the market sorts into three types, and the vendors below are the ones a buyer meets most often.

• The infrastructure proxy that grew an AI mode. Cloudflare AI Gateway sits in front of your existing provider URL, so you keep each provider's own SDK and gain caching, request analytics and rate limiting for almost no integration work. Kong AI Gateway extends an established API gateway into model traffic, with the operational model your platform team already runs.
• The developer routing layer. LiteLLM is self-hosted and takes no markup on provider pricing, with virtual keys, per-team budgets, spend tracking and request fallbacks. Portkey is the managed version of the same idea, with broader provider coverage and guardrails you do not have to operate yourself.
• The enterprise governance product, which markets itself worst of the three. It is the category a risk or security team is usually asking for, and it is rarely what arrives when an engineer is told to go and get an AI gateway.

The expensive buying mistake

A routing layer bought against a governance requirement looks fine for a quarter. You get spend visibility, provider failover and a tidy dashboard. Then the first real question arrives from risk: which agent did this, acting for whom, under whose authority, and what did it change in the CRM. The routing layer has request logs. It does not have an answer, and no amount of configuration turns one into the other, because it was never modelling an actor or an action. The mistake in the other direction is cheaper. A governance product used for plain routing is heavier than the job needs, and you notice that in week one rather than at the audit.

The questions that separate these products

Vendor pages converge on the same vocabulary, so ask about behaviour instead. Put one real request through each candidate and work down this list.

• Does a policy decision happen before the request reaches the provider, or is the record written after the fact
• Can a policy differ by agent identity, by use case, by person and by data class, or only by API key
• What happens when the policy service cannot be reached: does the request proceed, stop, or wait for a person
• Does the product model a tool call against a business system, or only a call to a model
• Can one reviewer reconstruct a single run without joining several unrelated logs
• Does the record distinguish what was attempted, what was blocked and what completed
• Where does sensitive-data inspection run, and what does the model receive versus what the record keeps

Where the regulation actually lands on this

Vendors in this market often reach for the EUR 35 million figure from the EU AI Act. That number is the top tier under Article 99 and it applies to prohibited practices. Record-keeping and transparency duties for high-risk systems sit in the middle tier: up to EUR 15 million or 3% of worldwide annual turnover. The timing changed too. The Digital Omnibus entered into force on 27 July 2026 and moved the Annex III high-risk obligations, where most record-keeping duties live, to 2 December 2027. Article 50 transparency still lands on 2 August 2026. If a vendor is selling you urgency against an August 2026 high-risk deadline, their material is out of date, which is a useful thing to learn about a vendor during evaluation.

What none of these products cover once an agent acts

Every product in this market governs the request to a model. That is a real control, and it stops at the moment the model output becomes an action. An agent can pass a perfectly compliant model call and then invoke a payment tool, edit an order or send an email on a customer's behalf, and the routing layer has no view of any of it. OWASP put that gap into its Top 10 for Agentic Applications, published on 9 December 2025, naming identity and privilege abuse and rogue agents as agent-level risks rather than model-traffic ones. The distinction is architectural, not a verdict on product quality. An application that only calls models needs the left-hand column. An agent that acts needs both.

Where Difinity sits, and why it is not on this list

Difinity is not an AI gateway and is not an entrant in this market, which is worth saying plainly on a page like this rather than claiming a fourth camp. A gateway routes model calls, caches them and observes them. Difinity governs a run. An organisation configures its use cases, its agents and its connections in Hub, and every action, whether a chat reply or a tool call, goes through the same enforcement pipeline. Authority is settled before the run and never widens during it: it is the intersection of what the agent version binds, what the caller is entitled to and what the use case permits. Anything that changes something elsewhere is read by a judge running on AWS Bedrock before it happens, against a per-tool policy the organisation wrote in its own words, and the action then leaves through a tool gateway that holds the credential and decides. The agent holds no credential and cannot reach a system itself. What happened is written to an append-only run trail as it happens. A team that wants cheaper, faster model calls across providers should buy a routing layer. A team that has to show an agent did nothing it was not authorised to do is solving a different problem.

How current this is

Every capability above is dated to 2 September 2026, and all five named products ship features monthly, so treat the specifics as a starting point rather than a matrix you can reuse next quarter. None of them were tested hands-on for this page: the capability descriptions come from two independent published comparisons, not from our own bench. That is enough to tell the three types apart, which is what this page is for. It is not enough to settle a head-to-head between two vendors in the same camp, and anyone doing that should run their own workload through both.