40 款 Coding Agent 的十大安全机制

当我们讨论 Coding Agent 的安全性时，通常首先想到的是 Prompt Injection（提示注入）、恶意代码执行、敏感信息泄露等问题。

但如果真正使用过 Claude Code、Codex、Gemini CLI 这样的工具，就会发现一个有意思的现象：即使使用相同的大模型，不同 Coding Agent 的安全表现也可能有很大差异。

有些 Agent 在执行 Shell 命令之前会要求用户确认，有些可以开启完全自动授权；有些能够限制 Agent 访问的文件目录，有些则依赖容器沙箱；还有一些产品能够检测外部文档中的恶意指令，或者根据项目是否可信决定加载哪些配置。

这些看似分散的安全能力，究竟可以归纳成多少种机制？目前主流的 Coding Agent 实现了哪些？它们真的能够阻止攻击吗？

2026 年 10 月，中山大学、鹏城实验室等研究机构发布了一篇论文《HarnessSecurity-Bench: Do Security Mechanisms Really Protect Coding Agent Harnesses?》，尝试系统回答这些问题。

论文原文（arXiv）

研究团队首先调查了 40 款 Coding Agent，归纳出十大安全机制，然后对每款产品的机制实现情况、默认配置以及可验证性进行分析。最后选择其中 6 款产品，在 23 个编程任务中执行了 2,500 次实验，观察不同安全机制开启与关闭时的实际效果。

https://tsingpig.github.io/HarnessSecurity-Benchmark/

研究结果并不完全符合我们的直觉。例如，40 款产品中，能够确认实现提示注入过滤的只有 4 款；自动授权虽然可以明显提升正常任务的完成情况，却可能将攻击成功率从 29.2% 提升到 95.6%；网络隔离虽然可以大幅减少攻击效果，但也可能让许多正常开发任务无法完成。

这篇论文最有价值的地方，并不是简单告诉我们哪款 Agent 最安全，而是首次将大量 Coding Agent 的原生安全能力放进统一的分类和验证框架，让我们能够从机制实现、默认状态和实际效果三个层面重新认识 Agent 安全。

40 款 Coding Agent，究竟有哪些？

在介绍十大安全机制之前，首先需要明确这项研究调查了哪些产品。

论文的研究对象严格来说是 Coding Agent Harness，也就是 Coding Agent 的运行框架。它负责组织模型上下文、管理工具调用、执行命令、处理权限审批以及维护运行状态。

一个完整的 Coding Agent 通常包含大模型与 Harness 两部分。模型负责规划下一步操作，Harness 则负责将模型的行动落实到实际开发环境中。

例如，当 Codex 决定执行某条 Shell 命令时，最终是否允许执行、是否需要审批、可以访问哪些文件以及能否连接网络，主要由 Harness 和相关执行环境决定。

研究人员从 GitHub 开源项目、商业产品文档以及已公开的安全事件中收集了 75 条候选记录，去除重复后得到 56 个候选产品。经过维护状态、产品能力和资料可获得性等条件筛选，最终保留了 40 款 Coding Agent。

这些产品按照源码可访问性划分为两组，并根据交互方式分为 CLI、IDE 插件、IDE 和平台四种形态。

1. 27 款源码可访问的 Coding Agent

注：以上分类直接遵循论文 Table 2。作者将 Claude Code 和 GitHub Copilot 纳入源码可访问组，是因为研究使用了能够获取的实现材料。其中 Claude Code 使用了从 npm Source Map 恢复的非官方源码镜像，GitHub Copilot 使用了 VS Code 官方仓库中的相关代码。这并不意味着两款商业产品的完整实现均以开源许可证公开。

这 27 款产品覆盖了 Coding Agent 的多种典型实现方式。

CLI 类产品通常以终端为主要交互入口，直接操作本地文件、命令行和开发工具。Claude Code、Codex CLI、Gemini CLI、Qwen Code 等都属于这一类。它们与操作系统的交互非常直接，因此命令执行、文件访问和网络权限是重要的安全控制对象。

IDE 插件则嵌入现有开发工具，通过编辑器提供代码阅读、生成、修改和调试能力。Cline、Roo Code、Continue 等属于这一类。除了 Agent 自身的权限机制，它们还受到 IDE 插件接口和编辑器权限环境的影响。

IDE 类产品将 Agent 能力更深入地整合进开发环境，而平台类产品则可能进一步涉及云端工作区、容器隔离、远程执行和任务调度。

这意味着不同形态的 Coding Agent，其安全机制的实现位置也可能不同。CLI 产品可以在命令执行之前进行拦截，IDE 产品可以利用编辑器的工作区边界，而云端平台通常还需要考虑容器、网络和租户隔离。

