OWASP MCP Top 10: A Guide to Securing Model Context Protocol in 2026

Between January and February 2026, security researchers filed more than 30 CVEs against Model Context Protocol servers, clients, and infrastructure. Palo Alto Networks Unit 42 measured a 78.3 percent attack success rate when five MCP servers were connected to a single AI agent. The OWASP MCP Top 10 is the first OWASP framework dedicated to this new attack surface, and it arrived just in time.

This guide walks AppSec, platform, AI engineering, and DevSecOps teams through all ten risk categories. You will get a plain English description of each risk, real CVEs and disclosed attacks mapped to the categories, and a defense playbook layered across the SDLC and the Agentic Development Lifecycle (ADLC). If you are new to the protocol, start with this overview of the Model Context Protocol (MCP) before diving in.

What Is the OWASP MCP Top 10?

The OWASP MCP Top 10 is OWASP’s first dedicated Top 10 project for Model Context Protocol implementations. It catalogs the ten risk categories most likely to compromise an MCP deployment, ranging from token mismanagement and tool poisoning to shadow MCP servers and context over sharing.

The MCP Top 10 sits alongside two related OWASP projects: the Top 10 for LLM Applications and the Top 10 for Agentic AI. The LLM list focuses on model level risks like prompt injection and training data poisoning. The Agentic AI list addresses risks that emerge from autonomous agent behavior. The MCP list is narrower and more protocol specific. It targets the tool discovery, context passing, and tool invocation layer between an AI agent and external systems, which makes it directly relevant to anyone deploying MCP servers in production.

Why the OWASP MCP Top 10 Matters for AI Driven Development?

MCP has become the default connector between AI agents and enterprise systems, but adoption has outpaced security by a wide margin. Cycode’s 2026 State of Product Security report found that 81 percent of organizations lack full visibility into how AI is used across the SDLC, while 65 percent report increased security risk from AI tooling. MCP servers sit at the intersection of those two problems.

MCP Has Exploded Across the Developer Stack

MCP adoption has moved quickly across developer tools, AI coding assistants, IDE extensions, and agent workflows. What started as a protocol for connecting AI systems to external tools is now becoming a common integration layer across the software development stack.

That growth creates two practical problems. The ecosystem is dominated by individual developers and small teams shipping connectors without formal security review, and the dependency graph is enormous. A single AI coding tool might connect to ten MCP servers, each pulling in its own packages and credentials. Every new server is a new trust boundary that your existing AppSec controls likely cannot see.

• Thousands of public MCP servers now exist across GitHub, spanning GitHub, Slack, Jira, databases, cloud, and CI/CD tools.
• New MCP servers are published weekly, often without clear ownership, review, or maintenance.
• Anthropic, OpenAI, Microsoft, and every major IDE now ship MCP support by default.

MCP Expands the Trust Boundary Beyond Traditional AppSec

Traditional AppSec assumes code is the source of risk. MCP breaks that assumption in three places. Tool descriptions, retrieved documents, and tool outputs all enter the agent’s context window as trusted text. The agent treats them as instructions worth following, even when they come from an attacker controlled GitHub issue or a poisoned tool metadata field.

Every connected MCP server becomes a fresh trust boundary, and one compromised server can hijack an agent across the whole pipeline. That makes securing MCP a governance problem as much as a coding problem, spanning the Agentic Development Lifecycle (ADLC) from IDE to CLI to CI/CD to production.

• Tool descriptions and tool outputs are read by the agent as trusted instructions.
• Each MCP server connection introduces a new trust boundary outside your codebase.
• A single compromised MCP server can hijack agent behavior across an entire pipeline.

MCP Vulnerabilities Are Already Mass Scale, Not Theoretical

The numbers tell the story plainly. Researchers filed 30 plus CVEs in 60 days in early 2026. CVE-2025-6514 in mcp-remote hit a CVSS score of 9.6 and affected a package downloaded more than 437,000 times before disclosure.

These are not exotic AI native attacks but classic web application vulnerabilities wearing new uniforms, and they are exploitable today. Many MCP servers handle files, execute commands, call APIs, and manage credentials, which makes path traversal, command injection, insecure auth, and over-permissioned access immediate concerns.

• 30 plus MCP CVEs disclosed in January and February 2026 alone.
• CVE-2025-6514 (CVSS 9.6) impacted a package downloaded 437,000 plus times.
• 82 percent path traversal exposure and 34 percent command injection exposure across 2,614 surveyed servers.

