An AI gateway sits between your apps and the model APIs they call. This page sorts the vendors into five categories and shows the one layer most of them leave open.
That layer is web navigation: which pages an AI agent may open. It is what an AI agent allow list covers.
The term is used loosely. Vendors with very different products all call themselves AI gateways.
An AI gateway is a proxy that every call to a large language model passes through.
It adds routing, keys, cost limits, logging and safety checks without changing each app.
A classic API gateway manages your own APIs. An AI gateway manages outbound calls to model providers.
Some gateways include prompt and response filters. Others leave that to a separate security product.
The gateway sees prompts, completions, tokens and tool call payloads as they pass.
When an agent's browser tool opens a page, that request often goes out on a different path.
As agents take actions, buyers expect the gateway to decide what those actions may touch, including web pages and MCP tools.
For how the terms relate, see LLM gateway vs AI gateway vs MCP gateway.
Names below are examples that buyers commonly shortlist. They are grouped by where the product came from, which shapes what it controls.
Vendor names are listed as examples of each category, based on how the vendors describe their products. Check current capabilities with each vendor before buying.
Most buyers compare gateways on the first four rows. Agent deployments add the last three.
Send each call to the right provider, with fallbacks when one fails.
CommonOne place for provider keys, with per-team virtual keys.
CommonToken budgets, rate limits and spend alerts per app.
CommonPII masking, toxicity checks, prompt-injection detection on text.
VariesRead which tool the model asked for, and with which arguments.
VariesWhich MCP servers and tools an agent may connect to.
EmergingWhether the URL an agent is about to open is a login, checkout or upload page.
Usually missingA gateway can read "open https://example.com/account/new" in a tool call.
It cannot tell that this path is a signup page unless something has already mapped that site.
| Category | Best at | Typical buyer | Agent web control | Where page data plugs in |
|---|---|---|---|---|
| API management | Policy engine, auth, quotas | Platform and API teams | Needs a custom plugin | Plugin calls the lookup before egress |
| Edge and CDN | Caching, analytics, simple setup | Web and app teams | Not in the model path | Worker or function checks tool URLs |
| LLM ops gateways | Multi-model routing, budgets | Product engineering | Text guardrails only | Custom guardrail on tool calls |
| Data platforms | Governance tied to data | Data and ML teams | Limited | Policy table in the catalog |
| Open-source proxies | Full control, extensibility | Platform engineering | You build it | Filter or sidecar with local database |
The pattern holds across all five. Gateways own the model path, and navigation needs its own data source.
Most enterprises need both. See how to build an agent policy engine for the proxy side.
A lookup that says which part of a site a URL points to, before the request leaves.
The same check works as a plugin, a sidecar or an on-premise table. Details are in the API docs.
If not, URLs requested by agents are invisible to your policies.
Logging alone is not control. Ask for a pre-execution deny.
You will want to plug in URL data you did not build.
A navigation check should stay in the low milliseconds.
Fail-closed should be the default for agent traffic.
Agents increasingly reach tools through MCP servers.
Auditors will ask which agent tried which URL, and why it was denied.
Regulated teams often need the policy data inside their network.
Short orientation notes, not reviews. Each vendor's own documentation is the source of truth.
AI plugins on the Kong API gateway, including model proxying and prompt guard plugins. Category 01.
AI gateway policies such as token limits and load balancing across model deployments. Category 01.
API management used as a front door for model APIs, with Google Cloud identity. Category 01.
API management with AI gateway features for IBM-centred estates. Category 01.
Analytics, caching, rate limits and logging for model calls at the edge. Category 02.
One API to many models for apps built on the Vercel platform. Category 02.
Gateway with routing, fallbacks and guardrails, popular with product teams. Category 03.
Open-source proxy that exposes many model providers behind one compatible API. Category 03.
Open-source observability and gateway focused on logs, costs and caching. Category 03.
Usage tracking, rate limits and guardrails governed inside Databricks. Category 04.
Open-source project built on Envoy for model traffic in Kubernetes. Category 05.
Solo.io's cloud-native gateway with AI traffic policies. Category 05.
None of these notes claims that a vendor lacks a feature. Ask each one the eight questions above.
Record every URL your agents request for two weeks. Tag each with its page type from the lookup.
Count how often agents hit login, signup, checkout and upload pages. That is your real exposure.
Block the 8 action types by default. Keep read pages such as docs, pricing and blog open.
Deny unclassified destinations, then add approved exceptions per agent role.
signup, password_reset, cart, checkout, upload, post_create, comment and subscribe.
These are pages where an agent does something rather than reads. See page types explained.
| Your situation | Start with | Add for agents |
|---|---|---|
| You already run Kong, Apigee or Azure APIM | Their AI plugins | A pre-egress plugin calling the page-type lookup |
| Your apps sit on Cloudflare or Vercel | Their AI gateway for model calls | URL checks in the browse tool or a worker |
| Many models, many teams, fast product work | An LLM ops gateway | A custom guardrail on fetch and browse tools |
| Everything lives in one data platform | The platform's AI gateway | An on-premise page-type table in the catalog |
| Strict network control, Kubernetes everywhere | Envoy or another open proxy | A filter with the full database licensed locally |
| Browser and computer-use agents | Any of the above for model calls | An egress proxy or enterprise browser with page rules |
If you build a gateway, your customers will soon ask what their agents may browse.
See pricing, or the AI gateway integration page for the product view.
The honest fine print — the same two assumptions we publish, plus two operational ones
Where gateways sit among the other agent security categories.
Three terms, three traffic paths, one comparison.
The 28 page types and how the data is delivered.
Category data for the same domains, from our sibling product.
Test the data on 100 real domains, then choose API, on-premise or OEM.
