The OWASP MCP Top 10, explained in plain English

The OWASP MCP Top 10 is a list of the ten most serious security risks in systems built on the Model Context Protocol, the standard AI agents use to connect to tools and data. In order, they are: token mismanagement and secret exposure, privilege escalation via scope creep, tool poisoning, supply chain attacks, command injection, prompt injection through context, weak authentication and authorization, missing audit logs, shadow MCP servers, and context over-sharing. The list is still a beta, so it can change. Below, each risk is explained in plain English with a real case or a concrete fix.

What the OWASP MCP Top 10 is, and what beta means

OWASP, the nonprofit behind the well-known web application Top 10, started the MCP project to describe the risks specific to agents and their servers. Its project page lists the 2025 edition as being in phase 3, beta release and pilot testing, with feedback still being collected. The GitHub overview calls it a living document that will evolve.

That matters in practice. Even the names move: the OWASP project page calls MCP06 "Prompt Injection via Contextual Payloads", while the overview on GitHub calls it "Intent Flow Subversion". Treat the IDs as a shared vocabulary for your team and check the current wording before you put an item in a policy or a report.

The list is written for the people who build and approve agent setups: security engineers, platform teams and the developers who add servers to their tools. It does not rank the items by how often they happen. Several of them overlap in real attacks, so a single incident often touches three or four entries at once, as the cases below show.

Secrets and permissions: MCP01 and MCP02

MCP01: Token mismanagement and secret exposure

Agents need keys to reach other systems, and those keys end up in the wrong places: typed into config files, kept in long-lived sessions, or written to logs. OWASP's examples include an attacker asking an agent to repeat credentials from an earlier session, and someone reading tokens out of tool-call logs. VS Code's own documentation says a personal configuration file is not a secret store. The fix is to keep secrets in a vault or the client's secret storage, use short-lived tokens, and redact them from logs.

MCP02: Privilege escalation via scope creep

Permissions granted "just for now" tend to stay and grow. An agent ends up holding far more access than any single task needs. In the GitHub MCP case published by Invariant Labs in May 2025, an agent with a token that could reach every repository read a malicious public issue and leaked private repository data. The fix is narrow scopes per task, such as one repository per session.

Poisoned tools and supply chain: MCP03 and MCP04

MCP03: Tool poisoning

An attacker hides instructions in a tool's description, schema or output. The model reads them; the user usually does not. Invariant Labs showed an innocent-looking "add" tool whose description told the agent to read ~/.ssh/id_rsa and pass it along in a hidden parameter. OWASP's guidance is to scan descriptions before connecting, pin reviewed tool definitions with a hash, and require review when they change.

MCP04: Software supply chain attacks and dependency tampering

MCP servers are packages, and packages can be hijacked or impersonated. postmark-mcp, the first malicious MCP server found in the wild, published 15 clean versions before version 1.0.16 began blind-copying every email it sent to the attacker. Pin versions, check that the publisher is the real project, and review each update before it reaches developers.

Commands and prompts: MCP05 and MCP06

MCP05: Command injection and execution

Agents and their clients build commands from input that may not be trustworthy. CVE-2025-6514, rated 9.6, let a malicious server run commands on a developer's machine through mcp-remote versions 0.0.5 to 0.1.15, fixed in 0.1.16. The MCP specification now says clients must show the exact command before starting a local server and must not open URLs through a shell.

MCP06: Prompt injection via contextual payloads

Instructions hidden in content the agent reads, such as a web page, a file or an issue, act as a second set of orders that pulls the agent away from what the user asked. The GitHub case above is an example: the attack arrived as ordinary issue text. Keep untrusted content away from agents holding powerful tools, and require a person to confirm actions that send data out.

Access and visibility: MCP07 and MCP08

MCP07: Insufficient authentication and authorization

Servers, tools or agents that fail to check who is calling them open paths an attacker can walk through. The MCP specification forbids "token passthrough", where a server accepts tokens that were never issued to it and forwards them downstream. It also recommends the stdio transport for local servers, or an authorization token for local HTTP servers, so other processes on the machine cannot use them.

MCP08: Lack of audit and telemetry

Without records of which tools ran, with what inputs, there is nothing to investigate after an incident. OWASP recommends detailed logs of tool invocations, context changes and user-agent interactions, kept in immutable audit trails. Check whether your clients can export tool-call logs before you need them.

Shadow MCP servers and over-sharing: MCP09 and MCP10

MCP09: Shadow MCP servers

OWASP describes these as unapproved MCP deployments running outside security governance, often with default credentials, permissive settings or unsecured APIs. In most companies they start the same way: a developer adds a server to Cursor or Claude Code to get a job done. Nothing is wrong with the developer's intent, but security cannot review a server it does not know exists. Our guide shows how to find MCP servers on developer machines for each major coding agent.

MCP10: Context injection and over-sharing

Context that is shared, persistent or loosely scoped can carry one user's or one task's sensitive information into another. The fix is to scope context to a task, avoid long-lived shared memory for sensitive work, and give servers only the folders and data the job needs.

How to check your own servers against the list

A list of risks is only useful if you can check against it. Start with MCP09, because an inventory is what every other check runs against. Then go server by server: are secrets out of config files (MCP01), are tokens narrow (MCP02), are tool descriptions clean and pinned (MCP03), is the version pinned and the publisher real (MCP04). Our MCP security checklist turns the list into 12 concrete checks, each mapped to the item it covers, and our record of every malicious MCP server reported so far shows several of these risks in real attacks.

If your team is small, a sensible order is inventory first, then secrets and token scope, then version pinning and description review, then logging. Those four steps cover the entries behind most of the public incidents so far, and none of them needs new software to start.

Record the result for each server with a line of reason. Some servers fail a check for good reason; a deploy tool needs a powerful token. What matters is that the decision was made on purpose.

The OWASP agentic AI top 10 is a separate list that covers AI agents as a whole rather than MCP specifically, and most teams will want to read the two side by side.