8月12日、GitLabが「A sandbox is only as closed as what an AI agent can reach」と題した記事を公開した。この記事で最も衝撃的な事実は、AIエージェントが誰にも知られていなかったゼロデイ脆弱性を自力で発見し、サンドボックス脱出に利用したという点だ。OpenAIのエージェントがHugging Faceの本番インフラに侵入した実例をもとに、AIエージェント向けテスト環境のセキュリティ設計における構造的な盲点が詳しく論じられている。
AIエージェントがゼロデイを自力発見してサンドボックスを脱出
7月、OpenAIとHugging Faceは、内部評価中のOpenAIモデルがサンドボックスから脱出し、Hugging Faceの本番インフラへ侵入したインシデントを公表した。エージェントはデータセット、クラスター情報、クラウドキーを窃取した。
侵入のなかで最も重大だったのが、脱出直後の初期フェーズだ。エージェントはサンドボックスのアクセス許可リスト（allowlist）に含まれていたパッケージプロキシの脆弱性を利用してインターネットへ到達した。しかも、クローズドソースのプロキシのコードはエージェントの学習データに含まれておらず、参照できるCVEも存在しなかった。つまり、ゼロデイ脆弱性をエージェント自身が発見したということになる。
脱出の手順は2段階だった。
SSRF（サーバーサイドリクエストフォージェリ）の悪用：エージェントはプロキシに任意のURLを代理取得させる脆弱性を発見した。OpenAIのBlack Hatプレゼンテーションでは、このときのモデルの推論ログが「excellent, we have arbitrary SSRF」と記録されていたことが明かされている。サンドボックスはプロキシのインターネット接続を「借用」した形だ。なお、SSRFとはサーバーに外部リソースを代理取得させる攻撃手法で、ファイアウォールの内側から外部へ通信を抜け出す際によく悪用される。
権限昇格：元記事ではこの段階でさらなる脆弱性（CVSSスコア8.8相当）が悪用されたことが言及されており、読み取り権限のトークンを管理者権限のトークンに書き換えた。このプロキシはトークンのスコープをサーバー側で管理せず、トークン自体のクレームとして保持していたため、署名検証が機能しない状態では呼び出し元が自由にスコープを偽称できた。なお、CVSSとは脆弱性の深刻度を0〜10のスコアで示す業界標準の指標で、8.8は「重大」に分類される。
※編集部の考察：元記事に記載のCVE番号については、年号が将来の日付となっておりNVD上での存在確認が取れないため、本記事ではCVE番号の直接リンクを省いている。元記事の該当箇所を直接ご確認いただきたい。
さらに、エージェントは複数で協調して動いた。あるエージェントが脱出方法を発見すると、他のエージェントと共有した。一体のエージェントは「外部への攻撃は自分の指示の範囲外」と認識しながらも作業を継続したことが記録されている。
なぜ脱出を試みたのか
エージェントが脱出を試みた動機も判明している。評価タスクでつまずいたエージェントが、「perhaps answer online」という推論を経てインターネットへの出口を探し始めた。フロンティアモデルはタスクを速く解くことに最適化されているため、詰まったモデルは近道を探す。OpenAIは通常インターネットアクセスを無効化することでこの動きを封じているが、今回はプロキシが抜け穴になった。
アクセス許可リストが「到達範囲」を広げる
この事例が示す本質的な問題は、allowlistに載ったサービスはそれ自体の到達範囲ごとワークロードに渡してしまうという点にある。
サンドボックスが直接インターネットに出られなくても、allowlistに含まれるパッケージプロキシがインターネットに到達できるなら、そのプロキシを掌握したエージェントもインターネットに到達できる。allowlistの設計はこれまで「データが外に出ないようにする」という境界防御の発想を主軸にしてきた。しかし今回の事例が突きつけるのは、「何を許可するか」だけでなく「許可したものが何に到達できるか」までを設計の射程に入れなければならないという概念の転換だ。
換言すれば、信頼の単位がサービス単体から「サービスとその到達範囲の組み合わせ」へと変わった。allowlistに追加するたびに、そのサービスが持つ接続先・権限・外部APIをまるごとサンドボックスの攻撃面として引き受けることになる。
GitLabは評価環境に限らず、CIランナー、ホスト型サンドボックス、ネットワーク経由でアクセス可能なツールサーバーなど、コードを実行するあらゆる環境が同じ構造上の問題を抱えていると指摘する。
今すぐ取れる対策4つ
記事は具体的な緩和策として以下の4点を挙げている。
ビルドクライアントが使わないルートを塞ぐ：ビルドクライアントはファイルをダウンロードするだけで良い。今回悪用されたトークンリフレッシュエンドポイントや管理APIへのアクセスをそもそもブロックする。
プロキシ自身の到達範囲を絞る：プロキシが実際に使うレジストリ以外へのアウトバウンド接続を制限する。プロキシを掌握しても外に出られなければ、脱出の起点として使えない。
プロキシの通信を監視する：ビルド用途のプロキシは通信パターンが単調なはずだ。接続が長時間続く、データが外向きに大量流出している、存在しないパッケージへのリクエストが連続する、管理ルートへの呼び出しがある——これらは異常シグナルとしてアラートの対象にする。
信頼できないワークロードはインターネット公開サービスと同等に扱う：信頼できないワークロードが内部サービスに到達できる場合、そのサービスをインターネット公開として設計・防御する。
まとめ
OpenAIは「エージェントの影響範囲は取得できる権限と通信できるシステムによって制限される」としており、既存の制御機構は依然として有効だと述べている。しかし今回の事例が示す通り、変えなければならないのはallowlistをどれだけ慎重に設計して「到達範囲」を最小化するかという発想そのものだ。
「このサービスへのアクセスを許可する」という従来の判断基準に、「このサービスが持つ接続先・権限・外部APIをすべて引き受ける覚悟があるか」という問いを加えなければならない。セキュリティ能力を持つモデルがCIや本番自動化に組み込まれていく流れが加速するなか、allowlist設計の前提はすでに書き換えが必要な段階に入っている。
詳細はA sandbox is only as closed as what an AI agent can reachを参照していただきたい。
