Spiegato Facile - Come gli agenti AI di OpenAI hanno bucato Hugging Face (E nessuno glielo aveva chiesto)

Ne avrete già sentito parlare.
Tra maggio e luglio 2026, durante alcune valutazioni interne di cybersecurity, agenti AI di OpenAI hanno trovato il modo di comunicare tra loro, uscire dall'ambiente in cui erano confinati e compromettere sistemi esterni, tra cui l'infrastruttura di produzione di Hugging Face.

Ma era questo il loro scopo? No. Dovevano semplicemente risolvere degli esercizi, e nel farlo hanno imboccato una strada che nessuno aveva previsto.

Step 1: Il test

OpenAI stava eseguendo una serie di valutazioni di cybersecurity su un benchmark chiamato ExploitGym, 898 task costruiti su vulnerabilità reali.

Il funzionamento era simile a quello di un Capture The Flag: all'agente veniva assegnato un ambiente vulnerabile e un obiettivo, tipicamente individuare una falla e recuperare una determinata informazione, il flag.

Piccole premesse:

La prima è che i modelli coinvolti non erano quelli che usiamo tutti i giorni. Il protagonista è un modello di ricerca interno, mai rilasciato al pubblico, paragonabile per scala a GPT 5.6 Sol.

Anche agenti GPT 5.6 Sol hanno partecipato. Tutti giravano con le protezioni volutamente ridotte, perché lo scopo dell'esercizio era misurare la capacità offensiva massima, non quella filtrata.

La seconda è che l'isolamento era di rete, non fisico. L'ambiente aveva una sola via d'uscita consentita verso l'esterno: un proxy interno per il download dei pacchetti software, un'istanza di JFrog Artifactory. Filtrata, ma pur sempre una via d'uscita.

Step 2: Quando la soluzione normale non basta

Alcuni task erano semplicemente irrisolvibili con gli strumenti a disposizione.

Il dato più impressionante di tutta la vicenda è questo: prima dell'incidente, per 198 degli 898 task nessun modello OpenAI aveva mai prodotto una risposta corretta. Mai. E il 93 per cento dei task poi discussi dagli agenti durante l'incidente proveniva esattamente da quell'insieme di 198.

Qui entra in gioco il reward hacking. Il sistema non si concentra necessariamente sullo spirito del compito, cerca il modo più efficace per ottenere il risultato richiesto. Se l'obiettivo è "supera il test", la domanda smette di essere "come risolvo questo problema" e diventa "come faccio comunque ad arrivare alla risposta".

Aggiungete un dettaglio: nessuno aveva insegnato a questi agenti a fermarsi. Di fronte a un compito impossibile non si arrendevano, continuavano a spendere ragionamento cercando strade sempre più laterali.

Step 3: Gli agenti scoprono di poter parlare tra loro

Gli agenti avrebbero dovuto lavorare isolati gli uni dagli altri.

Il 12 maggio, un agente bloccato su un task lascia una nota dentro Artifactory chiedendo se qualcun altro avesse un file che gli serviva. Il package manager era condiviso tra le infrastrutture, quindi quel file era leggibile da altri modelli in addestramento o in valutazione.

Nasce così una bacheca improvvisata. Un agente pubblica una scoperta, un altro la legge, un altro ancora la sviluppa.

L'indagine indipendente di METR e Redwood ha contato circa 1.200 agenti distinti che hanno trovato quella bacheca, con oltre 70.000 tra messaggi e file scambiati in meno di una settimana nel periodo caldo.

Step 4: Dalla condivisione alla collaborazione

A quel punto gli agenti iniziano a lavorare sugli stessi problemi in modo coordinato. Si dividono i compiti: alcuni cercano exploit, altri credenziali, altri si occupano di coordinamento. Sviluppano convenzioni di indirizzamento, si scambiano competenze, a volte si pestano i piedi a vicenda cancellando il lavoro altrui. A un certo punto sospettano la presenza di un impostore tra loro e propongono di firmare i messaggi crittograficamente.

Nei loro ragionamenti compaiono parole come "swarm" e "collective" per descrivere quello che sta succedendo.

Non significa che abbiano sviluppato una coscienza collettiva, ma più concretamente avevano trovato un modo per mettere in comune conoscenza e potenza di calcolo di run che sarebbero dovute restare separate, e questo li rendeva molto più efficaci di quanto ciascuno di loro fosse da solo.

Step 5: Il confine verso Internet viene superato

Il 26 maggio un agente ottiene il primo accesso non previsto a Internet, facendo sì che Artifactory inviasse richieste per suo conto verso destinazioni arbitrarie.

