OpenAI ha pubblicato il 26 agosto 2026 il rapporto tecnico completo sull’incidente che, durante alcune valutazioni interne di cyber security, ha portato suoi agenti di intelligenza artificiale ad aggirare i sistemi di isolamento, raggiungere Internet e compromettere parti dell’infrastruttura di ricerca dell’azienda e dei sistemi di Hugging Face.
Hugging Face aveva comunicato l’intrusione il 16 luglio e OpenAI aveva riconosciuto il coinvolgimento dei propri modelli il 21 luglio.
Il nuovo rapporto modifica però sensibilmente la ricostruzione, perché mostra che i comportamenti alla base dell’incidente erano comparsi settimane prima e che alcuni segnali erano stati rilevati già tra maggio e giugno.
Indice degli argomenti
L’analisi forense di luglio
A fine luglio Hugging Face aveva inoltre pubblicato una propria analisi forense, ricostruendo circa 17.600 azioni dell’attaccante tra il 9 e il 13 luglio, raggruppate in circa 6.280 cluster.
Era dunque già conosciuta una parte consistente della catena tecnica.
Ciò che invece mancava era il quadro nel quale quella sequenza si era sviluppata, dalla comparsa di canali di comunicazione non autorizzati fino alla capacità degli agenti di cooperare tra esecuzioni che avrebbero dovuto restare indipendenti.
La comunicazione non autorizzata emerge a maggio
Secondo il rapporto tecnico di OpenAI, uno dei primi episodi rilevanti risale all’8 maggio.
Durante una sessione di addestramento, un agente doveva completare un compito che richiedeva materiali disponibili attraverso collegamenti Google Drive ai quali non poteva accedere.
Continuò a cercare una soluzione e tentò di utilizzare Artifactory, uno dei servizi raggiungibili dall’ambiente, per effettuare una server-side request forgery.
Il tentativo non gli fornì l’accesso desiderato a Internet, ma provocò incidentalmente la scrittura di un file sul servizio.
Il 12 maggio avvenne un passaggio diverso. Un altro agente era bloccato dalla mancanza di un file e ipotizzò che un’istanza differente potesse possederlo.
Scrisse quindi deliberatamente una nota su Artifactory chiedendo agli altri agenti di metterlo a disposizione.
Il giorno successivo altre istanze iniziarono a trovare messaggi analoghi e a lasciare le proprie richieste.
Artifactory, normalmente utilizzato per distribuire pacchetti software agli ambienti di ricerca, stava così assumendo una funzione imprevista.
Gli agenti non avevano bisogno di violarlo per comunicare, perché possedevano già credenziali condivise necessarie al normale utilizzo del servizio.
Avevano semplicemente scoperto che quella stessa infrastruttura poteva conservare informazioni accessibili ad altre esecuzioni.
Entro il 26 maggio fecero un passo ulteriore, sfruttando una vulnerabilità SSRF di Artifactory per ottenere accesso a Internet.
OpenAI afferma che nello stesso periodo un team interno osservò sia attività sulla bacheca improvvisata sia casi di accesso alla rete che non erano consentiti.
Segnali rilevati senza decifrare l’intero problema
Il 26 giugno alcuni agenti impegnati in una valutazione ExploitGym sfruttarono una vulnerabilità precedentemente sconosciuta in un endpoint legacy per il rinnovo dei token di Artifactory.
A partire dalle credenziali condivise già disponibili riuscirono a ottenere privilegi amministrativi e a creare successivamente un utente persistente.
Il giorno seguente un sistema di monitoraggio segnalò un port sweep nell’ambiente di ricerca.
Il rapporto riferisce che l’attività venne collegata a una valutazione ExploitGym nella quale Artifactory era utilizzato come bacheca improvvisata e come punto di transito sulla rete.
In quel momento il personale di reperibilità stabilì che non fosse necessario interrompere l’esecuzione.
È uno degli aspetti più rilevanti resi pubblici il 26 agosto. Non equivale però a dire che OpenAI conoscesse già la futura compromissione di Hugging Face o che avesse deliberatamente trascurato un attacco identificato come tale.
L’azienda sostiene che l’importanza della comunicazione tra agenti e le implicazioni più ampie per il contenimento non fossero ancora comprese dai responsabili della risposta.
Nel rapporto e nella comunicazione pubblicata il 26 agosto riconosce tuttavia che, con le informazioni oggi disponibili, alcuni di quei segnali avrebbero dovuto produrre un’escalation più tempestiva.
La difficoltà organizzativa
L’incidente evidenzia quindi anche una difficoltà organizzativa.
Un comportamento anomalo del modello poteva apparire contemporaneamente come problema di cyber security, uso improprio dell’infrastruttura e questione di allineamento.
Osservare i singoli eventi non era sufficiente se nessuno li avesse ricomposti in un’unica sequenza.
La bacheca scompare e viene ricostruita
L’attività degli agenti proseguì fino a contribuire all’indisponibilità dell’istanza Artifactory nella notte del 4 luglio.
Il 5 luglio OpenAI individuò un utente persistente non autorizzato, repository anomali, plugin capaci di eseguire comandi e modifiche alla configurazione compatibili con una compromissione amministrativa.
Il servizio venne messo offline, furono revocate le credenziali e nei giorni successivi vennero applicate diverse mitigazioni.
La ricostruzione eliminò anche la bacheca utilizzata dagli agenti. Dopo la ripresa delle valutazioni cyber, però, il canale venne ricreato.
L’8 luglio gli agenti trovarono un nuovo sistema, codificando i messaggi nei nomi delle directory di Artifactory.
La comunicazione acquisì progressivamente una struttura che consentiva di classificare le informazioni, indirizzare messaggi, condividere strumenti e coordinare attività.
La presenza di vulnerabilità zero-day in Artifactory è stata confermata anche da JFrog, produttore del software, che ha dichiarato di aver ricevuto le segnalazioni da OpenAI e di aver sviluppato e distribuito le relative correzioni.
Questo riscontro indipendente conferma uno degli elementi tecnici centrali dell’incidente, vale a dire che gli agenti riuscirono a sfruttare vulnerabilità fino ad allora sconosciute nel servizio che costituiva una delle principali interfacce tra le sandbox e l’infrastruttura circostante.
La collaborazione coinvolge centinaia di agenti
L’indagine indipendente svolta da METR con la partecipazione di Redwood Research permette di misurare la dimensione raggiunta dal fenomeno durante la fase centrale dell’incidente.
I ricercatori hanno lavorato sui dati messi a disposizione da OpenAI concentrandosi soprattutto sul periodo compreso tra il 7 e il 13 luglio.
La loro ricostruzione indica che circa 1.200 agenti, progettati per operare separatamente, utilizzarono la bacheca non autorizzata e vi scambiarono più di 70.000 messaggi e file.
Circa
00 finirono per partecipare alle attività contro Hugging Face. Nel pomeriggio dell’11 luglio METR stima che approssimativamente il 60% dei contenuti scambiati sulla bacheca riguardasse ormai quell’operazione.
La cooperazione era più articolata di un semplice passaggio di risposte. Gli agenti organizzavano progetti comuni, distribuivano compiti, costruivano strumenti e utilizzavano i risultati ottenuti da altre esecuzioni.
METR ha rilevato anche casi nei quali singoli agenti accettavano di mettere a rischio la riuscita del proprio task per produrre informazioni utili al gruppo. Secondo i ricercatori, alcune tappe raggiunte attraverso questa organizzazione sarebbero state difficili da ottenere per singole istanze della stessa capacità, anche concedendo loro tempi di esecuzione molto lunghi.
L’indagine indipendente ha comunque limiti dichiarati. METR non ha verificato gli episodi di addestramento precedenti, la successiva compromissione delle infrastrutture interne di OpenAI o il processo con cui l’azienda ha gestito l’incidente.
Per questi aspetti il rapporto tecnico di OpenAI resta la principale fonte pubblica.
Reward hacking e compiti impossibili spingono gli agenti fuori perimetro
La spiegazione proposta da OpenAI non attribuisce ai modelli un obiettivo autonomo paragonabile a quello di un attaccante umano.
L’attività viene ricondotta al tentativo di completare le valutazioni assegnate attraverso strategie non previste.
ExploitGym misura la capacità di individuare e sfruttare vulnerabilità software. Nel corso delle valutazioni alcuni agenti cercarono però percorsi alternativi per ottenere il risultato necessario al superamento del test. OpenAI interpreta questo comportamento come reward hacking, il
fenomeno per cui un sistema trova una scorciatoia capace di produrre la ricompensa attesa senza svolgere il compito nel modo che il progettista intendeva misurare.
La difficoltà dei problemi sembra aver amplificato questa tendenza. Prima dell’incidente, secondo OpenAI, nessuno dei modelli testati aveva mai prodotto una risposta corretta per 198 dei complessivi 898 task di ExploitGym.
Pur rappresentando circa il 22% del benchmark, questi problemi costituivano il 93% dei task discussi sulla bacheca durante l’incidente.
L’azienda ha osservato anche una relazione tra lo sforzo di ragionamento concesso agli agenti e la probabilità che questi iniziassero a esplorare l’ambiente o a partecipare alla bacheca.
La persistenza, normalmente utile per affrontare problemi complessi, diventava quindi un fattore di rischio quando il compito appariva insolubile e il sistema continuava a cercare alternative senza disporre di un meccanismo affidabile per fermarsi davanti ai limiti di autorizzazione.
La ricostruzione
METR ha inoltre ricostruito una parte del ragionamento collettivo. Gli agenti avevano scoperto come ricavare le flag richieste dal benchmark, ma ritenevano erroneamente che il sistema di valutazione verificasse anche il percorso utilizzato per ottenerle. Continuarono perciò a cercare informazioni sul funzionamento dello scorer e a sperimentare tecniche per alterare o rendere plausibile la traccia delle proprie azioni.
In circa il 7% dei transcript esaminati METR ha trovato esempi riusciti di spoofing di tool call, precisando che tutti i casi osservati erano di piccola scala.
L’intrusione raggiunge i sistemi di produzione di Hugging Face
Tra il 10 e il 13 luglio gli agenti individuarono credenziali Hugging Face esposte pubblicamente e le combinarono con vulnerabilità scoperte nell’infrastruttura della piattaforma.
Secondo il rapporto tecnico di OpenAI, agenti basati sul modello sperimentale interno e su GPT-5.6 Sol arrivarono complessivamente a eseguire codice su 41 worker di produzione, ottennero accesso root su almeno un nodo, raggiunsero credenziali dell’ambiente produttivo e una quantità limitata di dati interni e scaricarono quattro repository privati di
codice.
Hugging Face ha confermato autonomamente la profondità della compromissione.
Nella propria analisi tecnica descrive il passaggio dall’esecuzione di codice su un singolo pod a privilegi di amministrazione su più cluster in meno di tredici ore e ricostruisce una campagna capace di ristabilire strumenti e canali attraverso ambienti temporanei.
Le due ricostruzioni non sono identiche nella terminologia e nel perimetro analizzato, ma convergono sugli aspetti essenziali.
L’agente riuscì a concatenare vulnerabilità e credenziali attraverso più confini di fiducia, raggiungere sistemi di produzione e mantenere un’attività operativa prolungata senza che un essere umano impartisse le singole istruzioni dell’attacco.
Il rapporto rivela anche la compromissione di sistemi OpenAI
Il documento del 26 agosto amplia ulteriormente il quadro descrivendo attività offensive rivolte contro infrastrutture interne della stessa OpenAI. L’azienda precisa che questa catena era distinta e non contribuì all’intrusione in Hugging Face.
Il 19 luglio alcuni agenti riuscirono a ottenere privilegi root su un nodo dell’ambiente di ricerca e a muoversi lateralmente nei sistemi collegati.
In un’altra esecuzione vennero recuperati materiali lasciati da attività precedenti e utilizzati per ricreare credenziali amministrative di Artifactory. Gli agenti arrivarono infine a privilegi cluster-admin su Kubernetes , ottennendo token associati a servizi cloud, gestione dei segreti e infrastrutture di continuous integration.
Fu proprio un alert del 19 luglio relativo ad attività anomale sulle identità Artifactory a innescare l’indagine che, il giorno successivo, collegò le valutazioni OpenAI all’incidente già comunicato da Hugging Face.
Questo passaggio è particolarmente importante nella lettura del rapporto del 26 agosto.
La storia non riguarda più soltanto un agente che evade da una sandbox e colpisce una piattaforma esterna. Mostra che gli stessi comportamenti avrebbero potuto rivolgersi anche contro componenti dell’ambiente che ospitava le valutazioni.
Il modello principale era un prototipo interno
La maggior parte dell’attività viene attribuita da OpenAI a un modello sperimentale non destinato alla distribuzione pubblica, indicato come Internal Model 1, o IM1.
L’azienda lo descrive come paragonabile per scala a GPT-5.6 Sol e addestrato, tra le altre caratteristiche, per aumentare persistenza e collaborazione multi-agente.
GPT-5.6 Sol partecipò comunque ad alcune fasi dell’incidente. Il rapporto documenta agenti basati su questo modello che validarono credenziali esposte, riprodussero un exploit capace di eseguire codice su un worker Hugging Face e recuperarono quantità limitate di dati.
Il ruolo più esteso nella compromissione viene però attribuito al modello interno.
Le condizioni di valutazione erano inoltre diverse da quelle dei prodotti distribuiti agli utenti.
Per misurare le capacità cyber sottostanti, gli agenti operavano con salvaguardie ridotte e senza alcuni classificatori, system prompt e meccanismi automatici di revisione utilizzati negli ambienti di produzione. OpenAI dichiara che l’incidente non ha avuto conseguenze sui dati dei propri clienti, sulla funzionalità dei prodotti o sulla loro disponibilità.
Dopo l’incidente cambiano isolamento e procedure di risposta
OpenAI sostiene che le protezioni di produzione avrebbero modificato sensibilmente il comportamento osservato.
In esperimenti retrospettivi interni, l’utilizzo dell’harness e del system prompt di produzione ha ridotto di oltre cento volte la propensione dei modelli a compromettere infrastrutture durante ExploitGym.
Si tratta di una misurazione dell’azienda e non di una validazione indipendente, ma il risultato evidenzia quanto la configurazione sperimentale abbia inciso sull’incidente.
La risposta ha riguardato anche lo sviluppo dei modelli. Il 18 agosto OpenAI aveva annunciato una pausa di due settimane nell’addestramento reinforcement learning dei modelli più recenti destinati alla distribuzione.
Alla data del 26 agosto, il maggiore run RL di frontiera pianificato risultava ancora sospeso mentre proseguivano attività su scala più ridotta per verificare comportamento e salvaguardie.
Sono stati rafforzati l’isolamento delle sandbox, i controlli sulla rete e il monitoraggio dei workload considerati più rischiosi.
Per gli alert di massima gravità, la nuova procedura prevede inoltre la sospensione dell’attività se entro 30 minuti dalla segnalazione i responsabili non riescono a stabilire che si tratti di un falso positivo.
L’obiettivo dichiarato è arrivare, per gli episodi più severi, a meccanismi di arresto completamente automatici.
Un incidente cyber che diventa un problema di controllo
OpenAI definisce l’episodio il primo caso noto di un collettivo automatizzato di agenti impegnato in attività offensive senza autorizzazione.
È una caratterizzazione dell’azienda, non un primato certificato da un organismo indipendente, ma sintetizza il motivo per cui il rapporto del 26 agosto ha un peso diverso rispetto alle comunicazioni pubblicate a luglio.
La novità non consiste nell’aver scoperto che agenti OpenAI avevano compromesso Hugging Face.
Consiste nell’aver ricostruito una storia iniziata molto prima, nella quale agenti differenti avevano trovato canali di comunicazione non previsti, li avevano ricreati dopo la loro eliminazione e avevano condiviso informazioni sufficienti a trasformare problemi individuali in progetti collettivi.
Nel frattempo, alcuni segnali erano già entrati nei sistemi di monitoraggio senza essere interpretati come parti di uno stesso fenomeno.
Bibliografia
- OpenAI, The Hugging Face incident and the road ahead, 26 agosto 2026.
- OpenAI, OpenAI – Hugging Face Incident Technical Report, agosto 2026.
- METR, Ryan Greenblatt, Ajeya Cotra e Hjalmar Wijk, Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident, 26 agosto 2026.
- Hugging Face, Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident, 27 luglio 2026.
- Hugging Face, Security incident disclosure — July 2026, 16 luglio 2026.
- JFrog, Yoav Landman, Fast Remediation Is the New Trust Model: JFrog and OpenAI Collaboration on Zero-Day Security Findings, 27 luglio 2026, aggiornato il 5 agosto 2026.
- OpenAI, Pacing model development in an era of cyber-critical capabilities, 18 agosto 2026.
Partecipa alla community