从设计上防御提示注入的 CaMeL 系统

1. 01这篇论文试图解决什么问题？

   作者旨在解决LLM智能体处理非受信数据时的提示注入攻击与私有数据泄露问题。

   LLM智能体在处理不受信外部数据时极易遭受提示注入攻击，导致恶意指令劫持执行流程并泄露私有数据。

   • 场景与重要性：现代大语言模型广泛应用于构建能通过API和界面与外部环境交互的自主智能体。当处理来自不受信来源（如网页、第三方工具返回值或共享文件）的数据时，恶意行为者可注入指令诱导系统执行未授权操作或外发隐私数据（引言、Section 2）。
   • 现有防御的不足：作者指出，基于提示词分隔符（delimiters）、提示三明治（prompt sandwiching）或安全微调的现有防御均属于启发式方案，缺乏确定性安全保证；单纯的双LLM（Dual LLM）隔离虽然限制了控制流规划，但攻击者仍可通过操纵数据流（如替换工具调用参数）导致恶意操作（Section 2、Section 3）。
   • 核心观察与假设：智能体动作同时包含控制流与数据流。作者认为必须在控制流和数据流两个维度进行安全约束，通过将元数据（能力，capabilities）绑定至数据值并维护依赖图，可在系统层实现细粒度的信息流安全策略检查（Section 2、Section 5）。
   • 论文提出的方案：作者提出了CaMeL（CApabilities for MachinE Learning）防御框架，由特权LLM提取控制流并生成Python代码，受隔离的检疫LLM仅解析非受信数据，自定义解释器维护数据流图并基于能力执行安全策略，无需修改底层模型即可提供安全保证（Section 1、Section 5）。
   • 威胁模型：
     • 攻击者目标：在PI-SEC安全博弈中，攻击者旨在构造恶意状态，使智能体执行非允许动作集合（Omega_prompt）之外的不安全动作，如数据外传或恶意状态变更（Section 3、Section 4）。
     • 攻击者知识与能力：攻击者能向智能体可访问的外部数据源（如邮件、文档、表格）注入恶意内容（prompt injection），但无法直接修改用户的初始输入（Section 3）。
     • 受害系统：基于LLM构建的具备工具调用能力的智能体系统，拥有对外部API及持久状态的读写权限（Section 3、Section 4）。
     • 明确非目标（Non-goals）：作者声明不防御不影响控制流与数据流的纯文本攻击（如诱导虚假总结）及纯文本钓鱼攻击；假设用户prompt和记忆（memory）未被攻破（Section 3.1）。

   收起这一问

