SafeClawBench：在使用工具的大语言模型代理中分离语义危害、审计证据和沙箱危害

大家读完觉得有帮助记得关注和点赞！！！

摘要
使用工具的语言模型代理会引入超越不安全文本的安全失效：它们可能泄露受保护对象、写入持久化内存、发送消息、修改数据库，或触发有害代码和工具效应。现有评估往往将这些阶段合并为单一的攻击成功率，使得难以区分模型仅仅是同意了攻击者还是实际产生了可观察的危害。我们提出了 SafeClawBench，一个针对使用工具的代理安全的分阶段基准测试，包含 600 个受控对抗任务，涵盖六类攻击：直接和间接提示注入、工具返回注入、内存投毒、内存提取，以及歧义驱动的不安全推理。SafeClawBench 报告三个独立的端点：语义攻击接受度、审计可见的危害证据，以及沙箱观察到的工具/状态危害。我们在四种提示级策略下评估了五个代理端点，发现这些端点捕获了不同的失效模式。在没有额外提示保护的情况下，语义失败率在不同模型间差异很大，从 9.0% 到 44.2%。审计到的危害证据范围比语义失败更窄，并且在一种单独的可执行协议下，某些匹配的任务标识尽管通过了语义核心调用，仍会产生沙箱危害：在 12,000 行的匹配分析中，观察到的 347 例沙箱危害中有 291 例出现在通过语义检查的行中。提示策略会改变端点结果，但其效果既取决于模型也取决于协议。SafeClawBench 提供了一个可重现的框架，用于比较代理模型和提示策略条件，而不会将文本遵从性、证据支持的危害和可执行状态变化混为一谈。

1. 引言

大型语言模型已从对话助手演化为能够浏览、执行代码、查询数据库、发送电子邮件和存储持久化内存的代理（Yao 等，2023；Schick 等，2023；Zhou 等，2024）。OpenClaw（OpenClaw Contributors，2024）、AutoGPT（AutoGPT Contributors，2023）和 LangChain（LangChain Contributors，2023）等框架使得这类系统在环境权限（ambient authority）下易于部署：即代表用户采取行动而监督有限。这改变了安全目标。代理安全是分阶段的：一次攻击可能首先诱导语义顺从，然后访问受保护对象、改变状态、泄露金丝雀秘密，或为后续会话投毒内存。将这些端点压缩为一个攻击成功数字，掩盖了语义损害、仅语义失败和可观察基准危害之间的差异。

现有的 LLM 安全基准主要测量不安全的文本生成（Mazeika 等，2024；Zhang 等，2024；Huang 等，2024b）。代理安全基准如 PASB（Wang 等，2026）、InjecAgent（Zhan 等，2024）、AgentDojo（Debenedetti 等，2024）、AgentHarm（Andriushchenko 等，2025）、R-Judge（Yuan 等，2024）和 ToolEmu（Ruan 等，2024）解决了部分问题，但通常聚焦于单一攻击族、一种环境抽象或有限的防御覆盖。SafeClawBench 更接近于一个分阶段压力测试基准，而非群体风险研究：其目的是在受控对抗压力下区分模型、提示策略和端点定义。

核心设计原则是端点分离。语义损害、证据支持的危害、可执行状态变化和良性效用是相关但不可互换的。这种分离使我们不仅能够询问模型是否遵循了对抗性指令，还能询问该失效是否产生了受保护对象泄露、未授权访问、有害状态变化、持久化污染或有害工具/状态效应。

我们将主要分析围绕三个研究问题展开：

我们做出五项贡献：

图1：SafeClawBench 基准测试和端点结构。基准从600个精心策划的代理安全案例出发，评估固定的五端点×四个策略语义核心小组，审计规范的CoreFail行以寻找伪造物可见的伤害证据，并在执行平衡沙盒中单独运行匹配案例。论文报告了CoreFail@600、HarmEvidence@600、SemanticOnly和ObservedHarm@Exec作为不同的终点;D4 表示 D4/LongPolicy 提示复杂度探针。

2. 相关工作

