Så dirigerar SPACE förfrågningar till rätt sandlådekörning

När användare ber en AI-agent att analysera ett kalkylark eller testa programvara litar de på att den arbetar säkert med deras filer och data. Agenter behöver isolerade miljöer där de kan utföra arbetet utan att exponera andra användares data eller störa deras arbetsbelastningar.

När agenter tar sig an mer komplexa uppgifter med större självständighet hjälper de här miljöerna till att begränsa misstag och den skada som osäker eller skadlig kod kan orsaka. Sandlådor ger den isoleringen samtidigt som de delar kontrollplanstjänster, arbetsnoder och routningsinfrastruktur.

Den delade infrastrukturen måste leverera varje operation till den körning som är auktoriserad att hantera den. En inaktuell rutt kan skicka en giltig förfrågan till en annan sandlåda, eller till en äldre körning av rätt sandlåda. SPACE, Perplexitys säkra sandlådeplattform, binder varje operation till en vald körning och kontrollerar destinationen före vidarebefordran.

I flera månader har SPACE hanterat miljontals körningar per dag, var och en skyddad av en unik kryptografisk identitet, med en felfrekvens under 0,0002 % och noll tappade anslutningar.

Routningsproblemet

Sandlådesäkerhet förutsätter också att varje förfrågan når rätt destination. Även en enkel filläsning passerar genom delad infrastruktur som måste hålla reda på var sandlådan körs när den pausas, återupptas eller flyttas mellan maskiner.

En filläsning passerar flera komponenter. SPACE:s kontrollplan mappar sandlådan till en körning och en arbetsnod. Förfrågan kommer in via node-api, skickas vidare till sandlådehanteraren, sbx-manager, och passerar en Unix-socket till värdbryggan, spaced-host. Bryggan vidarebefordrar den över VSOCK, socket-transporten mellan värd och gäst, till spaced-guest inuti Firecracker-microVM:en.

Varje beslut bygger på tillstånd som kan släpa efter förändringar i infrastrukturen. En databas kan behålla en gammal placering, en cachad adress kan peka någon annanstans eller en socketsökväg kan få en annan lyssnare. En lyckad anslutning kan ändå nå fel destination. En läsning kan exponera en annan användares data; en skrivning kan ändra fel filsystem.

Ögonblicksbilder ger upphov till ytterligare ett problem. När en sandlåda återupptas på en annan arbetsnod bevaras dess logiska identitet, men en ny körning startas. En fördröjd förfrågan eller en kvarvarande anslutning kan nå dess föregångare och returnera gammalt tillstånd under rätt sandlådenamn.

Förstora

Sandlådeidentitet och körningsidentitet

SPACE skiljer användarens miljö från den körmiljö som betjänar den:

• Sandlådeidentitet: Det stabila ID:t för den logiska miljön. Anroparens auktorisering fastställer åtkomsten till sandlådan.
• Routnings-/körningsidentitet: Den valda runtime-inkarnationen och dess placering, inklusive dess worker, substrat och aktivering.

En körningsgeneration skiljer mellan körtidsinkarnationer. På Kubernetes innehåller rutten även poddens UID. Adresser lokaliserar slutpunkter; körningsidentiteten avgör om slutpunkterna får betjäna operationen.

Anta att sandlåda S körs som körning 7 på arbetsnod A och sedan återupptas som körning 8 på arbetsnod B. En förfrågan som valts för körning 8 måste misslyckas om den når körning 7. En kontroll av enbart sandlådans ID skulle inte upptäcka avvikelsen.

Förstora

Signerat val av körning

Varje förfrågan bär ett signerat bevis på vilken sandlådekörning som får hantera den och vilken åtkomst som är tillåten. Den mottagande komponenten kontrollerar beviset mot sin egen körtidsidentitet innan förfrågan får fortsätta.

Efter anroparens auktorisering utfärdar SPACE en kortlivad, signerad kapabilitet som identifierar sandlådan, körningen, placeringen och den tillåtna åtkomsten. Kapabiliteter för publika tjänsteportar anger även tillåten port och tillåtet protokoll.

Den mottagande sandlådehanteraren verifierar signaturen och jämför hela identiteten med sin lokalt lagrade körtidspost. Signaturen fastställer vem som auktoriserade valet. Jämförelsen fastställer om valet stämmer med mottagaren.

