Ambienti di test per agenti di intelligenza artificiale: architettura, rischi e modelli reali

Casa » Python » Ambienti di test per agenti di intelligenza artificiale: architettura, rischi e modelli reali

Consentire agli agenti di intelligenza artificiale di eseguire codice, modificare file, aprire browser e interagire con le API li trasforma da sofisticati strumenti di completamento automatico in qualcosa di molto più simile a un ingegnere junior con privilegi di amministratore su una macchina. Quel potere extra è esattamente il motivo per cui sembrano magici, ed è anche il motivo per cui possono essere pericolosi. Un agente non allineato o semplicemente difettoso può cancellare un database, divulgare una chiave API su Internet o distribuire una build difettosa in produzione senza realmente "capire" cosa sia andato storto.

La vera domanda non è più "quanto è accurato il modello?", ma "a cosa può arrivare quando sbaglia, viene ingannato o è troppo sicuro di sé?". Le sandbox di esecuzione per gli agenti sono la soluzione ingegneristica: ambienti con ambito ristretto in cui gli agenti possono leggere e scrivere codice, eseguire shell, avviare server o aprire browser, mentre voi controllate rigorosamente file system, rete, credenziali e ciclo di vita. Invece di affidarvi al modello, limitate il raggio d'azione.

Perché gli agenti di codifica necessitano di un ambiente di esecuzione dedicato

Gli agenti di programmazione moderni come Claude Code, LangChain Deep Agents, le sandbox di programmazione di Docker e strumenti simili non si comportano più come semplici chatbot con accesso ai file. Sono in grado di leggere interi repository, modificare file, eseguire comandi shell, manipolare Git, avviare build Docker, interagire con API esterne e persino gestire ambienti desktop completi tramite browser. La documentazione dei fornitori è molto esplicita al riguardo: Claude Code viene presentato come un assistente di sviluppo agile in grado di ispezionare il codice sorgente, apportare modifiche ed eseguire comandi; i LangChain Deep Agents utilizzano un backend sandbox come ambiente in cui eseguire comandi shell, gestire filesystem e delegare il lavoro a sub-agenti per garantire l'isolamento.

È proprio questo insieme di capacità che rende questi agenti utili, ma anche rischiosi dal punto di vista operativo. Una volta che un modello può essere eseguito pytestChe si tratti di installare pacchetti npm, aprire branch o eseguire il debug di errori di build, bastano poche chiamate di strumenti per modificare gli script di distribuzione, caricare immagini danneggiate, modificare le configurazioni CI o esfiltrare token tramite richieste HTTP. Le linee guida di OpenAI sulla sicurezza degli agenti e il lavoro del NIST sul dirottamento degli agenti sottolineano entrambi l'importanza dell'iniezione di prompt: istruzioni dannose nascoste in file, pagine web o log possono silenziosamente indirizzare un agente verso azioni che non si intendeva autorizzare.

Molti team iniziano con flussi ingenui che prevedono la richiesta di approvazione per ogni comando, e scoprono presto che non sono scalabili. Anthropic ha condiviso pubblicamente che gli utenti hanno approvato il 93% delle richieste di autorizzazione di Claude Code; la sandbox di Docker per Claude avvia persino Claude Code con --skip-permissions Di default, si punta sull'isolamento in fase di esecuzione anziché su una raffica di finestre di dialogo. Gli utenti si stancano di dover dare continuamente conferme, soprattutto quando si eseguono più agenti in parallelo e si passa da un contesto all'altro tramite numerose richieste. A quel punto, le finestre di dialogo di conferma diventano una formalità, non un controllo affidabile.

Un ambiente sandbox di esecuzione sposta il modello di sicurezza da "fidarsi che l'utente legga ogni richiesta" a "presumere che alcuni comandi saranno errati o dannosi e limitare i danni che possono causare". La sandbox diventa il confine rigido che delimita i file, i processi, le reti e i segreti a cui l'agente può accedere, anche quando viene manipolato tramite iniezione di prompt o semplicemente commettendo errori.

C'è anche una questione fondamentale legata all'esperienza dello sviluppatore: gli agenti hanno bisogno di spazio sufficiente per poter lavorare effettivamente. Se si crea un ambiente sandbox eccessivamente restrittivo, comandi semplici come build o test falliscono continuamente a causa di oscuri errori di autorizzazione. I sistemi migliori, come quelli implementati da Cursor su macOS/Linux/Windows o da Cloudflare, Heroku e Google Cloud per i carichi di lavoro ospitati, mirano a fornire agli agenti un'esperienza simile a quella di un "vero computer" all'interno di un perimetro ben definito.