2. 02有哪些相关研究？

   作者系统梳理了启发式提示防御、双LLM隔离架构与传统信息流安全理论，并对比了现有基线。

   论文围绕提示注入防御、隔离架构及信息流安全展开讨论，相关研究主要分为三类：

   • 启发式与模型层提示注入防御：
     • Hines et al. (2024) 提出 Spotlighting，使用特殊字符标记非受信上下文边界并指示模型忽略其中的指令；Learn Prompting (2024) 提出 Prompt Sandwiching，在每次工具输出后重复展示原始任务。作者称这些方法均为启发式，缺乏安全保证。
     • Wallace et al. (2024) 与 Wu et al. (2024) 通过指令层级（Instruction Hierarchy）微调模型忽略非受信指令；Chen et al. (2024)（StruQ）训练模型遵循结构化查询。作者称这些方法仍为概率性方案，在基准测试中仍会被突破。
     • Abdelnabi et al. (2024) 监测内部激活向量以捕获任务漂移；Sharma et al. (2024)（SPML）使用形式化语言定义任务；Zverev et al. (2025)（ASIDE）在架构层使用不同输入嵌入分离指令与数据；ProtectAI (2024) 与 Debenedetti et al. (2024a) 提出通过分类器或金丝雀（canaries）检测注入与外发。
   • 隔离架构与系统级防御：
     • Willison (2023) 提出 Dual LLM 模式，使用特权 LLM 处理受信 prompt 并规划工具调用，检疫 LLM 处理非受信数据且无工具调用权限。作者指出其局限在于无法防御数据流篡改（参数操纵）。
     • Wu et al. (2025)（IsolateGPT）通过隔离防御不受信工具，但对所有工具输出的跨工具访问均需用户显式批准，作者指出其易导致用户疲劳。
     • Wu, Cecchetti, and Xiao (2024) 基于信息流控制（IFC）追踪工具输出的可信部分以决定是否喂给模型。
   • 传统软件安全概念与近期并发工作：
     • 经典概念借鉴：控制流完整性（CFI, Abadi et al., 2009）、访问控制（Anderson, 2010）、信息流控制（IFC, Denning, 1976; Denning and Denning, 1977; Myers and Liskov, 1997）以及硬件/系统能力机制（Needham and Walker, 1977; Watson et al., 2010; Woodruff et al., 2014; Watson et al., 2015）。
     • 并发工作：Zhong et al. (2025)（RTBAS）利用粗粒度标签和分类器推断文本依赖关系，作者指出其策略表达能力不及 CaMeL；Abdelnabi et al. (2025) 基于合成数据为智能体间通信定义策略；Kim, Choi, and Lee (2025)、Li et al. (2025)（ACE）及 Costa et al. (2025) 提出了与 CaMeL 类似蓝图的双模型与工具调用策略检查机制。
   • 对比基线与基准：
     • 评测基准：AgentDojo 基准（Debenedetti et al., 2024b），包含 Workspace、Banking、Slack、Travel 4 个套件，共 949 个攻击测试。
     • 对比基线：原生工具调用（Native Tool Calling API / Undefended model）、Tool Filter（Debenedetti et al., 2024b）、Spotlighting（Hines et al., 2024）、Prompt Sandwiching（Learn Prompting, 2024）。

   作者将 CaMeL 定位为基于软件安全原理的系统层防御，不依赖模型行为修改或概率性启发式规则，而是通过隔离控制流、精确追踪数据流图并强制执行细粒度能力策略，提供确定性的安全保证。

   收起这一问

