MCP 的信任模型让一个被投毒的智能体得以触及其他智能体
这个已成为连接 AI 智能体默认方式的协议存在信任问题，而在下一次事件发生之前，弄清它的具体形态很有必要。
Ars Technica 于 10 月 5 日报道，独立研究员 Syed Anas Mohiuddin 展示了一类他称之为“协议跳板”（protocol pivoting）的攻击。其思路很简单。在网络内部，智能体通过模型上下文协议（Model Context Protocol，MCP）相互通信。防护栏最薄弱的地方，正是一个智能体把任务交给另一个智能体的那一刻，因为后者默认信任前者。只要在一个缺乏严格输入校验的翻译或数据分析智能体中植入恶意指令，它就会把该指令继续向下传递。接收方会照做——毕竟，一个可信的同事为什么要撒谎呢。
Mohiuddin 的概念验证波及五个互不相关的组织：谷歌、摩根大通、Weviate、Rapid7、法国的部际数字事务局，以及一个美国联邦机构。这些组织几乎没有共同点，除了都大量使用智能体。这正是关键所在。弱点出在管道本身，而非任何单一产品。
两个 CVE 与一处评分落差
具体的漏洞本身很普通，而这恰恰是让这个故事令人不安的原因之一。Rapid7 的 MCP 服务器带有 CVE-2026-97228，尽管该缺陷评分仅为 10 分中的 2.7 分，公司仍在 2026 年 9 月完成了修复。谷歌的问题评分更高，为 8 分，涉及 googleapis/mcp-toolbox。其 HTTP 客户端缺少 CheckRedirect 策略和目标 IP 校验，因此精心构造的路径参数可以把请求重定向到内部端点。谷歌随后加入了 IP 允许列表和阻止列表，并让该工具箱在启动时拒绝不安全的基址 URL。
严重性评分的错位本身就是一堂课。两个组织在同一协议中发现了可比的弱点，却给出了截然不同的评级，这说明业界尚未就智能体间信任缺口该值多少分达成共识。
并非所有人都接受“协议跳板”是一个新类别。X41 D-Sec 的研究员 Markus Vervier 告诉 Ars Technica，他将其解读为间接提示注入，也就是安全团队已经追踪了两年的同一类技术。这种说法是公允的，同时它也让实际问题更加尖锐：针对提示注入的防御手册假定输入来自外部。而在这里，输入来自内部，还带着内部凭证。
这个缺口是架构性的，而非一个补丁能解决的
安全厂商 ClawSecure 的另一份报告把这层分析又推进了一步。其研究人员测试了 Linear、Notion 和 Dropbox Dash，并认为缺陷存在于 MCP 规范之中，而非任何厂商的实现里。在 Notion 和 Linear 中，他们发现 MCP 服务器会在内容创建的那一刻自动抓取由攻击者控制的链接，整个过程中完全没有模型参与。任何拥有工作区写入权限的人都能把它变成一条泄露通道，无需再费心构思措辞巧妙的提示词。
他们给出的数字很直白。在包括零宽 Unicode 字符和同形字在内的 20 种混淆技术中，有 17 种成功通过了整个往返流程。在来自五个实验室的 14 个模型中，没有一个能稳定拦截这些威胁；表现最好的 Claude Opus 4.7 仍有约 26.7% 的时候会遵循恶意指令。
ClawSecure 本身销售安全产品，且该报告尚未被独立复现，因此对其中关于平台层的论断应保持适当的审慎。不过，其背后的基本状况很容易核实。MCP 每月的 SDK 下载量超过 5 亿次，公开服务器接近 16,000 个，而按某一统计口径，其中只有 8.5% 的服务器使用 OAuth。采用速度跑在了加固前面。
AWS 在 10 月 2 日发布的一份公告中提供了自己的证据。其开源智能体编排平台 Loom 中的三个缺陷可能导致未经身份验证的管理权限被接管、OAuth2 凭证泄露，以及对内部服务的访问。其中最严重的是 CVE-2026-103956，它允许任何网络客户端在未配置身份提供商的部署中访问智能体控制平面。Loom 1.6.1 和 1.7.0 版本修补了这些缺口。
为什么默认信任假设才是真正的发现
把 CVE 放在一边，有一个设计选择格外突出。智能体天生是为了协作而构建的，因此它们相互认证，随后就表现得仿佛有效凭证也意味着有效请求。而经典零信任恰恰主张相反的做法：每一个请求都要凭其本身证明其正当性，即便来自内网也不例外。
Mohiuddin 的攻击正是利用了这一倒置。恶意指令之所以能越过系统之间的授权边界，恰恰是因为它在代码层面从未跨越任何边界。它在一个可信的架构内部从一个智能体流向另一个智能体，而没有任何一层会去追问这个请求是否合理。
团队本周可以做的事
当务之急的修复并不光鲜，而且现在就能做。把任何来自语言模型的指令都当作敌意输入处理，无论它由哪个智能体产生。强制执行严格的重定向处理并校验目标 IP。在一个智能体向另一个智能体委派任务之前，要求进行逐个智能体的身份验证，并记录该委派过程，以便事后重建整条交接链路。
从更长的时间维度看，可以预期标准组织会把协议跳板正式列为一种具名威胁类别，这将推动厂商把零信任检查内置到 MCP 之中，而非仅仅放在它旁边。审计人员会随之跟进，关于智能体间防护栏的问题将开始出现在合规审查中，就像一代人之前防火墙规则那样。
这个故事令人不适的地方在于：智能体彼此越信任，这种手法就越奏效。每一个急于通过 MCP 连接自身工具的组织，此刻都在搭建那张信任网络，而其中大部分都没有为“团队中某个成员其实在撒谎”这种情形准备任何预案。
为什么它现在才出现
这些底层技术没有一个是新的。服务端请求伪造和注入类漏洞多年来一直名列 OWASP 榜单。变化的是它们运行的位置。智能体为这些老漏洞提供了一条新的投递路径，因为智能体会毫不犹豫地对文档中的一句话、数据库某一行里的一个字段，或另一个智能体输出中的一行内容采取行动。指令不需要由攻击者亲手输入，它只需要出现在模型会读取到的某个地方。
这就是为什么这次披露会横跨一家银行、一个搜索引擎、一家安全厂商和一个政府局级机构。它们没有共享代码，也没有共用同一家供应商。它们共享的是一种架构，而这种架构暗含一个假设：每一个参与者都是可信的。MCP 在大约一年时间里从新奇构想变成关键基础设施，月下载量以亿计，而通常会伴随这种增长而来的安全审查，大多并没有发生。
这个故事也有一个结局不错的版本。漏洞正在被修复，协议的维护者们反应积极，而这些攻击需要写入权限或已在网络内部取得据点，这是一道不小的门槛。但真正重要的修复是文化层面的，而非技术层面的。采用智能体的团队需要停止把有效的内部凭证当作请求合法性的证明，转而把每一个请求都当作来自陌生人的请求来校验。这比发布任何补丁都更难推动，而下一轮事件考验的正是这一点。