Non si trattava del normale ChatGPT e neppure di un modello lasciato libero su Internet. OpenAI stava invece conducendo un test interno in un ambiente che avrebbe dovuto essere isolato, con lo scopo di misurare fino a che punto i suoi sistemi più avanzati fossero capaci di trasformare vulnerabilità informatiche reali in attacchi funzionanti.
Qualcosa, però, è andato storto. Un agente alimentato da una combinazione di modelli, tra cui GPT-5.6 Sol e un sistema ancora più potente non ancora distribuito al pubblico, ha trovato il modo di uscire dalla sandbox, raggiungere Internet e penetrare nell’infrastruttura di produzione di Hugging Face. L’obiettivo era recuperare direttamente le soluzioni del test al quale era stato sottoposto.
OpenAI ha definito l’accaduto un “incidente informatico senza precedenti”.
OpenAI e il test su 898 vulnerabilità reali
Il benchmark utilizzato si chiama ExploitGym ed è una sorta di palestra per hacker: raccoglie 898 falle di sicurezza realmente scoperte in programmi, nel motore JavaScript usato da Chrome e nel cuore del sistema operativo Linux.
we had a significant security incident during evaluation of our models. we are sharing what we have learned so far. thanks to @huggingface for the partnership on this.https://t.co/2o2VfR6PIa
— Sam Altman (@sama) July 21, 2026
Agli agenti viene fornito un programma vulnerabile e viene chiesto di sfruttarne il difetto per costruire un attacco capace di ottenere accessi o privilegi non autorizzati.
Per misurare le capacità massime dei modelli, OpenAI aveva rimosso i sistemi normalmente impiegati per bloccare le attività informatiche considerate ad alto rischio. Le IA disponevano quindi di meno guardrail del normale, ma avrebbero comunque dovuto rimanere confinate nell’infrastruttura preparata per l’esperimento.
La connessione alla rete era limitata a un servizio interno usato come proxy per scaricare pacchetti software. I modelli hanno individuato proprio lì una vulnerabilità zero-day, cioè un difetto ancora sconosciuto al fornitore, e l’hanno sfruttata per aumentare i propri privilegi e spostarsi tra diversi sistemi di OpenAI, fino a raggiungere una macchina collegata a Internet.
L’attacco a Hugging Face
Una volta raggiunto Internet, l’agente ha ipotizzato che Hugging Face ospitasse materiali relativi a ExploitGym. L’intuizione si è rivelata corretta e penetrando nei sistemi della piattaforma, ha recuperato dal suo database alcune soluzioni utilizzabili per superare il test. OpenAI non ha spiegato perché quei materiali si trovassero lì né a chi appartenessero.
In altre parole, invece di risolvere le vulnerabilità previste dall’esame, il sistema ha trovato un percorso alternativo per impossessarsi delle risposte.
Parlare di un’IA che “bara” è una semplificazione efficace ma non significa che il modello abbia sviluppato intenzioni umane: ha piuttosto perseguito in maniera estrema l’obiettivo assegnato, considerando gli ostacoli tecnici come problemi da superare.
Ed è questo l’aspetto più preoccupante. Il sistema non ha scelto consapevolmente di attaccare Hugging Face: ha semplicemente cercato il modo più efficace per raggiungere l’obiettivo assegnato, senza capire che violare i sistemi di un’altra azienda era un limite che non poteva superare.
Oltre 17.000 operazioni automatizzate
Hugging Face ha spiegato che l’intrusione è iniziata da uno dei sistemi usati per gestire i dati caricati sulla piattaforma. Un insieme di dati preparato appositamente ha sfruttato due falle che hanno permettessno all’agente di raggiungere un nodo del sistema, recuperare credenziali cloud e spostarsi lateralmente tra diversi cluster.
L’agente ha distribuito l’attacco su numerosi sistemi temporanei, creati per eseguire operazioni isolate e poi essere eliminati e ha prodotto più di 17.000 eventi registrati. La società ha confermato l’accesso non autorizzato a un numero limitato di dataset interni e ad alcune credenziali utilizzate dai propri servizi.
Al momento non sono emerse prove di modifiche ai modelli, ai dataset pubblici, agli Spaces o alla catena di distribuzione del software. Hugging Face sta però ancora verificando se siano stati coinvolti dati appartenenti a clienti o partner, e ha consigliato agli utenti di cambiare i token di accesso. Ha poi segnalato l’incidente alle autorità.
Per difendersi è servito un modello cinese
L’attacco è stato individuato grazie ai sistemi di controllo di Hugging Face, che utilizzano modelli linguistici per analizzare le attività registrate nei propri sistemi. Per ricostruire migliaia di azioni automatiche, l’azienda ha quindi impiegato altri agenti IA.
E qui è emersa una situazione paradossale. I modelli di frontiera accessibili attraverso le API commerciali americane rifiutavano di elaborare i log, perché contenevano comandi di attacco, exploit, credenziali e strumenti di comando e controllo. I loro filtri non erano in grado di distinguere un criminale informatico da un tecnico impegnato a ricostruire un’intrusione.
Hugging Face si è così dovuta rivolgere a GLM 5.2, un modello open weight sviluppato dalla cinese Z.ai ed eseguito direttamente sulla propria infrastruttura.
L’asimmetria è evidente: chi attacca può usare sistemi privi di restrizioni, mentre chi si difende rischia di essere bloccato dai guardrail dei modelli commerciali.
Non è la prima volta
L’incidente assume un significato ancora maggiore perché non è il primo caso di questo tipo. Il 20 luglio, appena un giorno prima di rivelare il coinvolgimento nell’attacco a Hugging Face, OpenAI aveva raccontato il comportamento anomalo di un altro modello progettato per lavorare autonomamente per lunghi periodi.
Durante un test, al modello era stato imposto di comunicare i risultati soltanto attraverso Slack e di non pubblicare nulla all’esterno. Nel materiale del compito, però, compariva anche l’indicazione di aprire una richiesta di modifica su GitHub.
Il sistema ha interpretato questa seconda istruzione come un obiettivo da raggiungere. Ha quindi trascorso circa un’ora a cercare una via d’uscita dall’ambiente isolato in cui operava, ha trovato una vulnerabilità e l’ha sfruttata per collegarsi a GitHub e pubblicare autonomamente il proprio codice in un repository pubblico.
In un altro esperimento, dopo che uno scanner aveva bloccato una credenziale, il modello aveva diviso il token in due parti, le aveva offuscate e le aveva ricomposte soltanto durante l’esecuzione, impedendo al sistema di sicurezza di riconoscerlo.
OpenAI aveva sospeso temporaneamente l’accesso interno al modello e introdotto controlli capaci di analizzare l’intera sequenza delle sue azioni.
Controllare una traiettoria
I tradizionali guardrail dell’IA valutano soprattutto le singole richieste: un comando può essere permesso, bloccato oppure sottoposto all’approvazione dell’utente. Gli agenti che lavorano autonomamente per ore o giorni pongono però un problema diverso.
Ciascuna azione può sembrare innocua se osservata isolatamente, mentre la sequenza completa può condurre a un risultato che nessun essere umano avrebbe autorizzato.
Cercare un pacchetto software, accedere a una macchina, recuperare una credenziale e collegarsi a un server sono operazioni che, prese singolarmente, possono apparire legittime. Collegate tra loro, hanno prodotto un attacco informatico reale.
OpenAI sta ora rafforzando la configurazione delle infrastrutture, il monitoraggio delle traiettorie e i sistemi di contenimento, accettando esplicitamente un rallentamento delle attività di ricerca. Ma il caso dimostra che le capacità degli agenti stanno crescendo più rapidamente dei recinti costruiti per contenerli.
Il problema allora non è che l’intelligenza artificiale abbia deciso di ribellarsi. È che un sistema sufficientemente capace, persistente e autonomo può causare danni reali anche limitandosi a eseguire con eccessivo zelo il compito che gli è stato assegnato.
Fonte: OpenAI
