The safest pattern is to exchange credentials at each hop and reduce scope every time. That means no forwarding of the original bearer token, no privilege carryover from one agent to the next, and no task that depends on a single reusable credential across the chain.
Why reused bearer tokens break multi-hop agent chains
Agents should not carry the same token from one hop to the next because each hop usually has a different trust boundary, audience, and required privilege. A token that works for one step often authorizes too much for the next, which makes replay, confused deputy behavior, and lateral movement easier if any intermediary is compromised.
The safer model is token exchange, not token forwarding. Each hop should receive a fresh credential that is scoped to that hop alone, with the original authority stripped down or converted into a narrower delegation before it can be used again.
In practice, this means the chain should preserve intent, not preserve the credential. The first agent proves what it is allowed to do, the next hop gets only the minimum authority needed for its own action, and no downstream step should be able to reuse an upstream bearer token as if it were its own.
What changes when every hop gets a new credential
Per-hop exchange changes both the blast radius and the audit trail. If one agent or connector is compromised, the attacker gets only the authority attached to that hop, not a credential that still works across the rest of the workflow. That also makes it easier to revoke or expire the next credential without breaking the entire chain.
This pattern is especially important when agents call external services, internal APIs, or other agents. A reused token can silently become a standing credential for a broad set of actions, while exchanged tokens can be audience-bound, time-bounded, and purpose-bound to the current hop.
It also improves accountability. When credentials are exchanged at each step, each hop can be logged and evaluated independently, which is much easier to reason about than a long chain where one bearer token appears everywhere and hides which step actually exercised authority.
How to design the handoff so privilege does not follow the token
The practical design goal is to bind access to the current task, not the original session. A hop should only get the permissions it needs to complete its own action, and those permissions should expire as soon as that action is complete. That is the difference between delegated authority and credential reuse.
Use a hop-by-hop exchange pattern when the next service is acting on behalf of the prior one, especially if the downstream system is a different domain, tenant, or control plane. If a token must cross boundaries, it should be transformed into a narrower artifact rather than copied forward unchanged. Guide to NHI Rotation Challenges is useful background on why short-lived, replaceable credentials are safer than reusable ones.
Where agent-to-agent or tool-to-tool delegation is involved, the authorization decision should happen at the point of use, not once at the start of the workflow. That keeps downstream access aligned with the actual action being requested instead of inheriting a broad upstream grant. AI Agent Authorisation Guide covers this least-privilege pattern well, and Multi-Agent and A2A Security Guide shows how multi-hop delegation should be contained.
Risk and Threat Considerations
Reusing the same token across hops creates a single credential that can be replayed, forwarded, intercepted, or overextended across the whole chain. If any hop is compromised, the attacker may inherit far more authority than that step actually needed, which turns a local failure into a broad compromise path.
Failure mechanism: A bearer token is treated as transferable authority, so any intermediary, log sink, plugin, or compromised agent can reuse it at later hops or against a different resource.
Impact: The chain loses isolation, revocation becomes harder, and one stolen token can enable privilege escalation, unauthorized API access, or cross-service lateral movement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-09 — NHI Reuse | Multi-hop token reuse is the exact reuse pattern that expands blast radius. |
| NHI-07 — Long-Lived Secrets | Reusable tokens behave like long-lived secrets across chained agent actions. | |
| NHI-05 — Overprivileged NHI | Forwarded tokens often carry more privilege than the next hop needs. | |
| Recommendation — Eliminate credential reuse by issuing a new scoped credential at each hop. Shorten token lifetime and rotate credentials before they can be replayed. Reduce scope at each hop and remove excess privileges before delegation. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent chains fail when downstream steps inherit excessive identity authority. |
| ASI02 — Tool Misuse | A reusable token can let an agent or tool exceed its intended action boundary. | |
| Recommendation — Enforce per-hop authorization so agents cannot inherit upstream privilege unchanged. Bind each tool invocation to a fresh, task-scoped credential. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Service and agent hops need direct authentication rather than forwarded bearer reuse. |
| AC-6 — Least Privilege | Each hop should hold only the permissions required for its own action. | |
| IA-5 — Authenticator Management | Hop-by-hop token issuance, expiry, and revocation are credential lifecycle concerns. | |
| Recommendation — Authenticate each service hop directly and avoid passing the original bearer token onward. Constrain each hop to the minimum permissions required for that step. Issue short-lived credentials and revoke them as soon as the hop completes. | ||
Practitioner Guidance
What to verify: Confirm that each hop receives a fresh token or exchanged credential with a narrower audience, shorter lifetime, and only the permissions needed for that hop. If the downstream service would still work with the original bearer token, the delegation model is too loose.
Common mistake: Teams often fix token forwarding only at the application layer while leaving gateway, broker, or agent middleware free to copy the same credential onward. That still creates replay risk and makes revocation ineffective across the chain.
Decision rule: If a hop can act independently, give it its own scoped credential; if it is only relaying authority, convert the authority into a bounded delegation artifact before the next call.
Practitioner takeaway: Treat every hop as a new authorization decision, because reusable bearer tokens create hidden standing privilege and erase the security boundary between one agent and the next.
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