Cum rutează SPACE cererile către execuția corectă a sandboxului

Când cineva îi cere unui agent AI să analizeze o foaie de calcul sau să testeze software, are încredere că acesta va lucra în siguranță cu fișierele și datele sale. Agenții au nevoie de medii izolate în care să poată efectua această muncă fără a expune datele altor utilizatori și fără a le perturba sarcinile de lucru.

Pe măsură ce agenții preiau sarcini mai complexe, cu mai multă autonomie, aceste medii ajută la limitarea greșelilor și a daunelor pe care le poate provoca un cod nesigur sau rău intenționat. Sandboxurile asigură această izolare, deși partajează servicii ale planului de control, noduri worker și infrastructura de rutare.

Această infrastructură partajată trebuie să livreze fiecare operațiune către execuția autorizată să o gestioneze. O rută învechită poate trimite o cerere validă către un alt sandbox sau către o execuție mai veche a sandboxului corect. SPACE, platforma de sandbox securizată a Perplexity, leagă fiecare operațiune de o execuție selectată și verifică destinația înainte de redirecționare.

De luni de zile, SPACE gestionează milioane de execuții pe zi, fiecare protejată de o identitate criptografică unică, cu o rată de eroare sub 0,0002% și nicio conexiune întreruptă.

Problema rutării

Securitatea sandboxurilor depinde și de livrarea fiecărei cereri către destinația corectă. Chiar și o simplă citire de fișier trece printr-o infrastructură partajată care trebuie să țină evidența locului în care rulează sandboxul pe măsură ce acesta este pus în pauză, reluat sau mutat între mașini.

O citire de fișier trece prin mai multe componente. Planul de control al SPACE asociază sandboxul cu o execuție și un worker. Cererea intră prin node-api, trece la managerul de sandbox, sbx-manager, și traversează un socket Unix până la puntea de pe host, spaced-host. Puntea o redirecționează prin VSOCK, transportul socket dintre host și guest, către spaced-guest, în interiorul microVM-ului Firecracker.

Fiecare decizie se bazează pe o stare care poate rămâne în urma modificărilor de infrastructură. O bază de date poate păstra o plasare veche, o adresă din cache poate indica altundeva, iar o cale de socket poate ajunge să aibă un alt listener. O conexiune reușită poate ajunge totuși la destinația greșită. O citire ar putea expune datele altui utilizator; o scriere ar putea modifica sistemul de fișiere greșit.

Snapshoturile adaugă o altă problemă. Reluarea unui sandbox pe un alt worker îi păstrează identitatea logică, dar pornește o nouă execuție. O cerere întârziată sau o conexiune rămasă activă poate ajunge la execuția anterioară și poate returna o stare veche sub numele corect al sandboxului.

Extinde

Identitatea sandboxului și identitatea execuției

SPACE separă mediul utilizatorului de runtime-ul care îl servește:

• Identitatea sandboxului: ID-ul stabil al mediului logic. Autorizarea apelantului stabilește accesul la acest sandbox.
• Identitatea rutei/execuției: încarnarea de runtime selectată și plasarea acesteia, inclusiv workerul, substratul și activarea sa.

O generație de execuție distinge încarnările de runtime. Pe Kubernetes, ruta include și UID-ul podului. Adresele localizează endpointurile; identitatea execuției determină dacă acele endpointuri pot servi operațiunea.

Să presupunem că sandboxul S rulează ca execuția 7 pe workerul A, apoi este reluat ca execuția 8 pe workerul B. O cerere selectată pentru execuția 8 trebuie să eșueze dacă ajunge la execuția 7. O verificare limitată la ID-ul sandboxului nu ar detecta această neconcordanță.

Extinde

Selecția semnată a execuției

Fiecare cerere conține o dovadă semnată care arată ce execuție de sandbox o poate gestiona și ce acces este permis. Componenta care o primește verifică această dovadă în raport cu propria identitate de runtime înainte de a permite continuarea cererii.

După autorizarea apelantului, SPACE emite o capabilitate semnată, de scurtă durată, care identifică sandboxul, execuția, plasarea și accesul permis. Capabilitățile pentru porturile de servicii publice specifică, de asemenea, portul și protocolul permise.

Managerul de sandbox care primește cererea verifică semnătura și compară identitatea completă cu înregistrarea de runtime persistată local. Semnătura stabilește cine a autorizat selecția. Comparația stabilește dacă selecția corespunde receptorului.

