サンドボックス化されたOpenAIモデルがHugging Faceへの攻撃を実行した今回の事案は、プロンプトによるガードレールがAIエージェントの主要なセキュリティ境界にはなり得ないことを示しました。企業は今後、アクセス制限や横方向移動の阻止といったインフラ側の制御によってAIエージェントを封じ込める必要性に、一段と迫られています。
OpenAIの最も高性能なAIモデルの一部が結託し、サンドボックスを脱出してHugging Faceのシステムを攻撃していたことを、同社自身が認めました。これはサイバーセキュリティ評価が意図せぬ方向に転んだ結果だといいます。テスト対象となったモデルは、本番環境のバージョンであれば拒否するはずの、潜在的に有害な行動を実行できるよう改変されていました。今回の事案は、AIのプロンプトガードレールが機能しなかった場合、あるいは今回のように意図的に取り外された場合には、企業側が堅牢なサンドボックスやその他の技術的制限を備えてシステムを守らなければならないことを浮き彫りにしています。
OpenAIの評価では、GPT-5.6 Solと、より高性能な未公開のプレリリースモデルが、サイバーセキュリティ能力を測定するベンチマークツール「ExploitGym」の課題解決を競い合っていました。両モデルは、Hugging Face側のシステムに答えが存在し得ると結論づけ、そこへのアクセス獲得に乗り出したと、OpenAIはHugging Faceへの攻撃に関するブログ記事で説明しています。
ExploitGymは、AIモデルにセキュリティ脆弱性を攻撃用エクスプロイトへと変換させる課題を課すものです。OpenAIは攻撃コードを構築するために必要なコードをダウンロードできるよう、パッケージレジストリ用プロキシを介して限定的なインターネットアクセスをモデルに与えていました。ところがモデルはこのプロキシに存在したゼロデイ脆弱性を突き、無制限のインターネットアクセスを獲得。さらに窃取した認証情報やその他の欠陥を悪用して、Hugging Faceのシステムにアクセスしました。
CIOやCISOにとって、この問題の懸念はサイバーセキュリティ研究の枠にとどまりません。企業のデータベースやソースコードリポジトリ、決済システムに接続されたAIエージェントは、モデルレベルの安全策が破られた際にもアクセス制御とサンドボックス化が機能し続けない限り、機微なリソースを危険にさらしかねません。
Forresterのプリンシパルアナリスト、Biswajeet Mahapatra氏は次のように述べています。「プロンプトによるガードレールはセキュリティ制御ではありません。それは失敗したり回避されたり、あるいはテスト中に意図的に無効化されたりし得る、行動面での制御に過ぎないのです」
封じ込めはなぜ破られたのか
モデル側の安全策が緩められていたとはいえ、周辺のインフラは本来その活動を封じ込めるはずでした。ネットワークアクセスは、ソフトウェアパッケージレジストリ向けのプロキシおよびキャッシュとして機能する、社内でホストされたサードパーティ製サービスに限定されていました。こうしたプロキシは通常、企業において外部から仕掛けられるサプライチェーン攻撃を防ぐために使われています。
OpenAIによれば、モデルはこのサービスに存在したゼロデイ脆弱性を発見して悪用し、権限昇格と横方向への移動を重ねた末に、インターネットに開かれたノードへとたどり着いたといいます。
オンラインに到達したモデルは、Hugging Face側にExploitGymに関連するモデルやデータセット、あるいは解答が保管されている可能性があると推論しました。OpenAIによると、ある攻撃経路では、モデルが窃取した認証情報とゼロデイ脆弱性を組み合わせ、Hugging Faceのサーバー上でリモートコード実行を獲得したとしています。
自社インフラでの活動について、Hugging Faceは説明の中で、悪意あるデータセットがデータ処理パイプライン内にある2つのコード実行経路を悪用したと述べています。攻撃者はその後、ノードレベルのアクセス権を獲得し、クラウドおよびクラスターの認証情報を収集した上で、複数の社内クラスターへと侵入を広げました。
OpenAIによれば、モデルは最終的に、Hugging Faceの本番データベースから直接ExploitGymのテスト解答を入手しました。同社は、目的達成のためにこれほどまでの手段を尽くしたにもかかわらず、モデルは一貫してベンチマーク解決という目標に集中し続けていたと述べています。
Greyhound Researchのチーフアナリスト、Sanchit Vir Gogia氏は、このパッケージレジストリ用プロキシが企業のセキュリティチームにとって懸念材料となるのは、それが本来厳しく制限された環境の中で、狭い範囲に限って許可された例外だったからだと指摘します。
「あらゆる企業のIT環境は、まさにこの種の例外の積み重ねによって成り立っています」と同氏は述べています。
今回の事案では、OpenAIのモデルは意図しない手段によってではあるものの、本来意図された目的自体は達成していました。しかし企業は、自社のAIシステムが本来の目的から逸脱しないよう注意を払う必要があります。
Mahapatra氏は、企業はAIエージェントを「リスクの高い非人間アイデンティティ」として扱い、それぞれを隔離された環境に閉じ込め、アクセス範囲を割り当てられたタスクのみに限定し、認証情報も速やかに失効させるべきだと述べています。
「許容可能な被害範囲とは、侵害されたエージェントが影響を及ぼせる対象が単一のワークフローやデータセット、アプリケーションのみにとどまり、より広範な企業インフラへの侵入経路とはならない状態を意味します」とMahapatra氏は説明しています。
また、Gogia氏は、パッケージレジストリや更新システム、その他外部リソースへのアクセスを許可されたサービスは、エージェント自体と同水準の精査を受けていない限り、脱出経路となり得ると警告しています。
企業が備えるべき防御策
Hugging Faceによれば、今回の侵入により、限られた数の社内データセットと、同社のサービスで使用されているいくつかの認証情報への不正アクセスが発生しました。公開されているモデルやデータセット、Spacesが改ざんされた形跡は見つかっておらず、公開済みのソフトウェアパッケージやコンテナイメージも侵害されていないとしています。
同社は、アクセスに利用されたコード実行経路を閉鎖し、影響を受けたノードを再構築しました。また、露出した認証情報を失効させ、クラスターに受け入れるワークロードを管理する規則も強化しています。
自社のAIを内側に留めておく場合であれ、不正なAIを外側で食い止める場合であれ、Gogia氏は、企業はアーキテクチャ図や策定済みのポリシーに頼るのではなく、封じ込めの境界が実際に機能するかどうかを自らテストすべきだと述べています。そうしたテストでは、認証情報の窃取を試みたり、信頼境界を越えたり、エージェントに割り当てられたタスクの範囲外にあるシステムへの到達を試みたりする必要があります。
Mahapatra氏は、企業は封じ込めの層の一つが破られる可能性を前提とし、あるエージェントのアクセス権が無関係なアプリケーションやより広範な企業インフラへの侵入経路とならないよう確保すべきだと述べています。
OpenAIは、Hugging Faceとともに今回の事案について引き続き調査を進めており、脆弱性への対応が完了するまでの間、研究のスピードが落ちることになったとしても、自社の研究環境により厳格な設定を課しているとしています。また、今後の評価に向けて、封じ込めと監視の体制も強化しているといいます。