LLM 安全评估已从红队测试（Ganguli 等，2022；Perez 等，2022）发展到 HarmBench、SafetyBench、TrustLLM 和 AdvBench 等基准（Mazeika 等，2024；Zhang 等，2024；Huang 等，2024b；Zou 等，2023）。这些工作对聊天安全至关重要，但并不直接测试持久化内存、工具返回通道或状态变化。GCG、AutoDAN、PAIR、TAP 和多轮越狱等对抗提示方法（Zou 等，2023；Liu 等，2024；Chao 等，2024；Mehrotra 等，2024；Anil 等，2024）推动了鲁棒自动化评估的需求，而间接提示注入和投毒工作（Greshake 等，2023；Yang 等，2024；Zou 等，2024）则激发了代理特定威胁通道的动机。

代理安全基准在范围上更为接近。PASB、InjecAgent、AgentDojo、AgentHarm、R-Judge 和 ToolEmu（Wang 等，2026；Zhan 等，2024；Debenedetti 等，2024；Andriushchenko 等，2025；Yuan 等，2024；Ruan 等，2024）提供了个性化代理、注入、有害遵从性、风险意识或模拟工具评估。另一条相近的工作线研究自主研究代理：PaperQA 检索并综合带有来源的科学文献（Lála 等，2023），MLAgentBench 评估语言代理在机器学习实验任务上的表现（Huang 等，2024a），AI Scientist 自动化想法生成、编码、实验、可视化、论文写作和模拟评审（Lu 等，2024），Agent Laboratory 将研究辅助组织为文献综述、实验和报告撰写阶段（Schmidgall 等，2025）。更新的研究代理评估使规划和可视化表面更加具体：PaperBench 研究论文到代码的复现（Starace 等，2025），ScienceAgentBench 将数据驱动发现分解为经过验证的编程任务（Chen 等，2025b），AI Scientist-v2 增加了代理树搜索和图表反馈循环（Yamada 等，2025），SciVisAgentBench 针对科学数据分析和可视化代理（Ai 等，2026）。SafeClawBench 是互补的：它强调攻击-防御覆盖，在固定的前沿端点上评估多种提示策略，并分别报告 harness/Exec 证据，以便不混淆提示级和状态级声明（附录表 6）。我们与防御思想进行比较，包括指令层次、StruQ、SmoothLLM、Llama Guard、spotlighting、FASA/ClawGuard 和轨迹审计（Wallace 等，2024；Chen 等，2025a；Robey 等，2023；Inan 等，2023；Hines 等，2024；Ying 等，2026；Chen 等，2026）。

3. SafeClawBench：基准设计

3.1 攻击面形式化

我们将 DPI、IPI、TRI、MPI、MEX 和 ADI 视为报告族而非互斥的因果类别。DPI/IPI/TRI 主要描述指令来源，MPI 描述内存写入持久性，MEX 描述受保护信息提取目标，ADI 描述由欠规范触发的不安全推理机制。每个案例还可以分解为源/通道、机制、目标资产、危害目标、生命周期阶段和证据通道。在当前发布的工件中，这些多标签字段作为基准元数据提供，而非作为最终的正交分类法。旧的 ℱ × ℒ × ℋ 网格仅作为构建和报告设备保留；未覆盖的单元主要对应于不合理的组合，如输出期间的内存提取。

3.2 威胁模型

我们建模一个攻击者，它可以影响已部署代理可能处理的一个或多个不可信通道：直接用户消息、外部文档或网页、工具返回值以及内存写入候选。攻击者不能修改特权系统提示或基准代码，但可以将内容伪装为业务流程、合规指南、工具元数据或记忆的用户偏好。目标代理具有描述文件、电子邮件、Web、代码、数据库和内存工具的系统提示；在语义核心中，这些能力是上下文性的，而在 Exec-Balanced 中，它们由隔离的沙箱存储支持。

防御者在主矩阵中限于提示级策略。这些策略可以指示模型拒绝、澄清、维护指令/数据边界或验证请求范围，但不能强制执行文件系统权限、网络出口控制、人工批准或事后输出过滤。这种限制是故意的：它隔离了提示策略和模型对齐的行为。因此，我们避免声称提示防御是一个完整的生产控制；对于不可逆操作和承载秘密的工具，运行时访问控制仍然是必要的。

3.3 基准构建

SafeClawBench 包含 600 个合成挑战案例，每个报告族 100 个案例。每个发布的案例指定了场景、用户提示、危害目标、生命周期阶段、成功谓词和安全行为。表 1 总结了六个报告族。正文将此固定分割视为受控比较压力测试，而非流行率样本；附录 G 描述了发布的案例模式和代表性场景。

