They increase governance complexity because authority can change shape as it moves from one identity context to another. Each hop may narrow access, but it also creates a new place where audience, subject, and accountability must be explicit. Without that mapping, delegated access becomes hard to audit and easy to overextend.
Why delegated authority becomes harder to govern
token exchange and impersonation are attractive because they let a caller act with narrower, more targeted access than the original credential had. The governance burden rises because the access path is no longer one identity, one audience, one owner. Each exchange creates a new trust decision that must be understood, approved, and reversible.
That matters most when teams treat the token as the whole story. In practice, the same request may be acceptable at one hop and over-permissioned at the next if the subject, audience, and intended use are not carried forward explicitly. The result is a policy chain that looks compact on paper but becomes difficult to audit in production.
What changes at each hop
Governance complexity increases because token exchange changes the meaning of the credential without changing the surrounding workflow. A token can represent a user, a service, an application, or a delegated session, and impersonation can shift which actor is accountable for the action. That means authorization is not just about access, but about RFC 8693: OAuth 2.0 Token Exchange and the explicit preservation of audience and subject across the exchange.
The practical issue is that each hop can narrow scope while also introducing ambiguity. If the new token is valid in a different context, the organization now has to govern who may mint it, what claims must survive, which downstream API or system may accept it, and how the resulting activity is attributed. Those are separate controls, not a single access decision.
This is why good implementations usually pair token exchange with strong constraints on audience, issuer trust, and token lifetime. The closer the model gets to on-behalf-of or delegated operations, the more important it becomes to bind the token to the intended resource and to reject generic bearer reuse. RFC 6749: The OAuth 2.0 Authorization Framework provides the base model, but governance complexity emerges when the organization adds additional delegation layers on top of it.
Why auditability and accountability get complicated
Governance depends on being able to answer three questions: who initiated the action, whose authority was used, and which system accepted that authority. Token exchange and impersonation make those questions harder because the visible actor can differ from the accountable actor. If logging only records the final token, the chain of custody disappears.
That creates two common failure modes. First, security teams cannot reliably distinguish legitimate delegation from privilege overreach because the call path is valid but the context is incomplete. Second, revocation becomes messy because the original credential, the exchanged token, and any refresh or downstream session may all need different treatment. In other words, a single access decision can spawn multiple lifecycle objects.
Governance also becomes more sensitive to policy drift. An exchange rule that was safe for one service may be copied into another service with a broader audience, a longer lifetime, or weaker approval logic. Over time, that creates silent privilege expansion even when each individual rule looked reasonable at the time it was written.
Risk and Threat Considerations
Token exchange and impersonation widen the attack surface because compromise at one step can be translated into valid access at another. The primary risk is not only theft of the original credential, but abuse of delegated trust, replay of exchanged tokens, and loss of attribution when the authorization chain is not fully logged or constrained.
Failure mechanism: A weak audience check, permissive delegation rule, or incomplete audit trail lets a token be exchanged into a more useful context than intended, or makes a legitimate impersonation impossible to distinguish from abuse.
Impact: Attackers can move laterally through trusted integrations, overextend access beyond the original business purpose, and make incident scoping slower because investigators cannot easily reconstruct which identity exercised which authority.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-3 — Content of Audit Records | Audit records must preserve subject, actor, and action across delegated access paths. |
| AC-6 — Least Privilege | Delegation and impersonation must stay narrowly scoped to avoid access overextension. | |
| IA-5 — Authenticator Management | Token exchange depends on managing token lifecycle, reuse, and revocation safely. | |
| Recommendation — Record original and impersonated identities in audit events. Limit delegated tokens to the minimum permissions needed. Set short lifetimes and revoke exposed delegated tokens quickly. | ||
Practitioner Guidance
What to verify: For every exchange or impersonation path, verify that the policy records the original subject, the acting principal, the target audience, and the reason the delegated action is allowed. If any one of those elements is missing from logs or token claims, treat the path as hard to govern even if it is technically functional.
What good looks like: A delegated flow should be narrowly scoped, short-lived, audience-bound, and attributable end to end. The best indicator of healthy governance is that an operator can reconstruct the full authority chain without inferring intent from application code or tribal knowledge.
Common mistake: Teams often celebrate token exchange as a least-privilege improvement and stop there. The better test is whether the exchange reduces standing privilege without creating unowned delegated paths that are harder to review, revoke, and explain after the fact.
Practitioner takeaway: Delegation is governable only when the authority chain remains explicit at every hop; if subject, audience, and accountability are not preserved together, the control that narrows access can also hide who really used it.