Diciassettemila eventi, e l'API ha detto no

Il momento che conta nella divulgazione di Hugging Face non è l'intrusione. È un membro del team di risposta seduto davanti a un'API a pagamento con le prove in mano che si vede respingere. Il 16 luglio 2026 l'azienda ha pubblicato il resoconto di un incidente di sicurezza in cui, a suo dire, gli attaccanti hanno usato ciò che descrive testualmente come "(a remote-code dataset loader and a template-injection in a dataset configuration)" per eseguire codice su un worker di elaborazione. Ciò che il team aveva dopo era, nelle parole della stessa Hugging Face, "the full attacker action log, comprised of more than 17,000 recorded events". Altrove il post parla di "tens of thousands of automated actions".

Il rifiuto è la notizia, e la frase l'ha scritta Hugging Face stessa. Il post afferma: "This did not work: the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker." L'ultima proposizione è quella che regge tutto. Il sistema non stava giudicando Hugging Face sbagliando. Non aveva alcun modo di formulare quel giudizio.

Tutto quanto sopra poggia sulla parola di Hugging Face, e vogliamo dirlo chiaramente. Non abbiamo alcuna fonte primaria indipendente per i fatti dell'incidente. Nessuna testata li ha confermati; ogni resoconto che abbiamo trovato si limita a riportare il post dell'azienda. Hugging Face non fornisce né una data di intrusione né una di rilevamento, solo "Earlier this week" e "over a weekend". Non nomina alcun fornitore. E dichiara incompleto il proprio lavoro: "We are still completing our assessment of whether any partner or customer data was affected." Questo articolo non è cronaca dell'incidente. È una lettura di ciò che i contratti pubblicati dei fornitori dicono davvero, messa a confronto con la condotta che Hugging Face descrive.

Abbiamo letto le tre policy cercando il divieto

Non c'è. Abbiamo recuperato le policy d'uso pubblicate di Anthropic, OpenAI e Google, e nessuna delle tre vieta di analizzare materiale ostile proveniente da una violazione del proprio sistema. Non è una lettura di comodo. Ogni divieto informatico nei tre documenti è delimitato da una qualificazione, e la condotta che Hugging Face descrive cade fuori da ognuna di esse.

La policy d'uso di Anthropic, in vigore dal 15 settembre 2025, vieta il lavoro volto a "Discover or exploit vulnerabilities in systems, networks, or applications without authorization of the system owner", e vieta separatamente agli utenti di "Create or distribute malware, ransomware, or other types of malicious code". Hugging Face era il proprietario del sistema, quindi la prima clausola non la raggiunge. Analizzava payload che già esistevano, non li creava né li distribuiva, quindi neppure la seconda. Non c'è alcuna eccezione per ricerca sulla sicurezza, risposta agli incidenti o difesa in nessun punto del documento. Il lavoro di jailbreak e prompt injection è vietato solo "without prior authorization from Anthropic", il che contempla un'autorizzazione ma non rimanda ad alcun processo pubblicato per ottenerla.

Le policy d'uso di OpenAI, in vigore dal 29 ottobre 2025, vietano la "destruction, compromise, or breach of another's system or property, including malicious or abusive cyber activity". La qualificazione sta nella parola another's. Il sistema in questione era quello di Hugging Face. Non abbiamo trovato eccezioni per la ricerca sulla sicurezza; l'unico varco di revisione documentato riguarda "national security or intelligence purposes without our review and approval".

La Generative AI Prohibited Use Policy di Google, modificata l'ultima volta il 17 dicembre 2024, dice: "Do not compromise the security of others' or Google's services. This includes generating or distributing content that facilitates: Spam, phishing, or malware." Di nuovo è la qualificazione a fare il lavoro. Sottoporre payload catturati per l'analisi non è generarli né distribuirli. Non c'è eccezione di sicurezza, solo una clausola generale di eccezioni: "We may make exceptions to these policies based on educational, documentary, scientific, or artistic considerations, or where harms are outweighed by substantial benefits to the public." Nessuna via di richiesta, contatto o procedura è documentata. Tutte e tre le policy erano in vigore prima dell'incidente.

Il contratto del vostro fornitore non è il vostro controllo

Questa è la frase che porteremmo davanti a un consiglio di amministrazione. La lacuna non sta nel fatto che il contratto e il classificatore si contraddicano. Sta nel fatto che il contratto non ha mai affrontato la situazione, mentre il classificatore si è comportato come se fosse vietata. Il team di Hugging Face, per sua stessa ricostruzione, ha incontrato un rifiuto per un lavoro che nessuna policy pubblicata dei tre grandi fornitori vieta.

