Skip to content
ToLO Knowledge Base

CaMeL 通过设计抵御提示注入

一句话

据论文,CaMeL 在 LLM 周围加一层系统化保护层,把”可信查询的控制流”与”数据流”显式抽出,再用能力(capability)策略约束工具调用,使被污染的检索数据无法影响程序执行。

为什么读这篇

CaMeL 是 C_SAFE^capability 的代表性实现,正面回应本站第 3 章 §防御模式提到的”主流框架几乎缺失能力门控”这一缺口。

读这篇之前,“capability gate” 听起来抽象;读完之后,你会看到它长什么样、怎么部署、什么时候能 token 也不依赖:即使 LLM 完全被 prompt injection 攻破,控制流还在可信侧。

CaMeL 也是 AgentDojo 同作者的后续防御工作,直接在 AgentDojo 上做对照评估。

核心贡献

  • 提出 CaMeL:与底层模型解耦的”by design”防御层
  • 把控制流与数据流从 trusted query 中显式抽取
  • 引入 capability 标签限制工具调用与数据出口

它解决的问题

主流 prompt injection 防御都是 defense-in-depth 的某一层(模型对齐 / 输入分隔 / 检测器),都依赖 LLM 自己做正确决策。这意味着:

  • 一旦 prompt injection 成功(成功率 > 0 总会发生),所有依赖 LLM 决策的防御都失效
  • 没有”确定性”安全保证

CaMeL 的诉求:让安全性不依赖 LLM 是否被注入。即使 LLM 完全被攻击者控制,程序行为仍然受可信策略约束。这就是 “by design” 的含义:确定性安全(provable security)。

与 ToLO 的关联

CaMeL 是 ToLO C_SAFE^capability 的代表性实现:在工具边界与执行边界处对 LLM 决定的动作做能力门控。

论文同时改造解析边界 —— untrusted 数据被强制视为不可控的值,不能成为控制流决策依据。

覆盖 source 子集覆盖 sink
S_LLM^direct任意七子类 sink
S_LLM^framework都受益于 capability 兜底
S_LLM^parsed
S_LLM^rag
(不直接控制 S_LLM^structured)

CaMeL 不替代 schema 与 allowlist,而是对它们之外的剩余路径设防。

方法摘要

据论文,CaMeL 采用 dual-LLM 思路:

Privileged Planner

  • 只读 trusted user query(不读外部 / RAG / tool 返回)
  • 把任务编译成显式的控制流(包含工具调用计划 + 数据依赖)
  • 这条控制流就是”程序”

Quarantined LLM

  • 处理可能被污染的工具返回与检索数据
  • 输出只能作为 untrusted value 流动
  • 不能改变程序结构

Capability 标签

每个数据值都带 capability 标签:

value: "some content"
   ├── source: where it came from (trusted_user / external_web / RAG / tool_X)
   ├── visibility: who can see it (private / public)
   └── reachable_sinks: where it can be written to

运行时在调用工具前对照安全策略检查;不满足策略的调用被拒绝。

该层独立于具体模型,可叠加在任意 LLM 之上。

简化伪代码示意

# Privileged planner 只看 user_query
plan = privileged_llm(trusted_user_query)
# plan = [fetch_url(url), summarize(content), save_to_file(path, summary)]


# 执行 plan 中每一步
for action in plan:
    # Quarantined LLM 处理上一步的 untrusted 结果
    if action == "summarize":
        summary = quarantined_llm(prev_output)   # ← 受污染
        # summary 带 capability 标签:source=external_web, visibility=public
    if action == "save_to_file":
        # 检查 capability
        if summary.capabilities.has_sink(path) is False:
            raise PolicyViolation("untrusted content cannot reach this path")
        write(path, summary.value)

实验与结论要点

据论文,作者在 AgentDojo 基准上评估:

  • CaMeL 在保留可证明安全性(provable security)的前提下解决约 77% 的任务
  • 相对未设防系统 84% 的解决率仅有有限的实用性损失

评估覆盖多种模型与攻击向量,结果支持 “capability-based 设计可在不牺牲过多功能的情况下阻断 prompt injection 引发的危险动作”。

代码已在 GitHub 公开。

局限与开放问题

  • 任务解决率较未设防版本下降约 7 个百分点,部分合法任务被策略拒绝。
  • 安全策略需要针对具体应用与工具集编写,自动生成与维护成本未在论文中量化。
  • AgentDojo 之外的真实多 agent / 长链路场景下的可扩展性未充分验证。
  • Privileged planner 自身仍是 LLM,虽然只读 trusted query,但如果 user query 本身被诱导(C1)仍可能 plan 错误 —— 不过相比直接污染 quarantined LLM,攻击面已大幅缩小。

对本站的启发

强支持本站把 C_SAFE^capability 列为独立 sanitizer 子类,并保持”sink 端不发明、把 novelty 压在 source 端”的设计原则 —— CaMeL 在不改变 sink 集合的前提下,给七子类共用的工具/执行边界提供统一防御。

无需扩展 taxonomy。

同时印证 Defensive Patterns 结论:ToLO-Exec、ToLO-Shell 等子类的修复必须落到能力与隔离层,单纯 input validation 不够。

对静态分析的具体启示

在静态分析中,CaMeL 风格的 capability check 应被识别为有效 sanitizer 节点,与 schema、allowlist、parameterized 等同等对待。CodeQL 规则可加:

predicate isCapabilityCheck(DataFlow::Node n) {
  exists(Call c |
    c.getFunc().(Attribute).getName() in ["check_capability", "has_capability", "verify_capability"] and
    n.asExpr() = c.getAnArg())
}

CaMeL 的开源实现(google-research/camel-prompt-injection)是这类检查最完整的参考。

ToLO 一行标注

- / 五子集 / 七子类 / C_SAFE^capability / 工具+执行边界

读完检查

  • CaMeL 和 IsolateGPT 都属于 C_SAFE^capability。它们的差别在哪里?
    • IsolateGPT 主要靠 process isolation + hub-and-spoke 架构;CaMeL 主要靠 dual-LLM + 静态控制流 + capability 标签。前者偏运行时隔离,后者偏静态策略推导。
  • CaMeL 解决 C5 模型供应链污染吗?
    • 部分。如果 privileged planner 也来自被污染模型,它写出的 plan 可能就有问题。但 quarantined LLM 即使完全被攻破,只能产生数据,不能改 plan,所以 C5 影响被显著缩小。

外部链接

内部互链