引言多智能体系统正在成为 AI 应用的主流架构。一个编排器调用文档处理智能体文档处理智能体查询数据库智能体数据库智能体又把结果交给风控智能体——消息在内部总线、API 和注册中心之间不停流动。问题恰恰出在这里流量一旦被打上“内部”的标签就很容易被当作可信的。OWASP Agentic Top 10 将ASI07: Insecure Inter-Agent Communication列为第 7 名指向的正是这个盲区智能体之间缺乏身份验证、完整性校验和语义验证导致攻击者可以拦截、篡改、重放或伪造智能体消息。与 ASI03身份与权限滥用关注凭据盗用不同ASI07 聚焦于传输中的消息本身与 ASI06记忆与上下文投毒关注存储知识污染不同ASI07 的危害发生在实时通信链路上。对于开发者和安全工作者来说理解 ASI07 的关键不在于记住定义而在于认清一个事实内部来源不等于完整性证明。一个 JSON 结构完美、签名有效的消息完全可能是有害的。一、ASI07 与传统未加密协议、中间人攻击的本质区别很多开发者会问这不就是没加密、不就是 MITM 吗加上 TLS 不就行了答案是否定的。ASI07 与传统安全问题的核心区别在于传统安全关注的是“数据有没有被偷看或改动”而 ASI07 关注的是“智能体的行为有没有被改写”。一条经过加密、签名验证的消息在传统安全视角下可能是完全安全的但在多智能体系统中如果接收方没有验证消息的语义意图和新鲜度这条“安全”的消息仍然可能让智能体执行完全错误甚至有害的动作。下表从多个维度对比两者的差异维度传统未加密协议 / 中间人攻击MITMASI07 不安全的智能体间通信攻击目标数据本身——窃取密码、篡改金额、注入恶意代码智能体的决策逻辑不只改数据更要改“智能体接下来会做什么”信任假设假设“内部网络/已认证通道相对可信”安全边界在系统外围进入内网即放行攻击的恰恰是智能体之间默认的信任利用的是去中心化架构中“来自内部对等方即可信”的架构性假设“安全”的定义加密 签名 安全消息完整、来源可验证即过关加密 签名≠ 安全消息可以加密、签名有效、schema 通过但语义已被改变或是一条已被消费过的旧消息重放的杀伤力重放通常用于绕过认证如重放登录令牌获取会话重放一条合法的业务指令即可造成实际损害签名有效但“新鲜度”缺失系统毫无告警攻击面范围主要发生在网络传输层横跨传输、路由、发现、语义四个层面还包括服务发现欺骗、协议降级、语义分叉、流量模式推断可见性南北向流量进出系统是监控重点WAF/API 网关部署在边缘攻击几乎全部发生在东西向流量智能体之间的内部流量往往不走边缘网关传统安全工具看不到防护充分性部署 TLS/mTLS 即可大幅缓解mTLS 只保护“谁在和谁说话”不保护“说的话里具体是什么内容”也不保护“这条消息是否已经过时”一个例子说清区别假设一个医疗智能体系统中编排器向文档智能体发送处方消息。消息走的是内部 mTLS 加密通道双方证书都有效。传统安全视角通道加密了身份验证了数据在传输中没有被第三方截获。安全。ASI07 视角一个拥有东西向流量访问权的攻击者比如一个被攻陷的内部服务在消息进入文档智能体之前修改了载荷——二甲双胍变成胰岛素。mTLS 保护的是“谁在和谁说话”但不保护“说的话里具体是什么内容”。如果文档智能体只依赖通道安全而不验证载荷签名和语义意图它就会把篡改后的处方当作合法指令执行。更关键的是即使攻击者什么都不改只是重放一条昨天的合法处方消息传统安全工具也完全无法拦截——因为一切看起来都是“正常的、加密的、经过认证的”内部通信。ASI07 揭示的正是这种“看起来完全安全、实则已经失控”的信任失效模式。二、攻击是怎么发生的三个真实场景场景一篡改处方——当“结构正确”掩盖了“语义致命”一家医疗系统的智能体工作流中医生开具了二甲双胍 500mg 每日两次的处方。编排智能体生成药物订单事件通过内部智能体总线发送给文档智能体。系统假设内部对等流量是可信的没有 mTLS没有载荷签名没有独立的发送者身份证明。一个拥有东西向流量访问权的网络攻击者拦截了消息只改了一个字段二甲双胍 500mg → 胰岛素 40 单位。案件 ID 仍然有效JSON schema 仍然通过消息结构完美无缺。唯一改变的是临床含义。文档智能体收到消息相信它来自可信对等方将药物写入患者病历。工作流“成功”完成。直到护理团队按照病历执行给药患者被注射了本不该使用的胰岛素ICU 升级可报告的患者安全事件发生。这个场景的残酷之处在于每一个智能体都在正确地做自己该做的事。编排器生成了正确的订单文档智能体正确处理了它收到的消息schema 验证从未失败。失败发生在智能体之间——一个可信通信通道接受了被篡改的对等消息而这个单一的信任决策一路传播到了患者护理环节。场景二重放审批——签名有效但“新鲜度”已死财务经理批准了一笔 25,000元 的供应商付款。审批智能体创建一次性令牌发布了一条签名审批消息到内部智能体总线。签名合法金额合法付款合法。数小时后一个能访问审批传输日志的内部人员取出了这条先前已签名的审批消息。没有修改任何内容没有伪造任何东西只是重新发布了原始审批包。签名仍然有效内容仍然有效金额仍然匹配。唯一缺失的属性是新鲜度。付款执行智能体收到重放审批验证签名通过却从不检查这条审批是否已经被消费过。它把昨天的有效审批当成了今天的新授权。第二笔 25,000元 汇出。从智能体视角看一切正常签名验证成功付款指令与原始批准完全一致没有触发任何异常告警。金融平台是健康的信任生命周期不是。每条经过认证的消息必须同时证明两件事它是真实的以及它是新鲜的。只验证前者而忽略后者就是在为重放攻击敞开大门。场景三发现欺骗——当“找到的”被等同于“可信的”零售客户报告账单错误分诊智能体识别为账单争议准备路由给账单专家。它的职责很简单找到正确的对等智能体并转发案件。与此同时一个恶意运营者在服务发现中注册了虚假的账单端点。该端点遵循预期的命名惯例宣称自己是账单专家成功出现在服务发现结果中。分诊智能体执行正常的服务发现查询注册中心返回“账单专家 v2”。一切看起来都有效。但注意缺失的控制没有签名注册没有对等允许列表没有经过认证的智能体注册中心。即使每个连接都使用了 mTLS结果也完全相同——mTLS 保护的是通信通道而经过认证的智能体注册中心保护的是被发现的那个身份。两者是不同的控制都需要。虚假端点收到了客户的完整账单上下文。它复制了客户画像然后立即将案件转发给真正的账单专家。合法团队解决了问题客户得到了正确答案支持工单成功关闭。没有任何可疑迹象。数周后安全团队才发现数千份客户资料通过一个虚假内部对等方被复制。发现层被攻破整个路由信任模型就崩塌了。发现不等于信任。三、现实世界中的回响恶意 MCP 服务器与 Agent-in-the-Middle上述场景并非纯粹的理论推演。2025 年 9 月安全研究人员发现了首个在野利用的恶意 MCP 服务器 npm 包postmark-mcp。攻击者复制了合法的 Postmark 邮件服务 MCP 实现只添加了一行代码将所有经 AI 智能体发送的邮件密送到攻击者控制的地址。这个包在被移除前被下载了超过 1,600 次任何使用该 MCP 服务器发送邮件的用户其密码重置链接、发票、内部通信都静默泄露。这起事件与 ASI07 的核心关切高度吻合智能体信任了一个“看起来内部”的工具端点而这个端点从未真正证明过自己的身份和意图。攻击者不需要攻破任何单个智能体只需要在通信链路上插入一个虚假的参与者。学术界也在系统性地验证这一威胁。2025 年 ACL Findings 发表的一项研究提出了Agent-in-the-Middle (AiTM)攻击攻击者不攻破任何单个智能体仅通过拦截和操纵智能体之间的消息就能破坏整个多智能体系统。研究者在多种框架、通信结构和真实应用中验证了 LLM-MAS 对通信攻击的脆弱性。另一项针对 MCP 生态的实证研究则展示了“工具投毒”“傀儡攻击”“拉地毯”等四类攻击向量证明恶意 MCP 服务器可以在用户不知情的情况下触发访问私有文件、控制设备转移数字资产等有害行为。四、防御的核心逻辑证明通道、证明载荷、证明时机、证明对等方ASI07 的防御不能靠单一措施。消息在传输、路由、发现和语义四个层面都可能被攻破防御必须分层。下表汇总了各层防御的关键控制与对应拦截的攻击场景防御层核心控制拦截的攻击场景证明通道端到端加密 双向认证mTLS、每智能体独立凭据、PKI 证书固定、前向保密伪造/未授权智能体接入对话但不解决载荷篡改和重放证明载荷数字签名、载荷与上下文哈希、自然语言感知清洗、意图差分检测隐藏/修改指令处方篡改二甲双胍→胰岛素在进入文档智能体前即失败证明时机nonce、会话标识符、任务窗口绑定的时间戳、短期消息指纹/状态哈希、一次性令牌消费检查财务审批重放第二笔 25,000元被识别为已消费的旧消息证明对等方经过认证的智能体注册中心、签名智能体卡片、对等允许列表、数字证明身份/来源/描述符完整性零售账单虚假端点无法出现在发现结果中恶意 MCP 端点无法被信任协议与能力安全禁用弱/遗留通信模式、协议固定与版本强制、拒绝降级与未识别 schema、验证能力/版本指纹一致协议降级注入目标与风险参数语义分叉导致的“脑裂”元数据推断限制固定大小或填充消息、平滑通信速率、避免确定性调度通过流量模式推断智能体角色与决策周期发现与路由保护密码学身份认证所有发现/协调消息、注册中心访问控制与信誉验证、异常路由流监控、敏感重路由治理门发现欺骗、A2A 注册欺骗、Agent-in-the-Middle 描述符投毒可观测性记录完整信任路径握手、签名校验、nonce、失败、发现事件、路由审批让“看起来正常”的内部流量中的异常信任决策变得可见第一层证明通道。端到端加密加双向认证mTLS是基础。每个智能体使用独立凭据PKI 证书固定前向保密。没有 mTLS伪造或未授权的智能体仍然能在对话中占有一席之地。但 mTLS 只解决“通道另一端是谁”不解决“载荷是否被改过”。第二层证明载荷。对消息进行数字签名同时对载荷和上下文做哈希。更重要的是在语义层面做检测——自然语言感知的清洗和意图差分用来发现隐藏或修改的指令。医疗处方场景中如果文档智能体验证了载荷签名胰岛素篡改会在处理之前失败。第三层证明时机。防重放需要 nonce、会话标识符和任务窗口绑定的时间戳。短期消息指纹或状态哈希用于检测跨上下文重放。关键原则是一次性令牌必须真正只被消费一次。付款审批场景中如果执行智能体检查了审批标识符是否已被消费第二笔 £25,000 就不会发生。第四层证明对等方。发现和路由必须用密码学身份来认证。服务注册中心需要访问控制和经过验证的信誉只允许经过签名的智能体卡片和已证明身份的智能体出现在发现结果中。零售账单场景中如果分诊智能体查询的是一个经过认证的注册中心虚假账单端点根本无法出现。此外协议固定和版本强制同样重要。定义并执行允许的协议版本MCP、A2A、gRPC拒绝降级尝试和未识别的 schema验证双方声明的能力和版本指纹一致。元数据推断限制则针对侧信道固定大小或填充消息、平滑通信速率、避免确定性的通信调度让攻击者难以仅从流量模式推断智能体角色和决策周期。可观测性则记录完整的信任路径——握手、签名校验、nonce、失败、发现事件、路由审批——让“看起来正常”的内部流量中的异常信任决策变得可见。五、结语ASI07 之所以危险恰恰因为它攻击的是多智能体系统最引以为傲的特性自主协作。智能体被设计为相互信任、高效协调而攻击者利用的正是这种设计中的隐含信任假设。一条内部消息看起来可信不等于它真的可信。一个 schema 验证通过的消息可能语义致命。一个签名有效的审批可能已经被消费过。一个服务发现返回的端点可能从未证明过自己。传统 MITM 防护TLS/mTLS解决的是“通道安全”而 ASI07 要求的是通道、载荷、时机、对等方四者同时被证明——这正是它与普通未加密协议和中间人攻击最根本的分野。对于正在构建多智能体系统的团队最务实的一条建议是在每一个智能体处理对等消息之前先让它证明自己是谁、消息是否完整、时机是否正确、对等方是否经过认证。这不会让系统变得绝对安全但会让 ASI07 描述的那些“看起来正常、实则灾难”的场景在到达下游之前就被拦截。