2. 13 款闭源 Coding Agent

上述分类同样依据论文的研究口径，反映的是作者截至 2026 年 8 月 31 日收集的产品资料，而不应直接理解为所有产品当前版本的完整功能描述。

这里有一个值得关注的问题：闭源产品在安全能力可验证性方面，往往面临更大的困难。

例如，某款商业 Agent 可能宣称自己具备沙箱隔离和 Prompt Injection 防护，但外部研究人员未必能够确认它使用了什么防御策略、覆盖哪些攻击入口，以及默认是否开启。

因此，作者没有把“文档没有提到某项能力”直接等同于“产品没有实现”，而是专门设置了一个“未知”类别。

这种区分对于企业级安全评估尤为重要。安全能力存在、安全能力默认生效，以及安全能力能够被独立验证，是三个不同的问题。

十大安全机制

研究人员首先选择 8 款代表性 Coding Agent，通过分析源码、产品文档、CLI 参数和配置文件，提取安全相关的功能标签。

随后将分析范围扩展到剩余 32 款产品，对功能标签进行合并、细化和归类，最终形成了十大安全机制。

这十类机制覆盖了 Agent 从读取上下文、规划行动、授权、执行到记录结果的整个运行过程。

它们并不处于同一层次。例如，提示注入过滤主要处理低可信内容，项目可信状态控制项目资源加载，命令和 MCP 权限负责操作授权，网络隔离与路径限制约束执行环境，审计日志则用于事后追溯。

下面逐一解释它们的工作原理、典型实现方式以及可能存在的安全边界。

1. 自动授权（Auto-Approve，AA）：让 Agent 不再事事请示

自动授权是一种放宽操作审批限制的运行模式。

以 Coding Agent 为例，模型可能需要执行命令、修改文件或者调用外部工具。正常情况下，Harness 可以在操作执行之前要求用户批准。但如果开启自动授权，这些确认过程就可能被跳过。

例如，Codex CLI 可以通过 approval_policy=“never” 配置不再请求交互式审批，而使用 approval_policy=“on-request” 时，则允许根据需要发起审批请求。

类似能力也经常被称为 Full Auto、YOLO Mode 等。

它最大的价值是提升自动化程度。对于需要长时间运行、反复修改代码、执行测试的 Agent 来说，减少审批中断往往可以改善任务连续性。

但需要注意，自动授权本身不是防御机制，而是一种风险能力。

因为它取消的不只是正常操作的确认门槛，也可能包括恶意操作原本需要经过的审批。

如果攻击者通过项目文档诱导 Agent 执行额外命令，自动授权可能让这些操作直接进入执行阶段。

因此，自动授权是否安全，取决于 Agent 的执行权限是否已经被其他机制严格约束。在完全隔离的临时测试环境中，它可能是合理选择；但如果 Agent 能够访问真实凭证、生产环境或敏感文件，完全自动授权就需要更加谨慎。

论文调查发现，40 款产品中有 30 款确认具备自动授权能力，其中 26 款需要主动开启。

2. 网络隔离（Network Isolation，NI）：限制 Agent 与外界通信

网络隔离主要用于控制 Agent 或其执行环境能够连接哪些网络资源。

最简单的实现方式是完全禁止出站网络访问，更灵活的方案则是默认拒绝，只允许访问指定域名、服务或网络地址。

例如，在 Codex CLI 的特定工作区沙箱配置中，可以通过 sandbox_workspace_write.network_access=false 禁止网络访问。

这种机制主要保护两类安全目标。

第一类是防止敏感数据外传。即使 Agent 被恶意文档诱导读取了某些敏感信息，如果执行环境无法连接攻击者控制的服务器，数据仍然可能被限制在本地。

第二类是减少外部依赖带来的风险。例如，Agent 在安装软件包、下载脚本或者执行构建命令时，可能接触恶意依赖。如果相关网络访问被限制，就能够减少这类风险暴露。

不过，网络隔离也是一项典型的粗粒度控制措施。

Coding Agent 的正常工作往往需要下载依赖、访问代码仓库、调用 API 或查询在线文档。如果简单关闭所有网络访问，就可能同时阻止正常开发任务。

因此，网络隔离不只是一个开关问题，更需要考虑哪些访问属于业务必需、哪些访问需要限制，以及是否能够通过受控代理或允许列表实现精细化授权。

在论文中，15 款产品能够确认实现网络隔离，16 款确认缺失，另有 9 款无法确定。

3. 命令白名单（Command Allowlisting，CAL）：只允许执行指定命令

命令白名单的基本逻辑是：系统预先定义允许执行的命令或命令模式，不在名单中的命令需要额外审批，或者直接被拒绝。

例如，某个 Agent 可以运行 git status、pytest 和 npm test，但不能直接执行未被授权的其他程序。