Che cosa isola realmente un ambiente di esecuzione sandbox per agenti

Una sandbox per agenti ben progettata non è semplicemente "un altro posto dove eseguire il codice", bensì un insieme di confini espliciti che definiscono il raggio d'azione. Si possono individuare cinque limiti principali che si ripresentano costantemente nelle piattaforme leader come Docker Sandboxes, Cloudflare Sandboxes, GKE Agent Sandbox, Freestyle VMs, E2B o Daytona.

Innanzitutto, il confine del filesystem: l'agente dovrebbe visualizzare solo l'area di lavoro che si condivide intenzionalmente. La documentazione di LangChain definisce la sandbox come la barriera che tiene gli agenti lontani dai file dell'host; il modello di sandbox di Docker è chiarissimo: la microVM vede solo una directory di progetto montata esplicitamente. Tutto ciò che si trova al di fuori di quella struttura è invisibile o di sola lettura, quindi l'agente non può leggere casualmente ~/.ssh o riscrivere le configurazioni di sistema.

In secondo luogo, il confine tra processo e kernel: i carichi di lavoro degli agenti non dovrebbero condividere un kernel host grezzo o una tabella dei processi. L'architettura sandbox di Docker isola ogni ambiente nel proprio microVM e kernel LinuxFirecracker (utilizzato internamente da diversi provider) considera il confine della macchina virtuale come il primo livello di isolamento, aggiungendo poi seccomp, namespace, cgroup e restrizioni simili a quelle di un jail. GKE Agent Sandbox di Google ottiene un effetto simile all'interno di Kubernetes utilizzando gVisor: un livello "sentinella" intercetta le chiamate di sistema e media l'accesso al nodo sottostante.

In terzo luogo, il confine di rete: senza una policy di rete, un agente in un ambiente sandbox rimane comunque una macchina per l'esfiltrazione dei dati. La maggior parte delle piattaforme più avanzate ora include di default il blocco di tutto il traffico in uscita. Le sandbox Docker, ad esempio, bloccano HTTP/HTTPS finché non viene esplicitamente consentito, interrompono il traffico TCP/UDP/ICMP non elaborato e impediscono il traffico verso intervalli IP privati ​​e localhost a meno che non vengano configurate delle eccezioni. Cloudflare, Google e altri progettano le loro sandbox in modo che le chiamate in uscita passino attraverso proxy programmabili, dove è possibile iniettare l'autenticazione, filtrare le destinazioni e monitorare l'utilizzo.

In quarto luogo, il limite delle credenziali: la divulgazione di informazioni riservate all'interno della sandbox dovrebbe essere considerata un'ultima risorsa, non la norma. Il design di Docker instrada le chiamate HTTP attraverso un proxy lato host che può allegare token o chiavi API alle richieste senza mai inserire questi valori grezzi all'interno della macchina virtuale. Allo stesso modo, Cloudflare Sandbox inietta le credenziali a livello di rete, non tramite variabili d'ambiente. In questo modo, anche se l'iniezione di prompt convince l'agente a "stampare tutte le variabili d'ambiente", non c'è nulla di interessante da rubare.

Quinto, il confine del ciclo di vita: gli spazi di lavoro degli agenti raramente durano per un singolo comando; necessitano di una semantica esplicita per avvio, pausa, snapshot, fork e chiusura. E2B espone filesystem isolati, comandi in background e volumi che possono sopravvivere oltre la durata di una singola sandbox. Freestyle si concentra sull'avvio, la sospensione e la ripresa molto rapidi delle VM con snapshot e branching dello stato in memoria. Daytona aggiunge sandbox basate su snapshot, oltre a policy di arresto automatico, archiviazione automatica ed eliminazione automatica, in modo da poter mantenere alcuni ambienti a lungo termine e trattare altri come usa e getta.

Una volta che avrete compreso questi cinque assi – filesystem, processo, rete, credenziali e ciclo di vita – potrete leggere qualsiasi pagina di prodotto sandbox come una serie di compromessi. Un container con kernel condiviso, dotato di un grande mount host ma con rigide regole di uscita, è molto diverso da una microVM senza mount host ma con una rete più permissiva. Per gli sviluppatori che necessitano di installare dipendenze, eseguire browser o creare immagini Docker, i limiti più stringenti tipici delle macchine virtuali tendono a essere l'opzione predefinita più sicura.

