Classic painting used as the article cover

DELEGATION

Agent-to-Agent Authorization: What Breaks When Delegation Chains Get Long

A2A standardizes how agents talk, not what authority travels with the request. What breaks at hop three, which mechanisms exist today, and the invariants worth enforcing before they do.

Paulina Xu•Sep 14, 2026•16 min

DelegationMulti-Agent SystemsIdentity

TL;DR

A2A tells two agents how to talk. It says nothing about whose authority survives the conversation.

By the third hop in a delegation chain, the request reaching a resource server carries an authenticated client and no verifiable answer to who authorized the action, at what depth, or whether that authorization still holds. A2A's own specification says as much: it states plainly that it doesn't carry user or client identity in its payloads.

The instinct is to blame the protocol. We don't think that's fair. Leaving credentials to HTTP headers is defensible for a single hop, and the spec says so directly. The real problem is that almost nobody builds hop two and hop three as carefully as hop one, so a customer's original consent quietly stops traveling with the request.

This isn't an argument that A2A is broken or needs a rewrite. Every hop can authenticate cleanly, pass every audit, and still let authority evaporate at a trust-domain boundary.

Two things fix most of it before any emerging standard ships: authority that can only shrink at each hop, never grow, and a hop counter that refuses to delegate past a depth set on purpose. Neither needs new cryptography. Both need someone to build them.

Overview

Multi-agent systems reached production faster than the authorization model for them did. An agent calling another agent looks, from the caller's side, like an ordinary HTTP request to a service. From the resource's side, three hops later, it looks like an authenticated request from a legitimate client. What is missing in between is any protocol-level account of whose authority the final action was taken under, and whether that authority was ever granted for it.

A2A makes the calling part work, and works well. It also states plainly that it does not carry identity in its payloads. We think that's a defensible scoping decision: the protocol treats remote agents as ordinary HTTP applications and leaves credentials to HTTP headers. But it means a chain's authorization semantics are entirely a property of whatever the implementers built around it, and most build the first hop carefully and let the rest inherit.

Two existing posts cover adjacent ground worth separating out. Multiagent Patterns is coordination architecture. The Problem of Passing Context Between Agents is about what leaks when data crosses an agent boundary. This post is neither. It is strictly about authority and accountability across hops: what travels with the request, what may not, and how you know.

Here's a hypothetical worth keeping concrete through the rest of this post: a retail delivery exception. A customer messages about a missing parcel. A customer-service agent (A) triages it and delegates to the retailer's fulfilment agent (B). B delegates to a carrier-integration agent (C), operated by the carrier, in the carrier's own trust domain, to reroute the replacement and register a goodwill credit against the retailer's account. Three hops, two organisations, one customer who consented to a support interaction and nothing else. No such customer or carrier exists; the numbers below are illustrative.

The gap in one sentence: A2A standardizes how agents talk. It does not standardize what authority travels with what they say, which means the authorization model of a delegation chain is whatever your implementation accidentally built.

What A2A Standardizes

Credit where it's due. A2A became the interoperability layer for cross-framework agent communication faster than most standards manage. Announced by Google in April 2025 and now hosted by the Linux Foundation, its one-year milestone on 9 April 2026 reported growth from 50+ to over 150 supporting organisations, among them AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP and ServiceNow, plus SDKs in five languages and production deployments in supply chain, financial services, insurance and IT operations. v1.0.0 shipped 12 March 2026, separating protocol definition from transport bindings, modernising its OAuth 2.0 flows and introducing signatures on the AgentCard; v1.0.1 followed on 28 May 2026 as a patch.

