Ask an MCP server vendor whether it accepts only tokens issued for itself, how narrow its default scopes are, whether it shows a consent page for each client, how it handles sessions, and what logs you can read. These map directly to risks the protocol's own security guidance names.
The questions, with the reason for each
| Question | Why it matters |
|---|---|
| Do you accept only tokens issued to your server? | The guidance forbids token passthrough, which weakens audit trails and bypasses downstream controls |
| What scopes does a new connection request? | Broad scopes enlarge the damage of a stolen token |
| Can scopes be elevated on demand? | The guidance recommends a minimal start and targeted elevation |
| Do you show a consent page naming the client and scopes? | A proxy that skips per-client consent can be abused through a confused deputy attack |
| How are redirect addresses validated? | Exact matching prevents code theft by a registered attacker address |
| Are sessions used for authentication? | The guidance says servers must not use sessions for authentication |
| What do your logs show? | You need to see which tools were called and for whom |
Reading the answers
Tokens. A good answer is specific: the server checks the audience claim, rejects tokens meant for other services and exchanges credentials with downstream APIs separately. A vague answer such as "we use OAuth" tells you little.
Scopes. Look for a short default list of read oriented scopes and a clear route to ask for more. Be wary of wildcard names such as full access.
Consent. If the server fronts another service, you want its own consent page that names the requesting client, the third party scopes and the redirect address.
Sessions. Session identifiers should be random and tied to the user. A server that trusts a session ID alone is exposed if the ID leaks.
Logs. Ask for a sample. Useful logs record the caller, the tool, the arguments and the outcome, and you can export them.
Questions about the vendor, not just the protocol
- Who operates the server and where is data processed?
- Is any of your data used for training or retained?
- How are vulnerabilities in the server reported and fixed? See patch timelines to ask for.
- Is there a way to revoke access fast and see what was reachable?
What to do with the results
Record the answers in your vendor register and give the server a tier based on the tools it exposes. A server that can only read public documentation sits low. One that can write to your repositories or send messages sits high. For the connection side of the decision, see whether a third party MCP server is safe to connect.
Quick check
What is token passthrough?
It is when an MCP server accepts a token that was not issued to it and forwards it to a downstream API. The security guidance forbids it because it undermines controls and audit trails.
Why do broad scopes matter if the server is trusted?
Tokens can leak through logs or local access. A narrow token limits what an attacker can do with a leaked one.
Safeguard includes an MCP Guardrail and agent identity to govern agent tool use, and a free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
