Skip to content
ToLO Knowledge Base

AgentDojo 动态评估 LLM agent 攻防

一句话

据论文,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 的工具/执行边界。

核心贡献

  • 提出 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(弱形式)

实验与结论要点

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

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

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

局限与开放问题

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

对本站的启发

支持把 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 / 多种 / 动态评测 / 工具+执行边界

读完检查

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

外部链接

内部互链