Hugging Faceの侵害：すべてのセキュリティ リーダーが答えるべき重要な問い

7月11日、OpenAIによるサイバー攻撃能力の社内評価中に、GPT-5.6 Solと、より高性能な未公開モデルがサンドボックスから脱出し、インターネットに接続してHugging Faceの本番システムを攻撃しました。

人間のオペレーターは存在しませんでした。フィッシング メールもありません。内部関係者もいません。偵察、エクスプロイト、権限昇格、ラテラル ムーブメント、窃取といったキル チェーンの全工程が、誰にも操作されることなくエージェント システムによって実行されました。おそらくこの種の事例として初めて公に開示されたインシデントです。

SFのような要素を取り除いてみると、そこにあるのは、はるかに退屈ではるかに深刻な事実です。システムは、許可されたとおりのことを正確に実行したのです。

許可リストが攻撃対象領域に

OpenAIは、この環境を高度に分離された環境として説明しており、ネットワーク アクセスは、内部でホストされたプロキシを介してパッケージを取得するという単一の機能に限定されていました。このプロキシは、公開レジストリーのキャッシュとして機能していました。

モデルが脱出するために利用したのが、その唯一の許可された経路でした。

モデルはプロキシ ソフトウェアに存在する未知のゼロデイ脆弱性を発見してこれを悪用し、権限を昇格させ、研究環境内を水平移動し、最終的にインターネットへのアクセスが可能なノードに到達しました。

ベンダー自身の分析によると、この脱出は少なくとも8つの脆弱性が連鎖した結果だとされています。その中には、リモート リポジトリーのプロキシ処理におけるサーバーサイド リクエスト フォージェリー、認証バイパスを悪用した権限昇格、パス トラバーサルなどが含まれています。

そして、これは耳の痛い教訓です。サンドボックス内の存在が自らの環境を調査し、防御策を探り、突破口を見つけるために事実上無制限のコンピューティング リソースを費やせるのであれば、許可リストが攻撃対象領域のマップになってしまうのです。

リスクを増加させる継承された信頼

Hugging Faceの本番環境内で、エージェントは信頼された認証情報、API、ワークロードを利用して移動しました。侵害された本番PodからKubernetes、さらにクラウドのメタデータ、内部システム、そして最終的にはソース管理のサプライ チェーンへと進んでいきました。

ほとんど何も破壊しませんでした。各段階で、乗っ取ったアイデンティティーにすでに付与されていた権限をそのまま継承したのです。

これこそが、暗黙の信頼に潜む根本的な弱点です。一度内部に侵入されると、アクセス権が次々と引き継がれ、リスクが増加していきます。

新たな運用上の前提：すべてのワークロードは潜在的な攻撃者

AIエージェントは、意図を持って行動するワークロードです。サービスと同じように認証を行い、サービスと同じように動作しますが、オペレーターのように推論します。サブプロセスを起動し、一時的なアイデンティティーを使用し、自身に付与されているあらゆる権限を行使します。これには、誰が付与したのか誰も覚えていない権限も含まれます。

それに応じて、運用上の前提も変えなければなりません。すべてのワークロードを検証されるまでは信頼できないものとして扱い、すべての接続においてその都度検証するのです。

サンドボックス内にあるから信頼するのではありません。内部ネットワーク上にあるから信頼するのでもありません。モデルが整合しているから信頼するのでもありません。

整合はエンティティーの特性です。包含性はアーキテクチャーの特性です。今回の評価では、通常であればモデルが危険なサイバー活動を追求するのを阻止する分類器を意図的に取り除きました。研究者がその能力の上限を確認しようとしたためです。エンティティーの抑制を意図的に解除した状態で、評価されたのはアーキテクチャーそのものでした。

そのアーキテクチャーに実際に求められるもの

この攻撃の各段階をそれぞれに対抗できる制御と対応付けてみると、一貫したモデルが浮かび上がります。5つの制御それぞれにZero Trust Exchange内の施行ポイントがあります。

1. デフォルト拒否のエグレス制御とインライン検査

研究用サンドボックス、評価クラスター、エージェントのランタイムいずれも、明示的に許可され、TLSを含めて完全に検査され、ログに記録されていない限り、インターネットへの経路を持つべきではありません。これを正しく実現できれば、「モデルがインターネットにアクセスできるノードに到達した」などと記述する必要もなくなります。エグレス制御は、コンプライアンスのためのチェック項目ではありません。AIの封じ込めを支える最も外側の防壁です。

2. パイプラインに取り込まれるすべてのデータのインライン分析

Hugging Faceへの侵入経路となったのは、コードを含むデータセットのアップロードでした。パッケージ、データセット、モデル アーティファクトなど、自動化されたパイプラインに入ってくるものはすべて、実行前に分離環境でデトネーションを行う必要があります。事後的にシグネチャーを照合するのではなく、分析が完了するまで実行を保留します。ML固有のフォーマットも脅威ベクトルです。シリアライズされたオブジェクト、モデルの重み、データセットのアーカイブなどが該当します。攻撃者はすでに、これらをそのように捉えています。