Three mechanics matter here. Agent Cards are the discovery document, carrying the agent's url, capabilities, skills, and, importantly, securitySchemes and security, aligned with the OpenAPI Specification, declaring how a caller must authenticate. Since v1.0.0 a card can carry signatures, signed as JWS over an RFC 8785 canonicalisation, so a recipient can verify it came from the domain claiming it; an unsigned card is a redirect primitive. Tasks are the delegation unit, and v1.0 names eight states: TASK_STATE_SUBMITTED, _WORKING, _INPUT_REQUIRED, _AUTH_REQUIRED, _COMPLETED, _FAILED, _CANCELED and _REJECTED, the last four terminal. This is how B hands work to C.

Extensions are how anything the core does not express gets expressed. Agents declare AgentExtension objects inside AgentCapabilities with a uri, description, required flag and params; clients activate them by listing URIs in the A2A-Extensions header, and the agent echoes back which were activated. Published examples include Traceability for task-flow visibility and Secure Passport, a trusted contextual layer for personalisation. Secure Passport is the closest thing in the ecosystem to standardised caller context. Context for personalisation is not authority for authorization.

What the specification says about the rest is direct. Credentials must travel in standard HTTP headers, and "A2A protocol payloads, such as JSON-RPC messages, don't carry user or client identity information directly." Credentials are obtained "through processes external to the A2A protocol itself." And "authorization logic is specific to the agent's implementation, the data it handles, and applicable enterprise policies." Agents are framed as opaque, with no shared memory, tools or resource access, which is what makes the client-server security model a reasonable fit for a single hop. Opacity is exactly what stops it fitting a chain.

Five Questions a Chain Cannot Answer

Give the hypothetical a normal implementation. A authenticates to B with a client credential. B authenticates to C with an OAuth client credential the carrier issued to the retailer. Every hop is authenticated, every hop is TLS, nothing is misconfigured. Five questions still have no answer at the protocol level.

Whose authority is C acting under? From C's perspective the caller is "the retailer's fulfilment integration." The customer is not a party to the request, and neither is the support agent who triaged it. C authorises against a client identity representing an organisation, so any action inside that client's scope is permitted regardless of which complaint provoked it.

Was the authority ever granted transitively? The customer authorised a support interaction; nobody asked them to authorise a carrier-side account credit. In a single-hop OAuth flow the consent screen and the action are adjacent. By hop three the grant is three abstractions removed from the effect, and the consent that exists covers the first hop only.

Can C tell how far back the human intent is? No. C sees one inbound request and cannot distinguish one a human initiated four seconds ago from one produced by an agent loop with no human involvement since Tuesday. Depth is invisible, so "an agent asked me to" and "a person asked for this" are the same signal.

What happens when the original grant is revoked mid-chain? The customer withdraws consent while B's task at C is still TASK_STATE_WORKING. C's credential is unaffected. It belongs to the retailer, not the customer, so C completes the action. Revocation at the origin has no path to the far end.

Who is accountable? C's logs show a valid request from the retailer's client. B's logs show a task delegated by A. A's logs show a customer conversation. No single system holds the causal chain, so accountability is reconstructed by correlation after the fact, if at all.

An April 2026 arXiv survey of the agent identity standards landscape puts the general form well: OAuth 2.0 handles one-hop delegation cleanly, but once delegation becomes recursive the authorization chain loses its anchor, and no deployed protocol can cryptographically demonstrate which human principal authorised which specific agent at the third or fourth hop.

A: customer service authority context: user=customer, scope=support:read, depth=0 [verifiable] A --> B: fulfilment authority context: user=customer, actor=A, scope=shipments:read [verifiable] B --> C: carrier integration (different trust domain) authority context: client=retailer-integration ONLY. user identity dropped, actor chain dropped, depth unknown, origin consent unlinkable. [UNVERIFIABLE] C --> Carrier API: reroute + goodwill credit (irreversible, external) -->

Figure 1 — A three-hop chain. Authority context survives the first two hops because both are inside one trust domain and one token lineage. It is dropped at the domain boundary, where the request becomes "the retailer's integration" and the customer disappears.

Mechanisms Available Today

