What breaks when token exchange is not narrowed at each hop?

The delegation chain widens silently, so a token minted for one action or server can be reused across tools and downstream APIs. That creates scope drift, weakens least privilege, and makes it harder to prove that the agent stayed inside its intended authority boundary.

Why narrowed token exchange matters at every hop

token exchange is only safe when each new token is narrower than the one before it. If a hop preserves broad audience, scope, or delegated authority, the chain stops acting like a guardrail and starts acting like a relay. The practical effect is that one compromise, one overbroad grant, or one bad integration can unlock multiple downstream systems instead of a single intended action.

That widening is especially dangerous in agentic and service-to-service flows, where the original actor and the final resource are not the same. The more hops you allow, the more important it becomes to bind the token to a specific purpose, audience, and expiry so downstream components cannot treat it as a general-purpose credential.

Where scope drift appears in real delegated flows

Scope drift usually shows up when an intermediary exchanges a token but does not reduce the authority to match the next step. Instead of converting “can act on behalf of” into a tightly bounded request, the system forwards something that still works across tools, APIs, or resource servers. RFC 8693: OAuth 2.0 Token Exchange is the clearest reference point for how delegation should be narrowed rather than passed through unchanged.

This is also where audience restriction and sender-constrained tokens matter. If the downstream token is not tied to the next resource, or if it can be replayed elsewhere, the exchange becomes a convenience mechanism instead of an authority boundary. That is the failure mode that turns a local handoff into an expandable trust chain.

Why least privilege fails when the chain stays broad

Least privilege breaks because the effective permission set becomes the union of every hop, not the minimum authority required at each hop. A token minted for one server can unintentionally function as a cross-tool pass, which makes later requests look legitimate even when they exceed the original intent. In practice, this creates implicit privilege escalation without any obvious policy violation at the first exchange.

For practitioners, the key question is not whether a token was exchanged, but whether the exchanged token is narrower in audience, scope, and lifetime than the previous one. That is the difference between delegation and uncontrolled reuse. RFC 6749: The OAuth 2.0 Authorization Framework provides the base authorization model, but the security outcome depends on how tightly each derived token is constrained in the next hop.

Risk and Threat Considerations

When token exchange is not narrowed, the main risk is blast-radius expansion: a single stolen, overbroad, or misrouted token can open access to multiple tools and APIs that were never meant to share the same authority. That also weakens auditability, because it becomes harder to tell whether a downstream action was genuinely within the intended delegation boundary.

Failure mechanism: An intermediary reuses or remints a token without tightening audience, scope, or expiry, so the token remains valid beyond the next hop and can be replayed across other services.

Impact: An attacker or misconfigured agent can move laterally through trusted integrations, amplify access, and create scope drift that is difficult to detect after the fact.

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 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 Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Token reuse across hops enables excessive delegated authority in agent flows.
Recommendation — Constrain each exchanged token to the next hop's exact authority.
OWASP Non-Human Identity Top 10	NHI-04 — Insecure Authentication	Broad token exchange weakens authentication boundaries between services and tools.
Recommendation — Bind exchanged tokens to the intended audience and purpose.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Token narrowing depends on controlled issuance, scope, and lifecycle of authenticators.
	AC-6 — Least Privilege	Each hop should receive only the minimum access needed for that step.
	AC-3 — Access Enforcement	Access decisions must enforce hop-specific boundaries on exchanged tokens.
Recommendation — Limit token lifetime and revoke credentials that can be replayed downstream. Reduce each exchanged token to the minimum permissions required. Enforce audience and scope checks at every resource server.

Practitioner Guidance

What to verify: Check that every exchange produces a token with a narrower audience and the minimum scope needed for the next action. If the next hop can still call unrelated APIs, the exchange has not actually reduced authority.

Decision rule: If a token can be used beyond one resource or one step, treat that as a design defect, not an acceptable convenience. Narrow first, then integrate, rather than hoping downstream services will refuse excess authority on their own.

What good looks like: Each hop has its own clearly bounded token, short lifetime, and traceable purpose, so any misuse is limited to one resource and one action path.

Practitioner takeaway: The goal of token exchange is not continuity of access, it is controlled conversion of authority. If the exchanged token is still broadly usable, the system has preserved convenience at the expense of containment.