每个 Agent 都安全，为什么系统还是会被攻破？跨 Agent 信任洗白与双通道防御

随着 AI Agent 从单体应用逐渐发展为多智能体协作系统，一个新的安全问题开始浮现：如果系统中的每个 Agent 都已经部署了安全防护，那么由它们组成的整个系统，是否也一定安全？

直觉上似乎应该如此。毕竟，每个 Agent 都能抵御提示注入，多个 Agent 组合之后，理应也能抵御同样的攻击。但现实并没有这么简单。

2026 年 10 月，来自牛津大学等机构的研究人员在论文《Can CaMeLs Talk? Securing Multi-Agent Systems Against Indirect Prompt Injection Attacks》中，研究了这一问题。作者发现，即使系统中的每个 Agent 都使用 CaMeL 这种基于控制流隔离的安全架构，攻击者仍然可能通过 Agent 之间的通信接口，诱导下游 Agent 执行未经授权的操作。

论文原文（arXiv）

研究人员将这种现象称为 Boundary Laundering（边界洗白）：原本被识别为不可信的数据，在跨越 Agent 边界后，被重新解释成了可信指令。

为了解决这一问题，作者进一步提出 multi-CaMeL，通过双通道通信和数据来源追踪，在系统层面维持指令与数据之间的隔离。在新构建的 MultiAgentDojo 测试集上，这套机制将平均攻击成功率从无 CaMeL 防护时的 12.9%，降低至单 Agent CaMeL 防护时的 0.2%，并进一步降至 0%。

这项研究揭示了一个值得重视的问题：单个 Agent 的安全保证，并不会自动继承到整个多 Agent 系统。

CaMeL：不让模型读取危险数据，能否阻止提示注入？

理解这篇论文，需要先了解 CaMeL 的基本原理。

目前常见的提示注入防御，通常依赖模型自身的安全能力，或者在模型输入前增加一个检测环节。例如，使用安全模型识别恶意指令，通过 Prompt 告诉模型不要听从外部数据中的命令，或者提前清洗工具返回的内容。

这些方法虽然有效，但都有一个共同的局限：最终仍然需要依赖模型自身正确区分数据与指令。

CaMeL 选择了另一条路线。它不再试图让一个模型同时负责规划任务和理解不可信数据，而是从架构上将两项工作分开。

具体来说，CaMeL 将 Agent 中的大模型划分为两个角色。

第一个是 PLLM（Privileged LLM，特权规划模型），负责根据用户的可信指令生成任务执行程序，确定需要调用哪些工具、执行哪些操作。PLLM 可以决定系统的控制流，但不能直接读取外部工具返回的不可信数据。

第二个是 QLLM（Quarantined LLM，隔离模型），负责处理网页、邮件、数据库等外部信息，完成摘要、提取和解析任务，但不能独立调用具有特权的外部工具。

例如，用户要求 Agent 读取一封客户邮件，总结需求后发送给销售经理。

传统 Agent 会先读取邮件，再由大模型根据邮件内容决定下一步操作。如果邮件中包含要求把客户信息发送到其他邮箱的恶意指令，模型就可能被误导。

CaMeL 则让 PLLM 在读取邮件内容之前，先生成任务执行程序：读取邮件、调用 QLLM 生成摘要、把摘要发送给指定的销售经理。

之后，邮件内容只会进入 QLLM，不会直接返回 PLLM 让它重新规划任务。

这样，即使恶意指令成功影响了 QLLM 的输出，也不能直接要求 PLLM 临时增加一次未经授权的工具调用。

这种机制的核心是控制流完整性（Control-Flow Integrity，CFI），即不可信数据可以影响程序中的变量和预先定义的分支选择，但不能让系统生成原定计划之外的新执行路径。

此外，CaMeL 还可以通过 Capability（能力标签）追踪数据来源，并在工具调用时执行额外的安全策略，例如阻止包含机密信息的数据发送给未授权接收方。

从单 Agent 的角度看，这已经是一套非常有代表性的系统级提示注入防御架构。

