💻 computer science

ChannelGuard: Safe Models Do Not Compose into Safe Multi-Agent Systems

该论文介绍了 ChannelGuard，这是一个无需训练的深度防御框架，通过在每个智能体间通道上设置确定性的信息瓶颈门控，来保障多智能体大语言模型系统的安全，从而在不依赖不透明的提供商侧过滤器或额外大语言模型调用的情况下，有效阻断工具投毒并降低提示词注入的成功率。

原作者： Elias Hossain, Md Mehedi Hasan Nipu, Fatema Tuj Johora Faria, Tasfia Nuzhat Ornee, Maleeha Sheikh

发布于 2026-07-23

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Elias Hossain, Md Mehedi Hasan Nipu, Fatema Tuj Johora Faria, Tasfia Nuzhat Ornee, Maleeha Sheikh

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，一支由专家级机器人组成的团队正在通力合作，解决一个复杂的谜题。其中一个机器人（规划者）负责将大问题拆解成小线索。其他机器人（执行者）则负责外出寻找这些线索、检查笔记并使用特殊工具。最后，第四个机器人（综合者）将所有的答案整合在一起，向你讲述这个故事。在人工智能的世界里，这被称为“多智能体系统”。它就像一场高科技的接力赛，接力棒就是从一个 AI 传递给下一个 AI 的信息。

长期以来，科学家们一直担心第一次交接环节：如果人类用一个狡猾的指令欺骗了第一个机器人怎么办？我们已经在正门口建造了“保安”来拦截这些诡计。但本论文提出了一个可怕的问题：如果在比赛的中途发生了呢？如果一个机器人被某个工具或共享笔记本中的笔记所欺骗，然后又将这个错误的念头传递给了下一个机器人呢？论文指出，虽然正门有守卫，但机器人之间的走廊却是敞开的。事实证明，许多这类机器人团队之所以安全，仅仅是因为托管它们的云服务公司在机器人传递信息之后、最终答案展示之前，设置了一个隐形的过滤器来拦截坏念头。作者称之为“借来的安全”，而他们想要构建的是一种安全感属于团队本身，而非属于房东的系统。

问题所在：隐形的走廊

研究人员埃利亚斯·霍塞恩（Elias Hossain）及其团队研究了这些 AI 团队是如何运作的。他们发现，每当一个机器人向另一个机器人传递信息时——无论是子任务、工具结果还是记忆笔记——信息都会通过一个“通道”传输。这些通道目前是无人监管的。攻击者可以将恶意指令混入工具的结果或记忆笔记中，从而误导下一个机器人去做危险的事情。

可怕之处在于，当科学家们测试这些系统时，往往会看到完美的安全性记录：零次攻击成功。但作者发现，这种安全性是一种幻觉。在他们的测试中，当他们在特定的云提供商（Azure）上运行系统时，系统拦截了 90% 的攻击。然而，拦截行为并非由 AI 团队完成，而是由云提供商的服务端过滤器完成的。如果他们切换到没有这种特定过滤器的不同云提供商（如 Anthropic），这种“安全性”就会消失，攻击也会成功。系统看起来安全，只是因为它在向云公司“借用”保护，而不是因为 AI 团队本身是安全的。

解决方案：ChannelGuard

为了解决这个问题，该团队开发了一种名为 ChannelGuard 的新防御机制。ChannelGuard 不仅仅是在正门设防，它还在机器人之间的每一个走廊都设置了安全检查站。

把它想象成俱乐部里每一扇门前的保镖：

检查站： 每当一条消息试图从一个机器人移动到另一个机器人时，它都会撞上一个闸门。
扫描： 这个闸门并不使用复杂的 AI 来猜测消息是否有害。相反，它使用一种简单、快速的数学技巧。它将消息拆分为句子，并将其与一小组“坏词组”（类似于危险指令的“通缉令”）进行对比。
决策： 如果消息看起来太像坏词组，闸门会立即拦截它。如果它只是有一点可疑，它可能会切掉危险的部分并让安全的部分通过。如果它是干净的，它就会放行。

至关重要的是，这些闸门是“无需训练”的，这意味着它们不需要学习或研究新数据即可工作。它们只需使用坏词组列表和数学公式即可瞬间做出决策。

他们的发现

该团队针对八种不同类型的诡计，对 ChannelGuard 进行了 2,100 次攻击尝试测试。以下是他们的发现：

