Jak SPACE směruje požadavky na správný běh sandboxu

Když někdo požádá agenta AI, aby analyzoval tabulku nebo otestoval software, svěřuje mu bezpečnou práci se svými soubory a daty. Agenti potřebují izolovaná prostředí, v nichž mohou tuto práci provádět, aniž by odhalili data jiných uživatelů nebo narušovali jejich úlohy.

Jak agenti přebírají složitější úkoly s větší autonomií, pomáhají tato prostředí zachytit chyby a omezit škody, které může způsobit nebezpečný nebo škodlivý kód. Sandboxy zajišťují tuto izolaci a zároveň sdílejí služby řídicí roviny, pracovní uzly a infrastrukturu pro směrování.

Tato sdílená infrastruktura musí každou operaci doručit tomu běhu, který je oprávněn ji zpracovat. Zastaralá trasa může poslat platný požadavek do jiného sandboxu nebo do staršího běhu správného sandboxu. SPACE, zabezpečená sandboxová platforma společnosti Perplexity, váže každou operaci na vybraný běh a před přeposláním ověřuje cíl.

SPACE už několik měsíců zpracovává miliony spuštění denně, z nichž každé chrání jedinečná kryptografická identita, s chybovostí pod 0,0002 % a bez jediného přerušeného připojení.

Problém se směrováním

Zabezpečení sandboxu závisí také na tom, aby se každý požadavek dostal ke správnému cíli. I prosté čtení souboru prochází sdílenou infrastrukturou, která musí sledovat, kde sandbox právě běží, zatímco se pozastavuje, obnovuje nebo přesouvá mezi počítači.

Čtení souboru prochází několika komponentami. Řídicí rovina SPACE přiřadí sandbox k běhu a pracovnímu uzlu. Požadavek vstupuje přes node-api, pokračuje ke správci sandboxu sbx-manager a přes unixový soket přechází k hostitelskému mostu spaced-host. Most jej přepošle přes VSOCK, soketový transport mezi hostitelem a hostem, do spaced-guest uvnitř microVM Firecracker.

Každé rozhodnutí se opírá o stav, který může zaostávat za změnami infrastruktury. Databáze může uchovávat staré umístění, adresa v mezipaměti může ukazovat jinam a cesta k soketu může získat jiného posluchače. Úspěšné připojení se tak stále může dostat do nesprávného cíle. Čtení by mohlo odhalit data jiného uživatele, zápis by mohl změnit nesprávný souborový systém.

Snímky přinášejí další problém. Obnovení sandboxu na jiném pracovním uzlu zachová jeho logickou identitu, ale spustí nový běh. Opožděný požadavek nebo přetrvávající připojení se může dostat k jeho předchůdci a vrátit starý stav pod názvem správného sandboxu.

Zvětšit

Identita sandboxu a identita spuštění

SPACE odděluje prostředí uživatele od běhového prostředí, které ho obsluhuje:

• Identita sandboxu: Stabilní ID logického prostředí. Autorizace volajícího určuje přístup k tomuto sandboxu.
• Identita trasy/spuštění: Vybraná inkarnace běhového prostředí a její umístění, včetně jejího workeru, substrátu a aktivace.

Generace běhu rozlišuje jednotlivé inkarnace běhového prostředí. V Kubernetes trasa obsahuje také UID podu. Adresy určují polohu koncových bodů; identita běhu určuje, zda tyto koncové body smějí operaci obsloužit.

Představte si, že sandbox S běží jako běh 7 na pracovním uzlu A a poté se obnoví jako běh 8 na pracovním uzlu B. Požadavek vybraný pro běh 8 musí selhat, pokud dorazí do běhu 7. Kontrola samotného ID sandboxu by tento nesoulad nezachytila.

Zvětšit

Podepsaný výběr spuštění

Každý požadavek nese podepsaný doklad o tom, který běh sandboxu jej smí zpracovat a jaký přístup je povolen. Přijímající komponenta tento doklad porovná se svou vlastní identitou běhového prostředí a teprve poté požadavek pustí dál.

Po autorizaci volajícího vydá SPACE krátkodobé podepsané oprávnění, které identifikuje sandbox, běh, umístění a povolený přístup. Oprávnění pro veřejné servisní porty navíc určují povolený port a protokol.

Přijímající správce sandboxu ověří podpis a porovná úplnou identitu se svým místně uloženým záznamem o běhovém prostředí. Podpis určuje, kdo výběr autorizoval. Porovnání určuje, zda tento výběr odpovídá příjemci.

