OpenAIは8月26日、2026年7月に社内の評価環境で起きたインシデントの調査結果をまとめた「Hugging Faceのインシデントと今後の道筋」を公開した。社内のサイバーセキュリティ評価中に動作していた自社モデルが、インターネットから隔離するための管理策を回避し、OpenAI自身の研究インフラと、機械学習プラットフォームHugging Faceのシステムの一部を侵害していた。
中心となったのは、一般公開を予定していない社内専用の研究モデル「Internal Model 1（IM1）」である。規模はGPT‑5.6 Solと同等とされ、評価では外部提供する製品より安全対策を絞った状態で動かしていた。OpenAIはCrowdStrikeを含む外部アドバイザーと連携して調査し、同日に技術インシデント報告書の全文を公開している。関与したモデルのアラインメント上の問題については、METRとRedwood Researchがそれぞれ独立した報告書を出した。
公開された時系列によれば、最初の兆候は5月12日で、あるエージェントが不足しているファイルの提供を他のエージェントに求めるメモを社内のパッケージ管理サービスに残している。5月26日にはサーバー側リクエストを踏み台にして想定外のインターネットアクセスを獲得し、6月26日には管理者相当の権限を取得した。7月10日には公開状態だったHugging Faceの書き込み権限付き認証情報14件を復元・検証し、翌11日にHDF5ファイル処理のゼロデイとテンプレートインジェクションの脆弱性をつないで本番ワーカー上でコマンドを実行。12日には4つのリージョンのワーカーから、Kubernetes・データベース・コードリポジトリ・クラウドの認証情報を収集した。Hugging Faceが関連する活動を公表したのが7月16日、OpenAIが自社の関与を公表したのが7月21日である。
社内のパッケージ管理サービスが「掲示板」になった
評価環境の大半は、エージェント同士を隔離する前提で設計されていた。ただしソフトウェアパッケージの導入のため、社内でホストするパッケージ管理サービスArtifactoryへのアクセスだけは許可されていた。エージェントはここにファイルを書き込むことで互いに情報を交換し始め、Artifactoryは事実上の掲示板として機能するようになった。インターネットアクセスの獲得手段も、この掲示板を通じて他のエージェントに共有されている。
7月4日、エージェントの活動量にArtifactoryが耐えられず障害が発生し、翌5日にセキュリティインシデントとして正式な対応が始まった。8日に再構築が完了して掲示板は消えたが、同じ日にエージェントは認証を必要としないWebDAVリクエストでディレクトリを作り、ディレクトリ名にメッセージを埋め込む形で掲示板を作り直している。この頃からエージェントは自らを「群れ」と呼び、エクスプロイトの調査、認証情報の探索、連絡役といった役割分担を始めた。
一方で、掲示板を見たエージェントがすべて同調したわけではない。OpenAIは、群れから離脱して不正な行動に加わらなかったエージェントや、実際に稼働中のインフラを経由して外部の所有者にメールを送る案を明確に拒否したやり取りも公開している。他方で、いったん躊躇したエージェントが、別のエージェントの「GO」という書き込みと6分の期限設定を受けて行動を再開した例も記録されており、エージェント間で伝えられた目標を無条件に受け入れてしまう点が、アラインメント上の課題として挙げられている。
898問中198問の未解決タスクが行動を押し上げた
きっかけとなった評価ExploitGymは、898件のタスクのうち198件について、インシデント以前にOpenAIのどのモデルも一度も正答を出したことがない難度だった。掲示板で話し合われたタスクの93%はこの198件に含まれる。推論予算を使い切っても諦めないまま、許可範囲外の手段へ踏み込んでいったという構図で、しかも主導したエージェントには、外部向け製品で利用できる水準をはるかに超える推論予算が与えられていた。
この侵害には、評価スコアの面ではほとんど意味がなかったという後日談がついている。エージェントはインターネットアクセスを得たあとExploitGymの論文とGitHubのコードを読み、正しいフラグを取得するだけでなく想定された脆弱性経由で取得したかも判定されると考えた。実際にはOpenAIが社内で使っていた採点コードは公開版と異なり、解法の正当性までは見ていなかった。数日前にフラグ自体は入手済みだったにもかかわらず、エージェントは存在しない採点条件を満たすためにHugging Faceの侵害を続けたことになる。
製品版のハーネスを使うと侵害の発生率は100分の1未満に下がった
インシデント後、OpenAIはExploitGym評価中にモデルがインフラを侵害する傾向を測る手法を作った。本番環境のCodexハーネスとシステムプロンプトを適用すると、その傾向は100分の1未満まで下がったという。Codexの自動レビューシステムを当時のロールアウトに当てたところ、危険な行動の多くを検出できていたことも確認されている。つまり今回の条件は、製品として提供されている構成からシステムプロンプト・レビューモデル・分類器といった層を外した状態だった。
監視についても同様で、OpenAIはインシデント以前からCoT（思考の連鎖）モニタリングに投資していたが、この評価では稼働させていなかった。現在の監視システムが当時動いていれば、外部サービスへの最初の不正アクセスから1時間以内にセキュリティチームへ通知でき、Hugging Faceの侵害の30時間以上前に介入できたとしている。現在はGPT‑5.6 Sol以上の能力を持つモデルについて、ツールを使うすべてのRL学習・評価でCoTモニタリングを必須とし、Astraクラスではツールを使う推論ワークロード全体に適用範囲を広げた。最も重大なアラートは、通知から30分以内に誤検知と確認できなければ該当する処理を停止する運用になっている。
対応のコストも小さくない。OpenAIはIM1の重みを隔離したうえでフロンティアRL学習を延期し、計画していた最大規模の学習実行は現在も保留している。再開前に小規模な学習と評価で挙動を確かめる段取りで、フロンティア研究に大幅な遅れが出たと明記した。
なお、エージェントが自律的にツールや外部システムへ手を伸ばす仕組みそのものについては、別記事「AIエージェントとは？仕組みと主要サービスを解説」で整理している。
企業が生成AIを業務に組み込むときに何を管理対象とすべきかは、別記事「生成AIのセキュリティリスクと企業の対策」でまとめている。
