Agent gateway: the four kinds, and what each one can decide

What an agent gateway is

An agent gateway is a proxy that sits between AI agents and the things they talk to, authenticates each agent and applies policy to its requests. Like an API gateway, it is a choke point. Unlike most API gateways, it understands agent traffic: model calls, Model Context Protocol (MCP) tool calls or messages between agents.

The trouble is that "agent gateway" names at least four kinds of product. As of October 2026, examples include:

• Google Cloud's Agent Gateway, described as "the governance and security enforcement layer for Google Cloud agent governance," covering client-to-agent ingress and agent-to-anywhere egress.
• agentgateway, an open-source proxy, built in Rust, for LLM, MCP and agent-to-agent traffic.
• Okta's Agent Gateway, "an identity-native proxy that sits between AI agents and the enterprise tools that they call."
• Amazon Bedrock AgentCore Gateway, which "converts APIs, Lambda functions, and existing services into Model Context Protocol (MCP)-compatible tools."

Same name, different jobs. Before you compare products, decide which traffic you need to govern and which decisions you need made. This page sorts AI agent gateway products by what they see, what they decide and what they can't decide. For the wider program, start with the AI agent security guide.

The four kinds of agent gateway compared

Most real products span more than one column. agentgateway's FAQ says one proxy can carry regular HTTP and gRPC traffic alongside LLM, MCP and A2A traffic. AWS says AgentCore Gateway also routes inference requests across model providers and fronts A2A traffic. So read the column, not the product name. AI agent security tools maps the wider market.

What each kind of agent gateway sees and decides

Each kind sits at a different point in an agent's traffic, so each has a different view. The sections below follow the order a request usually travels: to the model, to tools, to other agents and to business APIs.

AI gateways: agents to model providers

An AI gateway, also called an LLM gateway, proxies calls from applications and agents to model providers. Cloudflare's AI Gateway shows a typical feature set: caching, spend limits, rate limiting, routing with fallback, content guardrails, data loss prevention (DLP) on prompts and responses, analytics, logging, and provider keys stored in one place.

It sees something useful. When a model asks to call a tool, that request passes through the gateway inside the model's response. But the agent runs the tool somewhere else, with its own credentials. The AI gateway can observe intent and block a response. It can't read the invoice, check the week's refunds or hold the billing key. It governs the agent's brain, not its hands.

MCP gateways: agents to tools

An MCP gateway proxies MCP traffic. It can filter tools/list per agent, read the tool name and arguments in each tools/call, inject upstream credentials and log every call. agentgateway's FAQ describes JWT authentication, a role-based access control (RBAC) system for MCP servers and tools, and per-client tool virtualization that limits which tools each session can see. Okta says its Agent Gateway authenticates agents with Okta tokens, injects downstream credentials so the agent never directly accesses them, and enforces identity and policy on every tool call.

Its blind spots: local servers started over standard input/output (stdio) on a laptop never cross it, and REST calls that skip MCP don't either. Matching a tool name is not the same as checking the record a call touches. MCP security covers tool poisoning and definition pinning.

Agent-to-agent (A2A) gateways

The Agent2Agent (A2A) protocol lets agents from different vendors delegate tasks to each other. As of October 2026, the A2A specification is at version 1.0.0. Each A2A server publishes an Agent Card that declares its skills and the authentication schemes it accepts. Servers "MUST reject requests with invalid or missing authentication credentials" and must scope authorization so clients reach only the tasks they're allowed.

An A2A gateway applies those rules at one point. It authenticates the calling agent, decides which agents may delegate to which, routes requests and logs each task. Google's Agent Gateway, for example, "governs inter-agent delegation and task execution APIs."

What it can't decide is what the receiving agent does next. The specification lists opaque execution as a guiding principle: agents collaborate without sharing internal details. The person a chain started from also has to travel with each hop, or the last agent acts with nobody's authority. See AI agent identity.

Action-level authorization in front of business APIs

The fourth kind decides whether a specific action should happen. It sits in front of the service, reads the operation and arguments, fetches the record the call touches and checks all of it against policy before the call runs. Because it holds the service credential, an agent can't go around it.

