SPACE 如何將請求路由至正確的沙箱執行個體

當使用者請 AI 代理程式分析試算表或測試軟體時，就是信任它能安全地處理自己的檔案與資料。AI 代理程式需要隔離的環境，才能在不暴露其他使用者資料、也不干擾其工作負載的情況下完成這些工作。

隨著 AI 代理程式以更高的自主性承擔更複雜的任務，這些環境有助於控制錯誤，並限制不安全或惡意程式碼可能造成的損害。沙箱在提供這種隔離的同時，也共用控制平面服務、工作節點與路由基礎架構。

這些共用基礎架構必須將每項操作送達獲授權處理該操作的執行個體。過時的路由可能將有效的請求送往另一個沙箱，或送往正確沙箱的較舊執行個體。SPACE 是 Perplexity 的安全沙箱平台，會將每項操作綁定至所選的執行個體，並在轉送前檢查目的地。

數月以來，SPACE 每天處理數百萬次執行，每次執行都受到獨一無二的加密身分保護，錯誤率低於 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 接受第二次檢查。閘道會將身分與受信任的啟用狀態進行比對，並檢查連接埠與通訊協定。控制操作則會進入橋接器端點驗證。

SPACE 使用 Ed25519 簽章。權能由控制平面簽署金鑰核發；工作節點與閘道上的公開驗證金鑰則無法核發權能。

權能的有效期為 120 秒，判定到期時最多容許 15 秒的時鐘偏差。當所選身分與已安裝的身分不一致時，即使簽章有效且權杖未過期，仍不足以放行。

放大

在錯誤的目的地拒絕請求

即使請求本身已獲授權，接收端工作節點仍能發現路由錯誤。它會檢查自己是否正在執行為該請求所選的執行個體，若兩者不同，便拒絕該請求。

如果為執行 8 選定的請求抵達仍在服務執行 7 的工作節點 A，工作節點 A 會在轉送前予以拒絕。一旦接收端安裝了執行 8 的身分，即使執行 7 的權能尚未過期，接收端也會拒絕這些權能。

這項保證有一個重要的界限。在工作節點得知執行個體 7 已淘汰或權能到期之前，執行個體 7 的權能仍可能與正在服務執行個體 7 的該工作節點相符。在更新傳播期間，本機強制執行與有限的權能有效期會相互配合。

放大

橋接器端點驗證

相符的執行階段記錄可確立預定的執行個體。控制橋接也必須抵達屬於該次啟用的程序與傳輸，而不是繼承了相同位址的替代者。

沙箱與節點管理器會驗證主機橋接器的對等端憑證，以及橋接器與 Firecracker 的程序身分（包括啟動時間），以偵測重複使用的 ID 或已變更的執行檔

傳輸檢查會利用通訊端擁有權、客體身分與核心通訊端證據，將 VSOCK 監聽程式與預期的 Firecracker 程序綁定。橋接器僅在驗證完成後才轉送操作，並拒絕透明重新連線。每個新連線都必須再次通過這些檢查。

此驗證涵蓋 Kubernetes 及直接管理之主機上的 Firecracker 控制橋接。ServicePort 流量則在其閘道使用執行個體與連接埠檢查；它不會證明客體內任意應用程式的身分。

放大

串流生命週期與路由復原

某些連線會在沙箱的執行個體變更時保持開啟，因此身分檢查必須延伸至初始請求之外。SPACE 會淘汰與舊執行個體綁定的連線，並讓符合資格的操作在相同的安全檢查下，重新連線至目前的執行個體。

終端機與檔案監看的存續時間，可能比開啟它們的請求更長。SPACE 將後端串流與身分紀元綁定，因此在接收端安裝替代執行個體後，串流就無法繼續連接在前一個執行個體上。

SPACE 會在開啟串流前重新檢查持久身分。替換其路由或執行個體會取消該串流的租約，停止輸入與輸出。

擁有權變更與執行個體替換是兩回事。在未變更的 Kubernetes 常駐實體上進行生命週期操作交接時，會保留其路由身分、未過期的權能與串流。對於在相同路由與執行世代內僅涉及啟用嘗試的變更，閘道也會保留已建立的串流。新的開啟操作則需要使用更新後的身分。