Existing AppSec Tools Miss MCP Risk by Default

Traditional SAST and SCA were built for source code, not for tool descriptions. A clean source code scan will completely miss a tool poisoning attack, because the malicious content lives in metadata fields that the scanner has no reason to read.

Shadow MCP servers bypass centralized security policies because no one knew they existed in the first place. Classic application security tools also do not see the runtime interactions between an agent and the MCP servers it talks to. The result is a visibility gap that compounds with every new MCP server added to the environment.

• SAST and SCA cannot detect malicious instructions embedded in tool descriptions.
• Shadow MCP servers bypass centralized policy because they are not in any inventory.
• Runtime agent to server interactions are invisible to most existing AppSec tooling.

Regulatory and Compliance Pressure Is Rising

Compliance is catching up to the technology fast. The NIST AI Agent Standards Initiative kicked off in February 2026, and the EU AI Act, ISO 42001, SOC 2, DORA, and PCI-DSS all increasingly touch agent behavior and credential handling.

Auditors are starting to ask for evidence of agent activity logs, credential rotation, and tool inventory. The AI Bill of Materials (AIBOM) is emerging as the new SBOM analog for AI components, with MCP servers as one of its core inputs. Teams without an AIBOM today will be answering uncomfortable questions in the next audit cycle.

• NIST AI Agent Standards Initiative began in February 2026.
• EU AI Act, ISO 42001, SOC 2, DORA, and PCI-DSS all touch agent behavior or credential controls.
• AIBOM is becoming the required inventory artifact for AI components including MCP servers.

The OWASP MCP Top 10 Risks Explained

Below is a category by category walkthrough of the OWASP MCP Top 10, version 0.1 (2025). For each risk we cover what it is, a real world example or CVE with the source, and the most effective primary mitigation.

MCP01:2025 Token Mismanagement and Secret Exposure

Hard coded API keys, long lived tokens, and secrets stored in model memory or protocol logs expose connected systems to unauthorized access. Attackers retrieve these tokens through prompt injection, compromised context, or debug traces, then pivot into the systems the tokens authenticate to.

A typical scenario plays out like this: a developer commits an API key during testing, the MCP server reads it from a config file at startup, and the AI assistant later surfaces it in a response. Mitigation requires short lived scoped tokens, continuous secrets detection, and AI Guardrails that intercept outbound prompts before secrets leak.

• Many MCP servers still rely on static API keys, PATs, or long-lived credentials.
• OAuth and delegated access patterns are not yet consistently adopted across the ecosystem.
• Token leakage often happens through debug traces, prompt injection, or context spillover into AI responses.

MCP02:2025 Privilege Escalation via Scope Creep

Temporary or loosely defined permissions inside MCP servers tend to expand over time, granting agents excessive capabilities. An attacker exploiting weak scope enforcement can perform actions far beyond what the user intended, such as repository modification, system control, or cross tenant data access.

This risk is especially dangerous in GitHub connected MCP workflows. A prompt injection hidden inside a public issue can redirect an agent that has access to both public and private repositories, causing private code or secrets to be pulled into context and exposed through a public pull request or comment. The failure is not just prompt injection. It is excessive access across trust boundaries without runtime policy enforcement to stop data movement between sensitive and public environments.

• Broad scope PATs were the root cause of the GitHub MCP toxic agent flow attack.
• Most MCP integrations grant write level scopes that never get revoked after initial setup.
• Scope expiry, least privilege design, and access reviews are the most effective controls.

MCP03:2025 Tool Poisoning

Tool poisoning is when an adversary compromises the tools, plugins, or outputs that an AI model relies on. The sub techniques include rug pulls (a tool updates its description after install), schema poisoning (corrupting the interface definition), and tool shadowing (a fake tool intercepts calls meant for a legitimate one).

In MCP environments, tool descriptions and schemas are especially sensitive because they are often placed directly into the agent’s context window as trusted instructions. An attacker can hide malicious instructions inside a tool description or manipulate the schema so the model is guided to misuse the tool, leak data, or route actions through an unintended tool. This can happen even when the underlying tool code appears harmless.

• Rug pull attacks change a tool’s description with malicious content after initial approval.
• Schema poisoning corrupts interface definitions so the agent passes data to the wrong handler.
• Tool shadowing introduces fake or duplicate tools that intercept calls meant for trusted ones.

MCP04:2025 Software Supply Chain Attacks and Dependency Tampering