Provoz ServicePort prochází druhou kontrolou na síťové bráně jednotlivých sandboxů, netgtw, ještě před otevřením připojení k hostovi. Brána porovná identitu s důvěryhodným stavem aktivace a zkontroluje port a protokol. Řídicí operace pokračují k ověření koncových bodů mostu.

SPACE používá podpisy Ed25519. Oprávnění vydávají podpisové klíče řídicí roviny; veřejné ověřovací klíče na pracovních uzlech a branách je vydávat nemohou.

Oprávnění platí 120 sekund, přičemž při vyhodnocování vypršení se toleruje odchylka hodin až 15 sekund. Platný podpis a nevypršený token stále nestačí, pokud se vybraná a nainstalovaná identita neshodují.

Zvětšit

Odmítnutí v nesprávném cíli

Přijímající pracovní uzel dokáže zachytit chybu ve směrování, i když je samotný požadavek autorizovaný. Zkontroluje, zda provozuje běh vybraný pro daný požadavek, a pokud se liší, požadavek odmítne.

Pokud požadavek vybraný pro spuštění 8 dorazí na worker A, který stále obsluhuje spuštění 7, worker A ho odmítne ještě před přeposláním. Jakmile příjemce nainstaluje identitu spuštění 8, odmítá také oprávnění (capabilities) pro spuštění 7, a to i před vypršením jejich platnosti.

Tato záruka má jednu důležitou hranici. Oprávnění pro běh 7 může stále odpovídat pracovnímu uzlu, který obsluhuje běh 7, dokud se tento uzel nedozví o vyřazení nebo dokud oprávnění nevyprší. Místní vynucování a omezená životnost oprávnění se během šíření aktualizací vzájemně doplňují.

Zvětšit

Ověření koncových bodů mostu

Odpovídající záznam o běhovém prostředí určuje zamýšlený běh. Řídicí most se navíc musí dostat k procesům a transportu, které patří k dané aktivaci, a ne k náhradě, která zdědila stejnou adresu.

Správci sandboxu a uzlů ověřují přihlašovací údaje protějšku hostitelského mostu a identity procesů mostu i Firecrackeru včetně časů spuštění, čímž odhalují znovu použitá ID nebo změněné spustitelné soubory

Kontroly transportu svazují posluchače VSOCK s očekávaným procesem Firecracker pomocí vlastnictví soketu, identity hosta a důkazů o soketu z jádra. Most přeposílá operace až po ověření a odmítá transparentní opětovná připojení. Každé nové připojení musí kontrolami projít znovu.

Toto ověření pokrývá řídicí most Firecrackeru v Kubernetes i na přímo spravovaných hostitelích. Provoz ServicePort využívá na své bráně kontroly běhu a portu; neatestuje identitu libovolné aplikace uvnitř hosta.

Zvětšit

Životnost streamů a obnova tras

Některá připojení zůstávají otevřená i ve chvíli, kdy se běh sandboxu mění, takže kontroly identity musejí sahat i za úvodní požadavek. SPACE vyřazuje připojení vázaná na starý běh a umožňuje způsobilým operacím znovu se připojit k aktuálnímu běhu při stejných bezpečnostních kontrolách.

Terminály a sledování souborů mohou přetrvat déle než požadavky, které je otevřely. SPACE váže backendové streamy na epochu identity, takže stream nemůže zůstat připojený k předchůdci poté, co příjemce nainstaluje náhradní běh.

SPACE před otevřením streamu znovu ověří trvalou identitu. Nahrazení jeho trasy nebo běhu zruší pronájem streamu a zastaví vstup i výstup.

Změny vlastnictví jsou něco jiného než nahrazení běhu. Předání operace životního cyklu u nezměněného rezidentního prostředku Kubernetes zachovává jeho identitu trasy, nevypršená oprávnění i streamy. Brána také zachovává navázané streamy při změnách, které se týkají pouze pokusu o aktivaci v rámci stejné trasy a generace běhu. Nová otevření vyžadují aktualizovanou identitu.

Obnova tyto kontroly zachovává. Komparátor identit může vrátit RefreshRoute při neshodě inkarnace v rámci stejného sandboxu, nebo Deny v případě jiného sandboxu. Po odmítnutí identity spustí opravu trasy pouze rozpoznaný signál k obnovení. Selhání transportu se řídí samostatnými pravidly obnovy specifickými pro danou operaci. Neplatné podpisy, účely nebo profily portů zůstávají zamítnuty.