Nothing above requires new cryptography to improve. Three mechanisms are deployable now, with real limits.

Nested actor claims via token exchange. RFC 8693 lets an exchanged token carry the user as sub and the delegating agent as a nested act claim, so a token can express "the customer, acted for by A, acted for by B." Token exchange mechanics are covered in the RFC 8693 post on this site. The limitation that matters for chains: prior actors in the act nesting are informational, and RFC 8693 does not define how a delegation path is preserved and validated across successive exchanges. That gap was discussed on the IETF OAuth working-group list in early 2026 under the heading of delegation chain splicing: an attacker inserting themselves between legitimate hops. The class already has a production instance: CVE-2025-55241 in Microsoft Entra ID involved actor token validation failures with cross-tenant impersonation impact.

Cross-domain chaining. draft-ietf-oauth-identity-chaining (at -17, 19 July 2026, Standards Track) composes token exchange under RFC 8693 with the JWT authorization grant under RFC 7523, so identity and authorization information can cross trust domains: an intra-domain exchange produces a JWT grant, which the foreign authorization server accepts to issue its own access token. This is the correct shape for the B-to-C hop, and it's the mechanism draft-klrc-aiagent-auth reaches for at an authorization-server boundary. It's also a draft, and it standardises the carriage of a chain rather than proof of its integrity.

Delegation depth limits. The cheapest effective control and the most commonly omitted. Put a hop counter in the authority context, increment it at every delegation, and refuse to delegate past a configured maximum. This bounds the blast radius of any chain-integrity flaw without requiring you to solve chain integrity, turns unbounded recursion into a clean denial, and catches accidental cycles.

Monotonic Narrowing as an Invariant

The single most useful invariant in agent-to-agent authorization is that authority may only shrink along a chain, never grow. Each hop may pass forward a subset of what it holds, and nothing else. Formally: if hop n holds permission set Pₙ, then Pₙ₊₁ ⊆ Pₙ for every n, and the final action's scope must be a member of P at every preceding hop. That's checkable without understanding the workflow's semantics, which is what makes it valuable. The enforcement point doesn't need to know why B is calling C, only that C isn't being handed something B never had.

For the delivery scenario the narrowing is concrete:

customer grant           support:read, orders:read(own), shipments:read(own),
                         credits:request(<= GBP 25, own orders)

A -> B                   orders:read(order 88-4412), shipments:read(order 88-4412),
                         credits:request(<= GBP 25, order 88-4412)

B -> C                   shipments:reroute(consignment C-77120),
                         credits:apply(<= GBP 25, consignment C-77120)

C -> carrier API         shipments:reroute(consignment C-77120)     [executed]

Two properties fall out. The chain cannot produce a £400 credit, because no hop ever held authority for one. And C's request is scoped to a single consignment, so a compromised C cannot reroute the rest of the retailer's shipments. A client-credential-per-integration model would allow exactly that.

The failure mode to design against is scope re-acquisition: a hop that, instead of narrowing what it received, mints a fresh credential from its own client registration. It happens accidentally, because "call the carrier API with our integration credential" is the path of least resistance and it works. It silently resets the chain to full organisational authority and is invisible in logs unless you look for it. An enforcement point that compares outbound scope against the inbound authority context is what catches it.

Figure 2 — Monotonic narrowing. The permission set shrinks at every hop; the only way it can grow is if a hop stops delegating and starts re-authenticating as itself.

Research Toward Verifiable Chains

Several 2026 proposals attack chain integrity directly. None is deployed at scale; all are worth reading before you design something bespoke.

Cryptographically Verifiable Actor Chains for OAuth 2.0 Token Exchange (draft-mw-oauth-actor-chain-01, 15 June 2026, by A. Prasad of Oracle, R. Krishnan of JPMorgan Chase, D. Lopez of Telefónica and S. Addepalli of Aryaka) is an individual Standards Track submission adding an actc claim carrying actor-signed step proofs and cumulative commitment state, binding each hop to the prior accepted state. Its profiles are the cross-product of two evidence models against three disclosure modes, and the evidence axis is the useful one: declared, where the authorization server asserts chain continuity, versus verified, where each actor signs its own step and a resource can check the chain itself.