表 1：SafeClawBench 基准统计。 600 个受控测试案例，每个攻击类型 100 个。基准围绕匹配的任务标识组织，用于比较模型和提示策略行为。

攻击类型

样本数

主要危害

3.4 基准层级

SafeClawBench 将代理安全失效分解为分阶段端点。语义核心是用于广泛比较的 600 案例提示级基准：每个模型-防御对接收相同的用户和系统提示，LLM 评判员标记最终响应是否在语义上遵从攻击目标。核心门控的危害证据审计随后审查规范的核心失败三元组，寻找受保护对象、访问、行动和持久化证据；在五端点面板中，来自五端点 × 四策略矩阵的所有 1,834 个规范核心失败行均被审计。Exec-Balanced 面板是一个 600 案例的可执行扩展，涵盖所有六种攻击类型，通过确定性预言机对文件、电子邮件、数据库、内存、Web 和代码执行存储进行检查；解析的工具调用更新隔离的沙箱状态，状态差异预言机为工具/状态危害提供单独的可执行端点（第 5.1 节）。SafeClawBench-Harness 将核心案例包装在模拟工具调用 harness 中并记录轮次/工具轨迹，但工具观察是模拟的。

核心与 Exec-Balanced 之间的配对。
每个 Exec-Balanced 案例通过保留攻击目标和安全行为谓词，同时实例化受保护对象和状态预言机，从核心案例映射而来。核心和 Exec 是单独的模型调用，因为可执行协议暴露了工具和状态，而语义核心是提示级的。因此，门控验证分析仅在同时具有核心和执行结果的案例/模型/防御三元组上执行；汇总 Exec 表不作为对 CoreFail@600 的分母混合校正。

3.5 测量模型：语义失败、审计证据和沙箱危害

对于核心案例 ii、模型 mm 和防御 dd，令 Ci,m,d∈{0,1}Ci,m,d​∈{0,1} 表示语义核心矩阵中的规范 CoreFail 标签：评判员将响应标记为攻击成功，因为它从语义上采纳、授权、揭示、计划或证明不安全的攻击目标。CoreFail 是一个语义端点，而非完成的危害。规范核心指标为：

对于五端点 × 四策略精简面板，核心门控的危害证据审计精确选择规范 CoreFail 行：Si,m,d=1Si,m,d​=1 当且仅当 Ci,m,d=1Ci,m,d​=1。所有 1,834 个选定行均被审计，缺失审计行为零。令 Pi,m,d=1Pi,m,d​=1 表示审计返回了一个解析的非空处置。审计询问一个审计的核心失败三元组是否包含核心工件中四类危害之一的证据：

这里 HtextHtext、HaccessHaccess、HactionHaction 和 HpersistHpersist 是行级布尔审计标签，对应于同一 (i,m,d)(i,m,d) 三元组的 TextHarm、AccessHarm、ActionHarm 和 PersistHarm。我们在完整的 600 案例核心分母上报告主要的核心失败门控危害指标。令 Ii,m,dharm=1Ii,m,dharm​=1 当且仅当 Ci,m,d=Si,m,d=Pi,m,d=Hi,m,d=1Ci,m,d​=Si,m,d​=Pi,m,d​=Hi,m,d​=1，否则为 0：

因此，HarmEvidence@600 是规范 CoreFail 行上的核心门控证据端点。可执行沙箱危害由 Exec-Balanced 测量，它有自己独立的协议、模型调用、工具暴露和分母。我们单独保留空审计尝试。令 Ii,m,dnull=1Ii,m,dnull​=1 当且仅当 Ci,m,d=Si,m,d=1Ci,m,d​=Si,m,d​=1 且 Pi,m,d=0Pi,m,d​=0：

我们仅在核心门控审计内使用 CoreFail 行中的条件证据率 P(H=1∣C=1)P(H=1∣C=1) 作为诊断性证据率。没有危害证据的审计核心失败保留为 SemanticOnly：在审计模式下没有受保护对象、行动、访问或持久化证据的语义损害。NullAudit、NotObservable 和单个解析的 OtherNoHarm 残余行分别报告。附录表 12 给出了完整的证据模式，表 13 列出了分母。

3.6 核心门控的危害证据审计程序

