Sådan dirigerer SPACE anmodninger til den rigtige sandbox-eksekvering

Når nogen beder en AI-agent om at analysere et regneark eller teste software, stoler de på, at den arbejder sikkert med deres filer og data. Agenter har brug for isolerede miljøer, hvor de kan udføre arbejdet uden at eksponere andre brugeres data eller forstyrre deres arbejdsbelastninger.

Når agenter påtager sig mere komplekse opgaver med større autonomi, hjælper disse miljøer med at begrænse fejl og den skade, som usikker eller ondsindet kode kan forårsage. Sandboxe giver denne isolation, samtidig med at de deler tjenester i kontrolplanet, worker-noder og routinginfrastruktur.

Den delte infrastruktur skal levere hver operation til den eksekvering, der er autoriseret til at håndtere den. En forældet rute kan sende en gyldig anmodning til en anden sandbox eller til en ældre eksekvering af den rigtige sandbox. SPACE, Perplexitys sikre sandbox-platform, binder hver operation til en valgt eksekvering og kontrollerer destinationen før videresendelse.

I flere måneder har SPACE håndteret millioner af eksekveringer om dagen, hver beskyttet af en unik kryptografisk identitet, med en fejlrate under 0,0002 % og ingen tabte forbindelser.

Routingproblemet

Sandbox-sikkerhed afhænger også af, at hver anmodning når den rigtige destination. Selv en simpel fillæsning passerer gennem delt infrastruktur, der skal holde styr på, hvor sandboxen kører, når den sættes på pause, genoptages eller flyttes mellem maskiner.

En fillæsning bevæger sig gennem flere komponenter. SPACEs kontrolplan slår op, hvilken eksekvering og worker sandboxen hører til. Anmodningen kommer ind via node-api, går videre til sandbox-manageren, sbx-manager, og krydser en Unix-socket til værtsbroen, spaced-host. Broen videresender den over VSOCK, socket-transporten mellem vært og gæst, til spaced-guest inde i Firecracker-microVM'en.

Hver beslutning bygger på tilstand, der kan halte efter ændringer i infrastrukturen. En database kan bevare en gammel placering, en cachelagret adresse kan pege et andet sted hen, eller en socket-sti kan få en anden lytter. En vellykket forbindelse kan stadig nå den forkerte destination. En læsning kan eksponere en anden brugers data; en skrivning kan ændre det forkerte filsystem.

Snapshots tilføjer endnu et problem. Når en sandbox genoptages på en anden worker, bevares dens logiske identitet, men der startes en ny eksekvering. En forsinket anmodning eller en forbindelse, der stadig er i live, kan nå forgængeren og returnere gammel tilstand under det rigtige sandbox-navn.

Udvid

Sandbox-identitet og eksekveringsidentitet

SPACE adskiller brugerens miljø fra den runtime, der betjener det:

• Sandbox-identitet: Det stabile id for det logiske miljø. Kalderens autorisation fastslår adgangen til denne sandbox.
• Rute-/eksekveringsidentitet: Den valgte runtime-inkarnation og dens placering, herunder dens worker, substrat og aktivering.

En eksekveringsgeneration adskiller runtime-inkarnationer. På Kubernetes indeholder ruten også podens UID. Adresser lokaliserer endepunkter; eksekveringsidentiteten afgør, om disse endepunkter må betjene operationen.

Antag, at sandbox S kører som eksekvering 7 på worker A og derefter genoptages som eksekvering 8 på worker B. En anmodning, der er valgt til eksekvering 8, skal mislykkes, hvis den når eksekvering 7. Et tjek af kun sandbox-id'et ville ikke opdage uoverensstemmelsen.

Udvid

Signeret valg af eksekvering

Hver anmodning medbringer et signeret bevis for, hvilken sandbox-eksekvering der må håndtere den, og hvilken adgang der er tilladt. Den modtagende komponent kontrollerer beviset mod sin egen runtime-identitet, før anmodningen får lov at fortsætte.

Efter autorisation af kalderen udsteder SPACE en kortlivet, signeret kapabilitet, der identificerer sandboxen, eksekveringen, placeringen og den tilladte adgang. Kapabiliteter til offentlige serviceporte angiver også den tilladte port og protokol.

Den modtagende sandbox-manager verificerer signaturen og sammenligner den fulde identitet med sin lokalt gemte runtime-post. Signaturen fastslår, hvem der har autoriseret udvælgelsen. Sammenligningen fastslår, om udvælgelsen passer til modtageren.

