The agentic layer
MCP, A2A and model calls: what each protocol of the agentic layer changes to the contract, and what the gateway can actually do with it.
Agents form the third family of traffic on a platform, alongside APIs and events. The page gateway explains why the three need to be governed together. This page looks downstream: an agent calls a tool, another agent, or a model, and the three do not pose the same problem.
Agent
The consumer
What it calls
A tool
mcp
Another agent
a2a
A model
llm
| Protocol | Contract | Typical use case | What the gateway can do with it |
|---|---|---|---|
| MCP | Tool catalogue: name, description, input schema | Exposing an existing API catalogue to agents | A lot: filter the catalogue by identity, authorise per call, route on header |
| A2A | Signed Agent Card, task lifecycle | Delegating a task to a third party agent | Little, and with little track record: identify the agent, log the chain |
| Model call | Provider's OpenAPI, SSE for streaming | Generation, classification, extraction | Count in tokens, cap, route by model, cache |
What is worth knowing, protocol by protocol
MCP was rewritten for the intermediary. Since its revision on 28 July 2026, the protocol no longer has a session. Each request describes itself and carries its own credentials. A gateway therefore decides on what it sees, call by call, instead of trusting a state it does not hold.
A server can even ask that certain tool parameters be copied into HTTP headers. Routing and policies then happen without opening the request body. Nothing sensitive belongs in these headers, which are visible to every intermediary.
Discovery does not carry the right to invoke. The catalogue is read at the start of a task, and invocation arrives dozens of calls later. These are two decisions, on two different sets of data. The list is filtered by the identity requesting it. The call is authorised on the data requested, not on the tool. The detail is in access.
Two identities travel, not one. An agent acts on behalf of someone without being that someone. Forwarding the user's token gives the agent all of its scopes. Keeping only the agent's identity loses the user for audit purposes. The correct mechanism is token exchange, described in access.
A2A should not be judged on its announcements. The protocol moved under Linux Foundation governance, in version 1.0, with signed Agent Cards and more than one hundred and fifty organisations declared. Deployment figures, though, are not published, whereas MCP counts its servers in the thousands. This is to be assessed, not assumed.
What A2A really changes is the perimeter. The call path leaves your infrastructure, and a third party agent executes a task you no longer observe. Two requirements follow from this. Audit must carry the entire chain, not just the last hop. And an irreversible operation cannot depend on a sequence decided elsewhere.
The model call changes the unit of account. Two calls of the same method and the same path can differ by a factor of a thousand in cost. A quota per call no longer says anything. The useful limit is counted in tokens, and applies to the task as much as to the call, because an agent loop respects every per call quota.
What token counting actually requires
The token count of a response is only known at the end, and model responses arrive as a stream. A consistent counter therefore requires state shared across every instance of the gateway. This is a question to ask the vendor, not a box to tick on a comparison grid.
Attribution matters as much as counting. A budget without an owner cannot be defended in committee. What must come out: which team, which agent, which model, what cost, on what date. The rest of the mechanics is in observability.
Two operational decisions are made in advance, never during the incident. What the gateway does when the budget service is unavailable, let through or refuse. And what it does with a model it does not know and whose price it cannot determine.
The AI gateway reads the body
This is the only substantive difference from an API gateway, and it explains everything else. An API gateway routes without reading the body. An AI gateway reads the prompt and the response. This is what makes token counting, semantic caching and content filtering possible.
This is also what it costs. A gateway's own time budget is measured in a few milliseconds, and inspecting a large body does not fit within it. A semantic cache also adds a fingerprint computation before responding. The question to settle is therefore architectural, not a matter of configuration: does this traffic go through the same policy chain as your APIs, or through a dedicated path?
The honest answer depends on volumes, and it is measured. What is not up for debate is the control plane: one catalogue, one consumer identity, shared policies. Three separate products bring back three catalogues and three identity systems.
The common trap
The trust boundary does not shift by one step, it changes sides entirely. An agent reads what the API returns and treats it as context. A tool's description is verified once, at connection time. The response, on the other hand, never is.
A third party who writes into a free text field of your data therefore places text into an agent's reasoning, without ever having touched your platform. The caller's access control alone does not see this attack go by.
Three measures belong at the gateway. Flag fields that contain untrusted text, so an agent can treat them as data. Cap the size and number of returned elements, because exfiltration goes through large responses. And require human confirmation ahead of any irreversible operation, because inside the gateway it is not optional.
The protocol's annotations, which flag a tool as read only or destructive, do not replace this confirmation. These are hints intended for the client, and the specification itself asks that they be treated as untrusted. A security boundary sits where traffic passes, not where it was announced.
Updated August 2026.