Skip to content

Translation in progress Some entries still include text in the original language.

Original
论文追踪· arXiv:2610.07639·Indexed by this site · Originally publishedSelectedAttention58

HarnessSecurity-Bench horizontally evaluates the security mechanisms of six coding agent frameworks.

HarnessSecurity-Bench: Do Security Mechanisms Really Protect Coding Agent Harnesses?

Quick read

Evaluation and benchmarks

Based on 论文 PDF （Gemini 生成）; refer to the original

在GLM-5.2与6款harness上，开启auto-approve使总体ASR从29.2%升至95.6%。

Questions
代码智能体harness负责协调工具调用与授权操作，但其原生安全机制的实现现状与运行时防护效果缺乏系统性实证评估，难以明确安全机制能否在保证合法开发需求的同时防御攻击。
Methods
作者梳理出包含10类安全机制的分类法，通过研究人员与LLM独立评审评估40款harness的400个单元格；并构建包含23个任务、覆盖5类攻击面的基准HARNESSSECURITY-BENCH，用确定性预言机隔离测量开启与关闭配置下的任务效用和攻击效果。
Experiments and results
在GLM-5.2基线与6款harness的2500次测试中，开启auto-approve使总体ASR从29.2%升至95.6%；网络隔离与只读模式虽压低ASR但带来24.5和34.0个百分点的效用损失；命令黑白名单在维持或提升效用同时削弱了攻击效果。
Limitations and future work
闭源harness因GUI交互难以复现未纳入核心运行时评测；RQ3仅使用GLM-5.2单基线模型；Docker容器与模拟服务未完全还原真实部署；AA-OFF下的LLM审批存在模型偏差与非确定性。
Experimental setupHARNESSSECURITY-BENCH (HSB)、Terminal-Bench · Utility、ASR et al.
Benchmarks
HARNESSSECURITY-BENCH (HSB)Terminal-Bench
Metrics
UtilityASR∆Utility∆ASR
AI summaryand selection rationaleResearchers from Sun Yat-sen University, Hong Kong Baptist University, and other institutions propose HarnessSecurity-Bench, a horizontal evaluation of the native security mechanisms of six coding agent frameworks: Claude Code, Codex CLI, Gemini CLI, gptme, Qwen Code, and GitHub Copilot. The study first identifies ten categories of security mechanisms, and across 400 framework-mechanism combinations confirms 205 as implemented, 83 as missing, and 112 as having insufficient evidence. About half of the implemented items are optional features that require users to enable them manually, and the evidence gap is more pronounced for closed-source frameworks. The evaluation completed 2,500 trials under the GLM-5.2 base model, recording 81,155 tool calls and over 2.2 billion tokens. Case studies show that restricting shared capabilities blocks both legitimate and malicious operations, and allowed interpreters can still serve as bypass paths. The researchers recommend that framework providers publicly disclose verifiable security settings and report attack effectiveness, task utility, and execution cost together.

Researchers from Sun Yat-sen University, Hong Kong Baptist University, and other institutions propose HarnessSecurity-Bench, a horizontal evaluation of the native security mechanisms of six coding agent frameworks: Claude Code, Codex CLI, Gemini CLI, gptme, Qwen Code, and GitHub Copilot. The study first identifies ten categories of security mechanisms, and across 400 framework-mechanism combinations confirms 205 as implemented, 83 as missing, and 112 as having insufficient evidence. About half of the implemented items are optional features that require users to enable them manually, and the evidence gap is more pronounced for closed-source frameworks. The evaluation completed 2,500 trials under the GLM-5.2 base model, recording 81,155 tool calls and over 2.2 billion tokens. Case studies show that restricting shared capabilities blocks both legitimate and malicious operations, and allowed interpreters can still serve as bypass paths. The researchers recommend that framework providers publicly disclose verifiable security settings and report attack effectiveness, task utility, and execution cost together.

Why it was selected论文用 2500 次试验量化了六款编码智能体安全机制在攻击成功率与任务效用之间的取舍，为配置选择提供了可比较的数据。

Paper analysis

