Jak SPACE kieruje żądania do właściwego wykonania piaskownicy

Gdy ktoś prosi agenta AI o analizę arkusza kalkulacyjnego lub przetestowanie oprogramowania, ufa, że będzie on bezpiecznie pracował z jego plikami i danymi. Agenci potrzebują odizolowanych środowisk, w których mogą wykonywać tę pracę, nie ujawniając danych innych użytkowników ani nie zakłócając ich obciążeń roboczych.

W miarę jak agenci podejmują się coraz bardziej złożonych zadań z coraz większą autonomią, takie środowiska pomagają ograniczać skutki błędów i szkody, jakie może wyrządzić niebezpieczny lub złośliwy kod. Piaskownice zapewniają tę izolację, współdzieląc jednocześnie usługi płaszczyzny sterowania, węzły robocze i infrastrukturę routingu.

Ta współdzielona infrastruktura musi dostarczać każdą operację do wykonania uprawnionego do jej obsługi. Nieaktualna trasa może skierować prawidłowe żądanie do innej piaskownicy lub do starszego wykonania właściwej piaskownicy. SPACE, bezpieczna platforma piaskownic Perplexity, wiąże każdą operację z wybranym wykonaniem i sprawdza miejsce docelowe przed przekazaniem żądania dalej.

Od miesięcy SPACE obsługuje miliony wykonań dziennie, z których każde jest chronione unikatową tożsamością kryptograficzną, przy współczynniku błędów poniżej 0,0002% i bez ani jednego zerwanego połączenia.

Problem routingu

Bezpieczeństwo piaskownicy zależy również od tego, czy każde żądanie trafia we właściwe miejsce. Nawet zwykły odczyt pliku przechodzi przez współdzieloną infrastrukturę, która musi śledzić, gdzie działa piaskownica, gdy jest ona wstrzymywana, wznawiana lub przenoszona między maszynami.

Odczyt pliku przechodzi przez kilka komponentów. Płaszczyzna sterowania SPACE mapuje piaskownicę na wykonanie i węzeł roboczy. Żądanie wchodzi przez node-api, trafia do menedżera piaskownicy, sbx-manager, i przez gniazdo uniksowe dociera do mostka hosta, spaced-host. Mostek przekazuje je przez VSOCK, czyli transport gniazd między hostem a gościem, do spaced-guest wewnątrz microVM Firecracker.

Każda decyzja opiera się na stanie, który może nie nadążać za zmianami w infrastrukturze. Baza danych może przechowywać stare rozmieszczenie, adres z pamięci podręcznej może wskazywać gdzie indziej, a ścieżka gniazda może zyskać inny proces nasłuchujący. Udane połączenie nadal może trafić w niewłaściwe miejsce. Odczyt mógłby ujawnić dane innego użytkownika, a zapis zmodyfikować niewłaściwy system plików.

Migawki wprowadzają kolejny problem. Wznowienie piaskownicy na innym węźle roboczym zachowuje jej tożsamość logiczną, ale rozpoczyna nowe wykonanie. Opóźnione żądanie lub połączenie, które przetrwało, może trafić do jej poprzednika i zwrócić stary stan pod właściwą nazwą piaskownicy.

Powiększ

Tożsamość piaskownicy i tożsamość wykonania

SPACE oddziela środowisko użytkownika od obsługującego je środowiska uruchomieniowego:

• Tożsamość piaskownicy: Stały identyfikator środowiska logicznego. Autoryzacja wywołującego ustala dostęp do tej piaskownicy.
• Tożsamość trasy/wykonania: wybrana inkarnacja środowiska uruchomieniowego i jej rozmieszczenie, w tym proces roboczy (worker), substrat i aktywacja.

Generacja wykonania rozróżnia inkarnacje środowiska uruchomieniowego. W Kubernetes trasa obejmuje również UID poda. Adresy lokalizują punkty końcowe; tożsamość wykonania decyduje, czy te punkty końcowe mogą obsłużyć operację.

