Come SPACE instrada le richieste all’esecuzione giusta della sandbox

Quando qualcuno chiede a un agente IA di analizzare un foglio di calcolo o di testare un software, si affida al fatto che lavori in sicurezza con i propri file e dati. Gli agenti hanno bisogno di ambienti isolati in cui svolgere quel lavoro senza esporre i dati di altri utenti né interferire con i loro carichi di lavoro.

Man mano che gli agenti assumono compiti più complessi con maggiore autonomia, questi ambienti aiutano a contenere gli errori e a limitare i danni che il codice non sicuro o dannoso può causare. Le sandbox forniscono questo isolamento pur condividendo i servizi del control plane, i nodi worker e l’infrastruttura di routing.

Questa infrastruttura condivisa deve recapitare ogni operazione all’esecuzione autorizzata a gestirla. Una route obsoleta può inviare una richiesta valida a un’altra sandbox o a un’esecuzione precedente della sandbox giusta. SPACE, la piattaforma di sandbox sicura di Perplexity, vincola ogni operazione a un’esecuzione selezionata e verifica la destinazione prima dell’inoltro.

Da mesi SPACE gestisce milioni di esecuzioni al giorno, ciascuna protetta da un'identità crittografica univoca, con un tasso di errore inferiore allo 0,0002% e zero connessioni interrotte.

Il problema del routing

La sicurezza delle sandbox dipende anche dal recapitare ogni richiesta alla destinazione giusta. Persino una semplice lettura di file attraversa un’infrastruttura condivisa che deve tenere traccia di dove è in esecuzione la sandbox mentre questa viene sospesa, ripresa o spostata da una macchina all’altra.

Una lettura di file attraversa diversi componenti. Il control plane di SPACE risolve la sandbox in un’esecuzione e un worker. La richiesta entra tramite node-api, passa al gestore della sandbox, sbx-manager, e attraversa un socket Unix fino al bridge dell’host, spaced-host. Il bridge la inoltra tramite VSOCK, il trasporto socket da host a guest, a spaced-guest all’interno della microVM Firecracker.

Ogni decisione si basa su uno stato che può restare indietro rispetto ai cambiamenti dell’infrastruttura. Un database può conservare un vecchio posizionamento, un indirizzo in cache può puntare altrove o il percorso di un socket può acquisire un listener diverso. Una connessione riuscita può comunque raggiungere la destinazione sbagliata. Una lettura potrebbe esporre i dati di un altro utente; una scrittura potrebbe modificare il file system sbagliato.

Gli snapshot introducono un ulteriore problema. Riprendere una sandbox su un altro worker ne preserva l’identità logica, ma avvia una nuova esecuzione. Una richiesta in ritardo o una connessione sopravvissuta può raggiungere l’esecuzione precedente e restituire uno stato obsoleto con il nome della sandbox giusta.

Espandi

Identità della sandbox e identità dell'esecuzione

SPACE separa l’ambiente dell’utente dal runtime che lo serve:

• Identità della sandbox: l’ID stabile dell’ambiente logico. L’autorizzazione del chiamante stabilisce l’accesso a questa sandbox.
• Identità di route/esecuzione: l'incarnazione di runtime selezionata e il suo posizionamento, inclusi worker, substrato e attivazione.

Una generazione di esecuzione distingue le incarnazioni del runtime. Su Kubernetes, la route include anche l’UID del pod. Gli indirizzi individuano gli endpoint; l’identità dell’esecuzione determina se tali endpoint possono servire l’operazione.

Supponiamo che la sandbox S sia in esecuzione come esecuzione 7 sul worker A e venga poi ripresa come esecuzione 8 sul worker B. Una richiesta selezionata per l’esecuzione 8 deve fallire se raggiunge l’esecuzione 7. Verificare solo l’ID della sandbox non basterebbe a rilevare la discrepanza.

Espandi

Selezione firmata dell'esecuzione

Ogni richiesta contiene una prova firmata di quale esecuzione della sandbox può gestirla e di quale accesso è consentito. Il componente ricevente confronta tale prova con la propria identità di runtime prima di lasciar proseguire la richiesta.

Dopo l’autorizzazione del chiamante, SPACE emette una capability firmata e di breve durata che identifica la sandbox, l’esecuzione, il posizionamento e l’accesso consentito. Le capability delle porte di servizio pubbliche specificano anche la porta e il protocollo consentiti.

Il gestore della sandbox ricevente verifica la firma e confronta l’identità completa con il record di runtime che ha salvato localmente. La firma stabilisce chi ha autorizzato la selezione. Il confronto stabilisce se tale selezione corrisponde al destinatario.

