MCP 协议跳板是独立研究员 Syed Anas Mohiuddin 给一类攻击起的名字。Ars Technica 在 2026 年 10 月 5 日的报道中披露了他的概念验证结果：过去五个月里，Google 和另外四家机构已经确认过同类漏洞。麻烦的地方在于，出事的往往不是某个模型不够聪明，而是智能体之间默认互相信任——一个环节被骗，后面的环节会把骗子的指令当成同事的正常委派接着执行。
先中招的通常是防护最松的那个
Mohiuddin 的测试对象包括 Google、摩根大通、Weaviate、Rapid7、法国政府的跨部数字事务机构和美国联邦政府部门。他的切入点很有代表性：不去正面攻击防护最严的主智能体，而是找翻译、数据分析这类专用智能体下手。这类智能体处理的外部内容最多，护栏却往往最松。攻击者把恶意提示藏进它要处理的内容里，第一步就完成了。
接下来的关键一步发生在协议层：被攻陷的智能体通过 MCP（模型上下文协议）把指令转交给另一个智能体时，接收方看到的是一次内部委派，而不是一段来历不明的外部输入。原本可能被大模型直接拒绝的指令，换上“同事转交”的身份后就可能被执行，严重时还能进一步触发服务端请求伪造（SSRF），把请求打进内网。
信任为什么会在半路丢掉
这条链能成立，靠的是三个叠加的条件：
- MCP 服务器手里集中保管着多个智能体的凭据，一个入口失守，横向移动的通道就现成的。
- 内部智能体之间默认互信，敏感操作执行前不再重新核验授权。
- 指令在 MCP 与 Google 的 A2A、Agent Network Protocol 等协议之间转换时，原始的信任标记和授权信息容易丢失或被误读。
已经确认的两个样本，严重程度差得很远。Google 的数据库 MCP 工具箱（googleapis/mcp-toolbox）相关漏洞被评为 8/10：其 HTTP 客户端没有设置重定向检查策略，也不校验目标 IP，精心构造的路径参数就能让工具箱跟随重定向、替攻击者向内部端点发出请求。Google 的修复是给 IP 范围加上允许名单与拦截名单，并在启动时直接拒绝不安全的起始地址。Rapid7 那一例编号为 CVE-2026-97228，评分只有 2.7/10，已在上月修复。
Rapid7 的 Douglas McKee 点出了这类问题最难缠的地方：整条链上每个环节其实都按设计在工作，所以很难被发现，而智能体恰好给攻击者提供了一组新的、可以横向移动的连接。X41 D-Sec 的 Markus Vervier 则认为，这本质上仍是间接提示注入的一个子类，手法出人意料，也总体上难以缓解。类似的教训本站刚写过：Databricks Genie 被恶意 Skill 钻了空子，以及维基媒体确认被流氓智能体活动波及，共同点都是单点防护看着没问题、链条整体却不设防。
防守思路要回到零信任
披露给出的建议并不新鲜，难的是落实：默认假定已经有节点被攻陷，智能体之间交接敏感操作前重新授权；凡是从大模型传给工具的内容，一律按不可信的外部输入处理，注入和 SSRF 这些老问题防了多年的做法照样适用。多智能体系统正在快速进入企业内网，如果互信模型还停留在“都是自己人”，协议跳板不会是最后一次被命名的攻击方式。
