Creazione di SPACE: Runtime sicuri ed efficienti per agenti a lungo termine

Man mano che i flussi di lavoro degli agenti diventano più lunghi e autonomi, gli ambienti in cui operano gli agenti di IA contano tanto quanto i modelli che li guidano. Gli agenti devono svolgere un lavoro reale, come eseguire codice, modificare file system ed eseguire attività in più fasi nel corso di ore o giorni. Gli utenti desiderano che gli agenti abbiano accesso agli strumenti e ai file necessari per svolgere tali attività, ma devono anche avere la certezza che i propri sistemi rimangano sicuri anche se gli agenti venissero compromessi. Una sandbox è ciò che rende tutto questo possibile: un ambiente isolato in cui un agente può operare liberamente mentre l'host, altri tenant e le credenziali sensibili rimangono protetti.

I tradizionali approcci sandbox basati su container non sono progettati per queste attività. In genere presuppongono processi di breve durata e senza stato, con il kernel come singolo punto di guasto. Al contrario, le Sessioni degli agenti sono di lunga durata e mantengono uno stato: un agente accumula ore di contesto, un file system di lavoro e processi in esecuzione che non possono essere semplicemente eliminati e ricostruiti da zero. Inoltre, il carico di lavoro interno dovrebbe essere considerato inaffidabile per impostazione predefinita, rendendo necessarie misure di sicurezza più forti. Le Sessioni degli agenti a lunga esecuzione necessitano di un substrato in grado di isolare un guest ostile, preservarne lo stato e continuare a operare su larga scala.

La sfida principale nell'ingegneria delle sandbox deriva dalla tensione che spesso sorge tra sicurezza, funzionalità ed efficienza. Ad esempio:

Concedere un accesso più ampio consente a un agente di ottenere risultati maggiori, ma espone una parte più consistente del sistema a un carico di lavoro di cui non ci si fida.

Condividere di più tra le sandbox rende la creazione più veloce, ma amplia la superficie di attacco.

Effettuare snapshot più frequentemente migliora il ripristino e abilita funzionalità come il rollback, ma richiede tempo e Spazio di archiviazione.

Le sandbox agentiche, come quelle richieste per eseguire codice, utilizzare Agent Skills o svolgere pipeline di Search as Code nelle query di Computer, necessitano di tutte e tre. Negli ultimi mesi abbiamo lavorato duramente per progettare la prossima generazione di infrastrutture per agenti che alimentano i nostri prodotti. Oggi presentiamo SPACE (Sandboxed Platform for Agentic Code Execution): una piattaforma sandbox creata per flussi di lavoro agentici sicura, affidabile ed efficiente su larga scala. Il mese scorso, abbiamo iniziato a implementare SPACE come livello sandbox che alimenta Perplexity Computer. Nell'ultima settimana, ha supportato in modo sicuro milioni di creazioni di sandbox e decine di milioni di riconnessioni, con tempi di avvio da 3 a 5 volte più rapidi rispetto alla nostra soluzione precedente.

Questo articolo presenta le decisioni architettoniche e di progettazione alla base di SPACE. A partire da oggi, il 100% delle Sessioni di Computer viene eseguito su SPACE. Siamo entusiasti di distribuire questa piattaforma su ancora più superfici per fornire ai nostri utenti e sviluppatori un runtime agentico di eccellenza.

Architettura

A livello generale, il sistema è organizzato in tre livelli.

Il piano di controllo è il cervello del sistema e decide cosa deve esistere e dove. È costituito dal gateway API e dai moduli di gestione dello stato a livello di cluster.

I servizi locali ai nodi sono il meccanismo locale necessario per eseguire il piano del piano di controllo. Gestiscono il ciclo di vita della sandbox, lo spazio di archiviazione, la rete e le operazioni privilegiate sottostanti.

La sandbox è l'ambiente di esecuzione isolato stesso. È implementata come una macchina virtuale abbinata al demone space: un processo in background all'interno del guest che gestisce l'accesso al file system, ai processi e alla rete per il carico di lavoro.

Piano di controllo

Il gateway API è il punto di ingresso. Le richieste in entrata vengono autenticate e autorizzate, quindi tradotte in record dello stato desiderato.

