Understanding Model Context Protocol Security Risks and How to Mitigate Them

What Is MCP and Why Does It Widen the Attack Surface?

This guide covers MCP security risks, key MCP vulnerabilities, and hardening best practices. It focuses on practical controls for teams deploying or approving integrations. The Model Context Protocol links an AI host, a client inside it, and MCP servers exposing tools, resources, and prompts. Users interact with this front end. The host is one of the AI applications. Each client maintains one connection to a server. It passes messages both ways. The client also forwards results. An LLM reads descriptions as context and selects tool calls.

This changes the threat model because the agent, not fixed code, chooses which function to run. A malicious description can steer that choice. A local process can inherit the user's permissions. A remote MCP server can rely on OAuth. Many components come from third parties. Anthropic introduced the protocol, yet each integration still needs verification. The interface is natural language, so classic API allow-lists do not fully transfer. Approval dialogs may show only a short label, while hidden instructions remain in the full definition. Audit teams must therefore treat every description, token, and local process as untrusted.

Risks that follow include poisoned definitions, indirect prompt injection, name shadowing, and confused deputy authorization failures. They include token passthrough, weak validation, local compromise, and command execution.

Top MCP Security Risks at a Glance

Before hardening, inventory the MCP security risks that turn an AI integration into an attacker path. A 2026 MCP threats study groups threats around malicious developer or user activity, outside adversaries, and privacy or protocol flaws. OWASP’s LLM-specific risk lists are a useful reference for these MCP vulnerabilities. The list below highlights what each issue is and what it enables.

• Tool poisoning: OWASP flags poisoned definitions as a protocol-specific risk, hiding instructions that make the model call dangerous actions.
• Indirect prompt injection: fetched content can steer the assistant, rewrite intent, and trigger unwanted operations without visible review.
• Tool shadowing: rogue MCP servers imitate trusted names, redefine approved actions, or replace expected behavior after approval.
• Confused deputy: authorization risks let a request reuse consent the user never gave, granting access to a third party.
• Token passthrough: OWASP ranks token mismanagement first, and a host that forwards foreign tokens breaks boundaries and audit trails.
• Weak validation: unchecked audience, issuer, expiry, or revocation status keeps stolen credentials usable across environments and downstream APIs.
• Over-broad OAuth scopes: excessive permissions turn one compromised integration into account takeover, data deletion, or silent exfiltration.
• Local compromise: tampered configuration files start MCP servers with user privileges, expanding these risks to SSH keys and cloud credentials.
• Command injection: unsanitized parameters enable arbitrary code execution on the host, especially when startup commands accept raw input.
• SSRF: crafted OAuth URLs or fetch tools can reach internal endpoints from MCP servers, exposing dashboards, metadata services, and APIs.
• Secret exposure: credentials in configs, environment dumps, or responses can leak sensitive data to outputs, traces, or third-party logs.
• Supply-chain and audit risks: untrusted MCP servers and missing audit trails hide abuse, delay incident response, and complicate forensics.

MCP Vulnerabilities Explained

Four vulnerability classes below cause most real-world incidents in MCP servers. Unlike classic API vulnerabilities, the model becomes the confused or manipulated actor, invoking tools from tool-call content that users cannot see. In AI applications, weak authorization can enable confused-deputy attacks documented by MCP-SafetyBench (2025), which catalogs 20 attack types.

Tool Poisoning, Prompt Injection and Tool Shadowing

An attacker can hide instructions in a description, returned output, or fetched page. The LLM may treat that text as user intent. This is indirect prompt injection.

With tool poisoning, those instructions sit in metadata exposed by MCP servers. A simple add_numbers function might secretly read a local credentials file and pass it as a parameter. In Cursor or Claude Code, the approval screen can still show only “add two numbers.” The impact is data exfiltration, unintended tool calls, or unauthorized actions.

Shadowing adds a name-collision risk. When several MCP servers are connected, a malicious one can register similar names and intercept tool calls meant for a trusted integration. A rug pull changes the text after approval. ShareLock splits one instruction into benign-looking secret shares across several descriptions. Malicious MCP servers can inject a hidden prompt during connection, before any request occurs. In the 2025 MCPTox study of 20 prominent LLM agents, o1-mini reached a 72.8% attack success rate for tool poisoning.