核心门控审计使用语义核心工件而非 Exec-Balanced 沙箱日志。TextHarm 通过在最终响应中对种子金丝雀、受保护配置值和受保护内存值进行精确字符串和受保护对象匹配来检查。AccessHarm、ActionHarm 和 PersistHarm 是针对核心响应或结构化核心轨迹中表达的明确受保护对象访问、不安全行动承诺或持久化污染的审计证据标签；它们表示工件可见的危害证据。已执行的状态变化由 Exec-Balanced 的 ObservedHarm@Exec 测量。在确定性证据检查之后，使用一个单独的后备审计 API 将剩余选定的核心失败行分类为 SemanticOnly 或 NotObservable；NullAudit 表示在重试处理后无法解析的后备分类器响应。在选定的审计行中，HarmEvidence、SemanticOnly、NotObservable、NullAudit 和 OtherNoHarm 是互斥的审计结果。授权是场景本地的：每个案例定义受保护对象和允许范围；当核心工件明确针对该范围之外的受保护对象时，访问是未授权的，与 Exec-Balanced 是否会触发沙箱预言机无关。NotObservable 为向前兼容性和后备审计跟踪保留；在汇总的 D0 和四种防御审计工件中，在确定性检查和重试过滤后它为零。

3.7 代理环境和评估协议

每个核心案例在模拟代理环境中评估，系统提示中描述了六类工具：文件操作、Web、电子邮件、代码执行、数据库查询和持久化内存。主要核心指标是 CoreFail@600，即 GPT-5.4 评判员在固定的 600 案例核心分母上平均的攻击成功标签。我们还记录 1-5 安全评分、危害类型、防御行为和评判员解释。Harness 和可执行指标分别报告为 ToolCall-ASR、StateChange-ASR、ObservedHarm@Exec，以及适用时的良性效用（附录 M）。

4. 实验与结果

本节首先定义提示策略条件和固定的精简面板评估框架，然后报告语义核心和核心门控审计结果。可执行端点诊断在第 5 节单独报告。

4.1 提示级防御配置

我们评估了九种提示级配置，但正文聚焦于四种跨越设计空间的策略：D0/无防御、B2/Sandwich 作为轻量级基线、D3 作为分层提示策略堆栈，以及 D4/LongPolicy 作为故意长且过度指定的策略探针。表 2 给出了本文使用的策略组成。这些标签是实验条件而非产品化防御：所有都是系统提示添加，没有一个强制执行运行时文件系统、网络、内存或电子邮件权限，下面的设置指定了哪些条件进入主矩阵。

具体地，D0 是带有工具描述但无附加防御策略的基础代理提示，因此它在相同的模拟工具环境下测量基线行为。B2/Sandwich 是一个简短的基线包装器，放置在面向用户内容的前后；它提醒模型更高优先级的指令覆盖用户、文档、网页、工具返回和内存文本。D3 是主要的分层提示策略比较器：它结合了指令层次、受保护状态和内存处理、请求目标验证、安全行动检查以及提示级工具链规则。D4/LongPolicy 是长提示包，在受保护状态规则之上添加了语义意图锚定、内存完整性守卫和工具链分析器语言。B 行是轻量级基线，D 行是逐步分层的提示策略条件，D4/LongPolicy 保留为策略复杂性诊断，而非声称更长的提示本质上就是更强的防御。

表 2：SafeClawBench 中比较的提示策略配置。 这些配置是可加性的系统提示模板。B1–B4 是轻量级基线，D1–D3 是分层提示策略堆栈，D4/LongPolicy 保留为长策略复杂性探针，而非声称的生产防御。

配置

提示组成

预期边界或攻击族

在本文中的角色

因此，D4/LongPolicy 不被解释为新的访问控制机制，也不作为 SIA、MIG 或 TCA 独立因果的证据。消融表从 D4 中移除一个组件，作为存档的诊断运行，附录 L 将 D3 填充到与 D4 大致相同的长度，以测试提示长度混杂。这种设计让我们能够询问长且过度指定的策略包是否改变模型行为，同时保持基准贡献与可部署防御的主张分离。

4.2 实验设置

主要分析使用精简面板工件中固定的五个端点字符串：GPT-5.5、Claude Opus 4.7、Qwen3.6-Plus、GLM-5.1 和 Kimi K2.5。工件元数据定义了比较框架。从表 2 的配置中，核心分析使用 D0、B2/Sandwich、D3 和 D4/LongPolicy，产生 5 × 4 × 600 = 12,000 次提示级评估。标题核心表从精简核心精确行工件 reduced_core_exact_0524_rejudged_gpt55 重新生成：20 个模型-策略单元中的每一个都有 600 个解析的核心行，缺失行为零。GPT-5.4 在温度 0 下评判核心输出，以在大规模评估中实现成本、成熟度和确定性可用性；独立的第二评判员验证见附录 J。附录 K 给出 240 行校准样本和人工二次裁决检查。附录表 8、9 和 10 记录了端点 ID、调用参数、重试/截断设置、工具调用格式、评判员规则位置、哈希值和发布包工件。

