Breaking the Protocol: Security Analysis of the MCP Specification and Prompt Injection Vulnerabilities in Tool-Integrated LLM Agents (2026)论文重點本文是首篇对Model Context ProtocolMCP协议规范进行系统化安全分析的学术论文。研究发现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框架作者开发了PROTOAMPProtocol 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/A67.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-SonnetGPT-4oLlama-3.1-70B攻击场景847个测试用例InjecAgent改编312个间接注入、工具滥用AgentDojo改编398个多步骤攻击新型协议特定攻击137个采样、跨服务器基线对照使用直接函数调用的等价工具集成非MCP以隔离协议特定效应。控制变量工具语义在MCP与基线条件间完全一致相同注入载荷LLM提示策略恒定网络延迟匹配基线模拟MCP延迟MCP延迟实测stdio传输中位数12.4msHTTP/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的形式化验证论文承认尚未进行形式化验证计划使用符号模型检查。用户行为研究论文指出“告警疲劳”可能使用户习惯性点击“允许”降低实际防护效果。首次接触攻击的防护机制TOFUTrust 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