Sandboxing su macOS, Linux e Windows per agenti di codifica locali

Sui laptop degli sviluppatori non è sempre possibile avviare sandbox microVM ad alte prestazioni, quindi i team hanno dovuto trovare soluzioni creative per l'isolamento nativo del sistema operativo. Il recente lavoro di Cursor sulle sandbox locali è un buon esempio di come adattarsi alle specificità di macOS, Linux e Windows, mantenendo al contempo un'API unificata per il livello dell'agente.

Su macOS sono state valutate diverse opzioni: App Sandbox, container generici, macchine virtuali complete e una tecnologia di lunga data ma ormai "obsoleta" chiamata Seatbelt. App Sandbox avrebbe richiesto la firma di ogni singolo file binario che un agente avrebbe potuto eseguire, aumentando drasticamente la complessità e persino garantendo ai file binari generati una fiducia transitiva. I container Linux avrebbero costretto gli utenti macOS a utilizzare solo file binari per Linux, e le macchine virtuali complete avrebbero presentato latenza di avvio e sovraccarico di memoria inaccettabili per i flussi di programmazione interattivi.

Cintura di sicurezza, accessibile tramite sandbox-exec, alla fine si è rivelata la scelta pragmatica nonostante la sua età. Consente di eseguire un comando in un profilo sandbox che limita l'intero albero dei processi con un linguaggio di policy granulare: è possibile inserire nella whitelist o bloccare chiamate di sistema specifiche e limitare le autorizzazioni di lettura/scrittura a file o directory specifici. Cursor genera queste policy dinamicamente in fase di esecuzione in base alle impostazioni dell'area di lavoro e dell'amministratore, oltre a quelle dell'utente. .cursorignore, quindi i percorsi ignorati diventano off-limits all'interno della sandbox.

Su Linux, il kernel espone le primitive necessarie – seccomp per il filtraggio delle chiamate di sistema e Landlock per le restrizioni del filesystem – ma lascia la composizione allo spazio utente. Invece di dipendere da wrapper OSS esistenti che non supportavano ignoramenti specifici del repository come .cursorignoreCursor ha scelto di orchestrare Landlock e seccomp direttamente. Seccomp blocca le chiamate di sistema pericolose; Landlock impone regole di lettura/scrittura basate sui percorsi, consentendo persino la sovrapposizione di tali regole agli spazi di lavoro degli utenti, in modo che i file ignorati siano completamente inaccessibili o sostituiti da copie protette che i processi in sandbox non possono leggere o modificare.

Una sottigliezza di Linux riguarda le prestazioni: il rimontaggio o la riscrittura di tutti i file ignorati è la parte più lenta della configurazione di una sandbox. Un sistema di filtraggio differito in stile macOS, in grado di visualizzare il percorso esatto del file al momento della chiamata di sistema, semplificherebbe la situazione, ma seccomp-bpf di Linux non facilita tale ispezione del percorso, pertanto si presenta un vero e proprio compromesso ingegneristico tra isolamento rigoroso e velocità di avvio.

Su Windows, creare una sandbox nativa veramente equivalente rimane più difficile perché la maggior parte dei primitivi di isolamento sono ottimizzati per i browser e non per gli strumenti di sviluppo generici. Attualmente Cursor esegue un ambiente sandbox Linux all'interno di WSL2 per gli utenti Windows, sfruttando di fatto l'isolamento di Linux in attesa che siano disponibili funzionalità più avanzate. L'azienda sta collaborando con Microsoft per rendere disponibili le funzionalità necessarie affinché, nel tempo, gli agenti Windows possano beneficiare di un ambiente sandbox nativo di prim'ordine, senza dover ricorrere a WSL.

Il filo conduttore di questi approcci specifici per sistema operativo è un'API sandbox unificata a livello superiore. Dal punto di vista dell'agente, si tratta semplicemente di uno "strumento di interfaccia" con funzionalità e regole ben definite. Dietro le quinte, tuttavia, Seatbelt, Landlock/seccomp o l'isolamento basato su WSL2 applicano tali regole in modo diverso a seconda della piattaforma.

