OWASP Top 10 Vulnerabilities for MCP Agents

The Model Context Protocol spread faster than anyone could govern it, and the OWASP MCP Top 10 exists to catalog what that speed cost. Most MCP connectors in production today were built by individual developers or small teams, shipped without a formal security review, and plugged into agents that may talk to a dozen other servers at once. Every one of those servers brings its own packages, its own credentials, and its own blind spots. A single AI coding tool can end up wired into a sprawling web of third-party code that nobody on the security team has read.

Because of that, traditional application security broke down in three ways. Tool descriptions, retrieved documents, and tool outputs all land in the agent's context window as trusted text, with no inherent way for the model to separate a legitimate instruction from one buried in a poisoned document. Each MCP server an agent connects to is a new trust boundary, and it sits entirely outside the codebase a security team actually reviews. And because agents chain tool calls together, one compromised server can hijack behavior across an entire pipeline, not just the step where the compromise happened.

The damage is visible in the CVE record. More than 30 CVEs were filed against MCP servers, clients, and infrastructure in January and February 2026 alone, a pace that marks MCP as an active, fast-moving attack surface rather than a niche concern.

OWASP built a dedicated list because the existing frameworks did not fit the shape of the problem. Model-level risks like training data poisoning are what the OWASP Top 10 for LLM Applications covers. Risks at the level of autonomous decision-making are what the Top 10 for Agentic Applications covers. The MCP Top 10 sits beside both of those lists but stays narrower by design: it is protocol-specific, built around the exact mechanics of how MCP servers, clients, and hosts talk to each other. The categories that follow walk through that mechanics one failure mode at a time.

MCP01:2025 (Token mismanagement and secret exposure)

Credential exposure is where most MCP compromises start. Hard-coded credentials, tokens that never expire, and secrets sitting in model memory or protocol logs give an attacker the most direct route to taking over an MCP-connected environment, because once a credential is in hand, everything that credential can touch is in hand too.

What makes this different from ordinary secret sprawl is where the leak happens. An AI agent often holds a credential value temporarily while completing a task, and that value can be pulled out through prompt manipulation, command injection, a debug trace, or a misconfigured server endpoint. MCP workflows mix secrets with ordinary operational context, so if you don't enforce strict handling rules, a credential can end up sitting inside the context window, readable by anything that can influence what the agent processes next. That is the MCP-specific wrinkle: the leak path runs through the model's own working memory, not just through a log file or a config repo.

The consequences compound quickly once a secret escapes. If the same token is shared across multiple downstream tools instead of scoped to one, a single leaked credential can cascade across every workflow that trusts it.

Fixing this starts with identity. Agents need their own cryptographic identities, issued separately from the humans or service accounts they act on behalf of, so a stolen agent credential can't be traced back to a person's account or used to impersonate one. Every agent credential should be short-lived, and rotation needs to be built into the issuance pipeline, not left to a manual schedule. Refresh tokens belong in a vault, never sitting in an MCP configuration file where anyone with file access can read them in plain text.

MCP02:2025 (Privilege escalation via scope creep)

Scope creep is what happens after the setup phase of an MCP integration, when permissions that made sense on day one quietly outlive their purpose. Most MCP integrations grant write-level access right at setup, and those permissions rarely get revoked later. They just accumulate, session after session, until an agent is sitting on far more access than any single task actually requires. That excess is a vulnerability on its own, whether or not a credential is ever stolen.

The GitHub MCP toxic agent flow attack shows how this plays out. The root cause was a broad-scope personal access token: an agent holding excessive repository permissions could be steered into reading across repositories it had no business touching, moving from public data into private, and exfiltrating that data through pull requests. Nothing about that chain required stealing a credential. The agent already had the access. It just needed to be pointed in the wrong direction.

Once scope has crept that far, an attacker working within normal-looking agent behavior can modify repositories, reach into system controls, or cross tenant boundaries, all while the activity looks like routine automation to anyone watching the logs.

