[论文学习]Breaking the Protocol:MCP协议安全性分析——工具集成LLM智能体中的提示注入漏洞

HK2KING

172人浏览 · 2026-08-20 00:15:00

HK2KING · 2026-08-20 00:15:00 发布

Breaking the Protocol: Security Analysis of the MCP Specification and Prompt Injection Vulnerabilities in Tool-Integrated LLM Agents (2026)

论文重點

本文是首篇对Model Context Protocol（MCP）协议规范进行系统化安全分析的学术论文。研究发现MCP的三大协议级架构漏洞——能力自声明无验证、双向采样无来源认证、多服务器隐式信任传播——使其攻击成功率比非MCP集成高出23–41%。作者提出了ATTESTMCP这一向后兼容的协议扩展，通过能力认证和消息认证将攻击成功率从52.8%降至12.4%，且每条消息仅增加8.3ms延迟开销。

核心研究内容

问题定义

Anthropic于2024年11月推出的MCP协议，在短短数月内已被Claude Desktop、Cursor等主流平台采用，社区开发者服务器超过5,000个。然而，协议规范本身从未经过正式的安全分析。现有工作（如MCPSecBench、MCP-Bench）主要聚焦于攻击类型目录和能力评估，并未将MCP集成系统与非MCP基线进行对比，因此无法隔离出协议本身对攻击成功率的影响。论文要回答的核心问题是：MCP的架构设计选择究竟在多大程度上放大了安全风险？

创新方法

1. 协议规范的系统化安全分析

作者对MCP v1.0规范进行了逐条审查，从JSON-RPC消息格式、能力协商机制到信任边界，识别出三类无法通过实现层面修补解决的协议级漏洞：

能力自声明无验证（Least Privilege Violation） ：服务器在初始化时自行声明能力（tools/resources/sampling），客户端没有任何机制验证这些声明是否属实。恶意服务器可以先声明仅“resources”能力，随后却调用“sampling/createMessage”注入提示。
双向采样无来源认证（Sampling Without Origin Authentication） ：服务器可通过“sampling/createMessage”请求LLM补全，但客户端在处理时无法区分服务器发起的提示与用户发起的提示。作者检查了Claude Desktop、Cursor、Continue三个主流MCP宿主实现，没有任何一个提供视觉上的区分标识。
隐式信任传播（Implicit Trust Propagation） ：多服务器部署中，协议未定义服务器之间的隔离边界。控制服务器A的攻击者可以在工具响应中嵌入指令，诱导对服务器B的调用，或通过服务器A的通道窃取服务器B的数据。

2. PROTOAMP框架

作者开发了PROTOAMP（Protocol Amplification Benchmark）框架，将现有的智能体安全基准（InjecAgent、AgentDojo）适配到MCP兼容的基础设施上。该框架在三个协议层（资源内容、工具响应载荷、采样请求提示）注入攻击，并记录所有JSON-RPC消息以追踪攻击传播。

3. ATTESTMCP协议扩展

提出了向后兼容的协议扩展，包含五大设计原则：能力认证（加密签名证书）、消息认证（HMAC-SHA256）、来源标记（采样请求标记服务器来源）、隔离执行（跨服务器信息流需用户授权）、重放保护（时间戳+nonce）。支持三种迁移模式（Permissive/Prompt/Strict）以逐步推进生态采用。

研究成果

核心量化发现：

攻击类型	非MCP基线	MCP集成	增幅
间接注入（资源）	31.2%	47.8%	+16.6%
工具响应操纵	28.4%	52.1%	+23.7%
跨服务器传播	19.7%	61.3%	+41.6%
采样注入	N/A	67.2%	—
总体	26.4%	52.8%	+26.4%

MCP架构使总体攻击成功率从26.4%升至52.8%。跨服务器传播的增幅最大（+41.6%），因为MCP缺乏隔离边界使得单服务器部署中不可能的攻击在MCP中成为现实。

采样注入的严重性： Claude-3.5-Sonnet为58.3%、GPT-4o为71.4%、Llama-3.1-70B为72.1%，且42–61%成功窃取敏感上下文。

多服务器扩展效应： 当并发服务器从1个增至5个（其中1个被控制），攻击成功率从47.8%升至78.3%，级联率（成功危害其他服务器操作）达72.4%。

ATTESTMCP防护效果： 总体攻击成功率从52.8%降至12.4%（降低76.5%），其中跨服务器传播降低85.8%、采样注入降低83.2%。每条消息延迟开销中位数8.3ms（冷启动）或2.4ms（缓存），相比LLM推理的500–2000ms可忽略不计。

实际落地应用的可能性

