Perplexity lancia SPACE, il sandbox che fa girare gli agenti AI in sicurezza

Quando si parla di agenti AI l’attenzione finisce quasi sempre sul modello, sulla sua capacità di ragionare, di scrivere codice, di pianificare più passaggi in autonomia. Perplexity ha appena spostato i riflettori altrove, e lo ha fatto con un documento tecnico pubblicato il 15 luglio 2026 sul proprio blog di ricerca. L’azienda ha presentato SPACE, acronimo di Sandboxed Platform for Agentic Code Execution, la piattaforma di ambienti isolati che ora fa girare la totalità delle sessioni di Perplexity Computer. Il messaggio implicito è chiaro: se vuoi che un agente lavori per ore o per giorni sui tuoi file, con le tue credenziali e i tuoi strumenti, il collo di bottiglia non è più solo quanto è intelligente il modello, ma quanto è solido il pavimento su cui lo fai camminare.

Che cosa è SPACE e perché Perplexity ha deciso di costruirlo

Un sandbox è un ambiente isolato in cui un programma può eseguire operazioni senza toccare il sistema che lo ospita. È un concetto vecchio quanto l’informatica moderna, ma gli agenti AI lo hanno rimesso al centro del tavolo per una ragione precisa. Un agente che lavora davvero deve eseguire codice, modificare file, installare pacchetti, navigare in rete, e deve poterlo fare per un tempo lungo. Nel frattempo tu, che quell’agente lo hai avviato, vuoi la garanzia che un errore di ragionamento o un contenuto malevolo incontrato durante il lavoro non si trasformi in una fuga di dati o in un danno al resto del sistema.

Perplexity spiega di aver costruito SPACE negli ultimi mesi e di averlo distribuito progressivamente come strato di isolamento sotto Perplexity Computer, il suo prodotto agentico. Il rilascio è ormai completo: secondo l’azienda il cento per cento delle sessioni di Computer gira su questa infrastruttura, che nell’ultima settimana ha retto milioni di creazioni di sandbox e decine di milioni di riconnessioni. I tempi di avvio, dice sempre Perplexity, risultano da tre a cinque volte più rapidi rispetto alla soluzione precedente.

Il limite dei container tradizionali

La motivazione tecnica dietro il progetto è interessante perché tocca un’assunzione che molti danno per scontata. Gli approcci basati su container, spiega il documento, nascono per carichi di lavoro brevi e senza stato, e condividono il kernel del sistema ospite. Vanno benissimo per far girare una funzione che dura qualche secondo e poi sparisce. Una sessione agentica funziona all’opposto: accumula ore di contesto, si porta dietro un filesystem di lavoro, tiene processi vivi che non puoi semplicemente buttare e ricostruire da zero. In più il carico che ci gira dentro va considerato non affidabile per default, perché l’agente potrebbe essere manipolato da contenuti esterni.

Il kernel condiviso, in questo scenario, diventa un singolo punto di rottura. Se un carico ostile lo compromette, il danno non resta confinato. È esattamente il tipo di rischio che rende nervosa qualsiasi azienda prima di lasciare un agente libero di lavorare sui propri sistemi, e che si intreccia con la questione più ampia della robustezza dei modelli, un tema su cui anche OpenAI sta investendo con strumenti come il red teaming automatico contro la prompt injection.

Come è organizzata l’architettura

SPACE è diviso in tre livelli, e capirne la logica aiuta a intuire dove stia il valore reale del progetto.

Il primo livello è il piano di controllo, che Perplexity descrive come il cervello del sistema. Riceve le richieste attraverso un gateway API che le autentica e le autorizza, poi le traduce in descrizioni dello stato desiderato. La scelta di design più significativa qui è che questo strato è privo di stato: tutte le informazioni durevoli finiscono in un database condiviso. Il piano di controllo confronta continuamente lo stato desiderato con quello osservato e spinge i due a convergere, con operazioni idempotenti che permettono il recupero automatico dopo un crash o un guasto parziale.

Il secondo livello è quello dei servizi locali sul nodo, che fanno il lavoro concreto di preparare i template, avviare i sandbox, configurare la rete. Il dettaglio che merita attenzione è la separazione dei privilegi: il gestore dei sandbox gira senza privilegi elevati e delega ogni operazione sensibile a un gestore di nodo, l’unico processo con permessi di root. Accanto a loro lavorano un gestore dei volumi, che sposta snapshot e template da e verso lo storage a oggetti, un gestore delle credenziali e un gateway di rete che impone a ogni sandbox la propria politica di traffico in uscita.

Il terzo livello è il sandbox vero e proprio, ed è qui che sta la differenza più netta rispetto ai container. Ogni ambiente è una macchina virtuale con il proprio kernel, protetta da un confine di isolamento hardware. Dentro gira un demone chiamato space, un processo leggero che media ogni accesso al filesystem e ogni gestione di processo, segnala quando l’ambiente è pronto e traccia l’attività, così la piattaforma sa quando un sandbox è inattivo e può metterlo in pausa. Questo demone non parla mai direttamente con i client: comunica con l’host su un canale privato interno alla macchina virtuale, lasciando la rete del sandbox esclusivamente al traffico del carico di lavoro.

Sicurezza, funzionalità ed efficienza tirano in direzioni opposte

Il documento è onesto nel riconoscere che questi tre obiettivi sono in tensione fra loro. Dare più accesso a un agente gli permette di fare di più ma espone più superficie. Condividere di più fra sandbox rende la creazione più veloce ma allarga il perimetro di attacco. Fare snapshot più frequenti migliora il recupero ma costa tempo e spazio.