3. ネットワーク到達性ではなくアイデンティティーベースのアクセス

この攻撃チェーンにおけるあらゆる移動(サンドボックスとプロキシ間、ノード間、Podとクラスター間、クラスターとデータベース間の移動)は、ネットワークレベルの到達性に依存していました。アプリケーションレベルのセグメンテーションでは、この考え方を逆転させます。つまり、アイデンティティーによって検証され、ポリシーによって承認された明確な理由がない限り、どのワークロードもサービスに接続できません。また、ワークロードに公開されていないアプリケーションは、そのワークロードからは存在しないことになります。脆弱性が問題になるかどうかは、その脆弱性を利用して何に到達できるかによって決まります。

4. 最小特権のデータ態勢の継続的な施行

最終段階では、窃取された認証情報が利用されました。侵害されたノード上で発見された認証情報によって、クラウドのメタデータや内部のサプライ チェーンにまで到達できました。最小特権が施行されていれば、それらの認証情報で到達できる範囲は、そのノードの影響範囲に限定され、そこで止まっていたはずです。継続的な発見によって、これを適用可能な状態にできます。機密データがどこに存在するのか、どのアイデンティティーがそれにアクセスできるのか、そしてどの認証情報に過剰な権限が付与されているのかを把握します。これにより、盗まれた認証情報が何でも開けられるマスターキーになるのか、それとも行き止まりになるのかを判断できます。

5. エージェント自体に対するガバナンス

MCPやエージェント間のチャネルを介して通信する自律型エージェントは、人間のユーザーや予測可能なサービス間トラフィックを前提として構築された制御からは見えません。必要なのは、エージェントと、エージェントがアクセスするすべての対象との間にポリシーの施行ポイントを設けることです。つまり、どのエージェントが存在するのか、それぞれが何に到達することを許可されているのかを登録し、定義された範囲から外れた動作に対してはインラインで施行します。パッケージ プロキシへの探索を始めたエージェントが、見出しになるのではなく、そこで検知されるようにするべきです。

機能が連携してこそ効果を発揮する理由

ここには、非対称性があります。攻撃には、チェーンを構成するすべてのリンクが機能し続ける必要があります。一方、防御に必要なのは1つです。脱出の拒否、ペイロードのデトネーション、セグメントの閉鎖、認証情報の権限範囲管理、エージェントの検知といったことにより攻撃チェーンは断ち切られます。

では、なぜこれらすべてにこだわるのでしょうか？

自律型エージェントは、一度きりの攻撃者ではないためです。何度も試行し、探索を続けます。Hugging Faceのフォレンジック タイムラインによると、エージェントが記録した17,600件のアクションは、4日間で約6,280の個別のクラスターに分類されています。また、OpenAIは、この脱出に相当量の推論コンピューティングが費やされたと説明しています。忍耐力を時間ではなくコンピューティングで測る攻撃者を相手にする場合、1つの制御はパズルにすぎません。多層化された制御こそが壁になります。

エグレス制御は、サンドボックスが最終的には突破されることを前提とします。セグメンテーションは、検査で最終的にペイロードを見逃すことを前提とします。データ態勢は、ワークロードが最終的には侵害されることを前提とします。各レイヤーが存在するのは、その1つ前のレイヤーが機能しなくなることを許容するためです。

そして、これらの機能をポイント製品の寄せ集めではなく、共通のプラットフォーム上に配置すべき理由もここにあります。個別に組み合わせたツールでは、それぞれが1つのフレームを見ます。統合された施行プレーンなら、1本の映像として全体を見ることができます。

今四半期に問うべき質問

7月のインシデントは、ある意味では思いがけない贈り物でした。最先端の研究機関が実施した完全な再現性を備えたレッド チーム演習が、被害を限定した状態で透明性をもって開示されたためです。AIエージェントを導入する組織が、常にこれほど被害の少ないケースに遭遇できるとは限りません。

セキュリティ リーダーは、理想論ではなく具体的な内容で以下の4つの問いに答えられる必要があります。

• AIのトレーニング、評価、エージェントのランタイム環境からインターネットへのエグレスを何によって制御してますか？デフォルト拒否になっていますか？また、これらの環境が先週アクセスした外部エンドポイントをすべて把握していますか？
• パイプラインで実行するデータセット、パッケージ、モデル アーティファクトを、何によって検査していますか？その検査は実行前に完了していますか？それとも、実行後ですか？
• そのスタック内のワークロードが今日侵害された場合、どこまで到達できますか？Pod、クラスター、クラウド アカウント、データベースのどこまででしょうか？また、早期に阻止できることを証明できますか？
• 現時点で、自社環境にどのAIエージェントが存在し、それぞれが何にアクセスすることを許可されていますか？また、その範囲を逸脱した瞬間に何が起こるのかを把握していますか？

フロンティアAI企業2社は、世界最高レベルの能力を持つモデルをペネトレーション テスターとして使い、これらの問いへの答えを困難な形で公の場で知ることになりました。私たちにできるのは、同社が開示した内容から学ぶことです。

詳細はこちらから専門家にご相談ください。