Scopes limit what a token can do, but they do not say where that token may be used. Resource indicators add the destination boundary, which stops a narrow token from being replayed against the wrong MCP server. In multi-server agent workflows, that separation is essential for least privilege.
Why This Matters for Security Teams
OAuth scopes answer the question of what a token can do, but in mcp environment that is only half the control problem. Resource indicators add the destination boundary, which prevents a valid token from being replayed against the wrong server or tool endpoint. That distinction matters most when agents move across multiple MCP servers, because the same narrow permission can become unsafe if the audience is not fixed.
Current guidance from the OWASP Agentic AI Top 10 and the OWASP Non-Human Identity Top 10 is consistent on this point: agentic and non-human workloads need both capability limits and audience limits. NHIMG research also shows how often organisations lose visibility once OAuth is in play, with Astrix Security & CSA reporting that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps.
In practice, many security teams discover the gap only after a token meant for one MCP service is accepted by another and the blast radius becomes visible.
How It Works in Practice
In an MCP setup, scopes should be treated as the permission envelope and resource indicators as the audience lock. A client requests a token for a specific MCP resource, and the authorisation server binds that token to the intended server or API audience. At runtime, the MCP server checks both the scope and the resource indicator before honoring the request. That is what blocks replay across different servers, tenants, or tool chains.
This becomes especially important in agentic workflows, where an AI agent may chain tool calls, switch contexts, or request downstream access on the fly. The practical control pattern is to combine:
- short-lived tokens with explicit audience binding
- per-resource scopes, not broad cross-server scopes
- policy evaluation at request time, not just at token issuance
- server-side validation that rejects tokens without the expected resource indicator
The emerging best practice aligns with intent-aware authorisation: the agent should prove both what it is allowed to do and where it is allowed to do it. That is consistent with the direction signaled in the OWASP Agentic Applications Top 10 and with the operational lessons behind the Salesloft OAuth token breach, where token misuse showed how far valid credentials can travel once audience boundaries are weak.
These controls tend to break down in federated MCP ecosystems where older servers accept bearer tokens without checking audience binding because the authorization layer is not consistently enforced across services.
Common Variations and Edge Cases
Tighter audience binding often increases implementation overhead, requiring organisations to balance stronger containment against compatibility with older OAuth clients and mixed MCP servers. Best practice is evolving here, and there is no universal standard for every deployment model yet.
One common edge case is a single agent that legitimately needs access to several MCP resources. In that case, separate tokens for separate audiences are safer than one broadly scoped token. Another edge case is delegated workflows, where a gateway or broker exchanges tokens on behalf of an agent. The broker must preserve the original resource boundary rather than widening it for convenience.
Teams should also avoid assuming that scopes alone are sufficient just because the token is short-lived. A short TTL reduces exposure time, but it does not stop misuse inside the valid window if the token can be replayed to the wrong destination. For agentic systems, that distinction matters because tool chaining can create unexpected access paths faster than human review can intervene.
For background on the broader identity problem, NHIMG’s Ultimate Guide to NHIs – Key Challenges and Risks remains a useful reference point for why non-human credentials need both control strength and contextual limits.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Agentic systems need runtime boundaries beyond static scopes. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Token scope without audience control increases replay risk. |
| NIST AI RMF | Audience-bound authorization supports AI risk governance. |
Document agent access boundaries and evaluate them continuously against runtime context.
