Skip to content
ToLO Knowledge Base

AgentDojo 动态评估 LLM agent 攻防

一句话

核验状态:pending。 本页按论文自述做阅读笔记;venue、任务数量、测试用例数量和实验结论仍需回到官方来源核验。正文中的数字均应读作”据论文报告”。

据论文,AgentDojo 是一个可扩展的动态评测环境,用 97 个真实任务与 629 个安全测试用例,衡量工具调用 agent 在 indirect prompt injection 下的功能与安全表现。

为什么读这篇

ToLO 防御的难点之一是 “评估是否有效”。静态 benchmark(固定攻击集 + 固定模型 + 固定测试)很快被新攻击绕过。AgentDojo 给出动态环境 —— 应用 / 工具集 / 攻击 / 防御四件独立替换,可以长期作为攻防迭代平台。

本站收录它的原因:

  • 它提供 source 端覆盖率验证:你的 ToLOScanner 规则能否覆盖 AgentDojo 涉及的 tool_calls / AgentAction.tool_input 字段?
  • 它给出 C_SAFE^{allowlist} + C_SAFE^{capability} 的可执行参考(tool filter / capability config)。
  • 它实证:单纯 prompt-level 防御不足以闭合 ToLO 的工具/执行边界。

先对齐术语

  • Dynamic environment(动态评测环境):不是固定问答集,而是可运行的 agent 场景,包含工具、状态、任务与注入位置。
  • Utility:没有攻击时 agent 完成正常任务的能力。
  • ASR(Attack Success Rate):攻击任务达成比例;在 AgentDojo 中通常表现为 agent 调用了攻击者希望的工具或参数。
  • C_SAFE^{allowlist}:只允许固定工具、固定目标或固定参数集合通过。
  • C_SAFE^{capability}:高敏感工具调用必须有当前会话授权,常见弱形式是 user reconfirmation。

核心贡献

  • 提出 agent 安全评测的动态环境,而非固定 benchmark。
  • 设计 4 个套件、97 任务、629 安全测试,覆盖多通道污染。
  • 集成多种攻击与防御范式,支持自适应攻防迭代。

它解决的问题

agent 安全评估有几个痛点:

  1. 静态 benchmark 容易”训练去”:模型供应商把 benchmark 攻击 fine-tune 进 training data,得分虚高。
  2. 真实多步任务难还原:多数 benchmark 只测”单次输出是否含坏内容”,不测多步交互。
  3. 工具调用泛化场景缺失:大部分 prompt injection 评测不带工具,因此不能评 ToLO 风险。

AgentDojo 给出动态环境,让评估可以长期演进:研究者可以加新攻击 / 新防御 / 新套件,benchmark 不会过期。

方法摘要

据论文,AgentDojo 把 agent 部署在四个套件:

套件工具集主题例子
workspace邮件 / 日历 / 云盘整理收件箱、安排会议
slack团队聊天跨频道协作、文件分享
travel旅行计划订机票、查酒店
banking个人金融查余额、转账

每个套件提供:

  • 工具集合(可调用 API)
  • 初始数据库(邮件 / 联系人 / 账单 / 等)
  • 若干用户任务(user task,主用例)

安全测试在用户任务运行时把注入任务(injection task)藏进环境数据,要求 agent 偏离原任务去执行注入指定的危险动作。

解耦三件事

框架把三件事拆开,可以独立替换或扩展:

环境定义 (套件 + 任务 + 注入位置)
   ⊥
攻击范式 (direct PI / indirect PI / GCG / payload 模板)
   ⊥
防御范式 (system prompt 强化 / tool filtering / 再确认 / capability gate)

关键评测指标

  • utility:不带攻击时的任务完成率
  • targeted attack success rate(ASR):注入任务被达成的比例
  • benign task completion under attack:攻击存在时仍完成原任务的比例

代码与数据公开:https://github.com/ethz-spylab/agentdojo

与 ToLO 的关联

AgentDojo 的威胁模型直接对应 ToLO 攻击者通道:

  • C2 indirect PI(注入指令藏在邮件、文档、工单、网页等被工具返回的数据里)
  • C4 tool 响应控制(部分套件 simulate 工具返回值被劫持)

Source 子集主要是:

  • S_LLM^{framework}(AgentAction.tool_input)
  • S_LLM^{parsed}(tool_call.arguments 经 json.loads 后)
  • 部分套件涉及 S_LLM^{rag}

Sink 端在 AgentDojo 里被抽象

