Slik ruter SPACE forespørsler til riktig sandbox-kjøring

Når noen ber en AI-agent om å analysere et regneark eller teste programvare, stoler de på at den jobber trygt med filene og dataene deres. Agenter trenger isolerte miljøer der de kan utføre dette arbeidet uten å eksponere andre brukeres data eller forstyrre arbeidslastene deres.

Etter hvert som agenter tar på seg mer komplekse oppgaver med større autonomi, bidrar disse miljøene til å holde feil innenfor avgrensede rammer og begrense skadene som usikker eller ondsinnet kode kan forårsake. Sandboxer gir denne isolasjonen samtidig som de deler kontrollplantjenester, arbeidsnoder og rutingsinfrastruktur.

Den delte infrastrukturen må levere hver operasjon til kjøringen som er autorisert til å håndtere den. En utdatert rute kan sende en gyldig forespørsel til en annen sandbox, eller til en eldre kjøring av riktig sandbox. SPACE, Perplexitys sikre sandbox-plattform, binder hver operasjon til en valgt kjøring og kontrollerer destinasjonen før videresending.

I flere måneder har SPACE håndtert millioner av kjøringer per dag, hver beskyttet av en unik kryptografisk identitet, med en feilrate på under 0,0002 % og null tapte tilkoblinger.

Rutingsproblemet

Sandbox-sikkerhet avhenger også av at hver forespørsel når riktig destinasjon. Selv en enkel fillesing går gjennom delt infrastruktur som må holde oversikt over hvor sandboxen kjører når den settes på pause, gjenopptas eller flyttes mellom maskiner.

En fillesing går gjennom flere komponenter. SPACEs kontrollplan knytter sandboxen til en kjøring og en arbeidsnode. Forespørselen kommer inn via node-api, sendes videre til sandbox-manageren, sbx-manager, og krysser en Unix-socket til vertsbroen, spaced-host. Broen videresender den over VSOCK, socket-transporten mellom vert og gjest, til spaced-guest inne i Firecracker-microVM-en.

Hver beslutning bygger på tilstand som kan henge etter endringer i infrastrukturen. En database kan beholde en gammel plassering, en hurtigbufret adresse kan peke et annet sted, eller en socket-sti kan få en annen lytter. En vellykket tilkobling kan likevel nå feil destinasjon. En leseoperasjon kan eksponere en annen brukers data; en skriveoperasjon kan endre feil filsystem.

Øyeblikksbilder skaper enda et problem. Når en sandbox gjenopptas på en annen arbeidsnode, bevares den logiske identiteten, men en ny kjøring starter. En forsinket forespørsel eller en gjenværende tilkobling kan nå forgjengeren og returnere gammel tilstand under riktig sandbox-navn.

Forstørr

Sandbox-identitet og kjøringsidentitet

SPACE skiller brukerens miljø fra kjøretiden som betjener det:

• Sandbox-identitet: Den stabile ID-en til det logiske miljøet. Autorisering av kalleren fastslår tilgangen til denne sandboxen.
• Rute-/kjøringsidentitet: Den valgte kjøretidsinkarnasjonen og plasseringen av den, inkludert worker, substrat og aktivering.

En kjøringsgenerasjon skiller mellom kjøretidsinkarnasjoner. På Kubernetes inkluderer ruten også pod-UID-en. Adresser lokaliserer endepunkter; kjøringsidentiteten avgjør om disse endepunktene kan betjene operasjonen.

Anta at sandbox S kjører som kjøring 7 på arbeidsnode A, og deretter gjenopptas som kjøring 8 på arbeidsnode B. En forespørsel som er valgt for kjøring 8, må mislykkes hvis den når kjøring 7. Å kontrollere bare sandbox-ID-en ville ikke avdekket avviket.

Forstørr

Signert valg av kjøring

Hver forespørsel inneholder signert bevis på hvilken sandbox-kjøring som kan håndtere den, og hvilken tilgang som er tillatt. Den mottakende komponenten kontrollerer beviset mot sin egen kjøretidsidentitet før forespørselen får gå videre.

Etter autorisering av kalleren utsteder SPACE en kortlivet, signert kapabilitet som identifiserer sandboxen, kjøringen, plasseringen og tillatt tilgang. Kapabiliteter for offentlige tjenesteporter angir også tillatt port og protokoll.

Den mottakende sandbox-manageren verifiserer signaturen og sammenligner hele identiteten med sin lokalt lagrede kjøretidspost. Signaturen fastslår hvem som autoriserte valget. Sammenligningen fastslår om valget samsvarer med mottakeren.

