Security best practices

Security considerations, attack vectors and mitigations for MCP implementations.

Adapted from Security Best Practices. Read alongside the Authorization specification and OAuth 2.0 Security BCP.

Treat each server as a separate trust domain with its own consent and scopes.

Executive summary

MCP adds AI-specific risks on top of normal API security: confused-deputy OAuth proxies, token passthrough, tool-output prompt injection, and over-privileged local servers. Design consent, audiences and sandboxing explicitly.

Priority threats

Confused deputy (OAuth proxy)

When an MCP server proxies a third-party API with a static client ID, dynamic client registration, and third-party consent cookies, a malicious client may obtain authorization without proper per-user consent.

Mitigations:

• Per-client consent before forwarding to the third-party IdP
• Avoid cookie-only consent assumptions across MCP clients
• Prefer patterns that preserve user visibility of the true relying party

Token passthrough / confused tools

Do not forward end-user tokens to arbitrary upstreams without audience checks. Tools should use tokens minted for that resource.

Prompt injection via tool results

Tool output is untrusted content. Hosts must not treat retrieved text as system instructions. Separate “data from tools” from “instructions from the developer”.

Over-privileged local servers

Filesystem or shell tools with broad paths equal remote code execution risk under social engineering. Scope directories; require approval for writes.

Supply chain

Prefer Registry namespace authentication, pin package versions, and review server code before enterprise rollout.

Operational checklist

Decision checklist

• Remote servers require authn/authz + TLS
• Scopes are least-privilege and documented
• Tokens never logged or sent to the LLM
• Destructive tools require explicit user approval
• Tool output is sandboxed from system prompts
• Stdio servers do not run as root / admin by default
• Dependencies pinned; provenance reviewed
• Rate limits and timeouts on every tool handler

Negative cases (test these)

• Replay of stolen bearer tokens → short TTL + refresh + revocation
• Server returns HTML/script in tool text → host sanitises display
• User approves once, attacker reuses session for new client → bind consent to client identity
• “Read-only” tool that deletes via path traversal → validate and normalise paths

See the full upstream document for detailed attack diagrams and additional scenarios.

Key takeaways

• MCP security = classic API security + AI trust-boundary design.
• Consent and audience validation stop confused-deputy classes of bugs.
• Treat tool output as hostile until proven otherwise.

What to do next

Review Authorization and the official security best practices page in full before production.