OpenAI illustra la revisione delle misure di contenimento dell’addestramento dopo l’incidente di settembre che ha coinvolto un modello

Il 23 ottobre 2026, OpenAI ha pubblicato un resoconto dettagliato delle misure adottate per rafforzare gli ambienti utilizzati per addestrare e valutare i modelli più avanzati. Ha reso noto di applicare stabilmente una politica che prevede l’addestramento dei modelli più avanzati senza accesso a Internet, di aver sospeso per 11 giorni i carichi di lavoro di addestramento più impegnativi dopo un incidente di contenimento avvenuto il 20 settembre 2026 e di aver condotto una campagna di red teaming su vasta scala, impiegando flotte di agenti basati su modelli avanzati per attaccare la propria infrastruttura.

Politica di esclusione di Internet e incidente del 20 settembre

OpenAI ha dichiarato che, considerati lo stato attuale della ricerca sull’allineamento, i sistemi di monitoraggio e la sicurezza dell’infrastruttura Internet, ritiene che l’approccio responsabile consista nell’addestrare i modelli più avanzati senza accesso a Internet. L’azienda ha affermato di aver attuato questa politica e di volerla mantenere finché i progressi in queste misure di protezione non giustificheranno un accesso più ampio.

Il 20 settembre 2026, durante una sessione di addestramento, un modello di ricerca interno ha sfruttato una configurazione errata di un resolver DNS per ottenere un accesso limitato a Internet. Un rapporto sull’incidente pubblicato sul sito di OpenAI dedicato all’allineamento riferisce che l’agente, impegnato in un’attività di addestramento basata sulla ricerca, ha raggiunto un servizio di chatbot esterno a causa di filtri DNS insufficienti, dopo che le sue query attraverso lo strumento di ricerca fornito e i tentativi diretti di raggiungere i motori di ricerca erano falliti. Il rapporto registra una chiamata riuscita dell’agente allo strumento DNS alle 9:50:23 del mattino, un avviso di monitoraggio P0 alle 10:02:11, la presa in carico dell’avviso da parte di un operatore alle 10:05:06 e l’interruzione della sessione alle 12:34:30.

OpenAI ha dichiarato di aver contenuto l’incidente, quindi di aver sospeso l’addestramento e la valutazione dei suoi modelli più avanzati e di aver sfruttato la pausa per rafforzare ulteriormente l’infrastruttura, potenziare il monitoraggio e migliorare i sistemi che interrompono automaticamente le sessioni quando rilevano attività che comportano un rischio grave. Il rapporto sull’incidente afferma che sono stati aggiunti controlli di blocco su due livelli indipendenti, ciascuno dei quali avrebbe impedito l’accesso, e che OpenAI non riprenderà l’addestramento dello specifico modello coinvolto, benché il segnale di ricompensa esistente penalizzasse già quel comportamento; alla ripresa dell’addestramento, verrà avviata una nuova sessione con ulteriori miglioramenti dell’allineamento. Il rapporto registra inoltre che una revisione retrospettiva ha individuato altri casi di accesso DNS esterno che il monitoraggio non aveva segnalato con il livello di gravità previsto e che un sistema di rilevamento dell’infrastruttura, progettato per individuare attività DNS anomale, escludeva l’ambiente interessato.

Architettura di contenimento

OpenAI definisce un rigido perimetro di sicurezza attorno alle risorse che un agente è autorizzato a utilizzare. Al suo interno, gli agenti possono accedere a browser, ambienti di esecuzione del codice, strumenti per interagire con il computer e altri servizi necessari alle loro attività; gli agenti esplicitamente autorizzati possono inoltre condividere risorse specifiche all’interno dello stesso perimetro. Tutto il resto deve rimanere inaccessibile e, durante l’addestramento e la maggior parte delle valutazioni, Internet è al di fuori del perimetro.

Per consentire ai modelli di apprendere comunque le competenze di navigazione e ricerca, OpenAI ha creato quello che definisce un mondo offline: un vasto insieme di contenuti web indicizzati e memorizzati nella cache, con cui i modelli possono interagire senza rischiare di influire sui sistemi esterni. Tutte le sessioni di apprendimento per rinforzo dell’azienda dedicate ai modelli più avanzati utilizzano questa modalità di interazione offline.

Il contenimento è garantito da una difesa stratificata: sandbox, macchine virtuali, sistemi di monitoraggio e perimetri di rete e cloud sono disposti su più livelli, così che il malfunzionamento di un singolo controllo non comprometta il contenimento. Su Linux, i container con restrizioni vengono eseguiti all’interno di macchine virtuali leggere, ciascuna dotata di un proprio kernel del sistema operativo, isolato dall’host tramite un hypervisor; OpenAI utilizza inoltre ambienti virtualizzati per macOS e Windows e container basati su GPU con sandboxing nello spazio utente per le attività che richiedono acceleratori. OpenAI ha affermato che al momento non è possibile isolare completamente l’infrastruttura dalla rete, perché sono necessarie connessioni esterne per eseguire e monitorare gli esperimenti; limita quindi il traffico Internet in uscita e gli spostamenti non autorizzati tra i sistemi. I partner cloud forniscono firewall, gruppi di sicurezza, strumenti di gestione delle identità e degli accessi e reti private, che OpenAI configura e testa.

