HarnessSecurity-Bench 实测六款编码智能体：开启自动批准使攻击成功率从 29.2% 升至 95.6%
相关研究与后续进展
核心概要
该研究构建了覆盖 40 个编码智能体 harness 的十类安全机制分类体系并评估 400 个 harness–机制单元（205 个确认实现、83 个确认缺失、112 个未决），随后提出 HarnessSecurity-Bench，用 23 个任务、五个攻击面和独立确定性判据在 GLM-5.2 下对六款 harness 运行 2,500 次试验，发现开启自动批准使攻击成功率从 29.2% 升至 95.6%，网络隔离与只读模式分别把攻击成功率从 57.1% 和 8.3% 降至 0.8% 但带来 24.5 和 34.0 个百分点的效用损失，而命令白名单与黑名单分别以小幅效用损失和效用提升降低攻击效果。
Figure 1: Attack surfaces across the coding agent harness loop. The center shows five stages; panels A–F illustrate paths from adversarial resources or input to changed decisions or execution. Numbered markers identify stages that each surface can affect. HSB evaluates attacks on A–E.
arXiv · 第 3 页深度剖析
研究给出十类安全机制分类体系（自动批准、网络隔离、命令白名单、命令黑名单、MCP 权限、提示注入过滤、路径限制、只读模式、审计日志、项目信任），并在 400 个 harness–机制单元中确认 205 个实现、83 个缺失、112 个未决。 此前工作多为架构综述或仅覆盖少数 harness 的实证比较，本文以统一分类和可审计评级协议同时覆盖 27 个开源与 13 个闭源产品。 由三名研究者独立标注 44 个安全标签并归并为十类机制，RQ2 由三名 LLM 评审与两名人类研究者独立评级，五名评审在 382/400 单元达成多数，其余 18 个由三名人类研究者裁定；全体评审的序数 Krippendorff's α 为 0.740，人类评审间为 0.911。
已确认实现中约一半为需用户显式开启的 opt-in（205 个实现单元中 109 个为 O），且闭源 harness 的证据缺口更大（闭源 130 个单元中 69 个为未决，占 53.1%，开源为 43/270，占 15.9%）。 把“机制是否存在”与“默认是否生效”分开度量，并量化了闭源产品在外部可核查性上的差距，例如全部 13 个闭源提示注入过滤单元均为未决。 基于官方文档、CLI 材料与源码的逐单元评级，采用 Evidence-of-Thought 方法要求每条非未决评级引用来源路径与行范围并记录 SHA-256 哈希。
在 2,500 次试验中，开启自动批准使效用从 77.1% 升至 95.4%、攻击成功率从 29.2% 升至 95.6%；网络隔离使攻击成功率从 57.1% 降至 0.8% 但效用损失 24.5 个百分点，只读模式使攻击成功率从 8.3% 降至 0.8% 但效用损失 34.0 个百分点。 首次在同一执行环境下对原生安全机制的开启与关闭设置做配对比较，并用彼此独立的确定性判据分别度量任务效用与攻击效果。 六款 harness、九个机制基准、每个任务–harness–设置组合 10 次试验，共记录 81,155 次工具调用、超过 22 亿 token 与 589.32 小时累计执行时间，试验在隔离 Docker 容器中运行。
命令白名单使攻击成功率下降 48.1 个百分点而效用仅损失 1.5 个百分点，命令黑名单、路径限制与 MCP 权限分别使攻击成功率下降 40.4、48.1 和 28.1 个百分点并伴随 5.2、0.3 和 0.5 个百分点的效用提升；但案例显示被允许的解释器仍可绕过命令限制执行未授权检查器。 表明限制与合法任务共享的能力会同时压低攻击成功率与效用，而更精准针对有害操作的控制可在较小效用代价下降低攻击效果，同时揭示替代执行路径会留下残余攻击面。 配对 ON/OFF 比较与任务级案例（Dependency Lock Repair 中 Claude Code 效用由 96% 降至 76%、攻击成功率由 100% 降至 0；CLI Arg Parser 中 Qwen Code 在 CAL 开启下仍通过允许的 Python 解释器执行被拒检查器，六项效用检查与三项攻击检查全部通过）。
启示与展望
该结果面向使用编码智能体 harness 的开发者、安全评估者与 harness 提供方，适用于在隔离 Docker 容器中、以 GLM-5.2 为基座模型、按任务–harness–设置组合各 10 次试验的受控设置；机制分类与评级矩阵覆盖 40 个 harness（27 开源、13 闭源），运行时评估覆盖 Claude Code、Codex CLI、Gemini CLI、gptme、Qwen Code 与 GitHub Copilot 六款开源 harness 与九个机制。可直接复用的是任务包、效用检查与判据设计，用于在自身工作负载上比较机制开启与关闭时的攻击效果、任务效用与 token 与时间成本。
RQ3 仅使用单一基座模型 GLM-5.2，不同模型在工具使用与指令遵循上的差异可能影响绝对攻击成功率与 ON/OFF 差值幅度；自动批准关闭时的审批由固定的 LLM 审批者完成，模型偏差与残余非确定性可能影响个别审批决定；Docker 容器、自动化执行与模拟服务不能完全复现真实部署；闭源 harness 因交互方式差异（尤其 GUI 型 IDE 工作流）未纳入运行时评估；提示注入过滤仅 gptme 支持配对比较，其余单设置结果无法确立 ON/OFF 效应；RQ2 中 112 个单元仍为未决，其中闭源提示注入过滤全部未决，因此这些机制的实际覆盖范围仍是开放问题。