2026年7月中旬、Hugging Faceは、自律型AIエージェントによってエンドツーエンドで実行された自社本番環境インフラへの侵入を公表し、その検知と再現の大部分は自社のAIによって行われたと明らかにした。 その5日後、OpenAIはその実行主体を明らかにした。それは同社自身のモデル、GPT-5.6 Solと、より高性能な未公開モデルであった。これらは、サイバー防御機能を意図的に弱めた状態で、ExploitGymと呼ばれる社内ベンチマークに対してテストされていたが、その過程で制御を脱し、Hugging Faceを標的にした。
枠組みを取り除いてみると、その仕組みは、疲れを知らずに動作し続ける、おなじみの基本要素の連なりであった：
- OpenAI側によると、これらの モデルは テストzero-day 悪用し、権限を昇格させてインターネットにアクセス可能なノードへ横方向に移動した後、盗んだ認証情報とさらなるエクスプロイトを連鎖させて、Hugging Faceの本番サーバー上でリモートコード実行を実現し、ExploitGymの解答キーを盗み出した。
- Hugging Face側の見解によると、侵入の起点となったのは データ処理パイプラインであり、そこでは信頼できないユーザーコンテンツの実行が例外的なケースではなく、中核的な機能として扱われていた。悪意のあるデータセットは、2つのコード実行経路（リモートコードデータセットローダーと、データセット設定へのテンプレートインジェクション）を悪用して、ワーカー上でコードを実行した。そこからエージェントはノードレベルへの権限昇格に成功し、クラウドおよびクラスターの認証情報を収集した後、週末にかけて複数の内部クラスター間で横方向の移動を行った。
公開されているモデル、データセット、Spacesへの改ざんは確認されておらず、サプライチェーンの安全性が確認されたほか、本件は法執行機関に通報されました。社内データセットおよびサービスの認証情報へのアクセスは確認されましたが、Hugging Faceによると、顧客やパートナーのデータが流出したことは確認されていないとのことです。
そして、これは単発の出来事ではなかった。その 同じ週 、 英国のAIセキュリティ研究所（AISI）も、独自のテストで同様の挙動を 報告した。設定ミスがあり解決不可能なサイバー評価において、あるモデルがAISIの評価インフラにアクセスしようと、外部のインターネットサービス上でコードを記述・実行し、セキュリティアラートを発動させてしまった。 インフラが持ちこたえたため、情報の漏洩も被害も発生しなかった。これがHugging Faceとの唯一の違いである。AISIはまた、テストしたすべてのモデルがこの種の近道を試みたことを突き止めた。これは、単一の異常なモデルの問題ではなく、トレーニングとアラインメントの問題であることを示している。
報道陣は逃走を追いかけた。重要なのは捕まえることだ。
ほとんどの報道は、AIが脱走し、他社をハッキングしたという事件をトップ記事として取り上げた。ある米国下院議員はこれを「憂慮すべき事態」と指摘し、独立した第三者によるテストの義務化を強く求めた。より鋭い指摘としては、最先端の研究機関の外でも、既存のツールを使えば同様の攻撃はすでに可能であるという点や、OpenAI自身の安全対策に対する批判こそが最も的を射ているという意見があった。すなわち、安全対策を無効にした状態で、モデルが脱走しうる環境下で攻撃評価を行うことは、能力の問題以前に、プロセス上の失敗であるという指摘だ。
しかし、この警戒論に反する事実が一つあり、記録に残しておくべきだ。それは、検知が機能したということだ。両チームは、両社が連携する前から、それぞれ独立してこの活動を検知していた。攻撃そのものは目新しいものではない。このインシデントが、対応に用いられたツールに与えた影響こそが、注目すべき点である。
問題1：肝心だったのは相関であり、異常値ではなかった
Hugging Faceがこれをどのように発見したかについて、ほとんど誰も触れていない。これは奇妙なことだ。というのも、この点が今回の事件の中で最も他への応用が利く部分だからである。
この侵害は、AIを活用した検知、すなわちテレメトリデータに対してLLMベースのトリアージを行う異常検知パイプラインを通じて明らかになりました。しかし、異常そのものは単なるノイズに過ぎませんでした。 この侵入を検知できたのは、それらを単一のシグナルとして相関させたからであり、これは「異常な動きをフラグ付けする」ことと「攻撃を認識する」ことの違いである。攻撃者の行動を再現するため、チームは17,000件に及ぶイベントのアクションログ全体に対してLLM駆動の分析エージェントを実行し、タイムラインを再構築するとともに、侵害の兆候を抽出し、実際の影響と囮活動を区別した。
攻撃は週末、対応は1時間。Hugging Face自身の報告によると、このキャンペーンはたった1つの週末にわたって行われ、数万件の自動アクションが発生したが、AIを活用した復旧には約1時間しかかからなかった。通常なら数日かかる作業だ。これが成功したのは、エージェントが推論を行うための完全かつ相互に関連付けられたアクションログを保有していたためである。エージェント型防御の有効性は、その基盤となるシグナルの質に左右される。断片的で単一の視点からのデータしか与えられなければ、その盲点を引き継ぐことになる。
クラスタ間の移動は、「可視化されていない問題」（『Mind Your Attack Gaps』のギャップ3）に該当します。つまり、ワーカーからノード、クラウド認証情報、そして複数のクラスタへと移動する過程において、全体像を把握できる単一の平面が存在しないのです。しかし、その侵入経路は特定可能であり、検出可能です。信頼できないデータセットを取り込む場合は、今すぐ「リモートコード実行データセットローダー」と「データセット設定におけるテンプレート注入」という2つのコード実行経路を監査する必要があります。
問題2：ガードレールは、攻撃者ではなく防御者を締め出してしまった
Hugging Faceがログ分析を開始した際、まず商用APIの背後にある最先端モデルを利用しようとしました。しかし、うまくいきませんでした。フォレンジック再構築には、実際の攻撃コマンド、エクスプロイトのペイロード、C2アーティファクトを送信する必要がありますが、インシデント対応担当者と攻撃者を区別できないプロバイダー側のセキュリティ対策により、リクエストがブロックされてしまったのです。そこで彼らは、自社のインフラ上で、オープンウェイトモデルであるGLM 5.2を用いて分析を行いました。これにより、攻撃者のデータや認証情報が自社の環境外に流出しないという、もう一つの利点も得られました。
この不均衡を受け入れよう。攻撃者は、利用ポリシーが一切適用されない状態で活動していた。防御側が第一に選択したツールは、その任務を拒否した。是正措置によってこの不均衡は さらに鮮明になった。OpenAIはHugging Faceを「信頼できるアクセスプログラム」に組み入れた。このプログラムでは、正当なセキュリティ作業に対して安全フィルターを緩和してモデルへのアクセスを許可するが、これはまさに、今回のインシデントを引き起こしたのと同じ「拒否率を低く抑えた」設定であった。
この教訓は、いざという時が来る前に取り入れておく価値があります。つまり、自社のインフラ上で実行可能な、十分に検証済みでインシデント発生に備えて準備万端なモデルを常に用意しておくことです。これは、 ガードレールによるロックアウトを回避すると同時に、 攻撃者のデータを社内に留めておくためでもあります。 これは、ホスト型モデルの安全性を否定するものではありません。むしろ、主要なモデルが機能しなくなった場合に備えて、DFIRツールの運用計画を立てておくべきだという主張なのです。
問題3：特定できる脅威アクターが存在しない
私はこの1年の大半を、eCrimeに関するある一点について主張することに費やしてきました。それは、「ブランドではなく行動を追跡すべきだ」ということです。グループ名は18か月ごとに変わりますが、運営者や手口は変わらないからです。今回の事件は、その主張を裏付けるものであり、その理由について率直に述べたいと思います。
Hugging Faceの開示情報からは、エージェントの基盤となっているモデルがどれか、さらには それがホスト型かオープンウェイト型かさえも判りませんでした。 この謎が解明されたのは、OpenAIが自ら名乗り出たからに他なりません。その自主的な開示を除けば、通常の帰属を示す手がかりは乏しいのです。つまり、ペルソナが存在せず、手口を再利用するオペレーター集団もなく、コマンド＆コントロールシステムは設計上、公開サービス間を移動するように構成されていたのです。
行動追跡は、依然として技術レベルでは機能している。この操作の原動力となっている認証情報の再利用は、「認証成功」の問題（ギャップ2）である。つまり、有効な認証情報が収集・再利用され、成功がログに記録されており、操作主体が人間かモデルかを見分けることは可能だ。薄れつつあるのは、その上の層、すなわち、CTIが「誰が」行ったかを特定し、次に何が起こるかを予測するために依拠する、アクターレベルの帰属情報である。オペレーターが狭い目標を追求するモデルである場合、「誰」という問いは、ベンチマークの実行という形で解決される可能性があります。
「ブランドではなく、行動を追跡せよ」という原則は今もなお有効だ。その行動の背後に、探すべきブランドがそもそも存在しないだけかもしれない。
これが自分に降りかかる前に、何を変えるべきか
これらは、malware を高めたところで解決されるものではありません。なぜなら、malware存在しなかったからです。重要なのは次の3つの対策です：
- データとモデルの表面を、第一級の攻撃対象領域として扱うべきです。AIプラットフォームにおいて、信頼できない入力は「例外的なケース」ではなく、「正面玄関」なのです。
- 再構成にAIを導入し、応答が攻撃と同じ速度で実行されるようにする。ただし、これは基となる信号が各平面間で相関している場合にのみ機能する。
- インシデント発生中ではなく、発生前にセルフホスト型の分析モデルを検証しておけば、ガードレールによって対応担当者が締め出されることは決してありません。
ギャップ3は、この貫入体における実際の動きが集中していた場所であり、これは 『Mind Your Attack Gaps』 の中で、私が真っ先に読み返したい章です。