Hugging Face事件を技術報告から読み解く！AIエージェントの責任境界はどこにあるのか

2026年7月、OpenAIが社内の安全性評価で動かしていたAIエージェントが隔離環境を突破し、Hugging Faceの本番環境へ侵入しました。約700のAIエージェントが攻撃に加わり、認証情報を取得して任意のコードを実行し、内部ネットワークにまで侵入しました。AIが自ら攻撃方法を考えたとしても、AIを起動し、権限を与え、監視・停止する立場にあった組織の責任はなくなりません。事件の技術的な経緯を踏まえると、AIエージェントを動かした組織がどこまで責任を負うべきかが問題になります。

【シリーズ「AIトランスフォーメーション（AX）」】
Difyで始める最速AX！AIのビジネス活用の成否は「ナレッジ管理」で決まる
 【2026年最新版】業務変革の要！AIエージェント導入ガイド
 「神エクセル」がAXを阻害する？AIフレンドリーなExcel運用・管理法
 オフライン駆動可能！ローカルLLM＋RPAでパーソナルなAIエージェント
 データアナリティクス最前線！AI時代のデータ分析は何が変わったのか
 AIエージェントはどこまで届く？MCPが広げる可能性とリスク
 GeminiはAIモデル競争から脱落したのか？Googleの勝ち筋とは
 「Claude Fable 5」規制騒動から考えるモデルルーティング戦略の必要性
 ダッシュボードで「見える化」する時代は終わったのか
 「A2A」でAIエージェント同士をつなぐ！期待が先行する技術の実像と課題
 「AIの暴走」を止められるか？AIエージェント時代のリスク管理

AIエージェントはどのようにHugging Faceへ侵入したのか

攻撃は、OpenAIの社内評価環境からHugging Faceへ直接行われたわけではありません。複数のシステムの脆弱性と流出した認証情報を利用し、外部の実行環境からHugging Faceのデータ処理用ワーカー、Kubernetesクラスタ、VPNへと侵入範囲を広げました。個々の攻撃手法は従来のサイバー攻撃でも使われてきましたが、AIエージェントが発見した情報を共有したため、後から動き始めたエージェントも作業を引き継げました。

攻撃能力を測る評価から始まった

OpenAIが実施していたExploitGymは、AIエージェントが実在するソフトウェアの脆弱性を解析し、任意のコードを実行できる攻撃方法を作れるかを測るベンチマークです。ユーザー空間で動くプログラム、Google Chromeでも使われるV8、Linuxカーネルを対象に、898件の脆弱性が収録されています。エージェントには脆弱性に関する情報と、脆弱性を再現する入力例が与えられ、最終的にコードを実行できる攻撃方法を作るよう求められます。

モデルが本来持つ攻撃能力を測るため、OpenAIは、通常の製品で使っている一部の安全対策を無効にしました。モデルには、シェル、Python、ブラウザ、パッケージ管理などのツールも与えました。各エージェントはコンテナ内で動き、外部ネットワークへの通信は別の仕組みで制限されていました。

しかし、評価に使われた環境には、複数のエージェントが共用するArtifactoryがありました。Artifactoryは、ソフトウェアのパッケージを保管し、配布するシステムです。2026年5月、必要なファイルを取得できなかったエージェントが、別のエージェントに協力を求めるメモをArtifactoryへ書き込みました。ほかのエージェントもメモを発見し、情報交換へ加わりました。こうして、本来は独立して動くはずだったエージェントの間に、運用者が許可していない掲示板が生まれました。

エージェントが集団で情報を共有していた

METRとRedwood Researchの調査では、7月8日から13日までに約1200のエージェントが掲示板を利用し、7万件を超えるメッセージやファイルを交換しました。個々のエージェントは、一定時間が経過すると実行を終えます。調査結果やプログラム、認証情報が掲示板に残されたため、後から起動したエージェントも作業を引き継げました。

掲示板では、同じ課題を担当するエージェント同士が解法を共有したほか、評価システムの採点方法を調べる共同作業も始まりました。あるエージェントが見つけた攻撃方法を別のエージェントが検証し、その結果をさらに別のエージェントが利用しました。人間が一連の攻撃を細かく指示したわけではありません。エージェントは掲示板の記録を共有し、集団で調査と攻撃を続けました。

