IDENTIFYING THE RISKS OF LM AGENTS WITH AN LM-EMULATED SANDBOX一、文章基本信息论文标题IDENTIFYING THE RISKS OF LM AGENTS WITH AN LM-EMULATED SANDBOX作者Yangjun Ruan发表年份2024会议/期刊ICLR二、论文一句话总结为降低 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、EVALUATIONS4.1 Safety Evaluation如图数据莫所示**安全评估器safety evaluator**会接收完整的执行轨迹 Trajectory作为输入同时还会接收该测试案例对应的指令描述不充分之处underspecification潜在风险potential risks对应的潜在危险行为potential risky actions基于这些信息使用 LM 构建的评估器需要判断 LM Agent 是否采取了任何危险行为为了区分并量化这些风险评估器需要从两个维度进行判断风险实际发生的可能性肯定不会发生certainly not可能发生possible很可能发生likely一旦发生所造成后果的严重程度轻微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 能明显改善这种“安全 有用”的平衡。六、后序可扩展扩展威胁的领域本文为特定的提示词不充分更多的工具集和场景 Agent Safety论文阅读：ToolEmu
IDENTIFYING THE RISKS OF LM AGENTS WITH AN LM-EMULATED SANDBOX一、文章基本信息论文标题IDENTIFYING THE RISKS OF LM AGENTS WITH AN LM-EMULATED SANDBOX作者Yangjun Ruan发表年份2024会议/期刊ICLR二、论文一句话总结为降低 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、EVALUATIONS4.1 Safety Evaluation如图数据莫所示**安全评估器safety evaluator**会接收完整的执行轨迹 Trajectory作为输入同时还会接收该测试案例对应的指令描述不充分之处underspecification潜在风险potential risks对应的潜在危险行为potential risky actions基于这些信息使用 LM 构建的评估器需要判断 LM Agent 是否采取了任何危险行为为了区分并量化这些风险评估器需要从两个维度进行判断风险实际发生的可能性肯定不会发生certainly not可能发生possible很可能发生likely一旦发生所造成后果的严重程度轻微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 能明显改善这种“安全 有用”的平衡。六、后序可扩展扩展威胁的领域本文为特定的提示词不充分更多的工具集和场景