Hoe SPACE verzoeken naar de juiste sandboxuitvoering routeert

Wanneer iemand een AI-agent vraagt een spreadsheet te analyseren of software te testen, vertrouwt die persoon erop dat de agent veilig met diens bestanden en gegevens omgaat. Agents hebben geïsoleerde omgevingen nodig waarin ze dat werk kunnen uitvoeren zonder de gegevens van andere gebruikers bloot te stellen of hun workloads te verstoren.

Naarmate agents complexere taken met meer autonomie op zich nemen, helpen deze omgevingen fouten in te dammen en de schade te beperken die onveilige of kwaadaardige code kan aanrichten. Sandboxes bieden die isolatie terwijl ze control-planeservices, workernodes en routeringsinfrastructuur delen.

Die gedeelde infrastructuur moet elke bewerking afleveren bij de uitvoering die gemachtigd is om die af te handelen. Een verouderde route kan een geldig verzoek naar een andere sandbox sturen, of naar een oudere uitvoering van de juiste sandbox. SPACE, het beveiligde sandboxplatform van Perplexity, bindt elke bewerking aan een geselecteerde uitvoering en controleert de bestemming voordat er wordt doorgestuurd.

SPACE verwerkt al maanden miljoenen uitvoeringen per dag, elk beschermd door een unieke cryptografische identiteit, met een foutpercentage van minder dan 0,0002% en geen enkele verbroken verbinding.

Het routeringsprobleem

Sandboxbeveiliging hangt er ook van af dat elk verzoek op de juiste bestemming aankomt. Zelfs het simpelweg lezen van een bestand verloopt via gedeelde infrastructuur die moet bijhouden waar de sandbox draait terwijl die wordt gepauzeerd, hervat of naar een andere machine wordt verplaatst.

Het lezen van een bestand verloopt via verschillende onderdelen. Het control plane van SPACE bepaalt bij welke uitvoering en worker de sandbox hoort. Het verzoek komt binnen via node-api, gaat naar de sandboxmanager, sbx-manager, en passeert een Unix-socket naar de hostbridge, spaced-host. De bridge stuurt het via VSOCK, het sockettransport tussen host en gast, door naar spaced-guest in de Firecracker-microVM.

Elke beslissing berust op status die achter kan lopen op wijzigingen in de infrastructuur. Een database kan een oude plaatsing bewaren, een gecachet adres kan ergens anders naar verwijzen, of er kan een andere listener op een socketpad komen te zitten. Een geslaagde verbinding kan nog steeds de verkeerde bestemming bereiken. Een leesbewerking kan gegevens van een andere gebruiker blootleggen; een schrijfbewerking kan het verkeerde bestandssysteem wijzigen.

Snapshots brengen nog een probleem met zich mee. Wanneer een sandbox op een andere worker wordt hervat, blijft de logische identiteit behouden, maar start er een nieuwe uitvoering. Een vertraagd verzoek of een overgebleven verbinding kan de voorganger bereiken en oude status teruggeven onder de juiste sandboxnaam.

Vergroten

Sandboxidentiteit en uitvoeringsidentiteit

SPACE scheidt de omgeving van de gebruiker van de runtime die deze bedient:

• Sandboxidentiteit: De stabiele ID van de logische omgeving. Autorisatie van de aanroeper stelt de toegang tot deze sandbox vast.
• Route-/uitvoeringsidentiteit: De geselecteerde runtime-incarnatie en de plaatsing ervan, inclusief de worker, het substraat en de activering.

Een uitvoeringsgeneratie onderscheidt runtime-incarnaties. Op Kubernetes bevat de route ook de pod-UID. Adressen lokaliseren eindpunten; de uitvoeringsidentiteit bepaalt of die eindpunten de bewerking mogen bedienen.

Stel dat sandbox S als uitvoering 7 op worker A draait en vervolgens als uitvoering 8 op worker B wordt hervat. Een verzoek dat voor uitvoering 8 is geselecteerd, moet mislukken als het bij uitvoering 7 terechtkomt. Wie alleen de sandbox-ID controleert, mist die discrepantie.

Vergroten

Ondertekende uitvoeringsselectie

Elk verzoek bevat ondertekend bewijs van welke sandboxuitvoering het mag afhandelen en welke toegang is toegestaan. Het ontvangende onderdeel toetst dat bewijs aan zijn eigen runtime-identiteit voordat het verzoek verder mag.

Na autorisatie van de aanroeper geeft SPACE een kortlevende, ondertekende capability uit die de sandbox, uitvoering, plaatsing en toegestane toegang identificeert. Capabilities voor openbare serviceports specificeren daarnaast de toegestane poort en het toegestane protocol.

De ontvangende sandboxmanager verifieert de handtekening en vergelijkt de volledige identiteit met zijn lokaal opgeslagen runtimerecord. De handtekening stelt vast wie de selectie heeft geautoriseerd. De vergelijking stelt vast of die selectie overeenkomt met de ontvanger.

