OWASP MCP Security Taxonomy

This is a note from my public notes. View the canonical version: OWASP MCP Security Taxonomy.

The OWASP MCP Security Taxonomy is an open, vendor-neutral classification of the security risks of the Model Context Protocol (MCP): risks, weaknesses, attack patterns, controls, detections and test cases. It lives in the OWASP/MCP-Taxonomy repository on GitHub, under the GPLv3 License, and is maintained and curated by Vandana Verma Sehgal. Current version: v0.1. Tagline: "A common language for securing agentic AI connections, context, and capability."

Everything sits in a single document (MCP-SECURITY-TAXONOMY-COMPLETE.md, a bit over 2,200 lines). It's written for security engineers threat-modeling MCP hosts, clients, servers and gateways, for developers building MCP servers, for GRC and compliance teams, and for researchers comparing the academic MCP taxonomies.

Why it exists

Agent, client, server, tool, prompt, resource, context, gateway: these words mean different things from one MCP project to the next. The taxonomy fixes the vocabulary so that "the AI did something weird" turns into a diagnosis: which identity failed, which context was trusted, which tool ran, which data moved. From there you can name the framework category and pick the control that prevents it next time.

It treats MCP integrations as privileged application connectors. I agree with that default: a server holding a GitHub token and a shell is a connector with real permissions, whatever the chat UI around it looks like.

What's in v0.1

1. A relationship map of host, client, server, transport (stdio or HTTP) and the backends behind each server (files, APIs, databases, SaaS, shells, cloud)
2. Design principles for authoring entries (see below)
3. A glossary of well over a hundred terms in three families. MCP terms (host, client, tool schema, sampling, elicitation, roots, workspace trust...), AI security terms (direct, indirect and multi-modal Prompt injection, tool poisoning, rug pull, context and memory poisoning, excessive agency, goal hijacking...) and AppSec terms. Each entry has a definition, why it matters for security, and an example
4. Common confusions: host vs client vs server, tool vs resource vs prompt, prompt injection vs tool poisoning vs context poisoning, CVE vs CWE vs CVSS vs EPSS
5. A legacy 7-domain overview for high-level risk navigation: identity and authorization, context and memory, tool interface and execution, transport and protocol, supply chain and registry, observability and governance, agentic behavior and human control
6. An OWASP MCP Top 10 mapping with examples, impacts and controls
7. Root-cause tags aligned with real CVEs
8. External crosswalks to academic taxonomies (MCP-38, MCPShield, MCPThreatHive, MCP-DPT, MCPSecBench), the IETF draft on MCP security considerations, the MCP specification and OWASP's guide for using third-party MCP servers

The 11-domain model

The design principles define eleven top-level domains, MCP-ST-01 to MCP-ST-11:

1. Architecture & Trust Boundaries
2. Identity, Authorization & Consent
3. Context & Prompt Integrity
4. Tool Invocation & Execution Safety
5. Resource & Data Exposure
6. Transport, Session & Protocol Security
7. MCP Server & Supply Chain Security
8. Client, Host & Local Environment Security
9. Observability, Logging & Privacy
10. Runtime Governance & Policy Enforcement
11. Testing, Assurance & Compliance

It borrows from existing frameworks on purpose: outcomes and categories from NIST CSF, the tactics-and-techniques style of MITRE ATT&CK and ATLAS, CWE for weaknesses, and OWASP's own chain of risk, scenario, impact, prevention and testing.

To reach stable status, an entry needs a long list of fields: affected MCP components, trust boundaries, weakness type, attack patterns, preconditions, example scenarios, preventive and detective controls, test cases, evidence to collect, and mappings to OWASP MCP, OWASP LLM, CWE, MITRE ATLAS and ATT&CK, NIST CSF, ISO 27001, the EU AI Act and SOC 2. A defense_placement field says which layer should stop the attack.

