The Model Context Protocol went from a niche spec to the default way AI clients reach real tools in about a year — and the security research caught up fast. In 2025 the OWASP Foundation published a dedicated MCP Top 10, cataloguing the ten risk categories most likely to break an MCP deployment. It sits alongside OWASP’s Top 10 for LLM Applications but is narrower and more protocol-specific: it targets the tool-discovery, context-passing, and tool-invocation layer between an agent and your systems.
The list is in beta (led by Vandana Verma Sehgal) and numbered MCP01:2025 through MCP10:2025. Here’s what each one actually means for someone connecting or running MCP servers — and, honestly, which of them a gateway can help with and which it can’t.
The ten risks, in plain terms
- MCP01 — Token Mismanagement & Secret Exposure. API keys and OAuth tokens that get logged, committed to git, shared across a team, or stored in a plaintext
mcp.json. The classic MCP footgun, because one server often holds the keys to a whole SaaS account. - MCP02 — Privilege Escalation via Scope Creep. A server (or a single OAuth consent) that grants far more than the task needs. Because MCP consent is usually scoped to the whole server, not one tool, “read my calendar” quietly becomes “everything this server can do.”
- MCP03 — Tool Poisoning. Malicious instructions hidden in a tool’s description — which the model reads as commands. This is the attack that makes MCP uniquely dangerous; we cover it in depth in prompt injection & tool poisoning.
- MCP04 — Software Supply Chain Attacks & Dependency Tampering.The server package (or one of its dependencies) is compromised, typo-squatted, or silently updated. You’re running someone else’s code with live access to your data.
- MCP05 — Command Injection & Execution. A server that passes tool arguments into a shell, SQL query, or eval without sanitizing them — turning a tool call into remote code or data execution.
- MCP06 — Intent Flow Subversion. The agent’s plan gets steered off course — one tool’s output (or injected content) manipulates which tools get called next, chaining benign actions into a harmful sequence.
- MCP07 — Insufficient Authentication & Authorization. Servers with no auth, weak auth, or no per-user identity — so anyone who can reach the endpoint can use it, and you can’t tell who did what.
- MCP08 — Lack of Audit and Telemetry. No record of which tools ran, with what arguments, on whose behalf. When something goes wrong (or an auditor asks), there’s nothing to look at.
- MCP09 — Shadow MCP Servers. Servers connected by individuals with no review, inventory, or oversight — the new shadow IT. You can’t secure what you don’t know is connected.
- MCP10 — Context Injection & Over-Sharing. Untrusted content smuggled into the model’s context, and servers that return far more data than the task needs — both widening what an attacker can influence or exfiltrate.
What actually causes these — three buckets
The ten fall into three groups, and the distinction matters because they call for different defenses:
1. Server-code flaws (you can’t patch these from outside)
MCP04 (supply chain) and MCP05 (command injection) live inside the server’s own code and dependencies. No amount of client configuration fixes a server that shells out unsanitized input. Here the only real defenses are provenance (run code you can inspect and trust) and blast-radius control (assume it can be compromised, and limit what it can reach).
2. Trust-and-instruction attacks
MCP03 (tool poisoning), MCP06 (intent subversion), and MCP10 (context injection) all exploit the fact that the model treats text — tool descriptions, tool outputs, fetched content — as instructions. These are the hardest to catch by eye, because the malicious text is often invisible in a casual read.
3. Access, identity, and visibility gaps
MCP01 (tokens), MCP02 (scope creep), MCP07 (auth), MCP08 (telemetry), and MCP09 (shadow servers) are all about who can do what, with which credentials, and whether anyone can see it afterward. This is classic access-control and observability work — applied to a new surface.
Which of these a gateway actually helps with
A single control point in front of your MCP servers — an MCP gateway — is the natural place to address the third bucket and contain the first two. Being honest about the split:
- Directly addressed: per-user OAuth instead of shared keys (MCP01, MCP07); per-tool allow / ask / block and least privilege so one connection can’t do everything (MCP02); a scan for hidden instructions in tool descriptions before a server goes live, plus drift re-checks when they change (MCP03); a complete audit log of every call (MCP08); and an inventory with provenance so nothing runs un-reviewed (MCP09).
- Contained, not cured: for server-code flaws (MCP04, MCP05) and intent/context attacks (MCP06, MCP10), a gateway can’t fix the server — but keeping destructive tools behind an approval step, defaulting to read-only, and logging everything shrinks the blast radius when one goes wrong.
- Not a silver bullet: nothing here removes the need to vet a server before connecting it. Use a checklist for the first line of defense; use governance for the ongoing one.
The bottom line
The OWASP MCP Top 10 is a useful map precisely because it separates the MCP-specific risks (tool poisoning, shadow servers, context over-sharing) from the familiar ones wearing new clothes (tokens, scopes, auth, logging). Most teams can close the majority of it with two moves: vet each server before it connects, and route everything through one governed control point that enforces least privilege, scans for poisoned tools, and logs every call. That’s the gap a gateway like gate is built to fill — and it’s exactly why we publish a security scan verdict on every server, not just a connect button.