多智能体通信中的三大攻击面
最近的一项研究测试了 17 个处于多智能体配置中的前沿 LLM,发现当恶意指令来自同行智能体时,82% 的模型会执行这些指令 —— 尽管当用户直接发出完全相同的指令时,它们会拒绝执行。如果你正在交付多智能体系统,这个数字应该让你重新审视你的威胁模型。你的智能体可能在个体层面已经过加固,但作为一个整体,它们并非如此。
多智能体架构引入了大多数安全思维所忽视的通信渠道。我们加固了模型、系统提示词和 API 边界,但我们几乎不花时间去关注当智能体 A 发送消息给智能体 B 时会发生什么 —— 谁编写了该消息,它是否被篡改过,智能体 B 参考的记忆是否在三个会话前被一个从未接触过智能体 A 的攻击者所植入。
在多智能体通信中存在三个截然不同的攻击面。它们的运作方式不同,需要的防御措施不同,失败的方式也各异。对于任何将智能体流水线投入生产环境的人来说,熟练掌握这三者都是先决条件。
攻击面一:跨智能体边界的提示词注入
提示词注入(Prompt Injection)在单智能体案例中已广为人知:攻击者在智能体处理的内容(文档、网页、检索到的块)中嵌入指令,而这些指令会覆盖或增强系统提示词。在多智能体系统中,同样的攻击在结构上变得更难遏制,因为智能体将输出作为可信输入传递给其他智能体。
考虑这样一个流水线:一个研究智能体检索文档、进行总结,并将摘要传递给写作智能体。写作智能体将研究智能体的输出视为任务规范,而不是不可信的外部内容。如果攻击者能够通过污染网页、数据库记录或搜索结果来影响研究智能体检索的内容,他们就可以注入指令,这些指令会直接传播到写作智能体的上下文中,且没有任何迹象表明它们源自系统外部。
AgentDojo 基准测试通过 97 个任务中的 629 个注入测试用例对智能体进行评估,发现嵌入在工具响应末尾的注入在针对基于 GPT-4o 的智能体时,成功率高达 70%。在多步骤流水线中,成功率会叠加:第二步中部分成功的注入会成为第三步的输入,而第三步可能会将其视为事实真相(Ground Truth)。
架构上的问题在于,智能体没有原生的消息溯源(Provenance)概念。接收同行消息的智能体没有现成的方法来区分“这来自我们编排器的可信规划模块”和“这条消息经过了一个接触过攻击者控制内容的检索步骤”。信任级别默认取决于消息在上下文中扮演的角色 —— 而编排器消息通常会获得极高的信任。
Devin AI 的漏洞具体展示了这一点:研究人员证明,这个异步编码智能体可以通过注入的仓库内容被操纵,从而暴露内部端口、泄露访问令牌并安装命令与控制(C2)恶意软件。注入媒介是智能体理应读取的内容,而不是它理应遵循的指令。智能体未作区分。
这在协议层面上的要求: 接收其他智能体输出的智能体应将该输出视为“已污染”,除非它通过了验证。这意味着要跟踪内容是源自外部检索步骤还是直接来自编排器指令,并据此应用不同的信任级别。任何处理过外部数据的智能体输出都应标记溯源注释,以便下游智能体在采取行动前进行检查。
攻击面二:智能体欺骗与身份冒充
第二个攻击面是身份。在大多数已部署的多智能体系统中,智能体通过在对话中的位置、消息头中的名称字符串或永不轮换的 API 密钥来相互识别。这些都无法提供有意义的身份验证。
智能体欺骗通过冒充流水线中可信的智能体来运作。能够向通信渠道注入消息的攻击者只需要模仿可信同行的格式,即可绕过大多数访问控制。测试多智能体架构的研究报告显示,在攻击者拦截消息或合成看似来自合法智能体的新消息的“智能体中间人(Agent-in-the-Middle)”攻击中,成功率达到 40–70%。
这种攻击特别有效,因为多智能体编排框架是为易用性而构建的,而不是为了对抗性环境。一个被攻破的智能体如果注入冒充编排器的虚假消息,通常会获得编排器级别的信任。因此,单个被攻破的节点可以指示同行采取它本身无法直接执行的特权操作。
更复杂的变体是“智能体会话走私(Agent Session Smuggling )” —— 恶意远程智能体在握手序列期间,在合法请求和响应之间注入隐藏指令。Unit 42 记录了证明该概念的攻击,展示了利用此技术进行未经授权的股票交易和信息窃取。门槛很低:攻击者只需要说服受害者智能体连接到恶意同行一次即可。
智能体供应链攻破进一步扩展了这一点。在智能体注册于服务发现注册中心的企业级多智能体部署中,能够修改注册表元数据的攻击者可以将合法智能体重定向到伪造的端点。每个信任该注册表的智能体随后都会与攻击者的基础设施进行通信,同时还以为自己正在与授权的内部系统对话。
这在协议层面上的要求: 智能体在进行任何实质性交换之前,应出示经加密签名的身份凭证 —— 一些框架称之为 AgentCards。接收智能体根据发行者的公钥或注册表验证签名。经过签名的凭证应包括声明的能力和范围,以便可以将自称为财务报告模块的智能体验证为仅对财务操作拥有权限。防止传输中篡改的消息级 HMAC 签名是一个独立但互补的要求。
攻击面三:内存投毒 (Memory Poisoning)
第三个攻击面最容易被低估,因为它是异步且持久的。前两种攻击都发生在会话(Session)内,而内存投毒则是跨会话的。它将恶意内容插入持久化存储中,Agent 会在攻击者离开很久之后检索并执行这些内容。
大多数生产环境中的 Agent 系统都维护着某种形式的持久化内存:用于语义检索的向量存储(Vector Stores)、用于对话上下文的情景 记忆(Episodic Memory)日志、以及 Agent 在工作时更新的知识库。这些存储是由 Agent 自己写入的。攻击者如果能影响 Agent 的写入内容 —— 无论是通过上一次会话中的成功注入、通过 Agent 总结并存入内存的精心设计的用户输入,还是通过直接的数据库访问 —— 就会在未来的每一次会话中埋下一个常驻后门。
MINJA 攻击(发表于 NeurIPS 2025)证明了即使没有数据库的直接写入权限,也可以通过仅查询交互对内存存储进行投毒。通过设计特定的查询,使 Agent 在正常操作中将恶意的合成记忆存储下来,攻击者可以埋下在未来检索时浮现的指令。与仅影响单次响应的提示词注入不同,中毒的内存记录在每一个触发检索条件的会话中都会被提取并执行。
情景记忆尤其脆弱,因为 Agent 被设计为信任其之前的状态。当 Agent 检索一条内存记录时,隐含的假设是“这是我之前知道的事”。目前还没有原生机制去询问:“这条记录是否是在对抗性环境下写入的?”
跨 Agent 的内存共享进一步扩大了爆炸半径。在由研究 Agent 写入、推理 Agent 读取的共享向量存储架构中,研究 Agent 输出中的一次投毒事件就能无限期地腐蚀推理 Agent 的行为。推理 Agent 无法看到研究 Agent 的写入历史。
这在协议层面的要求: 内存存储需要写入溯源标记(Write Provenance Tagging)—— 每条记录都应携带元数据,说明是由哪个 Agent、在哪个会话上下文中写入的,以及该会话是否处理了外部输入。读取操作应触发溯源检查:在接触过外部内容的会话期间写入的内存,其信任等级应低于根据内部编排指令写入的内存。更强化的版本是架构隔离:处理外部检索的 Agent 应写入独立的内存分区,而非持有内部组织状态的 Agent 所使用的分区,并在两者之间 设置显式的晋升网关(Promotion Gates)。
为什么仅保护单个 Agent 是不够的
82% 的对等 Agent 遵从性(Peer-agent Compliance)发现并不是模型对齐的失败,而是协议设计的失败。能够正确拒绝用户直接请求的模型,在面对来自对等 Agent 的同样请求时却会遵从,因为对等通信的信任模型与用户输入的信任模型完全不同。模型的行为与其系统架构的设计是一致的。
这就是多 Agent 系统中“仅靠边界安全”的核心问题。针对直接的用户攻击加固每个 Agent 的系统提示词,对于来自被攻破的对等 Agent 的消息毫无作用。当攻击向量是三个会话前写入的中毒内存记录时,保护 API 入口也无济于事。单 Agent 的防御措施在多 Agent 环境中组合效果很差,因为攻击面在本质上发生了变化,而不只是规模上的扩大。
Agent 级应用 OWASP Top 10(2025 年 12 月发布)将不安全的 Agent 间通信和级联故障列入前十大风险,排名甚至高于传统安全框架优先考虑的大多数漏洞。非确定性的涌现故障 —— 即多个 Agent 与共享资源交互产生在任何单个 Agent 中都不存在的故障模式 —— 比传统的软件故障更难检测,因为它们不会产生一致的错误信号。由于上游三层的一个中毒内存记录而导致行为异常的 Agent,看起来更像是模型漂移(Model Drift),而不是遭到了攻击。
将通信安全构建到流水线中
多 Agent 通信的纵深防御方法有三个不可逾越的层面。
加密消息认证 处理伪造问题。每一条 Agent 间的消息都应该用发送者的私钥进行签名。接收者在处理前验证签名。这在分布式系统安全中是标准做法,通过 HMAC 或非对称密钥可以轻易实现。大多数框架中缺失的一环是强制执行:签名需要在传输层强制执行,而不是在应用层可选。
污点传播与溯源跟踪 处理注入问题。消息和内存记录应携带注释,标明它们是否源自外部内容。接收到带有“污点”消息的 Agent 应执行更严格的校验 —— 检查消息中的指令是否在发送 Agent 的声明范围内,是否请求了与既定任务不符的操作,以及指令模式是否符合合法对等方的通信习惯(针对异常命令序列的行为指纹识别)。
内存命名空间隔离 处理投毒问题。由处理外部检索的 Agent 写入的持久化存储,应与内部编排 Agent 写入的存储隔离。命名空间之间的晋升 —— 将研究发现从“外部来源”移动到“受信任的内部知识” —— 应该需要显式的授权,对于高风险决策,理想情况下应设有离线的人工审查关卡。
这些并不是罕见的要求。它们与保护后端系统中服务间通信的原则相同:认证调用方、即使对受信任源也要验证输入、不让一个被攻破的服务随意改写共享状态。这些原则之所以尚未成为多 Agent 框架的标准,是因为大多数框架在设计时优先考虑的是能力而非安全性。在自主 Agent 系统大规模处理敏感业务之前,这种优先级顺序需要反转。
48% 的安全专业人士将 Agentic AI 视为 2026 年的首要攻击向量,他们正是针对这一缺口 做出的反应。漏洞不在于任何单个模型,而在于当功能强大的模型在没有认证和隔离的情况下开始互相交流时,所产生的那种盲目信任。而在过去几十年里,服务间通信一直都必须具备认证和隔离。
- https://www.mdpi.com/2078-2489/17/1/54
- https://genai.owasp.org/llmrisk/llm01-prompt-injection/
- https://arxiv.org/html/2506.23260v1
- https://allabouttesting.org/owasp-agentic-ai-threat-t9-identity-spoofing-impersonation-in-ai-systems/
- https://galileo.ai/blog/multi-agent-systems-exploits
- https://unit42.paloaltonetworks.com/agent-session-smuggling-in-agent2agent-systems/
- https://arxiv.org/html/2511.03841v1
- https://arxiv.org/html/2603.20357v1
- https://medium.com/@michael.hannecke/agent-memory-poisoning-the-attack-that-waits-9400f806fbd7
- https://www.lakera.ai/blog/agentic-ai-threats-p1
- https://unit42.paloaltonetworks.com/indirect-prompt-injection-poisons-ai-longterm-memory/
- https://agentmessaging.org/
- https://medium.com/@adnanmasood/security-in-agentic-communication-threats-controls-standards-and-implementation-patterns-for-bf1eadc94e95
- https://opensource.microsoft.com/blog/2026/04/02/introducing-the-agent-governance-toolkit-open-source-runtime-security-for-ai-agents/
- https://adversa.ai/blog/cascading-failures-in-agentic-ai-complete-owasp-asi08-security-guide-2026/
- https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
- https://arxiv.org/html/2511.15759v1
- https://www.redhat.com/en/blog/model-context-protocol-mcp-understanding-security-risks-and-controls
- https://www.pillar.security/blog/the-security-risks-of-model-context-protocol-mcp/
- https://arxiv.org/html/2603.22489