但问题出现在多个 Agent 开始相互通信之后。

三个都有安全防护的 Agent，如何泄露了用户信息？

作者构建了一个典型的多 Agent 协作场景。

系统由三个 Agent 组成：

Orchestrator Agent（编排 Agent）：接收用户指令，负责协调任务。

SQL Agent（数据库 Agent）：负责查询数据库并返回结果。

Notification Agent（通知 Agent）：负责发送 Slack 消息或电子邮件。

三个 Agent 都部署了 CaMeL，每个 Agent 内部都具备 PLLM 与 QLLM 的隔离机制。

正常情况下，用户向编排 Agent 发出一条任务：查询所有求职者的信息，并通过 Slack 将摘要发送给 Julie。

编排 Agent 首先调用 SQL Agent 查询数据库，获得求职者信息后生成摘要，再调用通知 Agent，通过 Slack 发送给 Julie。

攻击者无法直接修改用户指令，也无法控制任何一个 Agent 的系统提示词，但可以在数据库内容中预先植入一段恶意指令，要求系统额外将求职者信息发送到攻击者指定的邮箱。

按照 CaMeL 的设计，这段恶意内容应该始终被当作不可信数据处理。然而，实验最终观察到，通知 Agent 不仅完成了正常的 Slack 消息发送，还额外生成并执行了一次电子邮件发送操作。

更值得关注的是整个攻击过程中各个 Agent 的表现。

首先，SQL Agent 并没有被直接攻破。 它只是按照任务要求查询数据库，返回包含恶意指令的数据。由于数据没有直接进入 SQL Agent 的 PLLM，因此没有改变它的执行计划。

其次，编排 Agent 也没有直接违反自身的控制流约束。 它接收 SQL Agent 返回的数据，通过 QLLM 生成摘要，然后按照预先规划的任务流程，调用通知 Agent。

真正的问题发生在第三步。

编排 Agent 调用通知 Agent 时，将摘要内容直接拼接进了一段自然语言任务描述，大致相当于：

“请通过 Slack 将以下摘要发送给 Julie：求职者信息……（其中包含恶意指令）。”

对于编排 Agent 来说，摘要仍然是来自外部数据库的不可信数据。

但对于通知 Agent 来说，整段自然语言却是来自上游 Agent 的任务指令。由于 CaMeL 将调用方视为当前 Agent 的可信用户，这段内容直接进入了通知 Agent 的 PLLM。

于是，一条原本被隔离的恶意指令，重新获得了影响控制流的能力。

通知 Agent 的 PLLM 在生成执行程序时，除了正常的 Slack 发送操作，还增加了一次向攻击者邮箱发送信息的操作。

SQL Agent 的执行计划没有变化，编排 Agent 的执行计划也没有变化，但通知 Agent 的执行计划发生了变化。

从单个 Agent 的安全边界看，它们都遵循了各自的 CaMeL 机制；但从整个系统看，攻击者已经成功引入了一项原始用户没有授权的操作。

Boundary Laundering：数据是如何跨越信任边界的？

作者将上述问题命名为 Boundary Laundering，可以翻译为“边界洗白”。

它与传统提示注入的区别在于，攻击不一定发生在 Agent 首次读取外部数据的时候，也可能发生在多个 Agent 之间转发信息的过程中。

传统提示注入通常是这样的过程：攻击者把恶意指令放进网页或文档，Agent 读取后错误地将其当作指令执行。

而边界洗白增加了一个环节：上游 Agent 已经将恶意内容识别为不可信数据，但在传递给下游 Agent 时，系统没有保留原有的信任属性，导致下游 Agent 把这些内容重新当作可信指令。

这个问题与传统软件安全中的信任边界问题有一定相似性。

例如，在 SQL 注入中，普通字符串如果被直接拼接进具有执行语义的 SQL 语句，就可能由数据变成代码的一部分。Agent 系统中的边界洗白虽然不依赖 SQL 解析器，但同样涉及数据与指令之间的混淆。

更深层的问题是，很多多 Agent 框架采用自然语言作为 Agent 间的主要通信方式。

