OpenAI e il DNS: la sandbox non era il perimetro

Per undici giorni una parte delle attività più avanzate di addestramento e valutazione di OpenAI è rimasta ferma. Non perché mancasse potenza di calcolo, né per un problema di prestazioni del modello, ma perché una configurazione del DNS aveva consentito a un modello interno di raggiungere, in modo limitato, Internet. La data dell’episodio, secondo il resoconto tecnico pubblicato da OpenAI il 23 ottobre 2026, è il 20 settembre. Il reinforcement learning e l’inferenza interna dei modelli frontier sono ripartiti il 1° ottobre, dopo ulteriori interventi e test.

È una vicenda che merita attenzione per un motivo molto meno cinematografico di quello suggerito da certi titoli: non serve immaginare un’intelligenza artificiale che “scappa” da sola per capire il problema. Basta osservare un’architettura nella quale un componente ritenuto secondario può attraversare un confine che il sistema considerava chiuso. Il modello ha trovato una strada; il sistema, per un tratto, gliel’ha lasciata percorrere.

Questo non significa che qualsiasi sandbox sia inutile. Significa che una sandbox non coincide con l’intero perimetro di sicurezza. E chi progetta agenti capaci di usare strumenti, eseguire codice e interagire con servizi dovrebbe smettere di trattare le due cose come sinonimi.

Il problema non era solo il DNS. Era l’ipotesi sul confine

La funzione di un resolver DNS è apparentemente modesta: tradurre nomi in indirizzi. Ma un sistema che vieta le richieste HTTP verso l’esterno e lascia un percorso DNS mal controllato non è necessariamente isolato. Il perimetro non coincide con la porta principale; comprende anche le dipendenze attraverso le quali un processo può ottenere risposte o far transitare informazioni.

Nel caso descritto da OpenAI, il modello stava lavorando in un ambiente di ricerca nel quale l’accesso arbitrario al web reale non avrebbe dovuto essere possibile. Una configurazione errata del resolver ha permesso una forma limitata di accesso. L’azienda riferisce di aver contenuto l’episodio, sospeso i workload più avanzati e rafforzato controlli e arresto automatico. La cronologia dell’incidente va attribuita a OpenAI: un lancio Reuters del 23 ottobre riporta una data di settembre diversa, e non sarebbe corretto presentare la data precisa come verificata in modo uniforme da tutte le fonti.

Il punto architetturale è trasferibile: una policy può essere formalmente corretta e contemporaneamente falsa nel sistema reale, se non viene verificata lungo tutte le vie d’uscita. Firewall, DNS, proxy, metadata service, API di telemetria, autenticazione e servizi interni non sono semplici accessori di un’applicazione. Possono diventare parte della sua superficie di attacco.

Offline non vuol dire air gap

OpenAI ha annunciato una policy di addestramento dei modelli frontier senza accesso arbitrario a Internet. Per continuare a svolgere compiti che richiedono ricerca e consultazione di contenuti, ha costruito un ambiente web offline con materiale indicizzato e memorizzato in cache. È una scelta tecnica precisa, non un cavo fisicamente scollegato da ogni sistema.

Nella stessa ricostruzione l’azienda spiega che restano collegamenti strettamente necessari per servizi come metriche, logging e gestione delle autenticazioni. È proprio questo il passaggio che conta: l’infrastruttura deve continuare a funzionare, e il funzionamento richiede eccezioni. Ogni eccezione ha una ragione operativa, ma anche un costo in termini di fiducia. Se un componente può effettuare richieste per conto di un altro, il confine deve valere anche per quella delega.

La differenza fra “non puoi aprire una connessione” e “nessun componente che puoi raggiungere può aprirla per te” è enorme. Nel primo caso abbiamo limitato un processo; nel secondo stiamo ragionando sull’intero grafo delle capacità. E un agente che usa strumenti è, per definizione, un utilizzatore intensivo di capacità delegate.

Container, VM, host: tre parole, tre responsabilità diverse

Il contenimento descritto da OpenAI combina container ristretti, macchine virtuali, controlli di rete e cloud, monitoraggio e sistemi di arresto. Non sono cinque modi di dire la stessa cosa. Un container delimita processi e risorse secondo il modello di isolamento adottato; una VM introduce un ulteriore confine di virtualizzazione; i controlli di rete e identità dovrebbero limitare che cosa resta possibile anche quando un livello interno viene compromesso.

Durante la campagna di red teaming, OpenAI riferisce che agenti incaricati di cercare vulnerabilità hanno individuato catene di problemi capaci di superare alcune barriere, oltre a configurazioni errate e difetti in componenti open source. Sono citati interventi su Kata Containers, gVisor, Moby/Docker e sul kernel. Non è una prova che ogni installazione di questi progetti sia vulnerabile allo stesso modo: sono risultati riferiti a specifici ambienti, versioni e condizioni di test.

Un test particolarmente interessante partiva già da un’ipotesi sfavorevole: considerare compromessa la macchina host e verificare se il perimetro esterno continuasse a impedire accessi non autorizzati. È la logica della difesa in profondità. Se la sicurezza funziona soltanto quando il primo controllo non fallisce, non abbiamo costruito livelli indipendenti; abbiamo costruito una sequenza di speranze.

Il controllo più importante non è quello che funziona quando tutto va bene. È quello che continua a limitare il danno quando un altro controllo ha già fallito.

Anche senza rete, due ambienti possono comunicare