Traficul ServicePort trece printr-o a doua verificare la gateway-ul de rețea dedicat fiecărui sandbox, netgtw, înainte de deschiderea unei conexiuni către guest. Gateway-ul compară identitatea cu starea de activare de încredere și verifică portul și protocolul. Operațiunile de control continuă cu verificarea endpointurilor punții.

SPACE folosește semnături Ed25519. Cheile de semnare ale planului de control emit capabilități; cheile publice de verificare de pe workeri și gateway-uri nu le pot emite.

Capabilitățile sunt valabile 120 de secunde, cu o toleranță de până la 15 secunde pentru decalajul de ceas la expirare. O semnătură validă și un token neexpirat tot nu sunt suficiente atunci când identitățile selectată și instalată nu coincid.

Extinde

Respingerea la destinația greșită

Workerul care primește cererea poate detecta o eroare de rutare chiar și atunci când cererea în sine este autorizată. Acesta verifică dacă rulează execuția selectată pentru cererea respectivă și o respinge dacă cele două diferă.

Dacă o cerere selectată pentru execuția 8 ajunge la workerul A, care încă deservește execuția 7, workerul A o respinge înainte de a o redirecționa. Odată ce un receptor instalează identitatea execuției 8, respinge și capabilitățile pentru execuția 7, chiar înainte ca acestea să expire.

Această garanție are o limită importantă. O capabilitate pentru execuția 7 poate corespunde în continuare unui worker care servește execuția 7, până când acel worker află de retragerea ei sau până când capabilitatea expiră. Aplicarea locală a regulilor și durata de viață limitată a capabilităților funcționează împreună cât timp actualizările se propagă.

Extinde

Verificarea endpointurilor punții

O înregistrare de runtime care corespunde stabilește execuția vizată. Puntea de control trebuie, de asemenea, să ajungă la procesele și la transportul care aparțin acelei activări, nu la un înlocuitor care a moștenit aceeași adresă.

Managerii de sandbox și de nod verifică credențialele peer ale punții de pe host și identitățile proceselor atât ale punții, cât și ale Firecracker, inclusiv momentele de pornire, detectând ID-urile reutilizate sau executabilele modificate

Verificările de transport leagă listenerul VSOCK de procesul Firecracker așteptat, folosind proprietatea asupra socketului, identitatea guestului și dovezi despre socket furnizate de kernel. Puntea redirecționează operațiunile numai după verificare și refuză reconectările transparente. Fiecare conexiune nouă trebuie să treacă din nou verificările.

Această verificare acoperă puntea de control Firecracker pe Kubernetes și pe hosturile gestionate direct. Traficul ServicePort folosește verificări ale execuției și ale portului la gateway-ul său; acestea nu atestă identitatea unei aplicații arbitrare din interiorul guestului.

Extinde

Durata de viață a fluxurilor și recuperarea rutelor

Unele conexiuni rămân deschise în timp ce execuția unui sandbox se schimbă, așa că verificările de identitate trebuie să meargă dincolo de cererea inițială. SPACE retrage conexiunile legate de vechea execuție și permite operațiunilor eligibile să se reconecteze la cea curentă, cu aceleași verificări de securitate.

Terminalele și monitorizările de fișiere pot rămâne active după încheierea cererilor care le-au deschis. SPACE leagă fluxurile de backend de o epocă de identitate, astfel încât un flux să nu poată rămâne atașat execuției anterioare după ce receptorul instalează o execuție de înlocuire.

SPACE reverifică identitatea durabilă înainte de a deschide un flux. Înlocuirea rutei sau a execuției anulează lease-ul fluxului, oprind intrarea și ieșirea.

Schimbările de proprietar sunt diferite de înlocuirea execuției. Un transfer al unei operațiuni de ciclu de viață pe un rezident Kubernetes neschimbat îi păstrează identitatea rutei, capabilitățile neexpirate și fluxurile. De asemenea, gateway-ul păstrează fluxurile stabilite în cazul modificărilor care vizează doar încercarea de activare, în cadrul aceleiași rute și al aceleiași generații de execuție. Deschiderile noi necesită identitatea actualizată.

Recuperarea păstrează aceste verificări intacte. Comparatorul de identitate poate returna RefreshRoute pentru o nepotrivire de încarnare în cadrul aceluiași sandbox sau Deny pentru un sandbox diferit. Doar un semnal de reîmprospătare recunoscut declanșează repararea rutei după respingerea identității. Erorile de transport urmează reguli de recuperare separate, specifice fiecărei operațiuni. Semnăturile, scopurile sau profilurile de port nevalide rămân refuzate.

