SPACEがリクエストを正しいサンドボックス実行にルーティングする仕組み

AIエージェントにスプレッドシートの分析やソフトウェアのテストを依頼するとき、ユーザーはエージェントが自分のファイルやデータを安全に扱ってくれると信頼しています。エージェントには、他のユーザーのデータを露出させたり、そのワークロードに干渉したりすることなく作業を遂行できる、分離された環境が必要です。

エージェントがより大きな自律性を持ち、より複雑なタスクを担うようになるにつれ、こうした環境は、ミスを封じ込め、安全でないコードや悪意のあるコードによる被害を抑えるのに役立ちます。サンドボックスは、コントロールプレーンのサービス、ワーカーノード、ルーティングインフラストラクチャを共有しながら、その分離を実現します。

この共有インフラストラクチャは、各操作を、その処理を認可された実行に確実に届けなければなりません。古いルートが残っていると、正当なリクエストが別のサンドボックスや、正しいサンドボックスの古い実行に送られてしまう可能性があります。PerplexityのセキュアなサンドボックスプラットフォームであるSPACEは、各操作を選択された実行にバインドし、転送前に宛先を確認します。

SPACEは数か月にわたり、1日あたり数百万件の実行を処理してきました。各実行は固有の暗号学的アイデンティティで保護されており、エラー率は0.0002%未満、切断された接続はゼロです。

ルーティングの問題

サンドボックスのセキュリティは、各リクエストを正しい宛先に届けられるかどうかにも左右されます。単純なファイル読み取りでさえ共有インフラストラクチャを経由し、そのインフラストラクチャは、サンドボックスが一時停止、再開、マシン間の移動を行う間も、サンドボックスがどこで実行されているかを追跡し続けなければなりません。

ファイル読み取りは複数のコンポーネントを経由します。SPACEのコントロールプレーンは、サンドボックスを実行とワーカーに解決します。リクエストはnode-apiから入り、サンドボックスマネージャーであるsbx-managerに渡され、Unixソケットを経由してホストブリッジであるspaced-hostに到達します。ブリッジは、ホストからゲストへのソケットトランスポートであるVSOCKを介して、Firecracker microVM内のspaced-guestにリクエストを転送します。

それぞれの判断は、インフラストラクチャの変更に遅れをとる可能性のある状態に依存しています。データベースには古い配置情報が残っているかもしれませんし、キャッシュされたアドレスが別の場所を指していたり、ソケットパスに別のリスナーが割り当てられていたりするかもしれません。接続に成功しても、誤った宛先に到達している可能性があります。読み取りによって他のユーザーのデータが露出したり、書き込みによって誤ったファイルシステムが変更されたりするおそれがあります。

スナップショットは、さらに別の問題をもたらします。サンドボックスを別のワーカーで再開すると、論理的なアイデンティティは維持されますが、新しい実行が開始されます。遅延したリクエストや存続している接続が前の実行に到達し、正しいサンドボックス名のもとで古い状態を返してしまう可能性があります。

拡大

サンドボックスアイデンティティと実行アイデンティティ

SPACEは、ユーザーの環境と、それを提供するランタイムを分離しています：

• サンドボックスアイデンティティ：論理的な環境の固定ID。呼び出し元の認可によって、このサンドボックスへのアクセスが確定します。
• ルート／実行アイデンティティ：選択されたランタイムインカネーションとその配置（ワーカー、サブストレート、アクティベーションを含む）。

実行世代によって、ランタイムインスタンスが区別されます。Kubernetesでは、ルートにPod UIDも含まれます。アドレスはエンドポイントの所在を示し、実行アイデンティティはそのエンドポイントが操作を処理できるかどうかを決定します。

サンドボックスSがワーカーAで実行7として動作し、その後ワーカーBで実行8として再開したとします。実行8向けに選択されたリクエストが実行7に到達した場合、そのリクエストは失敗しなければなりません。サンドボックスIDだけを確認していては、この不一致を見逃してしまいます。

拡大

署名付きの実行選択

各リクエストには、どのサンドボックス実行がそのリクエストを処理できるか、またどのようなアクセスが許可されているかを示す署名付きの証明が含まれます。受信側のコンポーネントは、リクエストの処理を進める前に、その証明を自身のランタイムアイデンティティと照合します。

呼び出し元の認可後、SPACEは、サンドボックス、実行、配置、許可されたアクセスを特定する、短期間有効な署名付きケイパビリティを発行します。パブリックなサービスポートのケイパビリティでは、許可されたポートとプロトコルも指定されます。