AgentDojo 的 sink 被抽象为”工具调用”:工具背后没有真正反序列化 / SQL / shell 执行,而是 simulate 状态变更。但七子类(Deser/Exec/Shell/SQL/Path/SSRF/Template)若被部署到这些工具背后,都可被这一环境驱动评估。

Sanitizer 上的对应

论文既评估 prompt 级防御(如 spotlight、tool filter),也评估系统级防御(白名单、capability)。这可对照本站:

AgentDojo 防御对应 C_SAFE
Tool filtering(限制可用 tool 集合)C_SAFE^{allowlist}
Capability check(每次工具调用前检查 user authorization)C_SAFE^{capability}
Spotlight(强调”用户原始任务”)(prompt 级,不属本站 sanitizer)
Re-confirmation(高敏感动作 user 点确认)C_SAFE^{capability}(弱形式)

为什么这对 ToLO 重要

AgentDojo 的价值不是发现某个 ToLO-* sink,而是提供一套可运行的 agent 安全语境。ToLOScanner 是静态分析工具,容易只看到 source/sink 路径;AgentDojo 则能帮助检验这些路径是否出现在真实 agent 工作流中,例如工具返回值如何进入下一轮 tool_calls,以及防御是否牺牲 utility。

它也提醒本站不要把”agent 调了错误工具”直接写成 ToLO。只有当错误工具调用进一步触达反序列化、代码执行、shell、SQL、路径、SSRF 或模板 sink,并且缺少匹配 C_SAFE,才进入 ToLO 七子类。

实验与结论要点

据论文,作者评估了多个前沿模型(含 GPT-4o、Claude 3.5 Sonnet、Gemini、LLaMA 等)。两类发现:

  1. 无攻击时模型的任务完成率仍偏低:复杂多步任务对当前 LLM 仍困难。
  2. 现有 prompt injection 攻击能在相当比例的安全测试上让 agent 执行注入动作,但并未在所有套件、所有任务上都成立 —— 存在仍受保护的安全属性。

论文未给出 “防御一劳永逸” 的方案,而是把环境作为后续攻防研究的迭代平台。

局限与开放问题

  • 套件以”应用 + 工具集”模拟真实场景,工具背后没有实际的反序列化/SQL/shell 执行,因此并不直接生成 ToLO 七子类的端到端 PoC。
  • 评测以”agent 是否调用了攻击者期望的工具/参数”为成功判据,与”工具被调用后下游 sink 是否真的造成损害”之间仍存在间隙。
  • 攻击与防御范式集合是论文发布时的快照,长期需要社区贡献保持与新攻击同步。
  • 它不提供静态 source spec;ToLOScanner 仍需单独建模 LangChain、LlamaIndex 等框架里的 AIMessage、AgentAction、tool argument 字段。

对本站的启发

支持把 prompt injection 与 ToLO 视作两层但相邻的问题:

  • AgentDojo 衡量”LLM 是否被诱导发出危险动作”
  • 本站 taxonomy 衡量”危险动作是否落到具体 sink”

对静态分析的具体启发

可借 AgentDojo 套件作为动态对照集,验证 ToLOScanner 在 LangChain / LlamaIndex 风格的 tool_calls、AgentAction.tool_input 字段上的 source 标注是否完备。

Sanitizer 视角

AgentDojo 的 “tool filter” 与 “capability” 配置可作为 C_SAFE^{allowlist} 与 C_SAFE^{capability} 的可执行参考实现,同时印证:单纯 prompt-level 防御不足以闭合 ToLO 的工具/执行边界。

无需扩展 taxonomy。

ToLO 一行标注

C2 + C4 / S_LLM^{framework} + S_LLM^{parsed} / 多种 / 动态评测 / 工具+执行边界

阅读顺序

建议在通道与防御论文之后读本文。先理解 Greshake / PoisonedRAG / ToolHijacker 的攻击入口,再理解 CaMeL / IsolateGPT 的 capability 思路,最后用 AgentDojo 看这些机制如何在动态 agent 场景中评测。

读完检查

  • AgentDojo 是 ToLO 检测方法吗?
    • 不是。它是 agent 安全评测环境,而不是 ToLO 检测工具。但可以与 ToLOScanner 配合:用 AgentDojo 跑 agent → 拿 trace → 让 ToLOScanner 验证 trace 中的 tool 调用是否触达 sink。
  • 它不能证明什么?
    • 不能证明在 AgentDojo 上有效的防御在生产 agent 上也有效(套件抽象掉了 sink 的具体语义)。

外部链接

内部互链