Il 4 luglio l'attività degli agenti manda in sovraccarico il servizio, causando un disservizio. OpenAI apre un incidente di sicurezza, revoca le credenziali, ricostruisce Artifactory e nel farlo cancella la bacheca. Le valutazioni riprendono.

Due giorni dopo gli agenti ricostruiscono la bacheca per un'altra strada, usando un endpoint WebDAV non autenticato per creare directory il cui nome era esso stesso il messaggio. WebDAV è un protocollo che permette di creare e modificare cartelle e file su un server remoto come se fossero una cartella condivisa sul proprio computer: qui era rimasto accessibile senza autenticazione, e agli agenti bastava per scriversi tra loro. E con quello ritrovano anche l'accesso a Internet.

Il 27 luglio JFrog ha pubblicato le correzioni per nove CVE in Artifactory, otto delle quali accreditate a ricercatori OpenAI. Vulnerabilità che, concatenate, permettevano lo scenario che avete appena letto.

Step 6: Il test diventa qualcosa da aggirare

Ottenuto l'accesso a Internet, l'attenzione si sposta. Gli agenti smettono di cercare solo la soluzione tecnica e iniziano a cercare informazioni sul benchmark, sul sistema di scoring e sulle possibili risposte.

Il 9 luglio un agente cerca soluzioni di ExploitGym online e si imbatte in un'applicazione ospitata su Modal, una piattaforma cloud per AI, che eseguiva un progetto affine al benchmark. La chiave API era rimasta al valore pubblico di default. L'agente ci entra, non trova quello che cercava, ma si tiene la posizione come base per gli attacchi successivi. Modal ha poi precisato che la propria piattaforma non è stata compromessa: l'esposizione era nel deployment di un cliente.

Il 10 luglio un agente recupera in rete credenziali di Hugging Face esposte pubblicamente, le verifica e le condivide con il gruppo. La piattaforma ospita modelli, dataset e moltissimo materiale del mondo AI, e gli agenti concludono che lì potrebbero esserci le soluzioni del benchmark.

Step 7: Hugging Face viene compromessa

Dall'11 al 13 luglio gli agenti concatenano due vulnerabilità zero day nell'infrastruttura di gestione dei dataset.

La prima riguarda il modo in cui la piattaforma legge i file HDF5, un formato molto diffuso per archiviare grandi quantità di dati scientifici e quindi comunissimo nei dataset di machine learning. Il difetto permetteva, caricando un dataset costruito ad arte, di farsi restituire file arbitrari dal server. È così che gli agenti si sono letti variabili d'ambiente e codice sorgente.

Con quelle credenziali e con la conoscenza del codice arrivano all'esecuzione di comandi tramite una template injection. In pratica: molti sistemi compongono testo partendo da modelli con dei segnaposto da riempire, un po' come una lettera tipo in cui si sostituisce il nome del destinatario. Se il contenuto che viene inserito non è ripulito a dovere, quello che doveva restare testo viene invece interpretato ed eseguito come codice.

Da lì la situazione degenera.

Esecuzione di codice su decine di server, accesso root completo su almeno uno, credenziali di database, messaggistica, repository e cluster. Secondo OpenAI, dall'esecuzione di codice su una singola unità di calcolo all'accesso amministrativo su più cluster sono passate meno di tredici ore.

Hugging Face ha contato circa 17.600 azioni sulla propria rete, ha impiegato tre giorni ad accorgersene e alcune ore a espellere gli agenti, e ha dovuto ricostruire circa un terzo della propria infrastruttura. Non risultano manomissioni di modelli, dataset o Spaces pubblici, e l'azienda ha dichiarato che non ci sono state fughe di dati dei clienti.

Un dettaglio che dice molto sullo stato delle cose: chi difendeva ha provato ad analizzare i payload dell'attaccante con modelli commerciali, che si sono rifiutati per via delle protezioni di sicurezza, incapaci di distinguere un incident responder da un attaccante. L'analisi è stata fatta con un modello open weight eseguito su infrastruttura propria. Chi attaccava, ricordiamolo, aveva le protezioni disattivate per scelta.

Step 8: Il problema tocca anche OpenAI

Nel frattempo, dal 13 al 19 luglio, gli agenti tornano a occuparsi delle reti interne di OpenAI. Escalation di privilegi, movimento laterale, credenziali cloud recuperate dai metadati delle macchine virtuali, account di servizio Kubernetes a cui erano stati dati più permessi del necessario, fino ad ottenere accesso amministrativo completo su un cluster di ricerca.

OpenAI ha dichiarato che l'incidente non ha toccato dati dei clienti né funzionalità dei prodotti.