Some authoring rules are very concrete. Prompt-integrity entries need one direct AND one indirect injection scenario. Tool and data entries need a "toxic flow" example where it applies, meaning a chain of individually allowed tool calls that adds up to exfiltration (the term comes from Invariant Labs). Governance entries must describe runtime authorization on the tools/call path. The anti-patterns are spelled out too: classify everything (the Top 10 alone isn't enough), no vendor product names as categories, no duplicate IDs, never map a domain straight to a CVE.

Caveat: in v0.1 the eleven domains are an authoring structure with nothing in them. No MCP-ST entries are published yet (the "MCP Security Taxonomy v0.1" heading in the glossary is empty), and risk navigation still uses the legacy seven domains. What you can use today is the glossary, the Top 10 mapping and the entry schema.

OWASP MCP Top 10 mapping

Each row also lists the common impact and the defensive controls (short-lived tokens, least privilege, signed tools, SBOMs, allowlisted commands, deny-by-default, immutable audit trails, MCP inventory, context minimization...).

Root-cause tags

The weakness families come from the disclosures collected in mcp-cve-project, Vandana Verma Sehgal's companion CVE index. Each CVE gets one primary tag, plus secondary tags when useful:

• Injection and execution: INJ-CMD, INJ-ARG, INJ-SQL, INJ-KQL/INJ-DSL, INJ-DESER, CODE-EXEC
• File, path and container boundaries: PATH-TRAV, SYMLINK, PREFIX-COLL, K8S-CONFUSE
• Classic web issues on MCP HTTP surfaces: SSRF, OPEN-REDIR, CSRF-XSITE, CORS-BAD, XSS
• Identity, OAuth and authorization: AUTH-BYPASS, AUTHZ-MISS, OAUTH-DCR, OAUTH-CONSENT, SESS-FIX, TOKEN-LEAK
• Availability and parsing: DOS-EX, REDOS, PARSER-DIFF
• Data confidentiality and integrity: X-TENANT, DATA-EXFIL, MODE-BYPASS

Nearly every tag on that list is plain application security: shell injection, path traversal, SSRF, broken OAuth. Tool poisoning and prompt injection get the talks and the blog posts, but the actual MCP CVEs are mostly old bugs in code that runs with too many permissions.

Distinctions worth remembering

• The host is the AI app (Claude Desktop, an IDE, an agent platform). The client is the connector inside it, one per server. Calling the whole app "the client" is the most common mix-up
• Tool = do something (often model-controlled). Resource = bring context. Prompt = guide the workflow (usually user-selected)
• Prompt injection manipulates the instructions the model reads, tool poisoning manipulates tool metadata or behavior, and context poisoning plants malicious data that drives future actions
• A rug pull is a trusted server that turns unsafe after adoption: version 1.0 is read-only, version 1.1 quietly adds an upload feature
• Shadow MCP is unapproved MCP usage that skips review, logging and gateways (the MCP flavor of Shadow AI)
• A malicious instruction is only text until it makes a tool read a secret, run a command or send data out. Tool invocation is where injection does damage; same logic as the Lethal Trifecta for AI Agents

My take

The part I'd use right now is the glossary's "beginner translation" table: host, client, server, tool, resource, prompt, gateway and registry, each paired with the security question to ask. It works as a review checklist before installing any MCP server. I build MCP endpoints myself (the Obsidian CLI REST MCP plugin for Obsidian and the Agentic Resource Discovery Server plugin for Obsidian), so that's the table I'd keep next to the code.

Limits:

• It's v0.1. The eleven domains have no entries, and two domain models (7 and 11) coexist in the same document
• One person curates it, and the companion CVE index comes from the same maintainer. A shared vocabulary needs more contributors before other teams adopt it
• GPL-3.0 is an unusual license for a reference document. Check it before copying large parts into your own docs or tools

Timeline

• 2026-05-26: repository created under the OWASP organization
• 2026-08-27: the actual content lands (glossary, design principles, mappings, root-cause tags)
• 2026-09-06: last update as of early October 2026

References

• Repository: https://github.com/OWASP/MCP-Taxonomy
• Complete reference: MCP-SECURITY-TAXONOMY-COMPLETE.md at the root of the repository (read for this note on 2026-10-04)
• Vandana Verma Sehgal on GitHub: https://github.com/vermava
• Companion CVE index (mcp-cve-project): https://github.com/vermava/mcp-cve-project
• OWASP MCP Top 10: https://owasp.org/www-project-mcp-top-10/
• OWASP, A Practical Guide for Securely Using Third-Party MCP Servers: https://genai.owasp.org/resource/a-practical-guide-for-securely-using-third-party-mcp-servers/
• MCP security best practices: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
• Invariant Labs, Toxic Flow Analysis: https://invariantlabs.ai/blog/toxic-flow-analysis

Related

• Model Context Protocol (MCP)
• MCP Gateway Registry
• Model Context Protocol Registry
• Prompt injection
• Lethal Trifecta for AI Agents
• Least Privilege Principle
• Shadow AI
• Software Supply Chain Security
• Microsoft AI Agent Governance Toolkit
• AI Skill Supply Chain Security

About Sébastien

Ready to get to the next level?