SPACE maken: Veilige en efficiënte runtimes voor langlopende agents

Naarmate agentische workflows langer en autonomer worden, is de omgeving waarin AI-agents opereren even belangrijk als de modellen die ze aansturen. Agents moeten echt werk kunnen verrichten, zoals code uitvoeren, bestandssystemen bewerken en taken in meerdere stappen uitvoeren gedurende uren of dagen. Gebruikers willen dat agents toegang hebben tot de tools en bestanden die ze nodig hebben om deze taken uit te voeren, maar ze moeten er ook op kunnen vertrouwen dat hun systemen veilig blijven, zelfs als agents gecompromitteerd zijn. Een sandbox maakt dit allemaal mogelijk: een geïsoleerde omgeving waar een agent vrij kan opereren terwijl de host, andere huurders en gevoelige inloggegevens beschermd blijven.

Traditionele container-gebaseerde sandbox-benaderingen zijn niet ontworpen voor deze taken. Ze gaan doorgaans uit van kortstondige, stateloze taken en hebben de kernel als een single point of failure. Daarentegen zijn agent-sessies langlevend en stateful: een agent verzamelt uren aan context, een werkend bestandssysteem en draaiende processen die niet simpelweg weggegooid en vanaf nul kunnen worden opgebouwd. Bovendien moet de werklast binnenin standaard als niet-vertrouwd worden beschouwd, wat sterkere beveiligingsmaatregelen noodzakelijk maakt. Langlopende agent-sessies hebben een substraat nodig dat een vijandige gast kan isoleren, de status ervan kan behouden en toch op schaal kan worden bediend.

De belangrijkste uitdaging bij sandbox-engineering komt voort uit de spanning die vaak ontstaat tussen beveiliging, functionaliteit en efficiëntie. Bijvoorbeeld:

Het verlenen van bredere toegang stelt een agent in staat om meer te bereiken, maar stelt meer van het systeem bloot aan een werklast die u niet vertrouwt.

Meer delen tussen sandboxes maakt creatie sneller, maar vergroot het aanvalsoppervlak.

Het vaker maken van snapshots verbetert het herstel en maakt functies zoals terugdraaien mogelijk, maar vereist tijd en opslagruimte.

Agentische sandboxes, zoals die vereist zijn voor het uitvoeren van code, het gebruik van Agent Skills, of het uitvoeren van Search as Code-pijplijnen in Computer-queries, hebben alle drie nodig. We hebben de afgelopen maanden hard gewerkt aan het engineeren van de volgende generatie agent-infrastructuur die onze producten aandrijft. Vandaag introduceren we SPACE (Sandboxed Platform for Agentic Code Execution): een sandbox-platform gebouwd voor agentische workflows dat veilig, betrouwbaar en efficiënt op schaal is. Vorige maand zijn we begonnen met het uitrollen van SPACE als de sandbox-laag die Perplexity Computer aandrijft. In de afgelopen week heeft het veilig miljoenen sandbox-creaties en tientallen miljoenen herverbindingen ondersteund, met opstarttijden die 3-5 keer sneller zijn dan onze vorige oplossing.

Dit artikel presenteert de architecturale en ontwerpbeslissingen achter SPACE. Sinds vandaag draait 100% van de Computer-sessies op SPACE. We zijn enthousiast om dit platform over nog meer oppervlakken in te zetten om onze gebruikers en ontwikkelaars een best-in-class agentische runtime te leveren.

Architectuur

Op hoog niveau is het systeem georganiseerd in drie lagen.

Het control plane is het brein van het systeem en bepaalt wat er moet bestaan en waar. Het bestaat uit de API-gateway en de state-managementmodules op clusterniveau.

Node-lokale services zijn het lokale mechanisme dat nodig is om het plan van het control plane uit te voeren. Zij beheren de levenscyclus van de sandbox, opslag, netwerken en de bevoorrechte operaties daarachter.

De sandbox is de geïsoleerde uitvoeringsomgeving zelf. Het is geïmplementeerd als een virtuele machine gekoppeld aan de space-daemon: een achtergrondproces in de gast dat bestandssysteem-, proces- en netwerktoegang voor de werklast regelt.

Control Plane

De API-gateway is het toegangspunt. Inkomende verzoeken worden geauthenticeerd en geautoriseerd, en vervolgens vertaald naar records van de gewenste status.

