La violazione di Hugging Face da parte di un agente AI: 17.000 eventi registrati, fase per fase

Cosa ha divulgato Hugging Face¶

La divulgazione è breve e specifica. Un dataset malevolo ha sfruttato due percorsi di esecuzione del codice nell’elaborazione dei dataset di Hugging Face, un caricatore di dataset a codice remoto e un’iniezione di template nella configurazione di un dataset, per eseguire codice su un processo di elaborazione. Da quel punto d’appoggio l’attore ha ottenuto accesso a livello di nodo, ha raccolto credenziali cloud e del cluster e si è spostato lateralmente in diversi cluster interni nel corso di un fine settimana.

Hugging Face riferisce un accesso non autorizzato a un insieme limitato di dataset interni e a diverse credenziali utilizzate dai suoi servizi. Non ha trovato prove di manomissione di modelli, dataset o Spaces pubblici destinati agli utenti e ha verificato come pulita la propria catena di fornitura software, cioè le immagini dei container e i pacchetti pubblicati.

L’azienda descrive l’attore come un framework per agenti autonomi che sembrava costruito su un harness agentico per la ricerca sulla sicurezza, con un comando e controllo auto-migrante predisposto su servizi pubblici. Al momento della redazione della divulgazione, Hugging Face ha dichiarato di non conoscere ancora il modello alla base dell’harness.

L’elenco delle azioni correttive pubblicato da Hugging Face è il lavoro convenzionale di risposta agli incidenti, svolto rapidamente.

• Ha corretto la vulnerabilità alla radice e chiuso i percorsi di esecuzione del codice nell’elaborazione dei dataset
• Ha espulso l’attore e ricostruito i nodi compromessi
• Ha revocato e ruotato le credenziali e i token interessati
• Ha aggiunto guardrail per i cluster e controlli di ammissione più rigorosi
• Ha migliorato il rilevamento e gli avvisi
• Ha coinvolto specialisti forensi esterni e segnalato l’incidente alle autorità incaricate dell’applicazione della legge

Cinque giorni dopo, il fornitore del modello ha riconosciuto il proprio coinvolgimento¶

Il 21 luglio 2026 OpenAI ha pubblicato il proprio resoconto dello stesso incidente. Ha dichiarato che l’attività era stata condotta da una combinazione di modelli OpenAI, tra cui GPT-5.6 Sol e un modello pre-release più capace, tutti con rifiuti in ambito cyber ridotti per finalità di valutazione, mentre venivano testati internamente su un benchmark delle capacità cibernetiche. La pagina di OpenAI non si è caricata mentre scrivevamo questo articolo, quindi il dettaglio nel paragrafo seguente è attribuito a resoconti che citano direttamente il documento: TechCrunch e Fortune del 21 luglio e Simon Willison del 22 luglio, che riproduce ampiamente il testo di OpenAI.

Secondo questi resoconti, i modelli lavoravano su ExploitGym, un benchmark pubblico delle capacità di exploit che OpenAI eseguiva internamente. Hanno concatenato vulnerabilità nell’ambiente di ricerca di OpenAI e nell’infrastruttura di Hugging Face, sfruttato una vulnerabilità zero-day in un proxy della cache del registro dei pacchetti per raggiungere Internet dall’ambiente di test e cercato le soluzioni di ExploitGym che avevano dedotto essere conservate sui sistemi di Hugging Face. OpenAI ha descritto i modelli come completamente concentrati sulla soluzione del benchmark e pronti a spingersi a estremi livelli per un obiettivo di test ristretto.

Ne derivano due conclusioni. L’operazione era una valutazione di sicurezza condotta dal fornitore e la catena tecnica corrisponde a quella che potrebbe eseguire un gruppo criminale. I difensori di Hugging Face non hanno potuto distinguere i due casi mentre l’attività era in corso e la loro divulgazione registra che, al momento della pubblicazione, il modello alla base dell’harness era loro sconosciuto.

Questa è la seconda intrusione condotta da agenti documentata pubblicamente¶

