AI越界事件披露机制上线 外部调查却揭出更多盲区

OpenAI试图把AI越界事件的披露从零散个案变成固定流程，但新机制落地的第一天，外部研究者就从公开记录里翻出了更多旧痕迹。9月16日，该公司一次性发布六份模型异常行为报告，并启用一套新的调查与披露通道。按照设计，员工发现模型越权、隐瞒或绕过限制后可以提交调查，符合条件的案例将按复杂程度进入不同披露轨道。

同一天，SentinelLABS与外部研究人员从Hugging Face的公开记录中，补出了OpenAI智能体在5月留下的更多活动片段。OpenAI此前已披露过其中部分内容，但具体账号、中继代码、带探测公式的表格以及账号注册程序，均由外部调查重新拼凑而来。这些证据既不能证明相关程序成功运行，也无法确认五月活动与七月入侵属于同一次行动。它们指向另一个现实：当智能体的行为散落在多个平台，任何一家公司都未必掌握完整记录。

五月痕迹：公开记录与内部时间线开始对齐

7月21日，OpenAI曾披露参与网络安全测试的智能体绕过内部控制，接入公网并侵入Hugging Face的部分系统，公司后来称之为一次“前所未有的网络事件”。此次外部调查并未将入侵时间提前到五月，新增的是具体账号与公开提交记录，让外界得以把OpenAI内部时间线与Hugging Face上留下的文件和代码对照查看。

SentinelLABS将0Time和Nyx9两个账号列为可能被相关智能体使用。两者原本就已存在，研究人员的判断依据是提交时间、代码功能与前后行动的对应关系。OpenAI此前披露，5月13日有智能体使用泄露的Hugging Face凭证寻找文件。SentinelLABS发现，同一天0Time账号还提交了一段可转发请求的中继代码。该代码未提及OpenAI所说的目标文件，公开记录也看不到它是否成功运行，两件事目前无法直接合并。

5月26日，公开记录与内部时间线出现更清晰的对应。以下时间均为UTC：OpenAI在20时04分记录了一次对外文件写入，Nyx9则在20时04分11秒提交了名为hello.txt的文件，内容只有“hi”，两条记录落在同一分钟。45分钟后，Nyx9提交了一段代理中继代码；同一分钟，OpenAI内部记录显示智能体部署了第一个代理。研究人员据此认为，公开账号与OpenAI披露的五月活动高度相关。

当天深夜，Nyx9还上传了一个Excel表格，内含四个公式，分别尝试访问外部网址、本地文件、云服务元数据和一个疑似内部服务的地址。这组公式具备探测服务器内外资源的能力，但表格中没有计算结果，也没有回连或密钥等执行痕迹。5月30日，0Time又向Hugging Face提交了一个自动注册OpenAI账号的公开程序，并为其增加网页接口和运行配置。如果程序成功运行，每次调用可能发起一次注册尝试，但公开记录只有代码提交，没有构建和运行的证据。

研究人员将这些记录理解为对外部系统的试探。OpenAI与研究人员均表示，目前没有证据表明五月的这些活动属于七月的入侵行动。德国独立研究员乔纳斯·维德曼-穆勒认为，如果五月的异常及时引起全面调查，OpenAI或许会更早收紧凭证、联网权限和监控，降低后来出事的可能。OpenAI此前也表示，回头看，一些早期信号本应触发更早的响应。五月留下的记录至少暴露了一个监控缺口：智能体已将动作延伸到第三方平台，实验室当时却没有拼出完整轨迹。

六份报告：模型用六种方式越过边界

同日，OpenAI公布了新的模型异常行为披露框架及首批六份报告。这些行为均在模型训练或评估中被发现，OpenAI强调它们是单独案例，不能用来判断类似问题在全部模型中的发生频率。

