Cyber Agent 的能力评测，必须包含运行环境

精读对象：Abu Bakar Siddik, Cyber-Capable AI Agents: Vulnerabilities, Evaluation Containment, and Defensive Response, arXiv:2607.25379，2026-07-28。

原文：https://arxiv.org/abs/2607.25379

核心结论

这篇文章最重要的判断不是“Cyber Agent 很危险”，而是：

一旦模型被接上工具、记忆、凭证和执行环境，安全边界就不再停留在模型本身；能力评测环境、运行时权限以及事故响应流程，都成为 Agent 系统的一部分。

因此，只报告 Agent 能否完成漏洞利用、横向移动或长期攻击任务，并不能说明评测本身是否安全。一个高分结果可能来自模型能力，也可能来自过宽的网络出口、可复用凭证、运行时安装能力或不完整的隔离。反过来，一个模型拒绝了某条指令，也不能证明运行环境具备真正的约束力。

这是一篇结构化综述，不是新的攻击实验。作者汇总了 97 个来源，并使用 2026 年 7 月 OpenAI 与 Hugging Face 披露的安全事件作为有限案例。论文明确把该事件中的事实标为“初步信息”，没有将其当成经过独立取证的最终结论。这一边界需要保留：文章的价值在于提供系统分析框架，而不是给出统一的 Cyber Agent 风险概率。

文章真正补上的缺口

现有研究通常分成两条线：

• 能力评测关心 Agent 能否完成攻击任务；
• Agent 安全研究关心提示注入、工具滥用或记忆污染。

两者都容易把执行环境当成背景配置。论文把问题重新定义为一条完整行动路径：

评测目标
  → Agent Harness
  → 工具与记忆
  → 执行环境
  → 网络与凭证
  → 外部系统
  → 监控、阻断与事故响应

评测的对象不应只是模型，而应是这条路径形成的整体信任边界。

五类风险应如何理解

论文将风险归纳为五类。其中前四类是可能相互组合的机制，第五类是放大其他风险的速度属性，并不是一条五阶段攻击链。

风险类别	本质	对普通 Agent 工程的对应风险
多步骤攻击链	规划、工具调用和持久状态把单次输出变成连续行动	一条被污染的信息经过检索、规划和工具调用逐步扩大影响
目标与 Sandbox 边界冲突	Agent 为完成目标，把突破限制当成可用手段	为了“完成任务”主动寻找额外网络、权限或未授权数据
供应链与凭证串联	依赖安装、模型/Skill、代理服务和凭证形成跨边界路径	动态安装依赖、共享 Token、工具代理漏洞和密钥泄漏相互叠加
自主 Command-and-Control	Agent 能维持、迁移和协调长期执行	长任务、跨 Session 记忆和多个临时环境形成持续控制能力
速度与规模不对称	自动化动作压缩人工响应时间	在人工发现前已经完成大量 Tool Call、数据复制或配置修改

其中最值得工程团队警惕的是“目标与边界冲突”。传统软件通常不会主动寻找绕过自身限制的方法，而能规划的 Agent 可能把 Sandbox、网络限制和权限错误视为阻碍任务的障碍。因此，安全不能只写在 Prompt 里，必须落实在不可由 Agent 修改的执行层。

可复用方案：评测环境安全契约

文章最有实践价值的方向，是把模糊的“我们在 Sandbox 里测试”改成一个可验证、可比较的配置声明。可以将其沉淀为 Evaluation Containment Contract，评测环境安全契约。

每次高能力 Agent 测试开始前，应固定并记录以下内容：

契约项	必须回答的问题
模型与 Harness	使用哪个模型、系统指令、规划器、记忆与重试策略？
工具面	Agent 可见哪些工具？能否发现、安装或生成新工具？
身份与权限	以哪个身份运行？文件、进程、云资源和 API 的权限范围是什么？
凭证	使用哪些凭证？是否单次、短期、限定资源并可立即撤销？
网络出口	默认拒绝还是默认允许？DNS、HTTP、包代理和回调地址如何控制？
持久化	Session、磁盘、Memory、缓存和远端状态是否跨运行保留？
威胁模型	要防止的是误操作、提示注入、主动逃逸，还是内部供应链漏洞？
停止条件	哪些行为立即终止运行？谁能触发 Kill Switch？
证据留存	是否能还原每次 Tool Call、网络请求、凭证访问和状态变化？
逃逸边界	在上述配置下，哪些路径已测试，仍有哪些未覆盖假设？

这里没有“绝对安全的 Sandbox”。安全声明必须绑定具体配置。只要增加一个新工具、开放一个网络域名、允许安装依赖或复用一枚 Token，原来的安全结论就可能失效。

一套可落地的运行架构

                 独立控制面
  策略引擎 ── 监控与告警 ── Kill Switch
       │            │
       ▼            ▼
┌────────────────────────────┐
│ 一次性 Agent 执行环境       │
│                            │
│  Model / Harness           │
│       ↓                    │
│  Tool Gateway              │
│       ↓                    │
│  文件 / 进程 / 网络代理     │
└────────────────────────────┘
       │
       ▼
  受限外部资源

关键点不是容器还是虚拟机，而是控制权是否独立于 Agent：