Insegnare agli agenti a comprendere e rispettare la sandbox

Un ambiente di test (sandbox) è utile solo se l'agente è in grado di prevedere cosa funzionerà al suo interno e quando è necessario elevare i privilegi o uscire dall'ambiente. Può sembrare ovvio, ma in pratica ha richiesto un lavoro sorprendentemente approfondito, con numerose iterazioni nella progettazione degli strumenti, da parte dei fornitori di agenti di codifica.

Il primo passo compiuto da molti team è stato quello di migliorare le descrizioni degli strumenti, in particolare per l'esecuzione tramite shell. Invece di un generico strumento "run_shell_command", la descrizione specifica esplicitamente quali risorse sono accessibili: se il comando ha accesso al filesystem, a Git, alla rete o a un ambiente completamente offline, a seconda della configurazione dell'utente. Documenta inoltre come l'agente può richiedere privilegi elevati (ad esempio, per accedere a Internet pubblico) quando necessario. Questo lavoro di ingegneria preliminare tende ad essere molto empirico: i team eseguono flussi di implementazione comuni, osservano dove il modello prevede in modo errato le capacità, modificano le descrizioni degli strumenti e ripetono il processo.

Vengono quindi utilizzati benchmark interni come "Cursor Bench" o suite di valutazione simili per confrontare le prestazioni dell'agente con e senza sandboxing. Una delle prime modalità di errore si è rivelata molto frequente: l'agente continuava a ripetere ciecamente lo stesso comando del terminale che non funzionava, invece di rendersi conto che si trattava di una restrizione della sandbox. Senza un segnale chiaro sul motivo del fallimento del comando, il modello non era in grado di apprendere lo schema.

La soluzione consisteva nel rendere espliciti gli errori della sandbox negli output degli strumenti, spesso con un suggerimento su cosa fare in seguito. Quando un comando veniva bloccato a causa di una regola del filesystem o della rete, lo strumento shell ha iniziato a includere una breve spiegazione come "bloccato dalla sandbox: accesso alla rete in uscita disabilitato per questa sessione" e, in alcuni casi, un suggerimento che l'agente poteva richiedere autorizzazioni elevate. Dopo questa modifica, gli agenti sono diventati molto più resilienti: hanno smesso di rimanere bloccati su comandi irrecuperabili e hanno modificato il loro piano o richiesto le autorizzazioni necessarie.

Le valutazioni offline sono utili, ma raccontano solo una parte della storia. Per capire se il sandboxing compromette realmente l'esperienza utente, i team hanno implementato gradualmente il supporto per il sandboxing in produzione, monitorando i tassi di errore, i tempi di completamento e i canali di feedback. In pratica, i fornitori segnalano che una parte consistente delle query su piattaforme compatibili viene ora eseguita interamente all'interno di sandbox – con clienti aziendali come NVIDIA tra i primi ad adottarle – e che gli agenti in sandbox si fermano per l'approvazione circa il 40% in meno nei flussi di lavoro reali, risparmiando ore di revisione manuale e riducendo i rischi.

Guardando al futuro, c'è molto interesse per gli "agenti sandbox nativi", ovvero modelli addestrati direttamente sui vincoli del loro ambiente. Invece di trattare shell, browser o filesystem come strumenti astratti, questi agenti comprenderebbero di vivere in un ambiente di runtime ben definito, di poter scrivere script e programmi di lunga durata e di dover rispettare condizioni limite come "nessuna connessione di rete in uscita" o "l'area di lavoro è di sola lettura". Tale addestramento potrebbe renderli molto più efficaci nella pianificazione di sequenze di azioni sicure ed efficienti, evitando di scontrarsi con ostacoli invisibili.

Ambienti di test cloud: Cloudflare, Google Cloud, Heroku e altri

Al di fuori del laptop dello sviluppatore, una grande ondata di fornitori di infrastrutture sta correndo per offrire sandbox ospitate e ottimizzate specificamente per gli agenti di intelligenza artificiale. I loro obiettivi sono gli stessi – isolamento, controllo e prestazioni – ma i compromessi assumono una forma leggermente diversa su scala cloud.