La sicurezza si gioca sulle credenziali

Sul fronte della protezione, l’isolamento ha due componenti che vanno violate entrambe per passare da un sandbox all’altro: quello della macchina virtuale e quello dei processi del sistema ospite. La parte che dovrebbe interessarti di più, se valuti questi strumenti per lavoro, riguarda i segreti. Le credenziali non vivono mai dove un agente potrebbe rubarle: l’archivio sta fuori dal confine del sandbox e le inietta al livello di rete oppure le fa compilare a un agente browser, senza che entrino nell’ambiente di esecuzione. C’è anche il supporto BYOK, cioè la possibilità di usare le proprie chiavi di cifratura, che restano nel sistema di gestione del cliente e non entrano mai nel sandbox. Se l’azienda revoca la chiave, i dati diventano illeggibili.

Il ciclo di vita è una macchina a stati

Perplexity modella l’intero ciclo di vita come una macchina a stati esplicita, e da lì derivano le operazioni di creazione, pausa, ripresa, sospensione e ripristino. Sotto ci sono gli snapshot, di due tipi: copie del filesystem prese di frequente e checkpoint completi della macchina virtuale in pausa, presi più di rado. I primi permettono di annullare un comando distruttivo riportando indietro il filesystem, i secondi consentono a un ambiente andato in crash di riprendere da un punto recente invece che da disco freddo. Quando un sandbox viene sospeso, gli artefatti finiscono nello storage a oggetti e diventano ripristinabili solo quando sono arrivati tutti, così non può mai risorgere in uno stato corrotto. Poiché lo snapshot non è legato al nodo originale, qualsiasi macchina può riportarlo in vita.

L’efficienza arriva dal filesystem

La scelta che rende sostenibile tutto questo è il filesystem btrfs, che unisce copia su scrittura e gestione dei volumi. Le copie condividono i blocchi sottostanti, quindi serve duplicare solo i metadati, gli snapshot sono atomici e veloci, e lo spazio occupato corrisponde soltanto a ciò che è cambiato. A questo si aggiunge un bacino di ambienti già caldi con i template più comuni già presenti su disco, così una richiesta viene soddisfatta agganciandola a uno di questi invece di costruire tutto da zero.

I numeri che Perplexity riporta dal confronto in produzione con la soluzione precedente sono concreti: la latenza mediana di creazione è scesa da 185 a 60 millisecondi, un miglioramento di 3,1 volte, mentre il novantesimo percentile è passato da 447 a 89 millisecondi, cinque volte meglio. Sono cifre che contano quando un agente deve aprire molti ambienti in parallelo e tu non vuoi aspettare che ognuno faccia il boot.

Perché questa notizia riguarda anche te

C’è una tendenza che si sta consolidando in tutto il settore: il valore si sposta dal modello all’infrastruttura che lo circonda. Perplexity aveva già mostrato la sua ambizione agentica con il browser Comet, e la stessa direzione si legge nella scelta di OpenAI di portare il lavoro agentico dentro ChatGPT invece di tenerlo in un’applicazione separata. In entrambi i casi la promessa è che l’agente faccia cose reali sui tuoi dati, e quella promessa regge solo se lo strato di esecuzione è affidabile.

Se stai valutando di introdurre agenti nei tuoi flussi di lavoro, il documento di Perplexity offre una griglia di domande utili da porre a qualsiasi fornitore, indipendentemente dal marchio. Dove vivono le credenziali quando l’agente lavora? L’isolamento si ferma al container o arriva alla macchina virtuale? Esiste un modo per annullare un’operazione distruttiva? Il traffico in uscita è filtrato o l’ambiente può contattare qualsiasi indirizzo? Sono domande poco appariscenti rispetto ai benchmark dei modelli, ma sono quelle che determinano se puoi davvero lasciare un agente lavorare senza supervisione continua. Se il tema ti è nuovo, la nostra guida su come funzionano gli agenti AI autonomi ti dà il contesto di partenza.

Cosa aspettarsi nei prossimi mesi

Perplexity dichiara di voler estendere SPACE oltre il proprio prodotto, immaginandolo come strato unificato per gestire ambienti isolati in contesti diversi, dalle microVM Linux agli ospiti Windows fino alla macchina locale dell’utente. È un’ambizione che, se realizzata, metterebbe l’azienda in competizione non solo con gli altri laboratori AI ma anche con i fornitori di infrastruttura cloud. Vale la pena ricordare che tutti i numeri citati provengono dall’azienda stessa e non sono ancora stati verificati da terze parti indipendenti, quindi conviene leggerli come dichiarazioni di prodotto più che come misure neutrali.

Resta il punto di fondo, ed è quello che ti conviene portare a casa. La corsa agli agenti autonomi si deciderà tanto sulla qualità dei modelli quanto sulla robustezza degli ambienti in cui li lasci operare, e chi costruisce quel pavimento sta accumulando un vantaggio poco visibile ma difficile da recuperare. Se lavori con strumenti agentici, inizia a chiedere ai tuoi fornitori come gestiscono isolamento e credenziali, e continua a seguirci per capire come questa parte meno raccontata dell’intelligenza artificiale sta cambiando il modo in cui lavoriamo.

Fonte primaria: Making SPACE: Secure and Efficient Runtimes for Long-Running Agents, Perplexity Research, 15 luglio 2026.