多智能体通信中的三大攻击面
最近的一项研究测试了 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 签名是一个独立但互补的要求。
- 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