ServicePort-trafikk får en ekstra kontroll i nettverksgatewayen for hver sandbox, netgtw, før en gjestetilkobling åpnes. Gatewayen sammenligner identiteten med pålitelig aktiveringstilstand og kontrollerer porten og protokollen. Kontrolloperasjoner går videre til verifisering av broendepunkter.

SPACE bruker Ed25519-signaturer. Signeringsnøkler i kontrollplanet utsteder kapabiliteter; offentlige verifiseringsnøkler på arbeidsnoder og gatewayer kan ikke utstede dem.

Kapabiliteter varer i 120 sekunder, med opptil 15 sekunders toleranse for klokkeavvik ved utløp. En gyldig signatur og et token som ikke har utløpt, er likevel ikke nok når den valgte og den installerte identiteten ikke stemmer overens.

Forstørr

Avvisning på feil destinasjon

Den mottakende arbeidsnoden kan fange opp en rutingsfeil selv når selve forespørselen er autorisert. Den kontrollerer om den faktisk betjener kjøringen som er valgt for forespørselen, og avviser forespørselen hvis de ikke samsvarer.

Hvis en forespørsel som er valgt for kjøring 8, når worker A, som fortsatt betjener kjøring 7, avviser worker A den før videresending. Når en mottaker har installert identiteten til kjøring 8, avviser den også kapabiliteter for kjøring 7, selv før de utløper.

Denne garantien har en viktig begrensning. En kapabilitet for kjøring 7 kan fortsatt samsvare med en arbeidsnode som betjener kjøring 7, helt til arbeidsnoden får vite om utfasingen eller kapabiliteten utløper. Lokal håndheving og begrenset levetid for kapabiliteter virker sammen mens oppdateringene spres.

Forstørr

Verifisering av broendepunkter

En samsvarende kjøretidspost fastslår den tiltenkte kjøringen. Kontrollbroen må også nå prosessene og transporten som tilhører den aktiveringen, og ikke en erstatning som har arvet samme adresse.

Sandbox- og nodemanagerne verifiserer vertsbroens peer-legitimasjon og prosessidentiteten til både broen og Firecracker, inkludert starttidspunkter, slik at gjenbrukte ID-er eller endrede kjørbare filer oppdages

Transportkontroller knytter VSOCK-lytteren til den forventede Firecracker-prosessen ved hjelp av socket-eierskap, gjesteidentitet og socket-bevis fra kjernen. Broen videresender operasjoner først etter verifisering og avviser transparente gjenoppkoblinger. Hver ny tilkobling må bestå kontrollene på nytt.

Denne verifiseringen omfatter Firecracker-kontrollbroen på Kubernetes og på direkte administrerte verter. ServicePort-trafikk bruker kjørings- og portkontroller i gatewayen sin; den attesterer ikke identiteten til en vilkårlig applikasjon inne i gjesten.

Forstørr

Strømmers levetid og rutegjenoppretting

Noen tilkoblinger forblir åpne mens kjøringen til en sandbox endres, så identitetskontrollene må gå lenger enn den første forespørselen. SPACE faser ut tilkoblinger som er knyttet til den gamle kjøringen, og lar kvalifiserte operasjoner koble seg til den gjeldende kjøringen på nytt under de samme sikkerhetskontrollene.

Terminaler og filovervåkinger kan leve lenger enn forespørslene som åpnet dem. SPACE knytter backend-strømmer til en identitetsepoke, slik at en strøm ikke kan forbli koblet til forgjengeren etter at mottakeren har installert en erstatningskjøring.

SPACE kontrollerer den varige identiteten på nytt før en strøm åpnes. Hvis ruten eller kjøringen skiftes ut, kanselleres strømmens lease, og inndata og utdata stoppes.

Eierskapsendringer er noe annet enn utskifting av kjøringen. En overlevering av livssyklusoperasjoner på en uendret Kubernetes-resident bevarer ruteidentiteten, kapabiliteter som ikke har utløpt, og strømmene. Gatewayen bevarer også etablerte strømmer ved endringer som bare gjelder aktiveringsforsøket, innenfor samme rute og kjøringsgenerasjon. Nye åpninger krever den oppdaterte identiteten.

Gjenopprettingen bevarer disse kontrollene. Identitetskomparatoren kan returnere RefreshRoute ved inkarnasjonsavvik innenfor samme sandbox, eller Deny for en annen sandbox. Bare et gjenkjent oppdateringssignal utløser reparasjon av ruten etter identitetsavvisning. Transportfeil følger egne, operasjonsspesifikke gjenopprettingsregler. Ugyldige signaturer, formål eller portprofiler blir fortsatt avvist.