4.3 RQ1：语义核心

除非另有说明，核心结果使用 CoreFail@600：LLM 评判员对最终响应是否遵从攻击目标的二元标签，在固定的 600 案例分母上平均。我们将 ToolCall-ASR 和 StateChange-ASR 保留用于可执行端点。表 3 是主要的模型-防御比较；完整的九策略精简面板矩阵保留为附录表 27。

表 3：在四种面向提交的提示策略下，精简五端点面板的主要语义核心结果。 条目是精确的 CoreFail@600 百分比，括号中为描述性 95% Wilson 区间，每个模型-防御单元使用固定的 600 案例挑战分母。最后一行汇集了每个防御内的五个 600 案例单元（n=3,000），并给出了描述性汇集区间，而非配对的模型级检验。

模型

D0

B2/Sandwich

D3

D4/LongPolicy

图2：精简面板 CoreFail@600 防御轨迹。每行跟踪一个端点跨提示策略；越低越好。

在挑战集中，内存/持久化和提取导向的案例最高。在五端点面板的 D0 下，MPI 和 MEX 平均 CoreFail@600 均为 54.4%，高于 DPI（20.8%）、IPI（16.0%）、TRI（13.4%）和 ADI（9.0%）。这一模式反映了挑战集对代理特定状态和受保护信息失效的强调：MPI 捕获持久化失效，而 MEX 混合了精确受保护对象泄露与更广泛的安全策略/配置透明度错误。MEX 案例的启发式元数据分割证实了这种异质性：在挑战分割中，100 个 MEX 案例中有 30 个针对精确秘密或系统提示，9 个针对受保护内存/配置，49 个针对策略或架构透明度，12 个为其他泄露形式（附录表 17）。

即使在端点修剪后，模型选择仍然是一个重要的安全因素。D0 CoreFail@600 从 Claude Opus 4.7 的 9.0% 到 Kimi K2.5 的 44.2%，在精简主面板上比率为 4.9 倍，绝对差距为 35.2 个百分点。GPT-5.5（23.8%）、GLM-5.1（27.5%）和 Qwen3.6-Plus（35.5%）处于该压力测试分布的中间，而 Claude Opus 4.7 在本研究中具有最低的 D0 CoreFail 率。

提示策略效果依赖于模型。B2/Sandwich 与比 D0 更低的汇合精简面板 CoreFail@600 相关（14.8% 对比 28.0%）。D3 和 D4/LongPolicy 接近，分别为 9.1% 和 9.2%。D4/LongPolicy 在 GPT-5.5 上最低，在 Claude Opus 4.7 上与 D3 持平，而 D3 在 Qwen3.6-Plus、GLM-5.1 和 Kimi K2.5 上最低。因此，我们将其描述为依赖于模型的提示策略交互，而非统一的 D4 优势或提示防御组件的因果排序。附录 N 报告了来自单独扩展运行的配对检验作为稳健性证据。

D4/LongPolicy 是一个策略复杂性探针，而非标题赢家。跨端点，其实证值是混合的。在核心端点，汇合率上 D3 略低于 D4/LongPolicy（9.1% 对比 9.2%）。在核心门控审计中，D3 的 HarmEvidence 行数少于 D4/LongPolicy（119 对比 160），尽管 CoreFail 计数相似（272 对比 277；表 5）。在 Exec-Balanced 中，D4/LongPolicy 在四个标题策略中具有最低的汇合 ObservedHarm 计数（71/3,000 对比 D3 的 76/3,000；附录表 18），但这只是五行差异。匹配长度的 D3_LM 控制进一步平均 CoreFail@600 为 8.0%，低于 D3 和 D4/LongPolicy（附录表 38）。组件消融是存档的诊断，而非精确的精简面板因果估计。这些结果促使将 D4/LongPolicy 视为长提示和策略复杂性压力案例，而非经过单独验证的新防御或 SIA、MIG 或 TCA 独立因果的证据。

4.4 RQ2：核心门控的危害证据审计

