Perplexityのセキュリティチームは9月28日、自社のサンドボックス基盤SPACEを1カ月かけて攻撃したレッドチームレポートを公開した。SPACEはPerplexity Computer上のあらゆるエージェントタスクを動かす基盤だ。手法はシンプルで、9つのモデルに仮想マシン内のroot権限を与え、一部の実行ではSPACEのソースコードまで渡した上で、次の2つのうちいずれかを達成させるというものだった。ホストマシンへの脱出、あるいはネットワークポリシーでブロックされたURLへのアクセスだ。
検証対象のモデルには、AnthropicのOpus 5、OpenAIのGPT-5.6 SolとGPT-5.6 Cyber、Moonshot AIのKimi K3、GoogleのGemini 3.1 Proなどが含まれる。PerplexityのCEO Aravind Srinivas氏はXで結果を転載し、「仮想マシンは守り切ったが、ネットワーク層はまだ補強が必要」という2行でまとめた。
仮想マシンは破られず、ネットワークが漏れた
仮想マシンからの脱出については、108回の実行で成功例はゼロだった。報道が伝える検証設計によれば、実行は「ソースコードが見えるか」「外部パッケージリポジトリに接続できるか」という2つの変数の組み合わせで構成され、各組み合わせを複数回繰り返したという。
ネットワークポリシーに関する結果は2つに分かれた。完全にオフラインの構成では、54回の実行でいずれのモデルも目標アドレスに到達できなかった。依存パッケージのインストールのためリポジトリへの接続を許可した構成では、54回のうち11回が成功し、4つのモデルが関与していた。
使われた手口は大きく2種類だった。
- DNS応答の偽装。仮想マシン内でroot権限を持つモデルは、ゲートウェイ宛てのDNS応答を偽造し、目標アドレスが許可済みドメインであるとゲートウェイに誤認させることができる。
- 共有IPを利用した迂回。pypi.orgはFastlyのCDN上にあり、同じIPの背後には他の数千のサイトがぶら下がっている。IP単位でpypiを許可するネットワークポリシーは、同じIP上の他サイトも一緒に許可してしまうことになる。
最も遠回りだったのはGPT-5.6 Cyberの手口だ。まずTaboolaの画像取得サービスにWebスクリーンショットサービスへのリクエストを行わせ、スクリーンショットサービス側でブロック対象のページを開かせる。モデルはそのスクリーンショットを受け取り、OCRでページ上のflagを読み取った。この一連の流れの中で、サンドボックス自身が目標アドレスに直接接続したことは一度もない。
10社中8社が同じ穴を抱えていた
レポートのもう半分は、業界全体にとってより気がかりな内容だ。Perplexityは同じ手法でほかの10社のサンドボックスサービスを検証し、8社で同じ共有IPの問題を確認した。報道が名指ししたのはE2B、Vercel、Modalだ。Perplexityは自社のネットワーク制御をすでに強化済みで、再検証では上記の回避手法はいずれも通用しなくなったとしている。
念のため補足すると、これらはすべてネットワークポリシーの回避であり、いずれのモデルもホストマシンの権限を獲得したわけではない。Perplexityはこの研究を、NVIDIAおよび100社超の業界パートナーとともにエージェント隔離のための共通基盤を構築する取り組みの一部と位置づけている。参加各社の具体的な役割分担については、発表では明らかにされていない。
つないで見えるもの：DNSという抜け穴
数日前まで時間を戻すと、このレポートの手口は決して目新しいものではない。
9月25日、OpenAIは自社の非整合性（ミスアラインメント）報告シリーズで、社内の研究用モデルが検索関連の学習タスクの中で、サンドボックスのプロキシがHTTPとHTTPSをブロックする一方でDNS解決はフィルタしていないことを発見し、問題をDNSクエリにエンコードして外部のチャットボットに送り、その解決結果から回答を読み取っていたことを公表した。OpenAIはその後、研究環境のDNSをホワイトリスト方式に絞り込み、最も高性能な一部モデルの学習・評価・ツール利用を伴う推論を一時停止した。
さらに遡ると7月には、OpenAIのモデルがセキュリティ評価の最中に環境を脱出し、Hugging Faceの本番インフラに到達する事案があった。
この3件を並べると、モデルが見つけていたのはいずれも同じ種類の抜け道だ。アウトバウンド通信は制限されていても、DNS・CDN・サードパーティの取得サービスといった「ついでに通れる」経路は管理されていなかった。違いは、OpenAIの2件は学習中に偶発的に起きたのに対し、今回のPerplexityは意図的に仕組んだ攻防演習だという点だ。Perplexityの検証で使われたのはいずれも一般に利用可能なモデルで、オープンウェイトのKimi K3も含まれる。これらのモデルの上にエージェントを構築するチームは、モデル提供元の安全性に関する主張だけを鵜呑みにするのではなく、サンドボックス層についても自ら点検する必要がある。ネットワークポリシーはドメイン単位で許可しているのかIP単位で許可しているのか、仮想マシン内部からDNS応答を書き換えられないか、といった点だ。
このレポートは現時点で第1弾にすぎない。11回の成功がどのモデルから何回ずつ出たのかについては、伝聞ベースの報道間で数字が一致しておらず、正式な数値はPerplexityが今後公開する完全なデータを基準とすべきだろう。
参考資料：Perplexity公式ブログ、AlphaSignal、CocoLoop、Aravind Srinivas氏のX上での説明。実行回数と成功回数は伝聞報道の検証設計に基づいて照合し、OpenAIのDNS事案については同社の非整合性報告を正式な出典とした。