引言
多智能体系统正在成为 AI 应用的主流架构。一个编排器调用文档处理智能体，文档处理智能体查询数据库智能体，数据库智能体又把结果交给风控智能体------消息在内部总线、API 和注册中心之间不停流动。问题恰恰出在这里：流量一旦被打上"内部"的标签，就很容易被当作可信的。
OWASP Agentic Top 10 将 ASI07: Insecure Inter-Agent Communication 列为第 7 名，指向的正是这个盲区：智能体之间缺乏身份验证、完整性校验和语义验证，导致攻击者可以拦截、篡改、重放或伪造智能体消息。与 ASI03（身份与权限滥用）关注凭据盗用不同，ASI07 聚焦于传输中的消息本身；与 ASI06（记忆与上下文投毒）关注存储知识污染不同，ASI07 的危害发生在实时通信链路上。
对于开发者和安全工作者来说，理解 ASI07 的关键不在于记住定义，而在于认清一个事实：内部来源不等于完整性证明。一个 JSON 结构完美、签名有效的消息，完全可能是有害的。
一、ASI07 与传统未加密协议、中间人攻击的本质区别
很多开发者会问：这不就是没加密、不就是 MITM 吗？加上 TLS 不就行了？答案是否定的。ASI07 与传统安全问题的核心区别在于：传统安全关注的是"数据有没有被偷看或改动"，而 ASI07 关注的是"智能体的行为有没有被改写" 。一条经过加密、签名验证的消息，在传统安全视角下可能是完全安全的；但在多智能体系统中，如果接收方没有验证消息的语义意图 和新鲜度，这条"安全"的消息仍然可能让智能体执行完全错误甚至有害的动作。
下表从多个维度对比两者的差异：
| 维度 | 传统未加密协议 / 中间人攻击（MITM） | ASI07 不安全的智能体间通信 |
|---|---|---|
| 攻击目标 | 数据本身------窃取密码、篡改金额、注入恶意代码 | 智能体的决策逻辑：不只改数据，更要改"智能体接下来会做什么" |
| 信任假设 | 假设"内部网络/已认证通道相对可信"，安全边界在系统外围，进入内网即放行 | 攻击的恰恰是智能体之间默认的信任；利用的是去中心化架构中"来自内部对等方即可信"的架构性假设 |
| "安全"的定义 | 加密 + 签名 = 安全；消息完整、来源可验证即过关 | 加密 + 签名 ≠ 安全；消息可以加密、签名有效、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 描述的那些"看起来正常、实则灾难"的场景，在到达下游之前就被拦截。