Agent Gateway vs API Gateway: Keep, Extend, or Add?

Agent gateway vs API gateway is the question that follows a first MCP server into production: can the gateway you already run govern agent traffic too? This post follows one delegated call, a support agent acting for a named finance analyst and calling get_invoice then issue_refund on one MCP endpoint, through an ordinary API gateway, and at four hops (route, caller, catalog, clock) asks what that gateway can still see and hold.

Where an API gateway and an agent gateway genuinely overlap

Start with what the two share. The wire is the same wire, so TLS and mTLS carry over; an agent runtime obtains tokens like any other OAuth client, so caller authentication carries over; and a request counter still counts, even if the count no longer tracks cost. Kong runs its AI Gateway on Kong Gateway through plugins and, at the time of writing, documents an AI MCP Proxy plugin, an AI MCP OAuth2 plugin and MCP audit logs that capture session IDs and JSON-RPC methods. The data plane stayed; a plugin now parses what it used to forward untouched.

Lowercase agentgateway, one word, is not the category but an open-source project Solo.io contributed to the Linux Foundation in 2025: a data plane built for agent traffic, MCP and A2A included, on the announcement’s argument that most existing gateways predate AI agents and struggle with agent protocols without major rearchitecture. The category answers to several names, agentic gateway, agents gateway or AI agent gateway among them; the project is one entrant. And at the time of writing Solo’s feature overview lists OAuth scope restriction and policy-driven tool exposure under its Enterprise tier, so open-source and commercial builds differ on exactly the per-tool controls at issue here.

The boundary is not vendor quality but which unit the gateway can see (a request, or a tool name in a body), how many principals it carries (one, or user plus agent), and how long it holds state.

Follow one delegated agent call through your API gateway

Call the analyst Priya; the refund is for a duplicated charge on a billing MCP server behind your API gateway.

Hop 1: the route is one POST, whatever the tool

MCP carries every tool call as a JSON-RPC body to a single endpoint, so the lookup and the refund reach the gateway identically: POST /mcp, method tools/call, and a name that differs only inside the body. A policy that separates GET /invoices/INV-20417 from POST /refunds finds nothing in the request line to bind to; the Model Context Protocol JSON-RPC envelope keeps the decisive fact below the layer a route table reads.

One correction: the 2026-07-28 Streamable HTTP transport mirrors the JSON-RPC method into an Mcp-Method header and the tool name, on tools/call, into Mcp-Name, so a gateway can route issue_refund and get_invoice differently without opening the body, and a body-reading server must reject a request whose headers disagree with it. That settles routing and nothing else; the arguments, the result, Priya’s identity and the task that outlives the response stay out of reach.

Hop 2: the caller is two principals, but the consumer object holds one

Two parties are calling: the agent, with its own runtime identity, and Priya, whose authority it exercises. Microsoft’s Entra documentation for agent identities, at the time of writing, draws the same line between autonomous access (rights granted to the agent) and delegated access (the agent acts with a person’s rights). An API gateway maps JWT claims onto a consumer, but a consumer is one object bound to one identity; whichever it holds, the other has nowhere to live, and the billing system authorizes issue_refund on whichever principal survived.

Hop 3: the tool catalog is model input, so filtering it is enforcement

Before either call, the agent asked for tools/list, and nothing in an API gateway resembles that response. A route table is written by an operator for the proxy; a tool list is written by the server for the model, which treats it as the complete set of actions open to it. Whoever decides what appears in that list is exercising authorization, and Invariant Labs showed in April 2025 why the default matters: instructions planted in tool descriptions that a user never sees and a model follows. Agent gateways treat the list as policy; AgentCore Gateway aggregates MCP targets into one virtual MCP server with a single tools/list and semantic tool search.

Hop 4: the task outlives the response

Now the agent proposes the refund, and policy says no irreversible action runs without a named approver, so something must hold the call for a person and then resume it. Agent protocols model that pause: the A2A specification returns a Task while work continues, with interrupted states TASK_STATE_INPUT_REQUIRED and TASK_STATE_AUTH_REQUIRED, and MCP elicitation (2026-07-28 revision) lets a server pause a tool for client input with an accept, decline or cancel answer, behind a user-approval control that clients SHOULD implement. An API gateway’s state ends with the response; it has no representation for a suspended transaction and cannot hold issue_refund open for Priya’s manager.

