2026年7月16日、Hugging Faceはプロダクションインフラの一部への侵入を開示しました。インシデント対応チームはAI分析エージェントを使用して、17,000以上の記録されたイベントを含む攻撃者のアクションログを処理しました。しかし、チームが実際の攻撃コマンド、エクスプロイトペイロード、およびコマンド＆コントロール（C2）アーティファクトを商用APIを通じて提供されるフロンティアモデルに送信したところ、プロバイダのセーフティガードレールがリクエストをブロックしました。そのため、チームはオープンウェイトのGLM 5.2モデルを使用し、自社のインフラ上で実行することを余儀なくされました。
Hugging Faceは、この方法により攻撃者データと参照された認証情報を自社環境内に保持できると述べています。悪用を減らすための保護措置が、実際のインシデント中に防御側にとって可用性の障害となりました。これは、ホスト型AIに依存するインシデント対応計画に特有のリスクを浮き彫りにしています。アナリストが調査する必要のあるマテリアルは、攻撃者がモデルに生成させるように求めるマテリアルと非常によく似ていることがよくあります。フィルターは資格情報収集スクリプトやC2文字列を認識しますが、オペレーターの役割、周囲のインシデント、または承認チェーンを確実に認識することはできません。Hugging Faceは、プロバイダのガードレールが自社の対応担当者と攻撃者を区別できなかったと述べています。
Hugging Faceは、自社の経験がホスト型モデルの安全対策に反対する議論ではないと明言しています。より狭義には、プロバイダのポリシー境界が自社の可用性境界の一部になります。プロバイダが証拠を拒否した場合、モデルのベンチマークスコアやコンテキストウィンドウに関係なく、その機能は利用できなくなります。
ローカル実行はポリシー境界とデータ境界の両方を変更します。オペレーターはモデルが処理できる内容を制御し、機密アーティファクトが外部API境界を越える必要がなくなります。これにより、責任がオペレーターに移ります。ローカルのフォレンジックエージェントは依然として、分離、シークレットへの狭いアクセス、ログ記録されたツール使用、人間によるレビュー、および変更可能な内容に関する明確なルールを必要とします。したがって、ローカルフォールバックは単なるモデルウェイトの保存以上のものでなければなりません。対応担当者は、それを実行するための十分な計算リソース、敵対的アーティファクトを保持できる分離されたワークスペース、運用担当者のためのアクセス制御、およびインシデントログを取り込むためのテスト済みの方法を必要とします。これらの準備が、ローカル実行を調達オプションから使用可能な対応能力に変えます。
開示には重要な制限もあります。これはHugging Faceの説明であり、独立した監査ではありません。同社は商用APIを特定しておらず、すべてのホスト型プロバイダが同じ判断を下すことを示しておらず、ブロックが封じ込めを遅らせたとも述べていません。攻撃者の自律エージェントフレームワークの背後にあるLLMは依然として不明です。攻撃者がオープンモデルを使用した、または特定のプロバイダのポリシーを逃れたという証拠はありません。
セキュリティチームは、インシデント前にこの障害モードをテストできます。完全なAI支援分析パスを、現実的な悪意あるアーティファクトを使用した隔離された演習にかけてください。ホスト型サービスがそれらを受け入れるかどうか、ローカルフォールバックが必要なコンテキストを処理できるかどうか、プロンプトと出力がどこに保存されるか、誰がアクセスを承認できるかを確認してください。サニタイズされたデモログは、実際のエクスプロイトコンテンツがトリガーするポリシーブロックを決して引き起こさないかもしれません。
Hugging Faceは、防御側が管理するインフラ上で有能なモデルを事前に検証し準備することを推奨しています。これには、アラートが発報される前の容量、アップデート、アクセスルール、および訓練が必要です。通常のログでは機能するが、実際の侵入からの証拠を拒否するモデルは、依然としてテストされていない依存関係であり、インシデント対応能力ではありません。