Agent Gateway vs MCP Gateway: A2A vs Tool Access

Teams buying "a gateway for agents" often discover too late that an agent gateway and an MCP gateway sit on different traffic planes, enforce identity at different points and produce different audit evidence, so one cannot quietly stand in for the other. An agent gateway brokers traffic between agents (Agent2Agent, or A2A, and similar protocols) and often between agents and models; an MCP gateway brokers traffic between agents and the tools and data they call through the Model Context Protocol. This guide compares the two by plane: where each enforces identity and policy, how each integrates with your identity provider and token exchange, what each logs, how each fails, and how to decide what you need first. It is for security architects, identity teams and platform owners. Protocol details reflect MCP specification revision 2026-07-28 and A2A specification 1.0, both checked on 14 November 2026.

Key takeaways

Short answer: an MCP gateway controls what an agent can do to systems (tools, data, actions); an agent gateway controls which agents may talk to which other agents and models, and carries delegation across those hops. Estates with one agent and many tools need the MCP gateway first; estates with many cooperating agents across teams or vendors need both.
The planes have different trust models. MCP binds every token to one server through the RFC 8707 resource parameter and forbids passthrough; A2A leaves authorisation to each agent and keeps identity out of the message payload, so the gateway is where you make it consistent.
Token exchange is the common thread. Both gateways should authenticate the caller, then mint a fresh, audience-bound token for the next hop with RFC 8693, carrying the user as subject and the agent as actor, never forwarding the inbound token.
Converged products do not remove the distinction. Some products broker A2A, LLM and MCP traffic in one runtime. Configure and test each plane's policy separately, because a rule written for agent routing does not constrain a tool call.
Audit needs one trace across planes. Without shared trace context, you can see that an agent called a tool but not which upstream agent and user asked it to.

The three traffic planes

An agentic system generates three kinds of traffic, and the gateway question is really which of them you want in a policy enforcement path.

Agent to model (LLM plane): prompts and completions sent to a model provider. Controlled by an AI or LLM gateway: model allowlists, prompt and response inspection, token budgets, provider key custody. See the AI Gateway and LLM Gateway Guide.
Agent to agent (A2A plane): one agent delegating a task to another, possibly owned by another team or organisation. A2A runs over HTTPS with JSON-RPC, gRPC or HTTP+JSON bindings, discovers peers through Agent Cards and tracks work as tasks with states such as working, input required and auth required.
Agent to tool (MCP plane): an agent, through an MCP client, listing and calling tools, reading resources and fetching prompts from MCP servers. Remote servers use Streamable HTTP with OAuth; local servers usually use stdio.

An MCP gateway sits on the third plane only. An agent gateway sits on the second plane and, in many products, also fronts the first and third. The term is used loosely in the market, so the safest approach is to ask any product which planes it parses at protocol level (understanding A2A tasks or MCP tool calls) and which it only proxies as opaque HTTP.

Side-by-side comparison

Dimension	Agent gateway (A2A plane)	MCP gateway (tool plane)
What it brokers	Task delegation between agents: send message, get and list tasks, subscribe, push notification configuration	Tool listing and calls, resource reads, prompt retrieval between MCP clients and servers
Unit of policy	Calling agent, target agent, skill, task and tenant	User, agent, server, tool name and argument patterns
What the protocol mandates	HTTPS in production; server must authenticate every request; authorisation is implementation specific	MCP server is an OAuth 2.1 resource server; audience validation and no token passthrough are MUST requirements
Discovery artefact it governs	Agent Cards (skills, `securitySchemes`, optional JWS signatures, extended card behind authentication)	Server catalogue, tool descriptions and schemas, Protected Resource Metadata (RFC 9728)
Main threat it reduces	Rogue or impersonated agents, unbounded delegation chains, cross-tenant task leakage	Excessive tool permissions, poisoned tool metadata, scattered downstream credentials
Typical IdP integration	Workload identity for each agent plus token exchange per hop, with user context carried as subject	OAuth authorisation server for client tokens; vault or token exchange for per-server downstream credentials
Audit record	Task ID, context ID, calling and called agent, skill, state transitions, delegation chain	Tool name, arguments, result size, server, user and agent, scope decisions
Blast radius if compromised	Can route tasks to impostor agents and read inter-agent payloads	Holds or can mint credentials for every brokered tool and system
Out of reach	Tool calls an agent makes directly; local tools	Agent-to-agent delegation; stdio servers on endpoints

Where identity and policy are enforced

