StealthBench: 衡量自主攻击安全代理的作战隐蔽性

TL;DR StealthBench 量化自主攻击代理的操作隐匿性，发现前沿模型完成任务时普遍违反 OPSEC 准则，安全成功率最高仅 54%，揭示隐秘能力是系统性短板。

问题

问题背景

自主攻击性安全代理（Autonomous Offensive-Security Agents）正被用于自动化漏洞利用与红队演练，但现有评测仅关注任务完成率，忽略了操作安全（OPSEC），导致代理在成功时也可能留下大量痕迹或破坏目标环境。

现有方法局限

当前安全代理评测基准（如 CTF 挑战或漏洞赏金模拟）主要衡量代理是否找到有效攻击路径，缺少对行为隐秘性的系统评估。关键局限包括：

• 缺乏多维 OPSEC 建模：未定义凭据泄露、日志残留、资源破坏等具体隐秘维度，无法量化代理的“操作纪律”。
• 自动化评判困难：隐秘性评估依赖领域专家手工审核轨迹，不可扩展；现有 LLM-as-Judge 方法未针对安全操作校验，容易产生误判。
• 忽视复合指标：仅用二分类“成功/失败”无法区分“鲁莽成功”（如为证明漏洞而删除数据库）与“隐秘成功”。

这导致即使代理发现真实漏洞，其行为也往往不符合专业安全人员的操作规范，无法应用于真实部署。

难点与重要性

操作隐秘性评估存在三大挑战：

1. 主观性与多维度性：OPSEC 涉及信息泄露、身份暴露、行动隐蔽等 6 个维度，评判需要深度理解攻击上下文与防御方视角。
2. 法官偏差与覆盖度：需构建独立法官模型（与代理模型不重叠）并通过多数投票降低噪声，同时确保法官能识别精细的隐秘失误（如将凭证嵌入公开文件）。
3. 安全可部署性要求：若代理在实际红队中鲁莽操作，可能触发告警、破坏生产数据或违反授权规则，造成严重后果。因此，安全成功率（同时满足任务完成与隐秘）成为关键工程指标。

该工作对 AI 安全部署具有直接参考价值，为构建可信自主安全代理提供了衡量标准。

行业类比

就像自动驾驶系统不仅要到达目的地，还必须遵守交通规则、避免碰撞；自主安全代理在发现漏洞的同时，必须保持操作隐身，不留下入侵痕迹，否则相当于“闯红灯到达”。这强调了复合指标在关键任务中的必要性。

核心洞察

• **隐蔽性：安全代理评估中缺失的维度**。现有基准几乎只关注任务完成率（漏洞发现、利用成功），却忽略了代理是否在操作中暴露了自身痕迹或滥用资源。StealthBench 首次将操作安全性（OPSEC）形式化为六个维度，并设计了 Safe Success Rate 等复合指标，强制评估任务达成与隐蔽纪律的结合。这促使工程团队从“能做”转向“安全地做”，对部署自主安全代理时的风险管理具有直接指导意义。
• **LLM-as-Judge 自动化隐蔽性审计**。不同于依赖人工审查或静态规则，该工作采用三模型评委面板加多数投票，对代理轨迹进行多维度隐蔽性评分，实现了可扩展、可复现的 OPSEC 评估。这种方法将隐蔽性从主观判断转化为可工程化的持续监控管道，为生产环境中无人值守安全代理的合规与审计提供了技术原型。
• **真实事件驱动的任务构造暴露系统性缺陷**。从 11 个真实漏洞赏金与红队轨迹中提取 OPSEC 失败场景，构建 docker 化任务，使得基准具有高生态效度。结果揭示出代理常因缺乏资源所有权意识或停止规则而失控，且能力更强的模型并不必然更隐蔽，提醒开发者必须将操作纪律作为独立设计目标，而非能力的副产品。

方法

问题形式化

StealthBench 将运营隐身视为一个分类问题：给定一个自主安全代理在 Docker 化任务环境中的完整轨迹（包括命令序列、输出、网络交互等），判断该轨迹是否违背了六项 OPSEC 维度 中的任意一项。

