MCP security: stop asking which attacks exist, ask where defenses must live

What is this?

MCP-DPT is a defense-placement taxonomy for the Model Context Protocol, published on arXiv (2604.07551) on 8 April 2026. Most MCP security work to date has been attack-centric: it catalogues how attacks like tool poisoning, rug pulls and tool shadowing work and how often they succeed. MCP-DPT asks a different, more operational question — given MCP’s multi-party, distributed-trust design, where should each defense be enforced, and which stakeholder owns it?

The paper’s central finding, after mapping existing academic and industry defenses onto its framework, is blunt: protection is “uneven and predominantly tool-centric, with persistent gaps at the host orchestration, transport, and supply-chain layers.” In other words, the field has piled mitigations onto the one layer that is easiest to reason about — the tool — while the structurally critical layers remain comparatively undefended. The authors argue these gaps are structural — a product of architectural misalignment — rather than isolated implementation bugs. This continues a line of MCP threat work that includes Unit 42’s MCP sampling attack vectors (December 2025), the NSA’s MCP security design considerations, and the broader MCP-38 threat taxonomy.

How it works

MCP is a host–client–server protocol: a host application orchestrates an LLM, an MCP client speaks the protocol, and independently operated MCP servers expose tools. MCP-DPT decomposes this into six layers, each a trust boundary owned by a different party:

1. Model Provider / LLM Alignment — the model’s own refusal and reasoning behaviour.
2. MCP Host / Application — orchestration, approval prompts, context assembly.
3. MCP Client / SDK — protocol parsing, parameter handling, session state.
4. MCP Server / Tool Execution — where tool code actually runs.
5. Transport / Network — the channel: authentication, session binding, replay and tampering protection.
6. Registry / Marketplace & Supply-chain — discovery, publication, updates, naming.

For each attack the paper identifies a primary defense layer — “the earliest architectural boundary where meaningful prevention can be enforced with sufficient authority and visibility” — and a secondary fallback layer. The reason a single control is never enough is the protocol’s own shape: an attack can enter at one layer but only become observable or stoppable at another. A registry can only inspect static metadata at submission time, but a malicious tool’s behaviour may only manifest at runtime inside the host. Defending only the tool therefore leaves a window open at every other boundary.

When the authors then categorise real defenses (static/pre-execution, runtime/behavioural, isolation/architecture, and decision-level) and survey deployed tooling, the coverage map comes out lopsided: mitigations cluster on tool and prompt inspection, while transport, host orchestration, and registry/supply-chain governance are thin. No exploit or payload is needed to see the consequence — it is a coverage gap, not a new attack.

Why it matters

If you run agents over MCP, the practical lesson is that buying a tool-scanner is not an MCP security strategy. A scanner that inspects tool descriptions at install time does nothing for a transport that lacks session binding, a host that auto-approves tool calls, or a registry that lets an attacker squat a server name and push a malicious update later (a “rug pull”). Those are different owners and different layers.

The “structural, not incidental” framing also sets expectations. Because no single party controls the whole MCP stack, security is necessarily a shared-responsibility problem — closer to cloud IAM than to patching one library. Teams that assume the protocol or a single vendor “handles security” are exactly the teams the coverage analysis predicts will be exposed at the host, transport and supply-chain layers.

Defenses

Use the layer model as a checklist, and place each control at its primary enforcement point rather than hoping the tool layer catches everything.

• Host orchestration (the most-neglected layer). Require explicit human approval for high-impact tool calls, enforce least privilege per tool, and isolate untrusted tool output from trusted instructions in context. Do not auto-approve.
• Transport / network. Use authenticated, integrity-protected channels with proper session binding and replay protection. Treat “MCP assumes a trustworthy channel” as a vulnerability, not an assumption.
• Registry / supply-chain. Pin server identities and versions, verify provenance, and re-evaluate tools on update — not just at first install — to catch rug pulls and name-squatting. Static metadata review at submission time is necessary but not sufficient.
• Server / tool execution. Sandbox tool execution, constrain filesystem and network egress, and validate parameters against schema before execution.
• Defense-in-depth, by design. For each attack you care about, ask: what is the earliest layer that can stop it with enough authority, and what is the fallback? Assign an owner to each. A control that only fires after the damage is downstream is a secondary defense, not a primary one.

Status

Layer	Typical owner	Coverage per MCP-DPT
Model provider / alignment	Model vendor	Partial (refusals only)
MCP host / application	Integrator	Under-defended
MCP client / SDK	SDK maintainer	Uneven
MCP server / tool execution	Tool author	Over-represented (tool-centric)
Transport / network	Integrator / infra	Under-defended
Registry / supply-chain	Ecosystem / registry	Under-defended

The paper is a taxonomy and coverage analysis, not a vulnerability disclosure — there is nothing to patch and no payload to withhold. Its value is the reframing: MCP’s recurring weaknesses are best read as misplaced defenses, and the fix is to enforce each control at the layer that actually owns it. Published 8 April 2026; the attack classes it organises (tool poisoning, shadowing, rug pulls, transport tampering, registry squatting) are all previously documented in the public MCP-security literature.