AIエージェントがAI基盤を攻撃――Hugging Face侵害事件で浮上した「安全ガードレール」の逆説

AIモデル共有基盤Hugging Faceは2026年7月16日、本番インフラの一部への不正アクセスを公表した。攻撃者は自律型AIエージェントを用い、データセット処理パイプラインのコード実行経路を突いて内部データセットとサービス資格情報にアクセスしたとされる。

注目すべきは攻撃手法だけではない。事後のフォレンジック解析で、Hugging Faceのインシデント対応チームが商用AIモデルに攻撃ログの分析を依頼したところ、安全ガードレールによって解析要求が遮断された。攻撃側はいかなる利用規約にも縛られない一方で、防御側が利用するAIの安全対策に阻まれるという逆説的な状況が生まれている。

攻撃の手法と規模

データセット処理パイプラインに存在した二つのコード実行経路

Hugging Faceの公式開示によると、今回の侵入ではデータセット処理パイプラインに存在した二つのコード実行経路が悪用された。

一つ目は、リモートコードデータセットローダーの経路だ。悪意のあるデータセットを読み込ませ、処理ワーカー上でコードを実行するために使われた。二つ目は、データセット設定ファイルにおけるテンプレートインジェクションである。設定ファイルのテンプレート処理を悪用し、処理ワーカー上でコードを実行したとされる。

攻撃者はこれらの経路からノードレベルのアクセス権を獲得し、クラウド・クラスター環境の資格情報を収集した。その後、週末にかけて複数の内部クラスターへ横移動（ラテラルムーブメント）を行った。

自律型AIエージェントによる大規模な自動操作

Hugging Faceの分析によれば、この攻撃は「端から端まで自律型AIエージェントシステムによって駆動された」ものである。同社は「業界が予測してきたエージェント型攻撃者のシナリオと合致する」と説明している。

エージェントフレームワークは、短命なサンドボックス群を横断しながら数千回の個別操作を実行した。公開サービス上には、接続先を移しながら稼働するC2（コマンド&コントロール）基盤も展開していたとされる。Hugging Faceは、一連の攻撃が機械的な速度で進んだと位置づけている。

攻撃に使用されたAIエージェントを動かしていた大規模言語モデル（LLM）の特定には至っていない。

不正アクセスが確認された情報と影響調査

アクセスが確認されたもの

Hugging Faceの開示によると、不正アクセスが確認されたのは以下の二つの領域である。

第一に、限定的な範囲の内部データセット。これはHugging Faceが社内で利用していたデータセットであり、一般ユーザーが公開しているデータセットとは区別される。第二に、複数のサービス資格情報およびトークン。クラウド環境やクラスター環境へのアクセスに使用される認証情報が含まれていた。

顧客・パートナーデータへの影響については、2026年7月21日時点でも調査中とされている。公式開示で確認できるのは不正アクセスまでであり、内部データセットや資格情報が外部へ持ち出されたかは明らかにされていない。

公開リソースに改ざんの証拠は見つかっていない

一方で、Hugging Face上で公開されているモデル・データセット・Spacesについて、改ざんの証拠は見つかっていない。ソフトウェアサプライチェーンに当たるコンテナイメージ・公開パッケージも検証され、汚染の証拠はないと同社は説明している。

Hugging Faceには100万以上のモデルが登録されている。公開モデルが改ざんされた場合は下流の利用者へ影響が広がる可能性があるため、公開資産に改ざんの証拠がないことは重要だ。ただし、顧客・パートナーデータへの影響調査は完了しておらず、事件全体の範囲が確定したわけではない。

利用者への推奨対応

Hugging Faceは、利用者のアクセストークンが取得・悪用されたとは公表していない。一方、顧客・パートナーデータへの影響調査が続いていることから、予防措置としてアクセストークンのローテーションと最近のアカウント活動の確認を推奨している。

• アクセストークンの予防的なローテーション（入れ替え）
• 最近のアカウントアクティビティの確認
• 不審な操作があれば security@huggingface.co への報告