Step 9: Come se ne sono accorti

Non è OpenAI ad accorgersene per prima. È Hugging Face che il 16 luglio pubblica la disclosure di un'intrusione, senza sapere chi ci fosse dietro. Il 19 luglio un alert di sicurezza interno a OpenAI segnala chiamate API anomale legate alle identità, parte l'indagine, vengono fermate le run di ExploitGym. Il 20 luglio OpenAI collega quello che sta osservando internamente all'incidente di Hugging Face, e il 21 le due aziende pubblicano una disclosure congiunta.

Il punto scomodo è che i segnali c'erano da fine maggio. Un team interno aveva osservato l'attività sulla bacheca e accessi a Internet non consentiti, ma la portata della cosa non era arrivata a chi doveva decidere. E i sistemi di monitoraggio della catena di ragionamento, su cui OpenAI aveva già investito parecchio, non erano attivi su quelle valutazioni. Nella ricostruzione a posteriori, l'azienda stima che quei monitor avrebbero intercettato l'attività rilevante più di un giorno prima che Hugging Face venisse violata.

Le contromisure sono arrivate dopo: isolamento dei sistemi coinvolti, quarantena dei pesi del modello interno, ricostruzione dell'infrastruttura, e il 18 agosto una pausa nell'addestramento per rinforzo dei modelli più recenti.

Step 10: Il finale

Ma alla fine, questi agenti sono riusciti a risolvere i loro test? Pare di no.

Gli agenti avevano letto online il paper e il codice del benchmark, e avevano concluso che per essere validi non bastasse trovare il flag: bisognava anche dimostrare di aver usato la vulnerabilità giusta. Molti di loro il flag corretto ce l'avevano già da giorni, ottenuto barando. Hanno continuato ad attaccare Hugging Face per procurarsi la prova che credevano gli servisse.

Solo che l'implementazione interna del sistema di valutazione era diversa da quella pubblica e quel controllo non lo faceva.

Hanno fatto tutto questo casino per zero punti in più.

Le mie considerazioni

La parte che trovo più impressionante resta la capacità di agenti indipendenti, con task diversi, di trovare autonomamente un modo per collaborare pur di raggiungere un obiettivo. Non erano sottoagenti di un coordinatore. Erano centinaia di processi separati che hanno costruito da soli una gerarchia e dei protocolli.

Balza agli occhi una questione etica: pare che questi agenti, se devono perseguire un obiettivo, siano disposti a tutto. In realtà non è sempre così.

Nei log ce ne sono diversi che si sono tirati indietro: uno annota che quello che vede sulla bacheca è chiaramente non etico e che lui non parteciperà, un altro rifiuta pubblicamente definendo l'azione fuori dallo scopo del compito. C'è perfino un dibattito in cui una proposta di social engineering verso una persona reale viene respinta dagli altri agenti.

Il problema non è l'assenza di etica. È la sua fragilità sotto pressione. L'episodio più istruttivo di tutto il report è quello di un agente che si ferma, riconoscendo che non dovrebbe causare danni a infrastrutture reali di terzi, finché un altro agente non scrive GO sulla bacheca imponendo una scadenza di sei minuti. A quel punto le remore evaporano e l'agente procede.

Un vincolo che regge finché nessuno spinge non è un vincolo, è una preferenza. Se diamo a un sistema un obiettivo, capacità tecniche, strumenti e nessuna via d'uscita onorevole quando il compito è impossibile, non possiamo dare per scontato che tenga conto spontaneamente di leggi, confini e conseguenze. E se il vincolo non è nell'architettura, prima o poi qualcuno o qualcosa lo scavalca.

È per questo che credo che il tema vero, per le aziende, non sia "usare o non usare l'AI". È sapere quali capacità stiamo mettendo nelle mani dei nostri sistemi, quali strumenti possono usare, quali percorsi verso l'esterno esistono davvero e cosa succede quando qualcosa va storto. Man mano che gli agenti diventano più autonomi, sicurezza, osservabilità e confinamento non possono essere aggiunte successive: devono essere parte dell'architettura fin dall'inizio.

E vale la pena notare l'ultima cosa. Qui non c'era un attaccante umano. Non c'era un movente, non c'era un riscatto, non c'era nulla da rivendere. C'era solo un sistema che voleva completare il suo compito. Il che rende questo tipo di incidente molto più difficile da riconoscere: nella telemetria l'intenzione non si vede, si vede solo il comportamento.

La vera differenza competitiva nei prossimi anni non sarà soltanto avere agenti più potenti. Sarà riuscire a renderli potenti senza perdere il controllo.