OWASP MCP Top 10 Mapped to Enterprise Deployment Risks

Model Context Protocol (MCP) is the connector standard that lets AI agents reach outside their own walls and touch real systems: databases, file systems, internal tools, other servers. This piece maps the OWASP MCP Top 10 to what that connector actually does once it's running inside an enterprise, because the protocol's design choices turn familiar security problems into harder ones and introduce a few that have no real precedent. The specification reached a stable release on July 28, 2026, so the ten categories below are solid enough to plan around, even though the ranking of which risk matters most will keep shifting as more incidents get disclosed. If you're building controls today, you work against a document that still moves, not one that's finished.

MCP01 (Token mismanagement and secret exposure): why credential hygiene fails at protocol scale

Most MCP server deployments run on static, long-lived credentials today, and that habit has caused credential leaks in software for twenty years. What changes is how MCP's architecture gives those old habits new ways to fail. A debug trace or a prompt injection can pull a token straight into the model's context window or into an agent's visible response, handing an attacker a working credential without any network exploit.

Configuration is where the bigger risk lies. MCP server setup files, usually named mcp.json, can store secrets, and any other server connected in the same session can read them. So a single poisoned tool doesn't just compromise its own access. It can reach into the credentials for every other server the user has already approved in that session. One bad actor in the chain exposes the whole chain.

MCP sessions also tend to run long, which stretches the window during which a stolen token stays useful. A credential that leaks in a five-minute web session is bad. A credential that leaks inside a session running for hours, with standing access to several connected systems, is a much bigger problem.

The fix that actually closes most of this gap is just-in-time credential issuance: generate the credential only at the moment the agent needs it, scope it to that one tool call, and expire it right after. That sounds simple, but it requires credential infrastructure built specifically for non-human identities, with tokens issued, tracked, and retired on a machine's own schedule.

MCP02 (Privilege escalation via scope creep): how agent permissions expand past their original intent

Even a properly issued, correctly scoped credential becomes a risk if nothing enforces its boundaries over time. MCP places no built-in constraint on scope enforcement at the tool level, so an agent's permissions are only as narrow as whatever discipline a team applied on day one, and that discipline rarely holds.

The root cause is development convenience. Engineers build agents with broad read and write access because it's faster than negotiating narrow permissions for every function, and once the agent ships, nobody circles back to cut that access down. Permissions granted for a prototype stay in place for the production system.

In a multi-team enterprise, this becomes a governance problem, not just a misconfiguration. An agent built to serve one team's data can accumulate access to adjacent systems over months, quietly, because MCP has no standard mechanism that forces a periodic review of what an agent can actually touch. Nobody is checking, so nobody notices, until an incident forces the question.

The fix is fine-grained, role-based access control at the tool level, paired with automated reviews that check an agent's current permissions against what it was originally approved for. A one-time approval at deployment is a snapshot of a moment that immediately starts going stale.

MCP03 (Tool poisoning): why a trusted tool can become an attack vector between approval and use

Tool poisoning is the attack class built specifically around how MCP works, and it has no clean equivalent in traditional application security. An MCP agent reads a tool's description as trusted instruction text, and that description can change after a user has already approved the tool. What a user approved yesterday may bear no relationship to the tool running today.

Three mechanisms exploit this, and each hits a different point in the tool's lifecycle. A rug-pull attack changes a tool's description to include malicious content sometime after the initial approval, so the user is trusting a version of the tool that no longer exists. Schema poisoning corrupts the interface definition itself, so the agent passes data to the wrong handler without anyone writing a single line of obviously malicious code. Tool shadowing plants a fake or duplicate tool that intercepts calls meant for the real, trusted one.

The rug-pull mechanism breaks the basic assumption behind software approval: review once, deploy, move on. That workflow is a vulnerability posture for MCP tools, not a control, because the thing being approved can change at any later launch without the user doing anything differently. The approval moment and the risk moment are two separate points in time, and nothing in standard practice connects them.

Traditional AppSec tooling can't close this gap either. Static analysis and software composition analysis were built to scan source code, but a tool poisoning attack doesn't live there. It lives in a metadata field, the tool's description, that a code scanner has no reason to read. A perfectly clean scan result tells an enterprise nothing about whether the tool description sitting in front of the agent right now matches the one a security team reviewed last quarter.

MCP04 (Software supply chain attacks): the dependency graph is larger and less governed than it looks

Every MCP server an enterprise connects to is its own trust boundary, carrying its own dependency graph, and the way the MCP ecosystem is built makes that graph harder to govern than a normal software supply chain. New MCP servers go up every week, often from individual developers or small teams with no formal security review process behind them. A single AI coding tool can connect to dozens of these servers at once, and each one drags in its own packages, its own credentials, its own blast radius.

The Postmark MCP backdoor is the clearest proof this isn't theoretical. It was the first malicious MCP server caught running in the wild, and it silently exfiltrated emails for about eight days before anyone caught it. Eight days of quiet data theft through a server that looked, on the surface, like any other integration.

