MCP server security: the core risks, explained

The Model Context Protocol (MCP) is an open, vendor-neutral protocol that lets AI applications connect to external data sources, tools and workflows through a single standardized interface rather than a custom integration per connector. The official site's own analogy: "MCP is like a USB-C port for AI applications" — a single standard connector instead of a separate cable for every device. Anthropic introduced MCP on 25 November 2024 and open-sourced it; the official docs now list support across Claude, ChatGPT, Visual Studio Code, Cursor and other AI applications and development tools. Any AI application, device or product that lets an AI agent reach outside tools or data through an MCP server inherits MCP's security model, and that model has grown a detailed, versioned set of documented attack classes as the protocol has matured — the subject of this guide.

Hosts, clients and servers

MCP's own architecture documentation defines three participants. The host is the AI application that coordinates one or more connections — Claude Code or a code editor extension, for example. For each server it connects to, the host creates a dedicated client, which "maintains a dedicated connection with its corresponding MCP server." The server itself is "a program that provides context to MCP clients," and can run locally (typically over the stdio transport, talking to one client) or remotely (typically over Streamable HTTP, able to serve many clients at once). The distinction matters for security: a local server runs with the same privileges as the client process on the user's machine, while a remote server is reached over the network and authenticated more like a conventional web API.

A server can expose three primitives to a client, per the specification:

Primitive	What it is
Tools	"Executable functions that AI applications can invoke to perform actions"
Resources	"Data sources that provide contextual information to AI applications"
Prompts	"Reusable templates that help structure interactions with language models"

Tools are the primitive with the sharpest security edge: the specification states plainly that "tools represent arbitrary code execution and must be treated with appropriate caution," that tool-behavior descriptions "should be considered untrusted, unless obtained from a trusted server," and that hosts "must obtain explicit user consent before invoking any tool."

The protocol's own security principles

MCP's specification dedicates a "Security and Trust & Safety" section to three stated principles: User Consent and Control ("users must explicitly consent to and understand all data access and operations"), Data Privacy ("hosts must obtain explicit user consent before exposing user data to servers" and "must not transmit resource data elsewhere without user consent"), and Tool Safety (as above). Notably, the specification is explicit that these are design-level principles the protocol cannot itself enforce: "while MCP itself cannot enforce these security principles at the protocol level," implementors SHOULD build consent and authorization flows, document security implications, and apply access controls themselves. Security in MCP is therefore mostly an implementation responsibility, not something guaranteed by using the protocol.

Documented attack classes

MCP's official Security Best Practices page — which the protocol's own authors describe as "complementing the MCP Authorization specification" — documents several named attack classes, each with a specific, often MUST-level mitigation:

Attack class	What goes wrong	Core mitigation
Confused deputy	An MCP proxy using a static third-party OAuth client ID lets an attacker skip user consent via a leftover consent cookie	Proxy servers MUST implement per-client consent, checked before forwarding to the third-party authorization server
Token passthrough	A server accepts a token not issued for it and forwards it downstream unvalidated, which can itself trigger the confused-deputy problem	Servers MUST NOT accept any token that was not explicitly issued for that server
Server-Side Request Forgery (SSRF)	A malicious server supplies OAuth-discovery URLs pointing at internal IPs or cloud metadata endpoints	Clients SHOULD enforce HTTPS and block private/link-local IP ranges when following discovery URLs
State handle hijacking	An attacker guesses or steals an application-level state handle on MCP's stateless protocol and reuses another user's state	Servers MUST bind handles to the authenticated user server-side; possession of a handle is never treated as authentication
Local MCP server compromise	A malicious startup command or payload runs with the client's full privileges on the user's own machine	Clients MUST show an explicit, untruncated consent dialog before running a new local server, plus sandboxing
OAuth authorization URL validation	An unvalidated javascript: or shell-interpretable URL from a malicious server causes XSS or remote code execution	Clients MUST allow-list only http(s):// schemes and MUST NOT open URLs via a shell
Scope minimization	An over-broad, upfront token increases blast radius and audit noise if leaked	Clients and servers SHOULD use progressive, least-privilege scopes with step-up authorization rather than one omnibus grant

This list is not exhaustive — the same page also covers mix-up attacks between multiple authorization servers and localhost redirect-URI impersonation for native clients — but it covers the attack classes most relevant to anyone standing up or integrating an MCP server today.

A workable starting point

1. Treat every tool description as untrusted input unless it comes from a server you have independently vetted — a tool's name and description are exactly as trustworthy as the server that supplied them, and MCP's own spec says so directly.
2. Never forward a token you didn't validate was issued for you. Token passthrough is the single mitigation MCP's own guidance states unconditionally (MUST NOT), because it undermines every downstream security control at once.
3. Sandbox local servers by default. A locally-run MCP server executes with the client's own privileges; require explicit, fully visible consent before launching one, and restrict its filesystem and network access where the client supports it.
4. Re-check the live specification before shipping. MCP is a young, fast-moving protocol — this guide cites protocol revision 2026-07-28; confirm which revision your SDK and servers implement, since security-relevant behavior (such as session versus state-handle semantics) has already changed between revisions.

SoftWSP's device and firmware assessments can factor in an embedded AI agent or MCP integration alongside conventional firmware and application risk: see device firmware security.

This guide summarises public Model Context Protocol and Anthropic publications as checked on 28 October 2026 (protocol revision 2026-07-28); it does not constitute security or compliance advice.