独立安全研究员 Syed Anas Mohiuddin 近日针对 Google、Rapid7、摩根大通以及 Weaviate 等机构的多 Agent 系统完成了一组概念验证攻击。攻击者无需攻破前置大语言模型，仅凭一条精心构造的提示词，便能顺着内部任务分发链条穿透防御，直接撬开企业内网数据库与敏感接口。
这一系列漏洞将当下正被行业疯抢的连接标准推上了风口浪尖。由 Anthropic 主导推广的模型上下文协议（MCP）旨在规范 Agent 与底层工具、资源之间的通讯，而各机构正急于用它拼装复杂的多 Agent 网络。但这起横跨科技巨头与金融机构的安全事件给行业泼了一盆冷水：当企业默认内网各个专属 Agent 互相信任时，原本被大模型拦截的攻击指令，会在协议转换中被层层洗白，沦为肆虐内网的合法通行证。
案发内网：Google 数据库工具箱暴露 8.0 分漏洞
在这批受影响的机构中，Google 的风险等级最为刺眼。其官方数据库工具箱开源项目 googleapis/mcp-toolbox 在 0.3.0 至 1.4.0 版本期间，存在一个官方评分为 8.0 的高危漏洞，漏洞编号为 CVE-2026-14540（CWE-918 服务端请求伪造，即 SSRF）。与之相对，Mohiuddin 在安全厂商 Rapid7 网络中测出的漏洞 CVE-2026-97228，危险评级仅为 2.7。
问题出在底层网络实现的粗糙。Google 的 MCP 数据库工具箱在初始化 HTTP 客户端时，既没有启用 CheckRedirect 策略来限制恶意重定向，也没有对目标 IP 地址进行有效校验。攻击者只要向具备访问权限的上游 Agent 注入一段特定的路径参数，该工具箱就会顺从地跟随重定向，以内网高权身份向原本与外界物理隔离的端点发送请求，把数据库内的商业机密和个人隐私打包带走。
为了堵上这个窟窿，Google 团队于 2026 年 6 月 18 日合入 PR #3448，并在随后的 1.5.0 正式版中加入了名为 SSRFGuard 的防护机制，不仅加入了静态 IP 范围白名单与黑名单，还在初始化启动阶段便强行拦截不安全的基础 URL，并引入了 DNS 重绑定防御。
各协议都在看守自家前门，却没有任何人看管连接彼此的走廊。
Rapid7 漏洞情报总监 Douglas McKee 一针见血地指出，这套攻击链中的每一个节点都在忠实执行原本的设计逻辑。前置 Agent 接到翻译任务，自然地向下游委托；下游 Agent 收到来自同事的合法调用，理所当然地执行任务。正是这种假定信任，让古老的漏洞在新架构中死灰复燃。
走廊危机：当身份认证被误当成内容可信
安全界对此类攻击的定性产生了一场有价值的分歧。Mohiuddin 将这种手法称为协议横向移动（Protocol Pivoting）。在典型的企业拓扑中，Google 的 Agent-to-Agent（A2A）协议负责独立 Agent 之间基于 Agent Card 的协同委托，而 Agent 内部则挂载 MCP 去调取底层工具与数据库。攻击者从一个相对边缘的协议切入，利用协议间默认互信的断层逐级跳跃，最终拿到了核心协议下才有的执行权限。
但安全研究机构 X41 D-Sec 的 Markus Vervier 提出了另一种视角：这依然是典型的间接提示注入。跨协议并非利用成功的必要条件，核心根源在于多 Agent 系统的结构性盲区，即企业把通信身份认证错当成了内容本身可信。
早在 2024 年 10 月 9 日，学术界论文（arXiv:2410.07283）就曾系统性论证过多 Agent 网络中恶意指令的链式传播现象。安全专家 Simon Willison 随后提出了著名的致命三元组模型：只要一个系统同时具备访问私有数据、处理不可信内容、发起外部通信这三项能力，发生越权与数据渗漏几乎是数学上的必然。
翻开 MCP 官方截至 2026 年 7 月 28 日的规范文档，其架构安全策略有着极为严苛的免责条款：协议假定客户端完全信任所连接的服务器，通过 stdio 传输的本地 Server 默认等同于已安装的可执行软件，本身不具备沙箱能力；一旦模型出现意料之外的工具调用，官方并不将其视作协议漏洞，而是要求 Host 宿主系统自行承担隔离与拦截责任。
安全研究机构 Invariant Labs 曾总结过当前针对 MCP 的三类主流工具攻击：工具投毒、工具阴影与恶意篡改变更。在现实企业环境里，开发者为了快速串联业务流程，根本无力为数十个工具逐一定制宿主沙箱。官方把防护责任完全推给 Host，实际上是在把极度专业的零信任架构包袱，甩给对网络安全一无所知的业务层工程师。
- 风险.多 Agent 编排如果未设立单次任务的权限预算，越权调用就会顺着 A2A 协议基于 Agent Card 的协同机制不断扩散，最终导致整条链路被高权接管。
盲目互联退潮：确定性防御重新接管业务底座
Google 对 CVE-2026-14540 的修复过程给全行业上了一堂生动的工程课：在大模型落地多 Agent 的体系中，大模型自身的安全对齐和系统提示词（System Prompt）根本无法作为底层边界。真正的安全，依然得退回最传统的网络工程防线。
如果不从网络层锁死 HTTP 请求重定向、不采用严格的 IP 静态准入，任何试图靠自然语言提示词要求 Agent 保持警惕的做法，在真实的渗透测试面前都脆弱得像一层薄纸。
软件工程咨询机构 Thoughtworks 已经在 2026 年 4 月 15 日的技术雷达中敲响了警钟，将默认采用 MCP（MCP by default）直接打上警惕标签。报告指出，不加节制地推行 MCP 互联不仅带来显著的协议开销，还会造成 API 原生类型与校验规则的精度丢失。
企业架构师当下面临的不仅是修补几个 SSRF 漏洞，而是要对多 Agent 互联进行架构重估。在企业核心数据库和敏感执行节点上，无脑接入 MCP 并不是灵丹妙药。收拢权限、退回更具确定性的 OpenAPI 契约或严格受限的 CLI 调用，正在成为多数务实工程团队的避险选择。
- 建议.停止在关键服务节点盲目挂载全局 MCP 工具，对跨 Agent 的 A2A 任务链强制实施单次递减的权限预算，并确保所有工具执行宿主在网络层完成静态 IP 阻断与 DNS 重绑定防护。