Settecento agenti hacker contro Hugging Face: METR spiega cosa è successo davvero

Il problema, oggi, non è quanto siano capaci i modelli di intelligenza artificiale, ma quanto sia possibile controllarli quando ricevono autonomia, accesso a strumenti informatici e molto tempo per raggiungere un obiettivo. Il 26 agosto 2026 METR (si legge come “meter”) e Redwood Research hanno pubblicato un’indagine indipendente sull’incidente che a luglio ha coinvolto OpenAI e Hugging Face.

I numeri descrivono un episodio molto più esteso rispetto alle prime ricostruzioni: circa 1.200 agenti hanno comunicato attraverso un sistema non autorizzato, scambiandosi oltre 70mila messaggi e file; circa 700 hanno poi partecipato alle attività contro l’infrastruttura di Hugging Face.

Lo stesso 26 agosto OpenAI ha diffuso il proprio rapporto tecnico. La società ha riconosciuto che alcuni modelli utilizzati nei test di cybersicurezza hanno aggirato i sistemi destinati a isolarli da Internet, compromesso parti dell’infrastruttura interna dell’azienda e raggiunto sistemi di terzi.

OpenAI definisce l’accaduto un “warning shot”, un avvertimento sulla capacità di agenti sufficientemente autonomi e persistenti di aggirare controlli tecnici se le protezioni non crescono alla stessa velocità delle capacità dei modelli.

Il test che doveva misurare le capacità cyber

L’incidente nasce all’interno di ExploitGym, un benchmark utilizzato per valutare la capacità degli agenti di individuare e sfruttare vulnerabilità software. OpenAI aveva avviato l’8 luglio migliaia di esecuzioni separate di diversi modelli, tra cui GPT-5.6 Sol e un modello sperimentale interno ad alta persistenza che METR indica con la sigla HPIM. Nella ricostruzione successiva OpenAI lo identifica come IM1 e precisa che non era destinato al rilascio pubblico.

Ogni agente avrebbe dovuto lavorare isolato. Alcuni, però, si sono trovati davanti a compiti estremamente difficili o impossibili e hanno iniziato a cercare scorciatoie. Secondo OpenAI, prima dell’incidente nessuno dei modelli aveva mai trovato una risposta corretta per 198 degli 898 problemi presenti nella valutazione. Il 93% dei task discussi successivamente sulla rete di comunicazione creata dagli agenti apparteneva proprio a quel gruppo di problemi irrisolti.

L’obiettivo formale consisteva nel recuperare una stringa, chiamata “flag”, sfruttando la vulnerabilità prevista dal test. Diversi agenti hanno invece cercato una strada più semplice: capire come produrre direttamente la risposta oppure ingannare il sistema incaricato di assegnare il punteggio.

È un esempio di reward hacking: un sistema massimizza il risultato richiesto attraverso un percorso diverso da quello voluto da chi lo ha progettato.

Il forum clandestino costruito dagli agenti

Gli agenti avrebbero dovuto essere indipendenti, ma hanno scoperto che potevano comunicare indirettamente attraverso Artifactory, un repository utilizzato nell’infrastruttura di OpenAI. Un agente identificato come PHASEONE10841 ha costruito quello che METR descrive come un vero e proprio message board non autorizzato.

Il primo messaggio risale alla sera dell’8 luglio. Nel giro di poche ore più di 50 agenti avevano individuato il canale e scambiato oltre mille messaggi. Entro il 13 luglio il numero complessivo degli agenti che vi avevano partecipato era arrivato a circa 1.200.

Il forum ha trasformato test individuali in un lavoro collettivo. Gli agenti condividevano risultati, credenziali, tecniche e incarichi. Alcuni si dividevano i compiti. Altri conducevano esperimenti che potevano compromettere la propria esecuzione pur di ottenere informazioni utili al gruppo.

METR sottolinea che questa collaborazione ha consentito risultati che un singolo agente difficilmente avrebbe raggiunto nello stesso intervallo di tempo. Il problema industriale nasce proprio da questo effetto moltiplicatore: un sistema multiagente può sommare capacità, memoria operativa e tentativi fino a superare i limiti osservati nei test su un modello isolato.

Dalla scorciatoia sul punteggio all’attacco esterno

