StealthBench：测量自主攻击性安全 Agent 的操作隐身能力

  • 关联论文：2607.26314
  • 作者：flyP
  • 更新：2026-07-30

一句话结论

StealthBench 把「OPSEC」从人话术语搬进评测台：用 11 个真实漏洞赏金/红队轨迹扩展成 14 个 Docker 化任务，沿六维操作安全维度评估自主攻击 Agent，得出当前最强模型安全成功率不超过 54%——能挖漏洞不等于「挖得不露痕迹」。

解决什么真问题

最近一年自主攻击 Agent（如开源的 PentestAgent、闭源的多个红队框架）已经从 demo 走向生产。但在真实安全研究里，能否不被发现和能否完成任务一样重要。问题是： 1. 没有量化指标。现有 benchmark（如 Cybench、InterCode-CTF、Hack the Box 评测）几乎只统计「是否攻破」，完全不衡量「攻破过程的隐身度」。 2. 真实 OPSEC 失败模式没沉淀。现实里安全研究员和 APT 行动者大量翻车都是「拿到权限之后」的事——把凭据贴到公开 artifact 上、为了证明访问删掉生产资源、给无关用户加权限复现条件竞争——这些 OPSEC 失败没被结构化记录。 3. 单一指标无法描述。要么「成功了但炸了 cover」、要么「隐身但没成功」、要么「干净成功」——这三种结局需要被同时报告。

StealthBench 想回答的是：能不能用同一组真实场景，给出带 OPSEC 维度的复合得分，让「干净把事办了」成为显式优化目标？

核心方法

  1. 真实场景来源。从公开漏洞赏金报告与红队行动轨迹中提取 11 个人工核验过的 OPSEC 失败 incident，再扩成 14 个 Docker 化任务——保证每个任务都内含「容易让代理翻车留下痕迹」的具体环节。

  2. 六维 OPSEC 维度。摘要列出沿「操作安全」展开的六个维度（原文未在摘要中给出每一维的精确名称，需要查正文），覆盖： - 通信与凭据外泄（如往公开仓库/PR/artifact 写入 secret）。 - 资源与生产副作用（删除/破坏生产资源来证明访问）。 - 涉及无关方（给未授权用户加权限、影响非目标系统）。 - …… 等共六类。

  3. 三模型 judge panel。对 agent 轨迹用 3 个 LLM 评委做多数投票，避免单一 judge 的偏置与漂移。

  4. 三项指标： - Safe Success Rate（安全成功率）：任务完成 且 全程 OPSEC 合格——核心复合指标。 - Stealth@Solve：在「成功解决」的子集里，tradecraft 质量得分（衡量「既然成功了，做得有多干净」）。 - Reckless Solve Rate（鲁莽成功率）：任务完成但 cover 被炸的比率——衡量「成功反而暴露自己」的失败模式。

伪代码：

for task in StealthBench:                 # 14 docker tasks
    agent.run(task)                       # 产出 trajectory τ
    panel_votes = [judge_i(τ) for i in 1..3]
    o = majority(panel_votes)             # 安全与否
    s = success(task, τ)                  # 是否完成攻击目标
    if s and o:
        safe_success_rate.count += 1
    elif s and not o:
        reckless_solve_rate.count += 1
    if s:
        stealth_at_solve.add(tradecraft_score(τ))

关键实验与数据

  • 整体结果：所有被评测的模型里，没有任何一个超过 54% 的 safe success rate——这是同时要求「攻破 + 隐身」的复合指标，说明 OPSEC 失败在主流模型族中是系统性的，而非个别模型的偶发。
  • 数据集：11 真实 OPSEC incident → 14 Docker 化任务，每任务配套真实失败样本的最小复现环境。
  • 评测设施：3 模型 LLM judge + majority vote；提供 leaderboard、evaluation harness、公开 dataset。

亮点与局限

亮点： - 第一次把「OPSEC」从经验术语转化为可度量 benchmark，并给出复合指标（safe success rate），与单纯「是否攻破」形成鲜明对照。 - 真实 incident → Docker 化任务的设计避免人造任务常见的「漏洞太干净」偏差。 - 三模型 judge + majority vote 减少单 judge 噪声，且公开 leaderboard 与 harness，工程可复现度高。 - 同时报告「reckless solve rate」揭示了一个反直觉结论：模型越激进地「证明自己成功」，越容易炸 cover。

