The resource identifier should be as narrow and network-verifiable as the protected service and tenant boundary require.
Why this question matters
RFC 8707 lets a client tell the authorization server which protected resource will receive the token. Audience restriction limits lateral use if a token leaks. MCP requires clients to include the resource in authorization and token requests and servers to validate the resulting audience.
Granularity matters. A host-wide resource may be too broad when paths identify separate tenants or services. Multiple audiences also create trust between resources because any valid recipient may be able to reuse the token at another.
Signals worth observing
- Tokens use a generic audience across unrelated tools.
- Tenant identity exists only inside mutable request arguments.
- One authorization request asks for several resource audiences by default.
Practical control direction
- Use canonical, specific resource URIs.
- Prefer one audience per token wherever feasible.
- Reject mismatched or missing resource context before tool execution.
AgentCollusion lensResource-bound credentials reduce the authority that cooperating or compromised agents can pool.Sources and further reading
Next field note: Tool Descriptions Are Part of the Attack Surface
