Breaking the Protocol: Security Analysis of the Model Context Protocol Specification and Prompt Injection Vulnerabilities in Tool-Integrated LLM Agents
First formal security analysis of MCP. Three architectural defects — no capability attestation, bidirectional sampling without origin authentication, implicit trust propagation across servers — measured over 847 attack scenarios on 5 implementations: MCP amplifies attack success 23-41% vs equivalent non-MCP integrations. Proposed MCPSec extension: ASR 52.8% -> 12.4% at 8.3ms median added latency per message.
Breaking the Protocol: Security Analysis of the Model Context Protocol
Abstract (as summarised from the arXiv abstract page, fetched 2026-09-11)
The paper presents the first formal security examination of the Model Context Protocol. It identifies three protocol-level vulnerabilities — absence of capability verification (attestation), bidirectional sampling without origin validation, and implicit trust propagation in multi-server setups — builds MCPBench to exercise 847 attack scenarios across five MCP implementations, and proposes MCPSec, a backward-compatible security extension.
Key Contributions
- The vulnerabilities are located in the specification, not in any one server. That is the load-bearing claim, and it is what makes this source durable while an individual CVE ages out.
- No capability attestation — a client has no protocol-level way to verify that a server's advertised tools are what it says they are. The tool description is accepted on trust.
- Bidirectional sampling without origin authentication — MCP lets a server request model completions back through the client; without origin authentication, the server can drive the model without the user's framing.
- Implicit trust propagation — connect several servers and each inherits the trust the client extends to the session; a compromised server reaches context contributed by the others.
- MCPBench, a harness of 847 attack scenarios across five MCP implementations.
- A measured amplification factor: MCP's architectural choices raise attack success rates by 23–41% relative to equivalent non-MCP tool integrations doing the same job. The protocol is not neutral — wiring tools through MCP is itself a risk delta.
- MCPSec, backward-compatible: attack success rate 52.8% → 12.4%, at 8.3ms median added latency per message.
Methodology
A specification-level analysis (reasoning over what MCP does and does not require), operationalised into an attack corpus and run against five real implementations rather than a mock. Effectiveness is measured as attack success rate (ASR), with the non-MCP integration serving as the control that isolates the protocol's contribution.
Results
| Measurement | Value |
|---|---|
| Attack scenarios | 847 |
| MCP implementations tested | 5 |
| Architectural defects named | 3 |
| ASR amplification, MCP vs non-MCP | +23% to +41% |
| ASR before MCPSec | 52.8% |
| ASR after MCPSec | 12.4% |
| Median added latency per message | 8.3 ms |
The residual 12.4% is the honest part: the fix is a large reduction, not a solution.
Limitations
- The figures above are read from the abstract page, not from the paper's tables. The per-implementation breakdown, the composition of the 847 scenarios, and which of the three defects drives the 23–41% band were not extracted in this pass. Anything compiled from this must cite the headline figures only, or go back to the full text.
- MCPSec is the authors' own proposal, benchmarked by the authors on their own harness — the standard attack-paper-proposes-the-defence conflict.
- Five implementations is a small denominator, and the paper is dated 2026-01-24: MCP has moved since, so the specification analysed may not be the specification shipping.
- ASR is scenario-weighted; a corpus built to demonstrate three defects will over-represent them relative to real traffic.
Why this is on the security rung, and the seat
The rung's scope names tool and supply-chain provenance and the exploitation surface. The 2026-09-06 candidate on this rung is a single incident (the Claude Code hook RCE); this is the protocol-level claim underneath it, and the paper's own conclusion — the vulnerabilities are design, not implementation — is why it was taken first.
Standing: I did this myself. MenFem ships an MCP server (/api/mcp/menfem, seven read tools plus four ops:write tools), so the three defects named here are assessable against a surface actually operated here, not merely read about. Specifically: implicit trust propagation is the reason INTERNAL_SCOPES refuses ops:* to every purchasable tier, and the absence of capability attestation is why the write surface holds its three invariants in code rather than in convention.
No live market call rests on this rung — brand and operating value only.
Source: Breaking the Protocol by Narek Maloyan and Dmitry Namiot — arXiv:2601.17549, submitted 2026-01-24.