CI/CDパイプラインやデプロイスクリプトが長期有効なHugging Faceトークンを参照している場合、ローテーション後は各環境のシークレットや環境変数も新しい値へ更新する必要がある。

安全ガードレールが防御側を阻んだ逆説

商用AIモデルがフォレンジック解析を拒否

今回の事件で浮上したもう一つの論点が、インシデント対応における商用AIモデルの安全ガードレールの問題である。

Hugging Faceのフォレンジック（デジタル鑑識）チームは、1万7,000件を超える記録イベントの解析にあたり、当初は商用APIで提供されるフロンティアAIモデルを活用しようとした。しかし、実際の攻撃コマンド・エクスプロイト（脆弱性悪用コード）・C2関連データを含む要求が、安全ガードレールによって遮断された。

攻撃の痕跡を調べるには、実際に使われたコードやコマンドを入力して分析する必要がある。Hugging Faceによると、利用したモデルの安全機構はインシデント対応者と攻撃者を区別できず、正当なセキュリティ調査も遮断したという。

Hugging Faceは公式ブログで「攻撃者はいかなる利用規約にも縛られない一方、我々自身のフォレンジック作業はホスティングされたモデルのガードレールに阻まれた」と記述している。

オープンウェイトモデルへの切り替えで対処

商用モデルの制約を受け、Hugging FaceのチームはオープンウェイトモデルであるGLM 5.2を自社インフラ上に展開し、フォレンジック解析を実施した。自社環境で動かしたため、攻撃者に関するデータとログ内の資格情報を外部へ送らずに分析できた。

同社はこの経験を踏まえ、「インシデントが発生する前に、自社インフラ上で動かせる高性能なモデルを検証・準備しておくべきだ」と提言している。一方で、今回の事例はホスティング型モデルの安全対策そのものに反対する主張ではないとも明記した。

この事例は、安全機構が正当なインシデント対応を遮断し、防御側に不利な非対称性を生む場合があることを示した。ただし、対象となった商用モデルや拒否条件は公表されておらず、全てのホスティング型モデルに同じ問題が常に起きるとまではいえない。

AIサプライチェーン攻撃の新たな局面

データセット処理が攻撃面になるという現実

今回の事件は、モデルファイルだけでなくデータセットの処理工程も、AI基盤における攻撃面になることを示している。データセットの読み込み・前処理は、AI開発ワークフローを構成する基本的な工程である。今回の侵害では、悪意のあるデータセットがコード実行経路を悪用し、処理ワーカーから基盤システムへの侵入口を開いた。

今回の事件は、モデルやデータそのものだけでなく、データセットを処理する実行基盤も監査対象になることを示している。アップロードという日常的な操作が攻撃の起点になったことで、処理パイプラインに意図しないコード実行経路が残っていないかを確認する重要性が浮き彫りになった。

「エージェント型攻撃者」が現実化した意味

業界ではAIエージェントがサイバー攻撃を遂行する「エージェント型攻撃者」のシナリオが議論されてきた。Hugging Faceは、今回の事件を自律型AIによる攻撃ツールがもはや理論上の存在ではないことを示す事例と位置づけている。

同社の開示で確認できるのは、エージェントフレームワークが数千回の操作を実行し、複数クラスターへの横移動や資格情報の収集を進めたことだ。短命なサンドボックス群や自己移転型C2も観測されたが、人間がどの程度監督・介入していたかは明らかにされていない。

Hugging Faceは対応措置として、コード実行経路の閉鎖・侵害ノードの再構築・資格情報の失効と更新・クラスターのアドミッション制御強化・検知アラートの拡充を実施した。また、外部のフォレンジック専門家と法執行機関にも報告している。

今回の侵害は、AIエージェントの能力が攻撃へ転用される可能性を、現実の運用課題として示した。防御側がAIで対抗する際には、安全対策による解析の遮断と、機密データを外部へ送らない運用の両方を検討する必要がある。AI時代のセキュリティには、攻撃への備えとAI利用時の安全管理を同時に設計する課題が生じている。