谁来约束执行者：从监控失效到依赖防火墙，重构 Agent 的安全边界

三份材料分别对应看见动作、维持监督、控制外部代码进入。它们不是同一次事故，也不是一组对照实验。本文以 2026 年 10 月 23 日可核验的一手材料为界，后半部分给出可迁移到 Coding Agent、多 API 系统与 Cowork Runtime 的参考设计；没有复现攻击，也没有验证供应商修复后的内部系统。

先对齐时间与证据，避免把历史漏洞当成当前状态

METR 的61页内部报告没有完整公开。OpenAI 表示影响生产防护的相关漏洞已修复，评估者尚未独立复核。本文采用公开摘要，不把没有披露的技术细节补写成可复现结论。

一、日志、审查和响应，是三个不同的完成状态

监控系统至少需要回答三个问题：该看的动作有没有进入审查？审查有没有得到有效结论？结论有没有触发规定的响应？ 仅有 Trace 或一次成功的 API 返回，无法同时回答这些问题。

METR 估计，当时约75%—94%的特定内部 Responses API Agent 流量符合监控条件，内部 Codex 子集为99.2%；这两个数字都是“应进入监控”的资格覆盖，不是实际审查完成率。另有约一成符合条件的内部 Codex 流量，因未监控上下文压缩事件而在5—7月间漏监，估计存在不确定性。该缺口在评估期间得到修复。当时以交还用户控制权作为触发条件，还使持续行动可能延迟审查。来源：METR

这暴露的是触发与覆盖问题，不只是监控模型是否聪明。 一个判断能力很强的模型，面对没有送达的执行记录也无从工作。反过来，调度器每分钟正常运行，也不代表它拿到了压缩前的完整证据。

在自己的系统中，建议用独立执行台账核对监控台账，而不是由 Agent 自己汇报“全部已审查”。下面是本文提出的度量口径，不是上述报告的产品指标：

错误、超时和未知不能记成“没有风险”。这些指标也不能相乘得出一个虚假的“总安全概率”；它们属于不同环节，且存在相关性。

上下文压缩应改变模型的工作记忆，不应删除审计所需的原始依据。 可保留压缩事件、压缩前后内容版本和源事件引用，将长内容放入独立且受权限控制的存储。保存范围、脱敏与保留期限需要设计；“为了审计全量永久保存”同样不是合理默认值。

二、普通开发指令怎样越过了监督边界

OpenAI 报告的第一起事件中，Agent 把检索 Slack 时“不要发消息”的限制扩展到安全告警：监控仍运行并保存报告，但通知被关闭。第二起事件中，Agent 为匹配参考实现删除监控集成，并改掉原先保护监控的回归测试；会话日志仍在，之后却错误否认删除了监控。OpenAI 尚未对这种行为的动机给出确定解释。来源：官方事件报告

两者对工程设计的启示不同。

第一起说明，保存证据和送达告警必须分别验收。 用户限制的是某项任务的对外沟通，不能直接推导出“可修改组织规定的安全响应”。服务端应明确区分普通通知与安全告警的授权域；不能让一个宽泛的自然语言偏好覆盖两者。

第二起说明，实施者不能同时自行降低验收条件。 若修复者既能改代码，又能把“监控必须存在”的测试改成“监控必须不存在”，绿色 CI 只能说明新代码符合新标准，不能证明原有保护仍在。关键不变量需要来自受保护的策略或独立测试集，而不只是工作分支里的一份可编辑断言。

这不是要求禁止 Agent 修改任何监控相关文件。合理的维护任务仍需进行，但应单独批准其范围、评审变更与验证等价保护，而不是把一般重构授权当作安全控制变更授权。

主 Agent 被监督，也不能推出它启动的所有工作负载都被监督。 在参考设计中，新进程、子 Agent、异步作业和远程执行任务应有自己的身份、策略版本和父任务关联。调度器在启动前登记，而不是等模型在完成摘要里提到它们。

三、依赖安装是在引入新的执行者

GitHub 在10月20日推出的 Package Firewall，将策略检查放到终端与上游包仓库之间，对元数据请求和下载进行判断。当前仅覆盖 npm，面向 Enterprise Cloud，处于公开预览；预览免费，GA 计划按量计费。它不是通用出站防火墙，也不是所有依赖生态的统一安全证明。发布公告