Delegated identity: the shortcut the MCP spec forbids

The obvious fix for hop 2 is to forward Priya’s token downstream. The MCP specification closes that door: under the 2026-07-28 authorization security considerations, an MCP server calling an upstream API is itself an OAuth client and must not hand along the token it received from its own client, and the authorization specification requires the RFC 8707 resource parameter so a token is bound to one audience and cannot be replayed elsewhere.

The spec-conformant pattern is an exchange, and the exchange is exactly the operation an API gateway lacks: trading the inbound token for one bound to the next audience and carrying both identities, tied to an agent identity you can revoke. AWS documents a token-exchange grant for AgentCore Gateway in which the gateway swaps the inbound user token for a new, scoped token aimed at the downstream resource and carrying both the user’s and the agent’s identity, so each hop can authorize on both; it also documents a passthrough option that, at the time of writing, its own guidance describes as not recommended for production. RFC 8693 names the two flavors, impersonation and delegation; for audit you want delegation, so the record shows who acted and on whose authority. If your agents act for people, this row settles the question by itself.

Workload identity federation across clouds

If the support agent runs in AWS AgentCore and the billing server is published through Azure AI Foundry, a token minted on the AWS side means nothing to Azure unless both trust a common identity. Secure agentic AI workflows depend on workload identity federation at each boundary, not on service accounts copied between clouds. ASCENDING documents an RFC 8693 exchange at each cloud boundary, with one EntraID authentication up front, on its AgentCore and AI Foundry federation page; the networking side is in why multicloud agentic workflows break.

Agent gateway vs API gateway, row by row: keep, extend, or add

Four hops give three verdicts. Keep: the API gateway already does it. Extend: an MCP-aware plugin on the same gateway does it, at the cost of a second policy vocabulary on the plugin vendor’s cadence. Add: the control needs a layer that understands the protocol and the session; no configuration of a request-scoped proxy produces it.

Extend is real wherever the body is parseable, and API-management vendors now sell exactly that: AI and MCP plugins positioned as enterprise-grade API security and governance platforms. Kong’s AI MCP Proxy, at the time of writing, defines a default_acl plus per-tool acl objects over consumer names, groups or claim values. Its AI Rate Limiting Advanced plugin limits on prompt, completion or total tokens with a cost strategy, scoped by consumer, group, model or provider, by reading usage out of LLM responses; whether anything does the same for A2A responses is a vendor question, and where nothing does, limiting falls back to request counts, the wrong unit: a retry loop resending a growing history raises requests slowly and spend fast.

Screening fits none of the three verdicts. OWASP’s LLM01 entry defines indirect prompt injection as external content that changes model behavior when interpreted, and most of its mitigations are architectural; only filtering by sensitive category is something a gateway can own, and each camp hands that to a managed classifier: Google’s Agent Gateway to Model Armor, Kong to guardrail plugins that call Azure Content Safety, AWS Guardrails or Model Armor. Mark the row vendor-dependent.

Agent traffic controls: keep, extend, or add

Control	Existing API gateway	MCP-aware plugin on that gateway	Protocol- and session-aware agent gateway	Verdict
Transport security and caller authentication	Native	Same	Same	Keep
Request-count rate limiting	Native	Same	Plus per-agent and per-tool quotas	Keep as backstop
Per-tool authorization inside one MCP endpoint	Every tool is the same POST	default_acl plus per-tool acl over consumers, groups or claims	Native	Extend
Token or dollar budgets	Request counts only	Token or cost limits for LLM traffic; A2A depends on the plugin	Per-agent and per-tool budgets; A2A coverage varies by vendor	Extend (verify A2A)
Tool-call audit with arguments and policy snapshot	One POST per log line	Session ID and JSON-RPC method	Tool, arguments, result, agent version, policy snapshot	Add
Delegated identity, user plus agent per hop	One consumer object per connection	Same limit	Scoped two-principal token exchanged per hop	Add
tools/list catalog filtering	Route tables are static	Static allow and deny lists where supported; no per-session filtering	Policy-filtered catalog, aggregation, semantic search	Add
Prompt and tool-description screening	None	Guardrail plugins calling a managed classifier	Same delegation, Model Armor or similar	Vendor-dependent
Long-running tasks and human approval mid-call	State ends at the response	Same	Holds the call open across interrupted task states	Add

