A2A Delegation: Verifying an Agent-to-Agent Authority Chain
Protocol facts reviewed: 2026-07-30 · Protocol: 1.0.0-alpha.15 (alpha) · Benchmarks: 2026-07-25
A2A delegation is one agent passing authority to another agent. Verifying it means checking that every hop in the chain was permitted to delegate at all, and that no hop granted more than it received. Ratify Protocol enforces both: sub-delegation requires an explicit identity:delegate grant that wildcards never confer, and the effective scope is the intersection of every certificate in the chain.
What does A2A itself provide, and what does it leave open?
A2A defines how agents discover one another and exchange tasks, including the authentication schemes an agent advertises. That is real infrastructure, and Ratify does not replace it. Those schemes range from API keys and bearer tokens through OAuth, OIDC, and mTLS. What one establishes is the authenticated identity or credential that scheme supports, which the server then authorizes under its own policy.
It does not, on its own, tell the receiving agent which human or organization delegated the authority being exercised, whether the calling agent was permitted to receive it from whoever passed it along, or whether the authority was narrowed correctly at each hop. In a chain of agents those questions are the whole risk, because the receiver is several steps removed from the principal and usually shares no infrastructure with them.
What are the two rules that make a chain verifiable?
Sub-delegation is not implicit. A party may only pass authority onward if its own certificate carries an explicit identity:delegate grant. The specification treats that scope as sensitive, and wildcards never confer it: holding meeting:* does not make an agent able to delegate. A certificate issued by a party whose parent never granted identity:delegate is rejected with delegation_not_authorized.
Authority only narrows.The effective scope at any depth is the intersection of every hop’s grant. An intermediate cannot widen what it received, so a chain cannot accumulate authority as it lengthens. This is what makes a long chain tractable to evaluate: the receiver does not have to accept an intermediary’s claim about its own authority. It checks the signed chain against its configured trust anchors, its revocation state, and its own policy.
What does a receiver get back when a link fails?
A closed set of deterministic statuses, not a boolean. Each row below is a canonical conformance fixture that ships with the protocol. Each one pins the canonical signing bytes as well as the expected verdict, and every reference SDK reproduces both, which is what makes passing the suite a statement about interoperability rather than about test coverage. The copies linked here are hash-verified at build time against the manifest they were synced with.
| Scenario | Status | Fixture |
|---|---|---|
| Valid two-hop chainA principal grants meeting:* to an intermediate, which sub-delegates meeting:attend to a leaf agent. The receiver requires meeting:attend. | valid:authorized_agent | happy_path_depth_2.json |
| Intermediate grants what it never receivedThe intermediate does hold identity:delegate, so it may sub-delegate. It grants files:write having only received meeting:attend. The receiver requires files:write. | rejected:scope_denied | reject_scope_escalation_depth_2.json |
| A link in the middle is revokedA two-hop chain where the intermediate certificate has been revoked. The leaf certificate itself is untouched and unexpired. | rejected:revoked | revocation_middle_cert.json |
The middle row is the one worth sitting with. The intermediate in that fixture is legitimately allowed to sub-delegate: it holds identity:delegate. It still cannot hand on files:write, because it only ever received meeting:attend. Permission to delegate and the authority being delegated are separate things, and conflating them is how authority quietly widens in a multi-agent system.
The third row shows failure locating itself correctly. The leaf certificate is valid and unexpired, and the chain is still rejected, because a revoked link invalidates everything downstream of it.
How long does verifying a chain take?
Measured on the documented Apple M2 Pro baseline in July 2026, the compiled verifiers in Go, Rust, and C complete a full chain verification in 0.36 to 0.83 ms at chain depths one to three. The TypeScript verifier is 7.4 to 14.9 ms for the same work. Verification does not require a call to a Ratify service, provided the receiver already holds its trust anchors and revocation state fresh enough for its own risk policy.
What this does not settle
Chain verification answers whether authority was properly delegated and narrowed. It does not answer several things a multi-agent deployment still has to handle.
- Whether the root key belongs to the organization it claims to. That comes from the receiver’s trust anchors, not from the chain.
- Whether a validly delegated action is a good idea. Ratify proves authority, not intent, safety, or competence.
- Whether revocation state is current. Verification runs locally, and revocation data still has an age. High-risk actions should fail closed when sufficiently fresh state is unavailable.
- Whether an intermediate platform holding an agent’s key will use it honestly. The chain proves delegation, not custody discipline.
Where to go next
AI agent authorization covers how delegated authority is expressed and verified in general, and where it sits next to identity providers, OAuth, and policy engines. The specification is normative for the sub-delegation gate and scope intersection described here, and the repository holds every canonical fixture alongside the SDKs that reproduce them.