A buyer should expect security tooling to help spot MCP servers that accept tokens not issued for them, forward received tokens to other APIs, or place tokens in URL query strings. These are the points the MCP authorization text marks as must or must not. Ask a vendor which of them it can surface.
What the specification says
The MCP authorization section of the 2025-06-18 specification states that access tokens must not be included in the URI query string. It says MCP servers must validate that tokens were issued specifically for them as the intended audience. It says clients must not send tokens to an MCP server other than ones issued by that server's authorization server, and that servers must not accept or pass on any other tokens.
It also describes the confused deputy problem, where an MCP server acting as an intermediary to a third party API can be abused. Token passthrough is the named failure: the server forwards a token it received unmodified to a downstream service.
You are not expected to audit every server by hand. You are expected to know which servers you use and to ask whether tooling helps.
Four checks to ask about
| Check | What it looks for | How you might verify |
|---|---|---|
| Audience validation | Server rejects tokens issued for another service | Test server given a token for a different audience |
| No passthrough | Server uses its own token upstream | Review code or vendor statement for the server |
| No tokens in URLs | Tokens sent in headers only | Inspect requests from a test client |
| Scope minimization | Tokens carry only needed scopes | Read the scopes the server requests |
Some of these are checks of the server, which only its authors or a careful reviewer can confirm. Tooling can help most with inventory, configuration review and change detection. Be honest in scoring: a tool that tells you which servers are in use has done half the job even if it cannot test audience handling.
Questions for the vendor
- Can the tool list remote MCP servers in use, with their URLs and the scopes they request?
- Does it flag servers that request broad scopes?
- Can it warn when a server configuration places credentials in a URL?
- What does it say about servers it cannot assess, and how is that shown?
- Is there a record when a server is approved?
Question four is the best signal of maturity. "Unknown" is a valid state.
Pair tooling with process
Add a short onboarding checklist for every new remote server: who owns it, what scopes it needs, whether the publisher states how it validates audience, and who approved it. Our posts on MCP token audience and resource indicators and token passthrough cover the concepts.
Try it yourself
Open the demo to see how an MCP server is registered. Look for the point where scopes and approvals would be captured.
Click through it at your own pace, or open it full screen.
Safeguard offers MCP Guardrail, asset discovery and agent identity. Check what each covers against the four checks above before relying on any tool, ours included. The free scan is at gold.safeguard.sh/scan.
Quick check
Do local MCP servers need the same authorization checks?
The authorization section is aimed at HTTP based transports. Local servers raise different questions, mainly what files and commands they can reach.
Can a scanner prove a server validates audience?
Rarely from outside. It can show configuration and change. Proof usually needs a test or the publisher's documentation.
Sources
Last reviewed: 19 October 2026.
