Risk & Safety Controls

Common attack vectors

Attack	Description	Primary mitigation
Prompt injection	Malicious instructions embedded in content (web pages, docs, tool results, injected notifications) that the model then follows	Treat all external content as untrusted; consent gates on consequential actions; output filtering
Tool poisoning	Malicious instructions hidden in a tool’s description/schema that manipulate the model — tool descriptions are untrusted unless from a trusted server	Review/pin tool definitions; show full descriptions to users; registry vetting
Rug pull	A server changes its tool definitions after initial approval	Re-prompt consent when definitions change; pin versions
Confused deputy	An MCP proxy server using a static client ID with a third-party authorization server is tricked into forwarding authorization for an attacker (consent-cookie skip)	Per-client user consent before forwarding; exact redirect URI validation; single-use state values
Token passthrough	A server accepts tokens not issued to it and forwards them downstream — an explicitly forbidden anti-pattern	Servers MUST NOT accept tokens that were not explicitly issued for them; audience validation (RFC 8707)
Token theft	Stolen access or refresh tokens grant access to downstream APIs	Secure token storage; short-lived access tokens; refresh token rotation for public clients
Session / state-handle hijacking	An attacker guesses or reuses a session ID (legacy) or state handle to inject events or impersonate a user	Never use sessions/handles as authentication; secure non-deterministic IDs; bind them to the verified user
SSRF via discovery	A malicious server points OAuth discovery URLs at internal or cloud-metadata addresses (e.g. 169.254.169.254)	Enforce HTTPS; block private/link-local IP ranges; validate redirect targets; egress proxies
Local server compromise	One-click install flows run malicious local server commands	Show the exact command and require explicit approval; sandbox local servers; prefer stdio locally
Excessive permission scope	Server requests broader access than needed	Least privilege; incremental step-up scopes; read-only credentials
Supply chain	Malicious or compromised server packages	Install from trusted registries; verify publishers; sandbox local servers
Data exfiltration	Sensitive context leaked through tool arguments or other server interactions	Minimize context sent to servers; egress controls; DLP monitoring

Session hijacking vs. state-handle hijacking

The session hijacking guidance applies to spec revisions 2025-11-25 and earlier, which had protocol-level sessions. In the stateless 2026-07-28 revision it is replaced by state-handle hijacking, with the same core rules: possession of a handle MUST NOT be treated as authentication, and handles should be securely random and bound server-side to the authenticated user.

The confused deputy attack, step by step

sequenceDiagram
participant U as User
participant P as MCP proxy (static client ID)
participant AS as Third-party auth server
participant A as Attacker
U->>P: Legitimate first use
P->>AS: Authorization request
AS->>U: Consent screen (approved, cookie set)
A->>U: Crafted link (malicious redirect_uri)
U->>AS: Follows link — cookie skips consent
AS->>A: Authorization code delivered to attacker
A->>P: Exchanges code, impersonates user

Confused deputy via consent-cookie skip

The mitigation the spec requires: proxy servers using static client IDs MUST obtain user consent for each dynamically registered client before forwarding to the third-party authorization server.

Safety controls checklist

• Human-in-the-loop approval for destructive or irreversible actions — users should always be able to deny a tool invocation
• Input validation on the server (schema validation, sanitization, path traversal checks)
• Sandboxing local servers (containers, restricted users, no unnecessary network)
• Rate limiting on tools and log output
• Version pinning of server packages and re-consent on definition changes
• Token hygiene — audience-bound tokens, short lifetimes, no passthrough, tokens never in URL query strings
• Safe URL handling — clients only open http(s) authorization URLs, never javascript:, data:, or file: schemes, and never via shell commands

Defense in depth

No single control suffices. A robust deployment combines: vetted servers (supply chain) + least privilege (blast radius) + consent gates (authorization) + monitoring (detection) + audit logs (forensics).

Key exam points

• Prompt injection and tool poisoning both exploit the fact that the model follows text — descriptions and content are attack surfaces
• “Rug pull” specifically refers to post-approval changes in tool definitions
• Token passthrough is an explicit anti-pattern: servers MUST NOT accept tokens not issued for them; downstream calls use the server’s own separately obtained token
• Confused deputy in MCP targets proxy servers with static client IDs; the fix is per-client user consent plus strict redirect URI and state validation
• Sessions and state handles are never a substitute for authentication

Check your knowledge

📝 Check your knowledge

1. A server accepts a token that was issued for a different service and forwards it to a downstream API. What is this called?

AConfused deputyBToken passthroughCRug pullDSession hijacking

2. Which setup is the target of the confused deputy attack described in the MCP security best practices?

AA local stdio server with filesystem accessBAn MCP proxy server using a static client ID with a third-party authorization serverCA client that stores refresh tokens in plaintextDA registry hosting unvetted server packages

3. A previously approved server silently changes its tool definitions to include malicious instructions. This is best described as:

APrompt injectionBSSRFCA rug pullDToken theft

4. Under the stateless 2026-07-28 revision, what replaces the session hijacking guidance?

ANothing — the attack is no longer possibleBState-handle hijacking: handles must not be treated as authentication and should be bound to the verified userCMandatory Mcp-Session-Id headersDSSE stream resumability rules

5. How can a malicious server trigger SSRF against a client?

ABy sending oversized tool resultsBBy pointing OAuth discovery URLs at internal or cloud-metadata addressesCBy registering a duplicate tool nameDBy emitting log notifications too frequently

6. Why are tool descriptions considered an attack surface (tool poisoning)?

AThey are executed as code by the hostBThe model reads and follows them, and they are untrusted unless they come from a trusted serverCThey contain OAuth tokensDThey bypass JSON-RPC validation