AWS offers one example inside a cloud gateway. Policy in AgentCore "intercepts all agent traffic through Amazon Bedrock AgentCore Gateways and evaluates each request against defined policies in the policy engine before allowing tool access." Policies are written in Cedar, and AWS describes fine-grained permissions based on user identity and tool input parameters.

This is the layer built to stop a $4,500 refund made through a tool the agent is allowed to call. Its limits: it doesn't judge what text means, and agents that can reach the service directly bypass it. AI agent authorization covers how to write the rules.

MCP gateway vs AI gateway

The two get confused because many products now do both. The difference is the traffic, not the brand.

• Direction. An AI gateway carries what the agent sends to a model and what comes back. An MCP gateway carries what the agent sends to a tool and what the tool returns.
• Credentials. An AI gateway holds model provider keys. An MCP gateway holds keys to your tools and data, which usually carry more risk.
• Decisions. An AI gateway decides cost, routing and content rules for prompts. An MCP gateway decides which tools an agent sees and which calls go through.
• Data. An AI gateway is where you mask personal data before it reaches a model provider. An MCP gateway is where you inspect tool results before the model reads them.

If your agents only answer questions, an AI gateway may be enough. Once they call tools that change records, you need policy on the tool path too. For actions that move money or data, you need policy that reads the record. AI agent data loss prevention covers the content checks both kinds often add.

How agent gateways fit with your API gateway

Agent gateways add to the API gateway you already run; they don't replace it. A common layout puts each decision where its traffic passes:

agent ──► AI gateway ──────────────────────────────────────────────► model provider
agent ──► MCP or A2A gateway ──► API gateway ──► action-level check ──► service
                                                  (last hop)

Three rules make the layout hold. First, keep the action-level check closest to the service, as the last hop, so every caller passes through it, including agents that never touch your MCP gateway. Second, pass the agent's own identity, and the person it acts for, through each hop unchanged, so the last hop knows who is calling. Third, block direct network paths from agents to services, so no gateway is optional.

With Envoy or Istio, the decision can also run inside the gateway through external authorization, with one gap: it can't mask fields in responses. Keep your API gateway covers the three placements and their configuration, so this page doesn't repeat them.

What to require from any agent gateway

Whichever kind you buy or build, hold it to the same requirements. Each one closes a specific gap.

The MCP specification's security guidance is blunt about the second row: "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server." It lists the risks of token passthrough, including security controls that get bypassed and audit trails that can't tell clients apart (MCP security best practices). The same logic applies to any gateway that forwards a caller's token downstream. For the evidence side, see AI agent audit trails.

Agent gateway checklist

• List the traffic you need to govern: model calls, tool calls, agent-to-agent calls and calls to business APIs.
• Map each candidate gateway to the four kinds by what it sees, not by what it is called.
• Give every agent its own identity, and carry the person it acts for through each hop.
• Reject tokens issued for other services, and never forward a caller's token upstream.
• Keep upstream credentials in the gateway, never in the agent.
• Filter each agent's tool list down to what its job needs.
• Check arguments and the target record for any action that changes data or moves money.
• Put the action-level check at the last hop before the service.
• Block direct network routes from agents to services.
• Configure every gateway to fail closed, and test it.
• Keep a receipt for every decision, allowed or denied.

Where AgentFort fits

AgentFort Access provides action-level authorization. It sits between agents and the services they call, over REST and MCP, and services are registered from their OpenAPI definition or MCP server. The AgentFort gateway trusts SPIFFE certificates, so every agent proves who it is on every request. Every call is checked: the agent's identity, the exact operation, its arguments and the record it touches, which AgentFort reads itself. Anything not granted is denied, and a forbid always wins. AgentFort calls the service with its own credential, scoped to that one operation, and over MCP an agent sees only the tools it may use. If the control plane is unreachable, the gateway keeps the last signed rules for 60 seconds by default, then refuses every call. It works behind or inside the gateway you already run. See AgentFort Access, watch a demo or become a design partner.