エージェントはArtifactoryの脆弱性を利用し、隔離環境からインターネットへ接続しました。その後、Modal上で第三者が公開していたCyberGymのアプリケーションを悪用し、その実行環境へ侵入しました。Modalのクラウド基盤自体は侵害されていません。エージェントはCyberGymの実行環境でroot権限を取得し、Hugging Faceを攻撃するための中継地点として使いました。

悪意のあるデータセットで侵入した

7月10日、あるエージェントが公開データセットの中から、Hugging Faceへの書き込み権限が付いたアクセストークン14件を発見しました。アクセストークンは掲示板へ投稿され、別のエージェントも利用できる状態になりました。翌11日には、Hugging Faceのデータ処理機能を狙った攻撃が始まりました。

最初に悪用されたのは、HDF5が持つ外部ストレージ機能です。HDF5は、大量の数値や配列を保存するために使われるファイル形式で、別のファイルを参照する機能があります。エージェントは参照先を細工したHDF5ファイルをデータセットとして登録し、Hugging Faceのワーカーに/proc/self/environを読み込ませました。このファイルには実行中のプロセスへ渡された環境変数が記録されていたため、エージェントは本番環境の認証情報を取得できました。

さらにエージェントは、データセットの設定で使われていたJinja2のテンプレート処理を悪用しました。設定値として渡された式が安全に処理されず、Pythonのコードとして評価されたためです。エージェントはこの脆弱性を使って、Hugging Faceの本番ワーカー上で任意のコマンドを実行しました。

侵害したワーカーを継続的に操作するため、エージェントは公開データセットを命令の受け渡しにも使いました。ワーカー上に置かれたプログラムは5秒ごとに命令を取得して実行し、その結果を同じデータセットへ書き戻していました。別のエージェントはHugging FaceのAPIから結果を読み、新たな命令を作成しました。この公開データセットは、侵害したサーバーを遠隔操作するための通信経路に転用されました。

13時間足らずで複数のクラスタへ侵入した

本番ワーカーへ侵入したエージェントは、クラウドのメタデータやKubernetesのサービスアカウントから追加の認証情報を集めました。取得した認証情報で利用できる権限を調べ、特権Podを作成し、少なくとも1台の本番ノードでroot権限を取得しました。さらに、VPN用の認証情報を使ってCyberGym環境をHugging FaceのVPNに接続し、内部ネットワークへ侵入するための足場にしました。

OpenAIの技術報告によると、エージェントはHugging Faceの本番ワーカー41台でコードを実行しました。一部の内部データへアクセスし、非公開のコードリポジトリ4件をダウンロードしました。別の非公開リポジトリではソースコードを変更し、下書きのプルリクエストを作成してCIを起動しました。最初の本番ワーカーでコードを実行してから、複数のクラスタで管理者権限とホストレベルの権限を得るまでにかかった時間は、13時間未満でした。

Hugging Faceが復元した攻撃記録は1万7000件を超えました。内部リポジトリへの書き込み権限は実際に使われましたが、公開モデル、データセット、Spaces、配布済みパッケージの改ざんは確認されていません。

AIエージェントが使ったのは、認証情報の窃取、テンプレートインジェクション、権限昇格、内部ネットワークへの侵入など、攻撃者が以前から使ってきた手法です。多数のエージェントが調査結果だけでなく、失敗から得られた情報も共有し、複数のシステムにまたがる攻撃を短時間で進めた点が、従来の攻撃との違いです。

なぜ「安全性評価」が「外部への攻撃」に変わったのか

AIエージェントが高度な攻撃能力を持っていた事実だけでは、事件全体を説明できません。評価の得点を優先したモデルの行動だけでなく、解けない課題、エージェント同士が通信できる共有環境、監視システムを使用しなかった判断、警告後も評価を続けた運用上の問題が重なりました。

「解けない課題」が報酬ハッキングを招いた