Chain the agent gateway in front of the API gateway, not instead of it

The resulting shape is small: one protocol-aware layer that fronts only the MCP and A2A endpoints, while every REST and GraphQL route keeps the gateway and policies it has today. AWS built the same chain into its own service: AgentCore Gateway accepts API Gateway REST APIs as an MCP target type, which only makes sense if the agent layer stands ahead of the API gateway rather than replacing it.

AWS’s published defaults for AgentCore Gateway, all adjustable, size the layer: 100 targets per gateway and 1,000 tools per target, so one gateway can front a 100,000-tool catalog; tools/call and tools/list at 200 requests per second; search-based tool calls at 25 per minute; a 15-minute invocation timeout. Discovery is metered far below invocation, so filter the catalog by policy up front and keep the resolved tool set for the life of the task; and a 15-minute timeout is the vendor’s own statement that this layer holds tasks, not requests. AWS Agent Registry entered preview in April 2026 as a governed catalog with approval workflows and CloudTrail audit (announcement); treat it as preview until you re-check.

The diagram separates what the word gateway blurs. The registry is the catalog beside the call path; the gateway is the data plane inside it. They must share one schema, one set of policy objects and one version reference, or policies point at tools that no longer exist and audit records cite versions nobody can reproduce. The six layers of that design are in enterprise MCP registry architecture; the MCP-specific flavor of the MCP gateway registry pairing is on ASCENDING’s MCP gateway page and in the MCP gateway evaluation guide. Above both sits the agentic orchestration layer, which plans the sequence and the approvals; the gateway rules on each call as it arrives.

When the gateway you already run is enough

Stay put if every tool looks like get_invoice and none like issue_refund:

• There is no Priya: agents hold their own service identity and never borrow a person’s.
• The catalog is yours: first-party servers, a handful of tools, changed only by your releases.
• Nothing is a refund: every tool reads, or writes something you can revert in seconds.
• One turn, one answer: no task waits on a person or another agent.
• Spend is throttled in the application; the gateway’s request counter is a safety net.

Add the layer when one of these becomes true:

• An agent acts for a named person against a system that records who did what.
• An MCP server in the catalog was written outside your organization.
• One tool moves money, deletes data, sends a message or changes infrastructure.
• A task outlives a request or hands off to another agent.
• An auditor may ask which tool ran, with which arguments, under which policy version.

Five questions to ask any agent gateway vendor

1. Is a revocation in the registry refused on the next call, or after a sync?
2. When an agent version is deprecated, when do callers stop reaching it?
3. Does the audit record name the MCP tool and its arguments, or only the agent?
4. Does it carry the policy snapshot in force, or only a policy ID?
5. Does one gateway reach AWS AgentCore, Azure AI Foundry, Cloudflare MCP Server Portals and self-hosted servers, or is it one per provider?

Where Jarvis Registry fits, with the disclosure

Jarvis Registry is ASCENDING’s product and ASCENDING publishes this blog, so read this section as a vendor placing its own product in the table above, not as an independent assessment.

ASCENDING documents Jarvis Registry as a universal MCP and agent gateway whose registry and enforcing gateway are one product rather than two systems kept in sync. Its agent gateway page documents per-invocation policy evaluation, identity federation over OpenID Connect and SAML 2.0 with RBAC scopes from the identity provider, per-hop audit spans tagged with the policy version in force, and federation of AWS AgentCore, Azure AI Foundry and self-hosted agents into one governed catalog. Verify each during evaluation; this is product documentation, not third-party testing.

Of the Add rows, those claims map directly onto per-call audit tagged with the policy version, and onto delegated identity through the cross-cloud exchange on the federation page; catalog filtering, mid-task approval and A2A token budgets should be demonstrated in a proof of concept, not read from a feature page. No benchmark against the vendors above was run.

Bring one delegated workflow, such as the refund above, and run the allowed, denied, revoked and paused-for-approval scenarios against your identity provider before choosing; ASCENDING can set up that proof of concept with you.

References