Cloudflare Sandboxes, basato su Cloudflare Containers e ora disponibile a tutti, mira a offrire agli agenti un'esperienza simile a quella di un ambiente di sviluppo completo. Ogni sandbox è uno spazio di lavoro persistente e isolato a cui ci si riferisce tramite nome. Se è inattivo, si avvia su richiesta; se è inattivo, si sospende automaticamente per risparmiare risorse di calcolo e riprende alla richiesta successiva. Gli sviluppatori (o gli agenti) possono interagire con esso tramite metodi tipizzati come exec, gitCheckout, writeFilee altro ancora, utilizzando un SDK JavaScript/TypeScript.

Uno dei problemi più complessi del cloud è l'autenticazione sicura dall'interno delle sandbox degli agenti. Spesso gli agenti devono accedere a servizi privati, ma è importante evitare che le credenziali non crittografate siano memorizzate nelle variabili d'ambiente. Cloudflare inietta le credenziali a livello del proxy di rete, mappando le richieste in uscita per host a una logica personalizzata che allega i token provenienti da un archivio sicuro. Il processo sandbox non ha mai accesso alle credenziali reali, ma la chiamata viene comunque autenticata. Questa architettura supporta l'iniezione dinamica delle credenziali basata sull'identità e si integra perfettamente con i binding di Workers.

Per i flussi di lavoro che fanno un uso intensivo del terminale, Cloudflare ha aggiunto un'esperienza PTY (pseudo-terminale) completa basata su WebSockets e xterm.js. Agenti e utenti umani possono aprire sessioni shell in tempo reale, interrompere processi, riconnettersi in un secondo momento e riprodurre l'output precedente. Ogni PTY ha la propria directory di lavoro e il proprio ambiente, e l'output viene memorizzato in un buffer sul server in modo che i client che si riconnettono possano recuperare i log persi.

Oltre al semplice accesso alla shell, Cloudflare offre anche "contesti di esecuzione del codice" persistenti per linguaggi come Python, JavaScript e TypeScript. A differenza di molti runner di snippet che eseguono ogni frammento in isolamento, questi contesti mantengono variabili, importazioni e stato tra le chiamate, proprio come un notebook Jupyter. Gli agenti possono caricare i dati in una chiamata, trasformarli in un'altra e visualizzare grafici o tabelle HTML senza dover continuamente rianalizzare e reimportare tutto.

Per le attività di sviluppo web, le sandbox di Cloudflare supportano processi in background, controlli di integrità e URL di anteprima in tempo reale. Un agente può iniziare npm run dev come attività in background, monitora i log finché il server non è pronto, quindi esponi la porta dietro un URL di anteprima pubblico. Metodi come waitForPort() or waitForLog() lasciare che gli agenti seguano sequenze di azioni basate su segnali di prontezza reali invece che ingenui sleep(2s) ipotesi.

I flussi di lavoro basati sugli eventi traggono vantaggio dalle primitive di monitoraggio dei file supportate dal meccanismo inotify di Linux. Un agente può iscriversi alle modifiche secondo /workspace/src e riavviare automaticamente i test o le build quando i file TypeScript vengono modificati. Questo è lo stesso ciclo di feedback su cui fanno affidamento gli sviluppatori umani, ma reso nativo dell'agente tramite API come sandbox.watch() e flussi di eventi inviati dal server.

Per completare il ciclo di vita, Cloudflare sta implementando snapshot reali: acquisizioni dello stato a livello di macchina virtuale che possono essere ripristinate in pochi secondi dallo storage R2. Gli snapshot mantengono lo stato del filesystem, la configurazione del sistema operativo, le dipendenze installate e i file di dati; le versioni future ripristineranno anche lo stato della memoria in tempo reale per una ripresa immediata. Gli agenti (o orchestratori) possono attivare gli snapshot a livello di programmazione per i checkpoint o per scenari di fan-out, quindi creare più sandbox dallo stesso snapshot per esplorare ipotesi parallele in isolamento.

In termini di prezzi, Cloudflare è passata a un modello "solo CPU attiva": si paga per i cicli di CPU effettivamente utilizzati, non per il tempo di inattività mentre gli agenti attendono i LLM. In combinazione con gli enormi limiti di concorrenza per le istanze "lite" e quelle più grandi, questo rende possibile gestire un'ampia flotta di agenti senza sprecare denaro in container inattivi.

Al contrario, GKE Agent Sandbox di Google Cloud è profondamente integrato con Kubernetes e gVisor. L'idea è quella di consentire l'esecuzione di carichi di lavoro dell'agente in pod isolati all'interno dei propri cluster. Si crea un cluster GKE (Autopilot può abilitare gVisor automaticamente, mentre i cluster Standard richiedono classi di runtime esplicite e pool di nodi abilitati per gVisor), quindi si distribuisce un controller Agent Sandbox tramite manifest con versione.