Il piano di controllo è progettato per essere senza stato, con tutte le informazioni durevoli scaricate su un database condiviso. Tiene traccia delle informazioni a livello di cluster sulle sandbox, come il nodo a cui sono assegnate, dove sono in esecuzione e se sono state salvate su un'archiviazione durevole. Confronta continuamente lo stato desiderato con quello osservato e guida entrambi verso la convergenza. Le operazioni sono idempotenti, quindi il piano di controllo può ripristinarsi automaticamente dopo qualsiasi arresto anomalo, riavvio o guasto parziale.

Servizi locali ai nodi

I servizi locali ai nodi svolgono il lavoro effettivo di preparazione dei modelli, avvio delle sandbox, collegamento della rete ed esecuzione dei servizi di runtime lato host. Ogni nodo esegue una piccola serie di demoni che gestiscono ogni sandbox posizionata su di esso, e il nodo è la fonte di verità per gli stati live di tali sandbox.

Il gestore della sandbox sa quali sandbox sono in esecuzione, in pausa, sospese o interrotte, insieme alle loro risorse reali. Viene eseguito senza privilegi e delega tutto il lavoro privilegiato al gestore del nodo, l'unico processo root che gestisce le primitive sottostanti. L'archiviazione viene gestita localmente e in modo durevole: gli snapshot degli stati attuali della sandbox vengono salvati sul nodo e un gestore di volumi sposta snapshot e modelli da e verso l'archiviazione a oggetti secondo necessità per abilitare operazioni tra nodi. I gate di sicurezza proteggono ciò che una sandbox può raggiungere: il gestore delle credenziali disciplina l'inserimento delle credenziali in base all'autorizzazione per servizio e il gateway di rete applica la policy di egress di ogni sandbox.

Sandbox

La sandbox stessa è una macchina virtuale (VM) con il proprio kernel guest, che esegue il carico di lavoro dell'utente dietro un confine di isolamento hardware. Poiché ogni sandbox ha il proprio kernel, un carico di lavoro compromesso non può ricadere su un kernel host condiviso come singolo punto di guasto; anche se riuscisse a sfruttare il proprio kernel guest, tale compromissione rimarrebbe confinata entro il confine della VM della sandbox anziché propagarsi ad altri carichi di lavoro.

Un demone space viene eseguito all'interno di ogni macchina virtuale, fungendo da agente leggero che regola ogni azione o modifica che la piattaforma esegue all'interno del guest. Gestisce l'accesso al file system e la gestione dei processi. Segnala inoltre la prontezza del guest e tiene traccia dell'attività, in modo che la piattaforma sappia quando una sandbox è inattiva e può essere messa in pausa o recuperata. Fondamentalmente, il demone space non comunica direttamente con i client, ma comunica con l'host tramite un canale privato interno alla VM. Ciò mantiene tutta l'interazione del guest su un percorso controllato e riserva la rete della sandbox esclusivamente al traffico in uscita del carico di lavoro.

Tre pilastri: Sicurezza, Funzionalità ed Efficienza

Successivamente, esaminiamo le proprietà chiave che SPACE deve fornire attraverso tre pilastri: sicurezza, funzionalità ed efficienza. Come notato in precedenza, questi tre elementi sono in contrapposizione tra loro. Eppure non possiamo scendere a compromessi su nessuno di essi se desideriamo supportare agenti potenti che siano all'altezza delle capacità dei modelli odierni. La sicurezza impedisce a un carico di lavoro inaffidabile, potenzialmente ostile, di danneggiare l'host, altri tenant o i segreti di un utente. La funzionalità offre agli agenti il ricco ciclo di vita di cui hanno bisogno. L'efficienza rende tutto ciò accessibile con memoria, disco e potenza di calcolo finiti.

Sicurezza: Protezione di dati e sistemi

Le piattaforme sandbox necessitano di una forte sicurezza per garantire che il codice errato o addirittura dannoso eseguito all'interno delle sandbox non possa causare effetti dannosi altrove. Senza applicare un rigoroso controllo in uscita e mantenere i segreti fuori dalla sandbox, un singolo passo falso di un agente potrebbe rivelare le chiavi di un utente o esfiltrare il lavoro.

