The OWASP MCP Top 10 is the first OWASP framework dedicated to Model Context Protocol security. It catalogs the ten risk categories most likely to compromise an MCP deployment, from token mismanagement to shadow servers. The project is in beta as of 2026 under the lead of Vandana Verma Sehgal, with categories published as MCP01:2025 through MCP10:2025.
This page explains every category, then maps each one to the control type that actually mitigates it. The matrix is the core of the page. No single tool category covers all ten risks, and the honest answer about any vendor (including Pipelock) is that it covers some rows fully, some partially, and others not at all.
If you want background on the protocol itself, start with MCP Security and MCP Vulnerabilities. For the broader ecosystem of tools that fit into the matrix below, see MCP Security Tools. For a 2026 view of how the market is responding, read The State of MCP Security 2026.
What the OWASP MCP Top 10 is
OWASP runs several Top 10 projects. The web Top 10 has been around for two decades. The Top 10 for LLM Applications launched in 2023. The Top 10 for Agentic Applications followed in 2025. The OWASP MCP Top 10 is the newest entry and the first to focus on a single protocol surface.
The project page lives at owasp.org/www-project-mcp-top-10. At time of writing, the framework is in Phase 3, beta release and pilot testing, which means the categories are stable enough to cite but the rankings and descriptions may shift. Check the project page for the current license terms before commercial use.
The framework exists because MCP changed the risk model for AI agents. Before MCP, an agent had a small fixed set of tools coded into the application. With MCP, the agent discovers tools at runtime from any server it can reach, and every server is a trust boundary. The OWASP MCP Top 10 catalogs the ten ways that boundary fails most often.
The categories are based on real incidents. The Postmark MCP supply chain compromise, the MCPJam Inspector RCE, the mcp-remote command injection CVE, the Mend.io shadow MCP report, the CyberArk “Poison Everywhere” research, and the Equixly data on missing MCP authentication all show up somewhere in the framework. You can think of the Top 10 as a structured index of attacks people have already paid for in production.
The ten risk categories
The list below uses the live OWASP MCP Top 10 categories as published on the project page. Because the framework is in beta, descriptions and ordering may change. Check the official OWASP page for the current version before you cite specific wording in audit material.
| ID | Category | What it covers |
|---|---|---|
| MCP01:2025 | Token Mismanagement & Secret Exposure | Hard-coded credentials, long-lived tokens, secrets in logs or model context |
| MCP02:2025 | Privilege Escalation via Scope Creep | Permissions that expand over time, agents acquiring unintended capabilities |
| MCP03:2025 | Tool Poisoning | Malicious tool descriptions or schemas that hijack agent behavior |
| MCP04:2025 | Software Supply Chain Attacks & Dependency Tampering | Compromised packages, backdoored servers, poisoned dependencies |
| MCP05:2025 | Command Injection & Execution | Agents constructing system commands from untrusted input |
| MCP06:2025 | Intent Flow Subversion | Injection that hijacks the agent’s reasoning chain through context |
| MCP07:2025 | Insufficient Authentication & Authorization | Servers that fail to verify identity or enforce access controls |
| MCP08:2025 | Lack of Audit and Telemetry | Missing logs, no real-time alerting, no record of what happened |
| MCP09:2025 | Shadow MCP Servers | Unapproved MCP deployments operating outside governance |
| MCP10:2025 | Context Injection & Over-Sharing | Sensitive data leaking across users, sessions, or agents |
The middle of the framework is where most production incidents happen. Tool poisoning, supply chain compromise, and command injection together account for the majority of disclosed MCP CVEs. Authentication gaps and shadow MCP often surface first as governance and inventory problems even before an exploit write-up exists. Token mismanagement and context oversharing are quieter risks that compound over time.
Risk coverage matrix
This is the most important section on the page. Each row is one OWASP MCP risk. Each column is a category of security tool. Each cell describes how well that category addresses the risk on its own. Combine four to six categories and the matrix fills out.
| Risk | Network Allowlist | MCP Gateway | Pre-deploy Scanner | Runtime Proxy (Inspection) | Identity Gateway (Auth) | Audit Log Platform |
|---|---|---|---|---|---|---|
| MCP01: Token Mismanagement | No | Partial | Partial | Partial | Yes | Complementary |
| MCP02: Scope Creep | No | Partial | No | Partial | Yes | Complementary |
| MCP03: Tool Poisoning | No | No | Yes | Yes | No | Complementary |
| MCP04: Supply Chain | No | No | Yes | Partial | No | Complementary |
| MCP05: Command Injection | No | No | Partial | Partial | No | Complementary |
| MCP06: Intent Flow Subversion | No | No | Partial | Yes | No | Complementary |
| MCP07: Auth & Authorization | No | Partial | No | No | Yes | Complementary |
| MCP08: Audit & Telemetry | No | No | No | Partial | No | Yes |
| MCP09: Shadow MCP | Partial | Partial | No | Partial | No | Complementary |
| MCP10: Context Oversharing | No | Partial | Partial | Yes | Partial | Complementary |
A few things to read into the matrix:
Pipelock sits in the Runtime Proxy column. It catches tool poisoning, command injection, intent flow subversion, and context oversharing in flight. It does not handle authentication for you, it does not replace an identity gateway, and it cannot fully verify packages before they ship. The matrix shows where Pipelock fits and where you need a different tool.
The audit column is “complementary” for almost every row because audit logs do not prevent anything on their own. They give you the record an auditor wants and the trail an incident responder needs. Pair an audit platform with whichever control covers the actual risk and you have both prevention and evidence.
MCP07 (auth and authz) is the row only an identity gateway clears. Inspection tools do not authenticate identities. Network allowlists do not enforce per-tool scopes. If you want a defensible answer to MCP07, you need an OAuth-aware gateway in front of every MCP server.
No row reads “Yes” across the board. That is the whole point. A defensible MCP deployment combines four to six of these categories. The combinations that work are described in the defense in depth section below.
MCP01: Token Mismanagement & Secret Exposure
The most common MCP failure is also the most basic. Servers ship with API keys hard-coded in config files. Tokens get logged in transcripts. Long-lived credentials sit in environment variables that any spawned subprocess can read. When the model sees a credential in its context window, it can leak it on the next tool call.
The defenses are layered. At the identity layer, you want short-lived tokens with explicit scopes, ideally OAuth 2.1 client credentials with rotation. At the inspection layer, you want DLP scanning on every tool argument and response so credentials never reach an outbound server. At the audit layer, you want a log of every credential access so leaks can be retraced.
Pipelock contributes the inspection piece. Its DLP engine carries 48 credential patterns at the time of writing and checks normalized text plus decoded variants such as URL-encoded, base64, hex, base32, and dot-collapsed forms before matching. If a credential appears in a tool argument, the proxy strips or blocks the request based on the configured action. That covers the runtime side. For provisioning and rotation you still need an identity gateway. See MCP Authorization for the auth half of the story.
MCP02 and MCP03: Tool poisoning and rug-pulls
The OWASP framework lists tool poisoning under MCP03, but rug-pull attacks (where descriptions change mid-session after a clean install) live next door to MCP02 scope creep. Both categories share a defense pattern.
Static scanners catch poisoning at install time. They pull tool descriptions, run them through pattern matchers and LLM classifiers, and flag suspicious instructions before the agent connects. That stops the obvious cases. What it does not stop is a server that serves clean descriptions to the scanner and poisoned descriptions later, or a server that updates its tool definitions during an active session.
The runtime defense is tool description fingerprinting. A proxy hashes each tool definition on first contact, caches the baseline, and compares every subsequent tools/list response against it. If a description changes after the baseline, the proxy logs the diff and blocks the modified tool. That catches rug-pulls in the act.
For the full pattern, including which fields in an MCP tool definition can carry injection and how the response-scanning passes and related normalization work, read MCP Tool Poisoning Defense. The tool poisoning blog post walks through the attack surface in more detail.
MCP04: Software supply chain integrity
MCP servers ship as packages. Most install through npm or pip with no signature verification. A maintainer who sells their account, ships a backdoored update, or has their token stolen can push malicious code into thousands of agent installations overnight. The Postmark MCP incident in 2025 was the canonical example: an email server with thousands of downloads pushed an update that exfiltrated message contents to an attacker-controlled domain.
The defenses are pre-deploy and runtime. Pre-deploy means dependency scanning, package signature verification, and reproducible builds. Tools like Trivy, Snyk, and Socket cover the dependency tree. A pre-deploy MCP scanner adds tool-level inspection on top of dependency scanning.
Runtime means tool description fingerprinting (catches the moment a server starts behaving differently after an update) and DLP scanning on outbound traffic (catches exfiltration even if the bad code slipped through). Pipelock covers the runtime half. For the dependency half, pair it with a package scanner that runs in CI before any new MCP server enters production.
MCP05: Command injection in MCP servers
Several disclosed MCP CVEs are command injection bugs in the server itself, not in the agent. The mcp-remote project shipped a code execution vulnerability in 2025 that allowed arbitrary commands when a malicious URL was passed to the tool. The MCPJam Inspector had a similar issue in its WebSocket handler. Both bugs let an attacker execute code on the host running the MCP server through a crafted argument.
The fix at the server level is input validation and argument sanitization. Servers should never construct shell commands from untrusted input. They should use parameterized APIs. They should run with the least privilege required to do their job. None of that is the agent’s responsibility.
The compensating control at the network level is a runtime proxy that scans tool arguments before they reach the server. If the argument carries a payload that looks like shell metacharacters, encoded command sequences, or injection patterns, the proxy can block the request. That does not patch the server bug. It does mean the server never sees the malicious input.
For containment after the fact, sandbox the MCP server. On Linux, run it under Landlock plus seccomp plus a network namespace. On macOS, use sandbox-exec. On Windows, pair the server with a runtime sandbox like agentsh. Even a vulnerable server cannot exfiltrate data it cannot reach.
MCP06: Intent flow subversion
Intent flow subversion is the OWASP category for prompt injection that hijacks the agent’s reasoning chain through MCP context. The injection might enter through a tool description, a tool response, a fetched document, or a memory entry. Once the agent reads it, the injected instructions compete with the user’s original goal for control of the next action.
The defense is content inspection at every entry point. Pipelock scans tool descriptions, tool arguments, tool responses, and fetched HTTP content. The pattern library includes “ignore previous instructions” variants, system and role overrides, jailbreak templates, multi-language equivalents, and known injection corpora. The response and description scanners normalize text and decode encoded variants before matching.
Pattern-based detection has limits. Novel attacks can slip through if they are not in the corpus. The mitigation is to combine pattern matching with classifier-based detection (on the roadmap), to log every detection for review, and to scope the agent’s tool access tightly so even a successful injection cannot reach high-impact tools. See Prompt Injection: Network-Layer Defense for the full pattern.
MCP07: Insufficient authentication and authorization
Equixly’s 2025 audit of public MCP servers found that a large share shipped without any authentication at all. Tools were callable by anyone who could reach the endpoint. Of the servers that did authenticate, many used long-lived tokens, no scope enforcement, and no per-tool authorization. The agent’s auth token granted access to every tool the server exposed.
The defense is an identity gateway in front of the MCP server. OAuth 2.1 with client credentials gives short-lived tokens. Per-tool scopes give granular access control. PKCE prevents authorization code interception. The MCP spec now documents OAuth as the recommended pattern, and several gateways implement it.
This is the row a runtime proxy does not clear. Pipelock does not issue tokens, does not validate OAuth scopes, and does not act as an identity provider. It can log which agent called which tool and surface that to your audit pipeline, but the authentication decision happens elsewhere. For the full story, see MCP Authorization, which also covers the confused deputy problem you have to solve once auth is in place.
MCP08: Audit and telemetry gaps
Auditors ask three questions about AI agents. What did the agent do. What data did it touch. Can you prove the record has not been tampered with. Most MCP deployments cannot answer any of them. Logs are missing, partial, or trivially editable.
The defense is a tamper-evident audit log. Each entry should record the request, the decision, the data classification, and a link to the previous entry through a cryptographic chain. Periodic checkpoints should be signed with a key the operator controls. Redaction should run on sensitive content before write so the log itself does not become a leak vector. That is the flight recorder approach.
Pipelock implements this in the runtime proxy. Every scan decision, policy action, and session event lands in a JSONL log with hash chaining and Ed25519 signed checkpoints. DLP redaction runs on each entry before write. The log is a durable session artifact designed for audit review. Pair it with a compliance evidence workflow and you have something concrete to hand to a SOC 2 or EU AI Act assessor.
MCP09: Shadow MCP servers
Shadow MCP is the unauthorized half of the agent’s attack surface. Developers install servers during exploration, AI IDEs suggest more, package managers make installation trivial, and nobody keeps a list. Mend.io published an early public write-up on shadow MCP, and the category is now tracked as MCP09:2025.
Detection happens at five layers: codebase scan for mcp.json and MCP package dependencies, IDE config inspection, runtime network monitoring, process monitoring for spawned MCP subprocesses, and CI pipeline audit. Routing every MCP session through a proxy adds a sixth layer because the proxy logs every server the agent actually contacts.
The full reference for how shadow MCP happens, how to find it, and how to enforce policy at runtime is at Shadow MCP. Pipelock contributes runtime detection through the proxy. It does not replace a CI scanning step that catches new servers before they ship.
MCP10: Context injection and oversharing
The last category covers what happens when sensitive data leaks across users, sessions, or agents through shared context. A multi-tenant MCP server returns the wrong customer’s data because session boundaries are loose. A shared memory entry written by one agent gets read by another. An over-privileged tool returns more fields than the agent needs and the extras enter the model’s context window forever.
The defenses are field-level access controls on the server, scope enforcement at the identity gateway, and DLP scanning on responses at the proxy layer. Pipelock contributes the response scanning. If a tool response contains data the agent should not see (credentials, customer records that match a redaction rule, internal system identifiers), the proxy can strip or block before the agent reads it.
The harder version of this problem is detecting that data has been over-shared without knowing what “too much” means in advance. That is a server design problem, not a runtime one. Get your MCP servers to return only the fields the agent’s task requires, then use the proxy as a backstop for the rest.
Defense in depth model
No single tool covers the OWASP MCP Top 10. The matrix above makes that clear. The combinations that do work look like this:
Minimum viable stack (small team, single agent fleet):
- Pre-deploy scanner for MCP03 and MCP04
- Runtime proxy for MCP03, MCP05, MCP06, MCP10
- Audit log platform for MCP08
This handles the core risks for a team that has not yet centralized identity. You have a known set of MCP servers, you scan them before deploy, you inspect traffic at runtime, and you keep a tamper-evident log. MCP01, MCP02, and MCP07 are gaps you accept until you can put an identity gateway in front of the servers.
Defensible stack (regulated environment, audit pressure):
- Pre-deploy scanner
- Runtime proxy
- Identity gateway with OAuth 2.1
- Audit log platform with hash-chained evidence
- Network allowlist or agent egress proxy on outbound traffic
- Optional MCP gateway if you route across many servers
Every row of the matrix has a covering tool. The audit platform reinforces every row. This is the configuration most enterprises end up at after they take the framework seriously.
Pipelock honest scoping for this matrix: runtime proxy column. Strong on inspection (MCP03, MCP05, MCP06, MCP10). Partial on telemetry (MCP08, the flight recorder is solid but does not replace a SIEM). Partial on shadow MCP (MCP09, runtime detection only, not codebase scan). No on identity work (MCP01, MCP02, MCP07). If you only deploy Pipelock, you have covered roughly half of the OWASP MCP Top 10 in full and another quarter in part. The other quarter needs different tools. Read MCP Security Tools for the other categories you need.
Getting started with OWASP MCP Top 10 mitigation
The first cuts are fast. Order matters because some controls reduce the cost of others.
Week one: inventory and inspect. Scan the codebase and IDE configs for every MCP server in use. Drop a runtime proxy in front of every agent so you have at least one record of what is calling what. Turn on audit logging. This handles MCP09 and MCP08 immediately and gives you the baseline for everything else.
Week two: pre-deploy scanning. Add an MCP scanner to CI. Block any server that fails the scan from reaching production. This handles the static side of MCP03 and MCP04 and stops the bleeding from new installs.
Week three: runtime inspection. Tune the runtime proxy to scan tool descriptions, arguments, and responses. Enable DLP scanning. Configure the action (block, strip, warn, ask) per server based on risk. This activates the matrix’s runtime proxy column for MCP03, MCP05, MCP06, and MCP10.
Week four: identity and authorization. Stand up an OAuth 2.1 identity gateway in front of MCP servers that handle sensitive data. Issue short-lived tokens with explicit scopes. This handles MCP01, MCP02, and MCP07. It is the most expensive step because it touches every server, which is why it comes last.
Ongoing: audit reviews and red team. Review the audit log weekly for the first month. Run a red team exercise against the deployed stack. Patch what fires. Rinse and repeat as the OWASP MCP Top 10 framework moves out of beta and as new categories of attack appear.
Further reading
- OWASP MCP Top 10 project page (the official source)
- The State of MCP Security 2026 (market overview and where the industry stands)
- MCP Tool Poisoning Defense
- Tool Poisoning: The MCP Attack Surface
- Shadow MCP
- MCP Authorization
- MCP Vulnerabilities
- MCP Security Tools
- MCP Proxy
- MCP Gateway
- MCP Security
- Flight Recorder
- Compliance Evidence
- OWASP Agentic Top 10 coverage
- Pipelock
- What is an Agent Firewall?
- MCP specification
- Vulnerable MCP Project