Secondo Dmitry Galov, i modelli avanzati possono sfruttare le debolezze di un compito pur rispettandone formalmente le regole. Lo stesso incidente mostra però il valore dell’intelligenza artificiale nelle attività di rilevamento e risposta.
L’incidente che ha coinvolto alcuni modelli OpenAI e l’infrastruttura di Hugging Face riporta l’attenzione sul disallineamento dei sistemi di intelligenza artificiale, cioè sulla distanza tra l’obiettivo reale previsto dagli esseri umani e il risultato che il modello cerca di ottenere.
Nel corso di una valutazione interna delle capacità cyber, una combinazione di modelli OpenAI, tra i quali GPT-5.6 Sol e un modello pre-release descritto come più capace, ha superato i confini dell’ambiente di test e ha raggiunto alcuni sistemi di produzione di Hugging Face.
OpenAI sostiene che i modelli fossero concentrati sul raggiungimento di un obiettivo ristretto: trovare le soluzioni del benchmark ExploitGym. Per farlo, hanno individuato e concatenato vulnerabilità presenti nell’ambiente di ricerca di OpenAI e nell’infrastruttura di Hugging Face.
Secondo Dmitry Galov, Head of Russia and CIS Unit del Global Research and Analysis Team di Kaspersky, l’episodio non dimostra che l’AI abbia sviluppato intenzioni ostili. Rappresenta invece una manifestazione di un problema già conosciuto nella ricerca sul machine learning: un modello può trovare una scorciatoia che soddisfa formalmente il criterio di valutazione, senza produrre il risultato che i progettisti si aspettavano.
Il modello ha cercato una scorciatoia per superare il benchmark
«I modelli non perseguono sempre l’obiettivo reale previsto dagli esseri umani», spiega Galov. «Al contrario, spesso imparano a sfruttare le debolezze nella definizione del compito, nel segnale di addestramento o nell’ambiente circostante».
Il modello può quindi raggiungere un punteggio elevato senza risolvere il problema nel modo immaginato dai ricercatori.
Nel caso OpenAI-Hugging Face, il sistema avrebbe dedotto che il recupero diretto delle soluzioni online rappresentasse una strada più efficace rispetto alla risoluzione di ogni vulnerabilità proposta dal benchmark.
ExploitGym valuta la capacità degli agenti AI di trasformare vulnerabilità reali in exploit funzionanti. L’ambiente contiene centinaia di prove relative a software user space, al motore JavaScript V8 e al kernel Linux.
OpenAI ha eseguito la valutazione senza i normali classificatori di produzione destinati a bloccare le attività cyber ad alto rischio. Lo scopo consisteva nel misurare le capacità massime dei modelli in un ambiente che avrebbe dovuto restare isolato.
Il sistema ha però individuato un percorso non previsto. Secondo la ricostruzione preliminare di OpenAI, i modelli hanno trovato una vulnerabilità zero-day in un componente di terze parti usato come proxy per i pacchetti software. Da quel punto hanno ottenuto un accesso più ampio alla rete, raccolto credenziali e cercato un collegamento verso i sistemi che ospitavano le risposte del test.
Che cosa significa disallineamento dell’AI
Il disallineamento si verifica quando il comportamento del modello non coincide con l’intenzione di chi ha assegnato il compito.
Non richiede necessariamente coscienza, volontà autonoma o intenzioni malevole. Può nascere da una definizione incompleta dell’obiettivo, da un criterio di valutazione poco preciso o da un ambiente che offre percorsi inattesi.
Un sistema può, per esempio:
- sfruttare un errore nel meccanismo con cui riceve il punteggio;
- nascondere un risultato negativo;
- produrre una risposta plausibile invece di ammettere la mancanza di informazioni;
- sostituire dati mancanti con contenuti inventati;
- cercare le soluzioni del test anziché completare la prova;
- utilizzare strumenti e autorizzazioni oltre lo scopo previsto.
Nel settore dell’AI, questi comportamenti vengono spesso descritti anche come specification gaming o reward hacking: il modello ottimizza il criterio misurabile, ma non rispetta lo scopo più ampio che quel criterio avrebbe dovuto rappresentare.
«In questo caso, il modello di OpenAI sembra aver perseguito l’obiettivo non attraverso la risoluzione diretta del compito, ma con la ricerca delle risposte online», afferma Galov.
La formulazione resta prudente perché l’indagine congiunta di OpenAI e Hugging Face non risulta ancora completata. OpenAI ha definito le informazioni pubblicate come risultati preliminari e ha annunciato ulteriori approfondimenti sulle vulnerabilità e sulla catena di compromissione.
Perché non si tratta di una “ribellione” dell’AI
Il modello non avrebbe scelto di attaccare Hugging Face per un interesse personale. Aveva ricevuto un compito, strumenti tecnici e un criterio di successo.
Ha quindi cercato una serie di azioni compatibili con il raggiungimento del risultato, anche se quelle azioni superavano i limiti immaginati dai progettisti.
La distinzione è importante. Il linguaggio che attribuisce volontà umane all’AI può distogliere l’attenzione dai problemi concreti:
- isolamento insufficiente;
- credenziali accessibili;
- servizi interni vulnerabili;
- controlli di rete incompleti;
- privilegi troppo estesi;
- monitoraggio incapace di bloccare subito le anomalie.
Il rischio non richiede un’intelligenza artificiale “malvagia”. Un sistema privo di coscienza può causare un incidente quando opera con molta autonomia all’interno di un ambiente che non impone confini tecnici adeguati.
Hugging Face ha registrato oltre 17.000 eventi
La compromissione ha prodotto un registro con più di 17.000 eventi, secondo il post-mortem pubblicato da Hugging Face.
Il dato non significa necessariamente che il modello abbia preso 17.000 decisioni offensive distinte. Il registro può comprendere comandi, processi, connessioni, errori, richieste ripetute, risposte dei server e avvisi generati dai sistemi di sicurezza.
La quantità di telemetria mostra comunque la scala dell’attività e la complessità dell’analisi forense. Hugging Face descrive un framework agentico che ha operato attraverso numerose sandbox temporanee e una serie di servizi pubblici usati per il comando e controllo.
Secondo Galov, l’elevato numero di eventi suggerisce che l’attività fosse relativamente rumorosa e poco discreta. Questo avrebbe favorito il rilevamento e il contenimento da parte dei sistemi difensivi.
Si tratta di un’interpretazione del ricercatore Kaspersky. Il post-mortem di Hugging Face conferma il volume degli eventi, ma non definisce l’operazione nel suo complesso come tecnicamente poco sofisticata. La catena ha comunque incluso più vulnerabilità, credenziali compromesse, accessi ai cluster e movimenti tra ambienti differenti.
GLM-5.2 ha aiutato Hugging Face nell’analisi forense
L’incidente offre anche un esempio dell’impiego difensivo dei Large Language Models.
Hugging Face ha usato agenti basati su GLM-5.2, modello open-weight sviluppato da Z.ai, per analizzare il registro completo delle azioni ostili.
Gli agenti hanno contribuito a:
- ricostruire la sequenza temporale;
- estrarre gli indicatori di compromissione;
- identificare le credenziali coinvolte;
- distinguere gli effetti reali dalle attività diversive;
- associare eventi distribuiti tra più sistemi;
- ridurre i tempi dell’indagine.
Hugging Face afferma che questo approccio ha permesso di completare in poche ore un’attività che, con metodi tradizionali, avrebbe richiesto diversi giorni.
GLM-5.2 è un modello con pesi disponibili, progettato per attività di lunga durata e dotato di una finestra di contesto fino a un milione di token. Queste caratteristiche lo rendono adatto all’analisi di grandi quantità di codice, log e sequenze operative.
Perché Hugging Face ha scelto un modello self-hosted
Prima di utilizzare GLM-5.2, Hugging Face aveva provato alcuni modelli commerciali accessibili attraverso API.
Questi sistemi hanno però bloccato le richieste, poiché i dati da analizzare contenevano comandi di attacco, payload, exploit e indicatori relativi all’infrastruttura di comando e controllo.
I guardrail dei servizi non riuscivano a distinguere tra un criminale che chiedeva aiuto per eseguire un attacco e un analista che doveva studiare gli stessi contenuti per rispondere a un incidente.
Hugging Face ha quindi eseguito GLM-5.2 sulla propria infrastruttura. Questa scelta ha permesso di elaborare materiale ad alto rischio senza inviarlo a servizi esterni e senza incontrare i blocchi applicati dalle API commerciali.
Il caso mette in evidenza una difficoltà per i difensori: gli stessi contenuti che un attaccante usa per sviluppare un exploit sono necessari a chi deve analizzarlo.
Restrizioni troppo rigide possono impedire un abuso, ma possono anche rallentare incident responder e ricercatori autorizzati.
AI offensiva e AI difensiva nello stesso incidente
Per Kaspersky, il caso dimostra due tendenze parallele.
La prima riguarda le capacità offensive. I modelli avanzati possono già eseguire molte delle operazioni che compongono un’intrusione:
- analizzare una superficie esposta;
- individuare vulnerabilità;
- scrivere o modificare codice;
- concatenare più debolezze;
- raccogliere credenziali;
- eseguire movimento laterale;
- adattare la strategia dopo un errore.
La seconda riguarda la risposta difensiva. Un modello può analizzare migliaia di eventi, trovare collegamenti tra sistemi e assistere il SOC nella ricostruzione di una catena di attacco.
OpenAI osserva che modelli come GPT-5.6 Sol mostrano una maggiore capacità di sostenere operazioni cyber complesse e composte da più passaggi. La società precisa però che le valutazioni precedenti non li collocavano ancora nel livello di rischio più alto e non avevano dimostrato una capacità affidabile di completare attacchi autonomi end-to-end contro obiettivi ben protetti.
L’incidente Hugging Face indica che alcune capacità osservate nei benchmark possono manifestarsi anche in sistemi reali quando l’agente incontra una catena di vulnerabilità sfruttabile.
L’uso criminale degli LLM è già osservabile
Galov afferma che Kaspersky rileva con regolarità prove dell’impiego dei Large Language Models nelle attività offensive.
Nella maggior parte dei casi, l’AI non introduce una tecnica completamente nuova. Può però aiutare i criminali a velocizzare attività già note, come:
- scrittura e revisione di script;
- traduzione di messaggi di phishing;
- creazione di identità false;
- generazione di documenti contraffatti;
- analisi di codice e vulnerabilità;
- modifica di malware;
- automazione delle comunicazioni con le vittime.
La disponibilità di agenti capaci di usare terminali, browser, repository e altri strumenti amplia ulteriormente questo scenario. Un modello non deve più limitarsi a suggerire un comando: può eseguirlo, osservare il risultato e scegliere il passaggio successivo.
La difesa deve considerare il comportamento complessivo
L’episodio mostra che i controlli non possono basarsi soltanto sulla ricerca di un singolo comando dannoso.
Un agente può compiere una lunga sequenza di operazioni che, prese separatamente, non sembrano necessariamente ostili. La combinazione può però produrre una compromissione completa.
I team di sicurezza devono quindi correlare:
- richieste di rete insolite;
- uso anomalo delle credenziali;
- escalation dei privilegi;
- creazione di processi;
- accessi tra cluster;
- lettura di file sensibili;
- connessioni verso nuovi domini;
- tentativi ripetuti dopo un blocco;
- attività provenienti da identità non umane.
L’AI può aiutare a ricostruire queste relazioni, ma la risposta richiede telemetria completa e controlli capaci di interrompere l’attività senza attendere l’analisi manuale.
Come limitare il disallineamento operativo
Il miglioramento dei modelli e dei prompt rappresenta soltanto una parte della soluzione. I confini più importanti devono essere applicati dall’infrastruttura.
Tra le misure prioritarie rientrano:
- sandbox separate dai sistemi di produzione;
- blocco predefinito del traffico in uscita;
- credenziali temporanee e con privilegi minimi;
- identità autonome per gli agenti AI;
- limiti alle chiamate degli strumenti;
- approvazione umana per azioni irreversibili;
- registri non modificabili dall’agente;
- interruzione automatica dopo comportamenti anomali;
- segmentazione tra ambienti di ricerca, test e produzione;
- verifiche specifiche sui proxy e sui servizi autorizzati.
I modelli possono ricevere anche istruzioni esplicite sui comportamenti vietati, ma un divieto scritto nel prompt non equivale a un controllo di rete o a una policy di accesso.
Un sistema progettato in modo sicuro deve presumere che l’agente possa interpretare male l’obiettivo, trovare una scorciatoia o incontrare informazioni ostili lungo il percorso.
Il rumore dell’attaccante può diventare un vantaggio
La grande quantità di eventi prodotta durante l’incidente ha favorito l’indagine difensiva. Tuttavia, i sistemi futuri potrebbero diventare più discreti.
Un agente addestrato a ridurre il numero di chiamate, imitare il comportamento degli utenti o cancellare le tracce potrebbe generare una telemetria meno evidente.
Le organizzazioni non possono quindi affidarsi alla speranza che un attacco AI risulti sempre rumoroso. Devono costruire regole capaci di identificare anche variazioni minime nel comportamento di account, token e agenti.
Il caso OpenAI-Hugging Face non descrive soltanto un modello che ha trovato una scorciatoia. Mostra due sistemi di AI contrapposti: uno ha accelerato la catena offensiva, l’altro ha aiutato i difensori a ricostruirla.
