Researchers Publish MCP-38 Security Taxonomy

Researchers published MCP-38 on March 18, a 38-category threat taxonomy for Model Context Protocol systems that puts protocol-specific security risks into a single naming scheme. For teams building MCP-based agents, tools, and connectors, the practical value is straightforward: you now have a security model that matches how MCP actually fails in production, not just how generic web apps or standalone LLM prompts fail. You can read the paper directly in arXiv:2603.18063.

Taxonomy Scope

MCP-38 defines 38 threat categories, numbered MCP-01 through MCP-38, and frames them around MCP’s distinct attack surface. The paper identifies risks including tool description poisoning, indirect prompt injection, parasitic tool chaining, and dynamic trust violations.

Those labels matter because MCP systems operate across multiple trust boundaries at once: model, client, server, tool metadata, authorization flow, and downstream side effects. If you already work with function calling or agent tool use, the difference is immediate. MCP adds protocol structure around those interactions, which means attackers can target the protocol layer, not just the prompt layer.

Methodology and Framework Mapping

The taxonomy uses a four-phase methodology: protocol decomposition, multi-framework cross-mapping, real-world incident synthesis, and remediation-surface categorization. It also maps MCP-specific threats against three familiar security lenses: STRIDE, the OWASP Top 10 for LLM Applications (2025), and the OWASP Top 10 for Agentic Applications (2026).

That cross-mapping is useful for security teams that already run threat modeling reviews with established frameworks. You do not need to abandon existing controls. You need a translation layer that captures MCP-native failure modes that broader taxonomies flatten into generic prompt injection or access-control bugs.

Why Generic LLM Security Models Fall Short

The paper’s core argument is that MCP introduces a semantic attack surface. This is the important shift.

In a conventional LLM app, prompt injection is often modeled as untrusted text influencing generation. In an MCP system, untrusted text can arrive as tool descriptions, capability metadata, elicited URLs, installation flows, or intermediate outputs that affect later tool calls. Once agents begin selecting, sequencing, and authorizing tools dynamically, the system’s security posture depends on how context is propagated and trusted at each step.

This is where context engineering and security meet. If your agent treats every tool description or server-provided hint as equally trustworthy, the protocol becomes an attack amplifier.

Alignment With MCP’s Existing Security Work

MCP-38 arrived as the protocol’s own security model was already tightening. MCP’s security best practices already call out the confused deputy problem. The authorization spec requires MCP servers to implement OAuth 2.0 Protected Resource Metadata, RFC9728, and requires clients to use that metadata for authorization-server discovery.

Earlier spec changes also required MCP clients to implement Resource Indicators (RFC 8707) to prevent malicious servers from obtaining access tokens. Those controls map directly to the paper’s view that MCP risk is created by trust delegation, context propagation, and protocol-mediated tool access.

Where MCP-38 Fits in Practice

The taxonomy is most useful when you translate it into design reviews and test plans.

Area	Existing common practice	MCP-38-driven adjustment
Prompt injection testing	Test user and document inputs	Test tool descriptions, server metadata, and indirect tool outputs
Access control review	Check OAuth and token storage	Check token audience, discovery flow, server identity, and delegation path
Agent evaluation	Measure task success and hallucination rate	Add adversarial tool-chain and trust-boundary test cases
Tool onboarding	Validate schema correctness	Validate provenance, naming clarity, permissions, and installation safety

If you build AI agents or multi-agent systems, this affects more than your security team. It changes how you model tool trust, how you gate actions, and how you evaluate agent behavior before deployment.

Immediate Engineering Implications

Treat tool metadata as untrusted input. Tool descriptions, annotations, and capability claims should go through the same scrutiny you already apply to user content.

Separate selection trust from execution trust. A model can use metadata to rank candidate tools, but execution should still require policy checks on scope, token audience, and allowed side effects.

Test chained failure modes. Parasitic tool chaining implies that individually safe tools can become unsafe when one tool’s output steers another tool’s invocation. This needs explicit evaluation coverage, similar to work on evaluating agents.

Harden installation and authorization flows. Local server installation, third-party OAuth, and out-of-band browser flows are part of the security boundary in MCP, not setup details.

MCP-38 gives you a concrete checklist structure for that work. If your roadmap includes MCP adoption, fold the 38-category taxonomy into architecture review, red-team scenarios, and acceptance tests before you add more tools or broader permissions.