An MCP server threat model starts from one fact: the server sits between an AI client and real systems, so it inherits the trust of both. The main risks are confused deputy flows, token passthrough, SSRF, session hijacking and local server compromise. Each has a concrete control in the protocol's own security guidance.
What are you actually defending?
Draw three boxes: the MCP client (a chat app, IDE or agent), the MCP server, and the downstream API the server calls. Credentials and consent move across both seams. Most MCP incidents are failures at one of those seams, not flaws in the model.
The protocol's security best practices page lists the attack classes below. We follow its 2025-06-18 revision here. A newer revision may exist, so check the current text before you adopt a control verbatim.
Where does the confused deputy problem show up?
It appears when your server is a proxy to a third-party API, uses one static OAuth client ID with that provider, and lets clients register dynamically. The provider sets a consent cookie after the first login. An attacker then sends a crafted link with a new client registration and a malicious redirect. The cookie suppresses the consent screen and the authorization code goes to the attacker.
The fix is per-client consent kept on your side. Keep a registry of approved client IDs per user, show the client name, scopes and redirect URI, and match redirect URIs by exact string, never by pattern.
Why is token passthrough forbidden?
Passthrough means accepting a token from the client and forwarding it downstream without checking it was issued for your server. It defeats rate limits and audit trails, because downstream logs show the wrong caller. A stolen token can also use your server as an exfiltration proxy. The rule is short: accept only tokens issued for your MCP server, and check the audience.
What is the SSRF exposure?
MCP clients fetch URLs that a server controls during OAuth discovery. A hostile server can point those at internal addresses or a cloud metadata endpoint. If your client runs server-side, require HTTPS, block private and link-local ranges, validate every redirect hop, and route discovery through an egress proxy. The guidance warns against hand-rolled IP parsing, because octal and IPv4-mapped encodings slip past custom checks.
What goes wrong with sessions?
Session IDs are not authentication. The guidance says servers must verify every inbound request, must not use sessions for authentication, and should bind session IDs to user-specific data. In a multi-node setup with a shared event queue, an attacker holding a session ID can inject events that another node delivers to the real client.
What about local servers?
A local MCP server runs with the user's privileges. A poisoned startup command in a shared config can read SSH keys. Clients should show the exact command before running it, sandbox it, and prefer stdio or a restricted socket over an open localhost port.
How to check or apply this
- List every MCP server your teams connect to, local and remote, with an owner for each.
- For each proxy server, confirm per-client consent and exact redirect matching.
- Confirm tokens are audience-bound and none are passed through.
- Run server-side clients behind an egress proxy and test with a metadata-endpoint URL in a staging discovery document.
- Review local server configs in version control, and require explicit approval for new commands.
- Log tool calls with the user identity, not just the server identity.
Safeguard's MCP Guardrail is built for the last step, applying policy to what agents call. See the demo below.
Open the full demo at /demos/mcp-guardrail.
Quick check
Is a read-only MCP server safe by default?
No. Read-only still exposes data, and the seams above (consent, tokens, sessions) apply regardless of what the tools can write.
Who owns the consent screen in a proxy server?
The MCP server does. The third-party provider's consent cookie cannot stand in for per-client consent.
Sources
Last reviewed: 18 October 2026.