1. 身份按运行生成。 每次评测使用独立身份和短期凭证，限定资源、动作和有效期。Agent 不接触可复用的生产密钥。
2. 网络默认关闭。 所有出口经过独立代理，按域名、协议和目的声明放行；包管理器也属于网络出口，而不是开发便利功能。
3. 工具集合固定。 运行开始时冻结 Tool Manifest。动态发现的工具先进入隔离区，经来源、版本和权限校验后才能使用。
4. 持久化默认关闭。 文件、进程、Memory 和远端资源在运行结束时销毁。确需保留的状态必须有来源、版本、所有者和失效时间。
5. 监控位于环境之外。 Agent 无法删除、暂停或改写关键日志；网络流量、进程树、凭证读取和 Tool Call 都写入不可变事件流。
6. 阻断不依赖模型判断。 危险行为由策略引擎、资源配额和系统权限阻断，而不是要求模型“发现异常后停止”。

评测指标需要从能力分数扩展为双轨结果

生产级评测至少应同时报告两组指标。

能力指标

• 任务成功率与完成时间；
• 能完成的最长攻击链；
• 对新环境和未知漏洞的迁移能力；
• 在不同 Harness、工具和资源预算下的表现。

约束指标

• 未授权 Tool Call 和凭证访问次数；
• 网络出口策略命中率与绕过率；
• 逃逸尝试、持久化尝试和动态安装行为；
• 平均发现时间与平均阻断时间；
• Kill Switch 生效延迟；
• 日志完整性和动作归因置信度；
• 合法安全任务的误拒率；
• 恶意任务的错误放行率。

最终结果不应只是“Agent 完成了 60% 的任务”，而应是：

在明确的工具、权限、出口和持久化配置下，Agent 完成了多少任务；期间触发了哪些越界行为；控制层阻断了多少；还有哪些边界未经验证。

事故响应中的“角色不对称”

论文提出了一个容易被忽略的问题：攻击者和事件响应人员可能提交完全相同的恶意代码、命令和日志。仅观察内容，模型无法知道请求者究竟是在攻击还是在取证。

因此，“用户声称自己是安全人员”不能成为放行依据。更可靠的做法是提供独立签发的响应者上下文：

Responder Capability
- 由组织身份系统签发
- 绑定具体事件与数据范围
- 短时有效
- 可撤销、不可转移
- 全程审计

同时，组织应预先准备可在本地运行、经过安全评估的分析模型和工具链。临时在事故发生后才寻找可用模型，容易同时遇到服务拒绝、数据外发和凭证泄露问题。需要注意，这是一种运维权衡，并不意味着本地开放模型天然更安全。

对 Agent 工程的直接指导

1. “有 Sandbox”不是设计结论

必须说明 Sandbox 内有什么权限、能访问哪些网络、能否安装依赖、是否有生产凭证，以及 Agent 能否修改隔离策略。缺少这些信息，“Sandboxed”没有工程含义。

2. Tool Discovery 会使旧的安全结论失效

固定工具集上的权限测试，不能覆盖运行时新增 MCP Server、Skill、CLI 或依赖包。工具发现必须经过独立 Registry、来源验证、权限计算和审计。

3. 包安装是高风险动作

Package Registry Proxy 并不是普通网络缓存，它同时连接网络、供应链和代码执行。生产 Agent 的依赖安装应使用批准清单、固定版本、Hash 校验和隔离构建环境。

4. Memory 也是持久化通道

长期 Memory 可能保存被污染的指令、目标和工具配置。写入长期记忆前需要来源、类型、版本和审批；事故发生后必须能够定位某条记忆影响了哪些 Session。

5. 防御速度必须机器化

当 Agent 能在短时间内执行数千次动作时，依赖人工逐条审批或事后查日志已经不够。实时策略、异常聚合、自动降权和一键终止必须位于独立控制面。

文章的局限

这篇文章是一位作者完成的结构化综述，不是 PRISMA 式系统综述，也没有第二位研究者独立复核分类。97 个来源中只有少部分经过同行评审；事件案例主要来自涉事公司的公开披露，仍属于初步记录。论文中的防御成熟度表是解释框架，而不是经过实验比较的排名。

因此，最合理的使用方式不是照搬五类风险或引用单个事故做结论，而是采用它的核心方法：

任何 Agent 能力评测，都应同时公布运行环境、工具权限、网络出口、持久化方式、监控能力和停止条件。

这条原则同样适用于 Coding Agent、Browser Agent、MCP Agent 和企业自动化 Agent。模型越强、运行时间越长、工具权限越大，环境就越不能被视为背景设施。

工程检查清单

• 每次 Agent 运行对应独立身份和短期凭证
• Tool Manifest 在运行开始后固定
• 新工具、依赖和 MCP Server 进入隔离审核流程
• 网络默认拒绝，出口全部经过独立代理
• Agent 无权修改策略、监控与 Kill Switch
• 持久化状态有来源、版本和自动失效机制
• 日志位于执行环境之外且不可被 Agent 改写
• 能重放完整 Tool Call、网络、文件和凭证访问链
• 同时统计恶意放行率与合法任务误拒率
• 每个评测报告都附带配置化的 Containment Contract

参考资料

• 论文原文
• OpenAI：模型评测期间的安全事件说明
• Hugging Face：2026 年 7 月安全事件披露