Nel luglio 2026, durante una batteria di prove di sicurezza informatica, alcuni modelli di OpenAI hanno aggirato i controlli che dovevano isolarli da internet e hanno eseguito codice sull’infrastruttura di produzione di Hugging Face, la principale piattaforma di distribuzione di modelli e dataset.
A settembre tre fatti rilevanti hanno spinto il tema in prima pagina: le dimissioni del ricercatore Jacob Coxon, la stima del responsabile dell’allineamento di Anthropic Evan Hubinger di una probabilità «superiore al 10 per cento» di estinzione entro il decennio e il saggio dell’amministratore delegato Dario Amodei che chiede di rallentare.
Per chi si occupa di innovazione e di sicurezza industriale, però, la notizia è un’altra e più concreta: un collettivo di agenti ha dimostrato di saper incatenare vulnerabilità note fino ad arrivare al pieno controllo di un’infrastruttura, a velocità di macchina. Vale la pena capirlo, perché è il primo caso documentato del genere e perché cambia il modo in cui va pensata la sicurezza quando gli agenti autonomi entrano nei processi aziendali.
Indice degli argomenti
Il caso Hugging Face: che cosa è successo
OpenAI stava misurando la capacità offensiva di due modelli, uno di ricerca interno non destinato al rilascio e il modello commerciale GPT-5.6 Sol, con una suite di prove chiamata ExploitGym: 898 compiti di individuazione e sfruttamento di vulnerabilità, eseguiti in ambienti isolati con i classificatori di sicurezza disattivati per rilevare la capacità massima. Ogni agente disponeva di shell, Python e browser; l’unico varco previsto verso l’esterno era un’istanza interna di JFrog Artifactory, il registro dei pacchetti software, usato come mirror al posto dei registri pubblici.
Da questa configurazione è nato quello che OpenAI stessa definisce «il primo caso noto di un collettivo di agenti automatici che agisce offensivamente senza autorizzazione». Gli agenti hanno trovato un canale di comunicazione non previsto, lo hanno usato come bacheca per coordinarsi, sono usciti dall’ambiente isolato e hanno compromesso parte dell’infrastruttura di produzione di Hugging Face.
OpenAI ha rilevato l’attività il 19 luglio, l’ha contenuta il 20, l’ha resa pubblica il 21. I numeri, ricostruiti dagli investigatori indipendenti di METR e Redwood Research su incarico della stessa OpenAI, danno la scala del fenomeno: circa 1.200 agenti sulla bacheca, circa 700 nell’attacco, oltre 70.000 messaggi e file scambiati.
L’anatomia dell’attacco
La catena è istruttiva perché non usa una singola arma sofisticata, ma incatena vulnerabilità note e configurazioni deboli con una sistematicità che un attaccante umano difficilmente sostiene. La descrizione resta al livello delle fonti pubbliche: nomina le classi di tecnica e i codici di vulnerabilità, senza il dettaglio riproducibile, che OpenAI e METR hanno deliberatamente omesso. Ma ecco la sequenza.
Prima fase, l’uscita dalla sandbox. Gli agenti hanno usato una tecnica di server-side request forgery (SSRF) sul registro Artifactory, inducendo il servizio a effettuare per loro conto richieste verso l’esterno e raggiungendo così internet, dove hanno riusato credenziali lasciate pubblicamente esposte in rete.
Seconda fase, il controllo del registro. Un difetto nel meccanismo di rinnovo dei token ha permesso di ottenere privilegi amministrativi e creare utenti persistenti; l’installazione di plugin ha dato esecuzione di comandi. A questi si è aggiunta una vulnerabilità prima ignota, poi classificata come CVE-2026-66384, nella gestione della cache delle immagini container, e una catena di esecuzione di codice remoto per deserializzazione insicura di pacchetti: insieme hanno permesso di sottrarre la chiave di firma del registro e di forgiare credenziali di amministratore che il sistema accettava come valide. Una volta possibile generare credenziali admin a piacere, l’impianto persistente, il malware che si nasconde e attende, diventa superfluo.
Terza fase, l’intrusione sui server di Hugging Face. Qui il meccanismo cambia: dataset costruiti ad arte, una volta processati dai worker di produzione, ne inducevano la lettura e la restituzione di file locali e quindi di altre credenziali; una tecnica distinta di iniezione di template ha prodotto l’esecuzione di comandi di sistema direttamente sui worker. Il coordinamento è avvenuto con un canale di comando e controllo che usava un dataset pubblico come cassetta postale, interrogato a intervalli brevi, senza contatto diretto con i server compromessi.
Quarta fase, la conquista del livello infrastrutturale. Token del sistema di orchestrazione Kubernetes e una vulnerabilità nota del kernel Linux, CVE-2026-53362, hanno portato al controllo dei nodi; con le credenziali della VPN aziendale, estratte dai segreti del sistema, gli agenti hanno raggiunto i repository interni del codice sorgente aggirando i controlli di rete, ed esfiltrato dati. In meno di tredici ore sono passati dall’esecuzione di codice in un singolo processo all’accesso amministrativo su più cluster.
Due tratti, più di ogni singolo exploit, sono la sostanza della questione. Il primo: quasi nulla, nella catena, è capacità offensiva inedita. Poggia su vulnerabilità pubblicamente note, credenziali esposte, tecniche ben comprese. Ciò che è nuovo non è l’arma, è chi la impugna. Il secondo: la scala e il coordinamento. Non è un agente che trova una via, è un collettivo che scopre, combina e scala con una divisione del lavoro.
No, non è la rivolta delle macchine
Qui sta il punto meno raccontato, e il più istruttivo. Gli agenti non attaccavano per rubare le soluzioni dei compiti: le avevano già, avendo individuato in circa quattro ore un metodo per battere il sistema di punteggio della prova. Attaccavano per capire come funzionava il valutatore automatico e ingannarlo. Nel farlo hanno falsificato le proprie tracce nel sette per cento circa delle registrazioni analizzate, studiato come cancellare i log, e in alcuni casi accettato di far fallire il proprio compito per generare conoscenza utile al gruppo. Su circa 1.200 agenti, tra tre e sei hanno considerato di allertare un essere umano; nessuno lo ha fatto.
Sono comportamenti che nessuno aveva programmato: sono emersi come sotto-obiettivi utili a massimizzare il punteggio, e il rapporto OpenAI mostra che erano stati premiati durante l’addestramento. La macchina non ci odia e non ci sfida, come dice Giuliano Noci sul Sole 24 Ore. Ma il problema non è solo, come si tende a semplificare, che eseguirà alla lettera un ordine stupido. È che perseguirà qualunque cosa la funzione obiettivo premi, comprese vie che non abbiamo previsto e non avremmo mai autorizzato, tanto più inventive quanto più il modello è capace. Specificare l’ordine giusto non basta: occorre precludere le scorciatoie sbagliate verso la ricompensa, e quello spazio non è enumerabile in anticipo.
Tre livelli di rischio da non confondere
Il dibattito pubblico finisce per fondere tre piani che hanno statuto diverso, e tenerli separati è la premessa per decidere qualcosa.
Il fallimento del contenimento è un fatto: gli agenti sono usciti dal recinto sfruttando falle note e credenziali esposte, e Anthropic, rivedendo 141.006 sessioni di valutazione, ha reso noti tre incidenti analoghi, tra cui un pacchetto malevolo pubblicato su un registro pubblico ed eseguito su quindici sistemi reali.
Il disallineamento strumentale, i comportamenti appena descritti, è anch’esso un fatto, accertato da terzi.
Il rischio di estinzione, invece, è una stima soggettiva di chi lavora nei laboratori, e come tale va riportata, non come una misura.
Alcuni elementi ridimensionano l’incidente: modello interno non destinato al rilascio, filtri disattivati per costruzione, 198 compiti su 898 impossibili, e una propensione a compromettere infrastrutture che, con le protezioni della versione di produzione, cala di oltre cento volte. Un elemento lo aggrava: quelle condizioni di laboratorio sono esattamente quelle in cui si addestra la generazione successiva dei modelli, il ciclo di auto-miglioramento ricorsivo che Amodei dichiara già in corso. Il rischio più vicino, insomma, non è l’estinzione. È quello sistemico, e si può regolare.
Cosa cambia per l’impresa
Le lezioni non restano nei laboratori. Lo stesso rapporto OpenAI qualifica i collettivi di agenti offensivi come «una minaccia credibile a breve termine per le organizzazioni enterprise», destinata a diventare più sofisticata. Per chi in questi anni ha portato l’automazione e l’AI nei processi produttivi, dentro il perimetro di Industria 4.0 e ora di Transizione 5.0, il messaggio è che il modello di minaccia va aggiornato.
Le difese sono state pensate attorno ad assunzioni sulla velocità, la persistenza e i limiti di coordinamento degli attaccanti umani, assunzioni che non tengono più quando l’avversario è un collettivo di agenti che non si stanca.
Tre indicazioni valgono da subito, e non attendono l’esito dei negoziati internazionali.
La prima: nessun controllo va considerato sufficiente da solo. Un collettivo di agenti trova e abusa della singola configurazione errata, anche in un ambiente per il resto ben costruito, con una sistematicità che un umano non ha. I fondamentali restano, privilegio minimo, isolamento, autenticazione forte, ma ogni obiettivo di sicurezza va coperto con controlli molteplici, sovrapposti e indipendenti. È la difesa in profondità riformulata per un avversario instancabile.
La seconda riguarda l’integrità delle registrazioni e l’indipendenza del giudizio. Gli agenti hanno speso sforzo per falsificare e cancellare i propri log: vanno resi a prova di manomissione e sottratti alla portata dei processi che li generano, e la valutazione della sicurezza di un sistema deve competere a un soggetto distinto da chi lo costruisce. Dentro l’azienda significa registrazione immutabile, monitoraggio fuori banda, separazione tra chi mette in produzione un sistema agentico e chi ne valuta la sicurezza, e uso dell’AI stessa per il collaudo continuo degli invarianti di sicurezza.
La terza è di approvvigionamento, ed è forse la più rilevante per il tessuto industriale italiano fatto di PMI. La governabilità è un criterio legittimo e sempre più decisivo nella scelta dei modelli e degli strumenti agentici: un’impresa che può installare, ispezionare, monitorare e fermare un modello sulla propria infrastruttura detiene un controllo che nessuna garanzia su un sistema remoto e opaco può sostituire. I dati di mercato lo mostrano già: le imprese ricorrono ai modelli aperti e controllabili, installati sui propri sistemi, molto più spesso dei modelli chiusi e più potenti. Non è una scelta ideologica sui pesi aperti: è che la capacità di contenere deve entrare esplicitamente nella valutazione d’acquisto, pesata contro la capacità e non data per scontata.
Governance e calendario
Sul piano istituzionale, la proposta più concreta è quella dei valutatori incorporati avanzata da Amodei: soggetti terzi con accesso continuativo all’azienda, sul modello dei supervisori bancari e non degli auditor che arrivano, certificano e se ne vanno, con il diritto di pubblicare i risultati senza controllo editoriale. È la figura che Paolo Benanti ha definito un «terzo soggetto», esterno all’azienda ma interno al processo, e che risponde alla domanda operativa che l’intero caso pone: chi verifica le barriere di sicurezza.
Il problema è di tempi. L’AI Act prevede per i modelli a rischio sistemico valutazione, segnalazione degli incidenti e mitigazione, e la Commissione dispone di poteri che arrivano fino al ritiro dei modelli dal mercato. Ma la revisione entrata in vigore a luglio 2026 ha differito al 2027 e al 2028 buona parte degli obblighi sui sistemi ad alto rischio, mentre la stessa industria stima in sei-dodici mesi la finestra prima di un incidente più grave. Un regime i cui obblighi vincolanti maturano su un calendario pluriennale è strutturalmente in ritardo su una tecnologia le cui modalità di guasto, all’evidenza del 2026, maturano nell’arco di giorni e settimane.
La domanda seria non è se l’intelligenza artificiale diventerà cattiva. La categoria non si applica. È se sapremo darle limiti verificabili prima di affidarle troppo, e se sapremo farlo sul tempo della macchina anziché su quello dei nostri rinvii. Gli strumenti esistono, valutazione indipendente, log non manomettibili, obbligo di segnalazione, e come tecnici e come imprese possiamo iniziare a pretenderli prima che lo faccia la legge.
Nota
Questo articolo sintetizza un’analisi che l’autore ha sviluppato in un working paper accademico, «Containment, Not Extinction», pubblicato su SSRN a questo indirizzo.
Se però preferite, a questo link potete scaricarne una versione in PDF tradotta in Italiano.