En kvalifisert operasjon kan slå opp den gjeldende kjøringen og gjøre ett nytt forsøk med gjenoppbygd rute. Utskifting i hurtigbufferen er betinget av den avviste ruten, slik at en forsinket avvisning ikke kan fjerne en nyere oppføring. Oppfriskning av native-økter bevarer det opprinnelige utløpet i hurtigbufferen, slik at rutereparasjon holdes atskilt fra fornyelse av kallerens autorisasjon.

Replay-reglene er fortsatt operasjonsspesifikke. En erstatningsbackend må gjennom opptakskontrollen på nytt, selv når den klientvendte WebSocket-tilkoblingen forblir åpen.

Forstørr

Avveininger og tillitsgrenser

Kjøringsidentitet blir sikkerhetskritisk tilstand. Oppdateringer fra kontrollplanet og pakker med verifiseringsnøkler må nå komponentene som betjener trafikk, og utfasing trer i kraft når hver mottaker installerer oppdateringen. Korte levetider for kapabiliteter begrenser gjenbruk mens oppdateringene spres.

Designet forutsetter at identitetshåndheving er aktivert, og stoler på kontrollplanets signeringstjeneste, arbeidsnodens kjerne og nodelokale administrasjonstjenester. Kompromittering av root på arbeidsnoden eller av privilegerte klyngeadministratorer ligger utenfor trusselmodellen. Broverifiseringen er lokal verifisering av prosess og transport, ikke maskinvarebasert fjernattestering.

Signaturverifisering, kjøretidssammenligninger og brovalidering gir ekstra arbeid i forespørselsstien. De bruker lokal tilstand i stedet for et eksternt autorisasjonsoppslag ved hvert private hopp.

Bransjesammenligning

Den relevante sammenligningen er hvordan plattformer håndterer at en autorisert forespørsel når feil kjøring av riktig sandbox. Disse funnene gjelder de undersøkte implementasjonene, ikke plattformenes samlede sikkerhet. SPACE, OpenShell og E2B ble kontrollert 8. oktober 2026:

• OpenShell: Tilbyr tilsvarende valg av kjøring for nye kall og binding mellom supervisor og kjøretid gjennom gateway-generasjons- og autorisasjonskontroller, validering av backend-identitet og bekreftede aktive supervisor-tilkoblinger (gateway-opptak, kjøretidsautentisering og binding). SPACE fører det signerte valget gjennom hele tjenestestien og legger til lokal prosess- og transportverifisering på arbeidsnoden; OpenShell fordeler tilsvarende kontroller på gatewayen, oppstartsidentiteten og den autentiserte kjøretidsprotokollen (kjøretidsdesign).
• E2B: Sporer kjørings-ID-er og isolerer proxy-pooler etter Firecracker-livssyklus, men den innkommende proxyen velger den logiske sandboxen og porten uten en forventet kjøringsidentitet som mottakeren kan sammenligne med (rutepublisering, proxy-opptak). En eldre kjøring som fortsatt er registrert som aktiv på en utdatert mottaker med samsvarende legitimasjon, kan ikke skilles fra den valgte nyere kjøringen ved hjelp av disse kontrollene, selv om normal nedriving fjerner ruter og lukker livssyklusbundne tilkoblinger (legitimasjon, nedriving).
• CubeSandbox: Reparerer ruting ved gjenopptak og ugyldiggjør hurtigbuffere, men privat ingress bruker sandbox-avgrenset legitimasjon og videresender uten en forventet kjøretidsinkarnasjon (ruting ved gjenopptak, ingress-ruting). Rutereparasjon reduserer vinduene med utdaterte ruter; SPACEs kjøringsbundne kapabilitet gir også mottakeren et uavhengig grunnlag for å avvise feil inkarnasjon.

Identitet som isolasjonsgrense

Trygg delegering avhenger av at hver agents arbeid holdes innenfor grensene som er tiltenkt den. En microVM gir isolasjon, mens plattformen rundt må sikre at hver forespørsel og hver pågående tilkobling når kjøringen som er autorisert til å håndtere den.

SPACE gjør kjøringsidentitet til en del av denne beskyttelsen. Ved å kontrollere destinasjoner, verifisere broendepunkter og knytte tilkoblinger til kjøringen som autoriserte dem, bevarer SPACE disse grensene når sandboxer settes på pause, gjenopptas og flyttes.

Vi fortsetter arbeidet etter hvert som infrastrukturen utvikler seg. For SPACE og andre sandbox-plattformer krever sikkerhet at disse stiene testes mot både vanlige rutingsfeil og fiendtlige arbeidslaster, og at grensene styrkes der testene avdekker svakheter.