• Kong. “AI Gateway”.
• Kong. “MCP Traffic Gateway”.
• Kong. “AI MCP Proxy plugin reference”.
• Kong. “AI Rate Limiting Advanced plugin”.
• Linux Foundation. “Linux Foundation Welcomes agentgateway Project”.
• Solo.io. “agentgateway overview”.
• Model Context Protocol. “Streamable HTTP transport (2026-07-28 revision)”.
• Model Context Protocol. “Authorization (2026-07-28 revision)”.
• Model Context Protocol. “Authorization: Security Considerations (2026-07-28 revision)”.
• Model Context Protocol. “Elicitation (2026-07-28 revision)”.
• Microsoft Learn. “What are agent identities?”.
• Invariant Labs. “MCP Security Notification: Tool Poisoning Attacks”.
• AWS. “AgentCore Gateway: Core Concepts”.
• AWS. “AgentCore Gateway: Inbound Authorization”.
• AWS. “AgentCore Gateway: Outbound Authorization”.
• AWS. “Quotas for Amazon Bedrock AgentCore”.
• AWS. “AWS Agent Registry in AgentCore (preview)”.
• Google Cloud. “Agent Gateway overview”.
• IETF. “RFC 8693: OAuth 2.0 Token Exchange”.
• OWASP GenAI Security Project. “LLM01: Prompt Injection”.
• A2A Project. “Agent2Agent (A2A) Protocol Specification”.

FAQ — Agent Gateway vs API Gateway

What is an AI agent gateway?

An AI agent gateway (also called an agentic gateway or agents gateway) is the inline component that every agent tool call or agent-to-agent call passes through. It authenticates the calling runtime, carries the identity of the person it acts for, authorizes the specific tool named inside the JSON-RPC body, filters the tool catalog the model is allowed to see, applies budgets by token or cost, holds long-running tasks open for human approval, and writes a per-call audit record with the resolved tool, arguments and the policy in force. An API gateway authenticates the runtime well; it carries one principal rather than two, and does the remaining jobs only partially or not at all.

Is agentgateway the same thing as an agent gateway?

Not quite. Lowercase agentgateway, one word, is a specific open-source project that Solo.io contributed to the Linux Foundation in 2025, a data plane built for agent protocols such as MCP and A2A. Agent gateway with a space is the product category that project belongs to, alongside AWS AgentCore Gateway, Google Cloud's Agent Gateway, Kong's MCP plugins and Jarvis Registry. If you are looking for the project, go to the Linux Foundation announcement; if you are deciding whether your API gateway already covers the category, this article is the comparison.

Should MCP servers sit behind an existing API gateway at all?

Yes. Fronting an MCP server with the gateway you already run adds TLS, caller authentication and request limits at no design cost, and it is the right first step. The limits appear one layer down: without an MCP-aware plugin the gateway cannot tell get_invoice from issue_refund, and its access log records a POST rather than a tool. Plugins close those two gaps. They do not close per-hop delegated identity, runtime filtering of the tool catalog or a pause for human approval, so test those three against your own gateway instead of assuming a configuration change will cover them.

Why can't an API gateway carry a user's identity through an agent call?

Because its consumer model holds one principal per connection, and an agent acting for a person involves two: the agent and the user whose authority it exercises. The MCP specification forbids the obvious shortcut of forwarding the inbound token upstream, and AWS AgentCore Gateway instead documents a token-exchange grant that mints a new audience-scoped token carrying both identities at each hop. Secure agentic AI workflows that span clouds add workload identity federation on top of that exchange; ASCENDING describes its version, an RFC 8693 exchange at each cloud boundary, on its AgentCore and AI Foundry federation page.

What is the difference between an MCP gateway, an agent gateway and an agent registry?

An MCP gateway is an agent gateway specialized for the Model Context Protocol; if MCP is the only wire your agents use, the two terms describe the same box. An agent gateway also fronts A2A traffic and can federate several MCP gateways behind one policy surface and one audit trail. An agent registry is the catalog plane: it records which agents, tools and MCP servers exist, who owns them and which version is approved, but it sits outside the call path and enforces nothing at runtime. An MCP gateway registry pairing is therefore two components sharing one source of truth, not one product doing both jobs.

Where does the agentic orchestration layer sit relative to the gateway?

Above it. The orchestration layer decides what should run, in what order and with which approvals, then issues the calls. The agent registry tells the orchestrator what exists, and the agent gateway decides at each invocation whether that call may run right now under the current policy and identity. An orchestrator without a gateway underneath is a workflow diagram with no enforcement; the gateway is what makes its approval steps binding.