真实的安全性，而非借来的安全性： 在“工具投毒”攻击（即坏的工具结果试图欺骗执行者）中，旧系统依赖云提供商来拦截 90% 的攻击。然而，ChannelGuard 本身就能拦截 100% 的攻击，无论使用哪种云提供商。它使安全性具有“提供商无关性”，这意味着无论系统在哪里运行都是安全的。
速度提升： 由于 ChannelGuard 可以在坏消息到达昂贵且缓慢的 AI 模型之前将其拦截，它实际上提高了系统的速度。对于“提示词注入”攻击（即在正门处的诡计），ChannelGuard 比未受保护的系统快了 3.30 倍，因为它通过早期切断坏消息，节省了计算机进行不必要工作的资源。
没有智力损耗： 系统并没有变“笨”。在没有任何攻击的数学问题（GSM8K）测试中，ChannelGuard 保持了完全相同的准确率（0.867），证明它不会误伤好的想法。
弱点： 该系统并非完美。如果攻击者知道“坏词组”列表，并使用意思相同但表达不同的词来重写他们的诡计（称为“自适应改写”），闸门就会感到困惑。在这种情况下，系统的失败率约为 66%，与未受保护的系统持平。作者承认，对于这类聪明的、经过改写的诡计，另一种防御方式（即改变词汇以迷惑攻击者的防御方式）效果更好。

总结

论文得出结论，我们不能仅仅信任云公司来保护我们的 AI 团队。我们需要在团队内部建立自己的守卫。ChannelGuard 表明，通过在每个机器人之间设置简单、快速的检查站，我们可以捕捉到那些溜过正门的攻击，并在它们扩散之前阻止它们。虽然它不能捕捉到所有类型的诡计（尤其是那些自我改写的诡计），但它将“借来的安全”转化为了“拥有的安全”，使系统无论在何处运行都足够可靠。作者发布了所有的数据和代码，以便他人核查其工作，证明了 AI 团队的安全性需要构建在架构之中，而不仅仅是寄希望于外部。

技术摘要：ChannelGuard：安全模型并不构成安全的多智能体系统

1. 问题陈述

现代大语言模型（LLM）应用日益依赖于多智能体系统，其中规划者（Planner）负责分解任务，执行智能体（Worker Agents）负责执行任务（通常涉及调用工具或读取共享内存），而验证器/合成器（Verifier/Synthesizer）则生成最终输出。作者指出存在一个关键的安全漏洞：现有的防御措施主要集中在输入边界（用户 $\to$ 规划者）或依赖于不透明且具有随机性的提供商侧过滤器（例如 Azure Content Safety），而智能体间的通道（规划者 $\to$ 执行者、工具 $\to$ 执行者、内存 $\to$ 执行者等）仍处于无人监控的状态。

本文认为当前的评估指标，特别是攻击成功率（ASR），具有误导性。一个流水线在特定后端（如 Azure GPT-5）上显示 ASR 为 0.000，并不代表该应用是安全的，而是因为云提供商的服务器端过滤器拦截了攻击。这产生了一个“机制替代”（mechanism substitution）问题：如果将后端更换为没有此类过滤器的模型（如 Anthropic Sonnet），安全结果仍可能显示为 0.000，但保护机制已完全转移到了模型的内部对齐（alignment）上，而这对于开发者而言是不可控且不可观测的。因此，从业者无法对系统的真实鲁棒性进行推理。

2. 方法论：ChannelGuard 框架

ChannelGuard 是一个无需训练的深度防御框架，旨在对每一个智能体间通道进行监测。它不需要修改智能体模型，也不需要重新训练。

核心组件

信息瓶颈（IB）门控：
- 部署位置： 在六个特定通道设置了门控：输入（IB-0）、规划者 $\to$ 执行者（IB-1）、工具 $\to$ 执行者（IB-3）、内存 $\to$ 执行者（IB-3-mem）、执行者 $\to$ 验证器（IB-2/IB-4）以及执行者 $\to$ 合成器（IB-5）。
- 机制： 每个门控通过将文本拆分为句子，利用本地 all-MiniLM-L6-v2 模型进行嵌入（embedding），并计算其与固定的、人工策划的对抗性短语库之间的最大余弦相似度。
- 决策逻辑： 门控计算风险得分并做出确定性的三路决策：
  - 通过（Pass）： 风险 < $\alpha\theta$ （文本原样通过）。
  - 压缩（Compress）： $\alpha\theta \le$ 风险 < $\theta$ （文本被截断至前 $N=2$ 个句子）。
  - 阻断（Block）： 风险 $\ge \theta$ （文本被替换为空字符串，从而阻断整个流水线）。