Załóżmy, że piaskownica S działa jako wykonanie 7 na węźle roboczym A, a następnie zostaje wznowiona jako wykonanie 8 na węźle roboczym B. Żądanie wybrane dla wykonania 8 musi zakończyć się niepowodzeniem, jeśli trafi do wykonania 7. Sprawdzenie samego identyfikatora piaskownicy nie wykryłoby tej niezgodności.

Powiększ

Podpisany wybór wykonania

Każde żądanie zawiera podpisany dowód tego, które wykonanie piaskownicy może je obsłużyć i jaki dostęp jest dozwolony. Komponent odbierający porównuje ten dowód z własną tożsamością środowiska uruchomieniowego, zanim pozwoli na dalsze przetwarzanie żądania.

Po autoryzacji wywołującego SPACE wydaje krótkotrwałe, podpisane uprawnienie, które identyfikuje piaskownicę, wykonanie, rozmieszczenie i dozwolony dostęp. Uprawnienia do publicznych portów usług określają ponadto dozwolony port i protokół.

Odbierający menedżer piaskownicy weryfikuje podpis i porównuje pełną tożsamość z lokalnie utrwalonym rekordem środowiska uruchomieniowego. Podpis ustala, kto autoryzował wybór. Porównanie ustala, czy ten wybór pasuje do odbiorcy.

Ruch ServicePort przechodzi drugą kontrolę w bramie sieciowej przypisanej do danej piaskownicy, netgtw, zanim zostanie otwarte połączenie z gościem. Brama porównuje tożsamość z zaufanym stanem aktywacji oraz sprawdza port i protokół. Operacje sterujące przechodzą do weryfikacji punktów końcowych mostka.

SPACE używa podpisów Ed25519. Klucze podpisujące w płaszczyźnie sterowania wydają uprawnienia; publiczne klucze weryfikacyjne na węzłach roboczych i w bramach nie mogą ich wydawać.

Uprawnienia są ważne przez 120 sekund, z tolerancją rozbieżności zegarów przy wygasaniu wynoszącą do 15 sekund. Prawidłowy podpis i niewygasły token nadal nie wystarczą, gdy tożsamość wybrana i zainstalowana się różnią.

Powiększ

Odrzucanie w niewłaściwym miejscu docelowym

Odbierający węzeł roboczy może wychwycić błąd routingu nawet wtedy, gdy samo żądanie jest autoryzowane. Sprawdza, czy uruchamia wykonanie wybrane dla tego żądania, i odrzuca żądanie, jeśli tak nie jest.

Jeśli żądanie wybrane dla wykonania 8 trafi do procesu roboczego A, który nadal obsługuje wykonanie 7, proces roboczy A odrzuci je przed przekazaniem dalej. Gdy odbiorca zainstaluje tożsamość wykonania 8, odrzuca również uprawnienia (capabilities) dla wykonania 7, nawet zanim wygasną.

Ta gwarancja ma jednak istotną granicę. Uprawnienie dla wykonania 7 nadal może pasować do węzła roboczego obsługującego wykonanie 7, dopóki ten węzeł nie dowie się o wycofaniu wykonania lub uprawnienie nie wygaśnie. Lokalne egzekwowanie i ograniczony czas życia uprawnień działają wspólnie w trakcie propagacji aktualizacji.

Powiększ

Weryfikacja punktów końcowych mostka

Zgodny rekord środowiska uruchomieniowego ustala zamierzone wykonanie. Mostek sterujący musi ponadto dotrzeć do procesów i transportu należących do tej aktywacji, a nie do zastępcy, który odziedziczył ten sam adres.

Menedżery piaskownicy i węzła weryfikują poświadczenia peera mostka hosta oraz tożsamości procesów zarówno mostka, jak i Firecrackera, w tym czasy ich uruchomienia, wykrywając ponownie użyte identyfikatory lub zmienione pliki wykonywalne

