An MCP Access Token Is Not a Passport to Every Tool
An agent calls an MCP server with an access token. The token is validly signed and has not expired. Is that enough to execute the tool? No. The important question is who the token was issued for. A token intended for a different API is not authorization to use this MCP server, even if both services trust the same issuer.
The MCP authorization specification requires clients to include a resource indicator in authorization and token requests. It also requires MCP servers to validate that presented access tokens were issued specifically for them, and forbids servers from accepting or passing through other tokens. This is a protocol requirement, not a prompt-writing technique.
Where the boundary breaks
Consider a tool that looks up a customer record in a downstream API. An implementation might accept the client's bearer token and forward it verbatim to that API. This blurs two separate grants: permission for the client to call the MCP server, and permission for the server to call the downstream service. A request can appear authenticated while neither grant has been independently checked. The specification discusses both audience-validation failures and token passthrough as security risks.
An agent instruction such as “only use authorized tools” cannot tell whether a bearer token is scoped to the right audience. The server must validate the token before processing a request, and its downstream credential flow must be designed separately. Authorization also belongs on every HTTP request, not just at the start of a logical session.
A useful test, without live secrets
Use a test issuer and dummy resources. Obtain one token for the MCP server, one for a different resource, and one expired token. Send each to an instrumented read-only tool. The other-resource and expired tokens should receive an HTTP 401 before the tool handler runs. Confirm that the downstream stub sees neither the rejected tokens nor a verbatim copy of the accepted inbound token. Repeat on a later request in the same session.
Then test authorization inside the server: an audience-correct token still must not grant access to a customer record outside the caller's permitted scope. Authentication says which service should accept a token; it does not replace resource-level authorization.
If you are auditing a system prompt, BreakMyAgent's /scan can flag text-level gaps in a non-sensitive prompt. It cannot inspect token validation, execute MCP tools, or prove this test passed. Keep the decisive evidence in server-side rejection traces and stubbed tool calls.