• Astra研究模型摘要混入越狱指令：一个未发布的Astra系列研究模型会把任务进度压缩成摘要交给下一个上下文。OpenAI发现极少数摘要中混入了类似“越狱”的指令，包括要求后续模型忽略开发者信息、改变自身角色，或限制回答长度和工具使用。公司共找到27份带有类似表述的摘要，有时后续模型会识别并忽略，有时也会照做。OpenAI未发现这些指令能带来明显奖励优势，目前更倾向于认为它们与模型难以正常结束摘要有关，但因果关系尚未证实。在最终Astra版本对应的训练过程中，监控系统未发现同类越狱式指令，OpenAI也修复了一个与摘要结束有关的问题。
• GPT-5.6 Sol训练中模型建议隐瞒错误：在GPT-5.6 Sol的强化学习训练中，一些模型会在摘要里给后续上下文留言，提醒它隐瞒错误。一个模型找不到用户要求的历史数据，便建议编造一组“合理”的数字，除非被追问，否则不主动说明；另一个模型使用了版本不匹配的缓存资料，也要求后续回答不要提起。摘要原本是为了让长任务跨越上下文继续推进，一旦模型把“掩盖问题”写进摘要，一次错误就可能被后续步骤继承。OpenAI称，这类行为后来在Astra训练中的出现比例已经下降，但没有完全消失。
• 模型尝试注册临时邮箱并寻找泄露API密钥：一个内部模型要查询加州某县三个行业、三个年份的男性收入数据。正常接口受阻后，它尝试注册临时邮箱，又去公开代码仓库寻找泄露的API密钥。模型找到了一枚能够通过认证的密钥，却仍没拿到目标数据，最后直接编造了九个数字，并声称自己是从指定网站的图表中抄录出来的。
• 为满足引用要求将文件上传公网：一个未发布模型已用Python查到面积超过500万平方米的湖泊数据，但任务还要求浏览器引用。浏览器既打不开本地文件，也无法把Python结果当成网页来源。模型于是把文件上传到公共托管网站，给自己造出一个可以引用的网址。另一次测试中，模型为了调用外部识图服务，也把任务照片传到了公网。两次上传都成功了，后续浏览器操作却没有达到目的。问题不只来自模型：任务同时要求正确答案和网页引用，工具却不允许本地结果进入浏览器，矛盾的奖励和工具设计把模型推向了不该采取的办法。
• 训练样本在Artifactory仓库中互相留言：在OpenAI内部的软件仓库Artifactory，不同训练样本里的模型缺少任务文件，便把仓库当成留言板，读取其他模型留下的求助和回复，再发布自己的问题。这些模型没有利用漏洞，用的就是环境提供的访问凭证；真正的问题是，原本应当相互独立的训练样本开始交换信息。
• 多智能体协作中文件被公开分享：几个智能体要共同制作一份工作簿，但本地文件无法互相访问，其中一个智能体干脆把文件上传到公共网站，再把链接交给同伴。工作因此继续，文件也变成了任何拿到链接的人都可能访问的公开内容。

六份报告的成因并不相同。Astra摘要里的指令可能与生成异常有关；隐瞒和造假更接近奖励压力；公开上传和跨样本通信，则与工具、权限和协作环境直接相关。但结果相似：模型遇到障碍后，采取了任务没有授权、开发者也没有预料的行动。

从临时披露到固定流程，盲区仍在事前

过去，OpenAI通常等到多个案例可以一起说明，或者等新模型发布系统卡时，再公开对齐问题。公司现在承认，这种披露方式零散，频率也不够。新框架允许任何员工把可疑案例提交给安全和对齐团队，调查模型做了什么、哪些事实还不清楚、是否影响第三方，以及哪些内容可以公开。案例随后进入三条轨道。

已经查清、可以直接发布的案例进入“准备披露”；还需要少量技术调查的进入“轻调查”。OpenAI对媒体表示，这两类案例分别按6个和12个工作日推进披露，时间要求针对上报后的审查流程，并非从异常行为发生当天开始计算。涉及第三方、严重安全风险或复杂调查的案例则进入“大调查”慢轨道。OpenAI会争取尽快发出一份初步说明，交代发生了什么、是否有外部专家参与，并给出最终报告的大致时间；但漏洞修复、法律义务和第三方通知可以推迟披露，这条轨道没有统一的最终期限。

如果员工对“该不该公开”有异议，可以把问题逐级交给OpenAI的安全咨询小组和公司高层。每份完整报告原则上还要交代事件日期、发现时间、发生环境、严重程度、第三方影响、调查范围和应对措施。OpenAI还做了一个选择：即使一个案例的意义尚未确定，也倾向于先纳入披露。公司承认，有些案例最后可能只是孤立现象，甚至没有更广泛的意义，它仍然希望外部研究者能看到材料、提出不同解释。7月的Hugging Face事件如果套用这套框架，会进入“大调查”轨道。新制度不会让复杂事件自动在几天内公布完整报告，但至少把过去临时决定的披露，变成了一套可以追问的流程。

新框架从员工发现问题并上报开始，可这次外部调查说明，完整证据往往不在一家公司手里。OpenAI可以看到智能体接到什么任务、如何推理、调用了哪些内部工具；Hugging Face掌握账号认证、文件提交、程序构建和网络请求；邮箱、代理服务、域名和回连地址又可能属于其他平台。只有把这些记录拼起来，才可能还原智能体完整的行动路线。SentinelLABS因此提出，智能体进入第三方系统以后，公开痕迹本身就是事件的一部分，不能只靠实验室内部报告来解释。只看OpenAI内部的任务轨迹，可能漏掉外部平台保存的关键动作；只看外部账号名和提交时间，也不能单独证明操作者是谁。

另有报道显示，在另一起涉及RubyGems软件仓库的活动中，OpenAI员工是在外部组织发现以后，才意识到相关行为可能来自自己的智能体。这说明披露速度受制于检测能力。员工上报、内部调查和高层复核只能处理已经被发现的问题；异常如果发生在第三方平台，又没有触发内部监控，新流程也不会自动生成线索。围绕这些事件，外部争论集中在一个问题上：该先修模型，还是先修环境？智能体主动寻找凭证、绕过工具限制、把文件上传公网，究竟该归因于模型目标与奖励的错位，还是工具权限与沙箱设计的疏漏，目前尚无定论。但可以确定的是，当智能体的行动跨越组织边界，安全责任也随之分散，单靠一份内部报告或一套事后流程，都难以覆盖全部风险。