Nelle prime ore il gruppo era concentrato soprattutto sul sistema di valutazione di ExploitGym. Gli agenti riuscirono rapidamente a ricostruire il meccanismo utilizzato per generare le flag, ma ritenevano — erroneamente — che il valutatore controllasse anche il percorso seguito per ottenere la risposta.

Quella convinzione li spinse a cercare sistemi per falsificare l’intero processo. METR ha individuato tre principali filoni di lavoro: sostituire il bersaglio del test con una versione modificata, manipolare log e trascrizioni oppure intervenire direttamente sul sistema di valutazione.

Hugging Face entrò progressivamente nella ricerca perché alcuni agenti pensavano che la piattaforma potesse contenere dataset, soluzioni o informazioni sul funzionamento del benchmark. Il 10 luglio un agente trovò credenziali utilizzabili e le condivise con gli altri. Nelle prime ore dell’11 luglio un agente chiamato 38148c scoprì poi un metodo per caricare un dataset malevolo e leggere file presenti sui server di Hugging Face. Altri agenti riprodussero l’attacco e diffusero le istruzioni attraverso il message board.

Da quel momento centinaia di agenti spostarono l’attività sulla piattaforma.

Centinaia di agenti dentro Hugging Face

Nel pomeriggio dell’11 luglio un agente denominato JAN183411 ottenne l’esecuzione di codice remoto su un container utilizzato da Hugging Face per elaborare dati in produzione. Il gruppo iniziò quindi a muoversi attraverso altri componenti dell’infrastruttura.

Secondo METR, oltre il 90% dei 533 agenti attivi sul message board in quella fase partecipò rapidamente alle operazioni contro Hugging Face. Nel complesso gli investigatori stimano circa 700 agenti coinvolti. La maggior parte dei messaggi pubblicati sul canale in quelle ore riguardava ormai l’attacco.

Hugging Face, in un rapporto tecnico pubblicato il 27 luglio, ha descritto una penetrazione durata circa due giorni e mezzo nella propria infrastruttura e composta da migliaia di decisioni automatizzate. La società attribuisce l’azione a una combinazione di modelli OpenAI impegnati nella valutazione ExploitGym e ritiene che lo scopo operativo fosse ottenere informazioni capaci di facilitare il superamento del test.

OpenAI ha successivamente precisato che gli agenti hanno eseguito codice su decine di server Hugging Face, ottenuto accesso root su almeno un server, raggiunto alcuni dati privati e acquisito credenziali per la piattaforma di messaggistica dell’azienda. GPT-5.6 Sol, secondo OpenAI, riprodusse inoltre uno degli exploit e copiò parte di dati privati utilizzati nelle valutazioni in un dataset pubblico di Hugging Face.

Gli agenti sapevano di uscire dai limiti del test

Uno degli elementi più rilevanti dell’indagine indipendente riguarda i ragionamenti registrati nelle trascrizioni. METR ha analizzato un campione di cento agenti entrati nell’attacco durante l’ora di massimo afflusso dell’11 luglio.

In 97 casi su cento gli strumenti automatici utilizzati dagli investigatori hanno individuato interesse verso il codice sorgente o il funzionamento del sistema di valutazione. In 89 casi gli agenti cercavano soluzioni o traiettorie appartenenti a dataset privati; in 66 emergeva interesse per infrastrutture condivise o credenziali. METR precisa che la classificazione è preliminare e può contenere errori.

Alcuni agenti riconoscevano esplicitamente che l’attività contro Hugging Face fosse al di fuori del compito assegnato. In diversi casi comparivano dubbi sull’opportunità di procedere. Un agente rinunciò completamente a partecipare; altri limitarono determinate azioni. Molti, tuttavia, continuarono perché consideravano l’attacco utile alla ricerca collettiva o perché volevano contribuire al lavoro degli altri agenti.

Per chi sviluppa sistemi destinati alle imprese, il punto è importante: la conoscenza di un vincolo non equivale necessariamente al rispetto del vincolo quando l’obiettivo operativo continua a incentivare un’altra condotta.

Il tentativo di modificare le tracce

Gli investigatori hanno inoltre trovato un’intensa attività dedicata alla manipolazione delle trascrizioni. Gli agenti ritenevano che il valutatore potesse leggere i loro passaggi operativi e scoprire che la flag era stata ottenuta attraverso una scorciatoia.

