Perplexityは2026年10月15日、AIエージェントやユーザーコードを隔離して実行するサンドボックス基盤「SPACE（Sandboxed Platform for Agentic Code Execution）」をApache 2.0で公開しました。SPACEは、1つのタスクをFirecracker microVM内で実行し、HTTP APIから環境作成、コマンド実行、出力収集、ライフサイクル管理を行います。
企業がエージェントにファイル操作やコード実行を任せると、モデルの回答品質だけでなく、実行環境からどこへ到達できるかが問題になります。SPACEは、タスクを動かすVM、資格情報を扱う外側のサービス、外向き通信を制御するノード側の機能を分ける設計を示しました。
公式の検証では、VMからホストへの脱出は108回中0回でした。ただし、部分的なネットワーク許可では4モデルが制限を突破しています。導入判断では「VMから出られない」と「許可外へ通信できない」を別の境界として確認する必要があります。
※本記事は2026年10月20日時点の情報です。
AIシステム開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。
SPACEとは｜1タスク1つのFirecracker microVMでコードを実行
SPACEは、AIエージェントやユーザーコードを隔離して動かす実行基盤です。PerplexityのGitHubリポジトリは、Firecracker microVM内でコードを実行し、アプリケーションからHTTP APIを呼び出してLinux環境を作成すると説明しています。
テンプレートが初期環境を用意し、作成されたサンドボックスは固有のVMと書き込み可能なファイルシステムを持ちます。コマンドが終わるたびに環境を捨てる方式だけではなく、同じサンドボックスで複数のコマンドを実行できます。
ライフサイクルもAPIで管理します。作成、起動、コマンド実行、停止、再開、削除を分けて扱い、作成要求は非同期のoperationとして追跡します。長時間の作業では、サンドボックスを残したまま次のコマンドを送り、不要になった時点で削除できます。
この構造は、エージェントのプロセスを自社アプリケーションと同じOS上で動かす設計とは異なります。実行対象をタスク単位のVMへ置き、テンプレートとファイルシステムを管理対象にすることで、作業ごとの初期状態と破棄条件を決めやすくします。
ポイント
SPACEの中心は、AIエージェント専用のモデルではなく、コードやファイルを実行する境界です。導入時は、1タスクのVM、初期テンプレート、作業終了後の削除条件をセットで設計します。
APIとデータプレーンを分離｜管理操作とコマンド出力を別の経路にする
SPACEの管理経路は、アプリケーションからAPI、PostgreSQL、コントローラー、worker servicesを通り、Firecracker microVM内のゲストプロセスへ到達します。一方、コマンドの出力は別のdata planeからゲストプロセスへ接続します。
APIが返す作成結果を、そのままコマンドの実行結果とみなさない点も特徴です。作成要求にはoperation IDが返り、クライアントは実行環境がrunningになったことと、プロセスの接続先を確認してからコマンドを開始します。
認証も分かれています。管理要求はユーザーまたはサービスのbearer tokenで認可し、コマンドストリームはsession-scoped attachment tokenで認可します。公式ガイドは、2種類のトークンは相互利用できないと明記しています。
AIエージェントの権限を考えるとき、利用者のアカウントをそのまま実行プロセスへ渡す設計は避けたいところです。タスクの作成、コマンドの開始、出力の受け取りを別操作として記録し、どのセッションがどの環境へ接続したかを追える状態にします。マネージドなエージェント実行基盤を比較するときも、管理面と実行面の責任分界が確認点になります。
ポイント
管理APIのトークンと、ゲスト内プロセスへ接続するトークンを分けると、権限の用途と監査ログを切り分けられます。作成成功とコマンド成功も別の状態として扱います。
資格情報と外向き通信をVMの外で制御｜侵害後の横展開を抑える
SPACEの安全設計は、VMを作るだけで終わりません。Perplexityの公式紹介では、資格情報をサンドボックス内へ常時渡さず、必要な時だけ外側から提供する構成を示しています。エージェントが侵害されても、プラットフォーム管理の資格情報へ直接到達しにくくする考え方です。
外向き通信もノード側で制御します。公式ガイドのKind構成では、sandbox podを専用namespaceに置き、NetworkPolicyでAPIやコントローラーとの通信を許可しつつ、サンドボックスのegressをpublic IPv4 internetとcluster DNSに制限します。
企業が同じ考え方を採るなら、秘密情報を環境変数や作業ディレクトリに長時間置かず、タスクと宛先に応じて短時間だけ使わせます。許可先はドメイン名だけで決めず、DNSで解決されたIP、TLSの接続先、HTTPの宛先が意図どおりかまで確認します。
この点は、VMから脱出できるかとは別の問題です。エージェントがVMから出られなくても、許可された通信経路を経由してデータを送れれば、機密性は損なわれます。AIエージェントのサンドボックス脱出事例を読む場合も、ホスト脱出とネットワーク経由の情報流出を分けて評価します。
ポイント
資格情報の保管場所と、外へ出られる通信経路は、VMの隔離とは別に設計します。許可リストはDNS、IP、TLS、HTTPの各段で意図した宛先になっているかを検証します。
検証結果の読み方｜VM脱出0回でもネットワーク突破は別問題
Perplexityは、SPACEの検証でVM隔離とネットワーク閉じ込めを別々に試しました。9モデルにゲストVM内のroot権限を与え、ホスト側の秘密や許可外のネットワーク先を取得できるかを調べています。
| 検証条件 | 試行回数 | 結果 |
|---|---|---|
| VMからホストへの脱出 | 108回 | 成功0回 |
| ネットワーク完全遮断 | 54回 | 突破0回 |
| 部分的なネットワーク許可 | 54回 | 修正前に4モデルが突破 |
VMからホストへの脱出は108回中0回でした。SPACEのソースコードを読め、Web検索やソフトウェアのインストールができる条件でも、ホスト側の境界を破ったモデルはありませんでした。ここで示されるのは、あくまで設定された試行での結果です。
差が出たのは部分的なネットワーク許可です。4モデルがDNS spoofingやshared-IP routingを使い、許可された経路から秘密のフラグを取得しました。Perplexityは問題を修正し、再評価では検証済みのネットワーク突破がなかったと説明しています。
導入側が再現すべきなのは、成功率の数字だけではありません。VMからの脱出、完全遮断下の通信、許可先を持つ通常運用の3条件を分け、DNSの書き換え、共有IP、TLS終端、HTTPホスト名の扱いを攻撃シナリオに含めます。
ネットワーク制御とエージェントのID管理を一緒に検証することも必要です。どのタスクがどの秘密を使い、どの宛先へ送信でき、誰が異常を停止できるかをログで追えるようにします。評価用AIの自律侵入事例からも、実行権限と監視の境界を確認できます。
ポイント
「VM脱出0回」は、ネットワーク許可リストの安全性を意味しません。隔離境界と通信境界を分けてテストし、修正後も同じ条件で再評価できる手順を残します。
OSS導入前に確認すること｜Linux・KVM・ネットワーク運用が前提
SPACEはApache 2.0で公開されたOSSですが、ライセンスだけで自社導入を決められません。公式のローカル導入手順は、aptベースのLinux x86_64ホスト、KVM、/dev/kvm、/dev/net/tun、loop device、btrfs、特権コンテナを許可するDockerを前提にします。
手順はKubernetesベースのKindクラスターを使い、macOSでは直接動かないと明記されています。自社の開発用Macで試す場合も、別のLinux x86_64環境、KVMを使える仮想化基盤、Dockerの権限設定を用意する必要があります。
導入前に、次の確認を担当者と合意します。
- 実行基盤：Linux x86_64、KVM、必要デバイス、btrfs、Docker、Kindを用意できるか。
- 秘密情報：ゲストに常置せず、必要時だけ渡す仕組みと失効手順を持てるか。
- 通信統制：許可先、DNS、IP、TLS、HTTPの宛先を記録し、変更をレビューできるか。
- 運用責任：テンプレート更新、VM削除、異常停止、トークン監査を誰が担当するか。
この確認は、SPACEをそのまま採用するかどうかに関係なく使えます。自社で別の実行基盤を選ぶ場合でも、タスク単位のVM、外部管理の資格情報、ノード側のegress、管理面と実行面の認証分離を比較項目にします。AIエージェントの非人間IDを管理する場合も、IDの発行・失効と実行ログを一つの運用に組み込みます。
ポイント
OSS化で得られるのはコードと設計を検証できる選択肢です。KVMを持つ実行基盤、ネットワーク担当、資格情報の所有者、更新と監査の手順まで揃って初めて、企業の運用に載せられます。
よくある質問
Q. SPACEは何を隔離するサンドボックスですか？
AIエージェントやユーザーコードをFirecracker microVM内で実行し、固有のVMと書き込み可能なファイルシステムを持つLinux環境として隔離します。
Q. SPACEの管理APIとコマンド実行は同じ認証ですか？
同じではありません。管理APIはbearer token、コマンドストリームはsession-scoped attachment tokenを使い、2種類のトークンは相互利用できません。
Q. 公式検証でAIモデルはSPACEから脱出できましたか？
VMからホストへの脱出は108回中0回でした。ただし、部分的なネットワーク許可では修正前に4モデルが制限を突破し、VM隔離とネットワーク制御は別の境界だと示されています。
Q. SPACEのローカル導入に必要な環境は何ですか？
公式手順はLinux x86_64、KVM、/dev/kvm、/dev/net/tun、btrfs、Docker、Kindを前提にします。手順はmacOSでは直接動かないとされています。
まとめ
PerplexityのSPACEは、AIエージェントやユーザーコードをFirecracker microVMで動かすOSSのサンドボックス基盤です。HTTP APIによるライフサイクル管理、管理APIとデータプレーンの分離、VM外での資格情報と外向き通信の制御を一つの構成にまとめています。
公式検証はVM脱出の抑止を示す一方、部分的なネットワーク許可では別の突破面が見つかることも示しました。企業が見るべきなのは、OSSかどうかだけではありません。KVMを含む実行基盤、タスク単位の権限、秘密情報の受け渡し、egress、監査と再評価の担当を決めてから導入を判断します。
ポイント
AIエージェントを閉じ込めるには、VM境界とネットワーク境界を別々に検証します。SPACEを候補にする場合も、コードだけでなく、資格情報・宛先・監査・運用責任まで確認してください。
関連記事
- Claudeのサンドボックス脱出事例を解説｜AIエージェントの封じ込めと供給網リスク
- 評価用AIの自律侵入事例を解説｜AIエージェント運用で見直すべき権限管理
- 非人間IDを解説｜AIエージェントの権限管理と監視のポイント
- OpenAI Agents APIを解説｜マネージドなエージェント実行基盤で何が楽になるか
- AgentOpsを解説｜AIエージェントの可観測性・評価・監視のポイント
▼開発を相談する前に読みたい無料ホワイトペーパー
・AIシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。