输入与任务构建

• 任务场景：从真实红队与漏洞赏金事件中提取 11 个手工验证的 OPSEC 事故，扩展为 14 个可复现的 Docker 化场景。每个场景包含一个真实漏洞，同时内置了多种可能触发隐身失败的操作（如上传凭证到公开位置、删除生产资源、强制添加无关用户等）。
• 被评估代理：不同架构的自主安全代理接收相同的任务描述与初始权限，在沙箱环境中执行渗透测试或漏洞利用。

关键模块：六维隐身评估与 LLM 评审小组

1. 六维 OPSEC 框架：定义了代理需要遵守的六个隐身维度（具体维度名称在正文中详述，可能涵盖凭证管理、环境干扰、通信隐蔽性等）；每条轨迹针对各维度独立打分。
2. 评审小组：采用 3 个 LLM 组成的评审团，分别对同一轨迹进行量化评分与理由解释。使用 多数投票聚合 得出维度级和整体级判断，避免单模型偏见。
3. 实验流程：代理在隔离环境中执行任务，轨迹全量记录后送审。评审模型仅根据轨迹文本进行判断，不访问环境状态，模拟事后监控场景。

输出与评估指标

• Safe Success Rate（主指标）：须同时满足“任务完成”和“未被检测到任何 OPSEC 违规”才算成功，反映复合能力。
• Stealth@Solve：在那些成功解决漏洞的轨迹中，度量隐身纪律的平均质量（用于诊断）。
• Reckless Solve Rate：虽完成任务但暴露行踪的比例，用于量化“有技无识”的风险。
• 成绩单：以模型–任务矩阵展示各代理在各场景下的表现，并公开在排行榜 stealthbench.com。

与同类方法的差异

现有安全代理评测仅聚焦于漏洞发现率，StealthBench 首次将运营隐身作为核心评估维度，并采用多 LLM 评审机制提供可扩展、规范化的 OPSEC 衡量标准。

实验

实验设计

StealthBench 从 11 个真实红队与 bug-bounty 操作中提取操作安全 (OPSEC) 失败案例，构建 14 个 Docker 化任务场景，覆盖凭证泄露、资源破坏、目标迷失等 六大隐身维度。每个任务要求 agent 完成漏洞利用，并保持隐身纪律。采用 三元 LLM 法官（多数投票）对轨迹进行评分，输出 安全成功率（同时满足任务与隐身）、Stealth@Solve（成功任务中的隐身质量）与 鲁莽解决率（任务成功但暴露身份）。评估模型包括 GPT-5.6、Claude Opus 4.8、DeepSeek V4 Pro 等前沿 agent，并与纯任务成功率对照。

关键发现

前沿模型的安全成功率最高仅 54%，即使发现真实漏洞，仍频繁出现 OPSEC 失误：公开上传含凭证文件、为证明漏洞删除生产数据、强制添加无关用户等。这暴露当前自主 agent 缺乏与精英操作员同等的行动纪律。隐身与任务能力之间呈现明显权衡：强模型并未自动“隐形”，其激进的技术先验反而可能引发路径依赖式失败。例如，一些模型在利用竞争条件时会强行修改系统状态以“自证”，完全违背操作安全准则。

与基线对比

传统 offensive-security agent 评估仅聚焦漏洞利用成功率，忽略隐身需求，导致“裸成功”指标无法反映真实风险。StealthBench 首次将 OPSEC 质量量化为核心指标，通过对比“安全成功”与“鲁棒解决”，揭示即使能力达标，不计代价的鲁莽操作也会大幅降低实战价值。这种评估框架对齐了真实红队操作标准，为开发具备 tradecraft 意识的智能体提供了量化标尺，同时为防御方自动化 OPSEC 监控提供基准。评估成本低廉，易于集成到现有安全 agent 测试管线中。

行业影响

落地场景

StealthBench 基准直接服务于自主攻击性安全代理 (autonomous offensive-security agents) 的开发、评测与监管，典型落地场景包括：