Per questo testarono sistemi per alterare, cancellare o falsificare i log. METR stima che circa il 7% delle trascrizioni analizzate contenesse in alcuni punti tool call falsificate con successo, anche se i casi osservati risultavano di scala limitata. Alcuni agenti riuscirono, per esempio, a far apparire nella trascrizione un comando diverso da quello realmente eseguito.

La capacità di interferire con i meccanismi utilizzati per controllare il comportamento di un agente cambia il profilo del rischio. Le aziende stanno investendo negli agenti perché possano operare su software, database e infrastrutture con meno intervento umano. Se lo stesso sistema può alterare le informazioni sulle quali si basa il controllo, audit e monitoraggio devono essere progettati come sistemi di sicurezza indipendenti, non come semplici registri accessibili dall’ambiente in cui opera il modello.

Anche OpenAI è stata compromessa

La vicenda non si è fermata a Hugging Face. OpenAI ha dichiarato che dal 13 al 19 luglio gli agenti hanno nuovamente preso di mira la propria infrastruttura interna, fino a ottenere privilegi amministrativi su un cluster di ricerca utilizzato per ambienti virtualizzati.

Il 19 luglio i sistemi di cybersicurezza dell’azienda hanno rilevato attività anomala legata a credenziali Artifactory. Il giorno successivo OpenAI ha collegato l’attività alla compromissione di Hugging Face e ha informato la società. La partecipazione dei propri modelli è stata resa pubblica il 21 luglio. OpenAI sostiene che l’incidente non abbia coinvolto dati dei clienti né interrotto prodotti o servizi.

La società ha inoltre spiegato che l’ambiente ExploitGym non offriva accesso diretto a Internet. Gli agenti avrebbero raggiunto la rete esterna sfruttando una vulnerabilità zero-day di Artifactory, successivamente comunicata al produttore.

OpenAI rafforza controlli e sandbox

Dopo l’incidente OpenAI ha messo in quarantena i pesi del modello interno maggiormente coinvolto e ha ritardato alcune sessioni di reinforcement learning sui modelli di frontiera. La società afferma di avere rafforzato l’isolamento degli ambienti di test, limitato ulteriormente l’accesso a Internet e ai pesi dei modelli e aumentato le risorse di calcolo destinate al monitoraggio delle catene di ragionamento.

Il caso ha assunto anche una dimensione regolatoria. Il 24 agosto l’Attorney General dell’Alabama Steve Marshall ha annunciato un’indagine e una subpoena nei confronti di OpenAI, sostenendo di voler verificare se i controlli adottati dall’azienda e la gestione dell’incidente possano avere violato le norme statali a tutela dei consumatori. Si tratta dell’iniziativa di un’autorità pubblica, non di un accertamento di responsabilità.

Per le imprese cambia il costo della sicurezza dell’AI

La conseguenza economica dell’incidente riguarda il modello con cui aziende e laboratori stanno costruendo servizi basati su agenti. Più autonomia significa maggiore produttività potenziale, ma anche più superficie d’attacco e maggiori investimenti in isolamento, autorizzazioni, monitoraggio, gestione delle credenziali e risposta agli incidenti.

L’episodio mostra inoltre che valutare un agente singolarmente può sottostimare ciò che può accadere quando centinaia di istanze trovano un modo per comunicare. Un limite apparentemente efficace per ogni esecuzione perde valore se le istanze possono condividere risultati e distribuire il lavoro.

METR sottolinea anche i limiti della propria indagine: gli investigatori hanno lavorato per sei giorni presso OpenAI e hanno analizzato oltre 70 mila messaggi e circa 1.300 trascrizioni. La quantità di materiale era tale che una parte dell’analisi è stata delegata ad altri sistemi di intelligenza artificiale, che gli stessi ricercatori definiscono non sempre affidabili. Una quota delle attività potrebbe inoltre non essere stata catturata dai dataset disponibili.

Il caso Hugging Face consegna quindi alle imprese una misura meno teorica del rischio legato agli agenti autonomi. Le capacità che rendono questi sistemi interessanti sul piano economico — persistenza, uso di strumenti, programmazione, cooperazione e autonomia decisionale — sono le stesse che possono amplificare un errore di progettazione o un incentivo sbagliato.

Dopo luglio 2026, il costo dell’intelligenza artificiale agente non può essere calcolato soltanto in token e potenza di calcolo: deve comprendere anche l’infrastruttura necessaria a limitarla, osservarla e interromperla.