随着 AI Agent 技术快速发展，人工智能应用正在从“单模型完成任务”逐渐转向“多个智能体协同工作”。研究、编码、审查、数据分析等不同 Agent 可以根据自身职责完成任务，再由编排器统一调度和汇总结果。
这种模式提升了复杂任务的处理能力，却也带来了一个容易被忽视的问题：当 Agent 开始相互传递信息，一个 Agent 接收到的恶意内容，也可能影响整个协作链路。
典型的多智能体工作流程通常可以概括为：
用户请求 → 任务编排 → Agent 分工 → 多 Agent 执行 → 信息交换 → 结果汇总 → 最终输出
在这一过程中，不同 Agent 之间需要不断交换网页搜索结果、文件内容、API 数据、任务状态以及其他 Agent 生成的信息。
问题恰恰出现在这里。
传统应用通常会重点关注用户输入是否安全，但在多智能体环境中，真正需要防范的不只是用户，还包括 Agent 获取的外部数据，以及 Agent 之间相互传递的信息。
例如，一个负责资料检索的 Agent 从网页中获取内容，如果网页中混入针对大模型设计的隐藏指令，而系统没有对外部数据与指令进行有效隔离，那么污染内容就可能随着任务流继续传递。
于是原本正常的流程可能变成：
外部内容污染 → Agent 处理异常 → 污染信息进入共享上下文 → 下游 Agent 接收 → 异常行为继续传播
这使多智能体安全问题从单点风险演变成了链式风险。
消息注入是较为典型的一类风险。
Agent 在处理网页、文档、邮件等外部信息时，如果没有明确区分“数据”和“指令”，攻击者就可能把特殊内容隐藏在正常信息中，诱导 Agent 偏离原来的任务。
更危险的是，被影响的 Agent 可能继续把处理结果发送给其他 Agent。
攻击目标因此不一定需要直接接触最终执行 Agent，而可以通过上游 Agent 间接影响下游节点。
现代 Agent 通常拥有搜索、文件读取、数据库访问、API 调用以及代码执行等工具。
Agent 会默认工具返回的数据具有一定可信度。
如果搜索结果、API 响应、文件内容或者第三方工具返回值遭到污染，Agent 就可能依据错误甚至恶意的数据继续做出决策。
与直接提示注入相比，这种方式更加隐蔽，因为异常信息来自 Agent 本身“主动调用”的工具。
多个 Agent 为提高协作效率，经常共享上下文、数据库、知识库或者任务状态。
一旦共享数据遭到污染，风险就不再局限于某一个 Agent。
任何读取该状态的 Agent 都可能受到影响，从而形成：
单点污染 → 多节点读取 → 异常扩散
因此，共享记忆和共享状态在提高多智能体协作能力的同时，也可能成为风险传播的重要通道。
多智能体系统的核心优势之一，就是 Agent 之间可以互相信任并传递工作成果。
但这种优势同样可能成为攻击者利用的突破口。
例如：
Research Agent → Coding Agent → Review Agent → Execution Agent
正常情况下，研究 Agent 获取资料，编码 Agent 根据资料生成程序，审查 Agent 检查结果，最后交给执行环境处理。
如果第一阶段的信息已经受到污染，而系统又缺少有效的内容隔离和安全检查，那么异常内容就可能沿着整个任务链继续传递。
这与传统网络安全中的横向移动具有一定相似性。
区别在于，传统攻击通常围绕账号、主机和网络权限展开，而 Agent 环境中的传播载体可能变成：
自然语言、上下文、工具结果、共享记忆以及任务状态。
攻击者利用的不是单纯的软件漏洞，而是智能体之间建立起来的“信任关系”。
多智能体系统通常存在一种默认逻辑：
既然信息来自内部 Agent，那么它应该是可信的。
但实际上，“内部 Agent”并不意味着“内部数据一定安全”。
一个 Agent 可能因为读取恶意网页、处理污染文件或者调用异常工具而受到影响。
如果下游 Agent 无条件信任它的输出，就可能形成连续的信任传递：
Agent A 信任 Agent B → Agent B 信任外部内容 → 外部内容被污染 → 风险最终传递给 Agent A。
因此，多智能体安全的核心问题之一，就是重新定义系统内部的信任边界。
面对这类风险，仅仅在 System Prompt 中增加一句“不要执行恶意指令”并不足够。
更合理的方案，是建立多层纵深防御体系。
首先需要控制单个 Agent 的风险。
对于网页、文件、邮件以及第三方数据，应明确标记为“不可信输入”，并进行必要的内容检查。
Agent 输出同样需要审计。
尤其涉及代码生成、Shell 命令、文件操作、网络请求等高风险行为时，不应直接进入执行环境。
同时可以建立 Agent 行为基线。
如果一个平时只负责搜索资料的 Agent 突然要求执行系统命令、访问敏感目录或者主动向外部地址发送数据，就应该触发异常检测。
Agent 之间不能仅凭“来自内部”判断信息是否可信。
可以通过身份认证、消息签名、完整性校验等机制，确认：
谁发送了消息、消息有没有被修改、发送方是否具有对应权限。
对于重要任务，还可以记录完整的 Agent 通信链路，为异常分析和安全审计提供依据。
传统内部系统经常采用“内部默认可信”的思路，而多智能体环境更适合引入零信任理念：
默认不信任，持续进行验证。
即使两个 Agent 都属于同一个系统，也应该根据身份、任务、权限和行为动态判断是否允许通信以及允许执行什么操作。
Agent 的权限也应该遵循最小化原则。
负责网页检索的 Agent 没有必要拥有服务器管理权限；负责生成报告的 Agent，也不应该默认获得任意代码执行能力。
Agent 能力正在越来越依赖 Skill、Plugin、MCP 和其他第三方扩展。
这些组件能够读取文件、访问网络、调用 API，部分甚至拥有代码执行权限。
因此安装一个第三方 Skill，本质上可能等于向 Agent 系统引入一个新的供应链节点。
在部署之前，应重点检查：
来源是否可信、申请了哪些权限、是否存在异常网络访问、是否涉及代码执行，以及后续更新是否可能引入新的风险。
传统网络安全重点关注：
服务器、终端、账号、网络和应用程序。
进入 Agent 时代之后，还需要增加新的安全对象：
Prompt、Context、Memory、Tool、Skill、Plugin以及Agent之间的通信关系。
未来企业部署大量 AI Agent 后，可能形成新的“AI 内部网络”。
一个企业内部可能同时存在财务 Agent、客服 Agent、运维 Agent、研发 Agent、数据分析 Agent以及安全 Agent。
这些智能体相互调用、共享数据并访问企业内部系统。
此时，一个 Agent 出现安全问题，影响的可能不只是一次对话，而可能进一步影响与它存在协作关系的其他智能体。
多智能体系统正在让 AI 从“回答问题”走向“自主完成任务”，但自主能力越强，安全边界也就越复杂。
未来需要保护的不只是模型本身，还包括 Agent之间的通信、共享状态、工具调用以及整个扩展生态。
对于正在部署多智能体系统的企业而言，至少应该逐步建立输入验证、输出审计、最小权限、身份认证、行为监控以及 Skill/Plugin 供应链审查机制。
因为在多智能体时代，一个值得重新思考的问题已经出现：
当一个 Agent 告诉另一个 Agent“这是可信信息”时，系统凭什么相信它？
网站资讯
渠道合作
解决方案
更多服务