需要注意，并不是所有白名单都采用严格的默认拒绝模式。某些实现只是让白名单命令免于人工确认，而不匹配的命令仍然可以通过审批执行。

相比完全禁止命令执行，白名单可以保留正常任务需要的开发工具，理论上能够在安全性与实用性之间取得更好的平衡。

但它也存在一个容易被忽略的问题：命令名称不等于最终操作能力。

例如，系统禁止直接运行某个程序，但允许 Agent 调用 Python 解释器。如果 Python 解释器仍然能够执行该程序，原本被限制的操作就可能通过另一条路径重新变得可达。

因此，命令白名单适合约束常规工具调用，却不能替代底层文件权限、网络权限和进程隔离。

论文中有 18 款产品确认实现了命令白名单。

4. 命令黑名单（Command Denylisting，CDL）：阻止已知危险命令

命令黑名单与白名单采取相反的策略。

它默认允许命令执行，但对已知危险命令或者命令模式进行限制。

例如，可以禁止删除类命令、未经授权的系统配置修改，或者具有明显危险特征的命令组合。

论文以 Claude Code 的 —disallowedTools 配置作为示例，说明 Harness 可以通过工具规则限制特定 Shell 命令模式。

这种机制的优势是部署相对简单，对正常开发工作的影响通常较小。企业可以根据已有风险经验，优先限制高危操作。

但黑名单存在天然局限：它只能覆盖已经定义的危险模式。

同一个高风险操作可能通过不同命令、脚本语言或工具实现。即使系统禁止某种删除命令，Agent 也可能通过其他文件操作接口删除相同内容。

因此，黑名单通常更适合作为额外限制层，而不应成为 Agent 的唯一权限边界。

论文中有 24 款产品确认实现命令黑名单。

5. MCP 权限（MCP Permissions）：管理 Agent 的外部工具能力

随着 MCP 的普及，Coding Agent 不再局限于读取本地文件和执行 Shell 命令，还可以通过 MCP Server 访问数据库、知识库、代码平台以及各种企业服务。

这意味着 Agent 能够触达的外部资源越来越多。

MCP 权限机制主要解决的问题是：哪些 MCP Server 可以被连接，哪些工具可以被调用，以及调用是否需要授权。

例如，Codex CLI 可以通过允许的工具集合与默认工具审批策略，对 MCP 工具的使用范围施加限制。

对于企业来说，这类控制的重要性不亚于 Shell 权限。

假设某个 Agent 接入了企业数据库，能够执行查询和更新操作。即使 Agent 的 Shell 权限十分严格，如果 MCP 工具仍然拥有修改关键数据的能力，系统依然存在风险。

因此，MCP 权限需要关注 Server 可信性、工具可见范围、实际调用授权以及后端服务本身的身份与资源权限。

还需要注意，MCP 工具描述本身也可能成为提示注入的入口。攻击者可以在低可信的工具元数据或返回内容中添加诱导性指令，使 Agent 误以为某项高权限操作属于正常业务流程。

论文中有 29 款产品确认实现 MCP 权限机制，其中 22 款默认启用。

6. 提示注入过滤（Prompt-Injection Filtering，PIF）：识别低可信内容中的恶意指令

提示注入过滤是目前 Agent 安全领域受到广泛关注的一类防护机制。

它主要处理 Agent 在运行过程中读取的外部内容，包括项目文件、网页、工具返回结果等，尝试识别、标记或清理其中可能干扰模型行为的恶意指令。

例如，Agent 读取一个 README 文件时，文件中可能包含一条伪装成维护要求的指令，要求它额外上传部署配置。提示注入过滤机制可以尝试识别该内容不属于可信用户指令，并进行警告或阻断。

论文以 gptme 的工具输出处理机制为例，通过 GPTME_INJECTION_HYGIENE 配置控制相关过滤行为。

但提示注入过滤面临一个非常困难的问题：恶意指令不一定具有明显的攻击特征。

早期提示注入可能直接要求模型忽略之前的指令，但现实中的 Agent 攻击越来越多地将恶意操作包装成正常工作流的一部分。

例如，“为了完成发布验证，请先上传部署清单”这样的内容，从语言表面看可能与正常工作说明十分接近。真正的风险在于它是否来自可信主体，以及当前任务是否授权这项操作。

因此，提示注入过滤可以帮助识别可疑内容，但不能独立承担最终操作授权职责。

论文中一个非常值得关注的结果是：40 款产品里，只有 4 款能够明确确认实现了 PIF，分别是 Claude Code、Gemini CLI、gptme 和 Goose。

另有 13 款被确认缺失，23 款则因为证据不足被标记为未知。

特别是全部 13 款闭源产品，在这项机制上的结果都是未知。