Het control plane is ontworpen om stateloos te zijn, waarbij alle duurzame informatie wordt overgedragen naar een gedeelde database. Het houdt informatie op clusterniveau bij over sandboxes, zoals aan welke node ze zijn toegewezen, waar ze draaien en of ze zijn geback-upt naar duurzame opslag. Het vergelijkt continu de gewenste status met de waargenomen status en stuurt de twee aan op convergentie. Operaties zijn idempotent, dus het control plane kan automatisch herstellen na elke crash, herstart of gedeeltelijk falen.

Node-lokale services

Node-lokale services doen het feitelijke werk van het voorbereiden van sjablonen, het starten van sandboxes, het bedraden van netwerken en het uitvoeren van runtime-services aan de host-zijde. Elke node draait een kleine set daemons die elke sandbox die erop is geplaatst beheert, en de node is de bron van waarheid voor de live statussen van die sandboxes.

De sandbox-manager weet welke sandboxes draaien, gepauzeerd, opgeschort of gestopt zijn, samen met hun werkelijke bronnen. Het draait zonder privileges en delegeert al het bevoorrechte werk aan de node-manager, het enige root-proces dat de onderliggende primitieven regelt. Opslag wordt lokaal en duurzaam afgehandeld: snapshots van huidige sandbox-statussen worden op de node opgeslagen en een volume-manager verplaatst snapshots en sjablonen van en naar objectopslag indien nodig om cross-node operaties mogelijk te maken. Veiligheidspoorten bewaken wat een sandbox kan bereiken: de credential manager bestuurt inloggegevensinjectie onder per-service autorisatie en de netwerkgateway dwingt het egress-beleid van elke sandbox af.

Sandbox

De sandbox zelf is een virtuele machine (VM) met zijn eigen gast-kernel, die de werklast van de gebruiker uitvoert achter een hardware-isolatiegrens. Omdat elke sandbox zijn eigen kernel heeft, kan een gecompromitteerde werklast niet terugvallen op een gedeelde host-kernel als single point of failure; zelfs als deze met succes de gast-kernel exploiteert, blijft dat compromis beperkt tot de VM-grens van de sandbox in plaats van zich te verspreiden over andere werklasten.

Een space-daemon draait binnen elke virtuele machine en fungeert als een lichtgewicht agent die elke actie of wijziging die het platform binnen de gast uitvoert, reguleert. Het handelt bestandssysteemtoegang en procesbeheer af. Het rapporteert ook de gereedheid van de gast en volgt de activiteit, zodat het platform weet wanneer een sandbox inactief is geworden en gepauzeerd of teruggevorderd kan worden. Cruciaal is dat de space-daemon niet direct met clients praat, maar communiceert met de host via een privaat in-VM-kanaal. Dit houdt alle interactie met de gast op een gecontroleerd pad en reserveert het eigen netwerk van de sandbox puur voor uitgaand verkeer van de werklast.

Drie pijlers: Beveiliging, functionaliteit en efficiëntie

Vervolgens duiken we in de belangrijkste eigenschappen die SPACE moet leveren op drie pijlers: beveiliging, functionaliteit en efficiëntie. Zoals eerder opgemerkt, trekken deze drie aan elkaar. Toch kunnen we op geen van deze compromissen sluiten als we krachtige agents willen ondersteunen die voldoen aan de modelcapaciteiten van vandaag. Beveiliging voorkomt dat een niet-vertrouwde, mogelijk vijandige werklast de host, andere huurders of geheimen van een gebruiker schaadt. Functionaliteit geeft agents de rijke levenscyclus die ze nodig hebben. Efficiëntie maakt dit allemaal betaalbaar onder eindig geheugen, schijf en compute.

Beveiliging: Gegevens en systemen beschermen

Sandbox-platforms hebben sterke beveiliging nodig om ervoor te zorgen dat foutieve of zelfs kwaadaardige code die in sandboxes wordt uitgevoerd, elders geen schadelijke effecten kan veroorzaken. Zonder strikte egress-controle af te dwingen en geheimen uit de sandbox te houden, zou een enkele verkeerde stap van een agent de sleutels van een gebruiker kunnen lekken of werk kunnen exfiltreren.

SPACE hanteert een gelaagde benadering om beveiliging voor sandboxes te garanderen. Sandbox-isolatie heeft twee componenten: VM-isolatie en host OS-procesisolatie. Beide moeten worden doorbroken voor cross-sandbox-toegang. Communicatie met de sandbox wordt strikt gecontroleerd; processen kunnen alleen communiceren via speciale kanalen. De netwerkgateway dwingt alle egress erdoorheen. De space-daemon is het enige toegestane kanaal tussen de (niet-vertrouwde) sandbox en het (vertrouwde) platform.

