10 月 5 日，Ars Technica 披露了一个 MCP（Model Context Protocol）协议层面的结构性安全缺陷：恶意提示词可以通过 MCP 连接在不同 agent 之间传播。这不是某个实现的 bug，而是协议设计本身的问题——Google、JPMorgan Chase、Rapid7 等多家机构已确认受影响。

漏洞机制：protocol pivoting

研究人员把这类攻击命名为 protocol pivoting（协议转向）。核心逻辑是：

• MCP 允许一个 agent 通过标准接口调用另一个 agent 或工具；
• 如果上游 agent 接收到的提示词里嵌入了恶意指令，它可能在不自知的情况下，把这些指令通过 MCP 连接传递给下游 agent；
• 下游 agent 收到的是「来自可信 MCP 通道」的请求，往往会直接执行。

换句话说，MCP 的「标准化连接」特性，恰好成了恶意提示词扩散的高速公路。攻击者不需要直接入侵目标系统，只需要污染链条中的任意一个节点。

为什么这是协议级问题

如果是某个具体实现的漏洞，修一个补丁就能解决。但 Ars Technica 的报道明确指出，这个问题出在 MCP 的协议设计 上——它假设连接双方都是可信的，没有内置对提示词内容的交叉验证机制。

这意味着： - 所有使用 MCP 的 agent 系统都可能受影响，不分厂商； - 防御方需要在应用层额外加一层「提示词清洗」或「来源校验」； - 短期内，MCP 的「即插即用」优势会被安全顾虑抵消一部分。

为什么值得关注

第一，MCP 正在快速成为 agent 互联的事实标准。 Adobe、Google、UiPath、Beeline 等厂商最近都在推 MCP 集成。协议级漏洞的曝光时机非常关键——如果安全机制跟不上 adoption 速度，第一批大规模部署 MCP 的企业可能成为试验品。

第二，「protocol pivoting」这个名字起得很准。 它揭示了一个更深层的问题：agent 之间的信任边界在哪里？当多个 agent 通过标准协议协作时，传统的「边界防火墙」思维不再适用。每个 agent 都需要对输入做零信任校验，无论它来自人类还是另一个 agent。

第三，对开发者的直接行动项。 如果你正在用 MCP 连接多个 agent 或工具，建议： - 在 MCP 消息入口加提示词注入检测； - 对敏感操作要求二次确认，不因为「来自 MCP」就自动放行； - 关注 MCP 规范后续是否会加入来源认证或内容签名机制。

参考：Ars Technica 2026-10-05、AI-Map AI Today、各厂商安全公告。