On the MCP plane

The MCP authorisation specification puts identity checks at the server. The client must send the resource parameter naming the server's canonical URI in both authorisation and token requests, the server must validate that the token was issued for it, and the specification states that MCP servers must not accept or transit any other tokens. A gateway therefore plays both roles: towards clients it is the resource server that validates gateway-audience tokens and issues 403 insufficient_scope challenges for step-up; towards each downstream server it is an OAuth client obtaining its own token for that server. Policy at this point is fine-grained: allow tickets.read for every engineer's coding agent, require step-up for tickets.close, deny any tool whose description changed since approval. The deeper governance mechanics are in the MCP Gateway and MCP Server Governance Guide.

On the A2A plane

A2A deliberately keeps identity out of the protocol semantics. The specification says identity information is handled at the protocol layer, the Agent Card's securitySchemes field declares what the server accepts (API key, HTTP authentication, OAuth 2.0, OpenID Connect or mutual TLS), the client obtains credentials out of band, and the server must authenticate every request. Authorisation is left to each agent, which may consider requested skills, actions within tasks, data policies and OAuth scopes. That flexibility is why an agent gateway is useful: without one, every agent team writes its own authorisation logic and the organisation has no single place to say "the procurement agent may delegate to the supplier-risk agent's assess_supplier skill and nothing else". See the A2A Protocol Security Guide for the protocol threats in depth.

Policy decision versus enforcement