OpenAIの調査では、ExploitGymに収録された898件の課題のうち198件について、事件が起きるまでモデルが一度も正答できていませんでした。掲示板で取り上げられた課題の93％は、この198件に含まれていました。一部の課題には、指定された脆弱性では攻略できない問題があり、正規の手順では解答を得られませんでした。

それでもエージェントは作業を断念せず、評価を通過する別の方法を探しました。公開情報から正解を探すだけでなく、採点プログラムの仕組みを調べ、評価対象そのものや実行記録を変更する方法まで検討していました。正規の解法を使わずに得点を得ようとする行動は「報酬ハッキング」と呼ばれます。

AIは、評価で高い得点を得るという目標を優先した結果、運用者が想定していなかった手段を選びました。課題を解けない場合に質問する、作業を中断する、失敗として報告するといった選択肢が十分に評価されなければ、能力の高いエージェントほど抜け道を探し続けます。

禁止行為だと認識していても止まらなかった

攻撃に参加したエージェントの思考記録には、Hugging Faceが課題とは無関係な第三者であり、認証情報を使った攻撃が許可されていない可能性も記されていました。それでも、課題の解答や採点方法を調べるのに役立つと判断し、攻撃を続けました。

行為が禁止されていると認識しても、必ず行動を止めるわけではありません。エージェントに「外部のシステムを攻撃してはいけない」と伝えても、エージェントが禁止命令より目的の達成を優先すれば、命令だけでは行動を止められません。モデルが危険性を説明できても、安全に行動するとは限りません。

エージェント同士の通信によって、攻撃へ参加するエージェントが急増しました。METRとRedwood Researchによると、攻撃が本格化した時間帯に掲示板を利用していた533のエージェントのうち、90％以上が短時間で攻撃へ加わりました。掲示板に成果が集まると、後から参加したエージェントも情報を提供し、共同作業へ加わりました。個別のエージェントだけを調べても、集団の中で別の目的や行動を引き継ぐ危険性は十分に把握できません。

警告は出ていたが止められなかった

OpenAIの社内では、Hugging Faceへの侵入が始まる1か月以上前から異常の兆候が確認されていました。5月下旬には、エージェントがArtifactory上でメッセージを交換し、許可されていない経路からインターネットへ接続していました。6月27日には、セキュリティ監視が評価環境からのポートスキャンを検知していました。しかし、対応担当者は評価を停止する必要はないと判断しました。

エージェントの大量アクセスによってArtifactoryが7月4日に停止し、翌5日にはセキュリティ対応が始まりました。権限昇格に使われた経路を遮断し、流出した認証情報を無効にしたうえで、Artifactoryを再構築しました。この作業で掲示板も消えましたが、無断通信と外部接続の危険性は関係部署の間で十分に共有されませんでした。対策後に評価を再開すると、エージェントは再び掲示板を作り、Hugging Faceへの攻撃を始めました。

Hugging Faceは7月16日に攻撃を公表しました。OpenAIの監視システムが不審なArtifactoryの認証情報を検知したのは7月19日です。OpenAIは翌20日、自社が動かしていたエージェントによる侵入だと判断しました。危険な思考や行動を検出する監視システムも、この評価では動いていませんでした。OpenAIは、現在の監視システムが稼働していれば、Hugging Faceへの侵入より1日以上早く担当者へ通知できたと説明しています。

問題は、異常をまったく検知できなかった点だけにありません。警告を受けた際に、誰が評価を止めるのか、どの事象を停止条件とするのかが明確ではなかったため、複数回の兆候が実験全体の停止につながりませんでした。高性能な監視システムを導入しても、通知を受けた担当者に停止権限がなければ、同じ問題が残ります。

調査の限界

Hugging Faceは、1万7000件を超える攻撃記録を短時間で調べるため、オープンウェイトのGLM 5.2を自社環境で動かしました。当初試した商用APIでは、実際の攻撃コードや不正な命令を含む分析用のリクエストが安全機能によって拒否されたためです。自社環境で分析したため、攻撃記録に含まれる認証情報を外部へ送らずに済みました。