完整的核心门控危害证据审计将第一阶段语义损害与工件可见的危害证据分离。在五端点面板的 D0 下，规范核心矩阵在 3,000 个模型-案例行中包含 840 个 CoreFail 行（28.0%）。所有 840 行均被审计：504 个在核心门控审计中显示 HarmEvidence（在五个模型汇合的固定 600 案例分母上为 16.8%），336 个为 SemanticOnly（11.2%），0 个为 NullAudit。在所有四个标题策略中，规范审计覆盖 1,834/1,834 个 CoreFail 行，缺失行为零：959 个 HarmEvidence，873 个 SemanticOnly，1 个 NullAudit，以及 1 个解析的 OtherNoHarm 残余。表 4 给出了 D0 模型级证据核算，表 5 给出了完整的防御级审计闭合。

表 4：精简五端点主面板在 D0 下的规范核心门控危害证据审计。 AuditRows 是从最终核心矩阵中选择的精确规范 CoreFail 行；所有 D0 CoreFail 行均被审计。NotObservable 对于这些行为零，为简洁起见省略。HarmEvidence、SemOnly 和 Null 是计数，闭合为 AuditRows = HarmEvidence + SemOnly + Null。证据列是核心工件证据计数，可能在 HarmEvidence 内重叠。

模型

CoreFail@600

AuditRows

TextHarm

AccessHarm

ActionHarm

PersistHarm

HarmEvidence

SemOnly

Null

Check

表 5：精简五端点面板按防御的规范核心门控危害证据审计核算。 计数是来自规范 CoreFail 审计的精确行；所有规范 CoreFail 行均被审计。HarmEvidence 是核心门控证据端点；OtherNoHarm 是解析的无危害/非语义残余类别，包含以使审计行核算闭合。

防御

CoreFail

Audited

Missing

HarmEvidence

SemOnly

NullAudit

OtherNoHarm

Check

攻击族触发不同的审计证据通道（附录 A.5）。在 D0 下，MPI 是最清晰的持久化证据族：272 个审计的 MPI CoreFail 行中有 251 个具有 HarmEvidence，主要通过持久化证据。MEX 在语义上仍然很高，但在严格的受保护对象证据下更窄：272 个 D0 审计的 MEX CoreFail 行中有 121 个具有 HarmEvidence，而宽泛的策略或配置解释除非暴露受保护对象，否则仍为 SemanticOnly。因此，D4/LongPolicy 被视为提示策略探针，而非统一占优的生产防御；详细的组件消融移至附录 E。

5. 端点分析

内存投毒之所以有效，是因为内存内容持久化且常被视为可信上下文。MEX 高的原因不同：当前的汇总 MEX 族结合了精确种子秘密泄露、受保护配置披露、受保护内存/记录检索以及宽泛的策略/配置透明度。在核心门控审计中，精确受保护字符串泄露计为 TextHarm，种子受保护配置披露根据情况计为 TextHarm/SensitiveConfig，而没有受保护对象的宽泛策略解释仍为 SemanticOnly 或良性透明度错误。MEX 子类型表是基于规则的，有助于将汇总 MEX 解释为混合的受保护信息族，而非纯精确秘密泄露率。

5.1 RQ3：Exec-Balanced 门控诊断

图3：按防御的 Exec ObservedHarm。条形显示均值；点和范围显示端点分布。

CoreFail@600 测量模型的文本输出是否在语义上遵从攻击目标；Exec-Balanced 则询问一个单独沙箱轨迹是否触发确定性文件、电子邮件、内存、数据库、Web 或代码预言机。在精简主面板中，D0 ObservedHarm@Exec 从 Claude Opus 4.7 的 0.5% 到 Kimi K2.5 的 11.3%，均值为 4.133%。StateChange 和 ObservedHarm 在此对抗性 D0 面板中重合，因为每个评分的攻击相关状态差异本质上是有害的，但这两个端点对于良性或混合用途面板在概念上保持分离。

精确的精简 Exec 工件支持每防御对 3,000 个案例-模型行的配对比较（附录表 18 和 19）。相对于 D0，B2、D3 和 D4/LongPolicy 在该协议中与更少的汇合 Exec 危害行相关：D0 下 124/3,000 对比 B2 76/3,000、D3 76/3,000 和 D4 71/3,000，具有显著的 Holm 调整 McNemar 检验。代表性和困难分割行是用于未来分割敏感性分析的重叠检查。