ServicePort-verkeer krijgt een tweede controle bij de netwerkgateway per sandbox, netgtw, voordat er een verbinding met de gast wordt geopend. De gateway vergelijkt de identiteit met vertrouwde activeringsstatus en controleert de poort en het protocol. Controlebewerkingen gaan door naar de verificatie van bridge-eindpunten.

SPACE gebruikt Ed25519-handtekeningen. Ondertekeningssleutels van het control plane geven capabilities uit; openbare verificatiesleutels op workers en gateways kunnen dat niet.

Capabilities zijn 120 seconden geldig, met een marge van maximaal 15 seconden voor klokafwijking bij het verlopen. Een geldige handtekening en een niet-verlopen token volstaan nog steeds niet wanneer de geselecteerde en de geïnstalleerde identiteit niet overeenkomen.

Vergroten

Weigering bij de verkeerde bestemming

De ontvangende worker kan een routeringsfout opvangen, zelfs wanneer het verzoek zelf geautoriseerd is. Hij controleert of hij de uitvoering draait die voor dat verzoek is geselecteerd, en weigert het verzoek als dat niet zo is.

Als een verzoek dat voor uitvoering 8 is geselecteerd bij worker A aankomt, die nog uitvoering 7 bedient, weigert worker A het verzoek voordat het wordt doorgestuurd. Zodra een ontvanger de identiteit van uitvoering 8 heeft geïnstalleerd, weigert die ook capabilities voor uitvoering 7, zelfs voordat ze verlopen.

Deze garantie kent een belangrijke grens. Een capability voor uitvoering 7 kan nog steeds overeenkomen met een worker die uitvoering 7 bedient, totdat die worker hoort dat de uitvoering buiten gebruik is gesteld of de capability verloopt. Lokale handhaving en een begrensde levensduur van capabilities werken samen terwijl updates zich verspreiden.

Vergroten

Verificatie van bridge-eindpunten

Een overeenkomend runtimerecord legt de bedoelde uitvoering vast. De control-bridge moet bovendien de processen en het transport bereiken die bij die activering horen, en niet een vervanger die hetzelfde adres heeft geërfd.

De sandbox- en nodemanagers verifiëren de peer-inloggegevens van de hostbridge en de procesidentiteit van zowel de bridge als Firecracker, inclusief starttijden, zodat hergebruikte ID's of gewijzigde uitvoerbare bestanden worden gedetecteerd

Transportcontroles koppelen de VSOCK-listener aan het verwachte Firecracker-proces aan de hand van socketeigendom, gastidentiteit en bewijs uit de kernelsocket. De bridge stuurt bewerkingen pas na verificatie door en weigert transparante herverbindingen. Elke nieuwe verbinding moet de controles opnieuw doorstaan.

Deze verificatie geldt voor de Firecracker-control-bridge op Kubernetes en op direct beheerde hosts. ServicePort-verkeer wordt bij de gateway gecontroleerd op uitvoering en poort; daarbij wordt de identiteit van een willekeurige applicatie in de gast niet geattesteerd.

Vergroten

Levensduur van streams en routeherstel

Sommige verbindingen blijven open terwijl de uitvoering van een sandbox verandert, dus identiteitscontroles moeten verder reiken dan het eerste verzoek. SPACE beëindigt verbindingen die aan de oude uitvoering gekoppeld zijn en laat daarvoor in aanmerking komende bewerkingen onder dezelfde beveiligingscontroles opnieuw verbinding maken met de huidige uitvoering.

Terminals en bestandswatches kunnen langer bestaan dan de verzoeken waarmee ze zijn geopend. SPACE koppelt backendstreams aan een identiteitsepoch, zodat een stream niet aan zijn voorganger gekoppeld kan blijven nadat de ontvanger een vervangende uitvoering heeft geïnstalleerd.

SPACE controleert de duurzame identiteit opnieuw voordat een stream wordt geopend. Wanneer de route of uitvoering wordt vervangen, wordt de lease van de stream geannuleerd en stoppen invoer en uitvoer.

Eigendomswijzigingen staan los van het vervangen van een uitvoering. Een overdracht van een levenscyclusbewerking op een ongewijzigde Kubernetes-resident behoudt de route-identiteit, niet-verlopen capabilities en streams. De gateway behoudt ook bestaande streams bij wijzigingen die alleen de activeringspoging betreffen binnen dezelfde route- en uitvoeringsgeneratie. Voor het openen van nieuwe streams is de bijgewerkte identiteit vereist.

Bij herstel blijven deze controles intact. De identiteitsvergelijker kan RefreshRoute retourneren bij een niet-overeenkomende incarnatie binnen dezelfde sandbox, of Deny bij een andere sandbox. Alleen een herkend vernieuwingssignaal activeert routeherstel na een identiteitsafwijzing. Voor transportfouten gelden aparte, bewerkingsspecifieke herstelregels. Ongeldige handtekeningen, doelen of poortprofielen blijven geweigerd.