ServicePort-trafik får et ekstra tjek i den netværksgateway, der hører til hver sandbox, netgtw, før en forbindelse til gæsten åbnes. Gatewayen sammenligner identiteten med betroet aktiveringstilstand og kontrollerer port og protokol. Kontroloperationer går videre til verifikation af broens endepunkter.

SPACE bruger Ed25519-signaturer. Kontrolplanets signeringsnøgler udsteder kapabiliteter; offentlige verifikationsnøgler på workers og gateways kan ikke udstede dem.

Kapabiliteter gælder i 120 sekunder med en tolerance for urforskydning på op til 15 sekunder ved udløb. En gyldig signatur og et token, der ikke er udløbet, er stadig ikke tilstrækkelige, når den valgte og den installerede identitet ikke stemmer overens.

Udvid

Afvisning ved den forkerte destination

Den modtagende worker kan fange en routingfejl, selv når selve anmodningen er autoriseret. Den kontrollerer, om den kører den eksekvering, der er valgt til anmodningen, og afviser anmodningen, hvis de ikke stemmer overens.

Hvis en anmodning, der er udvalgt til eksekvering 8, når frem til worker A, som stadig betjener eksekvering 7, afviser worker A den, før den videresendes. Når en modtager har installeret identiteten for eksekvering 8, afviser den også capabilities for eksekvering 7 – selv før de udløber.

Der er en vigtig grænse for denne garanti. En kapabilitet for eksekvering 7 kan stadig matche en worker, der betjener eksekvering 7, indtil workeren får besked om udfasningen, eller kapabiliteten udløber. Lokal håndhævelse og en begrænset levetid for kapabiliteter virker sammen, mens opdateringerne udbredes.

Udvid

Verifikation af broens endepunkter

En matchende runtime-post fastslår den tilsigtede eksekvering. Kontrolbroen skal også nå de processer og den transport, der hører til denne aktivering – ikke en erstatning, der har arvet den samme adresse.

Sandbox- og node-managerne verificerer værtsbroens peer-legitimationsoplysninger samt procesidentiteterne for både broen og Firecracker, herunder starttidspunkter, så genbrugte id'er eller ændrede eksekverbare filer opdages

Transporttjek knytter VSOCK-lytteren til den forventede Firecracker-proces ved hjælp af socket-ejerskab, gæsteidentitet og socket-evidens fra kernen. Broen videresender kun operationer efter verifikation og afviser transparente genforbindelser. Hver ny forbindelse skal bestå tjekkene igen.

Denne verifikation dækker Firecrackers kontrolbro på Kubernetes og på direkte administrerede værter. ServicePort-trafik bruger eksekverings- og porttjek i sin gateway; den attesterer ikke identiteten af en vilkårlig applikation inde i gæsten.

Udvid

Streamlevetid og genopretning af ruter

Nogle forbindelser forbliver åbne, mens sandboxens eksekvering skifter, så identitetstjek skal række ud over den første anmodning. SPACE udfaser forbindelser, der er knyttet til den gamle eksekvering, og lader berettigede operationer genoprette forbindelsen til den aktuelle under de samme sikkerhedstjek.

Terminaler og filovervågninger kan leve længere end de anmodninger, der åbnede dem. SPACE knytter backend-streams til en identitetsepoke, så en stream ikke kan forblive tilknyttet forgængeren, efter at modtageren har installeret en erstatningseksekvering.

SPACE kontrollerer den varige identitet igen, før en stream åbnes. Hvis streamens rute eller eksekvering udskiftes, annulleres dens lease, og input og output stopper.

Ejerskabsskift er noget andet end udskiftning af eksekveringen. En overdragelse af en livscyklusoperation på en uændret Kubernetes-resident bevarer dens ruteidentitet, ikke-udløbne kapabiliteter og streams. Gatewayen bevarer også etablerede streams ved ændringer, der kun vedrører aktiveringsforsøget, inden for samme rute- og eksekveringsgeneration. Nye åbninger af streams kræver den opdaterede identitet.

Gendannelse bevarer disse kontroller. Identitetskomparatoren kan returnere RefreshRoute ved en inkarnationsuoverensstemmelse inden for samme sandbox eller Deny for en anden sandbox. Kun et genkendt opdateringssignal udløser reparation af ruten efter en identitetsafvisning. Transportfejl følger separate, operationsspecifikke gendannelsesregler. Ugyldige signaturer, formål eller portprofiler forbliver afvist.

