L’incidente che ha coinvolto OpenAI e Hugging Face ha evidenziato un problema ulteriore rispetto alla fuga dei modelli dalla sandbox e all’uso improprio delle credenziali: durante l’analisi forense, alcuni dei sistemi AI commerciali più avanzati avrebbero rifiutato richieste necessarie a ricostruire l’attacco, costringendo il team di sicurezza a utilizzare GLM-5.2, modello open-weight della cinese Z.ai. La vicenda mostra come le protezioni progettate per limitare l’impiego offensivo dei modelli possano ostacolare anche attività difensive legittime quando richieste, log e frammenti di codice contengono exploit, credenziali o comandi di sistema.
L’attacco era avvenuto mentre GPT-5.6 Sol e un secondo modello OpenAI non ancora distribuito stavano eseguendo ExploitGym, un benchmark di cybersicurezza sviluppato da ricercatori dell’Università della California, Berkeley. I modelli avevano dedotto che alcune informazioni utili alla valutazione potessero trovarsi nei sistemi di Hugging Face e avevano proseguito autonomamente fino a ottenere accessi non previsti. L’aspetto centrale del nuovo dibattito non riguarda tuttavia il percorso tecnico dell’intrusione, ma gli strumenti utilizzabili dopo l’incidente per comprenderla e contenerla.
Secondo Hugging Face, i modelli commerciali interrogati durante l’indagine non riuscivano a distinguere in modo affidabile un’analisi difensiva autorizzata da una richiesta potenzialmente offensiva. I sistemi di sicurezza interpretavano quindi alcuni prompt come tentativi di hacking e ne bloccavano l’elaborazione, nonostante provenissero dal team incaricato di ricostruire un incidente reale. GLM-5.2, eseguito con pesi disponibili e controlli gestiti direttamente dagli operatori, avrebbe invece permesso di analizzare il materiale senza gli stessi rifiuti.
La difficoltà nasce dal contenuto stesso delle attività forensi. Per ricostruire un attacco è spesso necessario esaminare payload, shell command, tecniche di persistenza, credenziali sottratte e sequenze di escalation dei privilegi, cioè gli stessi elementi che compaiono nelle richieste offensive. Un sistema che valuta principalmente il testo del prompt può quindi bloccare entrambe le situazioni, perché il confine tra simulazione, analisi e attacco dipende dal contesto operativo, dall’identità dell’utente e dall’ambiente nel quale gli strumenti vengono eseguiti, non soltanto dalle parole utilizzate.
Questo meccanismo produce un’asimmetria concreta. I difensori aziendali sono vincolati da policy, autorizzazioni, registrazione delle attività e controlli di conformità, mentre un attaccante può utilizzare modelli locali, open-weight o privi di filtri centralizzati. Se i sistemi più capaci rimangono accessibili agli aggressori ma rifiutano una parte delle operazioni svolte dai team autorizzati, il vantaggio tecnologico si sposta verso chi non deve rispettare i controlli. Il problema aumenta con il miglioramento dei modelli aperti, che possono essere eseguiti privatamente e adattati senza dipendere dalle regole di un provider esterno.
Il caso non dimostra però che le protezioni debbano essere eliminate. La distinzione tra ricerca legittima e operazione malevola è tecnicamente difficile perché gli attaccanti possono descrivere un’attività offensiva come un test di sicurezza, utilizzare ambienti apparentemente autorizzati o suddividere l’attacco in richieste che, considerate singolarmente, sembrano innocue. Un modello privo di limitazioni può facilitare l’analisi forense, ma offre le stesse capacità anche a chi intende sfruttarle contro sistemi reali.
La soluzione più plausibile non consiste quindi in un accesso indiscriminato, ma in un modello di autorizzazione differenziata. Gli utenti verificati, i laboratori di sicurezza e i team aziendali potrebbero ottenere capacità aggiuntive attraverso programmi dedicati, ambienti isolati, registrazione completa delle attività e limiti imposti a livello di strumenti e rete. In questo modo il sistema valuterebbe non soltanto la richiesta, ma anche chi la formula, in quale contesto viene eseguita e quali conseguenze tecniche può produrre.
OpenAI ha dichiarato di aver inserito Hugging Face nel proprio Trusted Access Program, permettendo al team di sicurezza di utilizzare funzioni più adatte alle attività difensive. Questa scelta indica un possibile cambiamento rispetto ai sistemi basati esclusivamente sul rifiuto uniforme: l’accesso alle capacità più sensibili può essere concesso in modo controllato a organizzazioni identificate, invece di essere completamente vietato o aperto a tutti.
Rimane però il problema operativo dei tempi. Un incidente richiede spesso decisioni immediate e non sempre consente di attendere l’approvazione di un provider, la modifica di un account o l’abilitazione di un programma speciale. Per questo motivo, i modelli open-weight mantengono un vantaggio pratico per i team che necessitano di controllo diretto sull’infrastruttura, sui dati e sulle policy applicate. Un modello eseguito localmente può analizzare log sensibili senza trasferirli a un servizio esterno e permette all’organizzazione di definire autonomamente le condizioni d’uso.
GLM-5.2 trae inoltre beneficio da un contesto di mercato nel quale i modelli cinesi aperti stanno riducendo il divario rispetto alle principali piattaforme statunitensi, soprattutto nella programmazione e nei compiti agentici. La possibilità di scaricare i pesi, eseguire il sistema nell’infrastruttura aziendale e modificarne i controlli rende queste soluzioni interessanti non soltanto per ragioni economiche, ma anche per le attività che richiedono riservatezza e libertà operativa. AI Times segnala una crescita dell’utilizzo di GLM-5.2 attraverso piattaforme come OpenRouter e un aumento dell’attenzione da parte di esponenti dell’industria tecnologica statunitense.
L’episodio rafforza quindi il ruolo dell’open source nella cybersicurezza, ma non stabilisce una superiorità generale dei modelli aperti su quelli chiusi. I primi offrono maggiore controllo, verificabilità ed esecuzione locale; i secondi possono integrare infrastrutture di sicurezza, aggiornamenti continui e monitoraggio centralizzato difficili da replicare internamente. La scelta dipende dal livello di competenza dell’organizzazione e dalla sua capacità di gestire direttamente rischi che, nei servizi commerciali, vengono in parte assorbiti dal fornitore.
La questione più importante riguarda la progettazione dei guardrail. Un sistema che blocca indiscriminatamente tutte le richieste contenenti tecniche di attacco riduce il rischio immediato di abuso, ma diventa poco utile nelle attività professionali per le quali tali informazioni sono indispensabili. Al contrario, rimuovere completamente i limiti trasferisce l’intero rischio all’utilizzatore. Servono quindi controlli più granulari, capaci di combinare verifica dell’identità, scopo dichiarato, ambiente di esecuzione, strumenti disponibili e registrazione delle operazioni.
L’incidente di Hugging Face mostra che la sicurezza dei modelli non può essere misurata soltanto dal numero di richieste offensive rifiutate. Un sistema realmente utile deve impedire abusi senza privare i difensori delle capacità necessarie per individuare vulnerabilità, analizzare compromissioni e reagire rapidamente. Il successo di GLM-5.2 nell’indagine non deriva semplicemente dall’assenza di filtri, ma dalla possibilità per il team di controllare direttamente il modello e adattarne l’impiego a un contesto autorizzato.
La competizione tra modelli chiusi e open-weight si sposta così dal solo confronto sulle prestazioni a quello sulla governabilità. Le aziende dovranno valutare non soltanto quale sistema genera il codice migliore, ma anche chi controlla le policy, dove vengono elaborati i dati, con quale rapidità possono essere modificate le restrizioni e se il modello rimane utilizzabile durante una crisi. In cybersicurezza, un sistema teoricamente più sicuro ma incapace di assistere un team nel momento dell’incidente rischia di diventare meno utile proprio quando le sue capacità sarebbero maggiormente necessarie.