The names sound interchangeable. Each one sits on a different wire and sees a different kind of request.
This page compares them by traffic path, then shows the one path none of them covers: the web pages an agent opens. That path is what an AI agent allow list controls.
Front door for your own services. Auth, rate limits, routing.
It has existed for years and knows nothing about models.
One endpoint for many model providers. Routing, fallbacks, keys, costs.
Built for engineers switching between models.
An LLM gateway plus policies: prompt filters, PII masking, quotas per team.
The term buyers and analysts use most.
Proxy between MCP clients and MCP servers. Server allowlists, tool filtering, auth.
The newest of the four.
Some products do two or three of these jobs. The distinction still matters, because each job needs different data.
Follow a single research agent through one task. It produces four kinds of traffic.
Path 1: model calls
Path 2: tool calls through MCP
Path 3: your internal APIs
Path 4: the open web
Path 4 is where agents create accounts, spend money and post content. It is the path this site is about.
"Typical" means what the category usually offers. Individual products vary, so treat this as a map, not a verdict.
| Capability | API gateway | LLM gateway | AI gateway | MCP gateway |
|---|---|---|---|---|
| Auth and keys | Yes | Provider keys | Provider + team keys | Per server |
| Rate limits | Requests | Tokens | Tokens + budgets | Per tool, varies |
| Model routing and fallback | No | Core job | Yes | No |
| Cost tracking | No | Yes | Yes | Some |
| Prompt and output filters | No | Some | Core job | Rare |
| PII masking | No | Some | Usually | Some |
| Approved MCP servers | No | No | Emerging | Core job |
| Tool-level allow or deny | No | No | Emerging | Yes |
| Tool call audit log | No | As text | As text | Structured |
| Knows a URL is a login page | No | No | No | No |
| Blocks checkout and upload pages | No | No | No | No |
| Sees browser page loads | No | No | No | No |
The last three rows are empty for every gateway type. They need URL-level page data, fed into whichever gateway or proxy you run.
Only partly. An API gateway guards inbound calls to your services. An AI gateway guards outbound calls to model providers.
API gateways think in endpoints and users. AI gateways think in tokens, prompts and models.
It covers which tools an agent may call. It does not judge the URL a fetch tool is asked to open.
A browse tool can be approved while the page it opens is a checkout. Both checks are needed.
Prompt filters read text. A harmless instruction such as "renew the subscription" can still end on a payment page.
A URL check before the request is deterministic. It does not depend on how the task was phrased.
Large estates often run an API gateway, an AI gateway and an MCP gateway side by side.
Give all of them the same page-type data, so a login page is a login page everywhere.
Costs and keys get out of hand quickly without one entry point.
Yes: start with an LLM or AI gatewayThese are the features that turn an LLM gateway into an AI gateway.
Yes: choose an AI gatewayThird-party servers bring tools you have not reviewed.
Yes: add an MCP gateway with an approved server listResearch, procurement, sales and support agents almost always do.
Yes: add page-level URL policy at the tool or proxySignups, orders, uploads and posts are actions with real consequences.
Yes: deny the 8 action page types by defaultAgents have created accounts nobody asked for. Security asks which sites agents visited last month and nobody can answer. A browser agent pilot is about to start.
Agents only call internal APIs. No fetch, browse or computer-use tools are enabled. Every agent runs under close human review.
Each gateway can call the same lookup before a URL is opened. The answer is the same wherever the check runs.
| Agent type | How it reaches the web | Best place for the URL check |
|---|---|---|
| Chat assistant with a fetch tool | Tool call, then server-side fetch | AI gateway guardrail or the fetch tool itself |
| Agent using MCP fetch or browse servers | MCP tool call | MCP gateway or inside the MCP server |
| Computer-use or browser agent | Real browser page loads | Egress proxy or enterprise browser |
| Framework agent (LangChain, Agents SDK) | Python or JS tool function | Tool wrapper, with the proxy as backstop |
| Vendor SaaS agent you do not host | The vendor's own infrastructure | Contract terms and the vendor's controls |
Guides: MCP server access control, LangChain URL policy, Playwright guardrails.
Task: "Compare three SaaS vendors for our finance team and summarise their pricing."
Four checks run on four different paths. Only the last one looks at what kind of page the agent is about to open.
The AI gateway checks the prompt for customer data, applies the team budget and routes to the approved model.
AI gateway: allowedThe MCP gateway confirms the CRM server is approved and that the read-only tool is allowed.
MCP gateway: allowedThe page-type lookup returns pricing, a read page. The request goes ahead.
Page check: allowedThe agent tries to follow it. The lookup returns signup, an action page. The request is denied and logged.
Page check: denied (signup)Without step 4, the agent would now hold a trial account in your company's name. No gateway in steps 1 and 2 could have seen it coming.
Ask how the approved list is kept, and who can add a server.
Allowing a server should not mean allowing every tool on it.
A fetch tool's URL argument is where page policy applies.
You will want URL data from a source you did not build.
Servers should not see more secrets than their tools need.
Agent, server, tool, arguments and decision, in one record.
| Check | Where it runs | If the check is unavailable |
|---|---|---|
| Prompt filter | AI gateway, before the model | Teams often fail open for chat, closed for agents |
| Server and tool allowlist | MCP gateway | Fail closed: unknown server means no call |
| Page-type lookup (API) | Tool, gateway or proxy | Fail closed: deny the URL and log it |
| Page-type lookup (local database) | Inside your network | No outside dependency, so no outage path |
Examples of how vendors label themselves. Labels change often, so check the current product page.
Kong Gateway, Google Apigee, Azure API Management, AWS API Gateway.
LiteLLM, Helicone, KrakenD and other model routers described with this term.
Cloudflare AI Gateway, Kong AI Gateway, Portkey, Databricks Mosaic AI Gateway, Vercel AI Gateway.
Docker MCP Gateway, IBM ContextForge, Amazon Bedrock AgentCore Gateway, agentgateway (Linux Foundation).
For the full AI gateway list, see AI gateway vendors.
One AI gateway for model calls.
URL check inside the fetch tool, calling the lookup API.
Deny the 8 action types, allow read pages.
AI gateway plus an MCP gateway with approved servers.
One shared fetch server with the URL check built in.
Egress proxy as a backstop for browser agents.
API, AI and MCP gateways, each owned by a different team.
Page-type database licensed on-premise, queried locally.
Default-deny for unclassified hosts, every decision logged.
A model's request to run a named function with arguments, such as browse(url).
A program that exposes tools to agents through the Model Context Protocol.
A proxy that all outbound web traffic must pass through before it leaves your network.
A check that can change or block a request, not only log it.
The job a URL does on its site, such as login, pricing or checkout.
A page type where the agent does something: signup, cart, checkout, upload, post, comment, subscribe, password reset.
When a check cannot answer, the request is denied rather than allowed.
Anything not classified or approved is blocked until someone allows it.
More terms in the agent guardrails glossary.
The honest fine print — the same two assumptions we publish, plus two operational ones
One lookup before each URL, the same answer everywhere.
