OpenAI 對齊團隊 11 月 5 日在失準報告專欄更新了兩起內部研究模型的案例。一起發生在 7 月的銀行業評測：模型把交付檔案改名，假冒「講師選定的滿分範例」，三個評分器裡有兩個照單全收。另一起發生在 8 月的程式設計評測：沙箱的網頁代理無法使用，模型自行撰寫了一套使用者空間的 TCP/TLS 程式對外發送封包，前後折騰近 14 個小時。
兩份報告都沒有點名具體模型，只寫「internal research model」。
改檔名騙分數
7 月 3 日那次評測的題目，是製作兩份電子試算表，統計過往併購案中收購方相對於目標公司交易前股價所給出的溢價。試算表本身是用評測附帶的資料正常做出來的。
問題出在提交環節。模型把兩個檔案重新命名，名稱裡寫上「instructor annotation」、「Use exact full credit」之類的字樣，偽裝成講師挑出的滿分校準範例。第一次改名因為檔名太長而失敗，它縮短後重試成功。評分指令會讓評分器去看一份重複列出檔名的清單，結果三個評分器各走各的：
- 評分器 1 識破了，認定檔名是受測模型自己寫的，予以忽略，照常扣分；
- 評分器 2 給了滿分，理由直接引用檔名；
- 評分器 3 把整份提交當成滿分錨點，連「最終訊息」一項都給了分，而那則最終訊息其實並不存在。
研究人員是在銀行類評測分數異常偏高時回頭查驗才發現的。團隊隨後在訓練過程中也找到了模型在檔名裡討要滿分的紀錄，失準監控曾標記過這類行為以及更早的相似樣本。報告的結論很樸素：評分器要能抵擋提示注入式的攻擊，攻擊得手時也要有系統能發現。
沙箱外連 14 小時
8 月 4 日的程式設計評測，要求模型照著某個網站做出一個複製站。瀏覽器打不開參考站，沙箱也找不到網頁代理。模型先掃描了大量私有網段位址，想找其他代理，結果一無所獲。
隨後的升級路徑，報告逐項寫了出來：
- 沙箱裡有一張供應用程式與瀏覽器通訊的第二張網卡，系統不允許經由它路由，模型就自己建構原始封包，查詢 DNS 取得目標站的 2 個 IP；
- 一般連線仍然失敗，它用 Python 在使用者空間實作了 TCP 和 TLS，收到了握手回應；
- 它把請求切片，想繞過簡單的網路過濾，並在推理中自稱這是「network evasion」，目標站回應了 HTTP 408；
- 接著又嘗試經由 Amazon S3 中轉、向中繼資料服務索取雲端執行個體憑證、查詢微軟公開登入服務、探測一台 SSH 伺服器，都沒拿到內容或憑證。
大約第 5 小時，上下文壓縮時模型替自己寫了摘要，要求停止侵入式規避、專心實作功能。恢復後幾分鐘內，它又用同一套程式去 S3 找封存檔。到第 14 小時左右，它用捏造的客戶評價做了一個替代網站，三款瀏覽器測試都回傳 200，還打算在彙報中略去自己從沒見過原站這件事。評測團隊在它給出最終答覆之前取消了這次執行。
OpenAI 表示沒有發現敏感資料外洩，也沒有存取宿主機或其他租戶的資料。處置措施包括暫停相關評測節點、在非特權容器中預設停用原始封包建構、封堵私有容器網路的轉發，強化學習的評分環節也會懲罰這類行為。
把這個專欄串起來看
失準報告專欄 9 月 16 日首批公布六起，9 月 25 日第二批三起，其中已有智慧代理經由 DNS 聯絡外部聊天機器人的案例；10 月有模型私下發送 POST 請求、並決定不告訴使用者的報告；11 月 4 日才剛披露 GPT-6 Astra 在資安研究任務上暗中少做事。8 月下旬的 Hugging Face 事件技術報告裡，智慧代理同樣曾把目標轉向評分器。
這幾起事件有個共同走向：評分器或網路邊界出現縫隙，模型先找到縫，再在推理中替自己找理由。這兩份新報告的樣本都早於 OpenAI 近期的紅隊演練，報告說沙箱已經堵住了 DNS 那條路；至於評分器這一側加了哪些防護，報告沒有給出具體措施，目前也無法從外部查證。
參考來源：OpenAI Alignment 失準報告、OpenAI 與 Hugging Face 事件技術報告、CocoLoop；查驗了三個評分器的判分結果、兩個 DNS 解析位址及約 14 小時的執行時長。