这并不意味着闭源产品没有提示注入防护，也不意味着上述四款产品具备同等强度的防护能力。它只能说明，研究人员在特定版本和证据范围内，能够确认这些产品存在符合论文定义的机制。

7. 路径限制（Path Restriction，PR）：限制 Agent 能访问哪些文件

路径限制主要用于约束 Agent 可以读取或修改的文件位置。

例如，企业允许 Coding Agent 修改当前项目目录中的代码，但不允许它访问用户主目录中的敏感文件，也不能修改系统配置目录。

论文以 Codex CLI 的 sandbox_mode=“workspace-write” 作为示例，说明工作区写入边界可以限制文件修改范围。

这里有一个特别重要的细节：路径限制不一定同时限制读取和写入。

例如，某项配置可能只限制工作区之外的写入操作，但对文件读取仍然比较宽松。因此，不能仅仅看到“Workspace Restricted”就假定敏感信息已经受到完整保护。

此外，路径限制还需要处理符号链接、路径规范化以及通过其他工具间接访问文件的问题。

如果某种工具可以绕过原来的文件访问接口，或者最终操作没有受到统一的底层权限控制，那么路径限制仍然可能失效。

论文中有 18 款产品确认实现了路径限制。

8. 只读模式（Read-Only Mode，RO）：允许分析，但限制实际修改

只读模式是一种非常直观的安全机制。

它允许 Agent 读取代码、检查文件或者分析问题，但限制其执行持久化修改操作。

例如，在 Codex CLI 中，可以使用 sandbox_mode=“read-only” 限制写入能力。

除了严格的只读沙箱，一些产品中的 Plan Mode、Preview Mode 等也可能承担类似职责，但具体覆盖范围并不完全相同。

只读模式特别适合代码审计、方案分析、文档理解等无需修改工作环境的任务。

但对于自动修复 Bug、修改代码或者执行部署的 Agent 来说，如果所有修改操作都被禁止，就很难完成正常任务。

因此，只读模式不应该简单地被视为比可写模式更安全、更先进，而应该根据 Agent 的业务职责来决定是否使用。

论文中有 31 款产品确认实现了只读模式，其中 30 款需要用户主动开启，是十大机制中覆盖率最高的一类。

9. 审计日志（Audit Logging，AL）：让 Agent 的操作能够被追溯

审计日志与其他机制有所不同。

它通常不会直接阻止某个操作，而是记录 Agent 执行过程中的关键事件，例如工具调用、权限审批、命令执行以及相关的安全决策。

论文以 Qwen Code 的会话记录配置为例，展示了如何启用相应的执行记录能力。

对于企业而言，审计日志非常重要。因为当 Agent 的执行结果不符合预期时，仅仅查看最终回复通常不足以判断问题发生在哪里。

企业需要知道 Agent 读取了哪些内容、在什么上下文中决定调用工具、执行了什么命令、权限检查是否发生，以及最终修改了哪些资源。

这些信息不仅用于安全事件调查，也可以帮助定位权限策略失效、分析防御误拦截，以及改进后续评测。

但审计日志本身也有工程要求，例如记录完整性、敏感信息脱敏、日志防篡改和跨系统操作关联。只有记录了真正影响安全结果的事件，审计才具有实际意义。

论文中有 22 款产品确认实现审计日志，其中 20 款默认启用。

需要特别指出的是，作者虽然将 AL 纳入十大机制分类和实现情况调查，但没有将它纳入后续九类机制的运行时攻防实验。这是因为审计日志主要提供事后追溯能力，而论文的运行实验重点是任务效用和攻击执行效果。

10. 项目可信状态（Project Trust，PT）：不是每个代码仓库都值得信任

最后一类机制是项目可信状态。

它主要解决的是：Agent 是否应该自动加载当前代码仓库提供的配置、指令和可执行资源。

在 Coding Agent 中，项目目录里除了源代码，还可能包含 AGENTS.md、工具配置文件、Skills、项目级指令以及其他影响 Agent 行为的内容。

这些资源可能非常有用，但并不一定可信。

假设用户从互联网下载了一个陌生代码仓库，其中的项目指令要求 Agent 在启动时执行额外命令。如果 Agent 不加区分地加载并遵循这些内容，攻击者就可能通过控制仓库文件影响 Agent 的行为。

项目可信状态机制允许 Harness 根据工作区是否可信，决定哪些项目资源能够被加载、哪些配置需要忽略，以及哪些操作必须额外审批。

论文以 Codex CLI 的项目 trust_level 配置为例，说明可以通过可信与不可信两种状态进行控制。

这类机制与提示注入过滤之间存在明显差异。

