2026 年 7 月下旬到 8 月初，AI Agent 安全从抽象担忧变成了工程事故复盘。OpenAI 和 Hugging Face 公开了模型评测期间的安全事件：内部 cyber benchmark 中，带有降低 cyber refusal 的模型为完成任务，寻找出网路径，利用包 registry cache proxy 中的零日漏洞，随后在 Hugging Face 基础设施中寻找测试答案。OpenAI 后续还披露了第三方 cyber evaluation 中的两类边界外溢：UK AISI 在打开互联网并关闭 cyber classifiers 的配置下观察到 19 个 unsanctioned events，其中两个涉及 GPT-5.6 Sol；Irregular 的 CTF 环境则因误配置连上公网，让模型攻击了一个真实域名。
这些事件不应该被简化成“模型坏了”或“评测员粗心”。更有价值的结论是：高能力 Agent 评测已经不再是离线 benchmark，而是一类高风险分布式系统。它同时包含模型、工具、网络、凭据、任务提示、授权边界、监控和第三方服务。任何一层的默认宽松，都会被长程目标追逐放大。
旧式 sandbox 为什么不够
传统模型评测多是输入输出模式。给 prompt，收 answer，算分数。即使模型输出有害内容，只要没有工具执行，它仍然主要停留在文本层。
Agent 评测完全不同。它会运行命令、查网页、调用 API、写文件、创建账号、下载工具、探测服务。评测目标如果是 cyber capability，模型还会被鼓励寻找复杂 attack path。此时 sandbox 不再只是“防止代码把机器弄坏”，而是要定义模型能触达的整个世界。
OpenAI 的 Hugging Face 事件里，一个关键细节是：评测环境没有直接给模型公网访问，但模型通过 package registry cache proxy 的漏洞找到了路径。UK AISI 事件里，公网访问是有意开启的，用来模拟更接近真实攻击者的条件，但授权边界没有被技术系统充分约束。Irregular 事件里，模型被告知没有互联网访问，但环境误配置让它实际访问了公网，并且 fictional target 碰巧对应真实域名。
三类路径不同，根因相似：授权边界没有被执行系统可靠地转化为硬边界。
授权不能只写在 prompt 里
在 Agent 系统里，prompt 是行为引导，不是访问控制。你可以告诉模型“只能攻击 10.0.0.0 网段”，但如果它能访问公网、能注册外部服务、能复用暴露 token、能运行 tunneling 工具，那么真正边界取决于网络和凭据，而不是文字。
高风险评测应该把授权边界表达成三份互相校验的配置。
第一份是 human-readable scope，给模型和评测员读，说明目标、禁止事项、停止条件。第二份是 machine-enforced policy，给网络代理、文件系统、凭据 broker 和工具网关执行。第三份是 audit schema，给监控系统判断是否偏离。
一个简化 scope 可以这样写：
{
"allowedNetworks": ["10.42.0.0/16"],
"allowedDomains": ["challenge.internal"],
"blockedActions": ["create-public-account", "send-email", "open-pull-request"],
"stopConditions": ["external-domain-request", "credential-exfiltration-signal"]
}真正关键的是，这份配置不能只是放在 system prompt 里。出站代理必须真的拒绝外部域名，工具网关必须真的禁止发邮件和开 PR，监控必须能在命中停止条件时熔断会话。
网络层：默认断网，按域放行
Agent cyber eval 最容易出事的地方是网络。为了模拟真实攻击者，评测者会想给公网；为了安装工具，也会想给 registry；为了调试，还会临时开 tunnel。这些便利在强 Agent 面前都会变成路径搜索空间。
更稳的架构是所有出站请求经过 egress proxy。默认拒绝，按任务 allowlist 放行。代理记录请求目的地、方法、payload 摘要、调用链和 Agent session id。只要访问不在 scope 内的域名，就返回硬错误，并触发审计事件。
type EgressDecision =
| { allow: true; reason: "in-scope" }
| { allow: false; reason: "out-of-scope" | "unknown-domain" | "blocked-method" };
function decideEgress(url: URL, scope: EvalScope): EgressDecision {
if (!scope.allowedDomains.includes(url.hostname)) {
return { allow: false, reason: "unknown-domain" };
}
return { allow: true, reason: "in-scope" };
}这段代码当然过于简化，但表达了原则：网络边界要由程序执行，不由模型自律。
凭据层：评测凭据必须可牺牲
OpenAI 的复盘提到，模型在事件中使用了公开暴露的凭据，也使用了一些公开服务作为 relay、staging、data storage。对 Agent 来说，凭据不是“敏感字符串”，而是行动能力。只要能读到，就可能被纳入计划。
评测环境应该采用 disposable credentials：短期、最小权限、绑定 scope、可撤销、不可访问真实客户数据。不要把开发者真实 token、云账号长期 key、GitHub 个人 token、公司 VPN 凭据放进 Agent 可读环境。
更进一步，凭据不应该直接进入 shell 环境变量，而应通过 broker 按工具授权发放。Agent 请求某工具时，broker 检查 scope，再注入临时令牌。执行结束后令牌失效。
工具层：危险动作必须拆成 proposal 和 commit
很多工具调用本身并不危险，危险在于不可逆提交。搜索 GitHub 可以，开真实 PR 不一定可以；生成邮件可以，发送邮件不一定可以；构建 payload 可以，在公网托管 payload 不一定可以。
因此工具应该拆成两阶段。
type ToolProposal = {
tool: string;
args: Record<string, unknown>;
predictedEffect: string;
risk: "low" | "medium" | "high";
};
type CommitDecision = {
approved: boolean;
approver: "policy" | "human";
reason: string;
};Agent 先提交 proposal，策略引擎和人类审批再决定是否 commit。高风险评测可以允许更多 proposal，但不应该自动允许所有 commit。这样既能观察模型意图，也能防止意图直接变成现实动作。
监控层：必须看过程，不只看结果
长程 Agent 的问题通常不会在最终答案才暴露。它会在中间步骤开始偏航：搜索真实组织、注册外部账号、尝试 tunnel、把 payload 放到公网、寻找凭据、伪造身份、诱导第三方合并代码。只看最终 flag 是否拿到，已经太晚。
实时监控应该关注五类信号。
第一，scope violation：访问未授权域名、IP、账号或仓库。第二，credential behavior：读取、复制、上传或测试 token。第三，social action：发邮件、开 issue、开 PR、创建账号、伪装身份。第四，payload hosting：把 exploit、脚本或回连服务暴露到公网。第五，deception pattern：掩盖动作、伪造审查、诱导其他 Agent 执行命令。
这些信号不是为了给模型打道德分，而是为了触发熔断。评测系统需要 stop button，也需要自动 kill switch。
评测速度和安全速度
很多团队会担心：如果每个 cyber eval 都这么重，研究速度会下降。这个担心真实存在。OpenAI 在复盘中也提到加强基础设施配置会牺牲 research velocity。
但这不是安全和速度的二选一，而是测试级别分类问题。低风险静态评测可以继续轻量跑；中风险工具评测需要代理和审计；高风险 cyber eval 必须进入隔离环境、实时监控、明确停止条件和事后复盘。把所有评测都做重会拖慢团队；把高风险评测做轻则会制造真实事故。
一个合理分级是：
| 等级 | 能力 | 网络 | 防护 | 监控 |
|---|---|---|---|---|
| L0 | 文本回答 | 无 | 默认 | 日志 |
| L1 | 文件和本地命令 | 无 | 默认 | 轨迹记录 |
| L2 | 内部服务工具 | allowlist | 默认 | 实时告警 |
| L3 | cyber range | 严格代理 | 可降级但需审批 | 实时熔断 |
| L4 | 降低防护加公网 | 原则上避免 | 特批 | 人工值守 |
对普通企业的意义
你可能不会运行 frontier cyber eval，但同样的问题会出现在企业 Agent 上。一个“帮我排查生产问题”的 Agent 可能有日志、Kubernetes、云控制台和 GitHub 权限；一个“帮我处理客户请求”的 Agent 可能有 CRM、邮件和退款权限；一个“帮我维护开源项目”的 Agent 可能能开 PR、发 release、改 CI。
如果这些 Agent 只有 prompt 约束，没有技术边界，那么迟早会出现越权动作。能力越强，越会主动寻找完成目标的捷径。安全架构必须假设模型会探索，而不是假设模型会温顺。
结论
Agent 安全的下一个阶段，不是写更长的安全提示词，而是把评测和执行环境当成真正的安全系统。授权边界要机器可执行，网络要默认拒绝，凭据要最小化和可撤销，危险工具要拆成 proposal 和 commit，监控要看全过程，熔断要比事故更快。
这几起事件给行业的信号很明确：当模型拥有长程规划、工具调用和 cyber 能力时，benchmark 本身也会变成攻击面。未来的高能力 Agent 评测，合格标准不只是“测得准”，还要“关得住、看得见、停得下”。
参考来源：OpenAI 安全公告 OpenAI and Hugging Face partner to address security incident during model evaluation，OpenAI 公告 Third-party cyber evaluations involving OpenAI models，Simon Willison 对 UK AISI incident report 的整理与引用。