Il traffico ServicePort è sottoposto a un secondo controllo presso il gateway di rete dedicato a ogni sandbox, netgtw, prima che venga aperta una connessione verso il guest. Il gateway confronta l’identità con lo stato di attivazione attendibile e verifica la porta e il protocollo. Le operazioni di controllo passano alla verifica degli endpoint del bridge.

SPACE usa firme Ed25519. Le chiavi di firma del control plane emettono le capability; le chiavi pubbliche di verifica presenti su worker e gateway non possono emetterle.

Le capability durano 120 secondi, con una tolleranza fino a 15 secondi per lo sfasamento dell’orologio alla scadenza. Una firma valida e un token non scaduto restano comunque insufficienti quando l’identità selezionata e quella installata non coincidono.

Espandi

Rifiuto alla destinazione sbagliata

Il worker ricevente può intercettare un errore di routing anche quando la richiesta in sé è autorizzata. Verifica se l’esecuzione in corso è quella selezionata per quella richiesta e, in caso di discrepanza, rifiuta la richiesta.

Se una richiesta selezionata per l'esecuzione 8 raggiunge il worker A, che serve ancora l'esecuzione 7, il worker A la rifiuta prima di inoltrarla. Una volta che un ricevitore installa l'identità dell'esecuzione 8, rifiuta anche le capability per l'esecuzione 7, anche prima che scadano.

Questa garanzia ha un limite importante. Una capability per l’esecuzione 7 può ancora corrispondere a un worker che serve l’esecuzione 7 finché quel worker non viene a conoscenza del ritiro o finché la capability non scade. L’applicazione locale dei controlli e la durata limitata delle capability agiscono insieme mentre gli aggiornamenti si propagano.

Espandi

Verifica degli endpoint del bridge

Un record di runtime corrispondente stabilisce l’esecuzione prevista. Il bridge di controllo deve inoltre raggiungere i processi e il trasporto appartenenti a quell’attivazione, anziché un sostituto che ha ereditato lo stesso indirizzo.

I gestori della sandbox e del nodo verificano le credenziali peer del bridge dell’host e le identità di processo sia del bridge sia di Firecracker, inclusi gli orari di avvio, rilevando ID riutilizzati o eseguibili modificati

I controlli sul trasporto legano il listener VSOCK al processo Firecracker atteso tramite la proprietà del socket, l’identità del guest e le evidenze sui socket a livello di kernel. Il bridge inoltra le operazioni solo dopo la verifica e rifiuta le riconnessioni trasparenti. Ogni nuova connessione deve superare di nuovo i controlli.

Questa verifica riguarda il bridge di controllo di Firecracker su Kubernetes e sugli host gestiti direttamente. Il traffico ServicePort è soggetto a controlli sull’esecuzione e sulla porta presso il relativo gateway; non attesta l’identità di un’applicazione arbitraria all’interno del guest.

Espandi

Durata degli stream e ripristino delle route

Alcune connessioni restano aperte mentre l’esecuzione di una sandbox cambia, quindi i controlli sull’identità devono estendersi oltre la richiesta iniziale. SPACE ritira le connessioni legate alla vecchia esecuzione e consente alle operazioni idonee di riconnettersi a quella corrente con gli stessi controlli di sicurezza.

Terminali e osservatori di file possono sopravvivere alle richieste che li hanno aperti. SPACE lega gli stream del backend a un’epoca di identità, in modo che uno stream non possa restare collegato all’esecuzione precedente dopo che il destinatario ha installato un’esecuzione sostitutiva.

SPACE ricontrolla l’identità persistente prima di aprire uno stream. La sostituzione della relativa route o esecuzione annulla il lease dello stream, interrompendo input e output.

I cambi di proprietà sono distinti dalla sostituzione dell’esecuzione. Il passaggio di consegne di un’operazione del ciclo di vita su un resident Kubernetes invariato ne preserva l’identità di route, le capability non scadute e gli stream. Il gateway preserva inoltre gli stream già stabiliti in caso di modifiche che riguardano solo il tentativo di attivazione, all’interno della stessa route e della stessa generazione di esecuzione. Le nuove aperture richiedono l’identità aggiornata.

Il ripristino mantiene intatti questi controlli. Il comparatore di identità può restituire RefreshRoute in caso di mancata corrispondenza dell'incarnazione all'interno della stessa sandbox, oppure Deny per una sandbox diversa. Solo un segnale di aggiornamento riconosciuto attiva la riparazione della route dopo il rifiuto dell'identità. Gli errori di trasporto seguono regole di ripristino separate e specifiche per ciascuna operazione. Firme, scopi o profili di porta non validi restano rifiutati.