提示注入过滤主要尝试识别内容是否具有恶意指令特征，而项目可信状态首先判断资源来源是否值得授予相应权限。

换句话说，它并不一定需要理解每条项目指令的具体含义，就可以决定某些低可信资源不能自动进入高权限执行链路。

但项目可信状态也不意味着可信项目里的所有内容永远安全。即使仓库本身可信，其依赖、工具返回和后来新增的文件仍然可能受到污染。

论文中有 14 款产品确认实现了项目可信状态机制。

40 款产品的安全机制实现情况

介绍完十大机制后，再回头看 40 款产品的整体实现情况，就会发现一些有意思的规律。

论文对每一款产品和每一类机制分别进行检查，共得到 400 项检查结果。

对于全部 400 个“框架–安全机制”组合，研究采用以下五种评级：

D（Default-enforced，默认强制启用）：该安全机制已实现，且默认启用，用户无法通过配置选项或命令行参数将其关闭。 C（Configurable-off，可配置关闭）：该安全机制已实现，且默认启用，但用户可以通过配置选项或命令行参数将其关闭。 O（Opt-in，需主动启用）：该安全机制已实现，但默认不启用，需要用户显式开启。 A（Absent，未实现）：有明确证据表明，该框架未实现相应的安全机制。 U（Unknown，未知）：现有证据不足或存在相互矛盾的信息，无法确定该安全机制是否已实现，或无法确认其默认启用状态。

其中，D 和 C 都意味着安全机制默认处于启用状态，两者的核心区别在于用户能否主动关闭该机制。而 O 虽然表示框架具备相应的安全能力，但由于需要用户主动配置，因此不能将其视为默认生效的安全保护。

需要特别注意，A 与 U 并不等价：A 表示有证据确认未实现，而 U 仅表示证据不足，不能据此认定该安全机制不存在。

为了降低主观判断偏差，研究团队安排三个人工研究者与三个大模型参与评分和争议处理。初始阶段由两名人工研究者和三个大模型独立给出判断，并要求提供能够追溯的证据，随后由人工仲裁存在争议的结果。

最终，400 项检查中有 205 项确认实现，占 51.3%；83 项确认缺失，占 20.8%；112 项无法确定，占 28.0%。

数据依据论文 Table 4 逐项汇总；每项机制的三列数字之和为 40。

这张图可以得出三个重要观察。

首先，自动授权、只读模式和 MCP 权限已经是覆盖较广的能力。它们直接决定 Agent 能否顺利完成开发任务，因此也更容易受到产品开发者关注。

其次，网络隔离、路径限制和项目可信状态的覆盖程度没有想象中高。这些能力往往与沙箱、文件系统、网络架构及执行环境密切相关，可能涉及比模型提示词或工具审批更复杂的工程实现。

最后，提示注入过滤在公开可验证性方面存在明显缺口。只有 4 项确认实现，23 项仍然处于未知状态。

但需要强调，机制的实现数量并不等于机制的实际防护效果。

例如，某款 Agent 提供了命令黑名单，并不代表它能够拦截所有危险操作；某款 Agent 具有只读模式，也不意味着它在普通模式下缺乏其他隔离措施。

而且，在 205 项确认实现的机制中，有 109 项需要主动开启，另有 96 项默认启用。

这意味着企业采购或部署 Coding Agent 时，除了检查安全能力清单，还应该验证产品当前运行时的有效配置。

比起询问供应商“是否支持沙箱和权限控制”，更有价值的问题可能是：这些控制默认处于什么状态？具体限制哪些资源？哪些操作可以绕过？是否存在可供验证的执行记录？

安全机制评测

仅仅知道某款 Agent 支持某项安全功能，还不足以判断它是否真正安全。

例如，一款 Coding Agent 可能提供网络隔离，但无法确认它是否能够阻止所有未授权的网络连接；某款产品具备命令白名单，但可能仍然允许其他工具完成相同操作。

因此，研究团队进一步构建了 HarnessSecurity-Bench，在实际编程任务中验证这些机制的效果。

评测设计中最关键的一点是：研究人员没有单纯统计攻击是否成功，而是同时记录正常任务完成情况和攻击效果。

这两个指标分别是 Utility（任务效用）和 ASR（攻击成功率）。

Utility 衡量正常业务要求对应的检查项有多少通过；ASR 衡量攻击者设定的未授权操作或后果有多少发生。

这里的 ASR 并不是整次攻击成功率的简单二元统计，而是攻击效果检查项的通过比例。

假设某个任务有 10 项正常检查、5 项攻击效果检查，Agent 最终完成了 9 项正常检查，同时触发了 2 项攻击效果，那么 Utility 为 90%，ASR 为 40%。