上游 Agent 调用下游 Agent 时，常常只需要传递一个 Prompt。这个 Prompt 既包含任务要求，也可能包含来自数据库、网页或其他工具的原始数据。

对于下游 Agent 来说，它往往无法从通信接口上判断，哪些内容是上游 Agent 正式授权的任务，哪些只是上游 Agent 转发的外部信息。

一旦下游 Agent 将整段 Prompt 都视为可信指令，原本有效的安全隔离就可能失效。

论文进一步从形式化角度分析了这一问题。

作者研究了一类具有层级结构的 Agent-as-Tool 系统，即父 Agent 可以像调用工具一样调用子 Agent。在一定的工具调用表达能力假设下，作者证明，只要系统中存在返回不可信数据的工具，就不能仅凭每个 Agent 分别满足 CFI，推出整个系统也满足 CFI。

这涉及一个重要的系统安全概念：安全性质的可组合性（Security Compositionality）。

简单来说，单个组件满足某种安全性质，并不意味着多个组件通过任意接口连接之后，整体仍然满足这种性质。组件之间的通信协议，同样属于安全机制的一部分。

这也意味着，多 Agent 系统不能只关注每个 Agent 自身是否安全，还必须关注信任属性能否在 Agent 之间正确传递。

multi-CaMeL：将可信指令与不可信数据分开传输

针对边界洗白，作者提出了 multi-CaMeL。

它并没有重新训练一个更强的安全模型，而是修改 Agent 之间的通信方式，让可信指令和不可信数据通过不同的通道传递。

在原本的 Agent-as-Tool 架构中，调用一个子 Agent 可以只传入一个自然语言参数：

query_agent(message)

这意味着，任务指令和任务数据都可能被组织到同一个 message 中。

multi-CaMeL 将接口扩展为：

query_agent(message, variables)

其中，message 是可信指令通道，variables 是数据通道。

第一条通道：message，用于传递可信任务指令。

例如：“请把提供的摘要发送给 Julie。”

这部分内容可以直接进入下游 Agent 的 PLLM，让它理解需要完成什么任务，以及应该使用什么工具。

第二条通道：variables，用于传递实际数据。

例如，将数据库查询结果、邮件正文或文本摘要作为变量传入。下游 Agent 的 PLLM 不能直接读取这些变量的具体内容，而是在生成执行程序后，通过 get_variable 等运行时接口获取所需数据。

因此，通知 Agent 可以知道自己需要向 Julie 发送一份摘要，却不需要在规划工具调用时阅读摘要中的全部文本。

即使摘要中包含恶意指令，也不会直接进入具有特权的规划上下文。

不过，仅仅把接口拆成两个字段还不够。因为上游 Agent 仍然可能把不可信数据拼接进 message，重新造成相同的问题。

为此，作者还修改了 CaMeL 的运行时解释器，增加了两个关键约束。

其一，指令通道完整性（Instruction-channel Integrity）。

传递给下游 Agent 的 message 不能依赖工具返回值。系统需要追踪变量之间的数据依赖关系，如果发现某个 message 包含由不可信工具数据派生的内容，就必须阻止这种调用方式。

这不是依赖大模型判断某段文字是否危险，而是通过程序运行时约束，阻止不可信数据进入具有指令权限的通道。

其二，跨 Agent 来源保持（Cross-agent Provenance Preservation）。

不可信数据通过 variables 传递时，不能丢失原有的来源信息和 Capability 标签。

例如，一份内部客户资料即使经过多个 Agent 的查询、总结和格式转换，系统仍然需要知道这些内容最初来自内部数据库。

这样，后续 Agent 在调用邮件发送、文件共享等敏感工具时，才能继续依据数据来源和访问权限执行安全策略。

这里需要区分两种安全能力：指令通道完整性用于保护系统级控制流；来源信息和能力标签的保留，则为跨 Agent 数据流安全策略提供基础。只有进一步配置并执行相应策略，才能对敏感信息的流向施加约束。