3. 03论文如何解决这个问题？

   CaMeL通过特权规划模型与检疫解析模型实现隔离，由解释器追踪数据依赖并执行细粒度能力策略。

   CaMeL 借鉴传统软件安全中的控制流完整性（CFI）、访问控制和信息流控制（IFC）思想，构建包裹在LLM外层的系统防护层。

   安全博弈形式化与整体架构

   • PI-SEC 安全博弈：论文将威胁模型形式化为博弈，攻击者提供初始恶意状态 mem*，智能体执行用户 prompt 并产生工具调用轨迹 Trace，验证器检查轨迹中的每个三元组是否均在允许集合内：

   Verify(Trace, \Omega) = \bigwedge_{(tool, args, mem_{step}) \in Trace} ((tool, args, mem_{step}) \in \Omega) 该公式表示验证智能体在执行轨迹中的每一次工具调用及其参数与内存状态是否均属于允许动作集合 Ω（Section 4、Figure 3）。

   • 系统核心组件：系统包含特权LLM（P-LLM）、检疫LLM（Q-LLM）、外部工具集、安全策略、能力（capabilities）以及 CaMeL 自定义解释器（Section 5、Figure 5）。

   双模型隔离与结构化数据处理

   • 特权LLM（P-LLM）：负责将用户自然语言需求转换为表达执行计划的 Python 代码。P-LLM 仅接收受信的用户 prompt 和工具函数签名，绝对不接触外部工具返回的数据或 Q-LLM 的输出内容（Section 5.1）。
   • 检疫LLM（Q-LLM）：无任何工具调用权限，作为函数（query_ai_assistant）供 P-LLM 生成的代码调用，专门利用大模型内置的结构化输出能力将非受信的非结构化数据解析为 Pydantic BaseModel 实例（Section 5.1）。
   • 信息充足性反馈：系统在 Q-LLM 的输出模式中注入布尔字段 have_enough_information。当信息不足时返回 false，解释器抛出 NotEnoughInformationError，由 P-LLM 重新生成修复代码，但 Q-LLM 严禁告知 P-LLM 具体缺失什么信息以防注入（Section 5.1）。

   自定义解释器与数据流依赖追踪

   • 受限 Python 方言：基于 Python 内置 ast 库实现递归解释执行。严格禁止 while 循环、生成器、模块导入、eval/exec、break/continue、函数与 lambda 定义，以及具有就地修改副作用的方法（如 list.append），强制采用推导式等函数式写法（Section 5.4、Appendix H.1）。
   • 动态依赖图维护：解释器追踪每个变量的数据依赖关系（如 c = a + b 则 c 递归依赖 a 和 b）。系统提供 NORMAL 与 STRICT 两种解释模式：STRICT 模式下，控制流分支（if/for）内部赋值的所有变量均依赖分支条件或迭代对象，且 Q-LLM 调用之后执行的所有语句均依赖该调用的输入参数（Section 5.4、Section 7、Figure 7）。

   基于能力的安全策略执行与异常控制

   • 能力元数据（Capabilities）：每个数据值均绑定元数据标签，记录数据来源（User、CaMeL变换、具体Tool及内部来源如邮件发送者）与允许读取者集合（Public或用户邮箱列表）（Section 5.3）。
   • Python 编写的安全策略：安全策略直接用 Python 函数定义（非定制DSL），在工具执行前递归检查实参及其依赖图是否合规（如向外部发信前验证收件人是否在允许读取者集合内），合规返回 Allowed()，违规返回 Denied() 并中止执行（Section 5.2、Figure 6）。
   • 安全错误处理：解释器允许 P-LLM 重试最多 10 次以修复异常。若异常依赖于非受信数据，错误详情会被自动脱敏（redacted），防止报错内容成为提示注入通道；先前半途执行产生的副作用不可回滚（Section 5.4、Appendix H.2）。

   收起这一问