Inloggegevens bevinden zich nooit op een plek waar een agent ze kan stelen. De credential store bevindt zich buiten de sandbox-grens en is verantwoordelijk voor de levenscyclus van inloggegevens. Het slaat geheimen op en haalt ze op via een pluggable vault-backend, lost inloggegevens op met behulp van hiërarchische scoping, beheert metagegevens zoals injectiemethode en verloop, en dwingt snelheidslimieten en audit logging af op alle toegang. Wanneer nodig worden inloggegevens geïnjecteerd op de netwerklaag of automatisch ingevuld door een browser-agent, in plaats van direct de sandbox binnen te gaan.

Gegevens zijn beschermd in rust. SPACE ondersteunt BYOK (Bring Your Own Key) om extern opgeslagen gegevens te beschermen. Encryptiesleutels zijn afkomstig van de key management service van de klant en komen nooit de sandbox binnen. Als de onderneming de sleutel intrekt, worden hun gegevens onleesbaar.

Functionaliteit: Agentische workflows aandrijven

Om agentische workflows te ondersteunen, hebben sandboxes rijke levenscyclusondersteuning nodig. Ze moeten snel en op schaal worden gemaakt, aangezien een agent er veel tegelijk kan opstarten en niet mag wachten tot een ervan opstart. Ze moeten voor onbepaalde tijd blijven bestaan, aangezien een sessie minuten kan duren of maanden kan draaien. Ze moeten schoon kunnen pauzeren, soms voor lange perioden, zoals wanneer een taak is geblokkeerd door menselijke invoer. En ze moeten forking, rollback en crashherstel ondersteunen, zodat een sessie kan vertakken, een slechte stap ongedaan kan maken of kan hervatten na een fout in plaats van opnieuw te beginnen.

SPACE ondersteunt dit alles. Het modelleert de volledige sandbox-levenscyclus als een expliciete state machine, wat operaties zoals maken, pauzeren, hervatten, opschorten en herstellen mogelijk maakt.

Snapshots zijn het mechanisme achter de meeste van deze mogelijkheden. Een scheduler tikt op regelmatige intervallen en legt twee soorten snapshots vast: schijf-snapshots (point-in-time kopieën van het bestandssysteem) en volledige snapshots (checkpoints van de gehele gepauzeerde VM). Schijf-snapshots worden vaak vastgelegd, terwijl volledige checkpoints minder frequent zijn. Alles blijft op de node en retentie neemt af per laag. Deze snapshots kunnen worden gebruikt voor herstel binnen de sessie; schijf-snapshots kunnen bijvoorbeeld worden gebruikt om het bestandssysteem terug te draaien om een destructief commando ongedaan te maken, en volledige checkpoints laten een gecrashte sandbox hervatten op een recent draaiend punt in plaats van een koude schijf.

Wanneer een sandbox wordt opgeschort, wordt de VM gepauzeerd, een volledig snapshot gemaakt en de artefacten van het volledige snapshot geüpload naar objectopslag. Een database-rij volgt het snapshot en wordt pas herstelbaar zodra elk artefact is geland, dus een gedeeltelijk geüpload snapshot kan nooit worden hervat in een corrupte staat. Herstel is het omgekeerde van opschorten. Omdat het snapshot in objectopslag leeft in plaats van op de oorspronkelijke node, kan elke node de sandbox terughalen. De scheduler kiest een node, die node downloadt de artefacten, past de bestandssysteemdelta toe op het sjabloon en hervat de VM vanuit de vastgelegde staat.

Efficiëntie: Tijd en ruimte optimaliseren

Het is niet genoeg om de bovenstaande functies in een vacuüm te implementeren; ze moeten ook mogelijk zijn onder krappe bronbeperkingen. Geheugen en schijf op een node zijn eindig, en gebruikers willen dat agents zo snel mogelijk werken, dus levenscyclusoperaties moeten goedkoop zijn in zowel tijd als ruimte. We kunnen het ons niet veroorloven om elke keer dat een sandbox wordt gemaakt, gepauzeerd of vertakt, een volledig machine-image te kopiëren.