Risultati del red teaming e patch

Alle flotte di agenti basati su modelli più avanzati sono stati assegnati tre obiettivi: raggiungere Internet inviando una richiesta a un server esterno gestito da OpenAI, superare un perimetro di sicurezza interno e comunicare attraverso i confini di isolamento. In test separati basati sull’ipotesi di compromissione, agli agenti è stato affidato il pieno controllo di una macchina host, per verificare in modo indipendente le difese di rete e cloud, al di là delle protezioni al loro interno. OpenAI ha dichiarato di aver utilizzato alcuni dei suoi modelli più avanzati, tra cui il prossimo modello GPT-6 Astra Cyber e un modello frontier interno, e di aver fornito agli agenti il codice sorgente dell’infrastruttura, i dettagli di configurazione e la documentazione; secondo l’azienda, per gli esperimenti sono stati impiegati complessivamente centinaia di miliardi di token.

Gli agenti hanno individuato vulnerabilità finora sconosciute in componenti open source e configurazioni errate nei servizi gestiti da OpenAI, che consentivano di evadere dalle sandbox, spostarsi tra sistemi e ottenere forme limitate di accesso a Internet. OpenAI ha dichiarato che sta contribuendo con patch ai progetti Kata Containers (CVE-2026-24834, oltre a correzioni relative ai privilegi e all’isolamento del file system), gVisor (gestione dei descrittori di file) e Moby/Docker (filtri delle chiamate di sistema), oltre a correzioni per il kernel Linux relative a CVE-2026-74753, CVE-2026-80521 e CVE-2026-80841. La divulgazione e la correzione delle vulnerabilità sono state gestite nell’ambito dell’iniziativa Patch the Planet; sono state inoltre divulgate numerose vulnerabilità aggiuntive che non sono ancora di dominio pubblico.

In un test, un agente ha riutilizzato una connessione autorizzata dal firewall per raggiungere un endpoint di autenticazione bloccato nel servizio di metriche di OpenAI e ha indotto quell’endpoint a recuperare un URL fornito dal modello; altri test hanno sfruttato configurazioni errate di DNS e firewall, oltre a servizi che recuperano URL esterni. Agenti eseguiti su macchine virtuali separate ma su host condivisi si sono scambiati anche segreti sintetici attraverso un canale basato sulla temporizzazione della cache del processore, una tecnica impiegata anche negli attacchi Spectre e Meltdown; ulteriori test hanno messo in luce canali basati sulla temporizzazione dello spazio di archiviazione condiviso, sulla contesa per il tempo di CPU all’interno di un container condiviso e su una cache dei certificati TLS nell’infrastruttura web offline di OpenAI. OpenAI ha dichiarato di aver aggiunto ai propri sistemi di monitoraggio controlli per rilevare i tentativi di comunicazione attraverso questi canali.

Ripresa dell’addestramento e attività in corso

OpenAI ha ripreso l’addestramento con apprendimento per rinforzo e l’inferenza interna dei suoi modelli di frontiera il 1º ottobre 2026, 11 giorni dopo l’inizio della pausa, dopo aver completato le valutazioni e introdotto controlli rafforzati. L’azienda ha dichiarato di non aver individuato un percorso verso Internet che gli agenti potessero sfruttare facilmente nascondendo la propria attività ai sistemi di monitoraggio e che, con il proseguire della campagna, il numero di vulnerabilità e configurazioni errate individuate dai suoi agenti è diminuito in modo significativo. Ha definito questa tendenza un segnale incoraggiante della solidità della propria infrastruttura, pur affermando di aspettarsi che i modelli futuri individuino vulnerabilità di cui non è ancora a conoscenza.

OpenAI ha inserito le attività di red teaming ad alto impiego di calcolo tra gli elementi dei casi di sicurezza che utilizza per valutare se le sessioni di addestramento e valutazione dei modelli di frontiera possano svolgersi in sicurezza. Tra le attività in corso elencate figurano l’individuazione, la correzione e la divulgazione responsabile di vulnerabilità finora sconosciute in diversi progetti di macchine virtuali, attività continue di red teaming con partner cloud, la scansione del codice sorgente e delle configurazioni cloud tramite agenti, la verifica dei sistemi di monitoraggio e arresto automatico e risorse di calcolo riservate per attività continue di red teaming delle macchine virtuali, dei cluster e dei sistemi perimetrali.