MCP ecosystems depend on open source packages, connectors, and model side plug-ins, each of which can contain malicious or vulnerable components. A single compromised dependency can alter agent behavior or introduce execution level backdoors across every deployment that pulled the bad version.

The most consequential example to date is CVE-2025-6514 in mcp-remote, discovered by JFrog Security Research in July 2025. The flaw was a CVSS 9.6 OS command injection that triggered when mcp-remote initiated a connection to an untrusted MCP server, in a package downloaded more than 437,000 times. The first malicious MCP server ever caught in the wild, the Postmark backdoor disclosed silently exfiltrated emails.

• CVE-2025-6514 (CVSS 9.6) in mcp-remote affected a package with 437,000 plus downloads.
• The Postmark MCP backdoor became the first malicious MCP server caught in the wild.
• AIBOM and provenance tracking are now baseline supply chain controls for MCP ecosystems.

MCP05:2025 Command Injection and Execution

Command injection occurs when an AI agent constructs and executes system commands, shell scripts, API calls, or code snippets using untrusted input. The input could come from a user prompt, retrieved context, or a third party data source, and the agent rarely validates it before passing it to a shell or eval style API.

In MCP environments, this risk becomes more serious because local MCP servers often have access to files, developer tools, environment variables, package managers, or cloud CLIs. For example, a malicious issue comment, README, ticket, or retrieved document could cause the agent to append extra shell arguments, run a second command, exfiltrate a token, or modify local files. The mitigation pattern is to use parameterized command APIs, avoid shell execution wherever possible, apply strict input validation, enforce deny by default execution, and use Container Security to sandbox local MCP servers.

• 34 percent of 2,614 MCP implementations expose APIs susceptible to command injection.
• 67 percent of the same population expose APIs related to code injection.
• 43 percent of MCP CVEs in January and February 2026 were shell injection class vulnerabilities.

MCP06:2025 Intent Flow Subversion (Prompt Injection via Context)

The Model Context Protocol enables agents to retrieve complex context that can act as a secondary instruction channel. Intent Flow Subversion happens when malicious instructions embedded in retrieved context hijack the agent’s reasoning, steering it away from the user’s original goal toward an attacker’s objective.

The classic delivery vector is indirect prompt injection. An attacker plants instructions inside a document, web page, CRM entry, GitHub issue, or any other content the agent will later read. The GitHub MCP attack chained this technique with scope creep: a poisoned issue body redirected the agent’s intent flow into private repo exfiltration. Defending against this means treating all retrieved content as untrusted input and requiring human in the loop confirmation on sensitive actions.

• Indirect prompt injection embeds attacker instructions in documents, issues, web pages, or tool outputs.
• The GitHub MCP attack used a public issue body to hijack agent reasoning and exfiltrate private repos.
• Human in the loop approval on sensitive actions is the most reliable defense.

MCP07:2025 Insufficient Authentication and Authorization

Inadequate authentication and authorization arise when MCP servers, tools, or agents fail to properly verify identities or enforce access controls during interactions. Because MCP ecosystems involve multiple agents, users, and services exchanging data and executing actions, even small identity gaps create critical attack paths.

Many MCP servers still rely on static keys, PATs in environment variables, or weak access controls instead of delegated authorization. If an MCP server is exposed without proper authentication, it can become an open interface for attackers to invoke tools, access connected systems, or trigger sensitive actions. Mitigation centers on OAuth 2.1, per-server audience validation, MFA for human approval of sensitive actions, and managed identities for service-to-service calls.

• Many MCP servers still depend on static keys, PATs, or weak authentication patterns.
• Exposed MCP endpoints without authentication can give attackers direct access to connected tools and actions.
• OAuth 2.1 with per-server audience validation should become the baseline.

MCP08:2025 Lack of Audit and Telemetry

Limited telemetry from MCP servers and agents makes investigation and incident response nearly impossible. Without comprehensive logs of tool invocations, context changes, and user agent interactions, security teams cannot tell what an agent did, when it did it, or whether a prompt injection ever fired.

This is the meta risk that amplifies every other risk on the list. Token theft, command injection, and prompt injection all remain invisible without telemetry. Compliance frameworks like SOC 2, ISO 42001, DORA, and the EU AI Act all increasingly require traceable agent activity. The fix is immutable audit trails, real time alerting on tool invocation anomalies, and behavioral monitoring of agent action sequences against baseline patterns.

• No telemetry means token theft, injection attacks, and exfiltration all stay invisible.
• SOC 2, ISO 42001, DORA, and the EU AI Act all require traceable agent activity.
• Sequence level behavioral monitoring catches multi step attacks that individual logs would miss.