In zero trust terms both gateways are policy enforcement points. Keep the policy decision in one engine (a policy service or the IdP's authorisation layer) so that the same rule, for example "agents acting for contractors may not touch payroll", is evaluated identically whether the request arrives as an A2A task or an MCP tool call. Two gateways with two rule languages and two owners is the most common cause of inconsistent decisions.

IdP integration and token exchange

The identity design is where the two gateways meet. A typical chain is: user signs in to an orchestrator agent; the orchestrator delegates to a specialist agent over A2A; the specialist calls a CRM tool over MCP. Three hops, three audiences.

Give every agent its own identity. Register each agent as a workload or client in the IdP, with credentials that are not shared across agents. See the Agent Identity and Access Guide.
Exchange at every gateway hop. RFC 8693 defines the grant type urn:ietf:params:oauth:grant-type:token-exchange with a subject_token (the party on whose behalf the request is made), an optional actor_token (the party that will use the new token) and audience or resource naming the target. The agent gateway exchanges the user's token plus the orchestrator's credential for a token whose audience is the specialist agent; the MCP gateway does the same for the CRM server.
Use delegation, not impersonation. RFC 8693 distinguishes impersonation, where the actor becomes indistinguishable from the subject, from delegation, where the issued token names both. Delegated tokens carry an act claim, and nested act claims record the chain of prior actors. The RFC says only the top-level claims and the current actor should drive access decisions, so treat the nested chain as audit evidence, not as permission.
Constrain who may act. The may_act claim in a subject token declares which party may become the actor; the authorisation server can check it before issuing. Use it, or an equivalent IdP policy, to stop an arbitrary agent exchanging a user token it happened to receive.
Bind and shorten. Request narrow scopes, short lifetimes and, where the IdP supports it, sender-constrained tokens. The A2A specification recommends that credentials passed in band be bound to the originating agent and readable only by it.

The contrast with passthrough is covered in OAuth Token Exchange vs Token Passthrough, and the mechanics in the OAuth Token Exchange and Delegation Guide.

The auth-required state: A2A lets an agent pause a task in TASK_STATE_AUTH_REQUIRED and hand the authorisation request back to its client, and that client may push it further up a chain. The specification says agents must not treat the state transition by itself as authorisation. An agent gateway should log every auth-required transition, cap the depth of such chains, and route the eventual consent to the user through the IdP, not through message text that a model could forge.

Threat model: agent gateway

Agent impersonation: an attacker publishes an Agent Card that claims to be a trusted agent. Controls: verify card JWS signatures (A2A canonicalises with RFC 8785 before signing), pin approved agent endpoints, require mutual TLS or workload identity on the A2A hop.
Delegation sprawl: a task fans out through agents nobody approved. Controls: an allowlist of agent-to-agent and agent-to-skill edges, maximum delegation depth, and token exchange that refuses unknown actors.
Cross-tenant task leakage: the specification requires List Tasks and Get Task to return only what the authenticated client may see, with checks before any query that could reveal existence. The gateway can add tenant tagging and verify it on responses.
Push notification abuse: A2A agents call client webhooks. The specification asks agents to validate webhook URLs against private ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and link-local addresses, and asks receivers to validate authenticity. A gateway is a natural place to enforce an egress allowlist for webhooks.
Prompt injection carried between agents: artefacts returned by one agent become input to another, which maps to OWASP LLM01:2025 Prompt Injection. The gateway cannot judge intent, but it can label provenance so downstream agents treat peer output as untrusted.

Threat model: MCP gateway

Excessive agency: broad tool permissions let a manipulated agent take damaging actions (OWASP LLM06:2025 Excessive Agency). Controls: per-tool allowlists, argument constraints, step-up on destructive tools.
Confused deputy: the MCP security best practices describe proxy servers using a static client ID towards a third-party authorisation server. Where the gateway proxies OAuth this way, it must implement per-client consent, exact redirect URI matching and single-use state values.
Tool metadata poisoning and silent changes: the gateway should pin approved tool descriptions and hold changes for review. See MCP Tool Poisoning Detection.
SSRF during discovery: server-supplied metadata URLs can point at 169.254.169.254 or internal hosts. The specification recommends HTTPS enforcement, blocking private and link-local ranges and egress proxies.
Credential concentration: stolen gateway-held tokens map to ATT&CK T1528 Steal Application Access Token and their reuse to T1550.001 Application Access Token. Treat the gateway's vault as tier 0.

Logging and audit across planes

Each plane's protocol suggests what to record, and OpenTelemetry has semantic conventions for both, currently at Development status, so attribute names may change.

Evidence field	Agent gateway	MCP gateway
Caller identity	Authenticated agent identity plus user subject from the exchanged token	User, agent and MCP client identity from the validated token
Operation	A2A method (send message, get task, cancel, subscribe) and requested skill	`mcp.method.name` such as `tools/call`, and `gen_ai.tool.name`
Correlation	Task ID, context ID, W3C Trace Context headers	`jsonrpc.request.id`, trace context propagated in `params._meta`
Agent metadata	`gen_ai.agent.id`, `gen_ai.agent.name`, `gen_ai.agent.version` on `invoke_agent` spans	Server identity and `mcp.protocol.version`
Authorisation events	Auth-required transitions, denied delegation edges	401 and 403 responses, `insufficient_scope` challenges, step-up grants
Payload handling	Artefact type and size; full content only where policy permits	Argument and result capture under data classification rules

The A2A enterprise guidance recommends propagating W3C Trace Context and logging task IDs and correlation IDs. The OpenTelemetry MCP convention propagates context inside params._meta because HTTP trace context does not cover individual messages in a stream. Configure both gateways to forward the same trace ID so a single investigation query returns user, orchestrator, specialist agent and tool call in order. Retain these records with the same protection as other identity logs, because tool arguments often contain personal data.

Failure modes

Treating an agent gateway as tool control. The agent gateway sees that the specialist agent was invoked, not that it then deleted 400 CRM records through an MCP server it reaches directly.
Forwarding the user's token across hops. One stolen token then works at every agent and tool, logs show the wrong caller, and MCP servers built to the specification reject it anyway.
Shared agent credentials. Five agents behind one client ID make delegation edges and actor claims meaningless.
Divergent policy. The agent gateway team blocks contractor access to finance agents while the MCP gateway still exposes the finance tools to any agent.
No depth limit on delegation. Chains of auth-required tasks let a request travel far from the user who started it, and consent prompts lose context.
Unparsed traffic. A gateway that proxies A2A or MCP as opaque HTTP can apply only host-level rules, which gives a false sense of control.

Decision criteria

Situation	Start with	Why
One or a few agents, many internal and SaaS tools	MCP gateway	Risk is in actions on systems and in scattered downstream credentials
Many agents from different teams that delegate to each other	Agent gateway, then MCP gateway	Risk is in unapproved delegation and inconsistent per-agent authorisation
Agents exposed to partners or customers over A2A	Agent gateway	External callers need authentication, tenant isolation and rate limits at the boundary
Regulated workload needing end-to-end attribution	Both, with shared tracing and one policy engine	Auditors will ask who asked for each action, across every hop
Small organisation on one vendor's agent platform	Platform's built-in controls plus an MCP gateway for third-party tools	A separate agent gateway adds operational cost before there is cross-team delegation to govern

Converged versus separate: one product covering all planes simplifies trace correlation and policy, but concentrates blast radius and creates one outage domain. Separate products allow different owners and isolation, at the cost of stitching identity and logs together. Either way, test each plane's policy with its own negative test cases. Evaluation questions for the tool plane are in the MCP Gateway Buyers Guide.

Worked scenario: an insurance claims assistant

An insurer runs a claims orchestrator agent used by 600 handlers. It delegates over A2A to a fraud-scoring agent built by another team and to a supplier's repair-estimate agent, and the agents call MCP servers for the policy system, document store and payments.

Agent gateway: admits only signed Agent Cards for the two approved agents, allows the orchestrator to call score_claim and estimate_repair only, caps delegation depth at two, rejects the supplier agent's push notification URLs unless they match its registered domain, and exchanges the handler's token for an agent-audience token with the orchestrator as actor.
MCP gateway: lets the fraud agent read claims and documents but never call payments.release; requires handler step-up for any payment tool; pins tool descriptions; holds per-server credentials in a vault.
What went wrong in testing: the supplier agent returned an estimate containing instructions to "also release the payment". The agent gateway passed it as a valid artefact. The MCP gateway blocked the payment call because the fraud agent's actor identity had no payment entitlement, and the shared trace showed the full path from handler to blocked call in one view. Neither gateway alone would have produced both the block and the explanation.

Implementation path

Inventory planes and edges. List agents, which agents call which, which MCP servers each uses, and which models. Mark external parties.
Fix identity first. One IdP registration per agent, token exchange enabled, delegation (not impersonation) policies, short token lifetimes.
Deploy in observe mode. Route traffic through the gateway with logging and no blocking for two to four weeks; build the allowlist of edges and tools from observed, approved use.
Enforce on a pilot. Turn on deny-by-default for one agent group, with an exception path owned by the platform team.
Close bypasses. Egress rules so agents reach other agents and MCP servers only via the gateways; managed client policy for MCP configuration on endpoints.
Roll back safely. Keep a tested switch to return a plane to observe mode without changing tokens, and document which agents fail closed when a gateway is down.

Detection and measurement

Coverage: share of A2A and MCP requests (by volume) that pass through a gateway; target above 95% for remote traffic.
Exchange hygiene: share of downstream tokens issued by exchange with an actor recorded; any passthrough detected should be zero.
Edge drift: number of new agent-to-agent or agent-to-tool edges attempted per week that are not on the allowlist.
Step-up rate: privileged tool calls preceded by a step-up grant versus those denied.
Trace completeness: share of tool calls that can be joined to an originating user and agent chain.
Alerts: unsigned or changed Agent Cards, delegation depth above limit, webhook targets in private ranges, tokens presented with an unexpected audience.

Framework mapping

Framework	Reference	How it applies
NIST SP 800-53 Rev 5	AC-4 Information Flow Enforcement	Allowlisted agent-to-agent and agent-to-tool flows at each gateway
NIST SP 800-53 Rev 5	AC-6 Least Privilege	Per-skill and per-tool scopes, step-up for destructive actions
NIST SP 800-53 Rev 5	IA-9 Service Identification and Authentication	Distinct identity per agent and per MCP server, mutual authentication on hops
NIST SP 800-53 Rev 5	AU-2 Event Logging, AU-12 Audit Record Generation	Task, tool and authorisation events with shared trace context
NIST SP 800-53 Rev 5	SC-7 Boundary Protection	Egress control that forces traffic through the gateways
NIST CSF 2.0	PR.AA-01, PR.AA-05, PR.PS-04	Managed agent identities, enforced permissions, logs for continuous monitoring
MITRE ATT&CK	T1528, T1550.001	Theft and reuse of tokens held or minted by gateways
OWASP Top 10 for LLM Applications 2025	LLM01 Prompt Injection, LLM06 Excessive Agency	Untrusted peer output and over-broad tool access

Practitioner checklist

Confirm for each candidate product which planes it parses at protocol level and which it only proxies.
Register every agent with its own IdP identity; no shared client IDs.
Enable RFC 8693 token exchange at each gateway hop with delegation semantics and may_act or equivalent constraints.
Block token passthrough and verify audience on every inbound token.
Maintain one policy engine for both planes and an allowlist of agent edges, skills and tools.
Require signed Agent Cards and pinned tool descriptions for anything approved.
Cap delegation depth and log every auth-required transition.
Propagate one trace ID across A2A and MCP hops and test that an investigation query returns the full chain.
Close direct paths with egress rules and endpoint client policy.

Agent Gateway vs MCP Gateway: Which Traffic Plane Each One Secures