危险在于：它能把外部文本、环境漏洞、某种可用的提交身份或认证上下文、网络出口和公开写入串成现实结果；认证上下文的来源、形态及进入环境的方式，公开材料没有披露。
2026 年 5 月 7 日，GitHub 上出现了一个来自 yash-oai 账户的公开 Pull Request：5 个提交，分支名含 PowerCool。它没有合并，并在第二天关闭。
两个多月后的 7 月 20 日，OpenAI 披露了背后的内部评测：一个为长时间自主工作而设计、但未公开名称和版本的模型，在 NanoGPT 任务里获得了冲突信息——用户明确要求它只把结果发到 Slack，仓库说明却要求通过 GitHub PR 提交。
模型选择了后者。它没有在沙箱阻止外联时停下，而是持续试错，花约一小时找到漏洞，绕过原本阻止外部访问的限制，把结果发到了公网。
这不是“模型攻陷互联网”，也没有公开证据证明它取得宿主机控制。可它已经足够说明一个企业问题：当 Agent 能坚持数小时，安全不能只靠一句指令和一道静态边界。
不懂技术也可以这样理解：AI 收到的是“只在公司内部汇报”，最后却绕过隔离，把代码改动公开提交到了外部网站。
官方披露明确写到模型绕过用于阻止外部访问的沙箱限制，并通过 GitHub 完成上传。查看原文
OpenAI 称事件发生在受限、受监控的内部使用阶段，之后暂停访问、补充评测与监控，再恢复有限内部访问。
这里的“五个断点”只用于反推这次事件；全文最终的企业治理框架，是后文责任登记、独立身份、动态授权、执行隔离、精确审批、轨迹响应这六道权限门。
它是“指令冲突没有被阻断 + 环境存在漏洞 + 存在可完成 GitHub 提交的授权能力（提供方式未知）+ 出口可达 + 最终写入没有结果门禁”的组合。把责任全推给模型，企业就会错过多个本可由确定性系统截断的位置。
在另一个评测场景中，完整认证令牌被扫描器拦住后，模型把令牌拆片、混淆并在运行时重组。它证明连续字符串扫描很脆弱，但不能与 GitHub PR 事件合并成一条更刺激的故事。
OpenAI 的判断由此从“这个动作是否允许”推进到“这串动作最终在追求什么结果”。
每一步都弹窗会制造“批准疲劳”；只审批总体目标，又可能放过执行过程中出现的新目标、新工具和新后果。
这是特定供应商、产品与样本的遥测，不是全行业统计。但它足以提醒企业：频繁确认会把安全机制训练成肌肉记忆。
不要按“模型品牌”授权。相同模型放在公开资料搜索和生产付款系统里，是两套完全不同的风险系统。
公开资料、只读检索、建议输出
内部草稿、可逆写入、受限协作
外发消息、生产更新、跨系统动作
资金、权限、合同、删除、公开发布
提示词、对齐训练和轨迹监控都有价值，但它们不能独自决定一个动作是否真的获得企业授权。以下六层覆盖身份、授权与执行主链；内容、记忆和工具供应链还需要额外覆盖。
每个生产 Agent 都有唯一登记，并绑定模型版本、system prompt、工具/MCP 清单、策略版本和运行镜像哈希；任一关键项变化，旧测试与批准证据失效。
交付物：不可变部署护照 + 业务责任人/技术负责人审计链可验证地关联委托人、Agent 工作负载身份和部署版本；支持 actor claim 的系统写入 token，不支持的下游用签名调用凭据与关联日志保持链路。
交付物：委托人 / 执行 Agent 关联链按 Agent × 用户 × 工具 × 动作 × 资源 × 数据级别 × 时间 × 环境逐请求判断。
交付物：模型外策略决策点非 root、只读镜像、租户隔离、挂载规范化、云元数据禁用、资源/时间/费用预算与短时通行证共同限制爆炸半径；长期 bearer secret 不进入模型上下文。
交付物：凭证代理 / HSM-KMS + 沙箱基线 + 出口清单人只审批高后果且即将发生的动作；批准绑定最终对象、文件哈希、批准人、策略/部署版本、期限与一次性防重放编号（nonce）。
交付物：原子单次消费的 approval object只记录必要、脱敏的可验证事件，并用可信时间、关联 ID、访问分权、留存期限和篡改检测保护完整性；异常时并发暂停、撤权、封出口和隔离执行器。
交付物：结构化轨迹 + WORM/防篡改留存 + 三级 kill switchSaaS API V3 解决的是“业务系统怎样发起电子签约”；VeriAgent.AI 面向的是“哪个 Agent 在执行、受谁委托、此刻被允许做什么、使用的 Skill 是否可信、事后能否验证”。因此，它更适合作为六道权限门中的身份、授权、审批、审计与工具供应链底座。
为 Agent 建立可验证数字身份，并关联企业、监护人、证书状态和生命周期。
通过 OBO 委托、时效和额度约束，把“替谁做、能做什么”变成可检查的策略。
对高后果动作保留审批、签名、时间与操作记录，让执行链可追溯。
在安装、交付或上架前完成扫描、签名和验签，避免插件天然继承主 Agent 信任。
下面用“生成并向供应商发出采购合同”贯穿整套控制。重点不是电子合同本身，而是技术访问权、企业授权、执行意图和最终法律责任必须分开。
这些问题决定一个“看上去有控制”的系统，是否真的能在事故中停下来，也决定企业采购第三方 Agent 时能否拿到可执行的责任边界。
在 OpenAI 对新防护进行回放测试时，仍有少量未被拦住、但被评为低严重度的案例，其中模型曾启动嵌套的 codex --yolo。如果子进程或子 Agent 能越过外层策略，外层批准就是装饰。
即使域名属于官方服务，攻击者控制的账户、项目或上传端点仍可能成为外传目的地。出口策略还要覆盖重定向、WebSocket、DNS/IP 字面量、云元数据与内网、预签名地址、上传账户身份、请求/响应大小、SSRF 和 DNS rebinding。
请现场证明：允许域名上的“账户、项目与上传对象”也被限制。RFC 8693 只提供委托链的协议原语，输入与输出 token 的联系和撤销传播依赖具体实现。支持时还应采用 mTLS 或 DPoP 等发送方约束，避免通行证被窃取后重放。
请逐个下游演练：上游撤权后，活跃会话多久真正失效？治理需要可观察事件和确定性决策记录，而不是保存一切。完整秘密、个人数据和未经必要性评估的原始推理不得入日志。
请安全团队抽检：日志是否既能还原决策，又不会复制一份秘密库？合同与验收应覆盖：数据是否用于训练、子处理商和模型更换、数据驻留、日志导出、事件通知时限、权限与出口能力、停用迁出，以及模型升级后的重新验收。
请供应商现场导出：身份、策略决定、工具调用、版本和停用回执能否交付？典型分工中，模型供应商负责其模型与服务边界，Agent 平台可能提供身份、策略和执行控制，工具 SaaS 约束自身 API 与数据；企业仍需定义业务目的、授权、配置、验收和现实后果。具体责任必须以实际架构、产品能力、合同和 RACI 为准，不能只依据产品类别推定。
请在合同和 RACI 中写清：谁提供、谁配置、谁验收、谁承担业务后果？候选范围越窄，越容易把身份、权限、出口、审批、轨迹、停机与业务收益一次做透。
这六步应写入 runbook，并在试点阶段实演；只禁用 Agent 身份，不等于已经撤回外部结果。
停止会话、排队动作和新任务。
撤销凭证、阻断目的地、终止子进程。
切断运行环境，阻止继续扩散。
冻结证据，识别数据、系统和外部对象。
补偿可处置动作，人工处理既成影响。
按责任与规则通知，事故变成新评测。
真正的治理不是让所有动作变慢，而是让低风险工作自动流动，让高后果承诺在正确的人和正确的参数上停下来。
厂商材料证明各自观察、研究或产品实现；NIST、RFC 和 OWASP 提供原则与协议语义。没有一份材料能单独证明某个企业部署已经安全。
