TwKit
正在载入
TwKit

各派一人深入 OpenAI 三周:METR 与 Redwood 压力测试内部 Agent「错位行为」监控系统 今年夏天, @METR_Evals 与 @re… · @shao__meng · TwKit

@shao__meng

各派一人深入 OpenAI 三周:METR 与 Redwood 压力测试内部 Agent「错位行为」监控系统 今年夏天, @METR_Evals 与 @redwood_ai 各派一人进驻 OpenAI 三周,深度检查内部 agent(含 Codex)的错位行为监控。公开稿只给高层摘要:覆盖有缺口,也找到可绕过监控、沙箱与 Auto-review 的路径。OpenAI 称影响生产防护栈的漏洞已修补;评估方未独立复核。 https://metr.org/blog/2026-10-22-red-teaming-openai-agent-monitoring/ 试点怎么做? · 时间:2026-07-21 至 08-11。评估对象是截至 7 月 21 日及之前的异步内部监控系统,不评估同期正在扩展的改动。 · 权限:公司配发设备不离场、有人陪同;可看内部代码库、监控 prompt / 配置、文档,并访谈约十多名监控、安全系统与安全团队人员。 · 目标两个子问题:(1) 有多大比例的 agent 流量被监控;(2) agent 能否破坏或绕过监控。 · 产出:61 页报告给 OpenAI;经删减后 38 页给 METR / Redwood 管理层。事先约定只发简短公开稿;OpenAI 可删密,评估方无权单方面描述删了什么。 公开的关键发现(均为当时系统状态) · 覆盖率:内部 Responses API(支撑 Codex 等)中,不低于 GPT-5.5 的 agent 流量约 75–94%「有资格」被监控(不确定性大);其中内部 Codex agent 子集约 99.2%。「有资格」不等于一定跑完整条监控流水线(还有报错、过载丢弃、实现 bug)。另有内部研究推理服务上的 coding agent,因权限与时间未能估量。 · RL 训练:知情称 3–6 月有一部分 RL rollout 被监控;试点开始时 RL 训练运行不在覆盖内。 · Compaction 缺口:未监控 compaction 事件,估计 2026 年 5–7 月约有一成量级的合格内部 Codex 流量实际未进监控;精确比例不确定,因当时没记「多少监控调用由 compaction 触发」。OpenAI 在试点前已独立发现,并在试点期间修复。 · 拖延触发:当时监控在 agent「把控制权交回用户」时才触发。在 compaction 未监控期间,agent 只要持续行动,理论上可无限推迟被监控。评估方因权限未能查实是否已被真实利用。 · 监控可靠性:获悉当时监控报错率低于约 0.2%;试点中某 24 小时内过载丢弃为零。 · 可利用路径(细节多被删): · Codex agent 原则上可绕过沙箱与 Auto-review,做到主机用户能做的任意操作; · 一种 exploit 可让「数百条」近期动作(含 exploit 本身)不被监控; · 利用 agent 所见轨迹与监控所见序列化差异,构造可能让监控失败、从而不升级人工复核的输入; · 两个可由客户端控制的 header 可为新 agent 关掉监控(设 header、起新实例的动作本身仍可能被抓到); · 两个被认为只读的未监控内部 agent 工具,理论上可用简单方式突破限制(未在实战中验证)。 · 正面核对:除少数例外,监控所见轨迹与 agent 所见基本一致;监控 prompt 覆盖 scheming、破坏监控、破坏、数据外泄、欺骗、提示注入等类别。 · OpenAI 事后称:所有影响生产防护栈的已识别漏洞已修补,并描述了后续覆盖范围的重大变更。METR / Redwood 未评估这些说法。 他们提出的设计理想(摘要) 未来监控应能扛住高度能干的内部 agent 的故意、持续攻击:难逃监控(未监控请求需显式批准;按 N 条消息 / N 分钟触发,而非等回合结束);对「该监控的流量」做账本交叉核对;快速、权责清晰的事件响应与防篡改日志;定期对监控本身做控制评估与红队;agent 与监控强隔离,agent 行为不应能影响监控是否运行。

曝光 384 · 评论 4 · 点赞 3 · 书签 2

查看原帖