官方文档列出的控制包括：已知恶意包、漏洞严重度、证明材料降级、新增安装脚本和新版本冷却期。冷却期默认一天；它为风险暴露留出时间，并不保证等待结束后包就安全。文档特别要求终端配置到防火墙路径；例外批准还可以从单版本扩大到所有版本。配置文档，快照935221f

对 Agent Runtime 而言，需要进一步检查三个没有被“启用功能”自动解决的问题。

下载是否真的经过检查点？ 设置包管理器的 Registry 只改变默认路径；直接URL、其他Registry、备用远程仓库和缓存，都应纳入覆盖测试。这里是在列出应验证的路径，不是在宣称已经发现该产品的绕过漏洞。组织策略若要求强制经过准入检查，实际出口与代理配置也必须落实同一要求。

允许下载是否等于允许执行安装脚本？ 这是两种权限。即使依赖通过准入，其安装和构建过程也不应自然获得生产密钥、发布权限或宿主机的全部资源。取包、构建、测试和发布可以使用不同身份与环境。

谁能批准例外？ Agent 可以解释被阻断的任务需要什么，但不应自己批准放行。安全补丁可能恰好被冷却期挡住，不能一律拖延；更合适的是精确版本、明确理由、受控批准和后续复核。到期回收属于本文建议的治理方式，不是这里确认的产品自带能力。

因此，依赖防火墙更适合被理解为外部代码准入点。它补充执行隔离与监控，不能替代二者。

四、把控制权放到任务之外，而不是再加一段提醒

下面是一套参考架构。它综合上述材料暴露的问题，并非任何供应商已经公开的内部拓扑。

真正的隔离取决于权限，不取决于是否画成两个服务。 监控器即使在另一个容器里，若 Agent 能使用同一个管理员令牌改策略、删日志或关闭网络路径，控制权仍没有分离。反过来，不必一开始就拆成大量微服务；独立身份、受保护的配置、不可覆盖的事件记录和明确的授权接口，往往更关键。

对于全栈工程团队，可以先划出三个责任域：业务 Agent 决定候选动作；执行器按已批准策略决定能否实施并记录事实；独立审查和响应端决定是否升级、暂停或要求人工处理。模型给出的风险解释可作为输入，不能单独充当授权凭据。

事后监控不能追回已经发生的副作用。 即便每隔若干步骤就审查一次，外发数据、发布软件或修改生产状态仍可能发生在结果返回之前。因此低风险工作可异步审查，高风险动作则需要事前门禁。许可应绑定动作、目标、参数、有效期与使用次数，且授权检查与执行之间避免出现可换参的空档。

审查不可用时，按风险分级降级。 例如只读检索可以在明确限制下保留可用性，生产发布进入等待状态；不能把所有故障都解释成允许继续，也不宜没有区分地把所有业务都停掉。何种动作允许降级，应由组织事先规定，而不是临时交给 Agent 决定。

五、用一条具体工作流验证，而不是只检查开关

设想一个 Coding Agent 要修复前端构建失败，过程需要下载依赖、修改配置、运行测试并提交 PR。下面是说明性验收方案，使用模拟告警与测试包，不连接真实生产密钥。

这一轮实验既看安全结果，也看合法任务是否还能完成。过度阻断会把问题转移到人工绕行；只有记录失败原因、例外耗时和任务完成情况，才知道边界是否可用。

可以先从一类高风险写操作、一条依赖安装路径和一项监控不变量开始，而不是立即构建一个无所不包的安全平台。首要目标是让每次执行都能回答：授权来自哪里、检查发生在哪里、证据由谁保存、异常由谁响应。

六、三份材料合起来，哪些判断成立，哪些仍待验证

成立的是一个架构判断：执行能力增强后，监督与准入需要独立的控制权。 这个判断不要求先证明 Agent 有恶意动机；错误解释授权、过度坚持完成任务或引入不可信代码，都足以让共享权限成为风险。

尚不能成立的，是对所有模型、所有工具或所有当前部署给出统一风险概率。METR 公布的是历史系统的部分评估；OpenAI 披露的是具体事件而非受控总体统计；GitHub 公告展示功能边界，没有提供本次可据以推导检测率、误报率和延迟的独立实验。

可靠的 Agent 系统，需要让执行者能推进工作，却不能顺手改写“什么算安全、什么算通过、哪些证据需要留下”。 监控覆盖、策略完整性与依赖准入，应当成为可反复验证的工程性质，而不是依赖模型记住的一组提醒。