MCP 曝出结构性缺陷：被攻破的不是模型，是智能体之间的「默认互信」
结论
独立研究员 Syed Anas Mohiuddin 披露了一个针对 MCP（模型上下文协议） 的概念验证攻击：它利用协议内的信任缺口，让被攻陷网络中的一个智能体，向其他内部智能体传播恶意指令。过去五个月里，Google、JP Morgan Chase、Weaviate、Rapid7、法国政府跨部委数字部门与美国政府等机构确认了相关漏洞。这条新闻的重点不是某个产品被攻破，而是"智能体之间默认互相信任"这件事本身站不住 —— 一旦其中任何一个被污染，污染就会沿着信任链自动扩散。
三个要点
- 它针对的是智能体，而不是大模型。 传统提示词注入的目标是"让模型输出坏东西"。这类攻击的目标是"让智能体去指挥别的智能体"，危害从一次错误输出升级为一次横向移动，性质完全不同。
- 传播性来自架构，而不是配置疏忽。 如果一个网络里的智能体共享会话、共享工具清单、彼此接受对方的消息，那么信任就是默认开启的。攻击者只要找到一个入口，剩下的扩散几乎是免费的 —— 这正是"结构性缺陷"的含义。
- 五个月的确认周期说明复现门槛不低但确认链很长。 多个机构先后确认，反过来说明这不是单点误报；同时也说明这类问题需要协议层而非单个厂商补齐。
对你意味着什么
把智能体之间的通信当作不可信边界。 任何智能体发出的指令，在另一个智能体执行前都应当经过校验：允许调用的工具有哪些、参数范围是什么、是否需要人工确认。不要因为"它来自内部"就跳过检查。
按最小权限切分工具。 把工具清单按任务切细，让每个智能体只拿到完成本职所需的子集。即使某个智能体被污染，它能造成的破坏也被限制在自己的权限边界内。
给高风险动作加一道"人在环上"。 删除数据、发送外部请求、修改权限、写生产库 —— 这几类动作应当强制人工确认或二次校验。协议层不会替你兜底。
在采用 MCP 类集成的项目里做一次清点。 列出你能触达的所有智能体、它们共享什么、谁能指挥谁。这份图往往比任何单点补丁都更有用。
一句话：多智能体的安全问题，本质不是"模型够不够聪明"，而是"信任有没有边界"。
参考来源
延伸阅读：韩国五大银行同时被袭：被攻破的不是网银，是「支持系统」 · 多个智能体同时改一个仓库：Git 要补的不是速度，是边界