Because each hop can reissue or widen authority unless scope is intersected at issuance and lineage remains visible. The more products and integration boundaries involved, the easier it is for context to disappear and for the final privileged action to exceed the original principal’s intent.
Why separate gateways make delegation chains riskier
Separate agent gateways add another place where authority can be transformed instead of simply passed through. Each hop may translate a request, mint a new token, or preserve only part of the original context, so the final action can drift from the user’s intent if scope is not intersected at every boundary.
That risk rises when the gateways are owned by different products or teams, because lineage becomes harder to follow and policy assumptions stop lining up. In multi-hop chains, the security question is not just whether each gateway is “approved”, but whether every hop can prove what it received and exactly what it is allowed to forward.
When delegation is distributed across boundaries, the chain is only as strong as its weakest issuance step. A gateway that reissues credentials, expands scopes, or strips provenance can create a new principal-like artifact that looks valid to the next hop even when it no longer reflects the original caller’s constraints.
Where authority expands or disappears in the chain
The core failure mode is privilege inflation by accumulation. One gateway may add tool access, another may convert a broad user grant into a reusable service token, and a third may treat that token as sufficient evidence for a higher-value operation than the user originally authorized.
Context loss is the other half of the problem. If the original principal, purpose, and requested action are not carried forward in a machine-verifiable way, downstream controls have no reliable basis for deciding whether the next hop is still operating within intent. That is why delegation design needs explicit lineage, not just working authentication between services.
This is especially important in agentic workflows that rely on token exchange, impersonation, or on-behalf-of patterns. Those mechanisms can be sound, but they become fragile when each intermediary makes independent decisions without preserving the original scope and decision trail. Multi-Agent and A2A Security Guide explains why multi-hop delegation, signed agent identity, and containment need to be treated as one control surface rather than separate implementation details.
Multi-hop chains also create more trust boundaries, which means more chances for inconsistent policy, stale trust data, or a gateway that unintentionally becomes a confused deputy. AI Agent Authorisation Guide is useful here because it focuses on task-scoped access and per-action decisions, which are the right design instincts when authority must survive more than one hop without growing legs of its own.
For practitioners evaluating the broader pattern, the issue is not whether a gateway exists, but whether it can preserve least privilege through every translation step. Zero Trust for AI Agents is relevant because it frames verification, standing privilege reduction, and policy enforcement as continuous requirements rather than one-time checks.
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 and OWASP Non-Human Identity Top 10 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Multi-hop gateways can widen delegated authority across agents. |
| ASI07 — Insecure Inter-Agent Communication | Gateway hops can break trust context and handoffs between agents. | |
| ASI08 — Cascading Failures | One widened hop can propagate excess privilege through the chain. | |
| Recommendation — Enforce per-hop scope intersection and preserve delegation lineage. Protect inter-agent handoffs with signed context and explicit policy checks. Contain blast radius by limiting what each hop can reissue. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Delegation chains can expand non-human privileges beyond intent. |
| NHI-09 — NHI Reuse | Reused delegated credentials across hops can outlive the original context. | |
| Recommendation — Bound each reissued credential to the minimum required scope. Prevent credential reuse across hops without explicit scope reduction. | ||
Practitioner Guidance
What to verify: Check that every hop carries an immutable delegation record, a clear original principal, and a bounded action scope. If any gateway reissues authority, verify that the new token is strictly narrower than the upstream grant and that the downstream system can still see the full lineage.
Decision rule: If a gateway cannot prove what scope it received and what scope it forwarded, treat it as a trust boundary that needs redesign, not just monitoring. If a gateway can only enforce policy by assuming upstream correctness, the chain is already too loose for high-impact actions.
What practitioners underestimate: The most dangerous failure is often not a single overpowered gateway, but the cumulative effect of several “reasonable” transformations that together widen access. In delegation chains, the safe default is to intersect authority at each hop and keep provenance visible end to end.
Practitioner takeaway: Multi-hop delegation is safe only when every intermediary preserves lineage and narrows, rather than recreates, authority, because invisible context loss is how valid-looking requests become unauthorized outcomes.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org