Een daarvoor in aanmerking komende bewerking kan de huidige uitvoering opzoeken en één herbouwde poging doen. Een cache-item wordt alleen vervangen als het nog de geweigerde route bevat, zodat een vertraagde weigering geen nieuwer item kan verdringen. Het vernieuwen van een native sessie behoudt de oorspronkelijke vervaltijd van de cache, waardoor routeherstel gescheiden blijft van het verlengen van de autorisatie van de aanroeper.

Replayregels blijven bewerkingsspecifiek. Een vervangende backend moet de toelatingscontrole opnieuw doorlopen, zelfs wanneer de WebSocket aan de clientzijde open blijft.

Vergroten

Afwegingen en vertrouwensgrenzen

Uitvoeringsidentiteit wordt beveiligingskritieke status. Updates van het control plane en bundels met verificatiesleutels moeten de bedienende onderdelen bereiken, en buitengebruikstelling gaat in wanneer elke ontvanger de update installeert. Korte levensduren van capabilities begrenzen hergebruik tijdens de verspreiding.

Het ontwerp gaat ervan uit dat identiteitshandhaving is ingeschakeld en vertrouwt de ondertekenaar van het control plane, de worker-kernel en de node-lokale beheerservices. Compromittering van root-toegang op de worker of van een geprivilegieerde clusterbeheerder valt buiten het dreigingsmodel. Bridgeverificatie is lokale verificatie van proces en transport, geen hardwarematige attestatie op afstand.

Handtekeningverificatie, runtimevergelijkingen en bridgevalidatie voegen werk toe aan het verzoekpad. Ze gebruiken lokale status in plaats van bij elke private hop een externe autorisatiecontrole uit te voeren.

Vergelijking binnen de sector

De relevante vergelijking is hoe platforms omgaan met een geautoriseerd verzoek dat de verkeerde uitvoering van de juiste sandbox bereikt. Deze bevindingen betreffen de onderzochte implementaties, niet de algehele platformbeveiliging. SPACE, OpenShell en E2B zijn op 8 oktober 2026 gecontroleerd:

• OpenShell: Biedt vergelijkbare uitvoeringsselectie voor nieuwe aanroepen en binding van supervisor aan runtime via gatewaygeneratie- en autorisatiecontroles, validatie van de backendidentiteit en bevestigde actieve supervisorverbindingen (gateway-toelating, runtime-authenticatie en -binding). SPACE neemt de ondertekende selectie mee langs zijn serverpad en voegt worker-lokale verificatie van proces en transport toe; OpenShell verdeelt overeenkomstige controles over de gateway, de opstartidentiteit en het geauthenticeerde runtimeprotocol (runtime-ontwerp).
• E2B: Houdt uitvoerings-ID's bij en isoleert proxypools per Firecracker-levenscyclus, maar de inkomende proxy selecteert de logische sandbox en poort zonder een verwachte uitvoeringsidentiteit waarmee de ontvanger kan vergelijken (routepublicatie, proxytoelating). Een oudere uitvoering die op een verouderde ontvanger met overeenkomende referenties nog als live staat geregistreerd, is met die controles niet te onderscheiden van de geselecteerde nieuwere uitvoering, al worden bij een normale afbraak routes verwijderd en aan de levenscyclus gebonden verbindingen gesloten (referenties, afbraak).
• CubeSandbox: Herstelt de routering bij hervatten en maakt caches ongeldig, maar private ingress gebruikt sandboxgebonden referenties en stuurt door zonder een verwachte runtime-incarnatie (routering bij hervatten, ingress-routering). Routeherstel verkort de periodes waarin verouderde routes actief zijn; de uitvoeringsgebonden capability van SPACE geeft de ontvanger bovendien een onafhankelijke basis om de verkeerde incarnatie te weigeren.

Identiteit als isolatiegrens

Veilig delegeren vereist dat het werk van elke agent binnen de daarvoor bedoelde grenzen blijft. Een microVM biedt isolatie, terwijl het omringende platform ervoor moet zorgen dat elk verzoek en elke lopende verbinding de uitvoering bereikt die gemachtigd is om die af te handelen.

SPACE maakt uitvoeringsidentiteit onderdeel van die bescherming. Door bestemmingen te controleren, bridge-eindpunten te verifiëren en verbindingen te koppelen aan de uitvoering die ze heeft geautoriseerd, bewaakt SPACE die grenzen terwijl sandboxes pauzeren, hervatten en verhuizen.

We zetten dit werk voort naarmate de infrastructuur zich ontwikkelt. Voor SPACE en andere sandboxplatforms vereist beveiliging dat deze paden worden getest tegen zowel alledaagse routeringsfouten als vijandige workloads, en dat de grenzen worden versterkt overal waar die tests tekortkomingen aan het licht brengen.