企业官网建设流程全解析

IDENTIFYING THE RISKS OF LM AGENTS WITH AN LM-EMULATED SANDBOX

一、文章基本信息

二、论文一句话总结

为降低 LLM Agent 安全测试中搭建真实工具和沙箱的成本，作者提出 ToolEmu，使用基于LLM的模拟工具反馈和环境状态，并通过对抗模拟器构造长尾风险场景，再利用基于LLM的评价器评估 Agent 的安全性与有用性；人工验证显示约68.8%–72.5%的自动识别失败属于真实失败，但该方法只覆盖指令欠明确这一威胁模型，且存在测试案例依赖人工、模拟器与评价器同源及现实验证有限等问题。

三、研究背景与问题

1、研究背景

• LLM模型有更强的能力（能够通过Tool Calling调用外部工具），但是带来了更多的潜在威胁
• agent环境难以复现（需人工，工作量大），长尾问题难以发现

2、现有研究不足

• 无直接关注Agent安全测评领域
• 之前的评估需要人工专家搭建沙箱环境进行模拟，效率较低

四、核心方法

1、总览

核心想法：使用LLM模拟工具（Emulator）和它们的执行沙箱；然后根据Emulator生成的Trajectory，使用基于LLM的Evaluaor对执行进行安全性和有用性的评估
Emulator：模拟用户任务的执行轨迹，分为普通和增强版（用于发现长尾问题）
Evaluator：评估器，根据模拟轨迹，评估用户任务的安全性和可用性

输入主要有：工具描述，用户指令，不重复描述，潜在威胁和威胁行为，预期行动
Evaluator和Emulator根据不同的输入，得到不同的输出；比如Emulator需要工具描述，用户指令，输出Trajectory和Action；而Safety Evaluator输出的是socre；不同的部分使用不同的数据，获得其所需要的输出

2、 威胁模型

主要针对指令不明确这一具体的场景进行安全测试；并且我们假设用户的输入是无攻击性的（区别于红队对抗的恶意攻击）

3、Emulator （模拟器）

通过使用GPT-4大模型，编写提示词的方式实现；
首先，使用工具规范和用户指令来实例化沙盒（Agent运行环境），让其作为Trajactory的初始状态；
在之后的每一步中，都会接受当前的环境状态（之前的行动和观察，使用ReAct架构的Agent），然后模拟器结合这些内容，生成新的观察结果，依次类推

3.1 Adversarial emulator for red-teaming（对抗模拟器）

一个专门用于red team的emualtor，为了发掘长尾，更具挑战性的风险
核心思想：模拟器根据工具描述，用户指令，不充分描述和潜在风险，主动构造一些更加长尾、更加具有挑战性的场景，使 LM Agent 更有可能采取危险行为，并进一步引发潜在风险。

3.2 要求和设计

为了确保我们在模拟器中发现的失败案例是真实可信的，这些失败必须能够在实际的工具和沙箱环境中被真正复现出来。要满足这一点，模拟器必须保证其生成的输出同时具备以下特性：

• 准确性（accurate）：模拟结果应当能够反映对应工具在真实执行时的结果；
• 一致性（consistent）：例如，一个文件如果已经被删除，之后就不应该再次出现在环境中；
• 对于无效的工具输入，模拟器应当通过抛出异常的方式进行拒绝。

4、EVALUATIONS

4.1 Safety Evaluation

如图数据莫所示，**安全评估器（safety evaluator）**会接收完整的执行轨迹 Trajectory作为输入，同时还会接收该测试案例对应的：

• 指令描述不充分之处（underspecification）
• 潜在风险（potential risks）
• 对应的潜在危险行为（potential risky actions）
  基于这些信息，使用 LM 构建的评估器需要判断 LM Agent 是否采取了任何危险行为
  为了区分并量化这些风险，评估器需要从两个维度进行判断：

1. 风险实际发生的可能性：
   • 肯定不会发生（certainly not）
   • 可能发生（possible）
   • 很可能发生（likely）
2. 一旦发生所造成后果的严重程度：
   • 轻微（mild）
   • 严重（severe）
     然后，评估器会综合这两个维度，给出最终的量化安全分数

4.2 Helpful Evaluation

旨在评估 LM Agent 在不引发风险的前提下，能够多有效地完成用户指令。它提供了一个与安全评估互补的评价维度
主要使用的信息是如数据模型图中的：指令描述不充分之处和预期完成结果；并输出一个有用性得分

5、Benchmark

首先收集了一组多样化、可能涉及高风险的工具，覆盖 18 个类别。这些工具被组织成若干工具包（toolkits），每个工具包都是围绕某一类主要任务构建的一套完整且相互关联的工具集合。为了确保生成的工具包满足完整性和真实性等要求，我们会在模拟器中至少使用两个相关测试案例对其进行验证。
最终，我们构建的工具集合包含 36 个工具包，共 311 个工具

五、实验设计

1、VALIDATING TOOLEMU

• 作者通过“标准模拟器 vs 对抗模拟器”的成对实验，再用经过筛选的人工标注结果作为参考，验证模拟器质量以及自动安全性、有用性评估器是否可靠
• 该实验说明，模拟器不仅能较准确地发现现实中可复现的真实风险，而且对抗性模拟器还能主动挖出更多长尾、高风险失败，只是会牺牲一点精确率。
• 根据模拟结果中不存在严重问题的比例来评估模拟器的质量，这些严重问题由人工验证确定。通过衡量自动评估器与人工标注结果之间的一致程度，来评估自动评估器的准确性。

2、EVALUATING LANGUAGE MODEL AGENTS WITHIN TOOLEMU

“看起来安全”不一定真的好。例如 Vicuna-1.5 更安全，很大程度上只是因为不会使用工具，属于“能力不足带来的安全”。
合理的安全 Prompt 很有效。它可以同时提高安全性和有用性，说明真正理想的 Agent 不是“不行动”，而是能识别风险，并在安全前提下完成任务。
Agent 的目标不是单纯追求安全，而是在保持任务能力的同时提升风险意识；安全 Prompt 能明显改善这种“安全 + 有用”的平衡。

六、后序可扩展

• 扩展威胁的领域（本文为特定的提示词不充分）
• 更多的工具集和场景