- 特性： 门控不增加 LLM 调用，不需要训练数据，且其决策独立于下游智能体模型。
感知不确定性的验证器：
- 使用独立的 LLM（Claude Sonnet 4.5）对存活的执行者输出进行评分，通过 5 次蒙特卡洛采样来确定平均安全得分和离散度。
- 它会将输出标记为“不安全”或“不确定”。
三重过滤器合成器：
- 最终的合成器仅接受通过了 IB-5 门控、平均安全得分 $\ge 0.5$ 且未被同时标记为“不安全”和“不确定”的答案。
- 如果没有任何输出存活，则返回硬拒绝（hard refusal），不再调用进一步的 LLM。

评估方法论

本文引入了一种逐迹归因（per-trace attribution）方法。系统不仅报告 ASR，还会记录究竟是哪一层（IB 门控、提供商过滤器、验证器或模型对齐）首先拦截了攻击。这使得进行“机制替代”分析成为可能，从而能够区分应用拥有的拦截行为与借用的提供商拦截行为。

3. 核心贡献

逐迹归因： 一种将仅基于结果的 ASR 转化为层面级解释的方法论，使“机制替代”（对后端过滤器的依赖）变得可衡量且可见。
提供商依赖性分析： 实证研究表明，在 Azure GPT-5 上，无防御流水线的零 ASR 保护中有 90% 源自提供商的过滤器。当切换到 Anthropic 后端时，这种保护完全转向了模型的对齐，证明了尽管安全结果相同，但其来源不同且不可控。
ChannelGuard 框架： 一个由六个嵌入相似度门控组成的系统，提供了应用拥有的、与提供商无关的阻断机制。
精确的界限划定： 本文明确指出了该框架失效的地方（白盒自适应改写）以及成功的地方，并辅以广泛的消融实验和基准测试。

4. 结果

评估涵盖了 2,100 条追踪记录，涉及八类攻击、五种防御手段和三个模型后端（Azure GPT-5, Anthropic Sonnet 4.5, Anthropic Haiku 4.5）。

工具投毒（Tool Poisoning）： 在所有三个后端中，ChannelGuard 在 IB-3 门控（工具 $\to$ 执行者）处均实现了 30/30 的阻断。相比之下，无防御的流水线在 Azure 上 100% 依赖 Azure 提供商过滤器进行阻断，而在 Anthropic 后端上则 100% 依赖模型自身的对齐。ChannelGuard 的机制保持固定且由应用所有。
提示词注入（Prompt Injection）： 与无防御的基准线相比，ChannelGuard 将 ASR 降低了 50%（从 0.333 降至 0.167）。
内存投毒（Memory Poisoning）： 在 Azure 技术栈上，提供商过滤器在两个系统中都占据了阻断的主导地位。然而，在 Anthropic 后端上，ChannelGuard 的 IB-3-mem 门控提供了部分阻断，其余部分由模型对齐处理，展示了“共享信用”的结果而非完全替代。
自适应改写（白盒攻击）： ChannelGuard 和无防御基准线均失败，ASR 约为 0.667。静态短语库无法检测语义等价但词汇差异巨大的改写。论文指出，一种非签名基准（SmoothLLM）在此类攻击上的表现更好。
效率： ChannelGuard 在聚合对抗性负载下的速度快了 1.19 $\times$ 。特别是在提示词注入方面，由于其 IB-0 门控在昂贵的模型调用之前就阻断了流水线，其速度提升了 3.30 $\times$ 。
推理保真度： 在良性 GSM8K 任务（无攻击）中，ChannelGuard 完全保留了推理准确性（两者的 CTCA 均为 0.867）。

5. 重要性与主张

本文声称，如果不对智能体间的通道进行显式监控，安全的模型也无法构成安全的多智能体系统。其主要意义在于：

揭示“安全幻觉”： 证明当前评估中的零 ASR 往往掩盖了对不透明、随机的提供商过滤器的完全依赖，而开发者无法控制或审计这些过滤器。
提供商无关性： 证明 ChannelGuard 提供了一种确定性的、可检查的阻断机制，无论底层模型后端如何变化，该机制都能保持一致，这与无防御流水线所“借用”的安全感截然不同。
深度防御： 将 ChannelGuard 定位为提供商过滤器或仅针对输入的防御措施的补充，而非替代品，它是一个必要的层，用于保障内部流水线的表面安全。

作者对框架的局限性持谦逊态度，承认静态短语库无法击败自适应的白盒改写，且目前的实现依赖于仅限英语的人工策划模板。他们总结道，下一步是通过对抗性方式学习短语库，以匹配其覆盖范围。