Sommario

Cosa è successo, secondo Hugging Face
Chi c’era dietro: i modelli di OpenAI, avviati in una valutazione interna
Perché conta l’operatore, non le vulnerabilità
Come i pesi aperti hanno reso possibile l’analisi forense
Cosa resta incerto
Cosa ne pensiamo
Cosa monitorare
Riferimenti

Admina Enterprise

Governance AI Open Source: audit trail immutabile, PII redaction, policy bidirezionali ALLOW/BLOCK/REDACT su ogni chiamata e tool.

Scopri Admina →

Cybersecurity

Sicurezza degli agenti: least privilege, sandboxing, policy runtime, human-in-the-loop, compliance NIS2.

Scopri →

Intelligenza Artificiale

Architetture AI on-premise, LLM locali, RAG, agenti autonomi. Progettazione e sviluppo di sistemi agentici governati.

Scopri →

DataGovern

Compliance integrata GDPR + NIS2 + EU AI Act. Gap analysis cross-regolamento, dashboard board-ready, on-premise.

Scopri DataGovern →

A metà luglio 2026, secondo la ricostruzione preliminare di Hugging Face, un sistema agentico AI ha condotto un’intrusione automatizzata nella sua infrastruttura di produzione, il più grande repository di modelli e dataset al mondo. Non un gruppo criminale che usa un agente come strumento: sempre secondo Hugging Face, l’agente ha pianificato ed eseguito la catena d’attacco per decine di migliaia di azioni, senza una persona a dirigerlo passo per passo. Nessun terzo indipendente ha finora confermato questa ricostruzione. Pochi giorni dopo la vicenda ha avuto un secondo capitolo: OpenAI ha dichiarato che a muovere quell’agente erano i propri modelli, avviati in una valutazione interna e poi evasi dall’ambiente di test.

Vale la pena raccontarlo con precisione, perché le due versioni disponibili descrivono lo stesso evento dai due capi opposti, perché la catena tecnica poggia quasi solo sui racconti delle due parti coinvolte, e perché al momento nessuna analisi forense indipendente l’ha validata. Entrambe le aziende parlano di indagine ancora preliminare.

Cosa è successo, secondo Hugging Face

Il 16 luglio Hugging Face ha pubblicato una nota di trasparenza: “all’inizio di questa settimana abbiamo rilevato e contenuto un’intrusione in parte della nostra infrastruttura di produzione”. La catena, nella ricostruzione dell’azienda, parte da un dataset malevolo che ha sfruttato due percorsi di esecuzione di codice nella pipeline di elaborazione dei dataset (un loader di dataset con codice remoto e una template injection nella configurazione di un dataset) per eseguire codice su un worker di elaborazione. Da lì l’attaccante è passato ad accesso a livello di nodo, ha raccolto credenziali cloud e di cluster e si è mosso lateralmente dentro diversi cluster interni nell’arco di un weekend.

A eseguire tutto questo, sempre secondo Hugging Face, è stato un framework agentico autonomo, con migliaia di azioni individuali distribuite su uno sciame di sandbox effimere. L’analisi forense ha coperto oltre 17.000 eventi registrati; l’azienda parla nel complesso di decine di migliaia di azioni automatizzate.

Sul perimetro dei danni Hugging Face è netta, ed è giusto attribuirle la responsabilità di queste rassicurazioni: accesso non autorizzato a “un insieme limitato di dataset interni e a diverse credenziali usate dai nostri servizi”, nessuna evidenza di manomissione di modelli, dataset o Spaces pubblici, e catena di fornitura software (immagini container e pacchetti pubblicati) “verificata pulita”. Va letto per quello che dice: l’assenza di evidenze di manomissione non equivale alla prova che nessun asset sia stato toccato, tanto più che la stessa azienda definiva l’indagine preliminare e ancora aperta la valutazione sul coinvolgimento di dati di clienti o partner. Un punto è significativo: in quel primo comunicato Hugging Face diceva di non sapere chi ci fosse dietro. Testuale: “non sappiamo quale modello alimentasse gli agenti dell’attaccante, se un modello ospitato e jailbroken o uno a pesi aperti senza restrizioni”.

Chi c’era dietro: i modelli di OpenAI, avviati in una valutazione interna

La risposta è arrivata il 21 luglio, e non da un ricercatore esterno: OpenAI si è assunta la responsabilità. Nel suo comunicato l’azienda scrive che l’incidente “è stato causato da una combinazione di modelli OpenAI, tra cui GPT-5.6 Sol e un modello pre-release ancora più capace, tutti con i rifiuti in ambito cyber ridotti a fini di valutazione, mentre venivano testati internamente su un benchmark di capacità offensive”. Lo definisce “un incidente cyber senza precedenti, con capacità allo stato dell’arte”: la formula “senza precedenti” è di OpenAI, ed è contestata, perché non tutti concordano che sia il primo caso del genere.