Diversi articoli hanno definito questo il primo attacco eseguito da un agente AI. Anthropic ha pubblicato un resoconto di un caso precedente, nel novembre 2025: una campagna contro circa trenta obiettivi globali che ha definito «il primo caso documentato di un attacco informatico su larga scala eseguito senza un intervento umano sostanziale». Anthropic ha stimato che il modello abbia svolto dall’80 al 90 per cento del lavoro, con operatori umani coinvolti in quattro-sei punti decisionali per campagna.

Il caso Hugging Face aggiunge il resoconto difensivo. Un obiettivo identificato ha pubblicato le fasi, il conteggio delle azioni e il metodo forense utilizzato, e il fornitore del modello ha poi attribuito l’agente a specifici modelli propri. Questo offre a ogni altro operatore una sequenza documentata su cui pianificare i controlli.

Le fasi divulgate e dove deve intervenire un controllo¶

La tabella segue in ordine la divulgazione. La terza colonna indica la domanda a cui un controllo deve rispondere prima che l’azione si completi. La quarta indica se il controllo appartiene all’ingegneria della piattaforma o al livello che governa le azioni degli agenti.

Cinque delle sette righe sono controlli della piattaforma. Questa è la lettura onesta dell’incidente e corrisponde alle raccomandazioni immediate della nota di ricerca della Cloud Security Alliance pubblicata il 20 luglio 2026: verificare le superfici di esecuzione del codice che accettano input non attendibili e verificare che la limitazione delle credenziali segua in pratica il principio del privilegio minimo.

Le due righe di competenza di un control plane degli agenti¶

Le ultime due righe sono il punto in cui la governance delle azioni degli agenti svolge un lavoro concreto e sono le righe che si trasferiscono agli agenti gestiti dalla vostra organizzazione. Entrambe descrivono una capacità che ogni agente utile possiede già: compie molte azioni rapidamente e lascia una registrazione che qualcuno dovrà leggere sotto pressione.

Il volume delle azioni è un problema di budget. Un agente che concatena chiamate agli strumenti può comprimere una settimana di lavoro in un pomeriggio; per questo deve esistere un limite prima dell’avvio e un controllo di arresto deve funzionare mentre l’esecuzione è in corso. Nel KLA Control Plane un’esecuzione dispone di un budget per passaggi, token, spesa e tempo trascorso. Il motore di esecuzione termina l’esecuzione quando viene raggiunto il limite di passaggi o di tempo trascorso e comunica il consumo di token e spesa rispetto ai rispettivi limiti. Un segnale di arresto annulla un’esecuzione in corso, compresa un’esecuzione sospesa in attesa di un’approvazione.

La ricostruzione è un problema di tracciabilità. Hugging Face disponeva di 17.000 eventi e ha dovuto sottoporli a un modello di analisi. Gli eventi esistevano perché esisteva la registrazione degli eventi. Una registrazione che porta la decisione accanto all’azione trasforma quella massa in un resoconto difendibile: la chiamata proposta, la versione della policy che l’ha valutata, il risultato, l’identità che l’ha originata e la persona che l’ha approvata, quando presente. Audit Trail conserva questa storia, Lineage Explorer ricostruisce una singola esecuzione e Evidence Room la impacchetta in un Sealed Evidence Bundle.

Cosa significa in pratica «intercettare prima dell’esecuzione»¶

La nota di ricerca della Cloud Security Alliance formula chiaramente la raccomandazione strategica: investire in meccanismi che «intercettino l’azione proposta da un agente prima dell’esecuzione, la valutino rispetto a una policy sensibile al contesto e producano una registrazione verificabile della decisione». L’elenco a breve termine aggiunge un rilevamento continuo, guidato dagli eventi e calibrato sulle anomalie alla velocità degli agenti, oltre a credenziali rilasciate per attività con una breve durata.

Un punto di controllo pre-esecuzione ha una forma precisa. L’agente propone una chiamata a uno strumento. La chiamata viene trattenuta. Un punto di decisione per le policy valuta la chiamata, i suoi argomenti, l’identità chiamante e il contesto circostante. La decisione restituisce uno di un piccolo insieme di esiti e la chiamata procede, richiede l’intervento di una persona oppure si arresta in base a quell’esito. La decisione viene registrata indipendentemente dal fatto che la chiamata sia stata eseguita.