HDP (arXiv 2604.04522, Asiri Dalugoda, 6 April 2026) is narrower and, for accountability, more pointed. It binds a human authorization event to a session and records each agent's delegation as a signed hop in an append-only chain, verifiable offline using only the issuer's Ed25519 public key and the current session identifier. It reports no performance figures, but its framing is the right one: what you need to prove at the far end of a chain is not that the caller is authenticated but that a human authorised this, through this path, within this scope.

AIP (arXiv 2603.24775, Sunil Prakash, 25 March 2026, with a companion submission draft-prakash-aip) proposes Invocation-Bound Capability Tokens, fusing identity, attenuated authorization and provenance into one append-only artifact in two wire formats: a signed JWT for single-hop, and a Biscuit token carrying Datalog policies for multi-hop, where holder-side attenuation enforces monotonic narrowing at each step. Reported overheads are small: 0.22 ms added latency over real MCP-over-HTTP, 2.35 ms in a multi-agent deployment, described as 0.086% of total latency. Its adversarial evaluation reports 600 attack attempts rejected at 100%, catching delegation depth violations and audit evasion that unsigned and JWT-only baselines missed. That is a self-designed suite evaluated by its author, so the figure establishes internal consistency rather than security in the wild; the interesting part is which categories the baselines missed. The paper also reports a survey of roughly 2,000 MCP servers finding authentication absent, a reminder that the chain problem sits on top of a first-hop problem many deployments have not solved.

AATs (draft-niyikiza-oauth-attenuating-agent-tokens-01, Niki Aimable of Tenuo, 15 June 2026, another individual submission) takes the monotonicity argument furthest. Attenuating Authorization Tokens profile Rich Authorization Requests (RFC 9396) into signed JWTs encoding both which tools an agent may invoke and what argument constraints apply, the argument-level detail most schemes omit and what separates "may call issue_refund" from "may call issue_refund for at most $50 on orders it was given." The mechanism worth noting is offline derivation: a holder mints a narrower child token locally, with no round trip to the issuer, and an enforcement point verifies the whole chain from the root issuer's public key alone, each link cryptographically bound to its parent. Six mandatory invariants cover tool scope, argument constraints, depth and lifetime, framed as a capability lattice. The tradeoff is the one every capability system makes. Removing the token service from the hot path removes the latency and availability cost of an exchange per hop, and also its chance to apply policy per hop. A leaked intermediate token stays usable until expiry without the issuer ever seeing it. Right for high-fanout, latency-sensitive chains, wrong where every hop is a decision point you want recorded centrally.

Accountability and the Fragmented Record

Audit-log design for agents is covered elsewhere on this site. The point specific to chains is worse: a fragmented chain means no single system can reconstruct why an action happened, no matter how good each system's logging is.

A's transcript holds the customer's words and A's reasoning. B's task record holds a delegation with a task id and a scope. C's log holds an authenticated API call from the retailer's client. Each is complete on its own terms and each lacks the join key that would attach it to the others. Reconstruction is a correlation exercise across three retention policies, two organisations and, if C is a vendor, a contractual data request. For an EU AI Act high-risk system that is not a theoretical inconvenience: standalone Annex III obligations apply from 2 December 2027 under the deferral adopted in June 2026, and the Article 12 automatic-logging requirement exists precisely so a specific decision can be explained afterwards. A chain that cannot be reconstructed cannot be explained.