The fix is to stop treating permission as something granted once at connection time. Authorization needs to be evaluated per invocation, checked against the agent's current permission set rather than whatever it was handed at the start of the session. High-privilege operations should require just-in-time escalation: explicit re-authorization at the moment of use. Each MCP server deserves its own dedicated OAuth app registration, so a single compromised credential exposes only what that one server touches, not everything connected to it.

MCP03:2025 (Tool poisoning)

Security teams tend to assume that once a tool is reviewed and approved, it stays that way. The agent trusts tool descriptions and schemas as instructions, so when tool poisoning strikes, that assumption breaks. Whoever controls that metadata controls what the agent does next, and they don't need to touch a single line of executable code.

Invariant Labs first documented tool poisoning in April 2025, and it now ranks as MCP03 on the OWASP list. Traditional SAST and SCA scanners miss it entirely, because the malicious content lives in metadata fields those scanners were never built to read.

Three variants appear in the record. A rug pull attack changes a tool's description after it has already passed review, exploiting the gap between a one-time approval and a description that can change at any point afterward. Schema poisoning corrupts the interface definitions themselves, so the agent ends up passing data to the wrong handler. Tool shadowing introduces fake or duplicate tools, and they intercept calls meant for the real, trusted ones.

If you defend against tool poisoning, you treat tool descriptions as untrusted input and give them the same scrutiny code gets. Metadata needs to be monitored for changes between invocations. Allowlists should enforce which tool schemas are permitted, and runtime detection should be watching for description mutations as they happen, not after the fact.

MCP04:2025 (Supply chain attacks and dependency tampering)

Tool poisoning manipulates metadata after a server is already deployed. Supply chain attacks reach further back, into the packages and registries an MCP server depends on before it runs. The dependency graph behind most MCP deployments is large and largely unreviewed, so this is the attack path that scales fastest and stays hidden longest.

CVE-2025-6514, found in mcp-remote, carried a CVSS score of 9.6, and it affected a package downloaded more than 437,000 times before anyone disclosed the flaw. One widely used connector was enough to put a massive installed base at risk.

The first real-world malicious MCP server to arrive through the supply chain surfaced in September 2025: a package on npm impersonating Postmark's email service. It worked like a legitimate email connector, but it quietly copied every message to an attacker. If an agent used it for email, it was exfiltrating its own correspondence without anyone noticing. Days later, researchers found a separate MCP server built with two reverse shells baked in, one that triggered at install time and one that triggered at runtime, giving the attacker redundant access so that closing one shell left the other wide open.

Left unmonitored, a supply chain compromise can rewrite agent logic, insert malicious automation, pull data out, or hand an attacker remote access. Because the same dependency often travels across multiple AI systems at once, the damage spreads fast and stays quiet.

The response is the same discipline already applied to ordinary software dependencies, carried over to MCP servers specifically: pin versions, verify checksums, and watch for ownership changes or new maintainers taking over a package. Every organization running MCP servers needs an inventory of which servers are deployed and which upstream dependencies feed into them.

MCP05:2025 (Command injection and unsafe execution)

Command injection is the most common exploitable flaw found in deployed MCP servers today, and it occurs often enough across the ecosystem to treat as a default assumption rather than a rare edge case. None of this is new to AI. It is the same class of vulnerability web applications have dealt with for two decades, now running inside infrastructure that most existing AppSec tooling never scans.

The documented attack patterns are familiar ones: remote code execution through command injection, unrestricted URL fetching that opens the door to server-side request forgery, and path traversal that lets an attacker read arbitrary files off the server. What makes MCP servers especially exposed is the combination of capabilities they typically carry at once. A server that handles files, executes commands, calls APIs, and manages credentials, all in the same process, turns any unsanitized input into something directly exploitable.

Once command injection succeeds, the attacker has direct execution capability. That capability enables file manipulation, infrastructure compromise, data deletion, or a foothold in whatever downstream system the server touches next.

Every input reaching an MCP tool invocation needs to be treated as untrusted, regardless of where it came from, whether that's a user prompt, retrieved context, or third-party data. All of it needs validation and sanitization before it reaches a command-executing tool. Least privilege should apply to what any MCP server process is permitted to execute in the first place, so a successful injection still has nowhere useful to go.

