MCP Security Best Practices
The Model Context Protocol's own security guide: the attacks that matter for MCP clients and servers (confused deputy, token passthrough, SSRF during OAuth discovery, state handle hijacking, local server compromise, over-broad scopes) and the mitigations the specification expects. The page to read before you install, build or review an MCP server.
Guide
AI & Machine Learning
Model Context Protocol
Two hours to read carefully
Intermediate
Free
What this guide is
The Model Context Protocol (MCP) is the common way to connect tools and data sources to AI models. Alongside the protocol specification, the MCP project publishes a security best practices page. It is written for people who build MCP clients and servers, people who run servers, and security engineers who review MCP-based systems, and it is meant to be read next to the MCP authorisation specification and the OAuth security best practices.
It is a living page that follows the specification. Recent revisions made MCP stateless, so the old advice about protocol sessions now lives in the page for the 2025-11-25 version, and the current page talks about state handles instead. Always check which revision your SDK speaks.
What it covers
Each section describes an attack, the conditions that make it possible and the mitigation the specification expects:
- Confused deputy: an MCP proxy server that uses one static OAuth client ID with a third-party API can be tricked into handing an authorisation code to an attacker when consent is skipped. The fix is per-client consent on the MCP server itself, exact redirect URI matching and a properly validated
stateparameter. - Token passthrough: a server that accepts tokens not issued for it and forwards them downstream. The rule is simple: an MCP server must not accept tokens that were not issued for it.
- Server-side request forgery (SSRF): a malicious server can point a client's OAuth discovery at internal addresses or cloud metadata endpoints. Mitigations include HTTPS only, blocking private IP ranges and egress proxies.
- State handle hijacking: possession of a cart or workflow ID is not authentication; bind handles to the verified user.
- Local MCP server compromise: a local server is a program running with your permissions. Clients must show the exact command and ask for consent, and should sandbox servers.
- Authorisation URL validation, mix-up attacks and localhost redirect impersonation for client authors.
- Scope minimisation: start with a small set of scopes and ask for more only when a privileged tool is first used.
Is it worth your time?
Yes, for anyone on the AI security path. Agent and tool security is where AI risk turns into real actions, and this page is the most authoritative short source on MCP specifically. Several of the attacks are classic web and OAuth problems in a new setting, so it also connects AI security to ordinary AppSec.
How to use it well
- Read it once end to end, then again with one real MCP server open and check each mitigation.
- Turn each section into a review question for any server you install: what can it run, what tokens does it accept, where can it connect?
- Pair it with the MCP Inspector to see what a server actually exposes.
Free or paid?
Free, part of the open MCP documentation.
Ready to start?
Opens on Model Context Protocol in a new tab.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.