Způsobilá operace může zjistit aktuální běh a provést jeden nově sestavený pokus. Nahrazení v mezipaměti je podmíněno odmítnutou trasou, takže opožděné odmítnutí nemůže vytlačit novější záznam. Obnovení nativní relace zachovává původní dobu platnosti v mezipaměti, čímž odděluje opravu trasy od obnovení autorizace volajícího.

Pravidla pro opakování zůstávají specifická pro jednotlivé operace. Náhradní backend musí znovu projít přijetím, i když WebSocket na straně klienta zůstává otevřený.

Zvětšit

Kompromisy a hranice důvěry

Identita běhu se stává stavem kritickým pro zabezpečení. Aktualizace řídicí roviny a sady ověřovacích klíčů se musejí dostat k obslužným komponentám a vyřazení začne platit, jakmile aktualizaci nainstaluje každý příjemce. Krátká životnost oprávnění omezuje jejich opakované použití během šíření.

Návrh předpokládá, že je vynucování identity zapnuté, a důvěřuje podepisovateli řídicí roviny, jádru pracovního uzlu a místním službám pro správu uzlu. Kompromitace pracovního uzlu na úrovni roota nebo privilegovaného správce clusteru je mimo model hrozeb. Ověření mostu představuje místní ověření procesů a transportu, nikoli vzdálenou atestaci podloženou hardwarem.

Ověřování podpisů, porovnávání se záznamy o běhovém prostředí a validace mostu přidávají cestě požadavku práci. Využívají však místní stav namísto vzdáleného vyhledávání autorizace na každém privátním přeskoku.

Srovnání v rámci odvětví

Podstatné je srovnat, jak platformy řeší situaci, kdy autorizovaný požadavek dorazí do nesprávného běhu správného sandboxu. Tato zjištění se týkají zkoumaných implementací, nikoli celkového zabezpečení platforem. SPACE, OpenShell a E2B byly prověřeny 8. října 2026:

• OpenShell: Poskytuje srovnatelný výběr běhu pro nová volání a vazbu supervizoru na běhové prostředí prostřednictvím kontrol generace a autorizace v bráně, ověřování identity backendu a potvrzených aktivních připojení supervizoru (přijetí bránou, autentizace a vazba běhového prostředí). SPACE přenáší podepsaný výběr celou svou obslužnou cestou a přidává ověření procesů a transportu přímo na pracovním uzlu; OpenShell rozkládá odpovídající kontroly mezi svou bránu, identitu spuštění a autentizovaný protokol běhového prostředí (návrh běhového prostředí).
• E2B: Sleduje ID běhů a izoluje fondy proxy podle životního cyklu Firecrackeru, ale jeho příchozí proxy vybírá logický sandbox a port bez očekávané identity běhu, kterou by mohl příjemce porovnat (publikace tras, přijetí proxy). Starší běh, který je na zastaralém příjemci se shodnými přihlašovacími údaji stále registrován jako živý, nelze těmito kontrolami odlišit od vybraného novějšího běhu, ačkoli běžné ukončení odstraňuje trasy a uzavírá připojení vázaná na životní cyklus (přihlašovací údaje, ukončení).
• CubeSandbox: Při obnovení opravuje směrování a zneplatňuje mezipaměti, ale privátní ingress používá přihlašovací údaje vázané na sandbox a přeposílá bez očekávané inkarnace běhového prostředí (směrování při obnovení, směrování ingressu). Oprava tras zkracuje okna, během nichž platí zastaralé trasy; oprávnění vázané na běh v SPACE navíc dává příjemci nezávislý základ pro odmítnutí nesprávné inkarnace.

Identita jako hranice izolace

Bezpečné delegování závisí na tom, aby práce každého agenta zůstala v hranicích, které jsou pro ni určeny. MicroVM zajišťuje izolaci, zatímco okolní platforma musí zajistit, aby se každý požadavek i probíhající připojení dostaly k běhu, který je oprávněn je zpracovat.

SPACE činí identitu běhu součástí této ochrany. Kontrolou cílů, ověřováním koncových bodů mostu a vázáním připojení na běh, který je autorizoval, zachovává tyto hranice i ve chvílích, kdy se sandboxy pozastavují, obnovují a přesouvají.

V práci pokračujeme s tím, jak se infrastruktura vyvíjí. U SPACE i dalších sandboxových platforem vyžaduje zabezpečení testovat tyto cesty jak vůči běžným chybám ve směrování, tak vůči nepřátelským úlohám, a následně posilovat hranice všude, kde tyto testy odhalí mezery.