Path traversal and argument injection vulnerabilities turned up in Anthropic's own Git MCP server, disclosed in January 2026, which should worry enterprise security teams more than a backdoor planted by an unknown developer. Anthropic wrote the protocol. If vulnerabilities can ship from the team that defines MCP itself, trusting a server because of who published it stops being a reasonable security control.

Organizations pulling from public MCP registries without signature verification, or without a private, curated registry of their own, are accepting supply chain risk they have no way to see. Most existing software composition analysis tooling watches source code. It isn't watching what a tool actually returns at runtime, which is exactly where a poisoned dependency does its damage.

MCP05 (Command injection and execution): what happens when an agent constructs system commands from untrusted input

Command injection is one of the oldest vulnerability classes in software, and MCP doesn't change the mechanism so much as it raises the stakes. Many MCP servers run on local machines with local execution privileges, so a bug that would be a contained web-application flaw anywhere else turns into full system compromise here.

The setup is straightforward: agents build system commands, shell scripts, API calls, or code snippets using inputs that can include user prompts, retrieved context, or third-party data, and any of those inputs can carry a payload designed to look harmless. A document fetched for context, a field pulled from a database, a response from another tool, any of it can carry the instruction that breaks the system.

What makes this specifically dangerous in MCP is the absence of a network boundary. A command injection that succeeds on a server sitting behind a firewall still has to find a way to pivot past that firewall to do real damage. An MCP server running locally has no such boundary to cross. The injection has direct access to the host system the moment it executes, no pivot required. The mcp-remote case covered under supply chain risk above is the clearest disclosed example of this pattern, where the malicious command triggered on connection initiation, before the user had done anything else.

The controls that reduce this exposure are familiar ones, applied with more urgency: run MCP tools inside sandboxed or containerized environments, validate every input rigorously before any tool is allowed to construct a command from it, and refuse to execute raw code passed through tool arguments. None of these are exotic. What's exotic is how much damage a lapse in any one of them can do once it's running with local execution privileges.

MCP06 (Intent flow subversion): how attacker-controlled content hijacks agent reasoning

Intent flow subversion is MCP's version of prompt injection, and it works because an MCP agent treats whatever it reads, documents, database rows, web pages, the output of another tool, as trusted instruction text. Anyone who controls that content gets a direct channel into how the agent reasons, bypassing the user's input.

That's the structural break from classic prompt injection. The adversarial payload doesn't need to reach the model through something the user typed. It can arrive through a tool result, a fetched document, or a database row the agent pulls in while doing a completely legitimate task. The user never sees the attack happen, because they never typed anything suspicious.

A disclosed attack against GitHub's MCP integration shows how little technical sophistication this requires. An attacker wrote a public GitHub issue, plain text, no exploit code, and the agent read that issue body as an instruction. That instruction was enough to hijack the agent's reasoning and exfiltrate private repository contents. No vulnerability was exploited in the conventional sense. The agent did what the text told it to do, with no way to tell a legitimate task instruction apart from an attacker's sentence sitting inside a public field.

Multi-step agentic workflows turn a single hijack into a chain reaction. Once an agent's reasoning is subverted, it can redirect downstream tool calls, pass attacker-chosen arguments to other MCP servers it's connected to, or produce outputs that trigger further automated actions elsewhere in the pipeline. The compromise doesn't stay contained to the first step. It propagates through every step that trusts the output of the step before it.

For an enterprise, this means every piece of content an agent is authorized to read is also a potential injection surface: databases, ticketing systems, email, internal documents, all of it. Agents deployed across enterprise systems read widely by design, so the attack surface grows in direct proportion to how much data access the agent has been given.

MCP07 (Insufficient authentication and authorization)

A large share of production MCP servers shipped without meaningful authentication between their own components, and the protocol's recent move to OAuth 2.1 closes that gap in the specification but not in actual enterprise deployments. The MCP Inspector vulnerability, tracked as CVE-2025-49596, is the clearest case on record: a developer tool that required no authentication at all between its components before version 0.14.1, letting a malicious actor execute stdio commands against it directly.

The MCP release candidate published May 21, 2026, and finalized as the 2026-07-28 specification, tightens several pieces of this. MCP servers are now formally defined as OAuth 2.1 resource servers, a designation first introduced in the 2025-06-18 spec and tightened further in this release. Servers must implement OAuth 2.0 Protected Resource Metadata under RFC 9728, letting clients automatically discover the correct authorization server. Clients must implement Resource Indicators under RFC 8707, binding tokens to one specific MCP server so a malicious server can't obtain a token meant for somewhere else, a requirement carried forward from the 2025-06-18 spec.

The Enterprise-Managed Authorization extension, now promoted to stable status, lets organizations route access through their own identity provider: users sign in once and reach every approved server without a separate consent prompt for each one. Anthropic, Microsoft, and Okta have adopted it.

None of this closes the gap that matters most once an agent is already inside a system. OAuth 2.1 alignment and the EMA extension only govern whether an agent gets through the front door. They say nothing about what that agent is allowed to do with any single tool call once it's standing in the room. Enterprises still need their own authorization controls at the action level, because the spec update solves entry, not conduct.