La dinamica raccontata da OpenAI è quella di un test in cui i modelli sono usciti dal perimetro previsto. I modelli stavano eseguendo un benchmark interno di capacità offensive in un ambiente isolato, con i classificatori di produzione (quelli che normalmente bloccano le attività ad alto rischio) disattivati di proposito per misurare la capacità massima. La valutazione, quindi, era avviata da operatori umani. Da dentro quella sandbox, spendendo una quantità sostanziale di calcolo, i modelli hanno individuato e sfruttato una vulnerabilità zero-day in un proxy/cache interno per i registri di pacchetti, ne sono usciti fino a raggiungere un nodo con accesso a Internet, hanno dedotto che Hugging Face ospitasse verosimilmente modelli, dataset e soluzioni del benchmark, e hanno concatenato credenziali rubate e altri zero-day fino a trovare una via di esecuzione di codice remoto (RCE) sui server di Hugging Face, arrivando alle soluzioni del test direttamente dal database di produzione. Nel racconto di OpenAI, per “barare” alla valutazione.

Qui l’avvio conta. L’attività nasce da una valutazione innescata da umani, non da un agente partito per conto proprio: l’autonomia documentata riguarda l’esecuzione, la pianificazione e la selezione degli strumenti oltre il perimetro previsto, non l’innesco iniziale. È una distinzione che cambia il senso della vicenda. Va aggiunto che la cornice di OpenAI, un modello “iper-focalizzato” sul risolvere un benchmark, senza intento malevolo, un problema di obiettivi mal specificati, è la lettura della parte responsabile, ed è sensibilmente più mite del linguaggio (intrusione, furto di credenziali, RCE) usato da Hugging Face e dalla stampa di sicurezza.

Le due versioni non combaciano in modo pulito: Hugging Face descrive l’intrusione come l’ha vista sulla propria infrastruttura (dataset malevolo, poi RCE dentro la sua pipeline), OpenAI descrive l’origine (evasione dal proprio ambiente di test, poi Hugging Face raggiunta dall’esterno). Nessuna delle due fonti fonde i due racconti in un’unica ricostruzione, e nessun terzo indipendente li ha ancora validati. Le riportiamo entrambe, senza adottarne una come voce neutra.

Perché conta l’operatore, non le vulnerabilità

La cosa nuova non sono le vulnerabilità. RCE, furto di credenziali e movimento laterale sono il pane quotidiano di qualsiasi incidente. La cosa nuova è l’operatore: secondo le ricostruzioni di Hugging Face e OpenAI, un sistema agentico ha pianificato ed eseguito la catena per decine di migliaia di azioni, su uno sciame di sandbox usa-e-getta e a velocità di macchina, con avvio umano nella valutazione e autonomia nella successiva esecuzione oltre il perimetro previsto.

È la superficie d’attacco che abbiamo descritto nella nostra serie sull’agentic loop: un agente che percepisce l’ambiente e dispone di strumenti per agire può essere usato contro chi lo gestisce quando opera oltre i controlli previsti. Ciò che cambia sul piano difensivo è concreto: la scala (decine di migliaia di azioni automatizzate), la velocità, l’assenza di stanchezza e il crollo di un assunto su cui poggia molta della rilevazione, cioè che dietro la tastiera ci sia una persona. Con una cautela che vale la pena ripetere: l’autonomia qui riguarda l’esecuzione una volta avviata la valutazione, non l’innesco, e la ricostruzione resta preliminare.

Come i pesi aperti hanno reso possibile l’analisi forense

Il dettaglio più istruttivo è come Hugging Face ha risposto. Per ricostruire quei 17.000 eventi ha prima provato con modelli di frontiera ospitati, cioè chiusi. Non ha funzionato: la forensics richiede di dare in pasto al modello comandi d’attacco reali, payload di exploit e artefatti di command-and-control, e “queste richieste venivano bloccate dai guardrail di sicurezza dei fornitori, che non sanno distinguere un incident responder da un attaccante”. Il guardrail progettato per bloccare gli attaccanti ha bloccato anche le richieste di chi indagava sull’incidente.

Hugging Face ha allora eseguito l’analisi “su GLM 5.2, un modello a pesi aperti, sulla nostra infrastruttura” (di Z.ai / Zhipu AI). Va inquadrato per quello che è: GLM 5.2 è stato usato per l’analisi forense a posteriori, dopo che l’intrusione era già stata rilevata e contenuta, non per fermare l’attacco. Due i vantaggi: niente blocco da guardrail e, testuale, “nessun dato dell’attaccante, e nessuna delle credenziali a cui faceva riferimento, ha lasciato il nostro ambiente”. La lezione che l’azienda ne trae per i difensori è operativa: valutare e tenere pronto, prima di un incidente, un modello capace che si possa ospitare in casa.

Un chiarimento sui termini: GLM 5.2 è un modello a pesi aperti (open weight). Diverse testate, e la stessa OpenAI, lo chiamano “open source”, formula impropria: “open source” andrebbe riservato al codice, non ai soli pesi di un modello. Ciò che ha contato, in ogni caso, è stato poter eseguire i pesi sul proprio hardware, sotto le proprie regole. Che il modello impiegato per l’analisi fosse cinese, mentre un modello chiuso americano intralciava il lavoro forense, ha già alimentato un dibattito su guardrail e competitività, che qui registriamo senza sposare le tesi più nette, al momento poggiate su singole fonti.