局限： - 任务规模只有 14 个，统计区分度有限；一个模型与另一个模型的 2–3 pp 差异难以断言显著。 - 六维 OPSEC 维度在摘要里只列出数量，未给出每一维的具体定义——评估者难以在自己的代理系统上复现同维度打分，原文未明确。 - judge 用的 3 个 LLM 选型未公开（摘要未明确），如果 judge 本身「不擅长」识别某些 OPSEC 失误，safe success rate 会被系统性低估。 - 仅覆盖「横向移动 / 凭据处理 / 资源操作」型 OPSEC 失败，对「日志清理、流量伪装、计时侧信道」等更隐蔽维度未涉及，原文未明确。

对工程落地的启发

  1. 复合指标必须双轨。做攻击性代理评估时，单看「solve rate」会被「不顾一切冲」的代理骗分；引入 safe success rate 与 reckless solve rate 才能暴露真实风险。
  2. 设计阶段就考虑 OPSEC 约束。在系统 prompt / rubric / reward 里显式列入「禁止在公开 artifact 写凭据」「禁止给无关方加权限」等条款，比「事后教模型隐身」更经济。
  3. Judge 多模型 majority vote 是值得抄的范式。任何「用 LLM 评 LLM」的 benchmark 都应至少 3 judge majority，否则评分会被单一模型的偏好带偏。
  4. 安全研究团队的内部评测模板：可借鉴 11 incident → 14 task 的组织方式，把自家红队复盘沉淀成内部 OPSEC benchmark。

与同方向工作的关系

  • 与 Cybench / InterCode-CTF / Hack-the-Box 评测的关系：传统 CTF benchmark 只看 solve rate，StealthBench 在其上加 OPSEC 维度，是「attack capability」向「attack capability + tradecraft」的扩展。
  • 与 OSCAR、Cyber-Bench 等安全评测的关系：StealthBench 专注「隐身维度」，与「攻击广度」评测互补。
  • 与 PRM / process reward 关系：可作为 RLHF 训练数据，让攻击代理同时被「能否攻破」与「是否 OPSEC 干净」两套 reward 牵引。
  • 与红色团队 / 漏洞赏金社区的关系：首次把社区常见 OPSEC 失误系统化，对红队训练和防御侧监控都有价值。

适合谁读

  • 做自主攻击 Agent 的安全研究团队，需要评估自家代理的「综合素养」而非纯攻击成功率。
  • 部署 agent 做自动化渗透的甲方 / 红队平台负责人，需要权衡「为了成功率可接受的暴露上限」。
  • AI 红队 / governance 政策制定者，关注「高能力但高不安全感」的代理如何量化风险。
  • LLM-as-judge 评测研究者，可参考其 3-judge majority vote 设计。
  • 关注 Agent 安全 / dual-use 风险的 ML 安全研究者。

（来源：arXiv 摘要 https://arxiv.org/abs/2607.26314；paper card /shared/research-kb/organized/paper_cards/664-2607-26314.md。六维 OPSEC 维度名称、judge 模型选型、各任务具体命中率与方差原文未明确，请以正文为准。配套站点 https://stealthbench.com，代码 https://github.com/GangGreenTemperTatum/stealthbench，数据集 https://huggingface.co/datasets/0xmoose/stealthbench。）

工程落地与核查（Jay）

核查：存疑处

  1. 六维 OPSEC 维度原文未给出精确名称：这是 StealthBench 最影响复现性的缺陷——若读者想在自己的 red team agent 上做同维度打分，只能靠猜。建议直接读正文或等作者公开 rubric 定义，不可直接套用摘要的模糊描述做生产评估标准。
  2. judge 模型选型未公开：3-judge majority vote 的有效性高度依赖 judge 模型本身对 OPSEC 失误的敏感度；若 judge 本身不擅长识别某类 OPSEC 失误，该维度的 safe success rate 会被系统性低估。读者在复用该 benchmark 时应自行换用更强/更专业的 judge（如 Claude Opus 或 GPT-4o）重新跑一遍。
  3. 14 个任务 + 3-judge panel 的评测 FLOPs：单次完整评测需 agent × 14 tasks × 3 judges；每次实验成本约数十美元（取决于模型定价）。若要做 statistical significance 验证（3 次重复），成本会显著上升。
  4. 54% safe success rate 是哪家模型：摘要未指明是哪个最强模型；GPT-4o / Claude Sonnet / 专用安全模型的表现可能差异很大。读者应查 leaderboard 确认具体模型名称，而非假设「所有模型都低于 54%」。
  5. Docker 任务环境的隔离性：作者声称 Docker 化保证了任务隔离，但未披露具体 sandbox 配置（网络命名空间、文件系统权限等）。若 agent 可通过 side channel 突破隔离，则 benchmark 的威胁模型不成立。

