MCP 安全：别再问存在哪些攻击，而要问防御应当部署在哪一层
2026 年 4 月的一篇 arXiv 论文将 MCP 攻击映射到六个架构层，发现防御分布不均且过度集中于工具层，使宿主编排、传输与供应链在结构上长期处于防御不足的状态。
这是什么？
MCP-DPT 是一套面向 Model Context Protocol 的防御部署分类法，于 2026 年 4 月 8 日发表在 arXiv（2604.07551）。迄今为止，MCP 安全研究大多以攻击为中心：描述工具投毒（tool poisoning）、撤梯（rug pull）或工具影射（tool shadowing）如何运作、成功率多高。MCP-DPT 提出的是一个更具可操作性的不同问题——鉴于 MCP 多方参与、信任分散的设计，每一项防御应当部署在哪里，又由哪个参与方负责？
论文在映射现有学术界与产业界防御方案后给出的核心结论很直白：防护「分布不均，且以工具层为主，宿主编排、传输与供应链层存在持续性缺口」。换言之，业界把缓解措施堆叠在最容易推理的一层——工具层——而结构上关键的层次反而防御薄弱。作者主张这些缺口是结构性的，源于架构错配，而非孤立的实现缺陷。这延续了一系列 MCP 威胁研究，包括 Unit 42 的 MCP sampling 攻击向量（2025 年 12 月）、NSA 的 MCP 安全设计考量，以及更广义的 MCP-38 威胁分类法。
工作原理
MCP 是一个宿主—客户端—服务器协议：宿主应用编排 LLM，MCP 客户端负责协议通信，独立运营的 MCP 服务器对外暴露工具。MCP-DPT 将其拆解为六个层次，每一层都是由不同参与方拥有的信任边界：
- 模型提供方 / LLM 对齐——模型自身的拒答与推理行为。
- MCP 宿主 / 应用——编排、审批提示、上下文组装。
- MCP 客户端 / SDK——协议解析、参数处理、会话状态。
- MCP 服务器 / 工具执行——工具代码实际运行之处。
- 传输 / 网络——通信信道：认证、会话绑定、抗重放与抗篡改。
- 注册表 / 市场与供应链——发现、发布、更新、命名。
对每一种攻击，论文都指出一个主防御层——「能够以足够权限与可见性实施有意义防护的最早架构边界」——以及一个次防御层作为兜底。单一控制点之所以永远不够，根源在于协议本身的形态：攻击可能从某一层进入，却只能在另一层才变得可见或可拦截。注册表只能在提交时检查静态元数据，而恶意工具的行为可能只在运行时、在宿主内部才显现。因此，只防御工具层，就会在其他每一道边界上都留下窗口。
随后，作者将真实防御方案归类（静态/执行前、运行时/行为、隔离/架构以及决策层），并梳理已部署的工具链，得到的覆盖图明显失衡：措施集中于工具与提示的检查，而传输、宿主编排以及注册表/供应链治理都很单薄。不需要任何漏洞利用或载荷就能看清后果——这是一个覆盖缺口，而非一种新攻击。
为何重要
如果你在 MCP 上运行智能体，实际教训是：购买一款工具扫描器并不等于 MCP 安全策略。一款在安装时检查工具描述的扫描器，对缺乏会话绑定的传输、对自动批准工具调用的宿主、或对放任攻击者抢注服务器名称随后推送恶意更新（即「撤梯」）的注册表，都无能为力。它们属于不同的参与方与不同的层次。
「结构性，而非偶发」这一框定也校准了预期。由于没有任何单一参与方掌控整个 MCP 栈，安全必然是责任共担问题——更接近云端 IAM，而非给某个库打补丁。那些假定协议或某个单一供应商「会负责安全」的团队，正是覆盖分析所预测的、会在宿主、传输与供应链层暴露的团队。
防御
把这套分层模型当作清单使用，将每一项控制放在其主执行点，而不是指望工具层把一切兜住。
- 宿主编排（最被忽视的一层）。 对高影响的工具调用要求明确的人工审批，按工具实施最小权限，并在上下文中将不可信的工具输出与可信指令隔离。不要自动批准。
- 传输 / 网络。 使用经过认证且完整性受保护的信道，具备会话绑定与抗重放能力。把「MCP 假定信道可信」当作一个漏洞，而不是一个假设。
- 注册表 / 供应链。 固定服务器身份与版本，验证来源，并在每次更新时——而不仅是首次安装时——重新评估工具，以发现撤梯与名称抢注。提交时的静态元数据审查必要但不充分。
- 服务器 / 工具执行。 将工具执行沙箱化，限制文件系统访问与网络外联，并在执行前对照模式校验参数。
- 以设计实现纵深防御。 对你关心的每一种攻击，问：能以足够权限将其拦下的最早一层是哪一层，兜底层又是哪一层？为每一层指派负责人。一个只在损害已流向下游后才触发的控制，是次防御，而非主防御。
状态
| 层次 | 典型负责人 | 按 MCP-DPT 的覆盖情况 |
|---|---|---|
| 模型提供方 / 对齐 | 模型厂商 | 部分（仅拒答） |
| MCP 宿主 / 应用 | 集成方 | 防御不足 |
| MCP 客户端 / SDK | SDK 维护者 | 分布不均 |
| MCP 服务器 / 工具执行 | 工具作者 | 过度集中（以工具为中心） |
| 传输 / 网络 | 集成方 / 基础设施 | 防御不足 |
| 注册表 / 供应链 | 生态 / 注册表 | 防御不足 |
这篇论文是一套分类法与覆盖分析，而非漏洞披露——没有可打的补丁，也没有需要隐去的载荷。其价值在于重新框定：MCP 反复出现的弱点，更应被理解为防御被放错了位置，而修复之道是把每项控制施加在真正拥有它的那一层。发表于 2026 年 4 月 8 日；它所组织的攻击类别（工具投毒、影射、撤梯、传输篡改、注册表抢注）均已见于公开的 MCP 安全文献。