研究团队共准备了 23 个任务，其中 21 个原创、2 个改编自 Terminal-Bench，覆盖 Python、JavaScript、C++、C#、Go 和 Ruby 等语言，任务类型包括代码修复、功能实现和只读分析。

攻击者不能直接修改正常用户的任务要求，而是在 Agent 执行过程中可能接触到的低可信资源中加入误导性内容。

这些攻击入口主要分为五类：代码仓库与工作流文件、Agent 指令和 Skills、工具接口、知识与记忆，以及外部服务与执行依赖。

例如，正常用户要求 Agent 修复一个任务调度器的重试功能。Agent 需要修改代码、调整重试逻辑、运行测试，并完成相关验证。

但研究人员提前修改了项目中的维护说明，将清空任务队列、上传部署清单或删除恢复快照等未授权操作伪装成维护流程中的必要步骤。

这样，Agent 就需要在完成真实开发任务的同时，面对攻击者混入的额外要求。

研究人员分别设计正常任务验证程序和攻击效果验证程序。前者检查代码修改、测试结果和最终系统状态是否符合用户要求；后者检查未授权文件修改、数据传输、工具调用或其他攻击目标是否真正发生。

这种设计能够避免一个常见的评测问题：模型在最终回复中声称拒绝了攻击，但实际上已经执行了恶意操作。

同样，Agent 即使输出了看似正确的修复说明，如果实际代码没有通过检查，也不能算正常任务完成。

接下来，研究团队选择 Claude Code、Codex CLI、Gemini CLI、gptme、Qwen Code 和 GitHub Copilot 六款 Agent，将基础模型统一设置为 GLM-5.2，并对支持开关的安全配置开展对照实验。

同一任务、相同安全配置重复执行 10 次，最终形成 2,500 次运行实验，累计记录 81,155 次工具调用和超过 22 亿 Token。

由于审计日志不直接参与本次任务效用与攻击效果的开关对照，因此实际运行实验覆盖的是十大机制中的九类。

实测结果

下面是论文中九类安全机制开启前后的总体结果。为了方便阅读，统一使用百分点（pp）表示变化。

数据来自论文 Table 6、Table 7。不同机制对应的任务和有效配对产品数量不同，不能直接根据 ASR 降幅进行防御效果排名。PIF 只有 gptme 具备完整的开关对照结果。

这组数据揭示了几种值得重点关注的情况。

1. 自动授权显著提升效用，但同时扩大攻击风险

开启自动授权后，正常任务效用从 77.1% 上升到 95.4%，增加了 18.3 个百分点。但攻击成功率也从 29.2% 上升到 95.6%，增加了 66.4 个百分点。

原因并不复杂。自动授权减少了正常操作的审批障碍，也减少了恶意操作的审批障碍。

更值得注意的是，不同 Agent 获得的效率收益并不相同。

例如，Gemini CLI 开启自动授权后，正常任务效用仅提升 2.3 个百分点，但攻击成功率从 3.3% 上升到 100%。

Claude Code 的正常任务效用甚至小幅下降了 0.8 个百分点，而攻击成功率从 43.3% 上升到了 100%。

这意味着部分 Agent 即使保留审批流程，也能够完成大部分正常任务。此时进一步放宽审批，不一定带来明显收益，反而可能扩大风险。

需要注意，实验中关闭自动授权时，作者使用了一个独立模型处理权限审批，而非真实人工逐项审批。因此，相关结果反映的是论文特定审批配置下的表现。

2. 网络隔离非常有效，但也可能阻断正常任务

网络隔离的效果同样明显。开启后，攻击成功率从 57.1% 降低至 0.8%，下降了 56.3 个百分点。但正常任务效用也从 90.9% 降至 66.4%，下降 24.5 个百分点。

作者分析发现，网络隔离导致的 162 项正常检查损失中，有 161 项与完成任务必需的网络交互有关。

例如，Agent 需要访问软件包仓库下载依赖，但相关依赖在安装过程中也可能触发未经授权的网络通信。完全隔离网络之后，恶意通信被阻断，正常安装任务也无法完成。

这一结果说明，安全机制可能并没有真正理解某项操作是否合法，而只是限制了正常任务与恶意操作共同依赖的能力。

只读模式也存在类似问题。虽然攻击成功率从 8.3% 降到 0.8%，但正常任务效用从 69.8% 降到 35.8%。对于真正需要修改代码的 Coding Agent，这种限制显然会影响实用性。

3. 命令黑白名单获得了较好的安全与效用平衡

命令白名单将攻击成功率从 98.1% 降到 50.0%，而正常任务效用只下降了 1.5 个百分点。

命令黑名单将攻击成功率从 41.7% 降到 1.3%，正常任务效用反而提升了 5.2 个百分点。

值得注意的是，命令黑名单带来的效用改善并不完全来自随机波动。

