Hugging Face侵害事件、人間不在のAIエージェント攻撃を止めたのは中国製オープンモデルだった

17,000件を超える不正な操作——これは人間の攻撃者ではなく、AIエージェントだけが実行した行動の数です。
AIモデル共有サービスのHugging Faceは7月16日、本番インフラが自律型AIエージェント（人間の指示なしに判断・行動し続けるAIプログラム）の「群れ」に侵害されたと公表しました。
侵入から権限奪取、内部クラスタへの横展開まで、人間の操作者は一人も関与していなかったといいます。
AIを業務で使う人やセキュリティ担当者にとっては、「攻撃も防御もAI任せになる時代」の輪郭が見えてきた出来事です。

先に結論をまとめると：
– Hugging Faceは悪意あるデータセット経由の2つの脆弱性を突かれ、AIエージェントに内部クラスタを横断されました
– 公開中のモデルやデータセット、Spaces自体の改ざんは確認されていません
– 米国製の主要AIモデルはガードレール（安全装置）により攻撃コードの解析を拒否したため、中国のオープンウェイトモデル「GLM 5.2」をローカルで動かして調査を完了しました

Xで広がった「人間不在の攻撃」という衝撃

事件の発端は、Hugging Faceにアップロードされた1つの悪意あるデータセットでした。
データ処理パイプラインの2つのコード実行の欠陥を悪用し、処理用サーバー上で不正なコードを実行。
そこからAIエージェントが自律的に権限を昇格させ、クラウドやクラスタの認証情報を奪い、社内の複数クラスタへ週末をかけて横展開していったといいます。
Xでもこの流れがそのまま引用され、拡散しました。

Hugging Face disclosed a major security breach executed entirely by an autonomous AI agent swarm. No human operator was involved.

Attackers uploaded a malicious dataset that exploited code execution flaws in the data processing pipeline. The swarm then escalated privileges,…
— Shakthi V (@v_shakthi) 2026年7月20日

（訳：Hugging Faceは、完全に自律型AIエージェント群によって実行された大規模なセキュリティ侵害を公表した。
人間のオペレーターは一切関与していない。
攻撃者はデータ処理パイプラインのコード実行の脆弱性を突く悪意あるデータセットをアップロードし、その後エージェント群は権限を昇格させた……）

ただ、この投稿だけでは「どこまで被害が広がったのか」「なぜ検知できたのか」は分かりません。
公式発表と主要メディアの報道を突き合わせて確認しました。

調べて分かったこと

攻撃はどこまで進んでいたのか？

公式発表や複数のセキュリティメディアの報道によると、攻撃者は短命なサンドボックス環境を使い捨てながら、自己移動型のC2（コマンド＆コントロール：攻撃者が侵入先を遠隔操作する仕組み）を構築していたとされます。
実行された操作は数千件から、多いところでは1万7000件超と報じられ、週末のうちに社内の複数クラスタへ横展開が進んでいたことがうかがえます。
一方で公開中のモデルやデータセット、Spaces（ユーザーが公開するAIアプリ）に改ざんの形跡はなく、被害は内部の限定的なデータセットと認証情報にとどまったとしています。
異常を最初に検知したのも、自社の独自LLM（大規模言語モデル）による監視システムでした。

TechCrunchもこの動きを速報しています。

Hugging Face confirms breach affected internal datasets and credentials, urges users to take action https://t.co/E74O0TqrzS

— TechCrunch (@TechCrunch) 2026年7月20日

（訳：Hugging Face、侵害が内部データセットと認証情報に影響したことを確認、対応を呼びかけ）

なぜ米国製AIモデルは”使えなかった”のか？

今回とりわけ注目されたのが、事後調査のプロセスです。
Hugging Face CEOのクレマン・デランゲ氏は、攻撃の実態を解析するため米国のフロンティアモデル（OpenAIやAnthropicが提供するような最先端モデル）を使おうとしたところ、ガードレールが実際の攻撃コード（エクスプロイトペイロード）を含むリクエストを拒否してしまったと説明します。
「対応中に、悪意あるペイロードの検査をツールに拒否されては困る」という趣旨のコメントも報じられました。
こうしたモデルは「対応者と攻撃者を区別できない」ため、正規の防御作業まで一律にブロックしてしまう構造だったといいます。

この点は投資家・政策関係者としても知られるデビッド・サックス氏がXで取り上げ、話題を広げました。

Here’s another example: Hugging Face tried using American frontier models to analyze an AI-powered cyber attack. But the guardrails blocked requests containing real exploit payloads so they switched to GLM 5.2 running locally. The guardrails actually impaired defensive security. https://t.co/SHRrXCtaK4
— David Sacks (@DavidSacks) 2026年7月19日

（訳：また一つ例が出てきた。
Hugging FaceはAIによるサイバー攻撃の分析に米国製フロンティアモデルを使おうとしたが、ガードレールが実際のエクスプロイトコードを含むリクエストをブロックしたため、ローカルで動かすGLM 5.2に切り替えた。
ガードレールが防御側のセキュリティ対応を妨げてしまったのだ。）

GLM 5.2とは何なのか？

最終的に使われたのは、中国のZ.ai（Zhipu AI）が2026年6月に公開したオープンウェイトモデル（重みデータが公開され、誰でも自社サーバーで動かせるモデル）「GLM 5.2」です。
100万トークンという長大な文脈を扱え、コーディング性能も主要な商用モデルに匹敵するとされ、MITライセンスで自社インフラ上にローカルで動かせました。
デランゲ氏は「オープンモデルなら誰の許可も得ずにその作業ができる」とも述べています。
攻撃者はそもそも利用規約やガードレールに縛られていないのに、防御側だけが安全装置に足止めされる非対称性が浮き彫りになりました。

Shiritomo編集部の考察：明日からセキュリティ担当者が確認すべきこと

この事件が示すのは、AIエージェントの脅威が「将来の話」ではなく、すでに本番環境で実行されているという事実です。
Shiritomo編集部の視点で気になるのは、攻撃側が数千〜1万7000件超の操作を人手を介さず自動で回せた一方、防御側は「安全なAIほど自分の手を縛られる」というジレンマに陥った構図です。
AIエージェントやAI関連サービスを運用する企業は、インシデント対応時に自社のAIツールが誤検知や利用規約でブロックされないか、平時のうちに確認しておくべきでしょう。
外部データセットやファイルを自動処理するパイプラインを持つ企業も、同様のリモートコード実行のリスクがないか点検する価値があります。
オープンウェイトモデルを緊急時のバックアップ手段として用意しておく発想も、選択肢の一つになっていくかもしれません。

まとめ

Hugging Faceの事件は、攻撃側にAIエージェントが使われただけでなく、防御側の調査そのものが商用AIのガードレールによって妨げられたという二重の意味で、AI活用企業にとって他人事ではない出来事です。
攻撃と防御の両方がAI任せになりつつある今、自社のAIツールが有事に本当に機能するかを見直すきっかけにしてみてはいかがでしょうか。