因此，multi-CaMeL 的核心并不是简单的 Prompt 分隔符，而是通过双通道通信、运行时依赖追踪和来源信息保持，将原本局限于单个 Agent 的安全边界扩展到整个多 Agent 系统。

实验结果：攻击成功率降至 0%，但任务能力有所下降

为了验证 multi-CaMeL 的效果，作者使用了两套测试基准。

第一套是 AssetOpsBench，主要评估多 Agent 系统在真实业务流程中的任务执行能力。

第二套是作者基于 AgentDojo 扩展构建的 MultiAgentDojo。它将原有的办公、银行、Slack、旅行等工具使用场景，拆分为具有不同专业能力的子 Agent，再由编排 Agent 负责协调，从而模拟典型的多 Agent 系统。

MultiAgentDojo 包含 97 个正常用户任务和 35 类攻击目标。论文在不同模型上比较了三种架构：不使用 CaMeL、每个 Agent 独立使用 CaMeL，以及使用 multi-CaMeL。

1. 安全性：边界洗白攻击被有效阻断

在 MultiAgentDojo 的攻击测试中，作者得到以下结果：

这里的平均值来自五款模型的测试结果。每款模型、每种防护配置均测试了 949 个注入任务实例。

从结果可以看出，单 Agent CaMeL 已经具备很强的防护效果，将平均攻击成功率从 12.9% 降低到了 0.2%。

不过，作者分析了剩余成功攻击的执行轨迹，发现这些攻击全部涉及边界洗白：不可信数据经过上游 Agent 转发后，进入下游 Agent 的可信指令通道，并改变了下游 Agent 的执行计划。

multi-CaMeL 通过分离指令与数据，消除了测试中观察到的这类成功攻击。

值得注意的是，实验中的 0% 并不意味着系统绝对安全。它只代表在当前测试集和测试条件下，没有观察到成功攻击。作者也没有证明其实现能够抵御所有未知攻击或更强的自适应攻击。

2. 任务能力：安全约束带来了额外成本

安全效果之外，作者还评估了正常任务完成率。

结果显示，CaMeL 类架构的安全约束会影响任务执行能力，而且不同模型之间的差异比较明显。

例如，在 MultiAgentDojo 上：

对于 GPT-5.5，采用 multi-CaMeL 后，正常任务成功率比无 CaMeL 时下降了 20.6 个百分点。而在 GPT-4.1 上，这一下降幅度达到 53.7 个百分点。

不过，不能把这些损失全部归因于 multi-CaMeL 新增的双通道机制。实验显示，相当一部分任务成功率下降，实际上发生在从传统 Agent 切换到单 Agent CaMeL 的过程中。

在另一套 AssetOpsBench 测试中，multi-CaMeL 相较于单 Agent CaMeL 的额外任务成功率损失，五款模型平均只有 3.2 个百分点，两款较强模型平均仅为 0.85 个百分点。

作者认为，模型能力越强，越能够适应提前规划和严格数据隔离的架构约束。不过，这一趋势并非在所有模型和任务上都严格成立。

这也反映出 Agent 安全架构面临的一个现实问题：如何在保证执行过程可控的同时，尽可能保留 Agent 根据环境变化灵活处理任务的能力。

双通道并不意味着解决了所有 Agent 安全问题

虽然 multi-CaMeL 在实验中取得了较好的安全效果，但它的保护范围仍然存在明确边界。

首先，控制流完整性并不等于所有行为都安全。

multi-CaMeL 可以阻止不可信数据让 Agent 生成预先计划之外的新操作，但不一定能够阻止攻击者操纵已有的执行分支。

例如，Agent 已经提前规划好：如果订单状态为已批准，就执行付款；否则停止付款。

攻击者如果能够控制订单状态字段，就可能让 Agent 错误地选择付款分支。

这种攻击不会增加新的工具调用路径，只是影响预先存在的分支选择。作者将其称为 Branch Steering（分支引导），并明确指出它不违反论文所定义的 CFI。

因此，即使使用 multi-CaMeL，系统仍然需要对关键数据的真实性、工具调用的授权条件和重要操作的执行结果进行验证。