SPACE adotta un approccio a più livelli per garantire la sicurezza delle sandbox. L'isolamento della sandbox ha due componenti: isolamento della VM e isolamento del processo del sistema operativo host. Entrambi devono essere violati per l'accesso tra sandbox. La comunicazione con la sandbox è rigorosamente controllata; i processi possono comunicare solo attraverso canali dedicati. Il gateway di rete forza tutto il traffico in uscita attraverso di esso. Il demone space è l'unico canale autorizzato tra la sandbox (non attendibile) e la piattaforma (attendibile).

Le credenziali non risiedono mai dove un agente può rubarle. L'archivio delle credenziali si trova al di fuori del confine della sandbox ed è responsabile del ciclo di vita delle credenziali. Memorizza e recupera i segreti tramite un backend di vault collegabile, risolve le credenziali utilizzando l'ambito gerarchico, gestisce i metadati come il metodo di iniezione e la scadenza, e applica limiti di velocità e log di controllo su tutti gli accessi. Quando necessario, le credenziali vengono iniettate a livello di rete o compilate automaticamente da un agente del browser, invece di entrare direttamente nella sandbox.

I dati sono protetti in stato di riposo (at rest). SPACE supporta BYOK (Bring Your Own Key) per proteggere i dati archiviati esternamente. Le chiavi di crittografia provengono dal servizio di gestione delle chiavi del cliente e non entrano mai nella sandbox. Se l'azienda revoca la chiave, i suoi dati diventano illeggibili.

Funzionalità: Potenziamento dei flussi di lavoro agentici

Per supportare i flussi di lavoro agentici, le sandbox necessitano di un solido supporto del ciclo di vita. Devono essere create rapidamente e su larga scala, poiché un agente potrebbe avviarne molte contemporaneamente e non dovrebbe attendere l'avvio di nessuna di esse. Devono persistere per una durata indefinita, poiché una Sessione potrebbe durare minuti o essere eseguita per mesi. Devono poter essere messe in pausa correttamente, a volte per lunghi periodi, come quando un'attività è bloccata dall'input umano. E devono supportare il forking, il rollback e il ripristino da arresti anomali, in modo che una Sessione possa ramificarsi, annullare un passo errato o riprendere dopo un guasto anziché ricominciare da capo.

SPACE supporta tutto quanto sopra. Modella l'intero ciclo di vita della sandbox come una macchina a stati esplicita, il che rende possibili operazioni come creazione, pausa, ripresa, sospensione e ripristino.

