Multi-agent authorization and agent-to-agent trust

What changes when there is more than one agent

A single agent acting for a user is a delegation problem with one hop. Add a second agent and three new questions appear at once.

1. Transitivity. A user delegated to agent A. Agent A now wishes to delegate to agent B. Was that within what the user consented to? Most consent screens do not express onward delegation, so the honest answer is usually that nobody knows.
2. Trust basis. Agent B receives a request claiming to act for a user. What makes that claim credible? Without a cryptographic basis it is an assertion in a message body.
3. Accountability across a boundary. If agent B belongs to a different team, tenant or organisation, whose logs establish what happened, and are they reconcilable?

None of these is exotic. They are the same questions distributed systems have always faced, arriving in a context where the requests are generated dynamically and the topology is not fixed at design time.

A2A and what it does not cover

Agent2Agent was announced by Google in April 2025 and contributed to the Linux Foundation in June 2025. It reached v1.0 in 2026, with v1.0.1 in May 2026 adding an extension mechanism. More than 150 organisations support it and it is integrated across the major cloud platforms with production deployments in supply chain, financial services, insurance and IT operations.

Mechanically, agents publish an Agent Card at a well-known path describing skills, transport bindings and security schemes; communication runs over JSON-RPC with alternative bindings; and tasks move through a defined lifecycle including an explicit auth_required state. The complementarity with MCP is clean and worth internalising: MCP is vertical, connecting an agent to its tools; A2A is horizontal, connecting agents to each other. Production systems commonly run both.

What A2A does well is discovery, capability description and task routing. What it does not do is express governance. Its four official extensions cover secure passport, timestamping, traceability and gateway routing; none addresses whether a delegation was authorised, how consent propagates, or what an auditor should be able to reconstruct. That is not a criticism of the protocol, it is deliberately scoped to interoperability, but it means adopting A2A does not give you multi-agent governance, and the gap has to be filled beneath it.

Establishing agent-to-agent trust

The trust basis has to come from the identity layer, not the message layer. Three mechanisms, in increasing order of what they buy you:

• Attested workload identity on both sides. Each agent holds a short-lived credential derived from its runtime rather than a stored secret, so "which agent is calling" is answered cryptographically. SPIFFE delivers this today.
• Trust-domain federation for cross-boundary calls. When agents sit in different clouds, tenants or organisations, federate the trust domains rather than sharing credentials across them. This is the model SPIFFE implements and the IETF WIMSE drafts formalise.
• Propagated authorization context. The receiving agent needs not just the caller's identity but the original principal's authority and its bounds. Transaction Tokens at the IETF OAuth working group address exactly this: carrying authorization context across a call chain rather than re-deriving or implicitly trusting it at each hop.

An agent that authenticates its caller but cannot see the original principal's consent is authenticating the wrong thing. It knows who is asking and not whether the asking is authorised.

Authority propagation, and the one rule that holds

Monotonic scope narrowing: no descendant may hold authority exceeding its parent.

Enforced at issuance rather than checked in review, this single rule bounds an entire agent tree by the original human consent, however deep or wide the fan-out becomes. It also converts an unbounded governance problem into a bounded one, because you no longer have to reason about every path, only about the root grant.

The failure it prevents is scope widening on exchange: a token exchange issuing a downstream credential broader than the original consent, usually because the downstream service only offered a coarse role. The chain stays intact and becomes meaningless, since the recorded consent no longer bounds what happened. This is common and almost never deliberate.

Alongside it, three practical bounds: a stable chain identifier issued at the human interaction and carried through every descendant call; depth and breadth limits, because an agent that can spawn agents without bound is an availability problem before it is a governance one; and a hop count in the propagated context so that unbounded delegation is detectable rather than merely undesirable.

Three topologies and their failure modes

The orchestrator pattern is the most common and its failure mode is the most often missed: teams scope each specialist carefully and give the orchestrator everything, because it needs to be able to call all of them. Scope the orchestrator per task, not per capability.

What to require before running agents in production

1. Every agent has its own attested identity. No shared service accounts across a fleet, which destroys attribution the moment two agents behave differently.
2. Authority is propagated, not re-derived. A receiving agent should never reconstruct authorisation from its own assumptions about the caller.
3. Scope narrows monotonically, enforced at issuance.
4. A chain identifier survives the whole fan-out, so hundreds of calls collapse back to one authorisation.
5. Cross-boundary calls federate trust domains rather than sharing credentials.
6. Depth, breadth and hop limits exist and are enforced.
7. Logs reconcile across boundaries. If agent B is operated by another team, agree the correlation identifier before the incident, not during it.

Frequently asked questions

What is the A2A protocol and what is its status?

Agent2Agent is an open protocol for communication between AI agents built on different frameworks, announced by Google in April 2025 and contributed to the Linux Foundation in June 2025. It reached v1.0 in 2026, with v1.0.1 in May 2026 adding an extension mechanism, and is supported by more than 150 organisations with integration across the major cloud platforms. It is a stable open specification under neutral governance rather than an IETF or ISO standard, and it is not certifiable.

What is the difference between MCP and A2A?

MCP is vertical and A2A is horizontal. MCP connects an agent to its tools, context and resources; A2A connects agents to each other so they can discover capabilities, delegate tasks and coordinate without exposing internal state. They are complementary rather than competing, and production systems routinely run both: A2A routes a task to the right specialist agent, and MCP gives that agent its tools.

Does A2A handle authorization and governance?

Only partially. A2A covers discovery, capability description, task routing and transport-level security schemes, and its task lifecycle includes an explicit auth-required state. Its four official extensions cover secure passport, timestamping, traceability and gateway routing, and none addresses governance directly. Whether a delegation was authorised, how consent propagates, and what an auditor can reconstruct all have to be handled at the identity layer beneath the protocol.

How do you establish trust between two AI agents?

Through the identity layer rather than the message layer. Each agent holds a short-lived credential attested from its runtime so the caller is identified cryptographically; trust domains are federated where agents sit in different clouds, tenants or organisations rather than sharing credentials; and the original principal's authority is propagated with the request rather than re-derived. An agent that authenticates its caller but cannot see the original consent knows who is asking, not whether the asking is authorised.

What stops a multi-agent system from escalating privileges?

Monotonic scope narrowing: no descendant agent may hold authority exceeding its parent, enforced at credential issuance rather than checked in review. That single rule bounds an entire agent tree by the original human consent regardless of how deep or wide the fan-out becomes. The failure it prevents is scope widening on exchange, where a downstream credential is issued broader than the original consent because the receiving service only offered a coarse role.

Which multi-agent topology is safest?

None inherently, but their failure modes differ. Orchestrator patterns concentrate risk because the coordinator accumulates the union of every specialist's permissions and becomes the highest-value target; scope it per task rather than per capability. Peer-to-peer patterns diffuse the authorization picture so no component holds it. Hierarchical patterns have dynamic depth, so blast radius is unknowable at design time without an enforced hop limit.