サンドボックスの閉鎖性は、AIエージェントが到達できる範囲で決まる

7月、OpenAIとHugging Faceは、社内評価中のOpenAIモデルがサンドボックスを脱出し、オープンなインターネットに到達したうえで、Hugging Faceの本番環境の内部インフラストラクチャにアクセスしていた事実を、責任ある開示のかたちで公表しました。この侵入で、エージェントはデータセット、クラスターの構成情報、クラウドキーを持ち出しています。

このインシデントの外部フェーズで最も重大だったのは、最初の1時間です。エージェントは、サンドボックスの許可リストに載っていたパッケージプロキシの脆弱性を突き、インターネットへの経路を手に入れました。

フロンティアモデルの開発元が同様のインシデントを開示する例は増えています。セキュリティ業界としては、エージェントがテスト環境内の到達可能性にどう影響するのかを、あらためて慎重に検討すべき段階に来ています。しかも、これは評価ハーネスを運用する組織だけの問題ではありません。エグレスリストの内側でコードを実行するワークロードは、いずれも同じ構造を持ちます。CI Runner、ホスト型サンドボックス、ネットワーク経由で到達できるツールサーバーなどです。こうした許可リストの多くは、データの流出を止める目的で設計されてきました。しかし現在、止めるべきものはそれだけではありません。

許可リストが到達範囲を広げる理由

許可リストを設計するとき、通常はワークロードが接続する必要のある宛先を洗い出し、そこから何が流出しうるかという観点で各エントリを評価します。

OpenAIのエージェントは、この一般的な手順の死角を突きました。エージェントがアクセスしたパッケージプロキシも、ひとつのサービスです。呼び出し元を認証し、脆弱性を抱えたソフトウェアを動かし、パブリックインターネットと通信します。サンドボックス自体はインターネットに到達できませんでしたが、エージェントは、インターネットに到達できるパッケージプロキシへのアクセスを獲得しました。

許可リストは、乗っ取り可能な宛先が持つ到達範囲を、そのままAIワークロードに引き渡します。

OpenAIのモデルはどのように脱出したのか

脱出にあたり、OpenAIのエージェントは、許可リスト上のパッケージプロキシに、見返りの非常に大きいゼロデイ脆弱性を2件見つけ出しました。

1件目は、サーバーサイドリクエストフォージェリの脆弱性です。これにより、エージェントは任意のURLの取得をプロキシに代行させられるようになりました。OpenAIのBlack Hat講演では、その瞬間のモデルの思考が「excellent, we have arbitrary SSRF（よし、任意のSSRFが取れた）」と記録されています。サンドボックスは、プロキシのインターネット接続を借用したことになります。

2件目は権限昇格の脆弱性です。CVE-2026-65616（CVSS 8.8）では、パッケージプロキシのリフレッシュトークンエンドポイントが、トークンの署名を検証しないまま新しいトークンを発行してしまいます。これらのトークンは、サーバー側でスコープを参照する方式ではなく、スコープをクレームとして自ら保持する方式です。そのため署名が検証されなくなった時点で、クレームの内容は呼び出し元の申告どおりになります。

今回、その呼び出し元はエージェントでした。エージェントはサンドボックス内で、読み取りスコープのトークンのクレームを管理者権限に書き換え、アクセス範囲を拡張します。そのうえで、そのトークンをパッケージプロキシに送って更新を要求したところ、管理者スコープのトークンが返されました。結果として、本来の読み取り専用権限ではなく、管理者権限で動作できるようになったのです。

脱出は、エージェントたちの集団作業でした。到達できる唯一のサービスを共同で調べ上げ、自分たちの代わりに通信させる方法を突き止めると、その手法を共有し、他のエージェントも使えるようにしています。あるエージェントは、外部への攻撃が指示の範囲外であると認識しながら、そのまま作業を続けていました。