4. 04论文做了哪些实验？

   在AgentDojo评测中，CaMeL在多个模型上消除注入攻击，除Travel外多数套件效用保留较好。

   实验设置

   • 被测模型：Gemini 2.5 Flash（gemini-2.5-flash-preview-05-20）、Gemini 2.5 Pro（gemini-2.5-pro-preview-05-06）、Claude 3.5 Haiku（claude-3-5-haiku-20241022）、Claude 4 Sonnet（claude-sonnet-4-20241022 无推理）、Claude 4 Sonnet*（带 16,000 reasoning tokens 预算）、GPT-4.1（gpt-4.1-2025-04-14）、o4-mini（o4-mini-2025-04-16 高推理努力）、o3（o3-2025-04-16 高推理努力）、Claude 3.5 Sonnet、GPT-4o Mini、GPT 4.1 Nano（Section 6.1、Section 6.3）。
   • 数据集与基准：AgentDojo 基准，涵盖 Workspace（40个任务）、Banking（16个任务）、Slack（20个任务）、Travel（20个任务）4个套件，包含 949 次攻击测试（Figure 9、Table 1）。
   • 对比基线：Native Tool Calling API（各模型官方原生工具调用/未防御模型）、Tool Filter、Spotlighting、Prompt Sandwiching（Section 6.1、Section 6.3）。
   • 主要指标：良性任务效用（Utility，任务成功率）、受攻击下效用（Utility under attack）、成功攻击数（Number of successful attacks，满分949次）、策略触发率（Policy Triggering Rate）、输入/输出 Token 增幅倍数（Section 6.1、Section 6.2、Section 6.5）。
   • 评审与判定方式：采用 AgentDojo 环境自动化判定（非LLM评审），基于环境状态与目标断言检查任务是否达成或攻击是否生效（Section 6.2.1、Appendix H.4）。
   • 样本量与统计：全量测试 949 次攻击，表格报告均值与标准差，论文未报告重复运行随机种子数（Table 2、Table 4）。

   主结果

   下表展示了主要被测模型在 AgentDojo 上的原生工具调用与 CaMeL 的防御表现对比（据 Table 4、Table 2）：

   表格较宽，可左右滑动

   模型	原生API成功攻击数	CaMeL(无策略)成功攻击数	CaMeL成功攻击数	原生API整体效用	CaMeL整体效用
   Claude 4 Sonnet	75 ± 58.6	13 ± 6.0	11 ± 4.5	86.6% ± 6.8	74.2% ± 8.7
   Claude 4 Sonnet*	75 ± 58.6	10 ± 3.8	11 ± 4.5	83.5% ± 7.4	70.1% ± 9.1
   Gemini 2.5 Flash	297 ± 268.7	1 ± 0.0	1 ± 0.0	55.7% ± 9.9	35.1% ± 9.5
   Gemini 2.5 Pro	163 ± 140.1	0 ± 0.0	0 ± 0.0	73.2% ± 8.8	41.2% ± 9.8
   o3 High	11 ± 4.5	1 ± 0.0	0 ± 0.0	84.5% ± 7.2	77.3% ± 8.3
   o4 Mini High	2 ± 0.0	1 ± 0.0	1 ± 0.0	79.4% ± 8.1	76.3% ± 8.5

   • 攻击防御效果：作者称即使不启用安全策略（仅靠模型隔离），成功攻击数也大幅减少；在启用完整策略后，Gemini 2.5 Pro 和 o3 High 的成功攻击数完全降为 0（Table 4）。
   • 残存成功攻击归因：作者指出残存的极少数被 AgentDojo 判定为成功的攻击（如 Claude 4 Sonnet 的 11 次，全部集中于 Travel 套件）并非由于控制流或数据流被劫持，而是模型调用 print 输出包含攻击词的评论文本，触碰了基准评测规则，属于纯文本范畴而非提示注入漏洞（Section 6.2.1、Section 6.2.2）。
   • 良性效用表现：作者指出先进模型使用 CaMeL 时效用损失较小（如 o3 High 从 84.5% 降为 77.3%，o4 Mini High 从 79.4% 降为 76.3%）；但在 Gemini 模型上出现明显效用下降，主要由 Travel 套件 API 输出格式未充分说明导致（Table 2）。

   与现有防御基线对比（Claude 3.5 Sonnet）

   • 评测内容：在 Claude 3.5 Sonnet 上对比 CaMeL、无策略 CaMeL、Spotlighting、Tool Filter、Prompt Sandwiching 及未防御模型在 949 次攻击下的安全与效用（Section 6.3，Table 5、Table 7）。
   • 实验结果：未防御模型成功攻击数为 44 ± 31.3，Prompt Sandwiching 为 24 ± 14.5，Tool Filter 为 8 ± 2.5，Spotlighting 为 5 ± 0.6，CaMeL 为 0 ± 0.0（Table 7）；效用方面，未防御模型为 90.72% ± 5.77，Spotlighting 为 92.78% ± 5.15，Prompt Sandwiching 为 89.69% ± 6.05，Tool Filter 为 73.20% ± 8.81，CaMeL 为 63.92% ± 9.56（Table 5）。在 GPT-4o Mini 上，原生工具调用遭受 276 次成功攻击，而 CaMeL 降至 0 次（Section 6.3）。
   • 作者解读：作者称 CaMeL 显著优于所有对比防御，提供可验证的安全保证，而其他启发式防御在自适应攻击下易发生鲁棒性崩溃。

   失败模式与效用影响分析

   • 评测内容：系统分类了 Claude 3.5 Sonnet 在 4 个套件共 96 个任务中的失败归因（Section 6.1.2，Table 1、Table 14）。
   • 实验结果：共记录 8 类失败模式（Table 1），其中“API未充分说明”占 13 次（全在 Travel 套件）；“数据要求动作（Data requires action）”占 5 次；“Q-LLM上下文不足”占 5 次；“Q-LLM过度处理/严格评估”占 3 次；“P-LLM错误假设”占 3 次；“AgentDojo评估Bug”占 3 次；“查询误解”占 1 次；“任务模棱两可”占 1 次。
   • 作者解读：作者指出“数据要求动作”是双 LLM 隔离无法通过单次前向规划解决的固有局限；而更新的模型通过 Q-LLM 解析未知结构使 Claude 系列在 Travel 套件的效用从 3.5 的 25% 提升至 3.7 的 55%、4 的 75%（Section 6.1.2）。

   运行开销与廉价模型替代实验

   • 评测内容：测量 CaMeL 带来的 Token 开销，以及使用轻量模型充当 Q-LLM 对系统效用和成本的影响（Section 6.1.3、Section 6.5，Figure 13，Table 10）。
   • 实验结果：以 Claude 3.5 Sonnet 测算，在受攻击任务中 CaMeL 中位数消耗 2.82× 输入 Token 和 2.73× 输出 Token（Figure 13，Table 10）；使用 Claude 3.5 Haiku 充当 Q-LLM 配合 Claude 4 Sonnet 担任 P-LLM 时，系统效用仅降低约 1%，中位数成本预计节省 12%（Section 6.1.3）。
   • 作者解读：作者认为 Q-LLM 承担的解析任务复杂度低，使用轻量模型甚至本地模型不仅经济高效，还能避免第三方服务商读取工具输出，提升隐私性。

   其他消融与分析

   • NORMAL vs STRICT 模式策略触发率：未受攻击时整体触发率 NORMAL 为 33.87%、STRICT 为 53.23%（据 Table 8）；受攻击时整体触发率 NORMAL 为 26.54%、STRICT 为 45.34%（据 Table 9）。
   • 受攻击下的整体效用（Claude 3.5 Sonnet）：CaMeL 为 66.70% ± 3.00，原生模型为 86.83% ± 2.15，Spotlighting 为 89.36% ± 1.96（据 Table 6）。
   • Claude 4 Sonnet 受攻击下分套件效用：CaMeL 在 Banking 为 68.8% ± 7.6，Slack 为 68.6% ± 8.9，Travel 为 75.0% ± 7.2，Workspace 为 78.9% ± 3.4（据 Table 3）。
   • 策略触发率套件分布（Claude 4 Sonnet*）：良性任务下 Workspace 为 0.42，Banking 为 0.58，Slack 为 0.94，Travel 为 0.30（据 Figure 10a）。
   • 基线防御 Token 中位数增幅（未受攻击）：Spotlighting 输入 1.08×、输出 0.99×；Tool Filter 输入 7.77×、输出 1.05×；Prompt Sandwiching 输入 1.14×、输出 1.16×（据 Table 10）。

   收起这一问