受信側のサンドボックスマネージャーは署名を検証し、完全なアイデンティティを、ローカルに永続化されたランタイムレコードと照合します。署名によって、誰がその選択を認可したかが確定します。照合によって、その選択が受信側と一致するかどうかが確定します。

ServicePortのトラフィックは、ゲスト接続がオープンされる前に、サンドボックスごとのネットワークゲートウェイであるnetgtwで2回目のチェックを受けます。ゲートウェイは、アイデンティティを信頼できるアクティベーション状態と照合し、ポートとプロトコルを確認します。コントロール操作は、ブリッジエンドポイントの検証に進みます。

SPACEはEd25519署名を使用しています。ケイパビリティを発行するのはコントロールプレーンの署名鍵であり、ワーカーやゲートウェイ上の公開検証鍵ではケイパビリティを発行できません。

ケイパビリティの有効期間は120秒で、有効期限には最大15秒のクロックスキューが許容されます。署名が有効でトークンが期限切れでなくても、選択されたアイデンティティとインストールされたアイデンティティが一致しない場合は、それだけでは不十分です。

拡大

誤った宛先での拒否

受信側のワーカーは、リクエスト自体が認可されている場合でも、ルーティングの誤りを検出できます。そのリクエストに対して選択された実行を自身が実行しているかを確認し、異なる場合はリクエストを拒否します。

実行8向けに選択されたリクエストが、まだ実行7を処理しているワーカーAに到達した場合、ワーカーAは転送前にそのリクエストを拒否します。受信側は、実行8のアイデンティティをインストールすると、実行7向けのケイパビリティも、有効期限前であっても拒否します。

この保証には重要な限界があります。実行7向けのケイパビリティは、実行7を提供しているワーカーがその廃止を把握するか、ケイパビリティの有効期限が切れるまでは、引き続きそのワーカーと一致し得ます。更新が伝播する間は、ローカルでの強制と、上限のあるケイパビリティ有効期間が連携して機能します。

拡大

ブリッジエンドポイントの検証

ランタイムレコードが一致すれば、意図された実行が確定します。さらにコントロールブリッジは、同じアドレスを引き継いだ置き換え先ではなく、そのアクティベーションに属するプロセスとトランスポートに到達しなければなりません。

サンドボックスマネージャーとノードマネージャーは、ホストブリッジのピア認証情報と、ブリッジおよびFirecrackerの両プロセスのアイデンティティを開始時刻も含めて検証し、再利用されたIDや変更された実行ファイルを検出します

トランスポートチェックでは、ソケットの所有権、ゲストのアイデンティティ、カーネルのソケット証跡を用いて、VSOCKリスナーを想定されるFirecrackerプロセスに結び付けます。ブリッジは検証後にのみ操作を転送し、透過的な再接続を拒否します。新しい接続はすべて、改めてチェックを通過する必要があります。

この検証は、Kubernetes上および直接管理されたホスト上のFirecrackerコントロールブリッジを対象としています。ServicePortのトラフィックではゲートウェイで実行とポートのチェックが行われますが、ゲスト内の任意のアプリケーションのアイデンティティを証明するものではありません。

拡大

ストリームの存続期間とルートの回復

サンドボックスの実行が変わる間も開いたままの接続があるため、アイデンティティのチェックは最初のリクエストだけで終わらせるわけにはいきません。SPACEは古い実行に結び付いた接続を廃止し、対象となる操作が同じセキュリティチェックのもとで現在の実行に再接続できるようにします。

ターミナルやファイル監視は、それらを開いたリクエストよりも長く存続することがあります。SPACEはバックエンドのストリームをアイデンティティエポックに結び付けるため、受信側が置き換え後の実行をインストールした後に、ストリームが前の実行に接続されたまま残ることはありません。

SPACEは、ストリームをオープンする前に永続化されたアイデンティティを再確認します。ルートまたは実行が置き換えられるとストリームのリースがキャンセルされ、入出力が停止します。

所有権の変更は、実行の置き換えとは別物です。変更されていないKubernetes上の常駐ランタイムでライフサイクル操作がハンドオフされる場合、そのルートアイデンティティ、期限切れでないケイパビリティ、ストリームは維持されます。ゲートウェイも、同じルートと実行世代の中でアクティベーション試行のみが変わる場合は、確立済みのストリームを維持します。新たにオープンする際には、更新されたアイデンティティが必要です。

リカバリーの際も、これらのチェックはそのまま維持されます。アイデンティティ比較器は、同じサンドボックス内でインカネーションが一致しない場合はRefreshRouteを、別のサンドボックスの場合はDenyを返すことができます。アイデンティティが拒否された後にルートの修復をトリガーするのは、認識されたリフレッシュシグナルだけです。トランスポートの障害には、操作ごとに定められた別のリカバリールールが適用されます。無効な署名、用途、ポートプロファイルは引き続き拒否されます。

