MCP security risks are structural, not incidental. Learn how confused deputy attacks, token theft, prompt injection, and supply chain threats target MCP servers.
Anthropic introduced the Model Context Protocol (MCP) in November 2024 as an open standard to connect AI assistants to external tools and services. The pitch was simple: a universal connector for LLMs, sometimes described as a "USB-C port for AI applications." Adoption followed fast. In a PwC survey of 300 executives, 88% said their team plans to increase AI-related budgets in the next 12 months due to agentic AI.
The problem is that MCP was designed for connectivity, not containment. The same trust model that makes it useful (one server, many tokens, natural language as the command interface) is what makes each integration a lateral movement path. Adding an MCP server is not adding a tool. It is expanding an authorization boundary that most security tooling cannot yet see.
This article maps the structural MCP security risks in the protocol and what to do about each one.
MCP follows a client-server architecture distributed across three entities: hosts, clients, and servers. A host (like an AI coding assistant or chat interface) communicates with multiple MCP clients, each establishing a one-to-one connection with a corresponding MCP server. Those servers connect outward to databases, APIs, file systems, and cloud services.
Every new connection between an AI assistant and an MCP server expands the trust boundary. These connections carry prompts, tokens, configurations, and executable schemas. Each element becomes a potential entry point.
Most developers think about MCP in terms of what it enables: connecting their assistant to Slack, GitHub, a database. The MCP security framing requires thinking about what each connection exposes. A server that reads your email also holds a token that can send email. A server that queries your database also has credentials that can write to it. The capabilities are bidirectional, and the trust is transitive.
The confused deputy problem is a classic privilege escalation pattern, and MCP is structurally prone to it.
When an MCP server performs an action triggered by a user's request, it should execute with the user's permissions. But as Red Hat's analysis notes, this is not guaranteed and depends entirely on the implementation. If implemented incorrectly, a user could gain access to resources available to the MCP server but not to them, violating least privilege.
The OAuth layer makes this worse. The official MCP security documentation describes how an attacker can steal an OAuth authorization code by exploiting static client IDs, dynamic client registration, and consent cookies in an MCP proxy server. The attack chain works like this: a malicious client registers with the same static client ID as a legitimate one, inherits existing consent cookies, and intercepts the authorization code during the OAuth flow. The attacker then exchanges that stolen code for access tokens and gains access to the third-party API as the compromised user, without the user ever approving the request.
The MCP community has identified that the current authorization specification includes implementation details that conflict with modern enterprise practices, and efforts to update it are underway. Until those land, the default OAuth behavior in many MCP servers is a confused deputy waiting to happen.
A compromised MCP server is not a single-service breach. MCP servers typically store authentication tokens for multiple services. Breach one, and an attacker gains access to all connected service tokens (Gmail, Google Drive, Calendar), the ability to execute actions across all of those services, potential access to corporate resources if work accounts are connected, and persistent access that may survive password changes since OAuth tokens often remain valid independently.
This creates a "keys to the kingdom" scenario where compromising a single MCP server grants broad access to a user's digital life or an organization's resources.
Detection is the second problem. Unlike traditional account compromises that trigger suspicious login notifications, using a stolen token through MCP may appear as legitimate API access. The requests come from expected IP ranges, use valid tokens, and follow normal API patterns. Security teams looking for anomalous logins will not find them, because from the API provider's perspective nothing anomalous happened.
If your LLM security model stops at the model layer, token theft through MCP servers sits in a blind spot.
Prompt injection through MCP collapses the boundary between reading data and taking action.
An attacker crafts a malicious message containing hidden instructions. It appears harmless to users but contains embedded commands. When the user shares this content with their AI assistant, the injected commands trigger unauthorized MCP actions. A seemingly innocent email could contain text that, when processed by the AI, instructs it to forward financial documents to an external address.
This is dangerous because traditional security boundaries between viewing content and executing actions become blurred. Users do not realize that sharing certain content with their AI could trigger automated actions through MCP.
The adversarial case gets the attention, but the non-adversarial case matters too. Red Hat points out that even if a user doesn't intend a specific action, the LLM might decide it's the appropriate one. An LLM connected to an MCP server with file deletion capabilities might interpret "clean up this project" more literally than intended. No attacker required. The risk is baked into the interaction model where natural language drives tool execution.
Robust AI guardrails become essential when the command interface is human language and the execution surface is every connected service.
Local MCP servers that execute OS-level commands carry a familiar vulnerability: command injection.
Depending on how the MCP client passes information to the server and how the server is implemented, command execution functionality may be vulnerable to command injection. If user-supplied input reaches a subprocess call without sanitization, an attacker (or a prompt-injected LLM) can chain arbitrary commands.
Consider a local MCP server that runs git commands. If the branch name parameter is passed unsanitized to a shell call, an input like main; rm -rf / executes both commands. The pattern is decades old. What is new is the attack surface: the input no longer comes from a web form or CLI argument. It comes from an LLM interpreting natural language, which makes the injection vector harder to predict and harder to validate.
The mitigation is also familiar: run local MCP servers in a sandbox so they are only capable of executing and accessing what they are explicitly allowed to. Container isolation, restricted filesystem access, and explicit allowlists for executable commands.
The MCP package ecosystem on npm, PyPI, and GitHub has no gatekeeping mechanism, and attackers have noticed.
Some MCP servers and tools are intentionally created with malicious intent. These artifacts are designed to appear trustworthy but crafted to exfiltrate data, escalate privileges, or manipulate context once integrated into AI systems. They exploit the trust users place in protocol-compliant services.
Rug pull attacks add a time dimension. A legitimate-looking MCP server establishes trust through normal operation, then receives a malicious update. MCP servers load schemas, configuration files, and runtime logic from external sources, creating opportunities for downstream compromise through tool poisoning, rug pull attacks, schema tampering, or malicious dependency updates. A single compromised element can propagate through multiple layers of the ecosystem.
This is not hypothetical. The pattern mirrors what happened with the LiteLLM supply chain attack, where a compromised upstream dependency cascaded through the AI infrastructure stack. MCP's architecture, where servers pull in third-party schemas and runtime logic dynamically, makes the propagation surface even wider.
Securing this ecosystem demands traditional application security rigor, supply chain vigilance, and AI-aware threat modeling all at once. No single control covers the attack surface. Here is what maps to each threat:
Sign and scan every MCP component. MCP components must be signed by the developer so users can verify integrity. Build pipelines should implement Static Application Security Testing (SAST) and Software Composition Analysis (SCA) to identify vulnerabilities in both your code and its dependencies. This is the supply chain defense.
Implement per-client consent in OAuth proxy flows. MCP proxy servers acting as OAuth clients must maintain a registry of approved client IDs per user, check this registry before initiating third-party authorization flows, and store consent decisions securely in a server-side database or server-specific cookies. This blocks the confused deputy attack chain.
Validate redirect URIs with exact string matching. The MCP security specification requires rejecting requests if the redirect URI has changed without re-registration, using exact string matching rather than pattern matching or wildcards. Pattern-based matching is what allows authorization code interception.
Use cryptographically secure OAuth state parameters. This prevents cross-site request forgery in the OAuth flow and is a baseline requirement in the MCP security best practices.
Sandbox local MCP servers. Run them in containers with restricted capabilities so that even a successful command injection cannot reach the broader filesystem or network.
Sanitize all inputs before subprocess calls. This applies to every local MCP server that executes OS commands. Double-check what commands will be executed and treat every input from the LLM as untrusted, because it is.
The broader MCP security posture requires understanding that each of these security threat layers compounds. A prompt injection that triggers a confused deputy on a server with unsandboxed command execution and valid tokens for six services is not three separate risks. It is one kill chain.