TL;DR: A2A standardises how agents communicate but not how authority survives across hops, so by the third hop a request can still authenticate while losing verifiable proof of who authorised it or whether consent still holds, according to Agentic Fabriq. The governance failure is not transport, but the assumption that delegation remains intelligible after authority is reissued, inherited, or silently reset.
At a glance
What this is: This is an analysis of A2A delegation chains and the point at which authority, not transport, becomes the weak link.
Why it matters: It matters because IAM and agent-governance teams need to know when authenticated hops still fail to preserve consent, scope, and accountability.
Context
A2A standardises message exchange between agents, but it does not standardise how delegated authority is preserved from one hop to the next. That leaves identity governance teams with a familiar problem in a new form: authenticated traffic can still arrive stripped of the consent, scope, and accountability that made the original action legitimate.
The article frames the issue around delegation chains rather than protocol transport. Once an agent delegates to another agent, and that second agent delegates again, the security question stops being whether the request is signed and becomes whether the final action still sits inside the authority that was originally granted. That distinction is the real governance boundary.
Key questions
Q: What breaks when an agent-to-agent chain gets longer than one hop?
A: The chain stops preserving verifiable authority. Each hop may still authenticate successfully, but the final service can lose the original principal, the delegated scope, and the depth of authorization. Once that happens, the request is technically valid but governance-opaque, which is exactly where unsafe actions slip through.
Q: Why do authenticated agent requests still create authorization risk across hops?
A: Authentication proves the caller is who it claims to be at that hop, but it does not prove the caller still has the right to act for the original principal. In a long delegation chain, authority can be reissued, widened, or detached from consent unless every hop preserves and checks the delegation lineage.
Q: How should teams limit delegated authority in multi-agent systems?
A: Use monotonic narrowing. Each downstream hop should receive only a subset of the upstream authority, and the resource server should reject any request whose scope grows at a later hop. That keeps the chain auditable and prevents one agent from silently expanding its access by calling another service.
Q: What should security teams do when a delegation chain crosses trust domains?
A: Treat the boundary as a governance checkpoint, not a routine handoff. Require explicit origin identity, short-lived per-hop credentials, and a depth limit that prevents the chain from continuing after the original consent should no longer apply. Without that, revocation and accountability degrade at the point where they matter most.
Technical breakdown
Why authenticated A2A hops still lose authority
A2A treats remote agents as ordinary HTTP applications and leaves credentials to headers, which is workable for a single hop. The problem begins when the request crosses trust boundaries and the protocol no longer carries a verifiable account of user identity, delegated actor lineage, or authorization depth. At that point, each hop may authenticate cleanly while the final resource server still cannot tell who authorised the action or whether the original consent still applies. The technical gap is not signature failure. It is the absence of a chain-of-custody model for authority across multiple delegations. See the Authorisation Models Guide.
Practical implication: Treat authentication success as insufficient unless the request also preserves delegating identity and depth across every hop.
How monotonic narrowing constrains delegation chains
The most practical control described in the article is monotonic narrowing. Each hop should receive no more authority than the previous hop held, and never gain scope by minting a fresh credential from its own registration. That makes the chain mechanically checkable: an enforcement point can compare outbound scope with inbound authority context and reject any expansion. This is the key architectural shift for agent-to-agent authorisation, because it removes the assumption that each hop can safely decide what it needs. Instead, every hop is forced to inherit a smaller permission set than it started with. See the AI Agent Authorisation Guide.
Practical implication: Enforce scope subset checks at each hop so delegation can only shrink, never re-expand.
Why delegation depth and revocation need explicit controls
The article shows that revocation at the origin does not automatically reach downstream hops, especially once a chain crosses trust domains. That is why depth limits and short lifetimes matter. A hop counter bounds recursion and prevents endless delegation, while per-hop expiry reduces the window in which stale authority can still act. Together, these controls do not solve chain integrity, but they do prevent a long chain from outliving the grant that created it. In practice, this is the difference between a contained delegation path and an unbounded authority trail. See the Multi-Agent and A2A Security Guide.
Practical implication: Set a maximum hop count and require each hop to revalidate authority before it can act.
Threat narrative
Attacker objective: The objective is to make a downstream agent perform an action that looks authorised at the final hop but is no longer traceable to the original grant.
- Entry begins with a legitimate agent-to-agent request that is authenticated but not yet bound to a preserved authority chain.
- Escalation occurs when each downstream hop reissues or inherits authority without proving that the original consent still applies at that depth.
- Impact appears when the final agent acts in a different trust domain and executes a consequential action that no longer has a verifiable authorization lineage.
Breaches seen in the wild
- Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
- Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Authority is not the same thing as authentication: this article shows that a request can be fully authenticated at every hop and still lose the answer to whose consent it is acting under. That is the central governance failure in multi-agent delegation. Identity teams should stop treating hop integrity as a transport question and treat it as an authorization lineage question instead.
Monotonic narrowing is the right governing assumption for agent chains: every delegated hop should hold the same or less authority than the hop before it, never more. The article makes clear that the dangerous failure mode is scope re-acquisition, where a hop mints fresh organisational authority and silently resets the chain. Practitioners need to treat that as a broken invariant, not a corner case.
Consent that cannot travel is consent that does not govern the final act: the article's three-hop example shows how an original customer instruction can disappear once the request crosses organisational boundaries. That breaks the assumption that a downstream system can rely on the origin request alone to justify action. The practical lesson is that accountability has to remain attached to the request all the way to the resource server.
Delegation depth is now an identity-control variable, not a design detail: the longer the chain, the more likely it is that authority will fragment, revocation will lag, and logs will disagree about who authorised what. This is why agent governance cannot stop at a single trusted boundary. Practitioners should treat hop count, scope inheritance, and cross-domain handoff as core control-plane decisions, not implementation afterthoughts.
What this signals
Delegation depth is becoming a control-plane variable: as multi-agent systems move from one-hop calls to longer chains, security teams need to govern not just who can call whom, but how far authority is allowed to travel before it must be revalidated. authorisation models matter here because the control question is no longer simple access control, but how to represent delegated scope across repeated handoffs.
The next programme-level question is whether your current IAM design can still explain a request after three hops. If it cannot, then logging, consent, and approval records are not yet operating as one governance system. That gap will matter most when agent activity crosses organisational boundaries or when a downstream service acts on behalf of a user it never directly sees.
Authority trail collapse: when a chain reuses credentials instead of preserving delegation context, the organisation loses the ability to prove which principal authorised the final action. That is not just an audit inconvenience. It is a structural limit on how far current identity governance assumptions can extend into agent-to-agent execution.
For practitioners
- Enforce hop-by-hop scope reduction Reject any outbound agent request whose authority exceeds the inbound authority context, even if the downstream service would otherwise accept it.
- Require depth limits on every delegation chain Set a maximum hop count in the authorization layer and block delegation once the request exceeds that depth, regardless of business workflow.
- Preserve origin identity through the full chain Carry the original user principal and delegating actor through every hop so the final resource can see who initiated the action.
- Make revocation a per-hop check Do not assume upstream consent revokes downstream execution automatically. Require each enforcement point to validate that the grant is still live before acting.
Key takeaways
- Agent-to-agent interoperability can work cleanly at the transport layer while still failing to preserve the authority that should govern the last hop.
- The central control problem is scope and consent continuity, not whether each hop authenticated successfully.
- Depth limits, monotonic narrowing, and preserved origin identity are the practical controls that keep long delegation chains governable.
Related NHI Mgmt Group resources: Authorisation Models Guide · Multi-Agent and A2A Security Guide · AI Agent Authorisation Guide · NHI Lifecycle Management Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article is about delegated authority drifting across agent hops and being abused or overextended. |
| ASI07 — Insecure Inter-Agent Communication | The article centres on what breaks when one agent talks to another without preserving authority context. | |
| Recommendation — Map chained delegation risks to ASI03 and enforce bounded, verifiable privilege transfer between agents. Apply ASI07 controls to require authenticated, integrity-protected inter-agent exchanges with preserved context. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The post shows that authenticated hops alone do not preserve the authority needed for safe action. |
| Recommendation — Use NHI-04 to ensure each hop proves both identity and the right to act on inherited authority. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about whether delegated permissions remain valid as requests cross hops. |
| Recommendation — Use PR.AA-05 to keep delegated permissions explicit, bounded, and revocable at every enforcement point. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack pattern discussed involves moving authority through successive hops into another trust domain. |
| Recommendation — Track chained delegation abuse as Credential Access and Lateral Movement to detect scope expansion across trust boundaries. | ||
Key terms
- Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.
- Monotonic Narrowing: Monotonic narrowing is the rule that each delegated hop may pass forward only a subset of the authority it received. For agent and workload governance, it prevents a downstream actor from silently regaining broader access than the upstream hop had, which is essential when requests cross trust boundaries.
- Scope Re-acquisition: Scope re-acquisition happens when a hop discards delegated authority and instead re-authenticates with its own broader credential. That resets the chain to organisational-level access, which can make a request look legitimate while breaking the relationship between the original consent and the final action.
- Authorization Context: Authorization context is the information used to decide whether an identity should be allowed to act. It can include workload state, environment, time, risk, and task intent. In modern PAM, richer authorization context is what separates a secure decision from a merely authenticated one.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org