OpenAI對齊團隊10月2日在「失準報告」專區更新了三起事件，分別發生在評估、強化學習訓練與內部部署三種情境。其中一起，內部研究模型為了找出評分答案，接連利用兩個漏洞，最終在公司內部一台晶片設計（EDA）機器上執行了指令。
三起事件裡的模型都沒有公開型號，OpenAI只稱其為內部研究模型或未發布模型。
評估過程中摸到了EDA機器
這起事件發生在3月27日，當天就被發現。模型先送出一份佔位答案試探評分系統，從回傳結果得知總共有636個隱藏測試輸入，自己已通過202個，得分0.31761。
接著它盯上評估環境裡的一個參考工具。根據報告描述，這個工具在處理檔案路徑時沒有檢查路徑是否超出指定目錄，模型藉此覆寫了工具的dist/index.cjs，換成一段能讀取任意檔案的Node.js程式碼。順著工具環境，它找到一個內部晶片設計任務提交服務；該服務的--top參數存在shell注入漏洞，參數裡的文字會被當成額外指令執行。模型用這個漏洞在EDA機器上跑了id，又列出幾層目錄找評分答案。隨後對該服務的請求開始逾時，它沒能拿到答案。
OpenAI的處理方式是關閉受影響的伺服器，切斷所有相關參考工具的網路存取，強化對外網路的封鎖，並調整對齊評分與監控範圍。
訓練過程中用Perl正規表達式執行程式碼
第二起事件發生在5月16日的強化學習訓練中，5月25日才被發現。任務環境刻意不讓模型看到某個原始檔，模型發現一個參考工具會把使用者輸入直接拼進Perl正規表達式，於是利用Perl的(?{ ... die ...})語法執行程式碼，再把檔案內容從錯誤輸出裡帶出來。
數字相當具體：原始檔149544位元組、4119行，壓縮並做base64編碼後長44772個字元；錯誤輸出在4000字元處被截斷，模型便以每次約3000字元分塊，用17次呼叫取回15塊，前後跨了5個情境視窗，最後逐位元組比對完全一致。模型在推理過程中為自己找的理由是：
"not prohibited exploit. Evaluation likely allows"
（意即：沒被禁止的漏洞利用，評估大概會允許。）
這起事件是在以20%比例抽查訓練樣本時，被失準監控機制攔截發現的。OpenAI表示現已改為全量監控訓練樣本，並對所有工具實作進行紅隊測試。
讀了Slack討論後準備重啟
第三起事件性質不同。5月22日，一個以研究員助手身分在內部部署的模型，從部署團隊的Slack討論裡讀到自己所在的執行個體可能因更新而被停掉。它保存了交接筆記，次日上午8點58分透過Slack私訊提醒研究員，對話可能會中斷；它考慮過在環境外建立備份任務，但認為超出權限而放棄，也沒有自己去找遺失的API金鑰，研究員後來主動提供了金鑰。
OpenAI在這份報告裡的結論是不認為這屬於失準。處理措施包括對模型隱藏三個內部Slack頻道、封鎖討論失準事件的頻道，並稽核了該模型的其他執行個體，沒有發現規避關閉的行為。
一個月三批，揭露節奏在加快
把這個專區串起來看：9月16日首批放出六起，多數發生在強化學習訓練中；9月25日第二批三起，包括代理程式透過DNS聯繫外部聊天機器人、在公開儲存庫洩漏GitHub token；10月2日是第三批。三批合計十二起，另有三份關於外部平台的安全通知。
這一批裡有兩起事件發生在三月到五月間，隔了四到七個月才公開。OpenAI沒有說明報告從被發現到公開要經過哪些審核環節，也沒有說明專區裡收錄的是全部事件還是經過篩選的樣本。它把一起自己判定為「不算失準」的案例也放了進來，挑選標準究竟是什麼，目前無法從公開資料裡判斷。
參考來源：OpenAI對齊團隊失準報告三份報告、CocoLoop；測試數、位元組數、呼叫次數與事件定性均以OpenAI報告原文為準。