Who is accountable when a token exchange policy allows excessive access?

Why This Matters for Security Teams

When a token exchange policy allows excessive access, the failure is not just a bad setting. It is a governance gap in how trust is granted, scoped, and reviewed at the gateway. Token exchange is often treated as a plumbing detail, but it becomes a high-risk control point because it can mint access that downstream services will accept as legitimate. Guidance from the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both point toward shared accountability for identity decisions, not blind reliance on service owners alone.

For NHI programs, this matters because exchanged tokens are often short-lived, highly privileged, and hard to spot once issued. If the exchange policy is too broad, the issue can spread across APIs, agent workflows, and backend services before anyone notices. That is why incidents like the Salesloft OAuth token breach and the Guide to the Secret Sprawl Challenge are so instructive: the blast radius is determined by trust design, not by the endpoint that eventually consumes the token. In practice, many security teams discover excessive exchange scope only after a token has already been reused beyond its intended boundary.

How It Works in Practice

Accountability should follow the control owner that defines the trust boundary and approves the exchange logic. In most environments, that is the team operating the gateway, broker, authorization service, or identity platform that performs token exchange. Downstream service owners still own their local authorization decisions, but they cannot be expected to compensate for an overly permissive upstream token minting rule.

Operationally, a sound review asks four questions:

• Who can request the exchange, and under what authenticated workload identity?
• What scopes, audiences, and claims are allowed to change during the exchange?
• Is access reduced to the minimum required for the task, or merely translated from one broad token to another?
• Is the policy evaluated at request time, with logging and review, or approved once and left to drift?

This is where NHI governance becomes concrete. The policy owner should enforce least privilege, short TTLs, and explicit audience restriction, then validate that exchanged tokens cannot inherit unnecessary upstream privileges. NHI programs also need evidence that the issuer trust model is reviewed regularly, because a trusted broker with weak scope rules is still a privilege escalation path. The Top 10 NHI Issues and the Ultimate Guide to NHIs both reinforce that the real control failure is usually in lifecycle governance, not in the consuming workload.

Where teams do this well, token exchange policies are versioned, reviewed like code, and tested against abuse cases such as privilege amplification, audience confusion, and token replay. These controls tend to break down when multiple platforms share one exchange broker but no single team owns the trust policy end to end.

Common Variations and Edge Cases

Tighter token exchange policy often increases operational overhead, requiring organisations to balance least privilege against release speed and service interoperability. That tradeoff is real, especially in microservice estates and agentic workflows where many callers need different scopes for different tasks.

There is no universal standard for every exchange pattern yet, so current guidance suggests treating the gateway as the decision authority and making exceptions explicit. For example, delegated user flows, workload-to-workload exchanges, and agent-mediated exchanges should not all inherit the same approval model. A service account used by an internal batch job is not the same risk as an AI agent that can chain tools and request new access dynamically.

Two edge cases deserve attention. First, if the broker issues tokens based on broad group membership or static roles, excessive access can persist even after local permissions are tightened. Second, if downstream services trust claims without checking audience or intent, the broker becomes only one part of the failure chain. That is why the exchange policy owner, the identity platform team, and the security governance function must all be able to explain who approved the scope model and when it was last reviewed. The most common real-world failure is not a missing owner, but an owner who assumes someone else is validating the trust boundary.

Related resources from NHI Mgmt Group

• Who is accountable when a DDoS outage disrupts customer access?
• Who is accountable when DNS weaknesses disrupt access to identity services?
• Who should be accountable for DNS access reviews?
• Who should be accountable for registrar access, DNS changes, and certificate renewal?