Gli snapshot sono il meccanismo alla base della maggior parte di queste funzionalità. Uno scheduler opera a intervalli regolari e acquisisce due tipi di snapshot: snapshot del disco (copie point-in-time del file system) e snapshot completi (checkpoint dell'intera VM in pausa). Gli snapshot del disco vengono acquisiti frequentemente, mentre i checkpoint completi sono meno frequenti. Tutto rimane sul nodo e la conservazione decade per livello. Questi snapshot possono essere utilizzati per il ripristino all'interno della Sessione; ad esempio, gli snapshot del disco possono essere utilizzati per riportare il file system indietro per annullare un comando distruttivo e i checkpoint completi consentono a una sandbox in crash di riprendere da un punto di esecuzione recente anziché da un disco freddo.

Quando una sandbox viene sospesa, la VM viene messa in pausa, viene eseguito uno snapshot completo e gli artifact dello snapshot completo vengono caricati nell'archiviazione a oggetti. Una riga del database tiene traccia dello snapshot e diventa ripristinabile solo una volta che ogni artifact è stato salvato, quindi uno snapshot parzialmente caricato non può mai essere ripreso in uno stato corrotto. Il ripristino è l'inverso della sospensione. Poiché lo snapshot risiede nell'archiviazione a oggetti anziché sul nodo originale, qualsiasi nodo può ripristinare la sandbox. Lo scheduler sceglie un nodo, quel nodo scarica gli artifact, riapplica il delta del file system sopra il modello e riprende la VM dal suo stato acquisito.

Efficienza: Ottimizzazione di Tempo e Spazio

Non è sufficiente implementare le funzionalità di cui sopra nel vuoto; devono anche essere possibili entro vincoli di risorse rigorosi. La memoria e il disco su un nodo sono finiti e gli utenti vogliono che gli agenti operino il più rapidamente possibile, quindi le operazioni del ciclo di vita devono essere economiche sia in termini di tempo che di Spazio. Non possiamo permetterci di copiare un'immagine completa della macchina ogni volta che una sandbox viene creata, messa in pausa o ramificata.

Una scelta progettuale chiave rende tutto ciò possibile: il file system. SPACE utilizza btrfs come file system sul nodo per l'archiviazione delle sandbox. Btrfs (B-tree filesystem) combina un file system copy-on-write con una gestione integrata dei volumi logici. Ciò presenta alcuni vantaggi:

Le copie Reflink sono veloci, poiché si condividono gli extent sottostanti, quindi è necessario copiare solo i metadati.

Gli snapshot sono atomici e veloci, poiché basta creare una nuova root.

È necessario uno Spazio di archiviazione minimo, poiché si memorizza solo ciò che è cambiato.

Di conseguenza, le sandbox possono essere create e ripristinate rapidamente. Invece di creare una sandbox da zero ogni volta, manteniamo un pool di pod pronti che hanno già modelli comuni materializzati sul disco e soddisfiamo una richiesta associandola a un pod il cui modello corrisponde già. Dare a quella sandbox il proprio file system root scrivibile è quindi un clone copy-on-write anziché una copia completa. Quando nessun pod pronto è adatto, materializziamo il modello su richiesta; uniamo le richieste simultanee per la stessa immagine in un singolo download, in modo che un'esplosione di richieste identiche non si trasformi in un'esplosione di lavoro identico.

Il risultato è un runtime sandbox che è al contempo potente, leggero e incredibilmente veloce. Quando abbiamo lanciato SPACE, lo abbiamo eseguito insieme al nostro precedente fornitore di sandbox sullo stesso traffico di produzione. Durante la settimana di lancio, SPACE ha creato sandbox da tre a cinque volte più velocemente in tutta la distribuzione. Nello specifico, la latenza di creazione mediana è scesa da 185 millisecondi a 60 millisecondi (miglioramento di 3,1x) e la latenza al 90° percentile è scesa da 447 millisecondi a 89 millisecondi (miglioramento di 5,0x). Abbiamo osservato miglioramenti simili di ordine di grandezza in altri indicatori di prestazioni e utilizzo delle risorse.

Rende inoltre facile acquisire snapshot del disco continui, poiché sono veloci, efficienti in termini di Spazio e non richiedono la messa in pausa della sandbox. Inoltre, l'archiviazione delta efficiente riduce lo Spazio necessario per memorizzare questi snapshot.

Conclusione

Quando si progettano sistemi complessi, è forte la tentazione di scegliere un unico obiettivo da ottimizzare isolatamente. Ma gli sviluppatori di agenti di frontiera richiedono sicurezza, funzionalità ed efficienza in egual misura. Con SPACE, ci siamo prefissati di ottenere un miglioramento di Pareto in tutti e tre i pilastri.

Ogni singola scelta progettuale può servire a molteplici obiettivi contemporaneamente, rendendo possibile questo delicato equilibrio. Le VM per sandbox forniscono a ogni carico di lavoro il proprio kernel, rafforzando la sicurezza attraverso un isolamento forte e fornendo al contempo il pulito confine del checkpoint su cui si basano gli snapshot. Btrfs abilita l'implementazione efficiente di snapshot, forking e altre operazioni essenziali per i runtime agentici. Il demone space mantiene tutta l'interazione del guest su un percorso controllato lato host, sigillando il confine guest-host pur preservando la libertà di manovra degli agenti. Il gateway di rete centrale media l'egress e l'iniezione delle credenziali senza mai esporre segreti al guest.

Il risultato di queste e altre decisioni progettuali è una piattaforma che consente l'orchestrazione di agenti nel mondo reale su larga scala. SPACE fornisce il substrato su cui gli agenti di lunga durata e con stato possono affrontare in modo sicuro lavori di arbitraria complessità o durata, senza sacrificare né le prestazioni né la sicurezza.

Oggi, SPACE alimenta già milioni di Sessioni di Perplexity Computer. Intendiamo far sì che SPACE funga da livello unificato per il provisioning e il controllo delle sandbox in qualsiasi ambiente: dalle microVM Linux ai guest Windows fino alla macchina locale di un utente. Stiamo lavorando sodo per spingere SPACE in questi nuovi ambienti, in modo che gli sviluppatori possano distribuire prodotti IA che funzionino ovunque lavorino gli utenti.

Se non vedi l'ora di dare forma al livello di calcolo che guida gli agenti di frontiera di domani, ti invitiamo a unirti al nostro team.