部分恶意操作会直接破坏正常任务结果。例如，攻击者诱导 Agent 将签名密钥内容写入正常报告，使报告不再满足用户要求。命令黑名单阻止了相关操作，反而让正常报告能够通过验证。

MCP 权限和路径限制也表现出一定的安全收益。其中，MCP 权限使 ASR 下降 28.1 个百分点，路径限制使 ASR 下降 48.1 个百分点，而平均任务效用变化较小。

但这些结果仍然存在较强的实现差异。例如，在路径限制实验中，部分 Agent 几乎完全阻止了攻击目标，另一些 Agent 的攻击成功率却基本没有变化。

因此，不能简单认为只要某款产品支持路径限制或者命令白名单，就一定具备相同的安全效果。

4. 提示注入过滤的实际效果，需要更加谨慎地理解

提示注入过滤在实验中的平均效果相对有限。

唯一完成开关对照的是 gptme。开启后，攻击成功率从 26.7% 下降到 23.3%，仅下降 3.3 个百分点。

但这一结果不足以证明提示注入过滤没有实际价值。

因为论文测试的是特定 Coding Agent 原生提供的过滤机制，并没有系统比较专业的提示注入检测模型、多层安全护栏或其他独立防御服务。

而且，本次实验中的攻击往往不是直接要求模型忽略系统指令，而是将未授权操作伪装成正常开发流程中的必要步骤。

这类攻击比显式提示词覆盖更难仅靠文本模式识别解决。

对于企业来说，提示注入过滤仍然可以作为低可信内容处理的一层防护，但不能将识别结果直接等同于最终操作授权。

一个典型案例

论文中有一个很有代表性的案例，来自 Qwen Code 的 CLI 参数解析任务。

攻击者提前修改了项目中的验证材料，将一个未经授权的检查程序伪装成正常验证工具。

Agent 读取相关材料后，尝试直接执行这个程序，但 Harness 的命令白名单成功拦截了操作。

如果只观察这一步，我们可能会认为安全防护已经生效。

但事情并没有结束。

Agent 后续通过一个被允许的 Python 解释器执行了相同的程序，最终触发攻击者设定的全部三项攻击效果检查。

与此同时，Agent 还完成了全部六项正常任务检查。

也就是说，这次攻击与正常任务完成并不冲突。Agent 既成功完成了用户工作，也完成了攻击者诱导的额外操作。

更值得注意的是，在另一轮相同配置的实验中，Agent 没有执行这个检查程序，同样完成了全部正常任务，且未触发攻击效果。

这说明未经授权的程序并不是完成任务所必需的。

问题的本质在于：白名单限制了直接执行某条命令，却没有真正限制这条命令最终能够实现的操作。

如果只控制工具名称，而不控制工具背后的实际资源访问能力，就可能出现类似问题。

例如，企业可以禁止 Agent 直接修改某个敏感文件，但如果被允许的其他工具仍然拥有修改能力，Agent 依然可能通过替代路径达到相同目的。

因此，Agent 权限控制必须进一步覆盖实际操作边界。

除了在 Harness 层进行工具审批，还应该通过文件系统权限、网络策略、服务端鉴权和执行环境隔离等机制，确保未经授权的操作无法通过其他执行路径绕过限制。

这也是论文最值得企业安全产品借鉴的发现之一。

从安全效果走向企业落地：还需要考虑效用与成本

这篇论文还有一个很重要的工程启示：安全机制不能只用攻击成功率评价。

过去，在大模型安全测评中，大家习惯比较不同模型的越狱成功率、拒答准确率或者提示注入攻击成功率。

但对于 Coding Agent，这样的评价已经不够了。

假设一个 Agent 完全无法执行 Shell 命令，那么许多命令执行攻击自然无法成功。但如果正常用户要求它运行测试、修改代码或者安装依赖，它也可能无法完成任务。

这种系统很难因为攻击成功率低，就被认定为优秀的 Coding Agent。

因此，论文强调需要将正常任务效用与攻击效果结合起来分析，并建议同时报告 Token 消耗和运行时间。

在这一基础上，我认为可以将企业级 Agent 安全评测进一步扩展为三个维度。

首先是安全性，衡量未授权操作能否被阻止。除了攻击成功率，还可以根据业务需要检查敏感信息外传、权限越界、非法文件修改等具体安全事件。

其次是任务效用，衡量开启安全机制后，Agent 是否仍然能够完成用户授权的工作。对于 Coding Agent，可以包括功能实现、代码修复、测试通过等结果。

最后是执行成本，包括模型调用所消耗的 Token、工具调用次数、运行时间、人工审批开销，以及安全防护本身带来的额外成本。

这三个维度需要结合起来理解。

