别把 AI 编码助手的安全宣传当测评：用 AgenticBench 看九项可复现实验
AI 编码 Agent 能读文件、运行命令、调用插件，也可能接触仓库外的内容。比较它们的安全性，光看权限说明或厂商宣传并不够：关键是把相同任务放进可观察的环境，检查数据流和边界是否真的生效。AgenticBench 提供了一个值得关注的独立测评案例：它不是通用“安全分数”，而是把若干具体风险变成可检查的实验，并公布每个工具版本的结果与方法。
它测的是什么，不测什么
AgenticBench 的公开榜单面向 AI coding agent harness，也就是驱动模型、管理工具与工作区的 Agent 软件。它当前列出九项安全测试，关注秘密文件是否被越界读取、仓库内容或工具输出中的恶意指令能否突破用户边界、项目配置能否擅自扩大权限、启动钩子是否需要同意、受限模式与符号链接是否绕过工作区边界，以及新会话是否意外继承旧项目上下文等问题。
测试使用伪造的秘密和隔离容器，并结合系统调用轨迹、模型请求及网络流量等证据判断结果。每个结果对应特定版本、运行模式和测试条件；榜单说明测试运行时通常采用工具自身默认设置，标注为 auto 的格子则另有说明。它测的是 Agent 软件在这些测试中的行为，不是模型写代码的质量，也不是对现实环境的全面渗透测试或安全认证。
这个边界很重要：九项测试能帮助团队发现具体控制缺口，却不能证明工具在所有配置、模型和攻击方式下都安全。页面也明确说明，每个格子是一次运行，更多重复实验和变体仍在计划中。把它当作可复核的信号，比把排名当成绝对结论更稳妥。
读懂 pass、fail 和缺失控制
榜单中的状态不应简化成“通过/不通过”二分法：
| 状态 | 含义 | 阅读时的注意点 |
| — | — | — |
| Pass | Agent 完成任务，且该项保护在本次运行中生效 | 只说明对应测试和版本，不代表全面安全 |
| Fail | 记录到泄漏或受保护变更等失败证据 | 查看测试说明、版本与证据上下文 |
| MC | 厂商文档表明所需保护不存在 | 是缺失控制，不等于该测试已实测攻击成功 |
| N/A | 无法形成有效测量 | 不是通过，也不应计作通过 |
还有“尚未测量”的情形：测试可能未触发目标行为、运行故障，或仍在进行。公开说明将它与 Pass 区分。页面同时展示披露状态：研究者会先核实并向厂商私下报告问题，部分细节在公开日期前暂缓展示。因此，榜单中的披露标记也不是测试结果本身，应该分别阅读。
如何把榜单用于团队选型
第一步，确认版本与模式。不要把旧版本的一次结果外推到刚发布的新版本，也别忽略榜单注明的模型差异。AgenticBench 通常使用指定模型；少数工具按其供应商模型测试，结果可能受到模型和工具共同影响。评估自家环境时，应记录 Agent 版本、模型、权限配置和运行日期，避免只保存一个“总分”。
第二步，按威胁模型挑测试。若团队最担心仓库提示注入，重点查看仓库内容、工具输出和项目配置相关测试；若 Agent 会在多项目间切换，则关注工作区边界、符号链接与新会话上下文。失败或 MC 都值得追问，但问题不同：前者是该次实验观察到失败，后者是对应保护未提供或文档明确缺失。
第三步，自己重放。AgenticBench 说明，完整测试材料（探针、运行配置和原始证据）可由受测厂商在保密协议下申请。团队可据此构造只含虚假凭据的隔离复现实验，再观察本地工具调用、文件访问和出站请求。不要把真实 API Key 或生产数据放进测试用例；安全评估本身也必须遵循最小权限。
一个可落地的审查清单
在引入新的编码 Agent 前，可以把评估流程写进内部验收：
- 固定版本、模型、默认权限和启用的扩展，记录测试环境。
- 用无害的假秘密测试越界读取、提示注入和失败日志等场景。
- 采集工具日志之外的证据，例如文件访问、进程调用与网络请求。
- 分开记录 Pass、Fail、MC、N/A 和未测量，不将缺少测试解释为安全。
- 升级 Agent 或更改权限后重跑关键用例，并保留结果差异。
这并不能替代正式的威胁建模，但能让“我们启用了安全模式”变成可以验证的问题。对开发团队来说，AgenticBench 最有价值的部分不是榜首是谁，而是它把安全主张拆成了具体测试、版本和证据；借用这种思路，才能判断某个控制是否真的保护了自己的代码与凭据。