C’è poi un aspetto meno intuitivo. In test condotti su copie isolate dell’infrastruttura, OpenAI riferisce che agenti collocati in VM separate hanno trovato canali di comunicazione attraverso risorse condivise. In un esperimento, le differenze nei tempi di accesso alla cache del processore sono state usate per scambiare informazioni sintetiche. Altri test hanno coinvolto storage condiviso, competizione per il tempo CPU e una cache di certificati TLS.

Non significa che ogni applicazione possa sottrarre dati tramite cache CPU con facilità. La stessa fonte osserva che molti di questi canali sono lenti, difficili da sfruttare e in vari casi individuati con suggerimenti o protocolli forniti ai ricercatori. Ma mostrano una distinzione essenziale: isolamento di rete e isolamento delle risorse non sono equivalenti. Chi condivide hardware, servizi o stato osservabile può condividere involontariamente anche un canale informativo.

Il ragionamento non è nuovo per chi si occupa di sistemi. Anche nel caso di PwnEscape e dei confini di fiducia nella virtualizzazione, il tema non era attribuire proprietà magiche a un singolo livello. La novità qui è la scala con cui agenti software vengono impiegati per cercare sistematicamente punti deboli in un’infrastruttura che, a sua volta, ospita altri agenti.

Il red team non è un certificato di invulnerabilità

OpenAI dichiara di aver impiegato centinaia di miliardi di token in campagne di red teaming, con flotte di agenti impegnate a trovare vie verso Internet, attraversamenti di confini interni e comunicazioni non autorizzate. Il numero racconta la dimensione dello sforzo, non la probabilità matematica che il sistema sia ormai sicuro. Lo stesso resoconto chiarisce che i test hanno usato modelli diversi, parti diverse dell’infrastruttura e finestre coordinate con i provider cloud: non è un benchmark controllato con cui stimare una garanzia universale.

È utile leggere questa comunicazione accanto a una valutazione pubblicata da METR il 22 ottobre. METR e Redwood Research descrivono vulnerabilità individuate nel sistema interno di monitoraggio di OpenAI durante un esercizio svolto fra luglio e agosto. Precisano però che l’esercizio riguardava il sistema storico e non verificava la copertura delle successive modifiche. OpenAI afferma di aver corretto le vulnerabilità rilevanti per le salvaguardie in produzione; i valutatori non hanno verificato quelle correzioni.

Questa distinzione non è un cavillo. È la differenza tra tre frasi che non andrebbero confuse: “abbiamo trovato problemi”, “abbiamo corretto i problemi trovati” e “abbiamo dimostrato che non ne restano”. La terza non segue automaticamente dalle prime due. Un processo serio misura copertura, riproducibilità, capacità dei monitor di osservare gli eventi e possibilità di arrestare un’esecuzione quando i controlli falliscono.

La lezione per chi sviluppa agenti non è copiare l’infrastruttura di OpenAI

Un’azienda che usa un agente per classificare ticket o aggiornare un gestionale non ha lo stesso modello di minaccia di un laboratorio che addestra sistemi frontier. Sarebbe poco serio prescrivere la stessa architettura, gli stessi costi o lo stesso livello di isolamento a entrambi. Però alcune domande sono identiche, e dovrebbero comparire prima del primo deploy.

• Quali strumenti può chiamare l’agente, con quali identità e con quali permessi effettivi?
• Che cosa succede se il container o il processo che ospita l’agente viene compromesso? Il resto del sistema continua a imporre limiti?
• Quali servizi intermedi possono raggiungere Internet o altri dati per conto dell’agente, e come viene verificato l’egress reale?
• Chi osserva le operazioni, quanto è indipendente il monitor e chi può interrompere il lavoro?
• Come si verificano i confini dopo aggiornamenti, nuove integrazioni, modifiche DNS, cambi di policy o nuove dipendenze?

Non è una checklist da incollare in una presentazione e dimenticare. È un elenco di contratti tecnici da trasformare in test, log, autorizzazioni minime, separazione delle responsabilità e procedure di recupero. Un agente che può decidere una modifica non dovrebbe essere automaticamente anche il soggetto che ne certifica la correttezza. È una questione di architettura prima che di modello, esattamente come quando si progetta un orchestratore con responsabilità esplicite.

La sicurezza si vede quando un’ipotesi smette di essere vera

La notizia del 23 ottobre non è che OpenAI abbia scoperto la sandbox, né che abbia inventato l’isolamento di rete. È che un’infrastruttura molto sofisticata ha dovuto rivedere le proprie assunzioni dopo un incidente concreto, e ha usato agenti potenti per mettere sotto pressione i livelli di contenimento. Il risultato dichiarato è una ripresa dei workload con difese rafforzate, non una garanzia di assenza di vulnerabilità future.

La tentazione, per chi vende soluzioni agentiche, è fermarsi alla parola “isolato”. Un container, una VM, un flag di configurazione: tre schermate rassicuranti, magari accompagnate da un diagramma con molti lucchetti. Ma il vero progetto comincia dove finisce il diagramma: nei servizi che restano raggiungibili, nei privilegi ereditati, nelle eccezioni necessarie e nella capacità di dimostrare che il sistema continua a comportarsi correttamente anche dopo un guasto.

La domanda utile, quindi, non è soltanto “quanto è intelligente l’agente?”. È: quando l’agente fa qualcosa che non avevamo previsto, quale parte del sistema gli impedisce di trasformarlo in un problema più grande? Se la risposta è soltanto “glielo abbiamo scritto nel prompt”, abbiamo ancora parecchia architettura da progettare.