OWASP Top 10 Vulnerabilities for MCP Agents
MCP agents face ten distinct security risks from token leaks to tool poisoning, each compounded by the protocol's default over-privileging of access.
What the OWASP MCP Top 10 Is and How It Relates to Other OWASP AI Frameworks
The OWASP Top 10 for MCP is the first OWASP framework dedicated specifically to MCP security, and understanding where it sits relative to the broader OWASP AI portfolio determines whether you apply it correctly or just add it to a checklist that misses the point. Published as MCP01:2025 through MCP10:2025, still in beta as of early 2025 under lead Vandana Verma Sehgal, it exists alongside two companion deliverables: the OWASP Agentic AI Threats and Mitigations guide, and the OWASP Top 10 for Agentic Applications, released in December 2025.
The LLM Top 10 covers the model and the application wrapping it: prompt injection at the model layer, training data poisoning, output handling failures. The MCP Top 10 covers the protocol the agent uses to call external tools. Tool poisoning, server authentication gaps, audit deficiencies, shadow servers. There is overlap on prompt injection, but the MCP framework locates the injection entry points in tool descriptions and tool responses, not in the user's prompt. That distinction changes everything you build to stop it.
The ten categories are: Token Mismanagement and Secret Exposure (MCP01), Privilege Escalation via Scope Creep (MCP02), Tool Poisoning (MCP03), Supply Chain Attacks and Dependency Tampering (MCP04), Command Injection and Execution (MCP05), Intent Flow Subversion (MCP06), Insufficient Authentication and Authorization (MCP07), Lack of Audit and Telemetry (MCP08), Shadow MCP Servers (MCP09), and Context Injection and Over-Sharing (MCP10).
Several categories connect mechanically in ways the framework makes explicit. A shadow server (MCP09) that lacks authentication (MCP07) and carries a poisoned tool description (MCP03) is one attack chain, not three separate incidents. That composability is what makes MCP security harder than a standard vulnerability checklist implies, and why organizations that approach this list item by item miss the actual exposure.
MCP01: How Credentials End Up in the Wrong Hands Before an Attack Even Starts
The default pattern in early MCP deployments was static, unscoped API keys stored in configuration files or environment variables. No expiration. No environment isolation. No tool-level scoping. The same key grants identical access whether the agent runs a routine read or attempts a destructive overwrite, which means nothing in the credential itself signals that something has gone wrong.
GitGuardian's State of Secrets Sprawl 2025 found nearly 23.8 million new hardcoded secrets in public GitHub commits during 2024, with AI-assisted commits leaking at higher rates than the base rate. That is not a story about individual carelessness. It is a story about structural defaults.
Here is what the actual attack looks like. A poisoned add() tool silently reads SSH keys and the mcp.json configuration file, which contains credentials for every connected server, encodes them into a math function parameter, and delivers them to the attacker. The user sees "85" as the answer to "What is 47 plus 38?" Nothing looks wrong. No error, no latency spike, no anomalous output. The attacker has the keys to everything while the user admires the arithmetic.
Token mismanagement is not primarily a developer discipline problem. It is a structural consequence of a protocol that does not enforce short-lived, scoped credentials by default. The mitigations that address mechanism rather than symptom are specific: short-lived just-in-time credentials scoped to the tool and session, secret scanning integrated into MCP configuration workflows, and audit logging that captures what credentials were presented to which tool call.
MCP02: Why Agents Accumulate More Access Than They Need, and What That Costs When Something Goes Wrong
Anyone who has shipped production software will recognize this pattern immediately. Developers reach for the credentials they already have, often admin-level API keys or service accounts with broad permissions, because they want the agent to work without hitting authorization errors during development. Those broad permissions rarely get scoped down before the agent ships. Convenience in development becomes structural over-privilege in production, and it stays that way because scoping down permissions is unglamorous work that appears on nobody's roadmap.
The OWASP MCP Top 10 treats over-privileged access as foundational because of how it compounds every other risk. When a customer support agent carries the same credentials as a database administrator, a single successful attack against that agent exposes the database, not just the support queue. Blast radius scales directly with what the agent was granted.
Scope creep is a multiplier on every other vulnerability in the list. An attacker who successfully exploits a tool poisoning vulnerability (MCP03) or a command injection (MCP05) gets access commensurate with the agent's full credential scope, not the scope of the specific tool they compromised. The mitigation principle follows directly from that mechanism: least-privilege scoping at the tool-call level, not the agent level. Each tool invocation should carry only the permissions that specific call requires. Not the permissions that seemed reasonable during a late sprint, not the permissions from the service account someone already had lying around.
MCP03: What Tool Poisoning Is and How It Works at the Metadata Level
The attack surface here is not the tool itself. It is the metadata: the description, the parameter names, the annotations. The LLM reads that metadata as legitimate instructions for how to use the tool. Because the model interprets tool descriptions as trusted context, malicious instructions embedded there are not filtered the way user input is. The injection is pre-installed before the conversation starts, which is precisely what makes it so difficult to catch.
In 2025, researchers demonstrated that tool poisoning could be used to inject SQL commands through MCP-connected agents. Benchmark data from subsequent research found an 84.2% attack success rate with auto-approval enabled (Invariant Labs, 2025). Palo Alto Unit 42 found that with five connected MCP servers, a single compromised server achieved a 78.3% attack success rate. Those numbers reflect something fundamental about how language models operate: the model follows instructions. That is the feature. Here, it is also the liability.
The rug pull variant is worth specific attention because of its timing. MCP tool registrations are typically approved once and not continuously re-verified. A server behaves during the review period, earns approval, then changes its tool descriptions after agents and workflows already depend on it. The server that was approved is not the server currently running. Ordinary tool calls start leaking arguments, rewriting responses, or exfiltrating tokens, and nothing about the request looks different from the thousands that came before.
Invariant Labs released the open-source mcp-scan tool specifically to detect poisoned descriptions in MCP configurations. Cryptographically signed tool manifests address the rug pull variant directly by preventing post-approval tampering without requiring continuous manual review of every description.
MCP04: How the MCP Supply Chain Became an Attack Surface Before Most Teams Noticed
MCP ecosystems depend on open-source packages, connectors, and model-side plug-ins that can contain malicious or vulnerable components. A compromised dependency can alter agent behavior or introduce execution-level backdoors at a layer most teams are not instrumenting at all. This is not a theoretical concern. The CVE record for 2025 makes that clear.
CVE-2025-6514 in mcp-remote, discovered by JFrog Security Research, is a CVSS 9.6 OS command injection that triggered when mcp-remote initiated a connection to an untrusted MCP server. The vulnerability did not require user action beyond connecting to a server. The connection itself was the attack surface, which is a meaningful distinction: the user did nothing wrong. Connecting was enough.
The threat matured faster than most security teams adjusted. Researchers identified malicious MCP packages and filed numerous CVEs targeting MCP servers, clients, and infrastructure components throughout 2025. A survey of 2,614 MCP servers found 82% with path traversal exposure and 34% with command injection exposure (Clutch Security, 2025). About 38% of MCP servers come from unofficial sources, per the same research. Typosquatting is a live problem: malicious servers published under names closely resembling official ones, such as github-mcp-svr instead of github-mcp-server.
The required controls are the same supply chain discipline applied to software packages, extended to MCP servers and their dependencies: signed components, dependency monitoring, and provenance tracking for every MCP module. The organizations that treat MCP servers as a different category from software dependencies are already behind.
MCP05 and MCP06: Two Injection Paths That Reach the Same Place Through Different Routes
Command Injection and Execution
MCP05 occurs when an agent constructs and executes system commands, shell scripts, API calls, or code snippets using untrusted input without validation or sanitization. The input can arrive from user prompts, retrieved context, or third-party data. The comparison to classic SQL injection is useful but incomplete: the interpreter here is the model, and the payload is natural language. Models are designed to follow instructions, which is what makes injection in this environment both potent and genuinely hard to detect.
The Clinejection attack demonstrated the real-world range of the vulnerability: a malicious GitHub issue title triggered code execution on the developer's machine. CVE-2025-49596, rated CVSS 9.4, allowed attackers to execute arbitrary commands through unauthenticated MCP Inspector instances. Several disclosed MCP CVEs are command injection bugs in the server itself, not in the agent. mcp-remote and the MCPJam Inspector WebSocket handler both shipped code execution vulnerabilities through crafted arguments. A single breached server without authentication controls gives access to every integrated database, file system, and cloud service the agent connects to.
Intent Flow Subversion
MCP06 is prompt injection that hijacks the agent's reasoning chain through MCP context. The injection enters through a tool description, a tool response, a fetched document, or a memory entry. Anything the agent reads is potentially adversarial: retrieved documents, web pages, GitHub issues, CRM entries, commit messages, all of it.
An Invariant Labs experiment made the mechanism concrete. A getfactoftheday tool description contained instructions that systematically redirected send_email to an attacker's address, with the real recipient buried in the message body where the confirmation dialog did not expose it. The trusted tool was called correctly from the agent's perspective. The destination was overwritten before the user typed anything.
What distinguishes MCP06 from a standard prompt injection is timing and location. The injected instruction arrives pre-installed in the tool manifest, present from the moment the agent loads its tool context. Any text the agent processes as context is a potential instruction surface, which means input validation and output sanitization must extend to tool responses and retrieved documents, not just user messages. That is a materially larger surface than most teams are currently scanning.
MCP07: What Happens When Authentication Is Optional and Most Deployments Skip It
A significant portion of scanned MCP servers lack any form of authentication, and only a small minority use a modern, secure authentication model (Clutch Security, 2025). Those figures reflect a root cause in the protocol itself: MCP's original design made authentication optional. The spec did not define how a session maps to a verifiable identity. RBAC was not part of the original design, and many implementations shipped without any access controls whatsoever.
The spec history explains the current distribution of deployments better than any other single factor. Early MCP had no authentication mechanisms and was prone to impersonation and spoofing. MCP v1.2 added token-based authentication. The November 2025 specification formalized OAuth 2.1 as the authentication standard for remote MCP servers, which was a meaningful maturation of the protocol. But adoption of the updated spec is not universal. Deployed servers span the full spectrum from completely unauthenticated to OAuth 2.1, with no reliable way to determine from the outside which you are connecting to.
The coarse-permissions problem persists even where authentication exists. MCP lacks fine-grained permissions at the field, endpoint, or task level, which means coarse access control lists expose systems to unpermitted access and feed directly back into MCP02's scope creep risk. An unauthenticated MCP server is one where every tool call is anonymous, every action is unattributable, and any client that can reach the network endpoint can invoke any tool the server exposes.
MCP08 and MCP09: The Visibility Problem That Lets Everything Else Persist Undetected
Lack of Audit and Telemetry
When MCP deployments lack structured logging, there is no record of which tool was called, with what arguments, by which agent, on whose behalf. The exfiltration path from MCP01, where a poisoned tool encodes stolen credentials into a math result, leaves nothing for the security team to reconstruct if tool-call-level telemetry was never implemented. The attack completes, the session ends, and there is no artifact indicating anything unusual occurred. The team finds out when something downstream breaks, or when they do not find out at all.
Tool calls in MCP carry context that standard application logs were not designed to capture: the tool name, the arguments passed, the server that responded, the identity of the session that initiated the call. Without telemetry at that depth, incident response is guesswork. Tamper-proof audit logs are the minimum foundation for any post-incident analysis, and most MCP deployments currently lack them.
Shadow MCP Servers
MCP09 compounds the audit problem by introducing servers that are never in scope for logging in the first place. Shadow MCP servers are servers operating outside the organization's visibility, whether deployed by individual developers who wanted a faster iteration cycle, procured directly by a business unit without going through security review, or discovered at runtime by an agent and accepted without verification.
The combination of MCP08 and MCP09 creates the conditions under which every other vulnerability on this list can persist indefinitely. A shadow server that lacks authentication and carries a poisoned tool description is a server that was never reviewed, never logged, and will never surface in a standard audit. The agent connects to it at runtime, executes its tools, and the organization has no record that the interaction occurred.
Every other mitigation in this framework depends on visibility as a prerequisite. Without it, the other nine categories are purely theoretical.