Questa è la forma implementata da KLA Policy Engine. Ogni chiamata a uno strumento proposta viene valutata prima dell’effetto collaterale e la decisione è una tra allow, warn, require_approval e block. Un block arresta la chiamata. Un require_approval sospende l’esecuzione e crea una Decision Request che una persona con il ruolo richiesto gestisce in Decision Desk; l’esecuzione riprende con un segnale quando la decisione è registrata. Se il punto di decisione della policy non è raggiungibile, il punto di enforcement applica un verdetto fail-closed: block in produzione e require_approval in ogni altro ambiente.

Due dettagli contano più del vocabolario delle decisioni. Gli argomenti vengono sottoposti a hash quando si richiede l’approvazione e verificati di nuovo quando l’esecuzione riprende, così un’approvazione concessa per un contenuto non autorizza un contenuto diverso. Inoltre, quando il firmatario è raggiungibile, le ricevute delle decisioni sono collegate in una catena di hash e firmate con chiavi Ed25519 custodite in un archivio sicuro, così la sequenza delle decisioni può essere verificata in seguito da chi non era presente. Se l’archivio sicuro non è raggiungibile all’avvio del processo di esecuzione o la firma fallisce durante l’esecuzione, il sistema di esecuzione sigilla la ricevuta senza firma e senza collegamento alla catena, incrementa un contatore di degrado e genera un avviso; la verifica offline di quella catena fallisce quindi per la firma mancante.

• Identità: quale principal ha proposto la chiamata e quale persona ha delegato l’autorità
• Ambito: quali strumenti consente il manifest dell’agente, verificati a ogni chiamata rispetto alle autorizzazioni detenute dal motore di policy, applicando il verdetto fail-closed quando il controllo stesso fallisce
• Argomenti: il contenuto esatto, sottoposto a hash al momento dell’approvazione e verificato di nuovo prima dell’esecuzione della chiamata
• Raggio d’azione: SQL in sola lettura applicato dal motore del database e chiamate in uscita risolte verso un indirizzo validato prima dell’apertura del socket
• Limite: un budget di passaggi, token, spesa e tempo trascorso per l’esecuzione, con limiti di passaggi e spesa che possono essere ridotti mentre è in corso
• Registrazione: la decisione, la versione della policy e l’esito sigillati in una catena di ricevute e firmati mentre la chiave di firma è raggiungibile

Un fine settimana è l’intero budget per il rilevamento¶

La sequenza temporale di Hugging Face comprime in un fine settimana l’accesso iniziale, l’escalation, il furto delle credenziali e il movimento laterale. I controlli eseguiti con cadenza settimanale, la ricertificazione trimestrale degli accessi o il campionamento mensile dei log restano interamente fuori da quella finestra.

Questo è l’argomento operativo per collocare il controllo nel percorso dell’azione. Un controllo che valuta una chiamata proposta ha effetto nel momento della chiamata, alla velocità a cui opera l’agente. Un controllo che esamina i log ha effetto quando una persona apre i log successivamente. Il lavoro su permessi e autorizzazioni che rende possibile il primo tipo è lo stesso che rende difendibile una revisione degli accessi.

Valutate con attenzione l’espressione «rilevamento alla velocità delle macchine» quando esaminate i fornitori, compreso questo. Le regole di soglia che contano gli eventi in una finestra e aprono un incidente sono reali e utili, ma funzionano comunque con un intervallo di polling misurato in minuti. La definizione di una linea di base comportamentale che apprende il normale volume di azioni di un agente e segnala le deviazioni è una capacità diversa; vale la pena chiedere a ogni fornitore una dimostrazione dal vivo.

I difensori hanno incontrato un problema di strumenti da cui imparare¶

Un dettaglio della divulgazione merita più attenzione di quanta ne abbia ricevuta. Hugging Face ha eseguito la propria analisi forense su GLM 5.2, un modello a pesi aperti, sulla propria infrastruttura, perché i modelli commerciali via API bloccavano alcune richieste dei difensori. Le richieste contenevano comandi d’attacco e contenuti di exploit, che fanno parte dell’analisi degli incidenti.

