Which of the following are categories in the community maintained OWASP MCP / Agentic AI risk taxonomy (2025)?
The MCP-specific risks are tool poisoning, excessive permissions, rug pull, and confused deputy. SQL injection and weak training data are generic distractors, not MCP categories.
Imagine hiring a contractor who hands you a list of jobs they can do. A poisoned list hides sneaky instructions in the small print, so tool poisoning. A contractor who keeps the master key to your whole house when they only needed the garage has too much access, so excessive permissions. One who swaps the job list for a worse one after you sign the contract is pulling the rug. One who uses your trust to slip into rooms they were never meant to enter is a confused deputy. Those four are real MCP worries. A clumsy database query or a model trained on thin data are real problems elsewhere, but they are not on this contractor-trust checklist.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Multi-select security questions like this one are not really testing whether you can recall a list. They test whether you can scope a threat model. The OWASP MCP Top 10, published in 2025, is a taxonomy of risks that arise specifically from the Model Context Protocol's architecture: a host LLM application talking to one or more capability servers over JSON-RPC, dynamically discovering and invoking their tools.
The distractors in this question are deliberately plausible. SQL injection and insufficient training data are both real problems an engineer encounters. The skill being probed is whether you can say, precisely, why they do not belong in an MCP-specific list while four other options do.
This deep dive walks each genuine category, explains the seam in MCP's trust model that it exploits, pairs it with a concrete defense, and then explains why the two distractors fall outside the taxonomy.
Why MCP needs its own threat taxonomy
MCP introduces a trust relationship that classic web security never had to model. A host application embeds an LLM, then connects to external servers that advertise tools, resources, and prompts. Crucially, the content those servers return, including the human-readable descriptions of their tools, flows into the model's prompt and influences its behavior.
That creates a new attack surface. The model is a confused, eager to help executor, and the servers are semi-trusted third parties. A description string is no longer inert documentation; it is effectively instruction text the model may act on. A server's granted scope is no longer just an API key; it is a capability the model can be steered into wielding.
General web security covers the transport and the database, but it has no vocabulary for an LLM that obeys text embedded in a tool catalog. That gap is exactly what the OWASP MCP Top 10 fills, which is why a generic flaw like SQL injection sits outside it even though it can travel through an MCP tool.
The deeper reason MCP earns a bespoke list is that it collapses two roles that used to be separate. In a traditional API, a human developer reads the docs and writes the client code; the runtime never reinterprets documentation. In MCP, the LLM is both the reader of the docs and the writer of the calls, in real time, with no human in the loop per request. That fusion is what turns a description field into executable influence and a granted scope into a steerable weapon. Every genuine category on the list traces back to this single architectural fact, and that is the lens this deep dive uses to sort the real risks from the distractors.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Category | MCP seam exploited | In OWASP MCP Top 10? |
|---|---|---|
| Tool poisoning | Tool description metadata trusted by the model | Yes |
| Excessive permissions | Server scope broader than the task needs | Yes |
| Rug pull | Tool definition mutated after approval | Yes |
| Confused deputy | Legitimate privileges abused on attacker's behalf | Yes |
| SQL injection | Generic query-building input validation | No, general web risk |
| Insufficient training data | Model quality, not a protocol channel | No, unrelated |
Real products, models, and research that use this idea.
- Anthropic's MCP spec added an OAuth 2.1 authorization layer in 2025 to curb excessive-permission and confused-deputy patterns on remote servers.
- Security researchers demonstrated tool-poisoning proofs of concept against early Cursor and Claude Desktop MCP integrations in 2025, hiding directives in tool descriptions.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you defend against a rug pull where a server mutates a tool after the user already approved it?
Pin the approved tool schema and description hash; re-prompt the user on any diff; audit advertised definitions in CI before each release.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Selecting SQL injection because MCP tools can run queries. The risk is real, but it is a generic web flaw, not an MCP-specific OWASP category.
60 second bullets to scan on the way to the call.
The four genuine MCP risk categories in this question
Why tool poisoning is effectively prompt injection with provenance
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.