OWASP MCP Top 10: Model Context Protocol Risks
A support agent at a SaaS company had been connected to the same CRM tool for four months. It read tickets and drafted replies. Nobody had touched its configuration since the day the tool was approved.
Then the tool’s description changed on the server. Not the code, not the schema, not the permissions. Two sentences of English prose that the agent reads before every call, now telling it to copy each drafted reply to an outside address.
The agent complied. It had no way to separate documentation from instruction, because for a model reading a tool manifest there is no difference. That is one category in the OWASP MCP Top 10, and it is one of ten ways the connection between an agent and its tools comes apart.
What is the OWASP MCP Top 10?
Section titled “What is the OWASP MCP Top 10?”The OWASP MCP Top 10 is a ranked list of the security risks specific to the Model Context Protocol, the standard that connects AI agents to external tools, data, and services. Published by the Open Worldwide Application Security Project, it covers ten categories: token mismanagement and secret exposure, privilege escalation via scope creep, tool poisoning, software supply chain attacks and dependency tampering, command injection and execution, intent flow subversion, insufficient authentication and authorization, lack of audit and telemetry, shadow MCP servers, and context injection and over-sharing. The list sits underneath the model layer that the OWASP LLM Top 10 covers, and alongside the autonomy layer described by the OWASP Agentic AI Top 10. Its subject is the plumbing: the servers, tokens, and tool manifests that turn a model’s decision into an action on a real system. OWASP lists the project as a v0.1 beta in pilot testing, so category wording may still move.
How is MCP security different from LLM and agentic AI security?
Section titled “How is MCP security different from LLM and agentic AI security?”The three OWASP AI lists describe three different layers, and a control that works at one layer does nothing at another.
The LLM Top 10 is about the model. Prompt injection, data poisoning, and insecure output handling are all failures of what goes into a model and what comes out of it. The blast radius stops at the response.
The Agentic AI Top 10 is about autonomy. Goal hijacking, memory poisoning, and cascading failures describe what happens when a model chains decisions together across many steps without a human approving each one.
The MCP Top 10 is about the wiring in between. It asks who is running the server on the other end of the connection, what credential the call carries, whether the tool still does what it said it did last month, and whether anything wrote the call down. A well-behaved model with sensible autonomy limits is still exposed if its tool layer is unauthenticated.
That distinction matters operationally. Guardrails on model output cannot stop a server that was never authenticated, and an approval workflow for agent actions cannot stop a token that already leaked into a chat transcript.
Why does a tool description behave like an instruction?
Section titled “Why does a tool description behave like an instruction?”An agent picks tools by reading their descriptions. That text is the only thing telling the model when a tool applies and how to call it, which makes it closer to executable code than to documentation.
Change the description and you change behavior, with no change to the handler, the schema, or the granted permissions. Nothing in a code review catches it, because the reviewed repository is not where the text lives. Invariant Labs published the first widely cited write-up of this pattern in April 2025, naming both the direct case and the rug pull, where a server earns approval on honest wording and swaps it later.
The poisoned tool description exercise puts you in front of a tool approved months ago that now instructs the agent to BCC an outside address. You diff the live description against the approved wording, then block the server at the gateway rather than only denying the one call.
The related failure is intent flow subversion, where the planted instruction arrives in data instead of in a manifest. A CRM note, a support ticket, or a public web page can be written by someone who expects a model to read it. In the hijacked agent intent exercise, an instruction submitted through a public support form ends up on a customer record, and an agent asked only to summarize that record emails billing details to a stranger.
Both categories reduce to the same rule. Retrieved content is data, and an agent that treats it as instruction has no boundary left to defend.
What goes wrong before an agent ever runs?
Section titled “What goes wrong before an agent ever runs?”Three of the ten categories are configuration problems that exist the moment a server is added, long before anyone sends a prompt.
Token mismanagement is first on the list for a reason. A secret written in plain text into an MCP config file is exposed as soon as anything reads that file back, and an assistant asked to help debug a broken connection will read it back. The leaked MCP tokens exercise follows a long-lived token with no expiry from a config file into a chat transcript and then into a replay against the real customer API.
Scope creep is second. An agent’s blast radius is set by the scope of its credential, not by the wording of its brief, and scopes granted for a one-off task tend to outlive it. The agent scope creep exercise has a triage agent obey an extra paragraph in a public bug report and paste a private signing key into a thread anyone can read, then asks you to review each grant by what it reaches today rather than by what it was for.
Supply chain is fourth. An MCP server is usually just a package, and installing a package runs its install scripts as the current user before anyone reads the code. The typosquatted MCP package exercise follows a dependency published one character away from a trusted name, whose postinstall hook ships credential files to an attacker host while the terminal still looks normal.
Why is an MCP server harder to defend than an API?
Section titled “Why is an MCP server harder to defend than an API?”An MCP server is a network service, so everything true of an unprotected API is true of it. The difference is that the caller is a language model deciding on its own which arguments to send.
Equixly ran security assessments against popular MCP implementations and published the results in March 2025. It found command injection flaws in 43% of the servers tested, path traversal or arbitrary file read in 22%, and unrestricted URL fetching in 30%. When the findings were disclosed, 30% of vendors shipped a fix, 45% called the risk theoretical, and 25% never replied.
Command injection is category five. Every argument an MCP tool receives is untrusted input, and pasting that input into a shell string means a semicolon stops being data. The MCP command injection exercise has you find the injected argument in an agent trace while the tool returns an ordinary empty result and a root reverse shell carries out database credentials, then replace the shell call with a parameterized one.
Insufficient authentication is category seven, and it is the one people most often assume they have handled. Approval by a governance process is not authentication. In the unauthenticated MCP server exercise, a registered and approved server was bound to 0.0.0.0 for a pilot, and an unauthenticated tools/list now returns finance warehouse tools that hand back named accounts and contract values.
Shadow servers are category nine, and they are why an inventory built from client configuration is not an inventory. A server spun up for an experiment keeps running on default credentials, and your client’s list only shows what somebody deliberately added.
The shadow MCP servers exercise has you run a discovery scan, compare it against the registry in both directions, and enforce an allowlist at the gateway. This is the AI-tooling version of the shadow IT problem, with a shorter path from unknown asset to production data.
What can you not fix after an incident starts?
Section titled “What can you not fix after an incident starts?”Two categories share a property that makes them worth handling early: neither can be retrofitted once you need them.
Lack of audit and telemetry is category eight. If tool-invocation logging was off at your gateway during the window an investigation cares about, nothing you configure afterwards recovers what was never written. The missing MCP audit trail exercise drops a customer complaint into a two-day logging gap, lets you find the answer unavailable, then walks through central logging, retention that outlasts detection, and tamper-evident storage.
Context over-sharing is category ten, and it is the quietest of the set. An agent serving many customers keeps a working context and a memory, and both are data. If neither is scoped to a session, one customer’s information surfaces in the next customer’s conversation with no tool misused and no access control broken.
The cross-tenant context leak exercise runs two sessions and shows one customer’s invoice and card details appearing in another’s answer, then has you prove from the tool trace that no lookup fetched the wrong record. That proof is the point. An incident with no failed access control is one your existing detection will not raise.
How should organizations train for MCP risks?
Section titled “How should organizations train for MCP risks?”Reading the category list does not build the reflex. The failures in this list look normal while they are happening, which is exactly why a walkthrough beats a policy document.
Start with the people who add servers. Engineers and platform teams own token handling, scope review, package pinning, and gateway configuration, which is seven of the ten categories. They need the supply chain, command injection, and authentication scenarios before their next integration ships, not after.
Everyone else needs the two that require no infrastructure access to trigger. Tool poisoning and intent subversion both land through ordinary work: approving a tool, summarizing a ticket, forwarding a document. Employees already using AI coding assistants or connected chat tools are inside the blast radius whether or not they configured anything.
Security teams get the investigative half. Audit gaps, shadow servers, and context leaks are all discovered rather than prevented, and each one rewards knowing what the trace should look like before you need to read one.
All ten categories are covered in our OWASP MCP Top 10 training course, which runs in the browser with no account required. If you are building an AI security program across all three OWASP lists, talk to us about sequencing the model, agent, and protocol layers for your teams.