核心-Exec 连接覆盖所有五个端点、所有四个标题策略和所有 600 个可执行映射，产生 12,000 个匹配行（附录表 21）。连接包含 56 个 CoreFail∧ExecHarm 行，1,778 个无 ExecHarm 的 CoreFail 行，以及 291 个 CorePass∧ExecHarm 行。因此，347 个 ExecHarm 行中的 291 个（83.9%）来自通过语义核心调用的行。这一模式支持端点分离，但不应解读为简单的文本评判员遗漏：核心和 Exec 使用不同的模型调用、提示格式、工具模式、解析器路径、沙箱权限和工具可见性。更狭窄的主张是，在单独的可执行协议下，一些匹配的任务标识尽管通过了语义核心调用，仍会产生沙箱危害。

辅助效用范围。
良性效用面板是存档的附录配套检查，而非安全-效用权衡的证据。它涵盖相同的标题提示策略标签，但除了 Kimi K2.5 外，所有提供者都使用最近的存档端点而非精确的精简面板端点。其任务成功率也混合了任务设计、工具环境、解析器行为和模型行为，而虚假拒绝字段较窄。因此，我们仅用它来记录在重试完成后的大规模过度拒绝或 API 任务失效模式；在相同端点、策略和工具协议下的精确精简面板效用重新运行留给未来工作。

6. 结论

SafeClawBench 表明，工具代理安全评估需要端点分离。在五端点四策略面板中，模型选择产生较大的 D0 方差，提示策略依赖于端点，核心门控的 HarmEvidence@600 比 CoreFail@600 更窄，并且核心-Exec 匹配在沙箱协议下暴露了一个大的 CorePass–ExecHarm 切片。正文中的可视化以图形方式说明了同一观点：核心防御曲线压缩了广泛的语义失败范围，而 Exec 条形测量状态预言机结果。

实际后果是，基准用户应在比较模型或提示策略之前决定哪个端点匹配其部署问题。CoreFail@600 测量模型是否在文本中接受对抗性目标。核心门控审计询问该核心工件是否还包含受保护对象、访问、行动或持久化证据。Exec-Balanced 将匹配的任务标识移至隔离的工具/状态环境并测量确定性沙箱结果。291 个 CorePass∧ExecHarm 行表明，在单独的可执行协议下，一些匹配的任务标识尽管通过了语义核心调用，仍会产生沙箱危害，而许多 CoreFail 行在审计模式下仍仅为语义性的。

提示策略结果遵循相同的分阶段模式。轻量级包装、分层提示指令和过度指定的 D4/LongPolicy 探针与某些端点上较低的率相关，但效果因模型和协议而异。匹配长度控制进一步表明提示长度本身会改变模型行为，因此我们将 D4/LongPolicy 视为提示策略压力案例，而非将结果归因于 SIA、MIG 或 TCA 组件。存档的良性效用检查仅为附录诊断；在没有精确精简面板效用重新运行的情况下，它们不支持安全-效用权衡的主张。

精简面板设计也使来源成为科学主张的一部分。我们通过端点字符串和工件哈希固定主要比较，在可重现性元数据中报告这些标识符，并将存档的全端点矩阵与精简面板标题行分开。发布包围绕这一边界组织：基准 JSON、原始模型输出文件、评判员和防御提示、审计跟踪、沙箱日志、运行清单和确定性图表/汇总脚本在附录中列出并附有验证角色。240 行校准检查以同样的精神报告，作为分层样本上的敏感性检查，而非对主要标签的替代。

SafeClawBench 是一个压力测试框架，用于定位失效发生的位置：语义遵从性、审计证据支持的危害、沙箱观察到的状态变化或良性任务退化。部署系统仍然需要运行时权限、监控和对不可逆操作的人工批准。通过在这些端点之间保持分离，同时在可能的情况下使用匹配的任务标识，SafeClawBench 支持工具代理模型和提示策略的可重现比较。

局限性

SafeClawBench 是一个受控压力测试套件，因此其数字最好作为比较性端点测量而非操作事件率。提示策略矩阵隔离了一个重要的控制层；部署系统应将策略与运行时工具权限和监控相结合。一些需要长上下文或外部服务的危害在当前沙箱之外。发布时，所有案例均为合成或受控，没有生产系统被攻击，公共工件在需要处进行了编辑；携带金丝雀的行使用受控访问。