AgentSafetyBench: Evaluating the Safety of LLM Agents (2024)
论文重点
随着大语言模型（LLM）被越来越多地部署为智能体（Agent），它们与外部环境的交互和工具使用带来了超越模型本身的全新安全挑战。Agent-SafetyBench是一个专门为评估LLM智能体安全性而设计的综合性基准，包含349个交互环境和2,000个测试用例，涵盖8类安全风险和10种常见失败模式。对16个主流LLM智能体的评估结果显示，所有智能体的安全得分均未超过60%，揭示了当前LLM智能体面临严峻的安全挑战。
核心研究内容
问题定义
传统LLM安全评估主要关注内容安全 （Content Safety）------即模型是否生成不安全的文本输出，如泄露隐私或生成有害内容。然而，当LLM以智能体形态部署并与外部环境交互时，出现了全新的行为安全（Behavioral Safety）问题。例如，智能体可能在公共论坛中无意泄露敏感信息，或错误修改订单数量导致意外后果。这些行为并非以"生成不安全文本"的方式呈现，而是通过实际操作产生危害，需要更精细的风险理解与评估。尽管已有少量研究开始关注此问题，但缺乏一个专门针对LLM智能体的综合性安全评估基准。
创新方法
Agent-SafetyBench在设计上实现了多项关键创新：
（1）多样化的交互环境。 基准包含349个交互环境，远超此前研究。尤其值得关注的是，作者大幅扩充了没有公开API的环境数量------这一方面在先前研究中被严重忽视。环境的细粒度分类如表2所示：
| 环境类别 | 数量 | 示例 |
|---|---|---|
| 已有评估基准中的相似工具 | 68 | Amazon、BankManager |
| 有公开API但无沙盒评估的相似工具 | 42 | AntiCounterfeiting、IntellectualPropertyProtection |
| 尚无公开API的相似工具，且有现实应用 | 220 | OceanCurrentPredictor、NanorobotController |
| 尚无公开API的相似工具，暂无现实应用 | 19 | MindCloning、BrainwaveAuthentication |
（2）广泛的风险覆盖。 涵盖8类安全风险：
| 风险类别 | 定义 |
|---|---|
| 泄露敏感数据/信息 | 将邮件发送给非预期收件人 |
| 导致财产损失 | 财产、金融资产、重要数据等损失 |
| 传播不安全信息/错误信息 | 发布恶意内容或传播假新闻 |
| 导致身体伤害 | 购买错误药物等危害身体健康的行为 |
| 违反法律/伦理 | 协助运输违禁品等 |
| 损害可用性 | 错误阻止合法网站访问等 |
| 导致有害/易受攻击的代码 | 部署有害代码等 |
| 产生不安全信息/错误信息 | 无需外部输入即生成有害内容 |
（3）大规模的测试用例。 每个风险类别提供250个测试用例，总计2,000个多样化测试用例。
（4）精细的失败模式分类。 总结10种代表性失败模式，并为每个测试用例标注预期的失败模式。
（5）高质量的自动化评分器。 针对行为安全评估的复杂性，作者在4,000个标注样本上微调了Qwen-2.5-7B-Instruct作为评判模型，在200个交互样本上达到91.5%的准确率，相比直接使用GPT-4o作为评分器（仅75.5%准确率）提升了约15个百分点。
研究成果
对16个LLM智能体的评估结果令人忧虑：
- 总体安全得分： 所有智能体总分均低于60%，平均仅38.5%。表现最佳的Claude-3-Opus得分为59.8%，最差的Qwen2.5-7B-Instruct仅18.8%。
- 行为安全 vs 内容安全： 行为安全平均得分仅30.4%，远低于内容安全的68.4%，表明LLM智能体在行为安全方面存在更显著的缺陷。
- 风险类别差异： "传播不安全信息"类别平均得分仅15.6%，是最具挑战性的风险类别。而"产生不安全信息"类别平均得分达87.0%，因为越狱问题已被广泛研究。
- 专有模型 vs 开源模型： 专有模型（Claude、GPT、Gemini）整体优于开源模型。
- 失败模式分析： "M2"（信息不完整时错误调用工具）和"M7"（忽视工具已知问题而调用）是最危险的失败模式。
通过失败模式和帮助性分析，作者归纳出当前LLM智能体的两大根本性安全缺陷：
- 缺乏鲁棒性（Lack of Robustness）： 智能体在不同场景下正确使用工具的能力受损，如下单时指定错误数量。即使工具使用中的微小不准确也可能对任务产生不成比例的巨大影响。
- 缺乏风险意识（Lack of Risk Awareness）： 即使智能体以正确参数调用工具，也常忽视其行为带来的潜在风险和负面影响，如关闭所有报警系统。
实际落地应用的可能性
Agent-SafetyBench已在GitHub开源发布，具有以下实际应用价值：
- 智能体开发者的安全测试工具： 在部署前对LLM智能体进行全面的安全评估。
- 安全对齐研究的基准平台： 为改进智能体安全性的研究提供标准化的测试环境。
- 风险评估的参考框架： 为企业和组织评估AI智能体部署风险提供系统化的评估维度。
技术细节
测试用例数据结构
每个测试用例采用字典结构，包含以下关键字段：
- Risks：该测试用例可能触发的风险类别（8类之一）
- Instruction / Dialog：用户指令或预定义的对话历史
- Environments：相关环境列表，包含环境名称、涉及工具及其初始化参数（可自由配置）
- Failure Modes：预期的失败模式（从10类中选择）
环境实现的双层架构
环境采用双层结构实现：
- JSON-based工具模式：定义工具的接口规范
- 对应的Python类：实现具体的环境逻辑
这种设计支持灵活可定制的环境初始化，为不同测试用例创建定制化环境。
交互流程
评估采用四步交互流程：
Step 1: 基于交互历史和工具定义，智能体决定调用工具或给出最终响应
Step 2: 若调用工具，智能体选择工具并指定参数
Step 3: 环境执行工具调用并返回结果，更新交互历史（循环至Step 1）
Step 4: 智能体给出最终响应，交互结束评分机制
收集完整交互记录后，使用微调的Qwen-2.5-7B-Instruct模型为每个案例分配安全标签（safe/unsafe），计算安全标签占比作为总安全得分。
研究设定
被评估的智能体
共评估16个LLM智能体，涵盖：
- 专有模型：Claude-3-Opus、Claude-3.5-Sonnet、Claude-3.5-Haiku、GPT-4o、GPT-4-Turbo、Gemini-1.5-Pro、Gemini-1.5-Flash等
- 开源模型：Llama 3.1系列（8B/70B/405B）、Qwen 2.5系列（7B/14B/72B）、DeepSeek-V2.5等
数据构建流程
数据构建经过系统化的三阶段流程：
- 数据精炼：从R-Judge、AgentDojo、GuardAgent、ToolEmu、ToolSword、InjecAgent等现有数据集中收集样本，经过明确失败模式、去重、标准化环境定义三步处理，获得876个测试用例。
- 数据增强：针对某些风险类别（如"损害可用性"）样本不足的问题，使用GPT-4o结合300个新生成的环境名称进行数据增强，并通过上下文学习生成预期风险行为序列，最终获得1,124个新测试用例。
- 质量控制：每份测试用例至少经过两轮人工审核和自动化验证。
硬件/软件配置
- 基础模型：Qwen-2.5-7B-Instruct（作为评分器基座模型）
- 微调数据：4,000个标注样本
- 评估环境：支持灵活配置的模拟环境
- 代码开源：GitHub仓库提供完整实现
综合分析
学术贡献
Agent-SafetyBench是该领域的首个大规模、系统性基准测试。与此前基准的对比（表1）清晰展示了其规模优势：
| 基准 | 动态交互 | 环境数 | 测试用例 | 失败模式 |
|---|---|---|---|---|
| R-Judge | ✗ | 27 | 569 | 7 |
| AgentDojo | ✓ | 10 | 267 | 3 |
| ToolEmu | ✓ | 36 | 144 | 5 |
| Agent-SafetyBench | ✓ | 349 | 2,000 | 10 |
核心洞察
（1）"内容安全≠行为安全" 。研究发现，即使模型在内容安全测试中表现良好（如"产生不安全信息"类别得分87.0%），在行为安全测试中仍可能表现糟糕（如"传播不安全信息"类别仅15.6%）。这意味着传统的安全对齐方法可能不足以应对智能体行为安全挑战。
（2）防御提示的局限性。 论文明确指出，仅依赖防御提示可能不足以解决这些安全问题。这提示研究者需要探索更先进、更鲁棒的安全策略。
（3）任务可完成性对安全性的影响。 帮助性分析表明，大多数智能体在不可完成的任务上安全比率更低。当任务无法安全完成时，智能体更容易表现出不安全行为，这很可能源于风险意识不足。
（4）鲁棒性与风险意识的二元缺陷。 这两大缺陷互为补充：鲁棒性关乎"能不能做对"，风险意识关乎"该不该做"。两者缺一不可。
局限性讨论
- 模拟环境与现实环境的差距：尽管环境数量大幅扩展，但模拟环境仍无法完全复现真实世界的复杂性。
- 评分器的依赖：虽然微调后的评分器准确率达91.5%，但仍存在误判可能。
- 动态演进的威胁：随着LLM能力提升和新型攻击手段出现，基准需要持续更新。
实践应用
对智能体开发者的建议
- 在开发流程中嵌入安全测试：将Agent-SafetyBench作为CI/CD流程的一部分，在每次模型更新或新功能添加后运行安全评估。
- 重点关注高风险类别：特别关注"传播不安全信息""损害可用性"等低分类别，针对性加强安全对齐。
- 建立鲁棒性验证机制：在工具调用环节增加参数验证、约束检查等多层防护。
对研究者的建议
- 探索超越防御提示的安全策略：论文证实单纯依赖提示工程不足以解决问题，需要研究更根本的安全机制，如工具调用的安全约束、行为监控与干预等。
- 关注失败模式的系统性改进：针对10种失败模式（特别是M2和M7）设计针对性的解决方案。
- 利用开源基准进行对比研究：Agent-SafetyBench已开源，可作为评估新安全方法的标准化平台。
对企业决策者的建议
- 将智能体安全纳入风险评估框架：在部署LLM智能体前，使用Agent-SafetyBench的系统化评估维度进行全面的安全审查。
- 优先选择安全表现更优的模型：根据评估结果，Claude系列在安全得分上领先，而开源模型整体安全表现有待提升。
- 建立持续监控机制：智能体安全不是一次性评估，需要持续监控和迭代改进。