Un agente di IA che scrive ed esegue il proprio codice è sicuro solo nella misura in cui lo è l’ambiente in cui tale codice viene eseguito. In un tutorial pubblicato da Machine Learning Mastery, l’autore mostra come isolare questo codice secondo tre livelli: un sottoprocesso limitato, un container Docker rinforzato e una microVM Firecracker, per poi confrontarne sicurezza e latenza.
Il sottoprocesso è il livello più leggero: si tratta di un processo figlio il cui tempo di calcolo, memoria e dimensione dei file sono limitati, ma che condivide il kernel e i file della macchina host. Un container aggiunge namespace e gruppi di controllo (cgroups), ma rimane un insieme di processi sul kernel dell’host. L’articolo ricorda che nel novembre 2025, tre vulnerabilità del motore di esecuzione runc hanno permesso ad aggressori di uscire dai container. Una microVM, invece, fornisce a ogni ambiente il proprio kernel, dietro un hypervisor, il software che fa funzionare le macchine virtuali.
Il dispositivo si basa su un unico strumento, run_python, messo a disposizione dell’agente. Ogni codice prodotto dal modello passa attraverso un oggetto «sandbox» dotato di un metodo run(code), in modo che cambiare livello di isolamento non modifichi l’agente. Il tutorial richiede Python 3.10 o più recente, un sistema Linux o WSL per il livello sottoprocesso, Docker per il container, e un account insieme a una chiave API E2B per la microVM. Una chiave API Anthropic è utile per l’agente, ma può essere evitata per i test.
Sei attacchi identici contro ogni livello
Per confrontare i tre livelli, vengono eseguiti gli stessi sei programmi ostili: un ciclo infinito, un’allocazione di 512 MB di memoria, un «fork flood» di 200 processi, la scrittura di un file da 50 MB, la lettura di un falso file di credenziali e la connessione a un falso servizio interno. Un attacco è considerato bloccato quando la parola-testimone non appare nell’output, o, per il ciclo infinito, quando l’esecuzione scade.
Sul livello sottoprocesso, eseguito con un utente Linux standard, quattro attacchi sono bloccati e due passano. Il limite di processi si applica solo a un utente dedicato, per cui il fork flood è consentito, e il file di false credenziali rimane leggibile perché il codice viene eseguito sotto l’identità dell’utente. L’autore conclude che questo livello è adatto soprattutto per codice di cui ci si fida.
Per il container Docker, l’autore indica che, con le opzioni scelte, Docker dovrebbe bloccare i sei attacchi, poiché il container non ha rete, il suo filesystem non contiene i file dell’utente e si applicano i limiti di memoria, processi e disco. In una microVM, gli attacchi su memoria, processi e disco possono raggiungere i limiti della macchina virtuale, ma rimangono confinati ad essa, e il file segreto come il servizio locale non esistono al suo interno.
Latenza e scelta del livello
Il sottoprocesso dovrebbe essere il più veloce, poiché si limita a lanciare Python. Per gli altri due livelli, l’autore precisa che le cifre pubblicate sono affermazioni e non garanzie: un articolo citato indica che E2B si avvia in circa 150 ms, mentre AWS e Docker descrivono avvii quasi istantanei per i loro prodotti di microVM. Lo script bench.py permette di misurare, sulla propria macchina, la mediana e il tempo più lungo su dieci esecuzioni di un programma print(1).
L’autore raccomanda di riservare il sottoprocesso al codice fidato, come script di sviluppo personali, e il container rinforzato ai casi in cui si controlla l’host e gli interessi sono bassi, prestando attenzione a mantenere runc aggiornato. La microVM si impone per codice proveniente da più utenti, per tutto ciò che riguarda segreti, e quando l’agente deve costruire ed eseguire esso stesso dei container, cosa che i container classici gestiscono male, secondo Docker. Docker ha lanciato le sue Docker Sandboxes su microVM nell’aprile 2026, e AWS offre Lambda MicroVMs che conservano il loro stato fino a 8 ore e si sospendono quando inattive. Secondo Docker, i file, le regole di rete e i segreti devono essere definiti dall’infrastruttura, e non dall’agente, prima della sua esecuzione.