高可行性：ATTESTMCP被设计为向后兼容的协议扩展，不破坏现有MCP生态。三种迁移模式（Permissive/Prompt/Strict）允许渐进式部署。延迟开销（2.4–8.3ms）对于实际应用完全可接受。

生态挑战：论文坦承，如果大多数服务器保持未签名状态，用户将默认使用Permissive模式，安全收益将归零。联邦CA模型需要Anthropic、Cursor、JetBrains等平台厂商的协调与跨签名协议。此外，论文未涉及形式化验证，计划未来通过符号模型检查进行验证。

技术細節

漏洞1：能力自声明（JSON-RPC示例）

MCP初始化过程中，服务器通过以下方式自行声明能力：

{
  "capabilities": {
    "tools": { "listChanged": true },
    "resources": { "subscribe": true },
    "sampling": {}
  }
}

问题：客户端完全信任该声明，无任何验证机制。恶意服务器可声明仅“resources”，后续却调用“sampling/createMessage”。

漏洞2：采样注入攻击流程

服务器通过以下方式发起采样请求：

{
  "method": "sampling/createMessage",
  "params": {
    "messages": [{"role": "user", "content": "..."}],
    "maxTokens": 1000
  }
}

攻击流程：用户→Host→Server 1→（tools/call返回）→Host→（sampling/createMessage注入）→LLM。服务器使用“user”角色注入内容，Host将其与合法用户输入等同处理，无任何视觉或语义区分。

漏洞3：跨服务器信任传播

多服务器部署中，所有工具响应汇聚于同一LLM上下文窗口，无来源追踪。控制服务器A的攻击者可：

在工具响应中嵌入指令，诱导对服务器B的调用
通过服务器A的通道窃取服务器B的数据
通过污染共享上下文建立持久性

ATTESTMCP协议扩展

能力证书格式：

{
  "capability_cert": {
    "server_id": "filesystem-server",
    "capabilities": ["resources", "tools"],
    "issued_by": "anthropic-ca",
    "issued_at": 1706140800,
    "expires_at": 1737676800,
    "signature": "base64..."
  }
}

认证消息格式：

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {...},
  "mcpsec": {
    "server_id": "filesystem-server",
    "timestamp": 1706140800,
    "nonce": "random-32-bytes",
    "hmac": "base64..."
  }
}

隔离-效用的量化权衡

隔离级别	攻击成功率	任务完成率
无隔离（MCP默认）	61.3%	94.2%
用户提示的跨流（ATTESTMCP默认）	31.7%	87.4%
严格隔离（无跨流）	8.7%	61.8%

ATTESTMCP默认采用“用户提示的跨流”隔离——在攻击成功率降低48%的同时保持87.4%的任务完成率。

研究設定

实验设计

MCP服务器（5个）：

mcp-server-filesystem：文件操作
mcp-server-git：仓库管理
mcp-server-sqlite：数据库查询
mcp-server-slack：消息集成
adversarial-mcp：协议边界情况测试

LLM后端：

Claude-3.5-Sonnet
GPT-4o
Llama-3.1-70B

攻击场景（847个测试用例）：

InjecAgent改编：312个（间接注入、工具滥用）
AgentDojo改编：398个（多步骤攻击）
新型协议特定攻击：137个（采样、跨服务器）

基线对照：使用直接函数调用的等价工具集成（非MCP），以隔离协议特定效应。

控制变量：

工具语义在MCP与基线条件间完全一致
相同注入载荷
LLM提示策略恒定
网络延迟匹配（基线模拟MCP延迟）
MCP延迟实测：stdio传输中位数12.4ms，HTTP/SSE为23.7ms

硬件/软件配置

论文未详细列出具体硬件规格，但根据实验描述可推断：

需要运行MCP客户端（如Claude Desktop或自定义客户端）及5个MCP服务器进程的环境
支持stdio或HTTP/SSE传输
PROTOAMP框架需适配现有基准（InjecAgent、AgentDojo）到MCP基础设施
实验环境需记录所有JSON-RPC消息用于攻击传播分析

綜合分析

核心洞见：架构漏洞 vs. 实现漏洞

论文最有价值的贡献在于明确区分了协议级漏洞与实现级漏洞。已披露的CVE（如CVE-2025-49596、CVE-2025-68143）都指向具体实现的bug，修补这些漏洞并不能解决能力认证缺失、采样注入和跨服务器隔离等根本性问题。换言之，即使用最安全的实现替代每个MCP服务器，上述三类攻击仍然存在——因为它们写在协议规范里，而非代码的bug里。

MCP的设计权衡：组合性 vs. 隔离性