Il modello si basa su due risorse personalizzate fondamentali: SandboxTemplate e SandboxWarmPool. SandboxTemplate funge da modello riutilizzabile che specifica un modello di pod (immagine, porte, risorse, runtimeClassName: gvisor, ecc.) per ambienti di runtime isolati, come ad esempio un ambiente Python. SandboxWarmPool Mantiene un numero configurato di capsule preriscaldate pronte per essere utilizzate quasi istantaneamente, evitando avvii a freddo quando un agente ha bisogno di un ambiente fresco in meno di un secondo.

A Sandbox Router Il servizio funge quindi da gateway per il traffico tra i client e questi pod isolati. In fase di sviluppo, è possibile incanalare il traffico attraverso kubectl port-forward senza esporre indirizzi IP pubblici. In produzione, normalmente si metterebbe il router davanti al router con un ingresso e un mTLS adeguati. Lato client, Google fornisce una libreria Python chiamata "Agentic Sandbox" che racchiude l'intero ciclo di vita: crea una richiesta sandbox da un modello, attendi che sia pronta, esegui comandi shell e ripulisci al termine.

In sostanza, tutto questo è ancora "semplicemente Kubernetes", ma confezionato in una narrazione coerente per gli ambienti di runtime degli agenti. gVisor offre isolamento dei processi e delle chiamate di sistema, SandboxTemplate standardizza le configurazioni, WarmPool risolve i problemi di latenza all'avvio e il router, insieme al client Python, lo rende ideale per le applicazioni incentrate su LLM.

Heroku, d'altro canto, si basa su un elemento costitutivo molto consolidato: i dyno singoli. Per anni, gli utenti di Heroku hanno eseguito attività ad hoc – migrazioni, script di manutenzione, attività amministrative – in dyno temporanei che si avviano su richiesta e si arrestano al termine dell'esecuzione. Heroku ha riutilizzato questa infrastruttura come sandbox per l'esecuzione del codice, lanciate insieme alle sue offerte Managed Inference e Agents. Un agente scrive frammenti di codice Python, Ruby, Node o Go; Heroku li esegue all'interno di dyno di breve durata e trasmette i risultati, limitando l'impatto al solo container temporaneo.