MCP09:2025 Shadow MCP Servers

Shadow MCP Servers are unapproved or unsupervised MCP deployments that operate outside formal security governance, much like shadow AI and shadow IT. Developers, research teams, and data scientists spin them up for experimentation or convenience, then leave them running with default credentials, permissive configurations, and unsecured APIs.

Cycode’s 2026 report shows 81 percent of organizations lack full visibility into AI usage across the SDLC. MCP servers sit squarely in that blind spot. A typical environment might have dozens of MCP servers running on developer machines, in CI runners, and in production, with no central inventory and no policy enforcement. Continuous MCP discovery, AIBOM inventory, and allowlist enforcement at the IDE and CI/CD pipeline security layers are the only way to stay ahead of it.

• 81 percent of organizations lack full visibility into AI usage across the SDLC.
• Shadow MCP servers typically run with default credentials and permissive configs.
• Continuous discovery plus allowlist enforcement is the foundational control.

MCP10:2025 Context Injection and Over Sharing

In MCP, “context” is the working memory that stores prompts, retrieved data, and intermediate outputs across agents or sessions. When context windows are shared, persistent, or insufficiently scoped, sensitive information from one task, user, or agent can be exposed to another. Convenience becomes a liability.

A single agent serving multiple users can leak one user’s PII into another user’s session if context isolation fails. Long lived memory features magnify the blast radius of any one compromised session, and cross tenant exposure has already been documented in early MCP deployments. Mitigation requires scoped context windows, ephemeral memory by default, and strict cross tenant isolation enforced at the protocol layer rather than the application layer.

• Shared or persistent context windows can leak data across users, tasks, or tenants.
• Long lived memory features magnify the impact of any one compromised session.
• Cross tenant isolation must be enforced at the protocol layer, not the application layer.

How to Mitigate the OWASP MCP Top 10

No single control closes the entire OWASP MCP Top 10. Effective defense layers identity, supply chain, runtime, and governance controls across the Agentic Development Lifecycle. The sections below group the controls by where they live in the SDLC and ADLC.

Govern Identity, Tokens, and Scopes Before Anything Else

This control set covers MCP01, MCP02, and MCP07, which together account for most of the worst MCP incidents to date. The static API key problem is the foundation. Replace static keys with short lived OAuth 2.1 tokens, validate audience per server, enforce automatic scope expiry, and require MFA for human approvers of high risk actions.

Layer on continuous secrets detection across repos, developer machines, and CI runners so that any token that does end up hard coded is caught before it ships. Treat every Personal Access Token as a future incident waiting to happen, and design scopes accordingly. The biggest behavioral shift is moving from a “set credentials once” model to a “credentials are short lived by default” model.

• Replace static API keys and PATs with short lived OAuth 2.1 tokens.
• Validate audience per server and enforce automated scope expiry.
• Catch hardcoded credentials at the source with continuous secrets detection across repos and CI.

Treat Tool Descriptions and Retrieved Context as Untrusted Input

This control set covers MCP03, MCP06, and MCP10. The mental model is simple: anything the agent reads is potentially adversarial. Tool descriptions, retrieved documents, web pages, GitHub issues, CRM entries, even commit messages can carry hidden instructions.

Pin tool versions and signed schemas at install time, alert on any description drift after first approval, isolate retrieved content from user instructions, and scope context windows per task. The OWASP MCP Top 10 guidance specifically calls out the importance of preventing description drift, because rug pull attacks rely on the fact that users approve a tool once and never review it again. Connect these controls into your broader strategy for AI security vulnerabilities.

• Pin tool versions and sign schemas at install time, and alert on any post install description drift.
• Isolate retrieved content from user instructions inside the agent context window.
• Scope context windows per task and avoid persistent memory by default.

Secure the MCP Supply Chain End to End

This control set covers MCP04. The mcp-remote and Postmark incidents show what happens when supply chain hygiene lags behind ecosystem growth. Demand provenance for every connector and dependency, maintain an AI Bill of Materials (AIBOM) across the ADLC, and monitor CVE feeds for MCP packages.

Apply SCA policies before agents pull new tools, not after. Treat MCP package registries with the same skepticism you would treat any other public package source, because the Postmark incident proved that malicious MCP servers can and do reach production environments. Provenance signals like signed releases, verified publishers, and reproducible builds should be required, not optional.