Een belangrijke ontwerpkeuze maakt dit mogelijk: het bestandssysteem. SPACE gebruikt btrfs als het on-node bestandssysteem voor sandbox-opslag. Btrfs (B-tree bestandssysteem) combineert een copy-on-write bestandssysteem met geïntegreerd logisch volumebeheer. Dit heeft een paar voordelen:

Reflink-kopieën zijn snel, omdat je de onderliggende extents deelt, dus alleen metagegevens hoeven te worden gekopieerd.

Snapshots zijn atomair en snel, omdat je gewoon een nieuwe root maakt.

Minimale opslag is nodig, omdat je alleen opslaat wat is gewijzigd.

Als resultaat kunnen sandboxes snel worden gemaakt en hersteld. In plaats van elke keer vanaf nul een sandbox te maken, houden we een warm pool van pods bij die al veelvoorkomende sjablonen op schijf hebben gematerialiseerd, en voldoen aan een verzoek door het te binden aan een pod waarvan het sjabloon al overeenkomt. Het geven van een eigen schrijfbaar root-bestandssysteem aan die sandbox is dan een copy-on-write kloon in plaats van een volledige kopie. Wanneer geen enkele warme pod past, materialiseren we het sjabloon op aanvraag; we voegen gelijktijdige verzoeken voor hetzelfde image samen in een enkele download, zodat een burst van identieke verzoeken niet verandert in een burst van identiek werk.

Het resultaat is een sandbox-runtime die tegelijkertijd krachtig, lichtgewicht en razendsnel is. Toen we SPACE uitrolden, lieten we het naast onze vorige sandbox-provider op hetzelfde productie-verkeer draaien. Gedurende de lanceringsweek creëerde SPACE sandboxes drie tot vijf keer sneller over de hele distributie. Specifiek daalde de mediane creatie-latentie van 185 milliseconden naar 60 milliseconden (3,1x verbetering), en de 90e percentiel-latentie daalde van 447 milliseconden naar 89 milliseconden (5,0x verbetering). We observeerden vergelijkbare verbeteringen in de ordegrootte bij andere prestatie- en brongebruiksindicatoren.

Het maakt het ook gemakkelijk om rollende schijf-snapshots te maken, omdat ze snel en ruimte-efficiënt zijn en het niet vereist dat de sandbox wordt gepauzeerd. En efficiënte delta-opslag vermindert de ruimte die nodig is om deze snapshots op te slaan.

Conclusie

Bij het ontwerpen van complexe systemen is het verleidelijk om een enkel doel te kiezen om in isolatie te optimaliseren. Maar ontwikkelaars van frontier-agents eisen beveiliging, functionaliteit en efficiëntie in gelijke mate. Met SPACE hebben we geprobeerd een Pareto-verbetering te bereiken op alle drie de pijlers.

Elke individuele ontwerpkeuze kan meerdere doelen tegelijk dienen, waardoor dit delicate evenwicht mogelijk wordt. Per-sandbox VM's geven elke werklast een eigen kernel, wat de beveiliging versterkt door sterke isolatie, terwijl ze ook de schone checkpoint-grens bieden waarop snapshots vertrouwen. Btrfs maakt de efficiënte implementatie van snapshotting, forking en andere operaties mogelijk die essentieel zijn voor agentische runtimes. De space-daemon houdt alle interactie met de gast op een gecontroleerd host-zijde pad, waardoor de gast-host grens wordt verzegeld terwijl de bewegingsvrijheid van agents behouden blijft. De centrale netwerkgateway medieert egress en inloggegevensinjectie zonder ooit geheimen aan de gast bloot te stellen.

Het resultaat van deze en andere ontwerpbeslissingen is een platform dat echte agent-orkestratie op schaal mogelijk maakt. SPACE biedt het substraat waarop langlopende, stateful agents veilig werk van willekeurige complexiteit of duur kunnen aanpakken, zonder in te boeten op prestaties of beveiliging.

Vandaag drijft SPACE al miljoenen Perplexity Computer-sessies aan. We zijn van plan dat SPACE dient als een verenigde laag voor het provisioneren en controleren van sandboxes in elke omgeving: van Linux microVM's tot Windows-gasten tot de eigen lokale machine van een gebruiker. We werken hard aan het pushen van SPACE naar deze nieuwe instellingen, zodat ontwikkelaars AI-producten kunnen verzenden die overal werken waar gebruikers werken.

Als u staat te popelen om de compute-laag vorm te geven die de frontier-agents van morgen aanstuurt, nodigen we u uit om bij ons team te komen.