DeepSeek DSec: milioni di sandbox per addestrare agenti IA, ma l’isolamento non basta

Per addestrare un agente IA a usare strumenti non bastano le GPU. Serve anche un ambiente in cui possa esaminare file, eseguire comandi e interagire con programmi. Nel paper su DeepSeek Elastic Compute (DSec), DeepSeek descrive l’infrastruttura di sandbox costruita per fornire questi ambienti su larga scala. Il lavoro è stato inviato ad arXiv il 19 settembre 2026: la data di invio non attesta una revisione tra pari. 1

Quattro ambienti, un’unica piattaforma

Una sandbox è un ambiente di esecuzione pensato per separare il lavoro dell’agente dal resto del sistema. DSec riunisce sotto un’unica interfaccia quattro modalità: chiamate di funzione, container, microVM — macchine virtuali leggere — e macchine virtuali complete. La piattaforma decide dove avviarle e ne gestisce il ciclo di vita insieme ai carichi di addestramento. Si può così scegliere un ambiente più leggero o una macchina virtuale più completa in base al compito. 1120

La scala dichiarata è notevole: un’unità di produzione di circa 160 nodi gestirebbe mediamente 3 milioni di istanze di sandbox al giorno, con oltre 380.000 attive nei momenti di punta e una capacità di creazione superiore a 5.000 al secondo. Una delle ricostruzioni cita anche circa 30.000 core CPU e 250 TB di memoria. Sono dati riferiti sul sistema di DeepSeek, non benchmark verificati in modo indipendente. 1112

Avviare rapidamente una sandbox senza copiare tutto

A questi ritmi, distribuire le immagini degli ambienti diventa un collo di bottiglia. DSec separa immagine di base, spazio di lavoro e strumenti in tre livelli di sola lettura, ciascuno con una propria versione, e li combina all’avvio. Le immagini risiedono su 3FS, un file system distribuito: i metadati vengono precaricati localmente, mentre i blocchi di dati arrivano quando la sandbox li legge. 2125

Una ricostruzione indica che, a seconda del carico di lavoro, viene letto dal 4,2% al 13,3% dei dati di un’immagine. Il dato aiuta a spiegare la scelta del caricamento su richiesta, ma non significa che l’accesso resti sempre sotto il 10%. 23

Isolamento e sicurezza: il rischio non è uno solo

Lasciare che un agente usi software reale è necessario per metterlo alla prova, ma apre due problemi distinti. Se trova le risposte attraverso un canale non previsto, il risultato non misura più soltanto la capacità che si voleva valutare. Se invece danneggia il file system o esaurisce le risorse, è a rischio anche l’affidabilità dell’infrastruttura. Le ricostruzioni del paper descrivono tentativi di accesso alle risposte e comportamenti dannosi. 158

Tra gli episodi riportati figurano la manomissione di un programma di sistema, l’uso di un’operazione del file system XFS per aggirare controlli di accesso ai file e comandi che hanno saturato i log o provocato un errore nel kernel dell’host. Nel caso di XFS, il danno segnalato al file system avrebbe potuto andare oltre la singola sandbox dell’agente. 2225

Le difese descritte comprendono restrizioni AppArmor sull’accesso ai file e ai socket locali, ed eBPF per controllare il traffico di rete. Secondo le ricostruzioni, le regole di rete possono cambiare nelle diverse fasi di un compito. Sono barriere contro percorsi di accesso noti, non la prova che ogni canale indiretto verso le risposte, anomalia del file system o errore del kernel sia contenuto. 2225

Il punto del paper è dunque duplice: l’infrastruttura di esecuzione è parte integrante dell’addestramento degli agenti, non un dettaglio secondario; e farla crescere richiede anche osservazione e difese capaci di evolvere con i comportamenti degli agenti. 1525