• Maintain an AIBOM across the ADLC that includes every MCP server, connector, and dependency.
• Apply SCA policies before agents pull new MCP tools, not after they are already installed.
• Require signed releases and verified publisher signals for any MCP component.

Sandbox Execution and Validate Every Tool Input

This control set covers MCP05, the single most common bug class in disclosed MCP CVEs. Wrap every shell, file, and network call in a parameterized API. Deny by default network egress for local MCP servers so that even a successful command injection cannot reach the internet. Run MCP servers inside containerized sandboxes wherever possible.

Apply consistent CI/CD pipeline security policies so that local development practices match production guardrails. A useful test is to check whether your MCP server takes any string input and feeds it to a subprocess, file path, or network call. Treat that path as exploitable until you can prove otherwise. The default assumption should be that untrusted tool input can become a working exploit.

• Wrap every shell, file, and network call in a parameterized API with strict input validation.
• Deny by default network egress for local MCP servers to limit blast radius.
• Run MCP servers inside containerized sandboxes with least privilege defaults.

Get Visibility: Discover, Inventory, and Log Every MCP Server

This control set covers MCP08 and MCP09, the meta risks that hide every other risk. You cannot defend what you cannot see. Run continuous discovery of MCP servers, AI assistants, models, and rule files across repos and developer machines, then feed everything into immutable audit logs and behavioral monitoring.

The goal is to turn shadow AI into governed AI. Once you have an inventory and a baseline, anomalies become detectable. Without them, the first sign of compromise will be a data leak in the news, not an alert in your SIEM. Discovery should run continuously, not as a quarterly inventory exercise.

• Continuously discover MCP servers across repos, developer machines, CI runners, and production.
• Pipe tool invocations and context changes into immutable audit logs.
• Run behavioral monitoring on agent action sequences to catch multi step attacks.

Apply Controls at the Developer Edge: IDE, CLI, and PR

This is the cross cutting control that ties the rest together. The IDE and CLI are now security boundaries. Intercept prompts, file reads, and MCP tool calls before sensitive data ever leaves the developer machine. Enforce policy in the pull request, not after deploy, because by the time MCP risk reaches production it has already crossed several trust boundaries.

This is where AI Guardrails live in practice. The goal is to make the secure path the easy path for developers, so that security and velocity do not have to trade off against each other. Friction at the developer edge is far easier than incident response after a leak hits production.

• Intercept outbound prompts, file reads, and MCP tool calls in the IDE and CLI.
• Enforce MCP policy in pull requests before code merges, not after deploy.
• Make the secure path the default workflow so developer velocity stays intact.

How Cycode Helps You Address the OWASP MCP Top 10

Cycode is an Agentic Development Security Platform purpose built for AI driven development, with native controls across every layer the OWASP MCP Top 10 covers. As MCP adoption grows across developer workflows, Cycode gives security teams correlated visibility, policy-driven control, and agentic remediation across the full ADLC, including the new MCP attack surface.

These capabilities fall into three pillars: Control, Context, and Autonomy.

Control pillar keeps AI usage governed and stops secrets from leaving from the developer machine.

• Native Cycode MCP Server that exposes Cycode’s scanners (SAST, SCA, Secrets Detection, IaC Security, Container Security) to any MCP compatible AI coding tool, including Cursor, Windsurf, and Copilot. Your AI coding tools check their own work against industry grade security engines.
• AI Guardrails that intercept prompts, file reads, and MCP tool calls in the IDE and CLI before secrets or sensitive data leave the developer machine, addressing MCP01, MCP03, and MCP10 at the source.
• Continuous discovery of shadow AI across the software factory, including AI coding assistants, models, MCP servers, AI packages, rule files, skill files, and secret references, feeding an AI Bill of Materials (AIBOM) for full inventory and governance.

Context pillar connects MCP risk to the rest of your supply chain.

• Maestro, the agentic security orchestration engine, for triage, exploitability validation, and PR ready remediation across MCP driven workflows.

Autonomy pillar triages and remediates issues with little manual effort.

• Unified Context Intelligence Graph across AST, SSCS, ASPM, and ADLC, so MCP risk is correlated with the rest of your software supply chain rather than treated as an isolated problem.

The result is that the OWASP MCP Top 10 stops being a list of categories you have to track manually and becomes a set of controls already in place across your environment, with Control, Context, and Autonomy operating as one platform. Book a demo today and see how Cycode secures every layer of the Agentic Development Lifecycle (ADLC) against the OWASP MCP Top 10.