O operațiune eligibilă poate determina execuția curentă și poate face o singură încercare reconstruită. Înlocuirea din cache este condiționată de ruta respinsă, ceea ce împiedică o respingere întârziată să elimine o intrare mai nouă. Reîmprospătarea sesiunii native păstrează expirarea inițială din cache, separând repararea rutei de reînnoirea autorizării apelantului.

Regulile de reexecutare rămân specifice fiecărei operațiuni. Un backend de înlocuire trebuie să treacă din nou de admitere, chiar și atunci când WebSocketul expus clientului rămâne deschis.

Extinde

Compromisuri și limite de încredere

Identitatea execuției devine o stare critică pentru securitate. Actualizările planului de control și pachetele de chei de verificare trebuie să ajungă la componentele care servesc cererile, iar retragerea intră în vigoare atunci când fiecare receptor instalează actualizarea. Duratele de viață scurte ale capabilităților limitează reutilizarea în timpul propagării.

Designul presupune că aplicarea identității este activată și are încredere în semnatarul planului de control, în kernelul workerului și în serviciile de management locale ale nodului. Compromiterea contului root al workerului sau a unui administrator de cluster privilegiat nu face parte din modelul de amenințare. Verificarea punții este o verificare locală a proceselor și a transportului, nu o atestare la distanță bazată pe hardware.

Verificarea semnăturilor, comparațiile de runtime și validarea punții adaugă muncă pe calea cererii. Acestea folosesc starea locală, nu o interogare de autorizare la distanță la fiecare salt privat.

Comparație cu industria

Comparația relevantă privește modul în care platformele gestionează o cerere autorizată care ajunge la execuția greșită a sandboxului corect. Aceste constatări se referă la implementările examinate, nu la securitatea generală a platformelor. SPACE, OpenShell și E2B au fost verificate pe 8 octombrie 2026:

• OpenShell: Oferă o selecție comparabilă a execuției pentru apelurile noi și o legare supervisor–runtime prin verificări de generație și de autorizare în gateway, validarea identității backendului și conexiuni active confirmate ale supervisorului (admiterea în gateway, autentificarea și legarea runtime-ului). SPACE transportă selecția semnată de-a lungul căii sale de servire și adaugă verificarea locală, pe worker, a proceselor și a transportului; OpenShell distribuie verificări corespunzătoare între gateway, identitatea de lansare și protocolul de runtime autentificat (designul runtime-ului).
• E2B: Urmărește ID-urile execuțiilor și izolează pool-urile de proxy în funcție de ciclul de viață Firecracker, dar proxy-ul său de intrare selectează sandboxul logic și portul fără o identitate de execuție așteptată pe care receptorul să o poată compara (publicarea rutelor, admiterea în proxy). O execuție mai veche, încă înregistrată ca activă pe un receptor învechit cu credențiale corespunzătoare, nu poate fi distinsă prin aceste verificări de execuția mai nouă selectată, deși demontarea normală elimină rutele și închide conexiunile legate de ciclul de viață (credențiale, demontare).
• CubeSandbox: Repară rutarea la reluare și invalidează cache-urile, dar ingress-ul privat folosește credențiale limitate la sandbox și redirecționează fără o încarnare de runtime așteptată (rutarea la reluare, rutarea ingress). Repararea rutelor reduce intervalele cu rute învechite; capabilitatea legată de execuție a SPACE oferă, în plus, receptorului o bază independentă pentru a respinge încarnarea greșită.

Identitatea ca limită de izolare

Delegarea sigură depinde de menținerea activității fiecărui agent în limitele stabilite pentru el. Un microVM oferă izolare, în timp ce platforma din jur trebuie să se asigure că fiecare cerere și fiecare conexiune în curs ajunge la execuția autorizată să o gestioneze.

SPACE face din identitatea execuției o parte a acestei protecții. Prin verificarea destinațiilor, validarea endpointurilor punții și legarea conexiunilor de execuția care le-a autorizat, SPACE menține aceste limite pe măsură ce sandboxurile sunt puse în pauză, reluate și mutate.

Ne continuăm munca pe măsură ce infrastructura evoluează. Pentru SPACE și alte platforme de sandbox, securitatea presupune testarea acestor căi atât împotriva erorilor de rutare obișnuite, cât și a sarcinilor de lucru ostile, apoi consolidarea limitelor oriunde aceste teste scot la iveală lacune.