The most common MCP security mistakes are granting broad scopes up front, passing client tokens through to downstream APIs, skipping per-client consent, trusting tool metadata, running local servers without review, leaving out human approval and not logging tool use. Each has a fix in the official spec.
Mistake 1: Asking for every scope at once
The MCP security best practices page says poor scope design raises the damage from a stolen token. Its common mistakes include publishing every scope in scopes_supported, using wildcard scopes such as * or full-access, and returning the whole catalog in each challenge.
The fix is a small starting scope for read and discovery, then a targeted request for more when a privileged tool is first used. Log each elevation.
Mistake 2: Token passthrough
Token passthrough means a server accepts a token from a client without checking it was issued to that server, then forwards it downstream. The spec forbids this. It breaks rate limits and monitoring that depend on token audience, it muddles audit trails, and it lets a stolen token use your server as a proxy.
The rule is short: accept only tokens issued for your MCP server.
Mistake 3: Proxy servers that skip per-client consent
A proxy that uses one static client ID with a third-party authorization server, allows dynamic client registration and relies on a consent cookie can be tricked into sending an authorization code to an attacker. That is the confused deputy problem.
The fix is consent owned by the MCP server for each registered client, exact redirect URI matching with no wildcards, and a state value checked at the callback.
Mistake 4: Trusting what a tool says about itself
Tool names, descriptions and annotations come from the server. The tools spec says clients must treat annotations as untrusted unless they come from a trusted server. A description that claims a tool is read-only proves nothing.
Review the exact tool list from any new server, and watch for list-changed notifications that add tools you never approved.
Mistake 5: Running local servers like any other package
Local servers run with your privileges. The spec lists attack routes: a malicious startup command in shared client configuration, a malicious payload inside the server and a server left on localhost that is reachable by DNS rebinding.
Show the full command before first run, prefer the stdio transport, require a token if you use HTTP, and sandbox the process with limited file and network access.
Mistake 6: No human in the loop for sensitive actions
The tools spec says there should always be a human who can deny tool calls, and clients should show tool inputs before sending them. A model deciding alone to call a delete or send tool is a design choice, and teams often make it by default without noticing.
Split tools into read and write, and require approval for write.
Mistake 7: Not logging tool use
The spec tells clients to log tool usage for audit and servers to rate limit and sanitize outputs. Without logs you cannot tell what an agent did after a bad prompt reached it.
What to do
- Inventory every MCP server your team connects to, local and remote, with an owner for each.
- Cut scopes to the least needed and remove wildcard scopes.
- Reject any token not issued for your own server, and test that this holds.
- Require approval for any tool that writes, sends or deletes.
- Pin the tool list per server and review changes.
- Run local servers in a sandbox and read their startup command first.
- Log every tool call with user, tool, inputs and result status.
The Safeguard MCP server at mcp.safeguard.sh is built for reading security data from agents, and tool calls are unlimited on every plan. Tenant admins can also switch off any client type, which is a handy kill switch when you are reviewing which clients are connected.
Quick check
What is the confused deputy problem in MCP?
A proxy server holds authority with a third-party API and can be tricked into using it for an attacker, because a consent cookie from an earlier approval lets a malicious client skip the consent screen.
Should tool annotations be trusted?
No. The spec says clients must treat them as untrusted unless the server is trusted.
Sources
- MCP security best practices, fetched 18 October 2026
- MCP tools specification, fetched 18 October 2026
Last reviewed: 18 October 2026.