MCP的设计者明确优先考虑了组合性（composability） ——让不同服务器的工具能够无缝协同工作。这本身不是错误，论文也承认“完全隔离会破坏合法工作流：用filesystem-server读取config.json，然后用sqlite-server查询数据库”。问题在于协议没有给用户选择权——没有机制让用户在需要时配置隔离策略。ATTESTMCP的“用户提示的跨流”模式正是在这个张力中找到了平衡点：攻击成功率从61.3%降至31.7%，任务完成率仅从94.2%降至87.4%。

采样机制：披着合法外衣的攻击通道

采样（sampling）是MCP中最具争议的设计——它允许服务器主动请求LLM生成内容。这在功能上是强大的（服务器可根据上下文动态调用LLM），但在安全上几乎是“特洛伊木马”。更关键的是，所有主流宿主实现（Claude Desktop、Cursor、Continue）都不对采样来源做任何视觉区分。用户完全无法知道自己是在与LLM对话，还是在执行服务器注入的指令。这已经超越了“技术漏洞”的范畴，进入了用户认知安全的领域。

攻击面的量化：从847个场景到普适结论

论文的实验设计严谨之处在于控制了所有变量：相同的工具语义、相同的注入载荷、相同的提示策略、匹配的网络延迟。唯一的变量是“是否通过MCP协议通信”。因此，23–41%的攻击成功率增幅可以确凿地归因于MCP架构本身。

847个测试用例覆盖了间接注入、工具滥用、多步骤攻击和协议特定攻击。多服务器配置测试了2–5个并发服务器。这种广度使得结论具有较高的外部效度。

局限性与未解决的问题

论文的诚实值得注意。它明确列出了ATTESTMCP无法解决的问题：

合法授权服务器内的恶意行为（服务器有有效证书但提供恶意内容）
用户被社会工程诱导授权恶意能力
CA被攻破（联邦化可缓解但无法消除）
首次接触攻击（TOFU——用户首次安装恶意服务器时无保护）
生态采用率问题

特别是最后一点——如果生态中大多数服务器保持未签名状态，安全收益将归零。这实际上把责任推给了整个MCP生态，而不仅仅是一个技术补丁能解决的。

實踐應用

对MCP应用开发者的建议

1. 立即采取的措施（无需等待协议更新）

在宿主应用中实现采样来源的视觉区分：即使协议规范未强制要求，宿主实现（如Claude Desktop、Cursor）应主动为采样产生的消息添加“来自服务器”的视觉标识。
在系统提示中添加隔离指令：论文测试表明，在系统提示中添加“未经用户明确确认，不得在不同工具服务器间传递数据”可将跨服务器攻击成功率从61.3%降至47.2%。虽不完美，但可立即降低风险。
限制多服务器并发数：论文显示服务器数量与攻击成功率正相关（1台47.8%→5台78.3%）。生产环境中应审慎评估多服务器并发的必要性。

2. 中期措施（推动生态改进）

推动MCP v2.0采纳ATTESTMCP概念：论文明确建议Anthropic将ATTESTMCP概念纳入MCP v2.0。开发者社区应积极向Anthropic反馈此需求。
参与联邦CA建设：论文提出的联邦CA模型需要平台厂商（Anthropic、Cursor、JetBrains等）运营CA并建立跨签名协议。生态参与者应推动此事。
包 registry 的命名空间保护：论文调查发现34%的攻击向量来自typosquatting（如mcp-server-filesytem）。npm、pip等包管理器应引入MCP服务器的命名空间保护机制。

3. 对LLM智能体平台运营者的建议

部署ATTESTMCP的“Prompt”模式：要求用户对未签名服务器明确确认。虽然可能影响用户体验，但在安全敏感场景中值得。
监控异常采样请求模式：如果服务器频繁发起采样请求，应触发告警。
考虑默认隔离策略：虽然完全隔离会降低任务完成率（61.8%），但对于高安全需求场景，这是可接受的权衡。

4. 对研究人员的方向建议

ATTESTMCP的形式化验证：论文承认尚未进行形式化验证，计划使用符号模型检查。
用户行为研究：论文指出“告警疲劳”可能使用户习惯性点击“允许”，降低实际防护效果。
首次接触攻击的防护机制：TOFU（Trust On First Use）在用户首次安装恶意服务器时无法提供保护。

參考資料來源

原始论文：Maloyan, N., & Namiot, D. (2026). Breaking the Protocol: Security Analysis of the Model Context Protocol Specification and Prompt Injection Vulnerabilities in Tool-Integrated LLM Agents. arXiv:2601.17549. https://arxiv.org/abs/2601.17549