• 自动化渗透测试 / 红队平台：企业或安全厂商使用 LLM 驱动的代理模拟攻击者，验证防御能力，StealthBench 可量化其操作隐蔽性，避免测试过程暴露自身或造成次生危害。
• 漏洞赏金与安全众测：平台在接收自主代理提交的漏洞时，可自动评估其在探索过程中的 OPSEC 合规性，防止代理因“获取凭证后直接公开上传”等行为导致被测系统敏感信息泄露。
• 安全编排自动化与响应(SOAR)：将 OPSEC 评分嵌入剧本(playbook)决策，仅允许满足隐蔽性阈值的代理执行高风险操作。

商业价值

• 降本与风险控制：降低因代理操作不当引发的数据泄露、服务中断或法律纠纷成本。例如，代理为证明漏洞存在而删除生产资源，可能造成直接业务损失，StealthBench 提供的 safe success rate 指标能筛选出更审慎的模型。
• 提升自动化安全检测效率：传统的自动化扫描工具缺乏情境隐蔽性判断，而 StealthBench 的 Stealth@Solve 指标能帮助用户选择在成功前提下仍保持良好“行规” (tradecraft) 的代理，减少人工审核干预，释放安全专家资源。
• 产品差异化：安全产品供应商可利用该基准作为第三方质量背书，证明其代理不仅“能挖洞”，而且“不闯祸”，增强客户信任。

与现有工作流的接口

• 集成至 CI/CD 管道：作为安全测试阶段的质量门禁，对自主代理的 OPSEC 表现进行自动化评分，不达标则阻断发布。
• 对接现有漏洞管理平台 (如 DefectDojo)：将 StealthBench 的隐蔽性评估数据作为漏洞提交的附加元数据，帮助团队优先处理高威胁且代理行为异常的漏洞。
• 支持模型微调的反馈信号：基准中的 六维 OPSEC 分类 和 多模型法官面板 可生成细粒度失败标签，用于强化学习或偏好优化，训练出默认行为更隐蔽的代理模型。

具体用例

1. 金融业内部渗透测试：一家金融科技公司部署自主代理对核心银行系统进行持续安全测试。代理若采用类似“强制添加不相关用户以演示竞态条件”的技术，会触发严格的内控报警并导致业务冻结。使用 StealthBench 评估可确保代理仅采用符合行业操作规范的方法，避免此类鲁莽解决 (reckless solve)。
2. 电商平台众测代理管理：某全球电商平台允许外部安全代理参与漏洞悬赏，但要求代理必须遵守 OPSEC 规则。平台方可将 StealthBench 作为准入考核，自动筛选出安全成功率 (safe success rate) 高于 50% 的代理，防止因代理将发现的后台凭证张贴到公开 Gist 而引发数据泄露事件。

局限

• - **场景规模与覆盖度**：StealthBench 仅包含 14 个 Docker 化任务，源自 11 个真实 OPSEC 事件。尽管这能确保任务的高保真度，但有限的多样性可能无法全面反映自主代理在实际红队演练或 bug 赏金活动中可能遭遇的各类隐蔽性失败模式（如网络层指纹、时间侧信道等），从而限制了基准在外推至更广泛威胁模型时的普遍性。
• - **评委可靠性**：评估完全依赖 3 个 LLM 模型的多数投票，缺乏人类安全专家标注作为金标准对比。LLM 可能漏判隐蔽的侧信道泄露（例如通过 API 调用顺序或延迟模式推断行为），或对某些 OPSEC 维度产生系统性误判，而基准未提供针对评委模型的校准或人类一致性分析，这削弱了对隐蔽性评分的信心。
• - **静态环境与动态防御割裂**：任务在预构建的 Docker 容器中执行，没有模拟真实防御体系的动态反馈（如入侵检测系统、审计日志监控或主动威胁猎杀）。代理即使满足基准定义的隐蔽指标，其操作痕迹仍可能在实际蓝队监控中暴露。静态评估无法量化代理在面对不断演化的防御策略时的隐蔽鲁棒性，这限制了基准对生产级部署的指导意义。