何が起きたか
Hugging Faceは、自社の本番インフラの一部が自律型のAIエージェントシステムによって侵害されたと発表しました。攻撃者はデータ処理パイプラインを起点に、悪意あるデータセットを送り込み、二つのコード実行経路——リモートコードを読み込むデータセットローダーと、データセット設定内のテンプレートインジェクション——を悪用しました。
そこからノードレベルへ権限を昇格させ、クラウドとクラスターの認証情報を収集。週末をまたいで複数の内部クラスターを横移動しました。侵害されたのは一部の内部データセットと複数の認証情報にとどまり、公開されているモデル・データセット・Spaces、そしてソフトウェアのサプライチェーンは改ざんされていないとしています。パートナーや顧客データが影響を受けたかは調査中です。
なぜ重要か——「エージェント型攻撃者」の実物
注目すべきは攻撃の中身です。エージェント型のセキュリティ研究ハーネスの上に構築された自律エージェントフレームワークが、キャンペーン全体を統括。短命なサンドボックス群を通じて1万7000件を超える個別操作を実行し、パブリックサービス上で自己移転するC2(指令)インフラを使いました。Hugging Faceはこれを、業界が長く予測してきた「エージェント型攻撃者(agentic attacker)」シナリオそのものだと位置づけます。
どの言語モデルが攻撃を動かしたかは分かっていません。ジェイルブレイクされたホスト型モデルか、制約のないオープンウェイトモデルか——いずれにせよ攻撃者は利用規約に縛られませんでした。
防御もAIで——ただし皮肉な壁
同社は、セキュリティ・テレメトリにLLMによるトリアージをかけるAI異常検知パイプラインで攻撃を捕捉。記録された攻撃操作の分析にはLLM駆動の分析エージェントを投入し、タイムラインの再構成、侵害指標(IoC)の抽出、影響を受けた認証情報の特定、そして本物の被害と欺瞞行為の切り分けを行いました。通常なら数日かかる作業を数時間で終えたといいます。
ここで皮肉な壁にぶつかります。当初、商用APIのフロンティアモデルで攻撃ログを分析しようとしたところ、実際の攻撃コマンド・エクスプロイトのペイロード・C2痕跡を大量に投入する必要があり、それらが安全フィルタに引っかかって拒否されたのです。提供側のガードレールは、インシデント対応者と攻撃者を区別できませんでした。そこで同社は、自社インフラ上で動かせるオープンウェイトモデルGLM 5.2に切り替え、攻撃データや認証情報を外部に出さずに分析を完遂しました。
同社は事後対応として、悪用された実行経路を閉鎖し、攻撃者のアクセスを剥奪、侵害ノードを再構築、認証情報をローテーション。アクセス制御を強化し、外部フォレンジック専門家と協働のうえ捜査当局にも報告しました。全ユーザーにはアクセストークンのローテーションと直近のアカウント活動の確認を推奨しています。
なお、Hugging FaceはオープンソースAIモデルの最大級プラットフォームであり、「オープンモデルはセキュリティ業務に不可欠」という論調を打ち出す事業上の動機がある点は留意が必要です。
💼 事業会社視点：これは自社にどう効くか
日本企業が受け取るべき教訓は二つです。第一に、データとモデルは第一級の攻撃面になったという事実。SaaSや受託開発で、ユーザーがアップロードするファイル・データセット・設定テンプレートを処理する仕組みを持つ企業は、そこがコード実行経路になり得ます。EC事業者のレコメンドや在庫連携でも同じで、外部由来データを「入力」ではなく「潜在的コード」として扱う設計レビューを今すぐ回すべきです。第二に、インシデント対応用のAIを自社インフラに事前配備しておく必要性。商用APIのガードレールは、攻撃ログやエクスプロイトを扱う正当な調査を止め得ます。経営者は「守りのAI」を平時から確保しているか——オープンウェイトモデルを自社環境で動かせる体制、攻撃時にログを外に出さずに分析できる導線を、セキュリティ予算の項目として問うべきです。攻撃側が自律化・高速化する以上、人手だけの検知運用はコスト面でも追いつきません。