A July 2026 preprint by Janssen (arXiv 2607.00941) formulates the standard a record must meet to support a legal finding: a typing that maps recorded events to the legally operative category, plus the relation (provenance, authority, derivation, temporal validity) on which the determination depends. It is explicit that this is necessity, not sufficiency, and that tamper-proof logs, generic process frameworks and provenance structures each fail alone. Applied here, agent logs record events well and relations not at all. "C rerouted consignment C-77120" is an event; "C rerouted it under authority derived from a grant the customer made at 14:02, narrowed twice, at depth 3" is a relation, and only the second answers a regulator.

Kang and Diponegoro's June 2026 gap analysis (arXiv 2606.31498) makes the structural version of the point, evaluating MCP, A2A, ACP, ANP and ERC-8004 against six governance dimensions and finding voting and dissent universally absent, deliberation absent or partial. Their conclusion is the one we'd take away: governance is "a missing architectural layer above current interoperability standards, not a missing feature within them." We aren't waiting for A2A to add this.

sequenceDiagram
    participant U as Customer
    participant A as Agent A
    participant B as Agent B
    participant C as Agent C
    U->>A: complaint, consent to support
    A->>B: task, narrowed authority
    B->>C: task, narrowed authority
    U->>A: withdraws consent
    A->>A: session terminated
    Note over B,C: task still working; C holds<br/>the retailer's own client credential
    C->>C: executes reroute plus credit
    Note over U,C: revocation never reached hop 3

Figure 3 — Revocation does not propagate. The chain outlives the grant that started it whenever a hop authorises on its own credential rather than on delegated authority.

Practical Rules

Pending a deployable standard, the following are enforceable now and hold up.

Keep chains short. Two hops is usually enough; each extra hop multiplies failure modes and divides verifiability. Depth is a design parameter: set a maximum and enforce it centrally rather than trusting agents to self-limit.
Make every hop explicit and logged with a shared correlation identifier. One id minted at the origin, propagated unchanged, recorded by every participant including across the organisational boundary. Contract for it with vendors the way you contract for uptime.
Enforce monotonic scope reduction as a hard invariant. Reject any outbound request whose scope is not a subset of the inbound authority context. A gateway can check this mechanically, and it catches scope re-acquisition.
Require the original user identity to travel the whole chain. If hop three cannot name the human, hop three should not take a consequential action. A carrier API that accepts only an organisational client identity is a gap in the carrier's design, and it is negotiable in an integration contract.
Give every hop a short lifetime and a revocation check. Since revocation does not propagate on its own, expiry bounds the window; per-hop expiry plus a revocation check at each enforcement point is the practical approximation.
Treat an agent that cannot present a verifiable chain as unauthorized. If the inbound request carries no origin principal, no actor lineage and no depth, the default for anything irreversible or external is denial.

All six require the same thing: an enforcement point outside the agents that sees each request, knows the identity of the calling agent and the human it acts for, and can refuse an individual action. Agentic Fabriq carries both identities on every request, computes the effective tool list as the intersection of the user's scopes and the agent's, and enforces permissions at the level of the individual action in the backend. That's what makes "hop three may only do a subset of what hop two could do" a check rather than a convention.

Conclusion

A2A solved the interoperability problem it set out to solve. Its scoping decision was reasonable for single-hop agent communication: credentials stay in HTTP headers, identity stays out of the payload, and authorization is whatever the implementer decided to build. Chains break that assumption. What's missing is a verifiable answer to a plain question, not stronger encryption or better authentication: on whose authority, granted for what, at what remove from a human.

Today that answer has to be constructed. Nested actor claims carry the shape of a chain without proving its integrity. Identity chaining carries it across domains as a draft. Depth limits and monotonic narrowing are cheap, mechanical and mostly unimplemented. We think the 2026 research converges on one conclusion: authority has to be an artifact that travels with the request and can be verified at the end, not an assumption that held at the beginning.

Design rule until the standards land: treat authority as something that must be presented at every hop, not something inherited by being called. An agent that cannot show whose authority it holds, narrowed from what, at what depth, is an unauthenticated caller with good manners.