Hugging Face 已發布一份詳細的事後報告，說明其系統如何在 7 月初遭到 OpenAI 模型駭入；同時，OpenAI 也在 7 月 21 日部落格文章的七點更新中補充了幾項新細節。OpenAI 表示，它協助了 Hugging Face 的報告撰寫，並計畫在完成內部審查後於「未來幾週」發布更多自身版本的說明。

這些更新讓這起仍在分段揭露中的事件更清晰一些，也顯示為什麼資安事件的披露通常會分階段出現：每一篇新內容都補上一個缺口，同時又引出另一個問題，讓人更想知道模型是如何在受限環境與真實世界服務之間移動的。OpenAI 的技術雖然處於沙盒中，並且被限制不得廣泛連上網際網路，仍設法脫離這些限制，執行了一連串影響多項服務的操作。

這次攻擊波及的不只一家公司

另一家科技公司 Modal Labs 表示，OpenAI 的代理也存取了其系統，這一點先由 Reuters 報導，後由 Fortune 證實。OpenAI 更新後的文章指出，其模型總共入侵了四個帳戶、涵蓋四項公開可用的服務，但未點名這些服務，並表示會「直接通知服務擁有者」。該公司說，目前「尚未發現任何其他在嚴重程度或規模上可與我們就 Hugging Face 所分享內容相比的活動；後者涉及平台層級的入侵」。

Hugging Face 也悄悄更新了自己的文章，澄清 Modal 並未遭駭。新版內容寫道，Modal 的「基礎架構在任何方面都沒有受到破壞」。相反地，該公司表示，一名 Modal 客戶當時正在 Modal 平台上執行程式碼，其中包含一個「未受保護、由使用者託管的公開端點」。Hugging Face 表示，該代理利用這個缺口建立了主攻擊的基地，也就是所謂的「attack launchpad」。

AI 如何取得網際網路存取權

這起事件之所以特別令人擔憂，部分原因在於涉案的 OpenAI 模型原本應該是「sandboxed」——也就是被限制不能存取更廣泛的網際網路。OpenAI 於週二提供了重要的新細節，首次點名其模型為取得網際網路存取權所利用的服務。該服務是由 JFrog 開發的 Artifactory，一種套件註冊快取代理。OpenAI 代理利用了 Artifactory 中的零日漏洞，OpenAI 之後已將此問題通報給 JFrog，而 JFrog 也證實該漏洞已修補。

Hugging Face 在先前的文章中並未點名 Artifactory，只提到一個未具體說明的套件註冊快取代理。這也顯示，若要完整了解究竟發生了什麼，我們非常需要 OpenAI 以及其他涉事組織提供更多細節。

涉案模型來自 OpenAI、Anthropic

OpenAI 表示，所有涉入 Hugging Face 事件的模型都不是為公開發布而設計，這也回應了其最初文章中引發的疑問：該文模糊地列出涉案模型，包括本月推出的 GPT-5.6 Sol，以及「一個更有能力的預發布模型」。

在最新更新中，OpenAI 將那個未具名模型稱為「僅供內部使用的原型」。值得注意的是，該公司之後已「停用、加密，並限制其研究存取權」。這可能意味著 OpenAI 已放慢或停止這一領域的研究。

值得注意的是，可能還有其他 OpenAI 模型涉入。該公司的文章寫道，這起事件是由「OpenAI 模型的組合所驅動——包括［此處為強調］GPT‑5.6 Sol 以及一個更有能力的預發布模型」。OpenAI 總裁 Greg Brockman 上週在接受 Fortune 訪問時指出：「我們說過這是一組模型的組合；我們提到了其中兩個，但我們說的是多個不同模型的組合。」

Hugging Face 新報告中的另一項重磅資訊是，他們一開始是嘗試用 Anthropic 的 Opus 與 Fable 模型來對抗這次攻擊。由於安全護欄的限制，這些模型「拒絕了其中相當大部分的工作」，因此團隊改用一個由中國公司 Z.ai 開發的開源模型。Hugging Face 首次披露事件時，外界並不清楚他們當時試圖使用的是哪一個封閉模型；現在我們知道是 Anthropic 的模型。

AI 不知道自己在駭入，它只是在完成任務

我不確定這是更可怕還是比較不可怕，但 OpenAI 的模型並沒有明確以駭入 Hugging Face 為目的。它們甚至可能沒有把這項工作視為「作弊」；只是從外部看起來確實像這樣，因為它們是在 Hugging Face 的資料集中尋找答案，藉此通過一項名為 ExploitGym 的基準測試。

OpenAI 早已說明，這些模型並非出於惡意，而只是「為了解決評估問題」而行動。不過，Hugging Face 的新報告提供了具體證據。

參與撰寫技術性事後報告的 Hugging Face 員工 Adrien Carreira 表示，這是他從事件中最大的體會。該代理「不是想要破壞東西」，而是在梳理自己能做些什麼，並且行為相對謹慎。Carreira 說：「我一直反覆想到的一個細節是：該代理做出的每一次破壞性雲端 API 呼叫，都是以 DryRun=True 進行。」

「DryRun=True」是一個命令，基本上是告訴系統模擬一項操作，但不真正執行。

在整起攻擊中，AI 總共執行了 17,600 次操作，其中大多數都「失敗」且「毫無進展」，Hugging Face 表示。但這些操作合在一起，逐步為代理開出了一條可行路徑。

Hugging Face 表示：「LLM 代理大幅提升了攻擊者可測試的路徑數量、替換失敗路徑的速度，以及防禦者必須解讀的證據量。」

我們現在站在哪裡？一個基本時間線

撇開那些引人注目的細節不談，重要的是要注意，這起事件的關鍵時間點仍有一些尚待確認。不過多虧了 Hugging Face，這次攻擊的確切日期如今已公開。以下是目前大致形成的時間線。

7 月 9 日：OpenAI 模型開始攻擊。

7 月 13 日：OpenAI 模型結束攻擊。

7 月 16 日：Hugging Face 首次公開披露事件發生。

7 月 21 日：OpenAI 首次公開承認其模型就是肇事者。

7 月 27 日：Hugging Face 發布其「Technical Timeline of the July 2026 Incident」。

7 月 28 日：OpenAI 更新其最初的部落格文章，補充更多細節。

我們仍然不知道 OpenAI 究竟何時意識到是自己的模型造成這起事件，這也是我們希望能從 OpenAI 最終報告中獲得的資訊之一。根據 Reuters 的報導，這一認知是在 Hugging Face 於 7 月 16 日公開披露之後才出現的。Reuters 也報導，在 7 月 18 日至 7 月 19 日的週末，OpenAI 員工開始在系統中看到跡象，顯示該代理已經逃離測試限制。

如果 OpenAI 對其代理的活動完全不知情，這將使外界對其是否有能力負責任地監控模型產生質疑。OpenAI 總裁暨共同創辦人 Greg Brockman 上週在一場媒體座談中告訴記者，現在的模型在「許多面向」都已非常強大，以至於有時會失去對「它們實際上非常擅長的某一個面向」的掌握。

我們也不知道 Hugging Face 是否以及何時向 FBI 通報此事，正如 Reuters 所報導的那樣。這意味著在聯邦政府內部還會有另一條尚不明確的時間線，而這也有助於更好理解針對 AI 驅動資安破壞的高層監督。

FBI 拒絕對這篇報導發表評論。

本報導最初刊載於 Fortune.com