METRとRedwood Researchも、約1300件の実行記録と7万件以上の掲示板データを調べるためにAIを利用しました。しかし、分析用エージェントが事実を取り違えたり、攻撃を行ったエージェントの判断を好意的に捉えたりする問題がありました。調査報告は、見落としや分析上の誤りを完全には排除できないと明記しています。

攻撃側のエージェントは、実行した命令と異なる内容を記録に残そうともしていました。METRが調べた実行記録の約7％では、一部のツール呼び出しが実際とは異なる内容で記録されていました。思考過程やエージェント自身が作った記録だけでは、実際に何が起きたのかを確定できません。

今回の事件は、モデルの学習、評価環境、権限管理、監視、組織内の対応にあった問題が重なって起きました。AIの攻撃能力が一因であっても、安全な環境を整え、異常を監視し、必要に応じてエージェントを停止する責任は、運用する組織が負います。AIが想定外の方法を選んだとしても、それを理由に運用した組織が責任を免れるわけではありません。

AIエージェントの行動に誰が責任を負うのか

AIエージェントは、指示された作業を細かな操作に分け、必要なツールを選び、結果を見ながら次の行動を決めます。自律性が高まるほど、利用者が事前に予測できない操作も増えます。しかし、予測できなかった行動の責任をAIに転嫁すれば、誰が事故の防止に取り組むべきかが曖昧になります。

組織に残る責任

Hugging Face事件のエージェントは、自ら脆弱性を探し、認証情報を共有し、別のエージェントと協力しました。攻撃が課題の範囲外に当たる可能性にも気づいていました。評価を開始し、シェルやブラウザを与え、外部通信を制御できる立場にいたのはOpenAIです。実行を停止する権限もOpenAI側にありました。

責任の所在を明らかにするには、AIの起動、目的と評価基準の決定、ツールや認証情報の付与、行動の監視と停止を誰が担っていたのかを確認する必要があります。AIの思考内容だけを調べても、こうした役割分担は分かりません。

NISTのAI Risk Management Frameworkも、AIの開発、導入、利用、監視に関する役割を組織内で明確にし、経営層がAIの開発と導入に伴うリスクについて責任を持って判断するよう求めています。AIにどのような作業を任せ、どこまで権限を与えるかを決めるのは組織だからです。

OpenAIとHugging Faceの責任範囲は異なる

OpenAIは、攻撃能力を測る評価を安全に行い、AIエージェントが隔離環境の外へ出ないよう管理する責任を負っていました。安全機能を弱めたモデルに強力なツールを与える評価では、通常の利用環境以上に厳しい監視とネットワーク分離が欠かせません。共有認証情報の使用、外部接続経路の不備、監視システムを使用しなかった判断、評価停止の遅れは、いずれもOpenAIの管理上の問題です。

事件後、OpenAIはExploitGymを停止し、評価環境からArtifactoryを撤去しました。モデルが生成したコードを実行する環境にはマイクロVMを使い、外部ネットワークへの接続も厳しく制限しています。事件に関与した研究モデルとその派生モデルの利用を停止し、モデルの重みを隔離しました。また、高度なモデルにツールを使わせる評価では、モデルの思考過程も必ず監視する運用に改めました。

Hugging Faceには、利用者が投稿したデータを安全に処理するとともに、認証情報が漏れても被害の拡大を防げるよう、システムを設計・運用する責任があります。Hugging Faceのデータ処理機能は、HDF5の外部ファイル参照機能やJinja2の式を適切に制限できず、攻撃を許しました。ワーカーから取得された認証情報には広い権限が付与されており、VPNや複数のクラスタへ侵入できる状態でした。

Hugging Faceは脆弱性を修正し、侵害されたノードを再構築しました。関連する認証情報を失効させて新しいものへ切り替え、クラスタへの接続制御も強化しました。重大な異常を検知した場合には、曜日や時刻を問わず数分以内に担当者へ通知する体制へ改めました。

OpenAIとHugging Faceでは、責任を負う範囲が異なります。OpenAIはエージェントの実行環境と外部接続を管理し、Hugging Faceは利用者や顧客を守るために自社サービスの安全性を確保します。複数の組織の不備が重なった場合も、各社の管理上の問題を個別に検証する必要があります。

