What breaks when token exchange is allowed without tight issuer and audience controls?

How token exchange turns into an access-control problem

token exchange is supposed to translate one security context into another only when the requested audience, issuer, and delegation rules are tightly bounded. Once those boundaries loosen, the exchange service stops being a narrow translator and starts acting like a privilege broker. The practical question is not whether the original token is valid, but whether the new token is still constrained to the intended trust path.

That is why the control failure sits in policy scope. A gateway that accepts too many issuers or lets a token be exchanged for too many audiences can turn a legitimate credential into a broader authority than the caller should ever receive. Properly designed token exchange keeps the original proof useful without letting it silently widen into a new access path.

In standards terms, this is the same class of problem described in RFC 8693: OAuth 2.0 Token Exchange, where the exchange is meant to preserve delegation intent rather than erase it. Audience restriction is also central to RFC 8707: Resource Indicators for OAuth 2.0, which helps bind tokens to the intended resource instead of making them reusable everywhere.

Where issuer and audience controls fail in practice

The most common failure mode is trust overextension. If the exchange endpoint accepts tokens from issuers it does not strictly expect, or if it treats many audiences as interchangeable, then the caller can pivot from one accepted context into another. That is especially dangerous when the exchanged token is accepted by a downstream API or service with higher privilege, wider data access, or weaker secondary checks.

This is also where token exchange becomes adjacent to broader OAuth security guidance. RFC 9700: Best Current Practice for OAuth 2.0 Security emphasizes tightening token handling, while RFC 6749: The OAuth 2.0 Authorization Framework defines the baseline grant model that implementers often extend too loosely. When exchange is added on top, the issuer and audience checks must remain stricter than the base OAuth flow, not weaker.

In operational terms, the mistake is allowing the exchange policy to behave like a universal bridge. The more issuers, audiences, and downstream services you permit without explicit allowlisting, the more likely a valid token becomes a reusable escalation artifact instead of a constrained delegation proof.

What breaks for architects and responders when the policy is too broad

Once exchange can broaden authority, the blast radius changes. A token that was safe for one service can be converted into a token that reaches another service, another tenant, or another privilege tier. That breaks least-privilege assumptions, complicates incident response, and makes it harder to reason about where a token should and should not work.

For teams building agent, workload, or service-to-service paths, this problem is documented well in OAuth 2.0 and OpenID Connect Guide for Identity Teams and NHI Authentication Guide, both of which cover token-based authentication patterns that need strict audience handling. The point is not that token exchange is unsafe by default, but that its safety depends on preserving the original trust boundary all the way through the exchange chain.

Risk and Threat Considerations

When issuer and audience checks are loose, token exchange can become a privilege-escalation path rather than a delegation mechanism. An attacker who obtains any accepted token may be able to trade it for a different token that reaches a more sensitive service, creating lateral movement opportunities and widening the impact of a single compromise.

Failure mechanism: The exchange service trusts too many issuers or accepts overly broad audience values, so a token minted for one context can be converted into a token valid in another, more privileged context.

Impact: Policy scope expansion can expose downstream APIs, enable unauthorized access to higher-value resources, and make compromise harder to contain because the exchanged token appears legitimate to the target.

Practitioner Guidance

What to verify: Treat issuer and audience as hard authorization boundaries, not metadata. Confirm that each exchange rule is pinned to a narrowly defined issuer set, a single intended resource or audience family, and an explicit delegation use case.

Decision rule: If the exchange path can mint a token with broader reach than the original token had, it is too permissive and should be redesigned before you rely on it in production. If the downstream service would still accept the token without knowing the original caller’s narrow context, you have lost the control point.

Common mistake: Teams often validate the incoming token correctly and assume the exchange is therefore safe. In reality, the dangerous part is the policy that decides what the new token is allowed to become.

Practitioner takeaway: The exchange mechanism is only safe when it preserves, rather than expands, the original trust boundary; once exchange can widen audience or issuer trust, it stops being a translation layer and becomes an escalation layer.

Related resources from NHI Mgmt Group

• What breaks when agentic AI is allowed to remediate systems without tight controls?
• What breaks when GitHub Actions are allowed to authenticate without tight repository and branch controls?
• What breaks when parallel agents are allowed to scale without cost and quota controls?
• What breaks when AI agents can chain tools through MCP without tight policy controls?