ServicePort-trafik genomgår en andra kontroll vid sandlådans egen nätverksgateway, netgtw, innan en anslutning till gästen öppnas. Gatewayen jämför identiteten med betrott aktiveringstillstånd och kontrollerar port och protokoll. Kontrolloperationer går vidare till verifieringen av bryggans slutpunkter.

SPACE använder Ed25519-signaturer. Kontrollplanets signeringsnycklar utfärdar kapabiliteter; de publika verifieringsnycklarna på arbetsnoder och gatewayer kan inte utfärda dem.

Kapabiliteter gäller i 120 sekunder, med upp till 15 sekunders tolerans för klockavvikelse vid utgången. En giltig signatur och en token som inte har löpt ut räcker ändå inte när den valda och den installerade identiteten inte stämmer överens.

Förstora

Avvisning vid fel destination

Den mottagande arbetsnoden kan upptäcka ett routningsfel även när själva förfrågan är auktoriserad. Den kontrollerar om den kör den körning som valts för förfrågan och avvisar förfrågan om de skiljer sig åt.

Om en begäran som valts för körning 8 når worker A, som fortfarande betjänar körning 7, avvisar worker A den innan den vidarebefordras. När en mottagare har installerat identiteten för körning 8 avvisar den också behörigheter (capabilities) för körning 7, även innan de har gått ut.

Den här garantin har en viktig begränsning. En kapabilitet för körning 7 kan fortfarande matcha en arbetsnod som betjänar körning 7 tills arbetsnoden får veta att körningen har avvecklats eller kapabiliteten löper ut. Lokal tillämpning och en begränsad livslängd för kapabiliteter samverkar medan uppdateringarna sprids.

Förstora

Verifiering av bryggans slutpunkter

En matchande körtidspost fastställer den avsedda körningen. Kontrollbryggan måste också nå de processer och den transport som hör till den aktiveringen, i stället för en ersättare som har ärvt samma adress.

Sandlåde- och nodhanterarna verifierar värdbryggans peer-autentiseringsuppgifter och processidentiteten för både bryggan och Firecracker, inklusive starttider, och upptäcker på så sätt återanvända ID:n eller ändrade körbara filer

Transportkontrollerna knyter VSOCK-lyssnaren till den förväntade Firecracker-processen med hjälp av socketägarskap, gästidentitet och socketbevis från kärnan. Bryggan vidarebefordrar operationer först efter verifiering och vägrar transparenta återanslutningar. Varje ny anslutning måste passera kontrollerna igen.

Den här verifieringen omfattar Firecrackers kontrollbrygga på Kubernetes och på direkt hanterade värdar. ServicePort-trafik använder kontroller av körning och port vid sin gateway; den intygar inte identiteten hos en godtycklig applikation inuti gästen.

Förstora

Strömmars livslängd och återställning av rutter

Vissa anslutningar förblir öppna medan en sandlådas körning ändras, så identitetskontrollerna måste sträcka sig längre än den första förfrågan. SPACE avvecklar anslutningar som är knutna till den gamla körningen och låter kvalificerade operationer återansluta till den aktuella under samma säkerhetskontroller.

Terminaler och filbevakningar kan leva kvar längre än de förfrågningar som öppnade dem. SPACE knyter backend-strömmar till en identitetsepok så att en ström inte kan förbli ansluten till sin föregångare efter att mottagaren har installerat en ersättande körning.

SPACE kontrollerar den beständiga identiteten på nytt innan en ström öppnas. Om dess rutt eller körning ersätts avbryts strömmens lease, vilket stoppar in- och utdata.

Ägarbyten skiljer sig från att en körning ersätts. En överlämning av livscykeloperationer på en oförändrad Kubernetes-resident bevarar dess ruttidentitet, kapabiliteter som inte har löpt ut och strömmar. Gatewayen bevarar också etablerade strömmar vid ändringar som endast gäller aktiveringsförsöket inom samma rutt och körningsgeneration. Nya öppningar kräver den uppdaterade identiteten.

Återställningen bevarar dessa kontroller. Identitetsjämföraren kan returnera RefreshRoute vid en inkarnationsavvikelse inom samma sandlåda, eller Deny för en annan sandlåda. Endast en igenkänd uppdateringssignal utlöser reparation av routningen efter ett identitetsavslag. Transportfel följer separata, operationsspecifika återställningsregler. Ogiltiga signaturer, syften eller portprofiler nekas fortfarande.