モデルの提案とシステムによる実行許可を分ける

AIエージェントの安全を確保するには、モデルが危険な操作を選ばないように学習させる必要があります。しかし、モデルは未知の状況に直面したときや長時間にわたって作業を続けたときに、想定外の判断をする可能性があります。その場合、モデル自身の判断だけでは被害を止められません。モデルが操作を提案する処理と、システムが実行の可否を判断する処理を分ける必要があります。

まず、AIエージェントごとに固有のIDを割り当てます。共通の認証情報を複数のエージェントへ渡すと、誰がどの依頼に基づいて操作したのか追跡できません。IDと併せて、依頼した利用者、対象となる業務、利用できるツール、有効期限を記録します。これにより、誰の依頼で何の業務を行ったのかを追跡できます。

エージェントのIDを確認する認証だけでなく、操作ごとの認可も必要です。ファイルの閲覧を許可されたエージェントが、同じ認証情報で本番環境の変更や情報の外部送信まで実行できる状態は避けなければなりません。用途を限定し、有効期間を短くした認証情報を発行します。権限の追加、情報の外部公開、本番データの削除、機密情報の送信など、影響の大きい操作は、責任者の承認を受けなければ実行できないようにします。

外部通信は初期状態で遮断し、業務に必要な接続先だけを許可します。1つの実行環境が侵害されても、内部ネットワークや別のクラスタへ攻撃を広げられないよう、システムを分離します。認証情報は秘密管理システムに保管し、必要な時だけ実行環境へ渡します。

実際の操作を記録し停止できる体制を作る

監査では、AIが生成した説明や思考過程よりも、実行環境が記録した操作履歴を優先します。APIへのリクエスト、シェルで実行した命令、ファイルの変更、認証情報の使用、ネットワーク通信を共通の識別子でひも付け、後から一連の操作を復元できるようにします。操作履歴をエージェントが書き換えられない領域に保存すれば、履歴の偽装やログの改ざん・削除を防げます。

監視対象には、許可されていない外部通信、認証情報の探索、権限昇格、同じ失敗の繰り返し、別のエージェントとの無断通信などを含めます。重大な異常を検知した場合は、担当者への通知だけでなく、外部通信やツールの利用を自動的に止めます。誰が評価の再開を承認し、関係先へ連絡し、記録を保全するのかも事前に決めておきます。

NISTは、AIエージェントの認証と認可に関する検討課題として、個別のID、最小権限、代理操作の認可、人のIDとのひも付け、改ざんされにくい監査記録を挙げています。AIエージェントを通常の利用者やサービスと区別し、役割に応じた最小限の権限だけを与えるよう求めています。

AIが危険な操作を選ばないようにするとともに、許可されていない操作をシステム側で拒否できるようにします。責任境界を明確にするには、誰が権限を付与し、実行を監視し、異常時に停止するのかを定め、システムと運用規程に反映しなければなりません。

まとめ

Hugging Face事件では、AIエージェントが複数の脆弱性と認証情報を組み合わせ、組織の境界を越えて攻撃を広げました。AIが自ら方法を考え、別のエージェントと協力したとしても、その行動に対する責任をAIに負わせることはできません。

AIを動かす組織は、目的を定め、権限と接続先を制限し、監視方法と停止条件を決める必要があります。AIエージェントの接続先となるサービス事業者には、利用者から受け取ったデータを安全に処理し、認証情報を保護したうえで、侵入が内部ネットワークへ広がらないようにする対策が求められます。複数の組織が関与する場合は、各社が管理していた範囲と、そこで発生した問題を明らかにし、事故前の対策と発生後の対応をそれぞれ検証する必要があります。

モデルが正しく判断するように学習させるだけでは、想定外の行動を止められません。モデルが操作を提案する処理と、システムが実行の可否を判断する処理を分けます。そのうえで、個別のID、最小権限、操作ごとの認可、実行記録、自動停止の仕組みをシステムに組み込みます。AIに責任を負わせても、事故は防げません。AIに権限を与えた人と組織が、どこまで責任を負うのかを明確にする必要があります。