5. 05有什么可以进一步探索的点？

   作者指出了生态适配成本高、策略维护与用户疲劳、侧信道泄露风险及语言复杂性等局限与后续方向。

   作者指出的局限与后续方向

   • 实施与生态适配成本高：构建基于能力的系统需要显著的开发与重构成本，且要求环境中的所有外部工具与第三方服务均支持能力机制，否则会导致效用下降（Section 9.1）。
   • 安全策略维护负担与用户疲劳：系统要求编写、编码并维护细粒度的安全策略；当策略过于严苛或模棱两可时，频繁向用户请求确认（降级/去分类过程）易导致警报疲劳，使用户无意识批准恶意操作（Section 9.2、Section 9.3）。
   • 侧信道信息泄露风险：系统仍存在利用间接依赖推断（如依据私有变量循环拉取外部资源）以及通过诱导异常导致执行中断来泄露私有变量单比特信息的侧信道风险（Section 7、Section 9.3）。
   • 小型控制流拼接规避可能：类似于传统控制流完整性被返回导向编程（ROP）绕过，攻击者可能通过构造一系列符合策略的小型合法操作并在数据流中传导，从而拼凑出恶意控制流（Section 6.4、Section 9.3）。
   • Python宿主语言复杂性：Python语言动态特性复杂且异常机制易引入侧信道，作者提出未来可探索更显式处理错误和I/O的函数式语言（如Haskell）作为解释器目标语言，以降低安全策略冲突解决难度（Section 10）。
   • 形式化验证与策略自动化生成：作者指出当前实现主要提供经验证据，未来需对解释器和安全属性开展形式化验证以证明其无漏洞；并探索结合 AirGap 或 DSL 自动生成上下文相关的安全策略（Section 10）。

   实验覆盖范围

   • 被测模型范围：实验覆盖了 Gemini 2.5 Flash/Pro、Claude 4 Sonnet（含推理版）、o3 High、o4 Mini High、Claude 3.5 Sonnet、Claude 3.5 Haiku、GPT-4o Mini、GPT 4.1 Nano 共 10 个模型（Section 6.1、Section 6.3）。
   • 测试环境与攻击规模：实验基于 AgentDojo 基准，涵盖 Workspace、Banking、Slack、Travel 4 个场景套件，攻击样本总量为 949 次（Section 6.1、Section 6.2）。
   • 对比防御基线：基线评测覆盖了原生工具调用、Spotlighting、Tool Filter 和 Prompt Sandwiching 共 4 种方案（Section 6.3）。
   • 消融条件设置：消融实验覆盖了无安全策略的 CaMeL、解释器的 NORMAL 模式与 STRICT 模式对比（Section 6.2.1、Section 6.2.2、Appendix D）。
   • 未报告信息：论文未报告各项任务的具体独立随机重复次数与随机种子设定，亦未报告各模型调用外部API时的具体网络时延数据（Section 6.1、Section 6.5）。

   收起这一问