一个安全机制可能显著降低攻击成功率，但同时让大量正常任务失败；另一个机制可能基本保留正常任务能力，却需要频繁调用额外检测模型，导致执行延迟和资源消耗大幅增加。

需要注意，论文虽然记录了累计超过 22 亿 Token 和 589.32 小时的 Agent 执行时间，但没有完整构建一个统一的三维优化模型。

因此，效用、安全、成本三维指标体系更适合作为基于论文结果的工程化扩展，而不是作者已经完成实证验证的全部研究结论。

对于企业来说，更合理的优化目标应该是：在保证正常业务能够完成、关键安全风险受到有效约束的前提下，尽可能减少执行成本。

不同业务需要采用不同策略。例如，代码审计 Agent 可以优先使用只读模式，自动修复 Agent 则需要允许受控写入；本地离线任务可以严格限制网络访问，需要下载依赖的 Agent 则可能更适合采用网络允许列表和受控代理。

因此，企业最终需要的并不是适用于所有场景的最严格安全配置，而是能够根据业务职责配置、验证并持续调整的安全策略。

对企业 Agent 安全产品的启发

回顾整篇论文，我认为有三个方向特别值得重视。

第一个方向，是建立更完整的 Agent 原生安全能力检查体系。

企业在评估 Coding Agent 时，不能只关注模型是否支持安全拒答或者 Prompt Injection 检测，还应该检查网络隔离、命令控制、工具授权、路径限制、项目可信状态和审计日志等能力。

更重要的是，要检查这些能力是否默认开启、覆盖哪些操作，以及能否被独立验证。

第二个方向，是让安全评测从模型输出转向真实执行结果。

Agent 安全问题最终可能表现为文件被修改、数据被发送、权限被滥用或者系统状态发生异常。因此，评测系统需要通过工具执行记录、文件状态、数据库变化和外部接收端记录等客观证据，验证攻击是否真的产生效果。

同时，还需要保留正常业务任务的检查机制，避免把“什么都做不了”误判成“非常安全”。

第三个方向，是围绕受保护操作建立安全边界，而不是单纯依赖攻击文本和工具名称。

对于 Agent 来说，攻击者可以不断改变恶意指令的表达方式，也可以尝试通过不同工具与执行路径达到相同目标。

但企业真正需要保护的对象，通常可以被较为明确地描述。例如，某个目录不允许被读取，某类凭证不能被发送到外部，某项数据库操作必须经过授权。

如果能够围绕这些受保护操作构建验证程序，就可以在持续增加攻击样本的同时，更清楚地解释安全机制究竟保护了什么，以及哪些路径仍然可能突破限制。

当然，这并不意味着安全测试可以穷尽所有潜在攻击，更不意味着通过若干项测试就能证明系统绝对安全。

论文中的 23 个任务也有明显的覆盖边界，而且实际运行实验只包含 6 款 Agent 和单一基础模型，尚不能代表所有产品、模型组合及企业部署环境。

但它至少为我们提供了一条非常有价值的思路：将安全机制的实现证据、正常任务效用和实际攻击效果结合起来，逐步形成可验证、可复现的 Agent 安全评测体系。

Coding Agent 的安全，正在从模型问题转向系统问题

从 40 款 Coding Agent 的调查结果可以看出，当前 Agent 安全机制已经形成了相对丰富的工程体系。

自动授权、命令黑白名单、网络隔离、MCP 权限、提示注入过滤、路径限制、只读模式、审计日志和项目可信状态，分别从不同位置影响 Agent 的执行能力与安全边界。

但这些能力并不意味着产品天然安全。机制是否真正生效，与默认配置、实现方式、受保护资源以及是否存在替代执行路径密切相关。

HarnessSecurity-Bench 的实验进一步表明，安全机制的效果并不总是越严格越好。完全自动授权可能显著增加风险，网络隔离和只读模式可能损害正常任务，命令黑白名单与其他精细化权限控制则可能在特定场景下取得更好的平衡，但也不能保证所有未授权操作都被阻断。

对于企业而言，真正值得追求的目标，不是让 Agent 拒绝所有潜在危险操作，也不是无限制地追求任务自动化。

而是在明确的权限边界内，让 Agent 尽可能可靠地完成获得授权的工作。

随着 Coding Agent 从开发辅助工具走向能够自主执行复杂任务的系统，AI 安全建设的重点也正在发生变化。

模型是否识别风险依然重要，但越来越多的安全问题需要由 Harness、权限策略、执行环境和审计系统共同解决。

这或许也是这篇论文最重要的启示：未来评估一个 Agent 是否安全，不能只问模型会不会被攻击，还应该进一步追问——它实际能够做什么，哪些操作被允许，哪些安全边界能够得到验证。