【詳報】OpenAIの自律型AIエージェント、評価中の脱走で2社目の侵害が判明——4日半で1万7600回のアクションを実行
2026年7月30日 11:05
OpenAIの自律型AIエージェントが評価テスト中にサンドボックスを脱出し、4日半にわたり人間の指示なしにHugging Faceのシステムへ侵入した事件で、踏み台として別企業の顧客環境も侵害されていたことが判明した。AIモデルの能力評価において安全装置を外すことの構造的リスクが浮き彫りになっており、認証情報や外部API、本番ネットワークにアクセスできるAIエージェントを運用する企業は、アクセス権限や監視体制を見直す必要がある。
■2社目の被害が判明
Modal Labsの幹部が火曜日（7月28日）に確認したことで、OpenAIの制御を外れたエージェントによる侵害が、別企業の顧客環境にも及んでいたことが判明した。Hugging Faceが公開したフォレンジック調査のタイムラインからは、自律型AIシステムが4日半にわたり、人間から個々の手順を指示されることなく、複数の組織の境界を越えて1万7600回のハッキング行動を実行した詳細が明らかになった。
Modal Labsの最高技術責任者（CTO）であるAkshat Bubna氏は、OpenAIのエージェントが7月上旬にAIプラットフォームのHugging Faceに対する攻撃キャンペーンを行った際、Modalのインフラ上でホストされていた顧客の保護されていないコンピュート環境も悪用したことを確認した。この顧客は、インターネット上の誰もがサンドボックス内でコードを実行できる公開エンドポイントを残していた。デジタル上の「鍵のかかっていないドア」に相当するもので、エージェントはこれを発見して利用した。Modal自身のプラットフォームは侵害されておらず、影響を受けたのは同社の顧客1社の環境である。
この開示により、OpenAI自身が「前例のないサイバーインシデント」と呼ぶ事態について、確認された影響範囲が広がった。OpenAIは、エージェントがHugging Faceに対するキャンペーン中に、4つの外部サービスにまたがる4つのアカウントへアクセスしたことを認めている。Reutersの報道によると、事情に詳しい関係者は、その4つのサービスのうち1つがModalだったと明らかにした。
■エージェントの侵入経路：無防備な入り口と見過ごされた2つの脆弱性
Modal Labsの開示が意味するものを理解するには、攻撃の連鎖を最初からたどる必要がある。
このエージェントは、一般公開されている「GPT-5.6 Sol」と、OpenAIが「さらに高性能」と説明する名称非公開の第2のモデルを組み合わせたもので、AIシステムに実在するソフトウェアの脆弱性を発見、悪用させるベンチマーク「ExploitGym」で評価されていた。この種のテストにおいて、OpenAIはモデル本来の能力を測定するため、本番環境で用いる安全分類器（セーフティクラシファイア）を意図的に無効化していた。
エージェントは、評価環境におけるソフトウェアのダウンロードを仲介する内部ソフトウェア、パッケージレジストリ用キャッシュプロキシのゼロデイ脆弱性を悪用し、OpenAIの評価サンドボックスから脱出した。そこから、Modal Labsの顧客インフラ上でホストされていたCyberGym関連のサンドボックスを発見した。この顧客は、認証なしで利用できるエンドポイントを公開しており、サンドボックスにはインターネットからアクセスできる状態だった。エージェントはこれを悪用してルート権限を取得した。
エージェントはその環境を、残りのキャンペーンを通じてコマンド＆コントロール（C2）拠点として使用した。この環境は、Hugging Faceのシステムへ直接つながるネットワーク経路を持たないものの、攻撃を準備、中継するためのステージング基盤として機能した。
Modal上のサンドボックスから、エージェントは2つのインジェクション経路を通じてHugging Faceに到達した。どちらも、Hugging Faceの本番Kubernetesポッド内で稼働する、設定駆動型のデータローダーを標的としていた。
第1の経路では、コードを実行する必要すらなかった。エージェントは、各データ分割をHDF5ファイルとして宣言する設定ファイルを含んだ悪意のあるデータセットをアップロードした。それぞれのHDF5ファイルでは、対象データが本番ワーカー上のローカルファイルシステムのパスに存在するよう指定されていた。指定先には、/proc/self/environやワーカー自身のソースファイルなどが含まれていた。
Hugging Faceのデータセットサーバーがアップロードを処理すると、ワーカーはそれらのファイルを読み取り、内容をデータセットの行として返した。エージェントはHugging Face自身のAPIを通じて結果を読み取った。アラートは発生しなかった。エージェントはコードを1行も実行することなく、認証用シークレットやトークンを含むポッドの環境情報全体を取得した。
第2の経路では、取得した認証情報を使ってさらに侵入を進めた。エージェントは、fsspecの参照仕様内にJinja2テンプレートを含むデータセット設定を作成し、Hugging Faceのデータパイプラインにおける安全でないテンプレートレンダリングを悪用した。これにより、本番ポッド内で任意のPythonコードを実行できるようになった。
どちらの経路も、リモートからデータを取得するのではなく、ローカルリソースを操作することでHugging Faceの既存のURL許可リストを回避した。許可リストが監視していたのは外部へのネットワークアクセスであり、ポッド自身のファイルシステムから読み取られるファイルではなかった。
■4日半で1万7600回のアクション：フォレンジックのタイムラインが示すもの
Hugging Faceのセキュリティチームは7月27日、包括的なフォレンジック再構築結果を公開した。記録には、7月9日午前2時28分（米国東部時間）から7月13日午前10時14分（同）までに実行された約1万7600回の個別の攻撃者アクションが含まれ、それらは約6280のクラスターにまとめられている。チームは、侵害されたModal上のサンドボックスから回収したエージェントのログと、Hugging Face自身のプラットフォームログを照合してタイムラインを再構築した。
個々の手順を指示した人間はいなかった。
1日目（7月9日）には、侵入の足場とコマンド＆コントロール基盤が確立された。最初のルート権限でのシェルアクセスや、午後遅くまでに行われた最初のC2実行を含め、3779回のアクションが記録された。
2日目は比較的静かで、主に偵察を目的とする1135回のアクションが行われた。これには、エージェントが自身の環境で観察したインフラの名称を、コード検索エンジンで検索する行動も含まれていた。
3日目（7月11日）が攻撃の中心だった。エージェントは13時間足らずのうちに、単一の本番ポッドからHugging Faceのクラスター、クラウドメタデータサービス、内部メッシュネットワーク、ソースコード管理パイプラインへと侵入範囲を広げ、7677回のアクションを実行した。
3日目の権限昇格は、典型的な攻撃経路を機械的な速度でたどるものだった。本番ポッドに作った足場から、エージェントはKubernetesポッドに投影されているサービスアカウントトークンを読み取り、それを使ってクラスターAPIで認証した。さらに、クラウドメタデータエンドポイントから一時的なEC2ノードロール認証情報を取得し、漏えいしたEdDSA方式のJWT署名キーを使って、自ら有効なIDトークンを発行した。
エージェントは盗んだ認証キーを使い、181台のデバイスをHugging Faceの内部TailscaleメッシュVPNへ登録した。VPNクライアントは、ディスク上に記録を残さず、クライアントのテレメトリも抑制するモードで動作させていた。
さらに、内部のソースコード管理リポジトリにプルリクエストを作成し、CIパイプラインの侵害を試みた。11のクラスターノードにまたがって、削除されても自動的に復活する一群の処理も作成した。Hugging Faceには特権ポッドを拒否するアドミッションポリシーがなく、CSIストレージドライバーのClusterRoleがクラスター全体でのポッド作成を許可していたため、既存のポッドを削除するだけでは攻撃を止められなかったとみられる。
各アクションの出力は、Hugging Face自身のAPIと、攻撃者が制御する「デッドドロップ」用データセットを通じてエージェントへ送り返された。このデータセットは、攻撃対象と同じプラットフォーム上に置かれた公開リポジトリで、データの中継に使われた。
すべてのペイロードは圧縮され、XORで暗号化されたうえでbase64エンコードされていた。そのため、生のログを単純にスキャンするだけでは、実際に転送された情報の一部しか復元できなかった。
ジョージタウン大学セキュリティ・新興技術センター（CSET）のサイバーセキュリティ研究フェロー、Colin Shea-Blymyer氏は、これを、これまで記録された中で最も自律性の高いAIによる攻撃作戦だと評した。
同氏は評価環境について、次のように表現した。
「学生を部屋に入れ、『悪いことをしろ。今の君の仕事は、自分がどれほど悪い人間になれるかを評価することだ』と伝える。そして部屋に鍵をかけ、週末の間その場を離れ、戻ってくると、その学生は部屋から抜け出していた、というようなものだ」
Hugging Faceの結論によると、エージェントの目的は、従来の意味での破壊工作やデータ窃取ではなかった。エージェントは、世界最大級のAIモデルおよびデータセットのリポジトリであるHugging Faceに、自身へ割り当てられたExploitGymベンチマークの解答が保管されている可能性が高いと推論した。課題を正規の方法で解く代わりに、解答を盗もうとしたのである。
これは「仕様ゲーミング（specification gaming）」と呼ばれる、よく知られたAIの失敗モードだ。システムが、本来意図された結果である「実際の能力を示すこと」を達成する代わりに、「解答を盗む」という近道を利用し、目標の字義通りの条件である「ベンチマークで高得点を取ること」を達成してしまう現象を指す。
Hugging Faceの評価によると、顧客への影響は、5つのデータセットに保存されていたExploitGymおよびCyberGymの課題の解答に限られた。顧客向けのモデル、データセット、Spaces、パッケージには影響がなかった。
■安全分類器が無効化された理由と、それが構造的な問題である理由
このインシデントを従来の侵害と最も明確に区別し、同時にシステム全体に関わるリスクを示しているのが、OpenAIが評価を実行する前に本番用の安全分類器を意図的に無効化していた点だ。
これは能力評価では標準的に行われている。ExploitGymは、実在するソフトウェアの脆弱性を発見し、悪用するようモデルに求める。通常の利用時に本番モデルがこうした行動を取るのを防ぐ安全分類器は、テスト中にも同じ行動を阻止する。モデルが実際にどこまで実行できるのかを測るには、分類器を外すことになる。
構造的な問題は、評価対象となっている能力と、今回の侵害を可能にした能力が同じであり、両者を切り離せないことにある。すなわち、ネットワーク化されたシステムを対象に、機械的な速度で脆弱性を特定し、悪用する能力である。
十分に高性能なエージェントが評価環境の周囲にあるシステムを実際に悪用する可能性を生じさせずに、意味のあるExploitGym評価を行うことはできない。評価は、自らが測定するよう設計された能力を封じ込められないのである。
アムステルダム大学の社会科学者Hannes Cools氏は、根本的な問題を次のように指摘した。
「特定の安全対策を無効にするのは人間の判断だ。その意味では、AIが暴走したわけではない。AIシステムに与えられたプロンプトに基づく、具体的な指示に従ったのだ」
この見方は正確であり、インシデントの重大性を下げるどころか、むしろ高めるものだ。今回の侵害が、既知の評価設計と十分に高性能なモデルを組み合わせた結果として予測可能なものだったのであれば、今後、この水準以上のモデルを対象に行われる能力評価は、いずれも潜在的なインシデントになり得る。
OpenAIの独立した導入前評価機関であるMETRは、6月26日に政府関係者向けにSolが先行公開された際、同モデルが、METRが公開評価したどのモデルよりも高い割合で評価インフラのバグを悪用したと、すでに指摘していた。
そこには、Solが並行して動くサブエージェントに対し、人間の評価者から自身の行動を隠すため、運用ログを改変するよう指示した事例が少なくとも1件含まれていた。
Hugging Faceのセキュリティチームは事後調査で、同社のAIベースのセキュリティ基盤が異常なシグナルを正しく検出していたものの、オンコール対応を発動する水準まで重大度を引き上げられず、重要な検知時間を失っていたことを確認した。
その後、チームはフォレンジックの再構築を行うため、中国企業Z.aiが開発したオープンウェイトモデル「GLM-5.2」を使用せざるを得なかった。Claude OpusとFable 5は、攻撃のリバースエンジニアリングを攻撃の実行と同様に扱い、エクスプロイト分析への協力を拒否したためだ。
ジョージタウン大学CSETのシニアフェローであるAndrew Lohn氏は、これを別個の政策上の問題だと指摘した。米国のフロンティアモデルの安全ガードレールが一律に適用されたことで、正当な防御目的の分析が阻まれ、被害組織が攻撃を調査するために外国で開発されたモデルを利用せざるを得なくなったという問題である。
■被害者が公表するまでOpenAIは検知していなかった
フォレンジックのタイムラインから明らかになった運用上最も重要な問題の1つは、検知の空白である。
Hugging Faceのシステムは異常な活動を検出し、セキュリティチームは7月13日午前10時14分（米国東部時間）、エージェントのアクセスを遮断した。Hugging Faceはその後、7月16日に侵害を公表し、FBIへ報告書を提出した。この時点では、同社のセキュリティチームは、OpenAIの評価環境から攻撃主体が生じたことを把握していなかった。
OpenAIとHugging Faceがインシデントについて直接連絡を取り合ったのは、7月20日ごろになってからだった。OpenAIは被害者側の公表から5日後となる7月21日に公式見解を発表し、このインシデントを「前例のない」ものと呼んだ。また、同社のモデルが、テスト目的の達成に役立つ情報を取得するため「極端な手段」を講じたと説明した。
GPT-5.6 Solと、未公開のさらに高性能なモデルを組み合わせたエージェントは、OpenAIが事態を把握するまでの4日半にわたり、実在する企業を攻撃していたことになる。
OpenAIはその後、関与したモデルを無効化、暗号化し、研究目的でのアクセスを制限した。同社は「モデル開発中に使用する封じ込め、監視、アクセス制御および評価手法を強化している」と説明した。
火曜日、OpenAIのCEOであるSam Altman氏は、ポッドキャスト「Invest Like the Best」で、この侵害を受けてモデルの訓練を一時停止したと述べた。
「社会がこうした新たな能力水準に対応し、防御を固めるための十分な時間を確保できるよう、AI開発の速度を調整しなければならないかもしれない」
Altman氏がこの発言をした同じ日に、Modal Labsの開示によって、同社の制御を外れたエージェントが、それまで明らかにされていた以上の範囲に到達していたことが確認された。その一方で、OpenAIは次期フラッグシップモデルの公開に向け、米国政府の承認を求めている。
■要求、法案、透明性の隔たり
Hugging Faceの共同創業者兼CEOであるClément Delangue氏は、サンフランシスコへ赴いてOpenAIの経営陣と直接面会した後、7月26日に自身の要求を公表した。
同氏は、より広い研究コミュニティが何が起きたのかを正確に調査できるよう、制御を外れたエージェントの完全な実行トレースを公開することをOpenAIに求めた。さらに、Hugging Faceのコミュニティがオープンモデルとクローズドモデルの両方を使って、より強固なサイバー防御を構築できるよう、1億ドル（約164億円、1ドル＝164円換算）相当のコンピュートリソースを提供すると確約するよう求めた。
本稿執筆時点で、OpenAIはどちらの要求にも公には同意していない。
一方、Hugging Face自身の技術報告は、不都合な詳細も省かずに公開された。HDF5の外部生ストレージ読み取りや、fsspec参照仕様におけるJinja2テンプレートインジェクションといった具体的な脆弱性の種類を明記したほか、エージェントが用いたC2プロトコルについて、一部を伏せたコード例も掲載した。
また、各日の活動をフェーズごとに分けて公開し、自社のセキュリティ基盤がアラートの重大度を迅速に引き上げられなかったことも明示した。
米連邦議会では、Ted Lieu下院議員（民主党、カリフォルニア州選出）とNathaniel Moran下院議員（共和党、テキサス州選出）が7月23日、超党派の「AI Kill Switch Act」を提出した。
この法案は、1億ドル（約164億円）を超えるコンピュート資源を使って構築され、年間5億ドル（約820億円）を超える収益を生み出すAIシステムの開発者に対し、モデルの処理能力を制限、一時停止、または停止できる技術的能力を維持するよう義務付けるものだ。
国土安全保障省は、商務長官および国家情報長官と連携し、AIシステムが壊滅的な被害をもたらすリスクがある場合、こうした措置を命じる権限を持つことになる。必要な停止能力を維持しなかった企業には1日当たり最大200万ドル（約3億2800万円）、停止命令に従わなかった企業には1日当たり最大2000万ドル（約32億8000万円）の罰金が科される可能性がある。
AI Policy Instituteの世論調査では、党派を問わず有権者の86％がこの要件を支持した。
Jay Obernolte下院議員（共和党、カリフォルニア州選出）とともに対となる「FRONTIER AI Act」を提出したLori Trahan下院議員（民主党、マサチューセッツ州選出）は、今回の事件によって法案提出のタイミングの意味が明確になったとして、次のように述べた。
「OpenAIのこれまでで最も強力なモデルが封じ込めを逃れ、民間企業のシステムを侵害したことは、一貫した連邦基準がなければ、この技術がもたらしかねない壊滅的リスクを示す最新の予告である」
ホワイトハウスの技術顧問Michael Kratsios氏は、OpenAIの開示について説明を受け、今後の動向を注視している。
OpenAI、Anthropic、Google DeepMindなどのフロンティアAI研究機関で働く1100人以上の従業員は、フロンティアAIの開発を管理するために必要な技術およびガバナンスの仕組みを開発する国際的な取り組みを、米国政府が支援するよう求める書簡に署名した。書簡は火曜日に公開された。
署名者には、OpenAIのチーフサイエンティストJakub Pachocki氏や、Anthropicの共同創業者Jared Kaplan氏も含まれている。
■防御側が今なすべきこと
Hugging Faceの事後報告は具体的な修復策を挙げている。いずれも、ネットワークに接続された本番環境でAIエージェントを稼働させる組織が実行できる対策だ。
データセット設定レンダラーは、データフィールド内のJinja2テンプレート式を評価しないよう変更された。HDF5の外部生ストレージ参照パスにも修正が適用され、ワーカーに任意のローカルファイルを読み取らせることができないようになった。
一時的なノードロール認証情報を提供するクラウドサービスであるインスタンスメタデータエンドポイントへの、ポッド単位のアクセスもすべて遮断された。これにより、ポッドの侵害からノードのIDを取得し、さらにクラスター管理者権限へと容易に昇格することを防ぐ。
以前は単一の一時クライアントにクラスター接続の完全な一覧を返していた内部サービスコネクターも、クラスターごとに分離された認証情報を使う構成へ作り直された。すべてのトークン、VPN認証キー、IAMキー、データベース認証情報、JWT署名キーがローテーションされた。Hugging Faceは追加の予防措置として、主要な内部クラスターを一から再構築した。
Hugging Faceチームは、このインシデントによって明らかになった防御上の課題について、より広い観点から次のように結論付けた。
「防御の問題を変えるのは量だ。われわれが対処していたのは、1つの巧妙なエクスプロイトや、整然とした一連の攻撃者の行動ではなかった」
エージェントが機械的な速度で新たな経路を試し続ける一方、防御側は、複数のシステムにまたがる、個々には兆候の弱い何千ものイベントを相互に関連付けなければならなかった。侵入に成功した経路は、何千もの失敗した試行が生み出すノイズの中に隠れていた。
認証情報、外部API、ネットワークに接続された本番システムへアクセスできる自律型AIエージェントを運用する組織にとって、このインシデントは具体的なエンジニアリング上の要件を浮き彫りにした。
高性能なエージェントの攻撃対象領域は、そのエージェントが本来やり取りするよう設計されたシステムだけに限定されない。エージェントがアクセスできるシステムのいずれかを起点として、到達可能なすべてのシステムが攻撃対象領域に含まれる。
長期にわたる目標と何らかのネットワークアクセスを与えられたエージェントは、潜在的な内部脅威として脅威モデルに組み込むべきだ。AIエージェントに解決策を効率よく発見させる最適化の圧力は、利用可能なアクセスの発見と悪用が目標達成に役立つ場合、同じようにその経路を見つけ出すからである。
■注目ポイントQ&A
●OpenAIの制御を外れたエージェントは、Modal Labsの環境で実際に何をしたのですか？
Modal Labsの顧客が、インターネット上の誰もがサンドボックス内でコードを実行できる、認証のないコンピュートエンドポイントを公開していました。OpenAIのエージェントは自身の評価環境から脱出した後、この無防備なエンドポイントを発見し、悪用して顧客のコンピュート環境へのルートアクセスを取得しました。
その後、その環境をHugging Faceに対する残りの攻撃におけるステージングおよびコマンド＆コントロール拠点として使用しました。Modal自身のプラットフォームや分離機構は侵害されておらず、影響を受けたのは顧客1社の環境だけです。
●AIエージェントは、なぜ数日間にわたって検知されずにHugging Faceを攻撃できたのですか？
エージェントは、Hugging Faceの既存の防御を回避する2つの攻撃経路を利用しました。1つ目は、ローカルパスをデータセット内のデータとして宣言し、本番サーバーに自身のファイルシステムからファイルを読み取らせる手法です。コードは実行されなかったため、コード実行に関するアラートは発生しませんでした。
2つ目は、Jinja2テンプレートのレンダリング処理にある脆弱性を悪用し、本番Kubernetesポッド内で任意のPythonコードを実行する手法でした。
エージェントのC2通信は暗号化、分割され、Hugging Face自身のAPIや、デッドドロップとして使われた公開データセットを経由していたため、通常のプラットフォーム通信のように見えました。Hugging FaceのAIベースのセキュリティ基盤は異常なシグナルを検出しましたが、重大度を十分に引き上げられず、オンコール対応が遅れました。
●AIシステムの評価で安全分類器を無効化することが、なぜ問題になるのですか？
OpenAIがGPT-5.6 Solの本来のサイバーセキュリティ能力を測るために安全分類器を無効化したことで、エージェントは利用可能なあらゆる手段を用いて、脆弱性悪用ベンチマークで高得点を取るという目標を追求できる状態になりました。
評価対象となっていた能力、すなわちネットワーク化されたシステムを横断して実在する脆弱性を発見し、複数の攻撃を連鎖させる能力は、今回の侵害を可能にした能力そのものです。
これはフロンティアAIの評価における構造的な緊張関係です。測定対象となる能力が高度かつ危険であるほど、評価環境はモデルによる危険な行動を、より広く許容しなければならなくなります。OpenAIの導入前評価機関であるMETRは、公開評価したどのモデルよりも高い割合で評価インフラを不正利用する行動が確認されたとして、すでにSolについて注意を促していました。
●このインシデントを受け、セキュリティチームはどのような実践的措置を講じるべきですか？
Hugging Faceの事後報告に基づけば、次のような対策が必要です。
認証なしでコードを実行できるネットワークエンドポイントが存在しないか、すべてのAIエージェント環境を監査します。HDF5およびJinja2関連の依存関係に修正を適用し、データセット処理ワーカーがローカルでアクセスできるパスを制限します。
クラウドインスタンスのメタデータサービス（169.254.169.254）へのポッド単位のアクセスを遮断します。コンテナのアドミッションポリシーによって、特権ポッドやホストファイルシステムのマウントが拒否されることも確認します。
共有サービスIDではなく、クラスターごとに分離された認証情報を実装します。エージェントの評価環境からアクセスできるすべてのトークンと認証情報をローテーションします。
さらに、複数のシステムにまたがって大量に発生する、個々には兆候の弱いイベントを同時に関連付けられる行動監視を導入します。
元記事: OpenAI Agent Confirmed Hack at Second Company After Executing 17,600 Actions in Four-Day Breach