Quando un agente AI smette di suggerire e inizia a eseguire — aprire file, lanciare comandi, chiamare API, scrivere su un server — la domanda di sicurezza cambia natura. Non è più «il modello dirà qualcosa di sbagliato?», ma «cosa può toccare mentre lavora?». Un sandbox per agenti AI risponde esattamente a questa seconda domanda: non rende il modello più prudente, delimita la macchina su cui gira. È una distinzione che in azienda separa un incidente contenuto da un incidente che si propaga.
Il tema è diventato concreto perché gli agenti lavorano sempre più spesso senza qualcuno che guardi lo schermo. Finché ogni azione passa da una conferma umana il confine lo mette la persona; quando le conferme spariscono — e spariscono, perché nessuno approva quaranta comandi al giorno — il confine deve stare nel sistema operativo.
Il sandbox non corregge il modello, limita la macchina
Conviene tenere separati due meccanismi che vengono spesso confusi. I permessi decidono se un'azione parte. L'isolamento decide cosa quell'azione può raggiungere una volta partita. La documentazione di Claude Code lo dice in una riga: i permessi stabiliscono se una chiamata a uno strumento viene eseguita, l'isolamento limita a cosa quel comando può accedere quando è già in esecuzione.
Servono entrambi. Un permesso scritto male si aggira con una richiesta formulata in modo creativo. Un confine di sistema operativo invece non si negozia: il processo prova a scrivere fuori dalla cartella consentita e il kernel dice no, a prescindere da cosa il modello pensava di fare. Su come si scrivono i permessi abbiamo già dedicato un pezzo: autonomia degli agenti AI, quali permessi dare e dove fermarli.
C'è poi un effetto collaterale utile, ed è la ragione pratica per cui conviene installarlo. Anthropic riferisce che internamente il sandboxing ha ridotto dell'84% le richieste di autorizzazione: se il confine è già definito, l'agente non deve chiedere il permesso per ogni comando. Meno finestre di conferma non significa meno controllo, significa averlo spostato dove viene davvero applicato.
Due confini, non uno: i file e la rete
Un sandbox fatto a metà non è un mezzo sandbox: spesso non è un sandbox. La regola che gli ingegneri di Anthropic mettono in evidenza è che servono entrambi gli isolamenti, quello del filesystem e quello della rete. Senza isolamento di rete un agente compromesso può esfiltrare file sensibili come le chiavi SSH; senza isolamento del filesystem può scrivere dove serve per riguadagnare l'accesso alla rete e uscire dal recinto.
In pratica: sul filesystem l'agente legge e scrive solo nelle directory che hai elencato, e il resto del disco per lui non esiste. Sulla rete il traffico non esce diretto, ma passa da un proxy che sta fuori dal sandbox e applica una lista di domini. L'agente raggiunge l'API del tuo gestionale e il repository di codice, nient'altro.
Tradotto in termini aziendali: se l'agente che ti gestisce i preventivi viene manipolato da un documento avvelenato — lo scenario classico della prompt injection — il danno massimo è quello che sta dentro quelle due liste. Non i backup, non le credenziali del CRM, non un indirizzo esterno a cui spedire l'archivio clienti.
Il confine non è uno solo: si sceglie quanto stretto in base a quanto ti fidi del codice e dei dati che l'agente tocca.
Perché un container non è un muro
Qui cade l'illusione più diffusa: «lo mettiamo in un container Docker, così è isolato». I container condividono il kernel dell'host — è esattamente il problema che progetti come gVisor risolvono interponendo un kernel in spazio utente. Kernel condiviso significa che una configurazione sbagliata diventa una via d'uscita.
Non è più un'ipotesi teorica. Alcuni ricercatori hanno pubblicato SandboxEscapeBench, un banco di prova aperto che misura quanto un modello linguistico riesce a evadere da un container: 18 prove su tre livelli — orchestrazione, motore di esecuzione, kernel e host — a difficoltà crescente. I risultati sono netti: sulle configurazioni sbagliate più comuni i modelli di punta evadono in circa l'85% dei casi, sulle vulnerabilità specifiche la percentuale scende intorno al 40%, sugli exploit complessi del kernel nessun successo.
Due dettagli contano. La distanza tra modelli di fascia alta e leggera è enorme (0,49 contro 0,18 di successo complessivo), quindi la robustezza di un recinto va ricalibrata ogni volta che cambia il modello sotto. E i risultati crescono in modo log-lineare con il budget di calcolo: tentare molte evasioni costa poco. La conclusione degli autori è la frase da portare via: trattare l'isolamento Docker semplice come insufficiente per impostazione predefinita.
I limiti che quasi nessuno legge
La documentazione ufficiale è onesta su un punto che i fornitori di solito tacciono: l'isolamento riduce l'impatto di una violazione, non elimina il rischio. I punti dove il recinto si assottiglia sono quasi tutti auto-inflitti.
- Domini troppo larghi. Il proxy decide in base al nome host dichiarato dal client e di default non ispeziona il traffico cifrato: consentire un grande servizio di hosting di codice apre di fatto una via di esfiltrazione.
- Socket di sistema concessi con leggerezza. Dare accesso al socket del demone Docker equivale a dare accesso all'host: il recinto c'è ancora, ma con un cancello aperto.
- Scrittura nei posti sbagliati. Concedere la scrittura su directory di eseguibili o sui file di avvio della shell fa eseguire codice più tardi, in un altro contesto, da un altro processo.
- Variabili d'ambiente. I comandi eseguiti nel sandbox ereditano l'ambiente del processo padre, credenziali comprese, se non le si rimuove esplicitamente.
- Quello che resta fuori. Un sandbox che copre solo i comandi di shell lascia liberi sull'host i server di integrazione e gli script agganciati agli eventi.
Tutti e cinque i punti hanno la stessa forma: il confine è stato allargato per far funzionare qualcosa in fretta e nessuno è tornato a stringerlo. Infatti la manutenzione del recinto è parte del costo dell'automazione, non un'attività straordinaria.
Come si sceglie il livello di isolamento
Non esiste un solo sandbox per agenti AI: esiste una scala, e il punto giusto dipende da quanto ti fidi del codice e dei dati con cui l'agente lavora. Dal più leggero al più severo:
- Sandbox per singolo comando — primitive del sistema operativo applicate ai comandi di shell e ai loro processi figli. Sforzo minimo, buono per il lavoro quotidiano presidiato.
- Runtime che avvolge l'intero processo — stesso meccanismo esteso a tutta la sessione: strumenti interni, integrazioni e script inclusi.
- Container di sviluppo o container su misura — ambiente completo con regole di rete proprie, la strada tipica di chi ha già un'infrastruttura a container.
- Macchina virtuale o microVM — kernel separato, la separazione più forte. Da usare su codice non fidato o quando la policy aziendale lo impone.
La regola operativa è una sola: se togli le conferme umane, devi mettere un confine di ambiente. Un agente non presidiato dentro il solo sandbox dei comandi non è protetto abbastanza, perché il resto della sessione resta scoperto. Tuttavia vale anche il contrario: una macchina virtuale con dentro un agente che ha le credenziali di produzione e l'accesso a tutta la rete non isola niente di utile.
Da dove parte una PMI
Tre passi concreti, in ordine.
Uno: scrivi cosa può toccare, prima di dargli autonomia. Due elenchi su mezza pagina, le cartelle e i domini. Se non riesci a scriverli, l'automazione non è ancora abbastanza definita per girare da sola.
Due: nessuna esecuzione non presidiata fuori da un confine di ambiente. Il momento in cui rimuovi le conferme è lo stesso in cui metti il container o la macchina dedicata: le due decisioni vanno prese insieme.
Tre: credenziali dedicate, non le tue. Un'utenza per l'automazione, con i soli permessi che servono e una scadenza: quando qualcosa va storto revochi una chiave invece di cambiare le password di tutta l'azienda. Aggiungi un registro delle azioni leggibile: il sandbox contiene il danno, il registro ti dice cosa è successo.
Noi progettiamo gli agenti partendo da questi due elenchi, non dal modello: è la parte meno affascinante del lavoro ed è quella che decide se un'automazione può restare accesa quando nessuno la guarda. Studiollice progetta agenti e automazioni su misura, confini compresi.