復原過程會完整保留這些檢查。身分比較器可以在同一沙箱內實例不符時傳回 RefreshRoute，或在沙箱不同時傳回 Deny。身分遭拒後，只有可辨識的重新整理訊號才會觸發路由修復。傳輸失敗則遵循另行訂定、依操作而異的復原規則。無效的簽章、用途或連接埠設定檔仍會遭到拒絕。

符合資格的操作可以解析目前的執行個體，並進行一次重建後的嘗試。快取替換以遭拒絕的路由為條件，可防止延遲的拒絕回應逐出較新的項目。原生工作階段重新整理會保留原本的快取到期時間，將路由修復與呼叫端授權的續期區分開來。

重播規則仍因操作而異。即使面向用戶端的 WebSocket 保持開啟，替代的後端也必須再次通過准入檢查。

放大

取捨與信任邊界

執行身分因此成為攸關安全的狀態。控制平面更新與驗證金鑰組合必須送達提供服務的元件，而淘汰會在各接收端安裝更新時生效。較短的權能有效期可限制傳播期間的重複使用。

此設計假設已啟用身分強制執行，並信任控制平面簽署者、工作節點核心與節點本機管理服務。工作節點 root 權限或具特殊權限的叢集管理員遭入侵，不在此威脅模型的範圍內。橋接器驗證是本機的程序與傳輸驗證，而非以硬體為基礎的遠端證明。

簽章驗證、執行階段比對與橋接器驗證，會增加請求路徑上的工作量。這些機制使用本機狀態，而不是在每個私有躍點都進行遠端授權查詢。

業界比較

值得比較的是，各平台如何處理已授權請求抵達正確沙箱之錯誤執行個體的情況。這些發現僅涉及所檢視的實作，而非平台的整體安全性。SPACE、OpenShell 與 E2B 的檢查日期為 2026 年 10 月 8 日：

• OpenShell：透過閘道世代與授權檢查、後端身分驗證，以及已確認的作用中監督程式連線，提供類似的新呼叫執行個體選擇機制，以及監督程式與執行階段之間的綁定（閘道准入、執行階段驗證與綁定）。SPACE 在其服務路徑中全程攜帶已簽署的選擇，並加上工作節點本機的程序與傳輸驗證；OpenShell 則將對應的檢查分散在其閘道、啟動身分與經驗證的執行階段通訊協定中（執行階段設計）。
• E2B：會追蹤執行 ID，並依 Firecracker 生命週期隔離代理伺服器集區，但其傳入代理伺服器在選擇邏輯沙箱與連接埠時，並未附帶可供接收端比對的預期執行身分（路由發布、代理伺服器准入）。若較舊的執行個體仍在憑證相符的過時接收端上登記為作用中，這些檢查便無法將它與所選的較新執行個體區分開來，不過正常的拆除流程會移除路由，並關閉與生命週期綁定的連線（憑證、拆除）。
• CubeSandbox：會在恢復執行時修復路由並使快取失效，但其私有入口使用沙箱範圍的憑證，且轉送時不帶有預期的執行階段實體（恢復路由、入口路由）。路由修復可縮短過時路由的時間窗口；SPACE 與執行個體綁定的權能，也讓接收端擁有獨立的依據來拒絕錯誤的執行階段實體。

以身分作為隔離界限

安全的委派取決於讓每個 AI 代理程式的工作維持在預定的界限之內。microVM 提供隔離，而周邊平台則必須確保每個請求與持續中的連線，都能送達獲授權處理它的執行個體。

SPACE 將執行身分納入這層保護之中。透過檢查目的地、驗證橋接器端點，並將連線綁定至授權它們的執行個體，SPACE 能在沙箱暫停、恢復執行與移動時維持這些界限。

隨著基礎架構持續演進，我們也將持續推進這項工作。對 SPACE 及其他沙箱平台而言，安全性需要針對例行的路由錯誤與惡意工作負載測試這些路徑，並在測試揭露缺口之處強化界限。