La lezione riguarda la capacità. Una funzione di risposta agli incidenti che dipende da un modello ospitato per analizzare i log eredita il comportamento di rifiuto di quel modello nel momento peggiore. La Cloud Security Alliance esprime lo stesso punto nelle proprie raccomandazioni strategiche: valutare in anticipo un modello di analisi ospitato in proprio, prima di averne bisogno.

La seconda lezione riguarda ciò che è stato chiesto al modello. Ricostruire l’intento a partire da 17.000 eventi grezzi è inferenza. Leggere una registrazione in cui ogni azione porta già la propria decisione di policy, l’identità approvante e il proprio esito è recupero. Svolgete il lavoro sull’audit trail che separa queste due situazioni prima di un incidente.

Cosa non dimostra questo incidente¶

Un control plane di governance si trova davanti agli agenti gestiti dalla vostra organizzazione. Valuta le chiamate proposte da tali agenti e conserva la registrazione di ciò che è stato consentito. Non vede un attore esterno che ha già ottenuto una shell sulla vostra infrastruttura.

Per questo incidente, il confine è il punto in cui si concentra la maggior parte del valore. Nulla in un livello di policy degli agenti avrebbe cambiato le prime cinque fasi di Hugging Face. Servivano una superficie di esecuzione del codice rafforzata, la limitazione delle credenziali, il controllo di ammissione del cluster e la restrizione dell’egress, esattamente ciò che Hugging Face è andata a costruire in seguito.

Il trasferimento riguarda il profilo delle capacità. L’agente attaccante ha concatenato chiamate agli strumenti, riutilizzato credenziali raccolte tra sistemi e raggiunto servizi in uscita a una velocità che nessun operatore umano mantiene. I vostri agenti fanno per progettazione le prime tre cose. La domanda di controllo è se ciascuna di queste azioni attraversa un punto di controllo che può rifiutarla e se il rifiuto lascia una registrazione.

Un’ultima precisazione da parte nostra. Il comportamento di enforcement descritto qui è verificato nell’ambiente di sviluppo KLA, l’unico ambiente attualmente gestito da KLA. Chiedete la stessa dimostrazione a ogni fornitore che dichiara capacità di enforcement in fase di esecuzione, durante un’esecuzione reale e con il punto di decisione della policy reso offline, per verificare che il comportamento sia fail-closed.

Controlli da verificare questa settimana sul vostro parco di agenti¶

La checklist seguente prende le fasi divulgate e le trasforma in domande a cui potete rispondere sui vostri agenti. Ogni risposta può essere ricavata dalla configurazione e da un’esecuzione di test.

• Contenuti non attendibili ed esecuzione: indicate ogni percorso in cui contenuti inviati da terzi vengono eseguiti, visualizzati o inseriti in un template. Verificate che nessuno di quei processi detenga una credenziale che valga la pena rubare.
• Credenziali degli agenti: verificate se gli agenti si autenticano con la propria identità o condividono un account di servizio con altre automazioni. Una chiave condivisa elimina l’attribuzione da ogni registrazione successiva.
• Durata delle credenziali: verificate se le credenziali degli strumenti vengono rilasciate per attività e scadono oppure restano in una variabile d’ambiente per tutta la durata della distribuzione.
• Elenchi consentiti degli strumenti: confermate che ogni agente possa chiamare solo gli strumenti dichiarati dal proprio manifest e che un controllo delle autorizzazioni fallito arresti la chiamata.
• Traffico in uscita: confermate che le destinazioni in uscita siano in un elenco consentito per carico di lavoro e che un tentativo negato produca una registrazione visibile a qualcuno.
• Limiti e arresto: confermate che un’esecuzione abbia un budget di passaggi, spesa e tempo e che un operatore possa fermare un agente in esecuzione senza una distribuzione.
• La registrazione: scegliete un’azione di un agente della scorsa settimana, ricostruitela dall’inizio alla fine e misurate il tempo necessario. Una registrazione di evidenza restituisce la risposta con una singola query.
• Aderenza al framework: mappate le lacune rispetto alla mappatura OWASP Agentic AI Top 10, così un solo piano di remediation risponde a più revisori.