En berettiget operation kan slå den aktuelle eksekvering op og foretage ét genopbygget forsøg. Cacheudskiftning sker kun på betingelse af den afviste rute, så en forsinket afvisning ikke kan fjerne en nyere post. Opdatering af native sessioner bevarer cachens oprindelige udløbstid og adskiller dermed reparation af ruter fra fornyelse af kalderens autorisation.

Regler for genafspilning forbliver operationsspecifikke. En erstatningsbackend skal igennem adgangskontrollen igen, selv når WebSocket-forbindelsen til klienten forbliver åben.

Udvid

Afvejninger og tillidsgrænser

Eksekveringsidentitet bliver sikkerhedskritisk tilstand. Opdateringer fra kontrolplanet og bundter af verifikationsnøgler skal nå de betjenende komponenter, og udfasning træder i kraft, når hver modtager installerer opdateringen. Korte levetider for kapabiliteter begrænser genbrug under udbredelsen.

Designet forudsætter, at identitetshåndhævelse er aktiveret, og har tillid til kontrolplanets signeringstjeneste, workerens kerne og de nodelokale administrationstjenester. Kompromittering af root-adgang på workeren eller af privilegerede klyngeadministratorer ligger uden for trusselsmodellen. Broverifikationen er lokal verifikation af processer og transport – ikke hardwarebaseret fjernattestering.

Signaturverifikation, runtime-sammenligninger og validering af broen tilføjer arbejde i anmodningsstien. De bruger lokal tilstand i stedet for et eksternt autorisationsopslag ved hvert privat hop.

Sammenligning med branchen

Den relevante sammenligning er, hvordan platforme håndterer, at en autoriseret anmodning når den forkerte eksekvering af den rigtige sandbox. Disse resultater vedrører de undersøgte implementeringer, ikke platformenes samlede sikkerhed. SPACE, OpenShell og E2B blev undersøgt den 8. oktober 2026:

• OpenShell: Giver tilsvarende eksekveringsvalg for nye kald og binding mellem supervisor og runtime via gateway-generationer og autorisationstjek, validering af backend-identitet og bekræftede aktive supervisorforbindelser (gateway-adgangskontrol, runtime-godkendelse og -binding). SPACE fører den signerede udvælgelse gennem hele den sti, der betjener anmodningen, og tilføjer workerlokal verifikation af processer og transport; OpenShell fordeler tilsvarende tjek på tværs af sin gateway, startidentitet og autentificerede runtime-protokol (runtime-design).
• E2B: Sporer eksekverings-id'er og isolerer proxypuljer efter Firecracker-livscyklus, men den indgående proxy vælger den logiske sandbox og port uden en forventet eksekveringsidentitet, som modtageren kan sammenligne med (publicering af ruter, proxy-adgangskontrol). En ældre eksekvering, der stadig er registreret som aktiv på en forældet modtager med matchende legitimationsoplysninger, kan ikke skelnes fra den valgte nyere eksekvering ved hjælp af disse tjek, selvom normal nedlukning fjerner ruter og lukker livscyklusbundne forbindelser (legitimationsoplysninger, nedlukning).
• CubeSandbox: Reparerer routing ved genoptagelse og ugyldiggør caches, men privat ingress bruger sandbox-afgrænsede legitimationsoplysninger og videresender uden en forventet runtime-inkarnation (routing ved genoptagelse, ingress-routing). Reparation af ruter mindsker de tidsvinduer, hvor forældede ruter er i brug; SPACEs eksekveringsbundne kapabilitet giver desuden modtageren et uafhængigt grundlag for at afvise den forkerte inkarnation.

Identitet som isolationsgrænse

Sikker delegering afhænger af, at hver agents arbejde holdes inden for de grænser, der er tiltænkt den. En microVM giver isolation, mens den omgivende platform skal sikre, at hver anmodning og igangværende forbindelse når den eksekvering, der er autoriseret til at håndtere den.

SPACE gør eksekveringsidentitet til en del af den beskyttelse. Ved at kontrollere destinationer, verificere broens endepunkter og knytte forbindelser til den eksekvering, der autoriserede dem, bevarer SPACE disse grænser, når sandboxe sættes på pause, genoptages og flyttes.

Vi fortsætter arbejdet, efterhånden som infrastrukturen udvikler sig. For SPACE og andre sandbox-platforme kræver sikkerhed, at disse stier testes mod både almindelige routingfejl og fjendtlige arbejdsbelastninger, og at grænserne derefter styrkes, hvor testene afslører huller.