対象となる操作は、現在の実行を解決し、再構築した試行を1回行うことができます。キャッシュの置き換えは拒否されたルートを条件として行われるため、遅れて届いた拒否によって新しいエントリが追い出されることはありません。ネイティブセッションの更新では元のキャッシュ有効期限が維持され、ルートの修復と呼び出し元の認可の更新が切り離されます。

リプレイのルールは引き続き操作ごとに異なります。クライアント側のWebSocketが開いたままであっても、置き換え後のバックエンドは改めてアドミッションを通過する必要があります。

拡大

トレードオフと信頼境界

実行アイデンティティは、セキュリティ上重要な状態になります。コントロールプレーンの更新と検証鍵のバンドルはサービングを担うコンポーネントに届く必要があり、廃止は各受信側が更新をインストールした時点で有効になります。ケイパビリティの有効期間を短くすることで、伝播中の再利用が制限されます。

この設計は、アイデンティティの強制が有効になっていることを前提とし、コントロールプレーンの署名者、ワーカーのカーネル、ノードローカルの管理サービスを信頼します。ワーカーのroot権限や、特権を持つクラスター管理者の侵害は、脅威モデルの対象外です。ブリッジの検証はローカルのプロセスとトランスポートの検証であり、ハードウェアに裏付けられたリモートアテステーションではありません。

署名検証、ランタイムの照合、ブリッジの検証により、リクエスト経路での処理が増えます。ただし、これらはプライベートなホップごとにリモートの認可照会を行うのではなく、ローカルの状態を使用します。

業界との比較

重要な比較ポイントは、認可されたリクエストが正しいサンドボックスの誤った実行に到達した場合に、各プラットフォームがどう対処するかです。以下の調査結果は検証対象の実装に関するものであり、プラットフォーム全体のセキュリティに関するものではありません。SPACE、OpenShell、E2Bは2026年10月8日に検証しました：

• OpenShell：ゲートウェイの世代チェックと認可チェック、バックエンドのアイデンティティ検証、アクティブなスーパーバイザー接続の確認を通じて、新規呼び出しに対する同等の実行選択と、スーパーバイザーとランタイム間のバインディングを提供します（ゲートウェイのアドミッション、ランタイムの認証とバインディング）。SPACEは署名付きの選択をサービング経路全体に引き継ぎ、ワーカーローカルでのプロセスとトランスポートの検証を加えます。一方OpenShellは、対応するチェックをゲートウェイ、起動時のアイデンティティ、認証済みのランタイムプロトコルに分散させています（ランタイム設計）。
• E2B：実行IDを追跡し、Firecrackerのライフサイクルごとにプロキシプールを分離していますが、インバウンドプロキシは、受信側が照合するための期待される実行アイデンティティを持たないまま、論理サンドボックスとポートを選択します（ルートの公開、プロキシのアドミッション）。認証情報が一致する古い受信側にまだ稼働中として登録されている古い実行は、これらのチェックでは、選択された新しい実行と区別できません。ただし、通常のティアダウンではルートが削除され、ライフサイクルに紐づく接続は閉じられます（認証情報、ティアダウン）。
• CubeSandbox：再開時にルーティングを修復してキャッシュを無効化しますが、プライベートイングレスはサンドボックス単位の認証情報を使用し、期待されるランタイムインスタンスを指定しないまま転送します（再開時のルーティング、イングレスのルーティング）。ルートの修復によって古いルートが残る時間枠は短くなりますが、SPACEの実行に紐づくケイパビリティは、誤ったインスタンスを受信側が拒否するための独立した根拠にもなります。

分離境界としてのアイデンティティ

安全な委任は、各エージェントの作業を、そのエージェントに意図された境界内に収められるかどうかにかかっています。microVMは分離を提供しますが、それを取り巻くプラットフォームは、すべてのリクエストと継続中の接続が、その処理を認可された実行に確実に到達するようにしなければなりません。

SPACEは、実行アイデンティティをその保護の一部にしています。宛先の確認、ブリッジエンドポイントの検証、そして接続とそれを認可した実行との結び付けによって、サンドボックスが一時停止、再開、移動しても、これらの境界を維持します。

インフラストラクチャの進化に合わせて、私たちはこの取り組みを続けています。SPACEをはじめとするサンドボックスプラットフォームのセキュリティを確保するには、日常的なルーティングの誤りと悪意のあるワークロードの両方に対してこれらの経路をテストし、テストで隙が見つかった箇所の境界を強化していく必要があります。