EXECUTIVE SUMMARY
- No existing security framework adequately covers the MCP threat surface. OWASP LLM Top 10, OWASP Agentic Top 10, and MITRE ATT&CK each address parts of the problem, but none captures protocol-layer trust model violations or the compositional attack paths that arise from chained tool calls.
- MCP-38 is the first enumerated, protocol-level threat taxonomy for MCP, classifying 38 distinct threat categories derived from four attack surfaces: User Interaction, Client, Protocol Transport, and Server.
- The core vulnerability is structural. Tool selection and invocation are mediated entirely by natural-language descriptions interpreted at inference time, meaning any attacker who controls text the LLM reads can influence agent behavior without touching application code.
- Real-world incidents validate the taxonomy. The GitHub MCP prompt injection attack and CVE-2025-6514 (arbitrary command execution via crafted OAuth URLs in
mcp-remote) both demonstrate threat categories that existing frameworks cannot cleanly map.
The protocol layer of agentic AI has a security problem. We mapped it across all 38 threats.
The Big Picture
AI agents are no longer confined to chat interfaces. Today they browse the web, write code, query databases, send emails, and invoke external services, often autonomously and in chains with other agents. The infrastructure making this possible is the Model Context Protocol (MCP): introduced by Anthropic in November 2024, it has become one of the de facto standards for connecting large language model-based systems to external tools and data sources. Major platforms including Claude, GitHub Copilot, and Cursor have already adopted it natively. As of early 2026, hundreds of open-source and commercial MCP servers are in active use.
That rapid adoption has created a security gap that the field has not yet closed.
The mechanism that makes MCP powerful is also what makes it dangerous: tool selection and invocation are mediated entirely by free-form natural-language descriptions, interpreted at inference time by an LLM. An attacker who controls any text the LLM reads (a tool description, an uploaded document, a returned API response) can influence agent behavior without ever touching application code. This is structurally new. It has no direct equivalent in classical software security, and no existing framework adequately describes it.
Today, we are releasing MCP-38: A Comprehensive Threat Taxonomy for Model Context Protocol Systems (v1.0), the first enumerated, protocol-level threat taxonomy for MCP, classifying 38 distinct threat categories grounded in both the MCP specification and real-world incidents.
Why Existing Frameworks Fall Short
Before building MCP-38, we systematically assessed how well established frameworks cover the MCP threat surface. The answer was: not well enough.
OWASP LLM Top 10 (2025) covers risks at the LLM component level, including prompt injection, data poisoning, and insecure output handling. These categories are necessary but not sufficient. They do not address the protocol-layer trust model of MCP or the compositional attack paths that arise from chained tool calls across multiple servers.
OWASP Top 10 for Agentic Applications (2026) extends coverage to autonomous agent risks such as goal hijacking and identity abuse. This is closer, but still lacks protocol-level specificity. A threat like a “Rug Pull” (where a trusted server silently replaces its tool descriptions post-deployment) falls across multiple OWASP Agentic categories without a single actionable mapping, making it difficult to engineer against.
MITRE ATT&CK operates at the system-action level, covering file access, process injection, and network connections. It cannot express inference-time, semantic-layer attacks. Forcing MCP threats into ATT&CK requires artificial mappings that obscure the actual mechanism.
NIST AI RMF 1.0 provides governance-level guidance but does not enumerate operational threat categories.
Two real-world incidents crystallize the gap. In early 2025, attackers contributed malicious files to public GitHub repositories. When a developer used an MCP-enabled assistant to read those repositories, the embedded instructions redirected the agent to exfiltrate data from private repositories, bypassing traditional sandbox isolation because the agent itself was the privileged execution engine. Separately, CVE-2025-6514 disclosed a critical command injection vulnerability in the mcp-remote client package: malicious MCP servers could trigger arbitrary command execution on client hosts by supplying crafted OAuth discovery URLs, affecting hundreds of thousands of developer environments. Neither incident maps cleanly to a single entry in any existing framework.
How We Built MCP-38
MCP-38 was derived through a systematic four-phase methodology designed to balance theoretical completeness with empirical relevance.
Phase 1: Protocol Decomposition. We examined every normative element of the MCP specification across four attack surfaces: User Interaction, Client, Protocol Transport, and Server. For each surface, we asked what an adversary could control, inject, forge, or exhaust, and what the consequence would be to the LLM’s decision-making or the system’s integrity.
Phase 2: Framework Cross-Mapping. Each candidate threat was assessed against OWASP LLM Top 10, OWASP Agentic Top 10, MITRE ATT&CK, the MCP Security Bench benchmark, and prior MCP-specific literature. Candidates were classified as Covered, Partial, or Novel, isolating what is genuinely new about the MCP threat surface.
Phase 3: Real-World Incident Synthesis. Theoretical possibility alone is not enough. We validated candidates against four evidence tiers: the NIST NVD CVE database, published security advisories, security research proof-of-concept studies, and community-reported cases in public MCP server registries such as Smithery and Glama. Candidates that could not be matched to any of these tiers were removed.
Phase 4: Categorization. The 38 validated threats are organized into five risk categories based on the structural MCP property each exploits, ensuring each category maps to a distinct class of engineering response.
The Five Risk Categories
Category I: Semantic Manipulation & Poisoning. MCP’s core attack surface is that the LLM selects tools based entirely on natural-language description and inputSchema fields that are unconstrained, unvalidated, and invisible to most monitoring systems. Threats here include Tool Description Poisoning (MCP-10), Full Schema Poisoning across all JSON schema fields (MCP-11), Resource Content Poisoning (MCP-12), Tool Shadowing and Name Spoofing (MCP-13 and MCP-14), and Preference Manipulation Attacks that statistically bias tool selection through crafted metadata (MCP-15).
Category II: Prompt Injection & Boundary Breaking. MCP agents use tools to fetch external content such as files, web pages, and database records. The protocol does not enforce an instruction-data boundary. Threats here include Direct Prompt Injection (MCP-19), Indirect Prompt Injection via data consumed through tools (MCP-20, as demonstrated in the GitHub Data Heist), Parasitic Toolchain attacks that chain individually benign tools into exfiltration paths (MCP-17), Command Injection (MCP-07), File System Exposure and Path Traversal (MCP-08), and Sandbox Escape (MCP-37).
Category III: Identity, Trust & Supply Chain. MCP has no mandatory cryptographic server identity. Trust is established purely by server URL or local path. Threats here include Identity Spoofing (MCP-01), Credential and Token Theft (MCP-02), Session Hijacking (MCP-03), Rug Pull attacks where servers silently replace tool definitions post-audit (MCP-16), Supply Chain Compromise via poisoned registries (MCP-26), Missing Integrity Verification (MCP-27), and DNS Rebinding (MCP-31).
Category IV: Access Control & Logic Drift. Agentic workflows involve autonomous multi-turn planning without deterministic guardrails. Threats here include Privilege Escalation and the Confused Deputy problem (MCP-04), Excessive Permissions and Overexposure (MCP-05), Consent Fatigue (MCP-23), Overreliance on LLM Safeguards as security controls (MCP-21), Planning and Agent Logic Drift through multi-turn manipulation (MCP-35), and Multi-Agent Context Hijacking (MCP-36).
Category V: Data Exfiltration & Resource Abuse. Agents can aggregate and act on data across disparate tools in ways that evade network-level DLP systems, which do not inspect JSON-RPC payloads. Threats here include Data Exfiltration via Tool Output (MCP-24), Privacy Inversion through cross-tool data aggregation (MCP-25), Unrestricted Network Access and Lateral Movement (MCP-32), Resource Exhaustion and Denial of Wallet attacks (MCP-33), and Invisible Agent Activity due to absent observability (MCP-38).
The Coverage Gap in Today’s Tooling
We evaluated five representative MCP security tools against the full 38 categories, including scanners (MCP-Scan, Enkrypt AI, AI-Infra-Guard) and runtime proxies (Akto, Promptfoo). The combined union of all five covers at most 18 of 38 categories. No evaluated tool addresses MCP-15 (Preference Manipulation), MCP-20 (Indirect Prompt Injection), MCP-22 (HITL Bypass), MCP-23 (Consent Fatigue), MCP-35 (Agent Logic Drift), MCP-36 (Multi-Agent Context Hijacking), or MCP-38 (No Observability). These are precisely the threats in the Semantic, Logic Drift, and Observability categories most distinctive to MCP’s agentic operating model.
This gap is the core motivation for publishing MCP-38 openly. The community needs a shared, precise vocabulary before it can build comprehensive defenses.
What Comes Next
MCP-38 v1.0 provides the definitional and empirical foundation for the next layer of work: automated threat intelligence platforms, red-team evaluation suites, runtime policy enforcement, and registry-level scanning. Each of the 38 categories is accompanied by concrete attack scenarios, real-world evidence, and mitigation guidance designed to translate directly into engineering decisions.
We are releasing MCP-38 as an open research contribution and welcome collaboration from the security community, MCP ecosystem builders, and practitioners deploying agentic systems in production environments.
Read the full paper on arXiv: https://arxiv.org/abs/2603.18063