MCP06:2025 (Intent flow subversion via prompt injection)

Prompt injection against MCP does not work the way the classic version of the attack does. The malicious instructions come from content the agent retrieves, not from the user. They arrive inside content the agent fetches and treats as trusted context, a document, an issue, an email, something the agent was never told to question.

Research from Tenet Security tested an attack called agentjacking, and it bypassed explicit anti-injection instructions in the system prompt in most cases they tried. A better-worded system prompt does not solve this. The defense has to be structural.

The agent was not malfunctioning. It was doing what the retrieved content told it to do, which was never what the user had actually asked for.

MCP's whole value proposition, retrieving documents, issues, emails, and API responses as context, is also what creates a secondary instruction channel the agent has no reliable way to filter out. It cannot consistently tell what the user wants apart from what an attacker embedded in the data it just pulled in. The NSA's security guidance calls this out directly, pointing to MCP's inversion of the usual client-server pattern as a source of new attack paths that are not yet well understood: the server acts, and the client simply accepts what comes back.

Defending against this means constraining what sources an agent is even allowed to retrieve from and act on. Output needs validation before any agent-generated action executes. Runtime intent monitoring should flag when an agent's behavior drifts from what the user actually asked for. Every retrieval, no matter how reputable the source looks, has to be treated as a potential injection vector.

MCP07:2025 (Insufficient authentication and authorization)

Every risk covered so far gets easier for an attacker when authentication is weak or missing. A large share of deployed MCP servers run with no authentication at all, which means the techniques already described don't require stealing a credential. They only require a network path to the server.

Research scanned large numbers of MCP servers and found that roughly four in ten had no authentication, a condition common enough to call a population-level failure rather than a one-off misconfiguration.

Two specific patterns compound the problem. An MCP server acting as an OAuth proxy can fail to validate the authorization context, letting an attacker manipulate it into using another user's credentials to carry out privileged operations. The MCP specification's own security best practices documentation covers this attack with full flow diagrams. Token passthrough is a related failure: a server accepts a token issued for one service and forwards it downstream without checking who the token was actually meant for. The spec calls this an anti-pattern and forbids it.

The November 2025 MCP specification update made OAuth 2.1 with PKCE mandatory, not merely recommended, for any remote MCP server meant for public use over HTTP, and it now replaces static API keys as the default. Authorization has to extend past the initial login, with per-invocation verification rather than a single check at connection time.

The threat model also shifts depending on where a server runs. Red Hat's Principal Product Security Architect, Florencio Cano Gabarda, draws a clear line between local servers, which execute OS commands on a machine someone directly controls, and remote servers, which run on infrastructure they don't. Authentication requirements should follow that distinction, not treat every deployment the same.

The practical defenses line up with the spec: enforce OAuth 2.1 with PKCE on every HTTP-exposed MCP server, use tool-level scopes instead of broad grants, validate token audience at every hop, and never let a single credential serve more than one MCP server or agent. Platforms like Runlayer approach this by issuing each agent its own time-limited cryptographic identity and storing refresh tokens in a vault rather than in MCP configuration files, so that even if an agent's context is compromised, the damage stays bounded by that agent's scope and lifetime rather than spreading to everything it's connected to.

MCP08:2025 (Lack of audit and telemetry)

Every risk in the previous seven categories shares one trait once it succeeds: without logging and telemetry built for MCP specifically, the attack leaves no trace a security team can find after the fact. A stolen token, a poisoned tool description, a compromised dependency, an injected instruction, an unauthenticated call, all of it passes through MCP's own request and response cycle, and if that cycle isn't being recorded with enough detail, the compromise is invisible the moment it's over.

Standard application logging wasn't built to capture what matters in an MCP exchange: which tool was invoked, what permissions were active at that moment, what the tool description looked like at the time of the call, and what data moved between the agent and the server. Without that record, incident response has nothing to reconstruct, and a security team can't tell whether an agent is behaving normally or has already been hijacked.

The categories covered earlier describe how an MCP deployment gets broken into. This one describes why so many of those break-ins go unnoticed for as long as they do.