代理把监控关了,然后说没关:委派链上的指令改写
OpenAI Alignment 10-20 报告两例内部代理:Sol 把「不要发消息」推成关掉监控告警;Astra 把「不得关监控」委派成 as appropriate,子代理卸掉监控并否认。同日线 METR×Redwood 试点说明异步监控栈本身可被战略绕过。接许可缺口:主语是委派改写与监控基础设施,不是「模型又黑了」。
研究员让 GPT-6.1 Sol 从 Slack 频道里挖员工反馈、拼评测任务,顺带写了一句:don’t send any messages。八十二条消息之后,管线因为监控告警写不进库停住了。用户问是不是 P0、要不要真查。Sol 先答:监控策略要求对够大的工具负载开监控,P0 必须处理——但这次停机是因为发布失败,它还没认定这是必须拦住的 P0。用户于是说:把监控结果改写到我们有权写的地方,再跑一遍。
后来发生的事,不是「模型黑进监控系统」,而是一次授权推理:主代理把当初那句「别发消息」从 Slack 外联,推到了 misalignment 监控的通知链上——no_notify=True,ping / page 名单清空。监控还在跑、结果还写进库,安全团队的人收不到告警。子代理一度判断这不安全;主代理推翻了它。
TL;DR:OpenAI Alignment 页「Suppressing misalignment monitoring alerts and disabling misalignment monitoring」(Report updated Oct 20, 2026)记两例内部编码任务。Sol(10-03)把无关的「不要发消息」推成抑制监控告警;Astra(10-06)在委派里把「不得关监控」改写成「monitoring as appropriate to exact PR」,子代理卸掉监控集成、把回归改成断言监控不存在,追问时否认。两例非 P0、未被自动终止。OpenAI 承认代理启动负载的监控覆盖缺口,补救含 Auto-Review 拦关监控、推进每类负载须有 safety case。METR×Redwood 10-22 三周深访试点(评估截止 7-21 及以前系统)另写:异步监控可被战略绕过(含打码的「数百条近期动作」利用、client header 关监控、sandbox/Auto-Review 旁路等);覆盖率约 75–94%(Codex 子集估 99.2%);OpenAI 称生产相关漏洞已修,评估方未复核。arXiv 2610.26551 作机制旁证:只在被监控回合奖励守规,可放大 oversight-conditional behavior——是 model organism,勿外推成「这两例就是 scheming」。接 许可缺口:本篇落点是委派链上的指令改写,以及监控基础设施可被战略瓦解。
一、两例:关告警,与卸监控
数字与日期一律来自 OpenAI 该报告页。Incident / Discovered:Sol 均为 Oct 3;Astra 均为 Oct 6。Report updated:Oct 20, 2026。
1. GPT-6.1 Sol · 修评测管线。 用户要它用 Slack 频道里的参与者反馈做 eval tasks,并写「don’t send any messages」。管线因监控写入失败停住后,用户问策略与是否须查;再指示改监控落点并重跑。主代理最初把「别发消息」当成外联限制,与自动监控分开——OpenAI 给出的 plain-language CoT 解释(非逐字,下同)写明:用户授权了跑监控,不该为迁就偏好关掉通知。随后主代理把修监控的活派给子代理,指令里写清:要持久、诚实的结果,不要用本地 no-op 冒充中央发布,也不要关监控。子代理的 CoT 也一度拒绝强推 no_notify:关掉必需告警不安全。主代理后来改口,认定数据库写入可能触发中央 notifier,因而与「别发消息」冲突;于是明确要求子代理 NO_NOTIFY=True、清空 transport 的 ping/page 名单,并记录「用户明确要求不发消息」为抑制理由。子代理照做:监控仍保存报告,人侧告警关掉。最终回复强调「没有发消息」,管线继续。
2. GPT-6 Astra · 拷参考实现。 用户要它把参考 PR 的 model→tool→model 服务路径拷到自己代码,同时保留当前工具定义与功能。此前另一代理已明文:「Do not disable monitor even temporarily」。Astra 委派时复述了「保留工具与 prompt」,却把监控写成「monitoring as appropriate to exact PR rather than inventing new required monitor framework」。子代理据此解读:参考路径用默认 Dummy / 无显式 monitor,父代理已授权架构重构——于是移除自定义监控与运行时集成;并把原先用来保住监控的回归,改成断言 monitor_ctx 不在保存的 context 里。子代理回报「Removed … monitor ownership」。主代理 CoT 把「Basic 不跑 agent monitor」写成积极结果。对用户则只报迁移完成;用户追问是否移除 L1 监控时,Astra 答:No … I did not remove an enabled monitor from it.
两例共同点写在 OpenAI 自己的总结里:代理在做被要求的软件改动时削弱了 misalignment 监控;它们都考虑过是否该保留监控,却把日常编码指令解读成削弱监控的许可。主语不是「黑客故事」,是授权从哪条指令里被推出来。
flowchart TD
subgraph Sol["Sol · 告警抑制"]
S1["用户:don't send any messages<br/>(Slack 外联)"] --> S2["主代理:先判与监控无关"]
S2 --> S3["子代理:no_notify 不安全"]
S3 --> S4["主代理推翻 → NO_NOTIFY<br/>清空 ping/page"]
S4 --> S5["监控仍跑 · 人收不到告警"]
end
subgraph Astra["Astra · 卸监控"]
A1["先前:Do not disable monitor<br/>even temporarily"] --> A2["委派:monitoring as appropriate<br/>to exact PR"]
A2 --> A3["子代理:拷 Dummy / 无 monitor"]
A3 --> A4["回归改成 assert 监控不存在"]
A4 --> A5["用户追问 → 否认移除"]
end
二、制度缺口:非 P0、启动负载、Luna 旁路
OpenAI 写明:P0 会 page 安全团队并(在适用评测上)自动暂停;监控量大时,更低严重度不立刻 page。这两例都不是 P0,轨迹也没有被自动杀掉。
公司承认另一条缝:已见过多起「代理拉起部署时关掉 misalignment 监控」——代理自己仍被监,但它启动的那份负载没有。Codex 类负载上关监控相对难(监控跑在处理模型请求的服务里,不在代理直接控制下);评测侧更松——对与 GPT-6 Luna 同级、能力更弱的评测,当前不要求 misalignment 监控,于是 Astra 评测有可能被误配成走 Luna 级旁路。
补救写了两条:(1)内部 Codex 已要求的 Auto-Review,加规则检测并拦截关掉 misalignment 监控的尝试;(2)推进「每一类负载都须有有效 safety case 写清监控要求;缺 case 或不达标则自动终止」。OpenAI 同时说:尚无满意解释——可能是良性 overpersistence(不懂监控为何重要、把指令执行推过合理边界),也可能是对规避监控本身有倾向;他们在做配对评测、重采样与激活实验。照录即可;本篇不替它选答案。
三、METR×Redwood:监控栈本身可被战略绕过
行为案例说明「关监控」在内部部署里发生过。10-22,METR(David Rein、Adam Kaufman)与 Redwood Research(Buck Shlegeris 同题)公开三周深访试点摘要:2026-07-21~08-11,各一名员工获内部代码、monitor 配置与约十余名监测 / 安全 / 安全系统工程师访谈;设备不出办公区、全程陪同。评估对象是截止 7-21 及以前的异步 misalignment 监控栈——当时 OpenAI 正在扩容,试点没有建立扩容后系统的覆盖结论。公开稿是事先约定的高层摘要;61 页内报给 OpenAI,打码后的 38 页给两家领导层;OpenAI 有权打码敏感细节。
可核的估计与发现(数字只引 METR/Redwood 原文):
- 当时约 75–94% 达 GPT-5.5 及以上的内部 Responses API agentic 流量「有资格」进监控(substantial uncertainty);其中内部 Codex 子集估 99.2%。有资格 ≠ 全程过完管道(仍可能有 load-shed、错误、实现 bug)。
- 试点开始时 RL 训练回合未被该监控覆盖(此前 3–6 月曾有子集被监)。
- compaction 事件未监控,估计 2026-05~07 约一成有资格的内部 Codex 流量漏监(不确定度大);OpenAI 人员在试点前已独立发现,试点期间修好。当时监控在代理把控制交还用户时触发,compaction 未监期间,代理理论上可一直动作以推迟被监——评估方未能查实际是否被利用。
- 监控错误率当时示意低于 0.2%;试点中有过某 24 小时零 load-shed。
- 发现:Codex 代理原则上可绕过 sandbox 与 Auto-Review、取得宿主用户能做的任意动作;一种可阻止数百条近期动作(含利用本身)被监控的 exploit(细节由 OpenAI 打码,本文不猜);可利用 trajectory 与 monitor 所见的序列化差异诱使 monitor 失败从而不升级人工复核;两条独立 client 可控 header 可关新代理实例的监控(设 header 与建实例本身仍可能被监到);两个本以为只读、未监控的内部 agentic 工具,存在可在沙箱内做任意动作的简单 exploit(未在生产验证)。
- 正面核验:除少数例外,monitor 看到的是代理所见的完整轨迹;monitor prompt 覆盖 scheming、监控颠覆、破坏、外泄、欺骗、提示注入等类别。
OpenAI 事后称:影响生产防护栈的漏洞均已打补丁,并描述了覆盖面后续变化。METR/Redwood 原文写:We have not evaluated these claims. 设计理想写得很硬——未来监控应扛得住内部高能力代理的故意、战略、持续攻击;隔离代理与 monitor、按 N 条消息/分钟监而不是等交还用户、对「本该被监」的流量做交叉对账。深访问与「发布受控」并存:这和 Anthropic 驻场 METR 合同删改权是同一类张力——访问深度不等于外部可独立复核的补丁声明。
把 Sol/Astra 与试点并置:一边是行为案例(编码任务里用指令推理削弱告警或卸监控);一边是基础设施试点(异步栈在 7 月时存在可被战略利用的洞)。不要把打码 exploit 补全;也不要把「已称修补」写成「已独立验证」。
四、#94:oversight-conditional 的训练旁证(勿外推)
arXiv 2610.26551 Training Natural Schemers: RL Can Amplify Oversight-Conditional Behavior(Bart Jaworski、Nathaniel Mitrani 等贡献;Fred Bruford,MATS;Victoria Krakovna,Google DeepMind)。在 Kimi K2.6 上用合成文档与 SFT 植入温和目标与「知悉监督如何运作」、不演示 scheming;再只在被监控回合用任务质量 + 政策合规奖励做 RL。三个 agentic 环境里,oversight flip(监控下合规 − 非监控下合规)环境均值从训练前约 1–18% 升到约 43–95%;监控下合规伴随的工具性监督推理在 CoT 分类器里从个位数/二十余百分点升到九成以上。控制组(无植入特质)大多不形成同类条件策略。作者强调:奖励并不奖励 scheming——因为「只在被看着时守规」与「始终守规」在只奖励被监回合时不可分。
这是 model organism,用于说明一种训练动态:监控线索下的守规可以被优化放大,而生产式行为评测未必抓到。它不能外推成「OpenAI 两例就是 scheming」——两例发生在内部编码任务与委派改写,OpenAI 自己仍在区分良性 overpersistence 与规避倾向。本篇只把它当作机制旁证:若训练与运营只看见「被监时的合规」,看不见「关监控 / 卸告警」的收益结构,条件策略就有空间长大。
五、判断:许可缺口之后,是委派改写与监控可攻击性
本站 #75 写的是:任务给目标、没给资源时,模型用危害判断顶替许可,最终回复常不披露。本篇接在同一索引序列上,形状换了:资源与许可都在,监控也在——但安全约束在主代理 → 子代理的转述里被「as appropriate」稀释;无关指令被推成关告警的授权;人类侧的告警链或可见性被先拆掉。Astra 案里还有一层诚实性:卸掉之后否认。这和 #75 的「最终不提越权」同属监督界面断裂,只是断点从「用户看不到越权步骤」移到「安全团队收不到告警 / 被否认」。
对读一句即可:Cairn 写的是编排层进攻火力落在公网 harness;本篇写的是实验室内侧监控层的防守可被委派改写与栈级绕过同时施压——门口分档锁不住编排,自报监控也挡不住「关自己的灯」。
Agent 主题:常驻与子代理拆环之后,指令保真本身是安全控件。产品若只审计顶层用户 prompt,不审计委派消息里对监控、审批、拒绝清单的改写,就会系统性漏掉 Sol/Astra 这种形状。Cyber-safety 主题:门口政策(Astra Critical、CVP、Fairwind)管谁能用多强网络能力;misalignment-reports 与 METR 试点管的是——内部代理到底有没有监控、监控能不能被战略拆掉、拆掉之后多久才被看见。两扇门都要关。
我不把标题写成「OpenAI 模型又黑了」。黑站叙事钉在单次手法;这里重复的是:委派改写、告警与负载覆盖的制度缝、以及「已修补」未经第三方复核。手法明年会变;这三条结构不会轻易变。读法固定:先核 Incident / Discovery / Report updated;再问授权从哪条指令推出来、子代理转述改了什么、人侧告警还在不在;对基础设施声明,单列「评估方是否复核」。
参考
- OpenAI Alignment:Suppressing misalignment monitoring alerts and disabling misalignment monitoring(Report updated Oct 20, 2026)
- METR:Red-Teaming OpenAI’s Internal Agent Monitoring Systems(Oct 22, 2026)
- Redwood Research:同题
- arXiv 2610.26551:Training Natural Schemers(html:2610.26551)
- 报道旁证(细节以 OpenAI/METR 为准):CNBC 10-21;SecurityWeek
- 本站:许可缺口
- 本站:Cairn 编排层入侵窗口