---

--- title: "Understanding the security landscape of MCP" description: "This article dives deep into the current state of MCP security in 2025, covering real-world vulnerabilities like prompt injection, tool poisoning, and token exposure. You’ll learn about the biggest threats facing MCP implementations today, including exploits seen in GitHub, Supabase, and others—plus what the new OAuth 2.0-based security spec is doing to address them." author: "Saurabh Rai" published: "2025-08-04T00:00+03:00" updated: "2025-08-04T16:58:20.569Z" url: "https://www.apideck.com/blog/understanding-the-security-landscape-of-mcp" tags: ["AI", "Industry insights"] --- # Understanding the security landscape of MCP # The State of MCP Security in 2025: Key Challenges and Emerging Defenses Model Context Protocol (MCP) is becoming the standard for communication and operation between external applications, LLMs, and AI agents. Think of it like USB-C, a standard and a protocol for communication and power transfer. MCPs are also a standard for communication between large language models (LLMs) and other applications, databases, etc. It hasn’t been a year (MCP was introduced in November 2024), and the adoption of the protocol has been great so far. We are seeing a wide adoption from giant corporations like Atlassian, AWS, Google, GitHub, Cloudflare, and Supabase. etc., they all have their MCPs available to try and download. And more enterprises are looking forward to being more AI-ready by building MCPs for their LLM stack. As of January 2025, more than [1000 community-made MCPs](https://www.pulsemcp.com/servers) are available for end-users to try. Model Context Protocol is becoming the standard for enabling data in apps to communicate with LLMs. While the hype and adoption are going great, we also need to consider the security, vulnerability, and other issues associated with MCPs. While APIs have been around for more than a decade, we’ve developed security patterns, rate-limiting, and other measures. MCPs must undergo cycles of improvement on the security front. The current goal is to discuss security issues in MCPs and raise awareness among readers. ### The Core Security Challenge: The "Confused Deputy" Problem The confused deputy is a classic security flaw that is highly relevant to MCP. An MCP server, acting on behalf of a user, might have more permissions than the user. An attacker could potentially trick the LLM into requesting that the MCP server execute with its elevated privileges, leading to unauthorized actions. For example, an LLM could be manipulated into telling a high-privilege MCP server to delete a file that the user shouldn't have been able to delete. The AI doesn't realize it's being manipulated because the malicious instructions come through normal channels like tool descriptions, user inputs, or data it reads from files. ### Prompt Injection Vulnerabilities This is a major attack vector for any LLM-based application, and MCP creates new opportunities for it. Attackers can embed malicious instructions in documents, emails, or any data that the MCP processes. When the AI reads this content, it interprets the hidden commands as legitimate instructions. Some of the common tricks for prompt injection are: - **Hijack the AI's behavior:** Make the model ignore previous instructions or perform unintended actions. - **Data exfiltration:** Trick the AI into revealing sensitive information it has access to through other MCP connections. - **Trigger malicious actions:** Instruct the AI to use one of its connected tools to send spam, delete data, or purchase items. ### Supply Chain Risks and Unverified Third-Party Tools Since anyone can develop an MCP server, there's a significant risk from unverified or malicious third-party tools. You can discuss the following points: - **Malicious MCP Servers:** Attackers could create and distribute MCP servers that appear legitimate but are designed to steal data, credentials, or execute malicious code. - **Typosquatting:** Similar to domain name typosquatting, an attacker could name their malicious MCP server something very similar to a trusted one, hoping users will mistakenly connect to it. - **Lack of a Central Vetting Process:** Unlike an app store, there isn't a universal, mandatory security review for all MCP servers. This places a heavy burden on users and organizations to vet the tools they use. ### Tool Poisoning Attacks Attackers embed malicious instructions within tool descriptions that are invisible to users but interpreted by AI models. These attacks can manipulate AI behavior to exfiltrate sensitive data, read SSH keys, or execute unauthorized system commands. The scary part is that these instructions can be hidden in any part of the tool definition, not just descriptions. ### Credential and Token Exposure MCP servers need to connect to various external services, and they often do so using API keys, OAuth tokens, and other credentials. This creates a centralized point of failure. If an MCP server is compromised, an attacker could gain access to all the credentials it stores, potentially giving them the "keys to the kingdom" to a user's or a company's various connected services (like email, cloud storage, code repositories, etc.). ### Over-Privileged Access and Excessive Permissions Developers of MCP servers might request broad permissions to make their tools as flexible as possible. This violates the principle of least privilege. An MCP server with read, write, and delete access to a user's entire email account, when it only needs to read subject lines, poses a significant and unnecessary risk. ### Lack of Granular Monitoring and Auditing Since MCP is in the early stage, it does not have robust, built-in mechanisms for detailed logging and auditing of all actions performed through it. This can make it difficult to detect malicious activity, investigate security incidents, and understand what data has been accessed or modified. What makes this especially dangerous is that MCP servers often store tokens for multiple services all in one place. Suppose an attacker breaks into one MCP server. In that case, they potentially get access to your Gmail, Google Drive, Calendar, and everything else you've connected, creating what security researchers call a "keys to the kingdom" scenario. ## What has been done so far? A new [specification](https://modelcontextprotocol.io/specification/2025-06-18/changelog) was released on June 18, 2025, which introduces numerous features and clarifies that all MCP servers are classified as OAuth 2.0 Resource Servers. Here are some of the details shared by the team on [authorization](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization#authorization-server-discovery): ### Authorization Flow Architecture Key Roles: - MCP Server: Acts as an OAuth 2.1 resource server - MCP Client: Acts as an OAuth 2.1 client, making requests on behalf of users - Authorization Server: Issues access tokens (may be hosted with resource server or separately) ### Implementation Requirements Authorization Servers: - MUST implement OAuth 2.1 with security measures for both confidential and public clients - MUST provide OAuth 2.0 Authorization Server Metadata (RFC8414) - SHOULD support Dynamic Client Registration Protocol (RFC7591) MCP Servers: - MUST implement OAuth 2.0 Protected Resource Metadata (RFC9728) - MUST use WWW-Authenticate header when returning 401 Unauthorized - MUST validate access tokens and ensure they were issued specifically for them - MUST NOT accept or transit tokens issued for other resources MCP Clients: - MUST use OAuth 2.0 Authorization Server Metadata and Protected Resource Metadata - MUST parse WWW-Authenticate headers and respond to 401 responses - MUST implement PKCE (Proof Key for Code Exchange) - MUST include resource parameter in authorization and token requests (RFC 8707) - MUST NOT send tokens other than those issued by the MCP server's authorization server ### Security Requirements Token Security: - MUST use Authorization: Bearer

---