A2A protocol
also called Agent2Agent · Agent-to-Agent protocol · A2A · agent card
A2A was announced by Google in April 2025 with a large group of partner vendors and contributed to the Linux Foundation two months later, which is why it is now maintained as a neutral project rather than one company’s interface. Its founding assumption is the one that separates it from every tool protocol: the agent on the other end is opaque. It has its own model, its own tools, its own memory and its own judgement about how to do the work, and the protocol is deliberately built so that none of that has to be revealed to the caller. That opacity is the feature — it is what allows two organisations to connect agents without either one publishing its architecture — and it is also the source of every governance problem in the rest of this entry.
The objects are small and worth knowing by name. An Agent Card is a JSON document served at a well-known path — /.well-known/agent-card.json, after earlier drafts used /.well-known/agent.json — carrying the agent’s name, description, service endpoint, version, provider, declared capabilities such as streaming and push notifications, its skills, its default input and output modes, and its security schemes. A Message carries Parts, which are text, files or structured JSON data. A Task carries an id, a context id grouping related work, and a lifecycle that runs through submitted, working, input-required, auth-required, and then one of completed, canceled, failed or rejected. Artifacts are the outputs a task produces. The method set is correspondingly small: send a message, stream a message, get a task, cancel a task, configure push notifications, resubscribe to a stream. The 1.0 HTTP+JSON binding uses REST-shaped names such as message:send and an explicit a2a-version request header.
Three things make A2A traffic harder to govern than a tool call, and all three follow from opacity. An Agent Card is a self-description: it is a claim the remote agent makes about itself, fetched from a path the remote agent controls, and nothing in the document proves the agent behaves as advertised or that the card is the same one you onboarded against. Delegation accumulates rather than narrows unless something makes it narrow: agent A asks agent B, which asks agent C, and if each hop evaluates the request under its own authority then a low-privileged agent escalates simply by asking a higher-privileged one to do the work. And a task is long-lived, so the authority checked when the message was sent may be exercised minutes or hours later, against a state of the world nobody re-examined.
What a deployment therefore has to add sits outside the specification. Bind the credential to the exact task rather than issuing a standing key, and make it one-use, so a captured capability is not a subscription. Check the Agent Card’s canonical digest against the binding recorded in your own inventory, so a card rewritten after onboarding fails rather than silently changing what you believe you are calling. Carry the ordered upstream identities on the request and make the effective grant the intersection of every agent in the chain, so a chain can only ever narrow authority — at which point a forged chain buys an attacker strictly less than sending none. And decide explicitly what happens to the parts you cannot inspect: a Part that names a URL or a file is asking your side to fetch content of the sender’s choosing and put it in front of a model, so refusing dereference outright is a defensible position and silently weakening the check is not.
A2A and MCP are complementary rather than competing, and both specifications say so. The distinction to hold in an architecture review is that MCP is how an agent acquires a capability and A2A is how it acquires a colleague. The governance consequences differ accordingly: with a tool you can inspect the arguments and know exactly what will happen, whereas with a peer agent you can inspect the request and the reply and nothing in between, so the record you are able to produce stops at your own boundary. Any claim about what happened on the far side is a claim about the other organisation’s controls, not about yours.
A delegation chain that widens
A procurement agent may read supplier records and may not approve payments. It hands a task to a finance agent that may approve payments up to £50,000. If the finance agent evaluates the incoming task under its own authority — which is the default behaviour of every implementation that does not do something specific about it — the procurement agent has just acquired payment approval by asking politely, and nothing in either agent’s configuration looks wrong afterwards. The fix is intersection at every hop: the request carries the ordered identities of every agent upstream of it, and the effective permission set is the intersection of all of them, so the chain can only narrow. The security property that follows is worth stating because it is unusual: once intersection is in place, forging the chain header is pointless, because every identity an attacker adds can only take authority away.
What a2a protocol is routinely confused with
- MCP
- MCP exposes capabilities for a model to call; A2A exposes an agent for another agent to delegate to. An MCP server does what it is told and its arguments are fully inspectable before it runs. An A2A agent is handed an objective, chooses its own method, and returns a result you can inspect without ever seeing how it was reached.
- A multi-agent framework (LangGraph, CrewAI, AutoGen)
- Those orchestrate agents inside one process or one codebase, sharing memory, a language runtime and a deployment. A2A is a wire protocol for agents that share none of those — different owners, different vendors, different networks — which is exactly why it needs an Agent Card, a task lifecycle and a security scheme, and why an in-process framework needs none of them.
- An Agent Card and a service registry entry
- An Agent Card is published by the agent about itself at a path it controls. A registry entry is written by your organisation about that agent and held where the agent cannot edit it. Treating the card as the inventory means the thing being governed maintains its own governance record, which is the failure the two-record split exists to prevent.
Related terms
Model Context Protocol (MCP)
The Model Context Protocol (MCP) is an open specification that lets an AI application connect to external tools, data and prompt templates through a uniform JSON-RPC 2.0 interface, so a capability written once can be called by any client that speaks the protocol. It defines how a client discovers what a server offers, how it invokes it, and how the two negotiate a dated protocol revision — and it deliberately says nothing about which caller is allowed to invoke which capability, which is left to the deployment.
OTLP
OTLP, the OpenTelemetry Protocol, is the vendor-neutral wire format OpenTelemetry uses to carry traces, metrics and logs from an instrumented process to a collector or a backend. Its payloads are Protocol Buffers messages sent over gRPC or HTTP — as binary protobuf or its canonical JSON mapping — and it is a one-way export: the receiver acknowledges what it accepted and names what it rejected, and never sends telemetry back.
OWASP Top 10 for LLM Applications
The OWASP Top 10 for Large Language Model Applications is a community-maintained list of the ten most significant security risks in applications built on large language models, published by the OWASP GenAI Security Project. It is an awareness and prioritisation document rather than a standard: nothing certifies against it, and its ranking comes from consensus among contributing practitioners rather than from measured incident data.
Where Token Observe does this
The definition above is the field's, not the product's. This is the part of the product that implements it, for a reader who wants to see one.
Agent permissions
Deny by default, explicit deny wins, and delegation intersects — so an agent cannot borrow authority it was never granted.
Off by default; only enforce refuses anything
Agent registry
One record per agent, and it is the record the gateway enforces against.
An overdue review never suspends the agent itself
The terms next to this one
The substrate everything here conforms to, and the four regulatory instruments that decide what evidence an operator has to be able to produce.
Definitions are the easy part.
The glossary is written to be useful whether or not you ever buy anything. If you have got to the point of deciding how to implement one of these in your own estate, say what your agents do and you will get a straight answer about what it would actually take.
no form · no qualification step · no sales desk · the other three ways in