Kontrole transportu wiążą nasłuchujące gniazdo VSOCK z oczekiwanym procesem Firecracker na podstawie własności gniazda, tożsamości gościa i dowodów pochodzących z gniazd jądra. Mostek przekazuje operacje dopiero po weryfikacji i odmawia przezroczystego ponownego łączenia. Każde nowe połączenie musi ponownie przejść te kontrole.

Ta weryfikacja obejmuje mostek sterujący Firecrackera w Kubernetes i na hostach zarządzanych bezpośrednio. Ruch ServicePort podlega w swojej bramie kontrolom wykonania i portu; kontrole te nie poświadczają jednak tożsamości dowolnej aplikacji działającej w systemie gościa.

Powiększ

Czas życia strumieni i odzyskiwanie tras

Niektóre połączenia pozostają otwarte, gdy zmienia się wykonanie piaskownicy, dlatego kontrole tożsamości muszą wykraczać poza pierwsze żądanie. SPACE wycofuje połączenia powiązane ze starym wykonaniem i pozwala kwalifikującym się operacjom ponownie połączyć się z bieżącym wykonaniem przy zachowaniu tych samych kontroli bezpieczeństwa.

Terminale i obserwatory plików mogą istnieć dłużej niż żądania, które je otworzyły. SPACE wiąże strumienie backendu z epoką tożsamości, dzięki czemu strumień nie może pozostać podłączony do poprzednika po zainstalowaniu przez odbiorcę wykonania zastępczego.

SPACE ponownie sprawdza trwałą tożsamość przed otwarciem strumienia. Zastąpienie jego trasy lub wykonania anuluje dzierżawę strumienia, zatrzymując wejście i wyjście.

Zmiany własności to coś innego niż zastąpienie wykonania. Przekazanie operacji cyklu życia w obrębie niezmienionej instancji rezydującej w Kubernetes zachowuje jej tożsamość trasy, niewygasłe uprawnienia i strumienie. Brama zachowuje również nawiązane strumienie przy zmianach dotyczących wyłącznie próby aktywacji w obrębie tej samej trasy i generacji wykonania. Nowe otwarcia wymagają zaktualizowanej tożsamości.

Odzyskiwanie nie narusza tych kontroli. Komparator tożsamości może zwrócić RefreshRoute w przypadku niezgodności inkarnacji w obrębie tej samej piaskownicy lub Deny w przypadku innej piaskownicy. Po odrzuceniu tożsamości naprawę trasy uruchamia wyłącznie rozpoznany sygnał odświeżenia. Awarie transportu podlegają odrębnym regułom odzyskiwania, właściwym dla danej operacji. Nieprawidłowe podpisy, cele lub profile portów są nadal odrzucane.

Kwalifikująca się operacja może ustalić bieżące wykonanie i podjąć jedną ponowną próbę z odbudowanym żądaniem. Zastąpienie wpisu w pamięci podręcznej zależy od odrzuconej trasy, co zapobiega usunięciu nowszego wpisu przez opóźnione odrzucenie. Odświeżenie sesji natywnej zachowuje pierwotny termin wygaśnięcia wpisu w pamięci podręcznej, oddzielając naprawę trasy od odnowienia autoryzacji wywołującego.

Reguły ponownego odtwarzania (replay) pozostają zależne od rodzaju operacji. Zastępczy backend musi ponownie przejść dopuszczenie, nawet gdy WebSocket po stronie klienta pozostaje otwarty.

Powiększ

Kompromisy i granice zaufania

Tożsamość wykonania staje się stanem krytycznym dla bezpieczeństwa. Aktualizacje płaszczyzny sterowania i pakiety kluczy weryfikacyjnych muszą docierać do komponentów obsługujących żądania, a wycofanie zaczyna obowiązywać, gdy dany odbiorca zainstaluje aktualizację. Krótki czas życia uprawnień ogranicza możliwość ich ponownego użycia w trakcie propagacji.

Projekt zakłada, że egzekwowanie tożsamości jest włączone, i ufa podmiotowi podpisującemu płaszczyzny sterowania, jądru węzła roboczego oraz lokalnym usługom zarządzania na węźle. Przejęcie uprawnień roota na węźle roboczym lub konta uprzywilejowanego administratora klastra wykracza poza model zagrożeń. Weryfikacja mostka to lokalna weryfikacja procesów i transportu, a nie sprzętowa zdalna atestacja.

