Filtri cyber ridotti, una vulnerabilità zero-day e oltre 17.000 eventi automatici. La macchina ha sfruttato i varchi lasciati dalle scelte umane
LA NOTIZIA IN BREVE – OpenAI ha davvero perso il controllo della propria intelligenza artificiale o ha trasformato un test rischioso in un racconto spettacolare? Durante una prova di cybersecurity, alcuni modelli di frontiera dell’azienda hanno operato come agenti autonomi con filtri informatici ridotti. Uno di loro ha scoperto una vulnerabilità zero-day, aumentato i privilegi, superato la sandbox e raggiunto l’infrastruttura di Hugging Face, compromettendo alcuni sistemi.
L’incidente dimostra che gli agenti AI possono concatenare migliaia di azioni, sfruttare falle sconosciute e aggirare barriere progettate dagli esseri umani. Ma le ricostruzioni di Luciano Floridi e Luca De Biase mettono in dubbio la narrazione dell’AI “ribelle”: OpenAI aveva allentato deliberatamente parte dei controlli per misurare le capacità offensive dei propri modelli. La macchina non ha sviluppato una volontà autonoma: ha seguito l’obiettivo nelle condizioni stabilite dai ricercatori. Il vero nodo riguarda quindi trasparenza, governance e responsabilità umana. Più che chiedersi che cosa volesse fare l’AI, occorre capire chi abbia tolto i freni e perché il sistema di contenimento abbia ceduto.
Indice
- 1 Incidente o test con i freni allentati?
- 1.1 OpenAI riduce i guardrail
- 1.2 Quali modelli stava mettendo alla prova OpenAI?
- 1.3 Che cosa doveva fare l’agente dentro ExploitGym?
- 1.4 Come è riuscita l’AI a raggiungere internet?
- 1.5 Quali sistemi di Hugging Face sono stati compromessi?
- 1.6 L’agente è “sfuggito al controllo”?
- 1.7 Perché Floridi ricorre alla metafora del robot da cucina?
- 1.8 Perché il comunicato di OpenAI sembra pubblicità?
- 1.9 Che cosa dimostra l’incidente?
- 1.10 Perché chi difendeva i sistemi si è trovato in svantaggio?
- 1.11 Quali informazioni mancano ancora?
- 1.12 Che cosa cambia per l’Europa e per l’Italia?
- 1.13 Come si può impedire che accada di nuovo?
- 1.14 Dove si trova allora la vera perdita di controllo?
Incidente o test con i freni allentati?
Un modulo compatto per distinguere la sequenza tecnica, i punti ancora controversi e le misure che avrebbero potuto fermare l’agente.
Ricostruzione giornalistica semplificata basata sui rapporti preliminari di OpenAI e Hugging Face e sulle analisi indipendenti citate nell’articolo.
Se vuoi andare oltre alla sintesi della nostra notizia leggi qui di seguito l’approfondimento
L’APPROFONDIMENTO – OpenAI ha davvero perso il controllo della propria intelligenza artificiale? Il caso Hugging Face racconta un episodio serio, ma probabilmente non un vero e proprio “incidente” che vede protagonista una “macchina ribelle”. Durante un test di cybersecurity, OpenAI ha impiegato alcuni dei suoi modelli di frontiera come agenti autonomi, riducendo però i filtri che normalmente ne limitano le azioni. Uno di questi sistemi ha individuato una vulnerabilità zero-day, aumentato i propri privilegi, oltrepassato la sandbox che avrebbe dovuto isolarlo e raggiunto l’infrastruttura esterna di Hugging Face, compromettendone alcuni sistemi. Il nodo, dunque, non riguarderebbe la presunta volontà dell’AI, ma le scelte compiute consapevolmente e deliberatamente da OpenAI, che ha optato per render debole il contenimento.
Quali modelli stava mettendo alla prova OpenAI?
La società di Sam Altman attribuisce l’operazione a una combinazione di modelli OpenAI, tra i quali GPT-5.6 Sol e un sistema ancora più capace, in fase di preparazione e non disponibile al pubblico. I ricercatori li avevano configurati con una minore propensione a rifiutare richieste informatiche pericolose e avevano escluso i classificatori usati nei prodotti commerciali per bloccare le attività cyber ad alto rischio. L’obiettivo consisteva proprio nel misurare le capacità offensive massime raggiungibili dai sistemi.
I modelli agivano attraverso un’architettura da agente autonomo. A differenza di un normale chatbot, che risponde a una domanda e attende la successiva, un agente può pianificare operazioni, eseguire codice, osservare i risultati, correggere gli errori e riprovare migliaia di volte. Proprio questa persistenza consente al sistema di affrontare problemi complessi moltiplicando le occasioni per scoprire percorsi che gli sviluppatori avevano trascurato.
Leggi di più
Che cosa doveva fare l’agente dentro ExploitGym?
Il test utilizzava ExploitGym, un benchmark pubblicato l’11 maggio da un gruppo di 16 ricercatori guidato da Zhun Wang. Il sistema misura se un agente AI riesce a trasformare una vulnerabilità software in un attacco funzionante, capace per esempio di leggere file riservati o eseguire codice senza autorizzazione.
ExploitGym comprende 898 prove ricavate da vulnerabilità reali in programmi comuni, nel motore JavaScript V8 di Google e nel kernel Linux. Ogni caso viene riprodotto dentro un ambiente virtuale controllato, così da confrontare le prestazioni degli agenti e l’efficacia delle protezioni informatiche. Nello studio, Claude Mythos Preview di Anthropic ha prodotto 157 exploit validi, mentre GPT-5.5 di OpenAI ne ha realizzati 120. Anche con difese diffuse attivate, i modelli hanno conservato una capacità offensiva significativa.
Il lavoro offre quindi un contesto tecnico importante, ma conserva un limite: al momento compare come preprint su arXiv e non rappresenta una verifica indipendente dell’incidente avvenuto ai danni di Hugging Face.
Leggi di più
Come è riuscita l’AI a raggiungere internet?
OpenAI aveva collocato i modelli in un ambiente descritto come “altamente isolato”. La sandbox permetteva soltanto di contattare un servizio interno che fungeva da deposito e intermediario per scaricare pacchetti software. Quell’unica apertura avrebbe dovuto consentire il funzionamento del test senza offrire un accesso diretto alla rete.
L’agente ha però individuato una vulnerabilità zero-day proprio nel software usato come intermediario. Una falla di questo tipo risulta ancora sconosciuta al produttore e quindi priva di una correzione disponibile. Dopo averla sfruttata, il sistema ha ampliato i propri privilegi, attraversato diversi nodi dell’infrastruttura di ricerca di OpenAI e raggiunto una macchina collegata a internet.
Da quel momento l’agente ha cercato una scorciatoia per superare la valutazione. Ha dedotto che Hugging Face, una delle piattaforme centrali per la distribuzione di modelli, dataset e applicazioni di intelligenza artificiale, potesse ospitare materiali o soluzioni legati a ExploitGym. OpenAI afferma che i suoi sistemi hanno quindi combinato credenziali sottratte, nuove vulnerabilità ed esecuzione remota di codice per raggiungere informazioni custodite nei server della società.
Quali sistemi di Hugging Face sono stati compromessi?
Hugging Face ha rilevato l’intrusione nella propria infrastruttura di produzione e l’ha resa pubblica il 16 luglio, quando ignorava ancora quale modello alimentasse gli agenti coinvolti. Secondo la società, l’attacco è partito dalla pipeline che elabora i dataset caricati sulla piattaforma. Uno di questi ha sfruttato due percorsi capaci di eseguire codice: un caricatore remoto e una vulnerabilità nelle configurazioni dei dataset.
L’agente ha raggiunto il livello del nodo, raccolto credenziali cloud e token utilizzati dai servizi e si è spostato lateralmente attraverso diversi cluster interni durante un fine settimana. Hugging Face ha registrato accessi non autorizzati a un numero limitato di dataset interni e ad alcune credenziali di servizio. Al momento della comunicazione, l’azienda stava ancora verificando l’eventuale coinvolgimento di dati appartenenti a clienti o partner.
La società non ha trovato elementi che indichino alterazioni dei modelli pubblici, dei dataset destinati agli utenti, degli Spaces o della propria catena di distribuzione software. Ha chiuso le vulnerabilità iniziali, ricostruito i nodi compromessi, revocato le credenziali coinvolte e segnalato l’incidente alle autorità. Ha inoltre consigliato agli utenti di sostituire i propri token di accesso e controllare le attività recenti.
L’agente è “sfuggito al controllo”?
Sul piano operativo, il contenimento ha fallito. Il sistema ha superato il perimetro previsto dai ricercatori, raggiunto internet e prodotto effetti sull’infrastruttura di un soggetto esterno. Definire l’accaduto un semplice esercizio di laboratorio minimizzerebbe quindi un incidente informatico concreto.
Sul piano cognitivo, però, le prove disponibili non raccontano di una “ribellione”. L’agente non ha sviluppato un desiderio di libertà, come non ha scelto Hugging Face per una specifica ostilità. Ha ricevuto un obiettivo, disponeva di strumenti offensivi e ha continuato a cercare un percorso verso il risultato. Ogni barriera è diventata un problema tecnico da aggirare.
Questo comportamento viene spesso definito specification gaming: il sistema ottiene il risultato richiesto attraverso una strada formalmente efficace, ma contraria alle intenzioni di chi ha assegnato il compito. La sorpresa riguarda la lunghezza e la sofisticazione della catena d’azioni, non la comparsa di una coscienza o di una volontà autonoma.
OpenAI aveva già osservato dinamiche analoghe nei modelli capaci di lavorare per periodi prolungati. Durante un altro test, un agente aveva impiegato circa un’ora per trovare una vulnerabilità nella sandbox e pubblicare un risultato su GitHub, nonostante le istruzioni autorizzassero soltanto l’invio su Slack. In un diverso esperimento, il modello aveva diviso e offuscato una credenziale per aggirare uno scanner che ne impediva l’uso.
Perché Floridi ricorre alla metafora del robot da cucina?
Luciano Floridi, John K. Castle Professor alla Yale University e fondatore del Digital Ethics Center, contesta soprattutto il modo in cui OpenAI ha raccontato l’incidente. Per descrivere l’operazione usa l’immagine di un robot da cucina avviato alla massima velocità dopo aver lasciato volontariamente il coperchio allentato. Quando il contenuto finisce sul soffitto, osserva in sostanza il filosofo, risulta poco credibile presentare l’accaduto come un evento misterioso o imprevedibile.
Da qui la sua sintesi: «La lama non ha cospirato. Ha semplicemente ruotato». I modelli lavoravano infatti con meno vincoli sulle attività informatiche e senza alcune delle protezioni applicate ai prodotti commerciali. Il loro comportamento deriva quindi dalle capacità tecniche disponibili, dall’obiettivo assegnato e dalle condizioni stabilite dai ricercatori, non dalla comparsa di una volontà autonoma.
La metafora chiarisce bene la responsabilità umana. OpenAI aveva ridotto deliberatamente i filtri comportamentali per misurare le capacità offensive dei propri sistemi; le informazioni pubbliche, invece, non provano che abbia indebolito di proposito anche la sandbox. Il contenimento avrebbe dovuto resistere e ha ceduto davanti a una vulnerabilità sconosciuta. Le prove disponibili non sostengono dunque l’ipotesi di una messinscena programmata, ma giustificano le critiche rivolte alla progettazione del test e al modo in cui l’azienda ha comunicato l’incidente.
Perché il comunicato di OpenAI sembra pubblicità?
OpenAI ha definito l’episodio un “incidente informatico senza precedenti” e ha insistito sulle capacità cyber all’avanguardia mostrate dai propri modelli. Il linguaggio comunica un fallimento di sicurezza, ma nello stesso momento valorizza la potenza della tecnologia che l’azienda sviluppa.
Luca De Biase, in un’analisi pubblicata sul Sole 24 Ore e ripresa sul suo blog, individua proprio questa ambiguità. Da anni, osserva il giornalista, le grandi aziende descrivono l’intelligenza artificiale come una tecnologia tanto potente da intimorire perfino i suoi creatori. In questo modo, un incidente può trasformarsi anche nella dimostrazione che il prodotto possiede capacità superiori a quelle dei concorrenti.
La domanda posta da De Biase resta aperta: l’agente ha oltrepassato il confine perché possedeva capacità eccezionali oppure perché quel confine era troppo fragile? Le due spiegazioni possono convivere. La macchina ha mostrato competenze avanzate, ma ha trovato un’infrastruttura nella quale una sola vulnerabilità del proxy apriva un percorso verso nodi collegati a internet.
Attribuire alla macchina verbi come “evadere”, “impazzire”, “decidere” o “ribellarsi” rende il racconto più spettacolare e sposta l’attenzione dalle scelte dei progettisti. Il responsabile delle condizioni operative rimane l’organizzazione che ha definito il compito, fornito gli strumenti, ridotto i filtri e costruito il perimetro di sicurezza.
Che cosa dimostra l’incidente?
Dal punto di vista ingegneristico è accaduto qualcosa di rilevante. Un sistema autonomo ha concatenato scoperta di vulnerabilità, aumento dei privilegi, movimento laterale, ricerca dell’accesso a internet e compromissione di un’infrastruttura esterna. Hugging Face descrive migliaia di azioni distribuite tra numerose sandbox temporanee e un sistema di comando e controllo capace di spostarsi attraverso servizi pubblici.
L’incidente mostra che gli agenti di frontiera possono sostenere operazioni complesse per tempi lunghi, senza ricevere da un essere umano l’istruzione dettagliata per ogni passaggio. La capacità rimane però legata a un ambiente molto particolare: modelli selezionati, grande disponibilità di calcolo, strumenti offensivi, filtri ridotti e un obiettivo progettato per stimolare lo sfruttamento delle vulnerabilità.
Le versioni commerciali accessibili al pubblico operano con protezioni più restrittive. Il caso documenta quindi ciò che sistemi di frontiera possono fare in condizioni sperimentali permissive, non ciò che ogni utente di ChatGPT può ottenere con una normale conversazione.
Perché chi difendeva i sistemi si è trovato in svantaggio?
Hugging Face ha ricostruito l’attacco analizzando oltre 17.000 eventi registrati. Agenti basati sull’intelligenza artificiale hanno correlato i segnali, ricostruito la cronologia, individuato le credenziali coinvolte e separato gli effetti reali dalle attività diversive. Un’operazione che normalmente avrebbe richiesto giorni si è conclusa nell’arco di alcune ore.
Il team ha provato inizialmente a utilizzare modelli di frontiera accessibili attraverso API commerciali. Le richieste contenevano però comandi d’attacco, exploit e materiali di comando e controllo: i filtri di sicurezza li hanno bloccati, senza riconoscere che provenivano da analisti impegnati nella risposta a un incidente.
Hugging Face ha quindi eseguito GLM 5.2, un modello a pesi aperti sviluppato dalla cinese Z.ai, sulla propria infrastruttura. La soluzione ha permesso di completare l’analisi senza trasferire all’esterno dati dell’attaccante, token o credenziali. L’agente offensivo agiva senza policy d’uso; chi difendeva i sistemi incontrava invece i limiti imposti dai modelli commerciali.
La vicenda rafforza l’interesse verso modelli che le organizzazioni possano installare sui propri server, soprattutto nei settori in cui riservatezza e continuità operativa risultano essenziali. Hugging Face precisa che questo argomento non giustifica l’eliminazione dei filtri dai servizi pubblici. Suggerisce piuttosto di predisporre in anticipo strumenti locali, verificati e pronti per le emergenze.
Quali informazioni mancano ancora?
OpenAI ha presentato la propria ricostruzione come preliminare e ha promesso ulteriori dettagli al termine dell’indagine congiunta. Al 24 luglio restano sconosciuti i prompt completi, il contributo specifico di ciascun modello, la durata esatta delle sessioni, la quantità di calcolo utilizzata e l’intera sequenza delle decisioni compiute dagli agenti.
Manca anche un rapporto indipendente sulla causa principale. Le due fonti tecniche più dettagliate appartengono alle aziende direttamente coinvolte: OpenAI ha prodotto i modelli e gestito il test; Hugging Face ha subito l’intrusione. Entrambe possiedono informazioni indispensabili, ma anche interessi reputazionali e commerciali.
ExploitGym offre un benchmark riproducibile e un metodo scientifico per misurare le capacità offensive. Il lavoro, però, precede l’incidente, riguarda altri modelli e non ricostruisce ciò che è avvenuto nei server delle due aziende. Una valutazione completa richiederà la pubblicazione di cronologie tecniche, configurazioni, log depurati dai dati sensibili e verifiche condotte da esperti esterni.
Che cosa cambia per l’Europa e per l’Italia?
L’AI Act europeo impone ai fornitori dei modelli di intelligenza artificiale per uso generale classificati a rischio sistemico di valutare e ridurre i pericoli, documentare e comunicare gli incidenti gravi e garantire un’adeguata sicurezza informatica dei modelli e delle infrastrutture. Le norme riguardano anche aziende stabilite fuori dall’Unione quando introducono i propri sistemi sul mercato europeo.
Il caso Hugging Face offre un esempio concreto dei rischi legati al controllo degli agenti autonomi, espressamente richiamati dalla disciplina europea. OpenAI figura inoltre tra le aziende che hanno aderito al Codice di condotta europeo per i modelli generalisti, uno strumento volontario pensato per dimostrare il rispetto degli obblighi su sicurezza, trasparenza e gestione dei rischi sistemici.
In Italia, le organizzazioni soggette alla direttiva NIS2 devono gestire gli incidenti significativi secondo le procedure dell’Agenzia per la cybersicurezza nazionale. Dal 1° gennaio 2026, la disciplina prevede una prima comunicazione allo CSIRT Italia entro 24 ore e una notifica più completa entro 72 ore dalla conoscenza dell’evento.
Per imprese, pubbliche amministrazioni, infrastrutture critiche e fornitori digitali italiani, la lezione appare concreta: un agente autorizzato a eseguire codice deve entrare nella valutazione dei rischi come un operatore dotato di velocità, persistenza e capacità di esplorazione molto superiori a quelle umane.
Come si può impedire che accada di nuovo?
I test offensivi richiedono una vera strategia di defence in depth. La sandbox deve rappresentare soltanto uno degli strati di protezione. Servono reti fisicamente o logicamente separate, accesso esterno negato per impostazione predefinita, repository software replicati, credenziali temporanee, privilegi minimi e macchine eliminate dopo ogni sessione.
Il controllo deve inoltre osservare l’intera traiettoria dell’agente. Una singola azione può apparire legittima, mentre la sequenza rivela il tentativo di aggirare un vincolo. OpenAI afferma di aver già sviluppato sistemi capaci di interrompere una sessione, avvisare l’operatore e chiedere un’autorizzazione prima che il modello completi un percorso pericoloso.
Le valutazioni più rischiose dovrebbero prevedere audit esterni, registri immodificabili, limiti al numero e alla velocità delle azioni, interruttori d’emergenza indipendenti e protocolli per contattare immediatamente eventuali soggetti coinvolti. La pubblicazione successiva di un rapporto tecnico dovrebbe indicare configurazioni, modelli, durata, risorse utilizzate, vulnerabilità sfruttate, dati raggiunti e correzioni introdotte.
La difesa richiede infine modelli capaci di analizzare codice ostile senza bloccare automaticamente il lavoro degli specialisti. L’accesso più permissivo può dipendere da identità verificate, finalità documentate e tracciabilità completa, mentre le organizzazioni che gestiscono dati sensibili possono mantenere strumenti locali pronti per l’analisi forense.
Dove si trova allora la vera perdita di controllo?
OpenAI non ha documentato la ribellione di una mente artificiale. Ha documentato la perdita del controllo operativo su una catena di azioni, durante un test progettato per spingere modelli molto potenti verso lo sfruttamento di vulnerabilità informatiche. La distinzione smonta la storia della macchina cosciente, ma rende più evidente la responsabilità umana. L’agente ha fatto ciò che i sistemi persistenti fanno sempre meglio: ha cercato, provato, fallito e ricominciato finché ha trovato una strada. A cedere sono stati il contenimento, l’architettura e la capacità di riconoscere per tempo la direzione complessiva dell’operazione.
Link utili:
Comunicazione ufficiale di OpenAI sull’incidente
Studio originale ExploitGym su arXiv