En kvalificerad operation kan slå upp den aktuella körningen och göra ett nytt försök med en återuppbyggd förfrågan. Cacheersättningen villkoras av den avvisade rutten, vilket förhindrar att en fördröjd avvisning tränger undan en nyare post. Förnyelse av den inbyggda sessionen bevarar cachens ursprungliga utgångstid, vilket skiljer ruttreparation från förnyelse av anroparens auktorisering.

Reglerna för återuppspelning är fortfarande specifika för varje operation. En ersättande backend måste passera åtkomstkontrollen igen, även när klientens WebSocket-anslutning förblir öppen.

Förstora

Avvägningar och förtroendegränser

Körningsidentiteten blir säkerhetskritiskt tillstånd. Uppdateringar från kontrollplanet och paket med verifieringsnycklar måste nå de betjänande komponenterna, och avvecklingen träder i kraft när varje mottagare installerar uppdateringen. Korta livslängder för kapabiliteter begränsar återanvändning medan uppdateringarna sprids.

Designen förutsätter att identitetskontrollen är aktiverad och litar på kontrollplanets signerare, arbetsnodens kärna och nodlokala hanteringstjänster. Intrång med root-behörighet på arbetsnoden eller med privilegierad klusteradministratörsbehörighet ligger utanför hotmodellen. Bryggverifieringen är lokal verifiering av process och transport, inte hårdvarubaserad fjärrattestering.

Signaturverifiering, körtidsjämförelser och bryggvalidering tillför arbete i förfrågningsvägen. De använder lokalt tillstånd i stället för en fjärrsökning efter auktorisering vid varje privat hopp.

Branschjämförelse

Den relevanta jämförelsen är hur plattformar hanterar en auktoriserad förfrågan som når fel körning av rätt sandlåda. Dessa resultat gäller de granskade implementationerna, inte plattformarnas säkerhet i stort. SPACE, OpenShell och E2B granskades den 8 oktober 2026:

• OpenShell: Erbjuder jämförbart val av körning för nya anrop och bindning mellan supervisor och körmiljö genom gatewayens generations- och auktoriseringskontroller, validering av backend-identitet och bekräftade aktiva supervisor-anslutningar (gateway-åtkomstkontroll, autentisering och bindning av körmiljö). SPACE för det signerade valet vidare genom hela sin anropsväg och lägger till lokal verifiering av process och transport på arbetsnoden; OpenShell fördelar motsvarande kontroller över sin gateway, sin startidentitet och sitt autentiserade körtidsprotokoll (körtidsdesign).
• E2B: Spårar körnings-ID:n och isolerar proxypooler per Firecracker-livscykel, men dess inkommande proxy väljer den logiska sandlådan och porten utan någon förväntad körningsidentitet som mottagaren kan jämföra med (ruttpublicering, proxyåtkomstkontroll). En äldre körning som fortfarande är registrerad som aktiv på en inaktuell mottagare med matchande autentiseringsuppgifter kan inte särskiljas från den valda nyare körningen genom dessa kontroller, även om normal nedmontering tar bort rutter och stänger livscykelbundna anslutningar (autentiseringsuppgifter, nedmontering).
• CubeSandbox: Reparerar routningen vid återupptagning och ogiltigförklarar cacheminnen, men privat ingress använder autentiseringsuppgifter som är begränsade till sandlådan och vidarebefordrar utan någon förväntad körtidsinkarnation (routning vid återupptagning, ingressroutning). Ruttreparation minskar tidsfönstren med inaktuella rutter; SPACE:s körningsbundna kapabilitet ger dessutom mottagaren en oberoende grund för att avvisa fel inkarnation.

Identitet som isoleringsgräns

Säker delegering förutsätter att varje agents arbete hålls inom de gränser som är avsedda för det. En microVM ger isolering, medan den omgivande plattformen måste säkerställa att varje förfrågan och pågående anslutning når den körning som är auktoriserad att hantera den.

SPACE gör körningsidentiteten till en del av det skyddet. Genom att kontrollera destinationer, verifiera bryggans slutpunkter och knyta anslutningar till den körning som auktoriserade dem bevarar SPACE dessa gränser när sandlådor pausas, återupptas och flyttas.

Vi fortsätter arbetet i takt med att infrastrukturen utvecklas. För SPACE och andra sandlådeplattformar kräver säkerhet att dessa vägar testas mot både vardagliga routningsfel och fientliga arbetsbelastningar, och att gränserna sedan förstärks där testerna avslöjar luckor.