Un’operazione idonea può risolvere l’esecuzione corrente ed effettuare un unico nuovo tentativo ricostruito. La sostituzione nella cache è subordinata alla route rifiutata, impedendo che un rifiuto tardivo rimuova una voce più recente. L’aggiornamento della sessione nativa preserva la scadenza originale della cache, separando la riparazione delle route dal rinnovo dell’autorizzazione del chiamante.

Le regole di replay restano specifiche per ogni operazione. Un backend sostitutivo deve superare di nuovo l’ammissione, anche quando il WebSocket lato client rimane aperto.

Espandi

Compromessi e confini di fiducia

L’identità dell’esecuzione diventa uno stato critico per la sicurezza. Gli aggiornamenti del control plane e i bundle di chiavi di verifica devono raggiungere i componenti che servono le richieste, e il ritiro ha effetto quando ciascun destinatario installa l’aggiornamento. La breve durata delle capability limita il riutilizzo durante la propagazione.

Il design presuppone che l’applicazione dei controlli di identità sia abilitata e considera attendibili il firmatario del control plane, il kernel del worker e i servizi di gestione locali al nodo. La compromissione dell’utente root del worker o di un amministratore del cluster con privilegi esula dal modello di minaccia. La verifica del bridge è una verifica locale di processo e trasporto, non un’attestazione remota basata su hardware.

La verifica delle firme, i confronti di runtime e la convalida del bridge aggiungono lavoro al percorso della richiesta. Si basano sullo stato locale anziché su una verifica remota dell’autorizzazione a ogni hop privato.

Confronto con il settore

Il confronto rilevante riguarda il modo in cui le piattaforme gestiscono una richiesta autorizzata che raggiunge l’esecuzione sbagliata della sandbox giusta. Queste osservazioni riguardano le implementazioni esaminate, non la sicurezza complessiva delle piattaforme. SPACE, OpenShell ed E2B sono stati verificati l’8 ottobre 2026:

• OpenShell: offre una selezione dell’esecuzione per le nuove chiamate e un binding tra supervisor e runtime comparabili, tramite controlli di generazione e autorizzazione sul gateway, convalida dell’identità del backend e conferma delle connessioni attive del supervisor (ammissione al gateway, autenticazione e binding del runtime). SPACE porta la selezione firmata lungo tutto il proprio percorso di servizio e aggiunge la verifica di processo e trasporto locale al worker; OpenShell distribuisce i controlli corrispondenti tra il proprio gateway, l’identità di avvio e il protocollo di runtime autenticato (progettazione del runtime).
• E2B: tiene traccia degli ID di esecuzione e isola i pool di proxy in base al ciclo di vita di Firecracker, ma il suo proxy in ingresso seleziona la sandbox logica e la porta senza un’identità di esecuzione attesa da confrontare sul destinatario (pubblicazione delle route, ammissione al proxy). Con questi controlli, un’esecuzione precedente ancora registrata come attiva su un destinatario obsoleto con credenziali corrispondenti non può essere distinta dall’esecuzione più recente selezionata, anche se il normale smantellamento rimuove le route e chiude le connessioni legate al ciclo di vita (credenziali, smantellamento).
• CubeSandbox: ripristina il routing alla ripresa e invalida le cache, ma l’ingress privato usa credenziali con ambito sandbox e inoltra il traffico senza un’incarnazione di runtime attesa (routing alla ripresa, routing dell’ingress). La riparazione delle route riduce le finestre di esposizione a route obsolete; la capability vincolata all’esecuzione di SPACE fornisce inoltre al destinatario una base indipendente per rifiutare l’incarnazione sbagliata.

L’identità come confine di isolamento

Una delega sicura dipende dal mantenere il lavoro di ogni agente entro i confini previsti. Una microVM fornisce l’isolamento, mentre la piattaforma circostante deve garantire che ogni richiesta e ogni connessione in corso raggiunga l’esecuzione autorizzata a gestirla.

SPACE rende l’identità dell’esecuzione parte di questa protezione. Verificando le destinazioni e gli endpoint del bridge e legando le connessioni all’esecuzione che le ha autorizzate, preserva questi confini mentre le sandbox vengono sospese, riprese e spostate.

Continuiamo a lavorarci man mano che l’infrastruttura evolve. Per SPACE e per le altre piattaforme di sandbox, la sicurezza richiede di testare questi percorsi sia contro i normali errori di routing sia contro carichi di lavoro ostili, rafforzando poi i confini ovunque tali test rivelino lacune.