Weryfikacja podpisów, porównania ze stanem środowiska uruchomieniowego i walidacja mostka zwiększają ilość pracy na ścieżce żądania. Korzystają one jednak ze stanu lokalnego, a nie ze zdalnego sprawdzania autoryzacji na każdym prywatnym przeskoku.

Porównanie branżowe

Istotne porównanie dotyczy tego, jak platformy radzą sobie z autoryzowanym żądaniem, które trafia do niewłaściwego wykonania właściwej piaskownicy. Te ustalenia dotyczą zbadanych implementacji, a nie ogólnego bezpieczeństwa platform. SPACE, OpenShell i E2B sprawdzono 8 października 2026 r.:

• OpenShell: Zapewnia porównywalny wybór wykonania dla nowych wywołań oraz powiązanie nadzorcy ze środowiskiem uruchomieniowym dzięki kontrolom generacji i autoryzacji w bramie, weryfikacji tożsamości backendu oraz potwierdzaniu aktywnych połączeń nadzorcy (dopuszczanie przez bramę, uwierzytelnianie i powiązanie środowiska uruchomieniowego). SPACE przenosi podpisany wybór przez całą ścieżkę obsługi żądania i dodaje lokalną weryfikację procesów i transportu na węźle roboczym; OpenShell rozkłada odpowiadające im kontrole między bramę, tożsamość uruchomienia i uwierzytelniony protokół środowiska uruchomieniowego (projekt środowiska uruchomieniowego).
• E2B: Śledzi identyfikatory wykonań i izoluje pule proxy według cyklu życia Firecrackera, ale jego proxy ruchu przychodzącego wybiera logiczną piaskownicę i port bez oczekiwanej tożsamości wykonania, z którą odbiorca mógłby je porównać (publikowanie tras, dopuszczanie przez proxy). Na podstawie tych kontroli nie da się odróżnić starszego wykonania, które nadal jest zarejestrowane jako aktywne na nieaktualnym odbiorcy z pasującymi poświadczeniami, od wybranego nowszego wykonania, choć standardowe wyłączanie usuwa trasy i zamyka połączenia powiązane z cyklem życia (poświadczenia, wyłączanie).
• CubeSandbox: Naprawia routing po wznowieniu i unieważnia pamięci podręczne, ale prywatny ruch przychodzący korzysta z poświadczeń ograniczonych do zakresu piaskownicy i jest przekazywany dalej bez oczekiwanej inkarnacji środowiska uruchomieniowego (routing przy wznowieniu, routing ruchu przychodzącego). Naprawa tras skraca okna, w których obowiązują nieaktualne trasy; powiązane z wykonaniem uprawnienie SPACE daje ponadto odbiorcy niezależną podstawę do odrzucenia niewłaściwej inkarnacji.

Tożsamość jako granica izolacji

Bezpieczne delegowanie zależy od utrzymania pracy każdego agenta w przeznaczonych dla niego granicach. MicroVM zapewnia izolację, a otaczająca ją platforma musi dopilnować, by każde żądanie i każde trwające połączenie trafiało do wykonania uprawnionego do jego obsługi.

SPACE czyni tożsamość wykonania częścią tej ochrony. Sprawdzając miejsca docelowe, weryfikując punkty końcowe mostka i wiążąc połączenia z wykonaniem, które je autoryzowało, zachowuje te granice, gdy piaskownice są wstrzymywane, wznawiane i przenoszone.

Kontynuujemy tę pracę w miarę rozwoju infrastruktury. W przypadku SPACE i innych platform piaskownic bezpieczeństwo wymaga testowania tych ścieżek zarówno pod kątem rutynowych błędów routingu, jak i wrogich obciążeń, a następnie wzmacniania granic wszędzie tam, gdzie testy ujawnią luki.