Pin descriptions, show the full text to users, require confirmation for sensitive operations, and give each integration a distinct namespace.

Confused Deputy and OAuth Authorization Failures

Confused deputy failures happen when MCP servers use one static OAuth client ID with a SaaS authorization server. A consent cookie can let a malicious site trigger a new request and reuse prior approval. The user does not approve the actual grant. An attacker can still obtain an authorization code and exchange it for an access token before revocation.

Authentication verifies identity. Authorization defines what the user allows a client to do. Relaying third-party OAuth APIs through MCP servers creates confused deputy exposure when validation is weak. An untrusted endpoint can return a crafted authorization URL. If the client follows it, the result can be SSRF or local command execution. Treat returned URLs as untrusted input.

For MCP servers, store consent for each user per client and per request. Require exact redirect URI matching, PKCE, state, and a distinct redirect URI for each issuer. Validate and restrict OAuth authorization URLs before opening them. Keep callback responses on encrypted connections only. Reject unexpected schemes and internal hosts to limit access.

Token Passthrough and Weak Token Validation

Token passthrough means MCP servers accept an OAuth token issued to another audience. They then forward it to a downstream API and violate authorization boundaries.

A resource server must refuse a request with a credential not meant for it. If the receiver skips issuer, audience, expiry, and scope checks, one stolen token can bypass rate limits and move across services. It can reach GitHub, AWS, or an internal SaaS tool. The downstream API sees a valid credential and trusts the request, even without real consent for that resource.

Weak storage and long-lived bearer tokens make the problem worse. Plaintext configuration files give attackers durable access and weaken the audit log. Sensitive data can leak through an unapproved path.

MCP servers must accept only credentials issued to themselves. They must not pass a received access token upstream. Validate every claim, use short-lived scopes, and keep authorization narrow. This secure baseline prevents stolen credentials from becoming universal keys.

Local MCP Server Compromise and Command Injection

Local MCP servers often start from a one-line README command pasted into configuration files. That shortcut feels efficient. The server then runs with your privileges, often with a static token in its environment. If a Python package is malicious or compromised, its startup logic runs first. It can read SSH keys, AWS credentials and repository contents before any tool is used.

Command injection appears when unsanitized parameters become shell arguments. A request that should list files can instead launch arbitrary code execution on the host. Exposed by Design (2026) found 687 tool instances across confirmed MCP servers with shell access and no access controls.

Malicious startup commands in configuration files create the same path. IDEs and coding assistants that parse MCP JSON can allow command injection inside a server definition. This can turn a trusted workflow into a launch path. If an HTTP endpoint binds to all interfaces, the attack surface grows. DNS rebinding can also reach localhost, so these MCP servers expose sensitive data beyond the intended host. The blast radius is full code execution under your account.

MCP Server Security Best Practices

Use these MCP server security best practices to secure MCP servers and secure tool access before connecting them to AI applications.

• Enforce least privilege. Grant the minimum file, API and sensitive data permissions needed for one task.
• Scope OAuth tokens. Use short-lived tokens with narrow scopes, and reject tokens issued for another service.
• Require per-client authorization. Store consent separately for each client, and re-check destructive actions.
• Validate inputs and tokens. Check issuer, audience, expiry and redirect URIs before trusting a request. MCP Under the Lens (2026) recommends mandating RFC 9207 issuer validation for MCP.
• Sandbox local MCP servers. Run them in containers or restricted accounts, with limited paths and no wildcard network access.
• Pin third-party code. Vet packages, freeze versions and review descriptions before approval.
• Confirm risky calls. Ask the user in Claude Code before deleting files, sending mail, changing SSH keys or spending AWS or SaaS resources.
• Keep secrets out of configuration files. Put credentials in environment variables or a secret manager.
• Bind local listeners to localhost. Do not expose a host service to all interfaces.
• Log decisions. Record the user, client, tool, parameters and outcome, and never store raw tokens.