Un operatore che avesse svolto correttamente l'approvvigionamento ci sarebbe finito lo stesso. Avete letto la policy d'uso. Non avete trovato nulla che vieti l'analisi difensiva della vostra violazione, perché non c'è nulla da trovare. Avete firmato. E poi ciò che vi ha respinto è stato il runtime, che è un oggetto diverso dal documento, governato da nessuna condizione che abbiate negoziato e descritto in nessuna clausola che abbiate esaminato. Ciò che avete verificato e ciò che decide alle tre di notte non sono lo stesso sistema.

Stiamo descrivendo una lacuna nei termini pubblicati, non accusando nessuno di averli violati. Sia Anthropic sia OpenAI consentono adattamenti contrattuali, e i termini enterprise non pubblici possono dire qualcosa di molto diverso dalle policy pubbliche; non abbiamo visto quei termini e non possiamo pronunciarci. Né possiamo dirvi perché i rifiuti siano avvenuti. Hugging Face non pubblica trascrizioni dei rifiuti, quindi se i blocchi fossero dettati dalla policy o da un ordinario sovrablocco del classificatore è inconoscibile dall'esterno, e non tireremo a indovinare. Hugging Face non nomina neppure i fornitori che hanno bloccato. Dice soltanto: "we are sharing this feedback with the providers concerned."

Ciò che Hugging Face ha davvero affermato, e ciò che non ha affermato

La valutazione dei danni dell'azienda è più stretta di quanto suggerisca una lettura veloce, e la precisione merita di essere conservata. Hugging Face riferisce "no evidence of tampering with public, user-facing models, datasets, or Spaces, and our software supply chain (container images and published packages) was verified clean". Sono due affermazioni distinte. Nessuna prova di manomissione è un'assenza di riscontri. Verified clean è un'asserzione positiva sulla catena di fornitura, ed è la più forte delle due. Fonderle in una sola rassicurazione è ciò che rende una sintesi dell'incidente meno accurata della divulgazione che sintetizza.

L'attaccante era esso stesso automatizzato, e questo dettaglio rende il problema del volume strutturale anziché sfortunato. Hugging Face descrive la campagna testualmente come "run by an autonomous agent framework (appearing to be built on an agentic security-research harness - used LLM still not known)". Un agente che genera decine di migliaia di azioni produce un registro che una squadra umana non riesce a leggere in tempi utili, ed è esattamente per questo che i soccorritori volevano un modello sopra, ed esattamente lì sono stati bloccati. L'unica istruzione operativa nel post è breve: "we recommend rotating any access tokens and reviewing recent activity on your account."

E Hugging Face ha anticipato l'argomento che qualche lettore vorrà ricavarne, perciò lo citiamo anziché aggirarlo. Il post afferma: "This is not an argument against safety measures on hosted models". Siamo d'accordo, e questo articolo non è quell'argomento. Barriere che non distinguono un incident responder da un attaccante svolgono comunque un lavoro reale contro l'attaccante. Il riscontro qui riguarda ciò che i termini pubblicati omettono e ciò che di conseguenza un operatore dovrebbe verificare, non se i filtri debbano esistere.

Mettete alla prova il rifiuto prima che l'incidente metta alla prova voi

Fissate l'esercitazione in questo trimestre. Prendete materiale ostile reale dai vostri registri, sottoponetelo all'API a cui ricorrereste davvero durante un incidente e mettete per iscritto ciò che torna indietro. Il riscontro che volete non è rassicurazione. È una risposta fattuale a una domanda cui nessun contratto risponderà per voi, ottenuta in un giorno in cui non brucia nulla.

Per un operatore europeo l'orologio rende la cosa concreta anziché teorica. Gli obblighi di segnalazione della NIS2 corrono su un preallarme di 24 ore e una notifica di 72 ore, e DORA impone alle entità finanziarie una propria stretta finestra di notifica iniziale. Quelle scadenze danno per scontato che sappiate caratterizzare l'accaduto. Se la vostra via di analisi si blocca alla terza ora perché un filtro non accetta le vostre stesse prove, l'orologio non si ferma mentre lo scoprite. È la differenza tra scoprirlo in un'esercitazione a tavolino e scoprirlo dentro una finestra regolatoria.

Poi tenete aperta la via che non può essere rifiutata. Il ripiego di Hugging Face, nelle sue parole: "We ran the forensic analysis instead on GLM 5.2, an open-weight model, on our own infrastructure." GLM 5.2 viene da Z.ai, già Zhipu, a Pechino; Hugging Face stessa non caratterizza l'origine del modello, e quell'identificazione è nostra, non sua. L'origine non è il punto. Pesi che possedete, in esecuzione su hardware che controllate, è l'unica configurazione in cui il runtime di terzi non ha voce in capitolo sul fatto che il vostro incidente venga analizzato. Ogni operatore dovrebbe sapere oggi se ne ha una e se funziona.

Da leggere ora: Due giganti dell'IA ora vogliono integrarti  |  I vostri seed MFA erano già usciti prima della patch