La difesa informatica ha un problema che spesso resta nascosto: chi attacca può usare comandi, payload e tecniche offensive senza chiedere il permesso a nessuno. Chi difende, invece, deve analizzare proprio quegli artefatti. E può capitare che il modello incaricato di farlo si rifiuti.
È successo durante un incidente divulgato da Hugging Face il 16 luglio 2026. Hugging Face racconta di aver provato prima alcuni modelli frontier tramite API commerciali. Le richieste, che contenevano grandi volumi di comandi d’attacco reali, payload di exploit e artefatti di comando e controllo, sono state bloccate dai sistemi di sicurezza dei provider. Hugging Face non identifica i provider o i modelli coinvolti.
Hugging Face ha quindi eseguito sulla propria infrastruttura un modello open weight, GLM 5.2. Il modello ha analizzato il log completo delle azioni dell’attaccante, composto da oltre 17.000 eventi registrati. Secondo Hugging Face, questa analisi ha permesso di ricostruire la sequenza temporale, estrarre gli indicatori di compromissione, mappare le credenziali coinvolte e completare in poche ore un lavoro che di solito richiede giorni.
Il 27 luglio 2026 NVIDIA ha annunciato la Open Secure AI Alliance. Le due date non raccontano la stessa notizia: prima è stato divulgato l’incidente, poi è arrivata l’alleanza, con l’obiettivo di costruire e condividere strumenti aperti per la sicurezza dell’AI.
La parte interessante, per me, non è che un modello aperto abbia “vinto” contro i modelli chiusi. La mia lettura del caso è più pratica: quando è servita un’analisi forense, il modello eseguibile in casa era quello che poteva lavorare sui dati reali.
L’incidente che ha mostrato l’asimmetria
Hugging Face ha descritto un’intrusione nella propria infrastruttura condotta da un sistema autonomo composto da agenti AI. Il modello usato dall’attaccante non è noto.
L’accesso iniziale è passato dalla pipeline che elabora i dataset. Un dataset malevolo ha sfruttato due percorsi che permettevano di eseguire codice durante la lavorazione:
- un loader di dataset con esecuzione di codice remoto;
- una template injection nella configurazione del dataset.
Dopo l’accesso iniziale, l’attaccante ha ottenuto privilegi a livello di nodo, raccolto credenziali cloud e del cluster e si è mosso lateralmente in diversi cluster interni. Secondo la divulgazione di Hugging Face, la campagna ha usato molte migliaia di azioni automatiche, sandbox temporanee e un sistema di command and control capace di migrare, appoggiato a servizi pubblici.
Non è un dettaglio da aggiungere all’archivio degli incidenti. È il punto che cambia il lavoro di chi deve difendere l’ambiente.
L’attacco si muove a velocità macchina. L’analisi manuale, invece, deve ricostruire una timeline, distinguere l’attività reale da quella usata come esca, capire quali credenziali sono state toccate e separare il danno effettivo dal rumore.
Hugging Face ha usato una pipeline di rilevamento assistita da modelli per correlare i segnali di sicurezza. Poi ha fatto analizzare agli agenti il log completo delle azioni dell’attaccante, composto da oltre 17.000 eventi registrati. Questo ha permesso di ricostruire la timeline, estrarre gli indicatori di compromissione, mappare le credenziali coinvolte e distinguere l’impatto reale dalle attività usate come esca. Hugging Face dichiara di aver completato in ore un lavoro che normalmente avrebbe richiesto giorni.
Qui l’AI non è il chatbot che riassume un documento. È uno strumento inserito nella risposta a un incidente reale.
Perché i modelli commerciali si sono fermati
Hugging Face ha provato prima a usare modelli frontier attraverso API commerciali. La scelta aveva senso: erano modelli capaci, già disponibili e spesso facili da integrare.
Il problema sono stati i dati.
Hugging Face spiega che l’analisi richiedeva di inviare ai modelli:
- grandi volumi di comandi reali usati dall’attaccante;
- i payload degli exploit;
- gli artefatti di command and control;
- gli eventi registrati nel log delle azioni;
- i riferimenti alle credenziali presenti nei log.
Le richieste sono state bloccate dai guardrail dei provider, che non riuscivano a distinguere il lavoro del team di risposta da quello di un attaccante. Hugging Face non identifica i provider o le API commerciali coinvolti. NVIDIA richiama lo stesso episodio e conferma che gli strumenti di AI chiusi hanno bloccato l’analisi forense.
Va detto con chiarezza: il problema non è l’esistenza dei guardrail. Un modello che genera materiale offensivo senza alcun controllo può essere pericoloso. Il problema nasce quando un controllo progettato per ridurre gli abusi diventa un ostacolo per il difensore che deve analizzare materiale offensivo già prodotto da qualcun altro.
Non è una contraddizione teorica. È un limite operativo concreto.
Chi attacca non deve rispettare policy d’uso. Chi difende, invece, deve affidare i dati a un servizio che può decidere di non elaborarli. Nel caso raccontato da Hugging Face e richiamato da NVIDIA, questa asimmetria ha costretto il team a cambiare modello e ambiente di esecuzione.
Il ruolo del modello open weight
Un modello open weight non è sicuro per definizione, né è automaticamente migliore. Il vantaggio pratico è un altro: puoi eseguirlo e controllarlo sulla tua infrastruttura, con i pesi disponibili per l’uso previsto.
Secondo NVIDIA, Hugging Face ha eseguito GLM 5.2 sulla propria infrastruttura per analizzare oltre 17.000 azioni dell’intrusione. Hugging Face descrive lo stesso lavoro come l’analisi di oltre 17.000 eventi registrati. Questa analisi ha permesso di ricostruire la timeline, estrarre gli indicatori di compromissione, individuare le credenziali coinvolte e distinguere l’impatto reale dalle attività diversive. Hugging Face dichiara di aver completato in ore un lavoro che normalmente avrebbe richiesto giorni.
L’esecuzione sulla propria infrastruttura ha permesso a Hugging Face di superare i limiti incontrati con le API commerciali. Nessun dato dell’attaccante e nessuna delle credenziali citate nei log ha lasciato l’ambiente di Hugging Face. NVIDIA presenta inoltre i modelli e gli harness aperti come strumenti che permettono di proteggere i dati e applicare controlli locali durante le attività di difesa.
Per chi gestisce incidenti di sicurezza, il secondo punto conta almeno quanto il primo. Inviare log, token, nomi di host e comandi usati durante un attacco a un servizio esterno può entrare in conflitto con le policy aziendali, con gli obblighi contrattuali o con la gestione dell’incidente stesso.
Io lavoro con nove agenti AI in produzione, su macchine mie e in Europa. Il principio operativo è semplice: i processi non devono poter aprire canali verso l’esterno senza un controllo esplicito.
Per questo il self-hosting non è una scelta ideologica. In certi casi è il modo più diretto per sapere dove passano i dati e quali sistemi possono leggerli.
Nel mio articolo sui First Principles per l’automazione AI self-hosted parto proprio da qui: prima del modello viene il perimetro operativo. Chi può accedere ai dati? Dove vengono elaborati? Cosa succede se il processo prova a uscire?
La Open Secure AI Alliance arriva dopo l’incidente
NVIDIA ha annunciato la Open Secure AI Alliance il 27 luglio 2026, undici giorni dopo la divulgazione dell’incidente pubblicata da Hugging Face il 16 luglio. NVIDIA descrive l’alleanza come una collaborazione per costruire e condividere strumenti aperti destinati alla sicurezza dell’AI.
L’alleanza nasce con l’obiettivo di sviluppare e condividere strumenti aperti per la sicurezza dell’AI e del software. NVIDIA collega questo lavoro anche alla leadership dell’iniziativa Akrites della Linux Foundation e alle attività della comunità OpenSSF.
Tra i partner fondatori elencati da NVIDIA ci sono aziende e organizzazioni del cloud, della cybersecurity, del software enterprise, dell’open source e della ricerca sull’AI. L’obiettivo dichiarato è mettere a disposizione dei difensori strumenti aperti che possano controllare e considerare affidabili.
La parte che mi interessa di più è il modello mentale.
La sicurezza non può dipendere da pochi sistemi opachi. Servono modelli, harness, dataset, simulatori d’attacco, framework di valutazione e strumenti di red teaming che i difensori possano analizzare, mettere alla prova e migliorare.
NVIDIA dice anche una cosa corretta: la sicurezza dell’AI non dipende soltanto dal fatto che i pesi siano aperti o chiusi. Conta tutto lo stack:
- identità;
- permessi;
- harness;
- guardrail;
- log;
- valutazione.
Un modello aperto collegato direttamente alla rete e dotato di permessi eccessivi non diventa sicuro solo perché i suoi pesi sono disponibili. Può succedere il contrario: diventa più facile da modificare o da usare male.
Ma vale anche l’opposto. Un modello chiuso, accessibile tramite API, non diventa automaticamente utile nella risposta agli incidenti solo perché è molto capace. Se non può leggere gli artefatti necessari alla forense, la sua capacità teorica serve a poco.
Non è open source contro modelli chiusi
La lettura più comoda sarebbe: modello aperto buono, modello chiuso cattivo.
Ma non funziona così.
NVIDIA sostiene che servano entrambi: modelli frontier chiusi e modelli frontier aperti. I primi possono offrire capacità elevate e servizi gestiti. I secondi danno più controllo sull’esecuzione locale, sull’adattamento del modello e sulla trasparenza. Quando devi proteggere sistemi sensibili, queste differenze pesano.
Per me il punto è scegliere il sistema in base al lavoro da svolgere.
Per una richiesta generica, un’API commerciale può essere la scelta più rapida. Nel caso raccontato da Hugging Face, però, l’analisi richiedeva di inviare grandi volumi di comandi d’attacco reali, payload di exploit e artefatti di comando e controllo. Le protezioni dei servizi commerciali hanno bloccato quelle richieste.
In un contesto del genere mi servono almeno:
- esecuzione nel mio ambiente;
- controllo sugli accessi ai dati;
- possibilità di verificare il comportamento;
- una procedura già provata;
- un piano per sostituire il modello se non è disponibile.
Il vendor lock-in non riguarda solo il prezzo o la dipendenza da un’API. Include anche il rischio di scoprire durante un incidente che il servizio più comodo non è in grado di fare il lavoro necessario.
È per lo stesso motivo che, quando parlo di strumenti locali come OpenUI con Ollama, insisto meno sulla demo e più sul confine dei dati. Il valore del locale non sta nel dire “mai il cloud”. Sta nel poter decidere quando il cloud non è accettabile.
La prova da fare prima dell’incidente
La lezione operativa è semplice: devi decidere prima quale modello userai per leggere i log.
Non durante l’incidente. Prima.
Una procedura minima dovrebbe verificare:
- quali dati finiscono nel contesto del modello;
- se il modello può girare senza inviare dati all’esterno;
- come vengono gestiti credenziali, token e riferimenti ai sistemi interni;
- quali limiti ha il modello quando incontra comandi e payload offensivi;
- se riesce a ricostruire una timeline partendo da log reali o rappresentativi;
- quali permessi ha l’agente durante l’analisi;
- come viene registrata ogni sua azione.
Non basta installare un modello e chiedergli di riassumere un file. Io lo proverei con gli stessi tipi di materiale che, nel caso raccontato da Hugging Face, sono stati bloccati dai sistemi di sicurezza delle API commerciali: grandi volumi di comandi d’attacco reali, payload di exploit e artefatti di comando e controllo.
Naturalmente i dati di test vanno gestiti con criterio. Non si copia un incidente reale dentro un ambiente improvvisato. Il test deve però assomigliare abbastanza al lavoro quotidiano da dirti se il modello è davvero utilizzabile quando serve.
Lo stesso discorso vale per l’orchestrazione. Il modello non dovrebbe avere accesso indiscriminato alla rete, al filesystem e ai segreti. Va inserito in un harness con permessi minimi, log completi e un controllo che impedisca ai processi di aprire canali verso l’esterno senza autorizzazione.
Un modello locale non sostituisce la sicurezza dell’infrastruttura. Durante l’analisi, però, ti permette di tenere meglio sotto controllo dove finiscono i dati e cosa può fare l’agente.
La mia conclusione
L’Open Secure AI Alliance non dimostra che l’open source risolva la cybersecurity. Dimostra una cosa più specifica e, per chi deve gestire un incidente, più utile: nella difesa informatica possono contare più la disponibilità del modello e il controllo sui dati della sua posizione in classifica.
L’incidente divulgato da Hugging Face il 16 luglio 2026 ha mostrato il problema sul campo. Hugging Face racconta che i modelli commerciali provati tramite API hanno bloccato l’analisi di grandi volumi di comandi d’attacco reali, payload di exploit e artefatti di comando e controllo. I provider e le API coinvolte non sono stati indicati. Con GLM 5.2, Hugging Face ha ricostruito la sequenza dell’attacco in poche ore, invece dei giorni normalmente necessari.
Hugging Face ha eseguito GLM 5.2 sulla propria infrastruttura per analizzare oltre 17.000 eventi registrati. I dati dell’attaccante e le credenziali citate nei log sono rimasti nel suo ambiente. La mia lettura del caso è questa: il modello eseguibile in casa era quello che poteva lavorare sui dati reali senza essere bloccato e senza farli uscire dal perimetro.
L’alleanza annunciata da NVIDIA il 27 luglio 2026 prova a trasformare questa lezione in un programma più ampio: strumenti aperti, valutazioni condivise, ricerca sui sistemi agentici e difese controllabili da più soggetti.
Per me il messaggio è semplice.
Non devi scegliere oggi il modello da usare durante il prossimo incidente. Devi averlo già scelto, isolato, valutato e provato.
Quando la difesa non può aspettare, scoprire che il tuo modello non riesce a leggere l’attacco significa averlo capito troppo tardi.
Perché un modello aperto può essere più utile durante un incidente?
Hugging Face racconta che i modelli accessibili tramite API commerciali hanno bloccato l’analisi di comandi d’attacco reali, payload di exploit e artefatti di comando e controllo. Eseguendo GLM 5.2 sulla propria infrastruttura, ha potuto analizzare oltre 17.000 eventi registrati senza far uscire dal proprio ambiente i dati dell’attaccante e le credenziali citate.
I guardrail dei modelli commerciali non servono anche alla sicurezza?
Servono a ridurre gli abusi, ma durante una risposta a un incidente possono creare un effetto paradossale. Hugging Face spiega che i sistemi provati non distinguevano il lavoro del difensore da quello dell’attaccante e bloccavano il materiale necessario all’analisi. In quel contesto, il rifiuto ha ostacolato la risposta all’incidente.
Far girare il modello in locale significa rinunciare alla sicurezza?
No, significa spostare la responsabilità sotto il controllo dell’organizzazione. Nel mio caso scelgo macchine in Europa e un controllo che impedisce ai processi di aprire canali verso l’esterno. La sicurezza non dipende soltanto dal modello, ma anche da isolamento, autorizzazioni, logging e controllo dei dati.
Come è iniziato l’incidente di Hugging Face?
Hugging Face descrive un dataset malevolo che ha sfruttato due strade di esecuzione di codice durante la lavorazione dei dataset. La prima coinvolgeva un loader capace di eseguire codice remoto, la seconda una template injection nella configurazione del dataset. Da lì, l’attaccante ha ottenuto accesso al nodo, raccolto credenziali cloud e del cluster e si è spostato lateralmente in diversi cluster interni.
Open Secure AI Alliance e incidente di luglio sono la stessa cosa?
No, sono due eventi distinti. Hugging Face ha divulgato l’incidente il 16 luglio 2026, mentre NVIDIA ha annunciato la Open Secure AI Alliance il 27 luglio 2026, richiamando anche quell’episodio. L’alleanza punta a fornire ai difensori strumenti aperti e avanzati che possano controllare e considerare affidabili.
Come posso capire prima dell’emergenza quale modello usare?
Bisogna provarlo prima, con materiale realistico ma controllato: log, comandi sospetti, payload disarmati e artefatti simili a quelli che si incontrano davvero. Verificherei rifiuti, qualità dell’analisi, funzionamento offline, isolamento dei dati e costi operativi. Scoprire durante l’incidente che il modello non tratta il contesto necessario è troppo tardi.
Per la stesura dell’articolo sono state consultate fonti ufficiali e documentazione tecnica relative a Open Secure AI Alliance, modello aperto per la difesa.
NVIDIA Blog
Industry Leaders Unite in Open Secure AI Alliance for AI Safety and Security
È la fonte diretta per verificare finalità, impostazione collaborativa e sviluppo di strumenti aperti per la sicurezza e l’affidabilità dell’AI.
Apri fonteHugging Face
Security incident disclosure - July 2026
È utile per approfondire il tema concreto della divulgazione e della gestione degli incidenti di sicurezza nelle piattaforme dedicate a modelli, dataset e applicazioni AI.
Apri fonte
Nuovo su Google
Aggiungi francescogruner.it come fonte preferita
Se leggi spesso i miei articoli su AI, automazione e tecnologia, ora puoi dire a Google che vuoi vedere più spesso i contenuti di francescogruner.it tra le notizie.