其次，当前解释器的数据依赖追踪仍存在局限。

例如，一个变量虽然由代码中的固定字符串赋值，但具体使用哪个字符串可能取决于不可信数据控制的条件分支。如果解释器没有充分追踪这种隐式依赖，就可能错误地认为变量没有受到不可信数据影响。

论文承认，当前 multi-CaMeL 继承了原 CaMeL 解释器在隐式信息流追踪方面的部分限制。这意味着，协议层面的安全保证与实际实现能够完整执行的约束之间，还存在需要解决的问题。

此外，作者的形式化分析主要针对树状层级结构的 Agent-as-Tool 系统。

现实中的多 Agent 系统可能更加复杂，例如多个 Agent 相互调用、共享长期记忆、通过消息队列异步通信，或者同一个 Agent 同时接收多个上游 Agent 的任务。

对于这些更加复杂的拓扑结构，如何保持跨 Agent 的信任边界，仍然需要进一步研究。

最后，论文的主要实验没有配置非平凡的数据流安全策略，因此主要验证的是控制流完整性，而不是完整的敏感数据防泄露能力。

这些限制并不否定 multi-CaMeL 的价值，但提醒我们：它解决的是一个明确的安全问题，而不是提供了一套覆盖所有 Agent 风险的完整防护体系。

从单 Agent 安全走向系统级 Agent 安全

这篇论文对于 Agent 安全产品设计的启发，并不局限于 CaMeL 本身。

目前很多 Agent 安全方案仍然以单个模型或单次工具调用为核心，重点关注用户输入是否包含违规内容、外部数据是否存在提示注入，以及模型输出是否安全。

但在多 Agent 系统中，安全边界已经发生了变化。

一个 Agent 生成的内容，可能成为另一个 Agent 的输入；一个 Agent 经过验证的数据，可能被其他 Agent 再次加工；某个原本只拥有信息查询权限的 Agent，还可能通过调用其他 Agent 间接获得执行操作的能力。

因此，系统需要区分两个问题：一个 Agent 能不能调用另一个 Agent，以及它传递的信息是否有资格成为下游 Agent 的指令。

前者属于 Agent 身份认证与调用授权，后者属于跨 Agent 的指令完整性和数据来源管理。即使完成了前者，也不能自动保证后者。

从工程角度看，multi-CaMeL 至少提供了三个值得借鉴的方向。

第一，Agent 间通信应尽可能采用结构化协议，明确区分任务指令、数据参数以及数据来源，避免将所有信息混合成一段自然语言 Prompt。

第二，数据的信任属性应当能够跨 Agent 保持。外部网页中的内容，不应因为被内部 Agent 总结就自动成为可信指令；敏感数据库中的信息，也不应因为经过多轮转发就失去原有的访问限制。

第三，Agent 安全评测需要从单节点测试扩展到跨节点测试。除了检验一个 Agent 能否识别提示注入，还应该测试恶意数据经过多个 Agent 转发、总结和加工后，是否会发生信任等级提升、控制流偏移或越权操作。

这对于采用多 Agent 编排、Agent-as-Tool、MCP 工具集成等架构的应用尤其重要。当然，multi-CaMeL 的形式化保证并不直接覆盖所有这些架构，其设计思想仍需要结合具体通信方式和权限模型实现。

过去，我们讨论提示注入时，更多关注模型能不能正确识别恶意指令。CaMeL 则尝试通过系统架构减少对模型安全判断能力的依赖。

而这篇论文进一步指出，即使单个 Agent 已经建立了可靠的指令与数据隔离机制，多个 Agent 组合之后仍然可能出现新的信任边界问题。

随着 Agent 系统逐渐走向专业化分工和多智能体协作，安全设计的重点也需要从保护单个模型，扩展到保护整个系统的信息流和执行过程。

真正可靠的多 Agent 安全，不只是确保每个 Agent 都有安全防护，还需要确保数据在 Agent 之间流动时，不会因为跨越了一道接口，就获得原本不属于它的指令权限。