Hardening should also secure the full lifecycle. Review all connected MCP servers before production. Pin approved tool descriptions, monitor for changes, and isolate each integration from the host network. MCPHunt (2026) found prompt-mitigation defenses reduced policy-violating propagation by up to 97% across three models while preserving 80.5% utility.

This configuration limits a filesystem server to one project directory:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "PROJECT_DIR"]
    }
  }
}

Replace PROJECT_DIR with the only allowed folder. Keep this file free of secrets.

When MCP servers include fetch or browser features, treat outbound traffic as untrusted egress. Separate it from internal infrastructure and from your corporate IP, because a proxy is not an MCP security control and cannot replace authorization or sandboxing. OnlineProxy provides mobile proxies on real 4G/5G carrier IPs through modems with real SIM cards. It supports HTTP and SOCKS5 with username/password authentication and is billed per port per period. See mobile proxies for AI agents as one routing option for such egress.

Monitoring, Auditability and Incident Response for MCP Servers

Weak auditability magnifies MCP security risks. Log each request with the user, client, MCP server, tool, parameters, token identifier, and authorization decision. Never log raw tokens. Forward structured events to a SIEM. Correlate them with identity, network, and cloud sources such as AWS CloudTrail. OWASP LLM guidance helps map related threats.

Alert on unusual tool calls. Also alert on new or changed descriptions. Watch calls to unexpected hosts. Treat each request as suspicious when access departs from approved workflows. Security monitoring should inspect agent-tool interactions for prompt injection, data exfiltration, or malicious execution. Approval attaches to a configuration at one moment. That configuration can drift after sign-off. The Model Context Protocol Threat Modeling and Analysis (2026) study recommends behavioral anomaly detection and metadata analysis.

MCP servers need continuous monitoring. Continuous evaluation of connections helps detect drift and policy violations early. For MCP servers, log first-seen tool calls and new client registrations. Alerts should also catch repeated failures. For incident response on affected MCP servers, revoke tokens, disable them, rotate secrets, review repeated tool calls, and check records for sensitive data exposure. Check the current specification and consent guidance before design reviews.

MCP Security FAQ

What are the top MCP vulnerabilities?

The highest-impact MCP vulnerabilities combine tool poisoning, confused deputy authorization flaws, token passthrough and local server compromise. Descriptions or fetched content can carry hidden instructions that the model executes. OAuth flows can reuse consent or accept tokens meant for another service. Local servers inherit user permissions. One malicious package or unsafe startup command can expose files, credentials and shell access. Review descriptions, pin versions and require confirmation for destructive operations. Treat every external tool as untrusted until scoped and logged. A 2026 study, Exposed by Design, found over 21,000 MCP server instances on the public internet.

What are the downsides of MCP?

The main trade-off is a wider attack surface. MCP makes tools and data reachable by an LLM. Weak registries, vague scopes and opaque tool calls matter more than in ordinary APIs. A registry analysis of 67,057 MCP servers found many could be hijacked because submission processes were not vetted. Authorization is also harder, and users often see limited detail before sensitive actions run. The benefit is real interoperability, but it requires isolation, review and consent controls. For private data, an NSA advisory recommends a local server over a third-party hosted one.

What are the top AI security risks beyond MCP?

Beyond MCP servers, the biggest AI risks start with prompt injection, where hostile text changes an LLM’s behavior. Sensitive data leakage is next. Systems can repeat training data, paste secrets into logs, or send private context to external services. Excessive agent permissions turn a compromised or confused model into an actor that can read, delete or exfiltrate resources. Supply-chain weaknesses add unsafe plugins, dependencies and datasets. OWASP LLM guidance is useful for prioritizing these issues, but each AI deployment needs its own threat model.

Conclusion: Treat MCP Servers as Untrusted by Default

Most MCP security risks arise when MCP servers, tool descriptions, tokens and local processes are trusted by default. These vulnerabilities let a manipulated model call tools, read sensitive data or execute actions the user never approved. To stay secure, apply least privilege, scoped OAuth tokens, proper authorization, runtime isolation, detailed logs, secret rotation and alerting for all AI applications. Audit every connected MCP server against the checklist above before you approve another tool, grant access, deploy to production or reuse credentials without review.