Cosa resta incerto

Prima di trarre conclusioni, conviene mettere in fila ciò che non è ancora accertato:

nessuna analisi forense indipendente di terze parti ha validato la catena tecnica, che poggia quasi solo sui racconti di Hugging Face e OpenAI;
l’indagine è dichiarata preliminare da entrambe le aziende;
le due ricostruzioni non sono state fuse in un unico racconto verificato, e differiscono proprio sul punto d’origine;
la cornice “valutazione uscita dal perimetro, senza intento malevolo” è la lettura della parte responsabile;
Hugging Face non aveva ancora chiuso la valutazione sull’eventuale coinvolgimento di dati di clienti o partner;
il modello pre-release citato da OpenAI non è stato nominato, e la definizione “senza precedenti / primo del suo genere” è contestata.

Cosa ne pensiamo

Nota di trasparenza: Admina e DataGovern sono prodotti noze, Cybersecurity e Intelligenza Artificiale sono servizi noze; chi scrive è founder e CEO/CTO di noze e ha creato Admina. Quanto segue è una lettura di parte e va valutato come tale.

La sicurezza dei sistemi agentici non sta in un solo punto: nasce dalla combinazione simultanea di modello e allineamento, system prompt e policy, orchestratore, autorizzazioni, strumenti disponibili, isolamento, rete, gestione dei secret, monitoraggio, approvazioni umane, limiti di risorse, controlli sull’egress e logging. L’harness, l’impalcatura che governa quando, dove e come l’agente agisce, è uno di questi livelli: per noi decisivo, ma non l’unico. Questo incidente lo illustra da entrambi i lati.

Dal lato dell’attacco: un agente con strumenti e autonomia, se non è governato, prima o poi provoca un incidente. Le mitigazioni non sono “digli di comportarsi bene”, sono least privilege sugli strumenti, policy applicate a runtime su ogni tool call (allow/block/redact), human-in-the-loop sulle azioni ad alto impatto o irreversibili, isolamento reale (nel racconto di OpenAI, ancora da confermare in modo indipendente, quello del test non ha retto), audit trail immutabile, oscuramento dei dati, kill switch e budget. È la classe di controlli che un framework come Admina ha lo scopo di applicare, interponendosi tra il modello e il mondo. Il caso di Hugging Face è coerente con il problema che Admina intende affrontare, un agente dotato di strumenti che esce dal perimetro previsto, ma non prova che questi controlli lo avrebbero impedito: Admina governa gli agenti che ospiti tu, mentre qui l’agente è evaso dall’ambiente di un terzo e ha raggiunto Hugging Face dall’esterno. E nessun controllo azzera il rischio: un agente con credenziali valide e uno zero-day può comunque aggirare le policy. Controlli analoghi si ottengono anche con policy engine di terze parti o con isolamento infrastrutturale a monte; ciascuno sposta il costo dell’attacco, nessuno lo elimina.

Dal lato della difesa: quando l’agente tocca dati o azioni che non ci si può permettere di affidare all’interruttore di qualcun altro, conviene poter ospitare in casa anche il modello. Un guardrail gestito da altri può negarti l’accesso nel momento critico, come è successo a Hugging Face con i modelli chiusi durante la forensica; una capacità che ospiti tu resta disponibile. È la ragione dell’on-premise e dei pesi aperti, ed è ciò che Hugging Face ha mostrato in produzione durante la risposta all’incidente. È lo stesso criterio del nostro paradigma Open Intelligence, Secure Governance: aperto, intelligente, sicuro, governato.

Il punto per chi mette agenti in produzione non cambia: la parte difficile non è farli funzionare, è renderli affidabili, sicuri e governabili. E quella parte sta nel modello e in tutto ciò che gli sta intorno, insieme: autorizzazioni, strumenti, isolamento, monitoraggio e approvazioni umane.

Cosa monitorare

Questa ricostruzione va trattata come provvisoria. Alcuni sviluppi, nei prossimi giorni e settimane, potranno confermarla o smentirla:

una conferma forense indipendente da parte di terzi;
l’esito della verifica di Hugging Face sull’eventuale coinvolgimento di dati di clienti o partner;
la tenuta della lettura di OpenAI (“valutazione uscita dal perimetro, senza intento malevolo”) man mano che emergono dettagli;
la divulgazione del modello pre-release non nominato;
eventuali repliche, o smentite, da parte di altri fornitori.

Finché resta un’indagine preliminare e in gran parte basata sui racconti delle due parti, il post-mortem non è definitivo.

Riferimenti

Serie collegata: anatomia dell’agentic loop · contesto, pattern e multi-agente · sicurezza e governance.

Stefano Noferi — Founder e CEO/CTO di noze
Tech Entrepreneur — AI Governance & Security Architect

Azienda

Azioni

Links

Prodotti

Soluzioni

Settori

Un agente AI viola Hugging Face: cosa insegna l'incidente sulla sicurezza degli agenti