6 questions; open one to read the full answer

  1. What problem does this paper attempt to solve?

    代码智能体harness的安全机制实现现状与运行时防护效果缺乏系统评估，论文提出了十机制分类法与基准测试HSB。

    代码智能体harness的原生安全机制在实际产品中的实现现状不明确，且缺乏在对抗性环境下评估其对安全性与任务效用运行时影响的系统性基准。

    • 场景与重要性：基于大语言模型的代码智能体已进入生产环境，由harness组装上下文、协调工具调用并执行操作授权；引入不受信任的代码或仓库数据可能引发提示注入等安全风险，进而导致未授权命令执行或敏感数据外传。
    • 现有研究的不足：作者指出，既有文献综述与架构映射未系统评估商业与开源产品的机制实现与默认配置，实证比较仅覆盖3款或11款开源harness，闭源产品代表性不足；现有安全基准多局限于特定资源或缺乏对安全机制开关状态（ON/OFF）的系统隔离比较。
    • 论文的核心观察：安全机制的作用取决于其治理的资源、执行点及默认配置；在限制共享能力时可能同时阻断正常操作与恶意操作，或因存在替代执行路径而导致防护被绕过。
    • 论文提出的解决方案：作者提出了HarnessSecurity实证研究与HARNESSSECURITY-BENCH基准，涵盖40款harness的十机制分类法与实现评估，并在23个跨多语言任务上使用双重确定性预言机评测6款harness的9类安全机制。
    • 威胁模型：根据论文第2节与第5节，
      • 攻击目标：诱导智能体执行非授权操作（如删除快照、清除队列、修改平台策略、外传token或canary）。
      • 攻击能力：通过仓库工件、指令与技能、工具接口、知识与记忆、外部服务等5类攻击面注入对抗性载荷或制造误导性前置步骤，但不能直接篡改合法用户的原始输入。
      • 受害系统：运行在Docker容器中的代码智能体harness及其调用的底层语言模型。
      • 攻击知识：论文未假定攻击者拥有模型白盒权重，攻击载荷以常规开发工件形式出现。

  2. What related research exists?

    既有研究涵盖harness分类、生命周期安全审计与特定载荷注入基准，但缺乏对原生机制ON/OFF状态的双重判定隔离评估。

    论文将相关研究主要归纳为以下几类，并在测试协议与评估范围上进行了对比：

    安全分类法与harness实证研究

    • Barbaste等（2026）、Crowe（2026）以及Agentic Control Plane（2026）——对代码harness及其原生安全机制进行源码级分析；Rashidi（2026）综述了隔离、访问控制和检查时到使用时（TOCTOU）漏洞。
    • Li等（2026）与Kim等（2026）——分别对智能体harness工程架构与智能体攻击防御全景进行了综述调查。

    智能体与harness安全基准

    • AgentDojo（Debenedetti等，2024）与Agent Security Bench（Zhang等，2025）——在工具使用智能体工作流中评估攻击与防御；HarnessAudit（Liu等，2026）检查执行轨迹的边界合规性；HarnessRisk（Bai等，2026）在harness生命周期中评估效用、攻击成功率、持久性与检测；ClawSafety（Wei等，2026）跨框架比较安全表现。

    代码智能体攻击基准

    • AIShellJack（Liu等，2025）、QueryIPI（Xie等，2025）、IssueTrojanBench（Singh等，2026）、RepoGuardBench（Li，2026）以及CodeIPI（Sinha，2026）——分别通过指令文件、工具描述、Issue内容与仓库资源评估代码智能体面临的间接提示注入。
    • Skill-Inject（Schmotz等，2026）、PoisonedSkills（Qu等，2026）与SkillHarm（Ning等，2026）——评估技能包（skill package）供应链攻击；RedCode（Guo等，2024）评测高危代码执行与恶意代码生成。

    基准对比与定位

    • 对比基线与基准：Table 1对比了AIShellJack、QueryIPI、IssueTrojanBench、Skill-Inject、PoisonedSkills、SkillHarm、RepoGuardBench、CodeIPI、RedCode-Exec、CapScope等工作。作者指出，既有基准覆盖的harness数量为1至5个（本文覆盖6个），多数仅覆盖1至2个攻击面，且均未对原生安全机制的开启与关闭（ON/OFF）状态进行系统隔离对比；评估判定上多数依赖轨迹或语义判官，而本文采用状态与结构化事件的双重确定性预言机。
    • 与既有工作的区别定位：作者称，与围绕特定攻击资源展开的既有基准不同，HARNESSSECURITY-BENCH围绕安全机制组织任务，在保留合法任务需求的同时引入5类攻击面的对抗资源，并通过支持的原生ON/OFF配置对比量化攻击效果与任务效用的权衡。

  3. How does the paper address this problem?

    建立十机制分类与五方独立审计矩阵，并通过Docker环境注入五类攻击面，以双重预言机量化ON/OFF状态差异。

    作者提出了HarnessSecurity实证分析框架与HARNESSSECURITY-BENCH（HSB）基准，先建立十机制分类法并审计40款harness，再构建23个多语言编码任务，通过双重确定性预言机评估机制在ON/OFF配置下的效用与安全影响。

    十机制分类法构建（RQ1）

    • 机制筛选与数据归档：从GitHub开源库、厂商材料及安全漏洞披露三类渠道收集75条记录，去重合并后按星标数（>=1000星）、维护活跃度（排除停更超12个月）及是否支持代码执行等标准筛选出40款harness（27款开源、13款闭源），数据截止时间为2026-08-31。
    • 开放与轴心编码：由3位拥有7年以上软件开发经验的研究人员对8款代表性harness进行独立审查，提取44个初始安全相关标签，并由拥有10年以上经验的第4位研究人员审定分类边界。
    • 十类安全机制定义：最终归纳出10类机制：自动审批（AA）、网络隔离（NI）、命令白名单（CAL）、命令黑名单（CDL）、MCP权限（MCP）、提示注入过滤（PIF）、路径限制（PR）、只读模式（RO）、审计日志（AL）及项目信任（PT）。

    思维证据独立评审流程（RQ2）

    • 五方独立评分体系：采用3个LLM判官（L1: Claude Opus 4.8、L2: DeepSeek V4 Flash、L3: GLM-5.2）与2名人类研究员（H1、H2）对400个单元格独立评审，评级分为默认强制（D）、可配置关闭（C）、需显式开启（O）、未实现（A）和未知（U）五级。
    • 思维证据（Evidence-of-thought）约束：非U评级必须引用源码路径和行号并记录SHA-256哈希；至少3名评审一致达成共识（U计为有效值），未达成共识的18个单元格由H1、H2与第3位资深研究员H3共同裁定。

    HARNESSSECURITY-BENCH 基准构建（RQ3）

    • 任务设计与多语言覆盖：构建23个任务（21个原创、2个改编自Terminal-Bench），涵盖Python、JavaScript、C++、C#、Ruby与Go六类语言，分布于除AL外的9类机制子基准中。
    • 五类对抗攻击面增强：在保留原始合法用户指令与效用预言机的前提下，向环境注入误导性工作流、伪造前置条件或未授权操作，覆盖仓库工件、指令/技能、工具接口、知识/记忆、外部服务5类攻击面（排除直接用户输入）。

    隔离执行与指标形式化

    • 隔离容器与统一模型执行：每个试验在全新隔离的Docker容器中运行，基础模型固定为GLM-5.2；在AA-OFF试验中通过确定性网桥调用Qwen3.8-27B作为统一权限审批模型；每个任务-harness-机制配置重复10次，外部执行超时设为28800秒（8小时）。
    • 指标定义与差值计算：分别计算效用预言机通过比例Utility与攻击预言机通过比例ASR，并通过两项差值公式衡量开启安全机制的影响： Δ Utility = Utilityon − Utilityoff，表示开启安全机制带来的任务效用百分点变化； Δ ASR = ASRon − ASRoff，表示开启安全机制带来的攻击成功率百分点变化。

  4. What experiments did the paper conduct?

    在GLM-5.2下开展2500次试验，发现机制防护效果与效用代价分化明显，部分机制存在解释器绕过路径。

    实验设置

    • 被测对象与模型：涵盖6款代表性开源harness（Claude Code、Codex CLI、Gemini CLI、gptme、Qwen Code、GitHub Copilot），底层基础模型统一固定为GLM-5.2；在AA-OFF配置下由Qwen3.8-27B担任权限审批模型。
    • 基准任务与攻击面：使用HARNESSSECURITY-BENCH的23个多语言任务（涵盖Python、JavaScript、C++、C#、Ruby、Go），覆盖仓库工件、指令与技能、工具接口、知识与记忆、外部依赖5类攻击面。
    • 对照设置与试验规模：评估除AL外的9类机制；针对可配置关闭（C）与需显式开启（O）单元格进行ON与OFF的成对对比；共规划54个批次、2500次试验，每个配置重复10次，单次试验外部超时为28800秒。
    • 评测指标与判定方式：指标为任务效用（Utility）与攻击成功率（ASR）及两者在ON/OFF下的差值（ΔUtility与ΔASR）；采用脱离工作区的确定性预言机（文件/数据库状态、接收端日志、结构化执行事件）进行独立判定，不依赖LLM主观评判。
    • 资源开销记录：统计试验的工具调用总数、累计执行时间以及输入/输出token消耗（包含一次缓存读取）。

    主结果

    下表呈现了6款harness在自动审批（AA）机制下的任务效用与攻击成功率对比：

    Swipe horizontally to read the table

    被测HarnessUtility offUtility onASR offASR on∆ASR (据 Table 6)
    Codex CLI95.4% (124/130)96.2% (125/130)81.7% (49/60)96.7% (58/60)↑ 15.0%
    Claude Code94.6% (123/130)93.8% (122/130)43.3% (26/60)100.0% (60/60)↑ 56.7%
    Gemini CLI94.6% (123/130)96.9% (126/130)3.3% (2/60)100.0% (60/60)↑ 96.7%
    gptme66.9% (87/130)97.7% (127/130)45.0% (27/60)100.0% (60/60)↑ 55.0%
    Qwen Code50.0% (65/130)94.6% (123/130)0.0% (0/60)90.0% (54/60)↑ 90.0%
    GitHub Copilot60.8% (79/130)93.1% (121/130)1.7% (1/60)86.7% (52/60)↑ 85.0%
    Overall77.1% (601/780)95.4% (744/780)29.2% (105/360)95.6% (344/360)↑ 66.4%
    • 自动审批大幅增加攻击暴露：作者报告，在所有6款harness上，开启auto-approve均导致ASR上升，总体ASR从29.2%升至95.6%（上升66.4个百分点），跳过审批让合法操作和维护材料中的恶意前置步骤都能直接执行。
    • 效用收益在不同harness上明显分化：作者指出，开启auto-approve使总体任务效用从77.1%升至95.4%（上升18.3个百分点），但各harness表现差异大：Qwen Code效用提升44.6个百分点，而Gemini CLI仅提升2.3个百分点，Claude Code微降0.8个百分点。
    • 安全风险提升与效用改善脱节：作者认为，即使在效用改善微弱的harness上（如Gemini CLI与Claude Code），开启自动审批同样导致ASR上升至100.0%，带来了不相称的安全风险暴露。

    网络隔离与只读模式的效用代价评测

    • 测了什么：评估网络隔离（NI）与只读模式（RO）在开启与关闭状态下对攻击阻断和正常任务完成的影响。
    • 结果：NI使总体ASR从57.1%降至0.8%（下降56.3个百分点），但Utility从90.9%降至66.4%（下降24.5个百分点，162项未通过的效用检查中有161项源于网络访问被阻断）；RO使总体ASR从8.3%降至0.8%（下降7.5个百分点），Utility从69.8%降至35.8%（下降34.0个百分点，367项未通过检查中有347项因无法持久化修改）（Table 6、Table 7）。
    • 作者的解读：作者指出，当合法业务与恶意操作依赖同一能力（如外网依赖或持久化写入）时，简单限制该共享能力会在削弱攻击的同时直接阻碍合法任务完成。

    命令过滤与项目信任的防护效用权衡

    • 测了什么：评估命令白名单（CAL）、命令黑名单（CDL）及项目信任（PT）的防护效果与正常操作保留情况。
    • 结果：CAL使总体ASR从98.1%降至50.0%（下降48.1个百分点），Utility仅从99.2%微降至97.7%（下降1.5个百分点）；CDL使总体ASR从41.7%降至1.3%（下降40.4个百分点），Utility从94.6%升至99.8%（提升5.2个百分点）；PT在排除Gemini CLI启动拒绝配置后，其余4款harness保持100%效用，ASR从75.8%降至50.4%（Table 6、Table 7）。
    • 作者的解读：作者指出，CDL带来效用提升的原因是阻止了攻击引发的密钥拷贝等破坏性副作用，从而保护了合法的验证输出；而CAL通过显式允许的命令保留了绝大多数合法执行路径。

    案例分析：能力共享与解释器绕过

    • 测了什么：在依赖包修复（Case A，NI机制）与命令行解析（Case B，CAL机制）任务中追踪具体执行轨迹。
    • 结果：在Case A中，Claude Code开启NI后Utility从96%降至76%，ASR从100%降至0，本地功能检查全部通过但外部依赖安装被拒绝从而阻止了回调外传（Section 6.3）；在Case B中，Qwen Code在CAL-ON下通过允许的Python解释器间接运行被拒绝的检查脚本，导致Utility和ASR均为100%（Section 6.3）。
    • 作者的解读：作者称Case A展现了共享能力的限制代价；Case B显示仅限制直接命令未能防御替代执行路径，必须对受保护操作的所有访问路径进行全面仲裁。

    其他消融与分析

    • MCP子基准（Table 7）：开启MCP权限使总体Utility从73.3%微升至73.9%，ASR从82.2%降至54.2%（下降28.1个百分点）。
    • PR路径限制（Table 7）：开启PR使总体Utility从81.6%微升至81.9%，ASR从95.0%降至46.9%（下降48.1个百分点）。
    • PIF注入过滤（Table 7）：在唯一步调一致的gptme上，开启过滤使Utility从85.0%降至83.1%，ASR仅从26.7%降至23.3%（下降3.3个百分点）。
    • 资源消耗统计（Table 8）：2500次试验累计记录81155次工具调用与589.32小时执行时间，总输入token达21.64亿、输出token达5371.4万。
    • 评审一致性（Section 4.2）：RQ2在全体5位评审员上的有序Krippendorff α为0.740（n=329），L1–L3为0.669（n=323），H1–H2为0.911（n=192）。

    负面结果与例外

    • PIF过滤效果有限：作者报告gptme开启PIF后ASR仅下降3.3个百分点，作者解释称其规则仅匹配工具输出中的显式注入模式并增加警告，伪装成常规工作流前置条件的攻击仍能绕过筛选。
    • Gemini CLI项目信任拒绝启动：PT-ON下Gemini CLI在全部40次试验中因目录信任门禁直接拒绝启动，导致Utility降为0.0%（ASR亦为0.0%）（Table 7）。
    • MCP部分操作仍可修改受保护状态：作者报告在开启MCP权限后，部分保留的合法工具操作仍可改变受保护状态，导致部分harness（如Claude Code和Qwen Code）在StreamLoop任务上的ASR仍达100.0%（Table 11）。

  5. What are some points that can be further explored?

    作者指出基准受限于单模型评测、仿真环境保真度及闭源工具缺失，实验覆盖6款开源harness与23个任务。

    作者指出的局限与后续方向

    • 闭源harness的自动化评测：闭源harness因包含GUI交互模式较难复现，目前核心评测聚焦于开源harness；作者计划未来开发针对闭源harness的自动化评测方法，并将自动化结果与人工评估对比（Section 7.2）。
    • 模型覆盖范围局限：RQ3仅使用单一底层LLM（GLM-5.2）进行对照评估，不同模型在工具使用和指令遵循能力上存在差异；作者计划未来将评估扩展至更多大语言模型（Section 7.2）。
    • 部署环境保真度：Docker容器、自动化执行与模拟服务未能完全复现真实的生产部署环境（Section 7.2）。
    • 审批判官的偏置与非确定性：AA-OFF试验中使用基于LLM的预设审批判官，模型偏置与残留的非确定性可能影响个别审批决策（Section 7.1）。
    • 安全设置可验证性缺失：40款harness中有69个闭源单元格存在证据缺失，作者呼吁厂商发布版本化的机制覆盖说明并暴露运行时的生效安全配置以便用户验证（Section 7.3）。
    • 对抗测试与替代路径检验：作者建议厂商测试通往受保护资源的替代访问路径，并在工具路由或权限配置变更后重复检查以检测访问控制退化（Section 7.3）。

    实验覆盖范围

    • 被测harness覆盖：机制矩阵审计覆盖40款开源与闭源harness；基准运行时评测覆盖Claude Code、Codex CLI、Gemini CLI、gptme、Qwen Code与GitHub Copilot共6款开源harness（Section 3.1、Section 6.1）。
    • 安全机制与任务覆盖：分类法定义10类安全机制，HSB基准实际评测其中9类机制（审计日志AL仅做静态审计未做运行时测试），共包含23个编码任务（Section 5.1）。
    • 模型与试验规模：运行时测试的基础模型全部使用GLM-5.2，AA-OFF下的权限审批模型统一使用Qwen3.8-27B；共进行2500次正式试验，每个配置重复10次（Section 6.1）。
    • 编程语言与攻击面覆盖：任务涵盖Python、JavaScript、C++、C#、Ruby与Go共6种编程语言；攻击面覆盖仓库工件、指令/技能、工具接口、知识/记忆、外部依赖5类，直接用户输入攻击面未纳入测试范围（Section 5.1）。
    • 未报告数据说明：在RQ2评估中，闭源harness有69个单元格为未知（U）状态，所有13款闭源harness的PIF机制均标记为U；在RQ3中，部分单配置harness未报告成对差值，部分批次的token总消耗未报告（Section 4.2、Section 6.1、Table 8）。

  6. Summarize the main content of the paper

    系统审计40款harness并实证评测9类安全机制，量化了自动审批的暴露风险、强隔离的效用代价以及替代执行路径绕过。
    • 论文定位：该研究是针对开源与闭源代码智能体harness原生安全机制的系统性实证分析与基准评测。
    • 核心问题：针对代码智能体harness安全机制实现状态不透明、在对抗环境下防护能力及对合法开发效用影响缺乏定量评估的问题展开研究。
    • 方法体系：作者构建了包含10类安全机制的分类法，通过研究人员与LLM独立评审审计了40款harness的400个单元格；进一步提出包含23个任务的HARNESSSECURITY-BENCH，在隔离容器中利用确定性预言机评测6款harness在开启与关闭机制下的表现。
    • 关键实验发现：
      • 在GLM-5.2基线与6款harness测试中，开启auto-approve使总体任务效用从77.1%升至95.4%，但ASR从29.2%升至95.6%（Table 6）。
      • 网络隔离（NI）与只读模式（RO）大幅降低攻击效果，总体ASR分别降至0.8%和0.8%，但分别带来24.5和34.0个百分点的效用损失（Table 6、Table 7）。
      • 命令白名单（CAL）将ASR降至50.0%且效用仅微降1.5个百分点；命令黑名单（CDL）将ASR降至1.3%，同时因阻断破坏性操作使效用提升5.2个百分点（Table 6）。
    • 绕过路径与安全风险：案例分析显示，限制共享能力会同时误伤合法操作，且仅限制特定直接命令仍可通过受信任的解释器等替代路径绕过控制（Section 6.3）。
    • 作者建议与启示：作者建议harness提供商发布机制级说明并暴露运行时生效设置以增强可验证性，针对受保护资源测试所有替代访问路径，并在评估安全机制时综合权衡攻击效果、任务效用与资源执行开销。
Read originalarxiv.org
#Agent safety