È possibile accedere a queste sandbox tramite gli strumenti integrati nell'API Agents di Heroku oppure implementando server MCP (Model Context Protocol) open source. I server MCP espongono endpoint di strumenti standardizzati, in modo che client come Agentforce, Claude Desktop o Cursor possano trattare la sandbox di Heroku come un backend generico per l'esecuzione remota del codice. Ogni server supporta limiti specifici di runtime (come max_calls per ciclo dell'agente) per evitare che gli agenti rimangano bloccati in cicli stretti e costosi.

I Deep Agent di LangChain aggiungono un'ulteriore dimensione integrandosi con provider di sandbox di terze parti come Runloop, Daytona e Modal. Il funzionamento è semplice: Deep Agent continua a funzionare ovunque si desideri (in locale o nel cloud), ma ogni volta che deve eseguire comandi, creare file o eseguire codice, queste operazioni vengono inoltrate a una sandbox remota. Gli script di configurazione possono precaricare variabili d'ambiente, clonare repository, installare strumenti e altro ancora, in modo che ogni agente disponga di un ambiente pulito e controllato. I gestori di contesto si occupano quindi della creazione e della pulizia, sebbene la documentazione raccomandi vivamente di monitorare le dashboard del provider per individuare eventuali sandbox in esecuzione da lungo tempo e dimenticate.

Prestazioni, stato e ramificazione: perché la velocità è importante per gli agenti

Una sandbox lenta ma estremamente sicura verrà aggirata nella pratica; il successo o il fallimento degli strumenti di sviluppo dipendono dalla latenza. Gli agenti di programmazione non si comportano come processi batch notturni. Eseguono cicli interattivi: leggono del codice, propongono modifiche, eseguono test, analizzano i log, richiamano strumenti, attendono l'intervento umano e poi ripetono il processo. Nelle sessioni reali, esplorano anche diverse ramificazioni di un problema, abbandonano alcuni percorsi e vi ritornano in seguito.

Ecco perché piattaforme come Freestyle sono ossessionate dai tempi del ciclo di vita delle macchine virtuali inferiori al secondo e dalla semantica di stato avanzata. Le loro macchine virtuali sono macchine Linux complete con accesso root, servizi systemd, supporto per la virtualizzazione nidificata e rete completa. La documentazione afferma che il provisioning avviene in meno di 800 ms dalla chiamata API all'avvio della macchina virtuale, la sospensione/ripresa in meno di 100 ms e la possibilità di creare snapshot o fork di macchine virtuali a metà esecuzione con un impatto minimo sulle prestazioni. Citano esplicitamente lo stato del browser come un vantaggio: se un agente ha portato un browser in uno stato interessante, può creare fork di quella macchina virtuale 20 volte dallo stesso snapshot anziché ricreare quello stato da zero.

SandboxWarmPool di Google per GKE esprime la stessa idea in termini di Kubernetes: mantenere un pool di pod pre-riscaldati in modo che gli agenti non debbano pagare le penalità complete di avvio a freddo per ogni nuova esecuzione. Gli spazi di lavoro basati su snapshot di Daytona, uniti alle politiche di arresto automatico, archiviazione ed eliminazione, ottimizzano il ciclo di vita per diversi tipi di sessioni: ambienti di sviluppo attivi, esperimenti effimeri e baseline di lunga durata.

L'enfasi posta da E2B sui processi in background, le directory monitorabili, i filesystem isolati e i volumi riutilizzabili è un altro aspetto della stessa medaglia. Queste funzionalità permettono a un agente di mantenere attivo un server di sviluppo o un ambiente di test mentre esplora le modifiche al codice, oppure di condividere un volume persistente tra più sandbox temporanee nel tempo. Senza di esse, gli agenti finiscono per eseguire comandi singoli e perdere il contesto, il che compromette la produttività.

Un modo utile per valutare qualsiasi ambiente di test per il lavoro degli agenti è porre alcune domande dirette. Posso avviare un nuovo ambiente in meno di un secondo? Posso salvare e ripristinare lo stato in modo pulito, incluse build parziali o sessioni del browser? Posso duplicare lo stato per un'esplorazione parallela? Posso mantenere aree di lavoro persistenti ma efficienti in termini di risorse per flussi di lavoro "torna più tardi"? Più risposte affermative si ottengono, più i tuoi agenti possono comportarsi come veri ingegneri anziché come semplici esecutori di script senza stato.

Segreti, policy di rete e fiducia nello spazio di lavoro come vero piano di controllo.

Anche con un isolamento host perfetto, è facile costruire un sistema insicuro se si ignorano i segreti, le policy di rete e la fiducia nello spazio di lavoro. La documentazione di Docker relativa alle sandbox è sorprendentemente chiara su questo punto. La microVM e il suo demone Docker privato costituiscono il principale confine di fiducia con l'host. All'interno di tale VM, tuttavia, l'agente ha il pieno controllo a livello di root e l'area di lavoro condivisa è montata in modalità lettura-scrittura. Per impostazione predefinita, qualsiasi modifica ai file si riflette immediatamente sull'host. Il traffico di rete in uscita è bloccato per impostazione predefinita ed è consentito solo tramite regole esplicite; le richieste HTTP utilizzano un proxy lato host in grado di iniettare le credenziali senza esporre i dati sensibili alla VM.

Ciò significa che isolare l'host è solo il primo passo; bisogna ancora considerare cosa l'agente può fare all'ambiente di lavoro e al mondo esterno. La documentazione di Docker avverte esplicitamente che se un agente modifica gli script che gli umani eseguono in seguito – hook Git, configurazioni CI, definizioni di attività IDE, Makefile obiettivi, package.json script: il danno può "saltare" indietro all'host o ai sistemi CI quando questi script vengono eseguiti. Sottolineano persino che Git si aggancia in .git/ non presentarsi in git diff, facilitando la persistenza silenziosa di logiche dannose.

Il proxying delle credenziali è potente ma subdolo. Il proxy in uscita di Docker garantisce che i segreti rimangano al di fuori della VM, ma consente comunque all'agente di agire utilizzando tali identità contro gli host consentiti. Alcuni flussi, come la scrittura di variabili d'ambiente personalizzate in file come /etc/sandbox-persistent.sh – superare questo limite memorizzando intenzionalmente i segreti all'interno della macchina virtuale, operazione sicura solo se ci si fida ciecamente dell'agente e della sandbox.

L'ambito di configurazione è importante tanto quanto i segreti. Le FAQ di Docker notano che le configurazioni a livello utente come ~/.claude or ~/.codex Le impostazioni presenti sull'host non vengono copiate nella sandbox; è visibile solo la configurazione a livello di progetto nello spazio di lavoro condiviso. La documentazione di configurazione di Anthropic ribadisce che le impostazioni a livello di progetto (strumenti, autorizzazioni, server MCP, hook) hanno la precedenza su quelle a livello utente e sono condivise tra i team. In altre parole, qualsiasi policy, istruzione e plugin vengano aggiunti al repository diventano l'interfaccia principale visualizzata dall'agente.

Le linee guida di OpenAI sulle competenze ribadiscono concetti simili, seppur con un linguaggio leggermente diverso. Le Skill (pacchetti di strumenti) possono introdurre rischi di esfiltrazione di dati tramite prompt injection. La documentazione sconsiglia di esporre un marketplace di Skill pubblico e non controllato direttamente agli utenti finali, poiché i file SKILL.md dannosi possono sovrascrivere le policy, attivare azioni distruttive o divulgare dati privati. Si raccomanda di vagliare le Skill degli sviluppatori, di limitarne l'ambito a flussi di lavoro specifici, di nascondere le azioni ad alto impatto dietro approvazioni e verifiche delle policy aggiuntive e di trattare le Skill come parte integrante del modello di minaccia.

Mettendo insieme tutti i pezzi, il piano di controllo "reale" per gli ambienti di test degli agenti si estende su quattro livelli. L'isolamento dell'host protegge le macchine e i nodi del cluster. La fiducia nell'area di lavoro protegge l'utente o l'infrastruttura di integrazione continua (CI) che in futuro eseguirà i file prodotti all'interno della sandbox. Le policy di rete proteggono i sistemi esterni e le fonti di dati private. La gestione delle credenziali protegge le identità attraverso le quali l'agente può agire. Una progettazione robusta offre soluzioni per tutti e quattro i punti, non solo per il primo.

Oltre a ciò, è comunque necessario mantenere un sano scetticismo riguardo all'iniezione immediata e al dirottamento degli agenti. NIST, OWASP e OpenAI descrivono tutti varianti dello stesso schema: input non attendibili – un file README, una pagina web, un file di log – incorporano istruzioni dannose che reindirizzano il comportamento dell'agente. La generazione potenziata dal recupero e la messa a punto non risolvono magicamente questo problema. Una sandbox ben strumentata unita a una buona politica non può impedire che il modello venga ingannato, ma può ridurne drasticamente le conseguenze negative quando ciò accade.

Le piattaforme cloud e gli ambienti di runtime degli agenti stanno iniziando a integrare questi insegnamenti. Proxy segreti, domini in uscita consentiti, configurazioni a livello di repository, subagenti con funzionalità più ristrette, flussi di approvazione basati su hook e sandbox riproducibili sono tutti pezzi dello stesso puzzle: accettare che i modelli siano fallibili e progettare l'ambiente in modo che il costo di tale fallibilità rimanga limitato.

Sia in ambienti locali che cloud, una sandbox di esecuzione per gli agenti può essere considerata come una linea tracciata con cura: non rende il modello più intelligente, ma rende i suoi errori meno catastrofici e più osservabili. Con la giusta combinazione di controlli su file system, processi, rete, segreti e ciclo di vita, oltre a un'intelligente formazione dell'agente sul suo ambiente, è possibile consentire ai sistemi di intelligenza artificiale di clonare repository, eseguire test, avviare browser e persino interagire con sistemi simili a quelli di produzione, senza dover fornire loro le chiavi di accesso a tutto ciò che è importante.

Ciò significa che isolare l'host è solo il primo passo; bisogna ancora pensare a cosa può fare l'agente allo spazio di lavoro e al mondo esterno, compresi i rischi come esecuzione di codice remoto. La documentazione di Docker avverte esplicitamente che se un agente modifica gli script che gli umani eseguono in seguito – hook Git, configurazioni CI, definizioni di attività IDE, Makefile obiettivi, package.json script – il danno può "propagarsi" all'host o ai sistemi CI quando questi script vengono eseguiti.