6. 06总结一下论文的主要内容

   论文提出基于能力和隔离的CaMeL防御框架，以确定性系统设计消除AgentDojo提示注入风险。

   论文提出了一种基于传统软件安全思想的智能体防御系统 CaMeL，旨在通过架构级设计而非模型微调来解决大语言模型面对的提示注入与数据外泄问题。

   • 核心定位与挑战：智能体在处理不受信网页、文档或邮件等外部输入时，恶意注入指令可能篡改参数或劫持行为。作者指出，主流的提示工程与微调方案均属启发式防护，无法提供确定性的安全保证；单纯隔离规划模型也无法阻止攻击者通过污染数据流操纵工具实参。
   • CaMeL 防御机制：系统将任务拆解为双模型架构。特权模型仅接触受信的用户初始指令，生成表征控制流的受限 Python 程序；检疫模型不具备工具调用权限，仅用于将非受信文本解析为符合 Pydantic 规范的结构化数据。自定义解释器在运行时跟踪数据依赖图并维护能力标签，在调用工具前由安全策略检查数据来源与接收者权限，违规操作将被直接阻断。
   • 主要实验结果：
     1. 在 AgentDojo 的 949 次攻击评测中，CaMeL 使 Gemini 2.5 Pro 和 o3 High 的成功攻击数从原生调用的 163 次和 11 次降至 0 次（Table 4）。
     2. 在 Claude 3.5 Sonnet 上，CaMeL 实现了 0 次成功攻击，优于基线 Tool Filter 的 8 次和 Spotlighting 的 5 次（Table 7）。
     3. 在良性任务中，o3 High 搭配 CaMeL 达到 77.3% 的整体效用，o4 Mini High 达到 76.3%，与原生调用的 84.5% 和 79.4% 相比保持了较高可用性（Table 2）。
     4. 采用廉价的 Claude 3.5 Haiku 充当检疫模型时，Claude 4 Sonnet 系统的整体效用仅下降约 1%，中位数成本预计降低 12%（Section 6.1.3）。
   • 局限与安全启示：作者指出，当智能体需依据未读数据动态决定下一步动作时（“数据要求动作”），纯前向规划存在固有局限；同时系统仍面临异常处理与依赖推断等侧信道泄露风险，且安全策略的手动配置存在用户疲劳隐患。作者认为，构建围绕不可信模型的系统级安全防护是增强智能体鲁棒性的切实路径。

   收起这一问

相关论文