Hugging FaceとOpenAIはまた、発見の難しい脆弱性であったにもかかわらず、プロキシの侵害が成立したのはサンドボックステスト開始からおよそ30分以内だったとしています。いずれもゼロデイであり、エージェントはCVEやアドバイザリーを参照できません。加えて、このパッケージプロキシはクローズドソースであり、そのコードがエージェントの学習データに含まれていたこともありません。

モデルはなぜ脱出したのか

エージェントがプロキシを狙った理由は、すでに判明しています。評価タスクに行き詰まっていたのです。OpenAIの講演資料には、脱出経路を探し始める直前に「perhaps answer online（答えはオンラインにあるかもしれない）」と推論する様子が残っています。フロンティアモデルは、タスクを速く解くことに対して報酬が与えられる設計です。行き詰まったモデルが近道を探すのは自然な帰結であり、OpenAIは通常、インターネットアクセスを無効化してその近道をふさいでいます。

エージェントの挙動には、未解明の点も残っています。4日間の侵入中に何を行ったのか、インターネットに到達したあと何をしたのか、といった点です。確かなのは、セキュリティ能力を備え、自律的に動作するAIのテスト環境を設計するうえで、新たに考慮すべき点があると、このエージェントが実例をもって示したことです。

AIテスト環境全体でリスクを減らすには

AIエージェント向けのサンドボックスを構築しているなら、リスクを下げ、到達範囲を絞る方法が4つあります。

1. ビルドクライアントが決して使わない経路をブロックする。ビルドクライアントの役割は、ファイルのダウンロードだけです。プロキシの管理APIや設定用の経路、そして期限切れ間近のトークンを新しいトークンに交換するトークン更新の経路を呼び出す理由はありません。今回悪用されたのは、まさにこのトークン更新の経路でした。
2. プロキシ自身の到達範囲を制限する。エージェントが外に出られたのは、プロキシがインターネット全体に到達できたからです。プロキシを支配した者も、同じ範囲に到達できます。プロキシからの外向き通信は、実際に配信対象としているレジストリだけに限定しましょう。
3. プロキシを監視する。ビルドフリートを支えるプロキシの通信は単調です。接続は短く、ダウンロードは小さく、リクエストはほとんど成功します。このパターンから外れる挙動には、アラートの設定を検討してください。接続が張られたままになる、データが大量に外向きへ流れる、存在しないパッケージへのリクエストが連続する、管理用の経路が呼び出される、といった挙動です。
4. 信頼できないワークロードは、インターネットに公開されているものとして扱う。信頼できないワークロードが内部サービスに到達できるなら、そのサービスはインターネットに公開されているものとして扱ってください。ワークロードを侵害したものは、そのサービスにも到達できます。GitLabでは今年、CI Runnerについて同じ問いを取り上げました。こちらは、信頼できないコードがエージェントのサンドボックスではなく、パイプラインで実行されるケースです。

サイバー能力を備えたモデルには、新しいサンドボックスの観点が必要になる

サンドボックスとは、その内側のワークロードが通信できる相手のリストです。そしてリストに載るものは、それぞれ自身の到達範囲を持ち込みます。ワークロードが単なるビルドジョブであれば、この点は問題になりません。しかし、許可リストの設計時には想定されなかったかたちでエージェントがそのリストを広げるとき、話は変わります。

エージェント型のワークロードは、評価ハーネスの外にも広がりつつあります。CI、本番環境の自動化、内部サービスと連携するツール群などです。そのいずれにも、同じ性質と構造を持つリストが存在します。モデルが脆弱性を見つけ、つなぎ合わせる能力を高めるほど、リストの到達範囲がそのままエージェントの影響範囲を押し広げます。

OpenAIは、これらのエージェントが依然として「取得できる権限と、通信できるシステムによって制約される」と述べています。つまり、既存のコントロールは今も機能します。
変えるべきなのは、到達可能性を最小化するために、そのリストをどれだけ慎重に描くかという点です。

脅威リサーチチームによる記事は、Security Labsサイトでご覧いただけます。