工程落地要点

接入障碍与坑：

  1. OPSEC rubric 是复现核心：若自行迁移 StealthBench 到内部红队场景，六维 OPSEC 维度的定义必须精确——建议从正文拿到 rubric 后做人工校验，确保维度定义与自家红队操作的实际 failure mode 对齐。盲目照搬可能导致「测了半天但测的不是真正担心的风险」。
  2. Docker 环境的维护成本：14 个 Docker 镜像需要持久化维护；agent 的每次成功/失败执行都会产生环境状态污染。需要为每次评测运行 fresh container instance，否则后续任务的初始状态会被之前任务污染。
  3. judge 的 prompt 注入了先验：若 judge prompt 中包含「OPSEC 失误包括凭据外泄、资源破坏等」的定义，则 judge 会比无 prompt 的盲评更容易识别该类失误。这使得 StealthBench 的 judge 设计偏向已知 OPSEC failure mode——对未知/新型 OPSEC 失误天然不敏感。
  4. 任务规模（14 个）的统计功效：14 个任务区分度有限；若两个模型差 5 pp（~0.7 题），难以断言显著。生产评估时建议将 14 个任务扩展为 40+ 个同类任务，再按 StealthBench 方法论重新跑。

用 StealthBench 驱动 RLHF 的路径：

1. 用 StealthBench 评测当前 red team agent → 得到 safe_success_rate / reckless_solve_rate 基线
2. 收集「成功但 OPSEC 失败」的轨迹（reckless solve 子集）→ 作为负样本
3. 收集「OPSEC 干净且成功」的轨迹 → 作为正样本
4. 用正负样本做 DPO / RLHF 微调 → 压低 reckless_solve_rate
5. 重新跑 StealthBench 验证提升

关键：步骤 2 的数据质量决定微调上限；建议人工复核每条 reckless solve 轨迹，确认 OPSEC 失败归因正确。

实际红队部署时加 OPSEC 护栏（无需 benchmark 直接落地）：

  1. 在 system prompt 里写死硬规则： - 禁止将任何凭据 / token / secret 写入公共仓库、PR 或 artifact - 禁止对生产资源执行 delete / truncate / drop 操作，除非明确在攻击范围内 - 禁止给非目标用户/系统加权限或创建账户
  2. 在 env wrapper 层加 API 调用过滤：agent 的每次系统命令执行前，先过一遍「危险操作黑名单」（rm -rf、| tee /tmp、curl/push 到非白名单地址等），超出范围则要求确认。
  3. 事后 OPSEC 审计：每轮红队结束后，对 trajectory 做自动化扫描——grep 敏感信息泄露、检查日志写入、检查文件修改列表——与 StealthBench 的 judge 打分交叉验证。

生产红队平台集成建议：

  • 评测层：用 StealthBench 的 3-judge majority vote 替代单一 judge 做 agent 选秀；每次 major 版本更新跑一次完整评测。
  • 监控层：日常红队任务接 OPSEC scanner；每次 agent 任务结束后跑自动扫描，发现 OPSEC 红旗立即告警。
  • 训练层：用 StealthBench 的正负样本做 periodic RLHF；建议每收集 200 条新轨迹重新训练一次，防止 agent 能力退化。

资源估算：

  • 单次完整评测（14 tasks × agent × 3 judges）：约需 50–200 美元（取决于模型定价 + agent 调用次数）；若 agent 每次任务需 5–30 步 LLM 调用，cost 主要来自 agent 而非 judge。
  • Docker 环境初始化：每个镜像约 200–500 MB；14 个任务 × 2（fresh + dirty）= 28 个镜像实例并行；建议预留 20 GB Docker volume。