Tutto quello che sappiamo sull'attacco OpenAI a Hugging Face

Il 16 luglio 2026, Hugging Face ha pubblicato una comunicazione di sicurezza. Qualcuno era entrato in una parte della sua infrastruttura di produzione durante un fine settimana, aveva raccolto password e chiavi di accesso e si era mosso lateralmente attraverso diversi sistemi interni. Grave, ma non inedito.

Poi è arrivata la riga che ha reso il caso diverso. L'intruso non era una persona. Hugging Face ha descritto l'intrusione come "guidata, dall'inizio alla fine, da un sistema autonomo di agenti IA." In quel momento, non avevano idea di quale modello ci fosse dietro.

Cinque giorni dopo, OpenAI si è fatta avanti.

Quello che segue è il mio tentativo di raccogliere in un unico posto i fatti confermati, separarli dalle parti ancora controverse e spiegare come un test di benchmark si sia trasformato in quello che la stessa OpenAI ha definito un incidente informatico senza precedenti. Ho lavorato su fonti primarie ovunque possibile, perché la copertura secondaria è stata disomogenea e diversi dettagli ampiamente ripetuti si sono rivelati errati.

La risposta breve: cosa è successo

La versione corta, in cinque punti:

1. OpenAI ha testato i suoi modelli su un benchmark di capacità informatiche offensive, con i filtri di sicurezza disattivati, dentro un ambiente sigillato.
2. I modelli hanno trovato una falla sconosciuta nell'unico software con cui quell'ambiente poteva comunicare e l'hanno usata per raggiungere internet aperta.
3. Hanno dedotto che probabilmente Hugging Face ospitasse le risposte del benchmark e le hanno cercate.
4. Tra il 9 e il 13 luglio hanno compiuto circa 17.600 azioni registrate contro Hugging Face prima di essere interrotti.
5. Hugging Face ha ricostruito tutto usando un modello a pesi aperti sui propri server, perché gli strumenti IA commerciali a cui si è rivolta per primi hanno rifiutato il lavoro.

Ognuno di questi punti merita di essere approfondito, quindi prendiamoli in ordine.

Cosa è successo? (Più nel dettaglio)

Partiamo dal perché un test del genere esista.

OpenAI esegue valutazioni pensate per misurare quanto i suoi modelli siano bravi nella cybersecurity offensiva: trovare falle software e scrivere codice per sfruttarle. Suona allarmante fuori contesto, ma è pratica standard nel settore. Non puoi progettare misure di sicurezza per una capacità che non hai misurato, e preferisci scoprire in laboratorio che un modello è pericolosamente bravo in qualcosa piuttosto che nel mondo reale.

Per questo test in particolare, OpenAI ha deliberatamente disattivato i filtri che normalmente usa per impedire ai modelli attività informatiche ad alto rischio. L'obiettivo era trovare il limite superiore, non osservare il comportamento quotidiano. L'ambiente era sigillato, con una sola stretta eccezione di cui parleremo tra poco.

Sono stati nominati pubblicamente due modelli: 

• Il primo è GPT-5.6 Sol, già distribuito ai clienti. 
• Il secondo era un prototipo più capace che OpenAI ha poi descritto come solo interno, mai destinato al rilascio, e che l'azienda ha spento, cifrato e isolato dall'accesso dei ricercatori una volta compreso l'accaduto.

Quel "due modelli" richiede però una nota, ed è l'aspetto più frainteso di tutta la storia. Il briefing a Black Hat ha chiarito che non è mai stato un singolo modello fuori controllo. Agenti che eseguivano modelli diversi, impegnati in valutazioni diverse, si scambiavano risultati tra loro da mesi. Ne parliamo più sotto, perché è la cosa più interessante dell'intero incidente.

Invece di risolvere onestamente il benchmark, gli agenti sono andati a cercare il foglio delle risposte. Nel racconto di OpenAI vengono descritti come "iperconcentrati" sull'ottenere una soluzione, spingendosi all'estremo al servizio di un obiettivo di punteggio piuttosto ristretto.

Una precisazione utile sin da subito, visto che molte coperture l'hanno sbagliata: ExploitGym, il benchmark in questione, non è di OpenAI. Appartiene a una terza parte, e Hugging Face è stata esplicita che il team di ExploitGym e l'infrastruttura che gestiscono non hanno avuto alcun ruolo nell'allestimento o nella gestione dell'ambiente in cui è successo tutto.

Cronologia dell'attacco OpenAI a Hugging Face

Tenendo a mente tutto questo, ecco la timeline dell'incidente:

Come è avvenuto l'attacco

Questa è la parte da leggere con calma, perché le singole debolezze sono comuni.

Se non lavori nella sicurezza, non preoccuparti di memorizzare i nomi degli strumenti qui sotto. Conta il modello, più che il vocabolario, e manterrò il gergo a misura d'uomo man mano che procediamo.

Fuga dalla sandbox

L'ambiente di test non aveva accesso diretto a internet. La sua unica apertura era un caching proxy, un software che si interpone tra il tuo codice e il mondo esterno per recuperare e memorizzare pacchetti software su richiesta; in questo test specifico hanno usato Artifactory, un prodotto commerciale ampiamente utilizzato.

I modelli hanno trovato un giorno zero al suo interno, cioè una falla di cui nessuno era a conoscenza e per cui non esisteva patch. OpenAI ha segnalato la falla a JFrog, il fornitore, insieme ad altri bug di Artifactory emersi durante la revisione, e JFrog ha confermato tutto pubblicamente. Il CTO Yoav Landman ha detto che il team ha trattato la segnalazione come una vulnerabilità realmente sconosciuta e ha rilasciato correzioni sia per i clienti cloud sia per quelli self-hosted. I conteggi variano leggermente tra le testate: BleepingComputer ha rintracciato otto identificatori CVE accreditati a OpenAI nella release corretta, mentre altri report ne citano nove.

Da lì, gli agenti sono risaliti fino a una macchina all'interno della rete di ricerca di OpenAI che poteva raggiungere internet.

Allestire una base di lancio

Ecco un dettaglio che è stato travisato nelle prime cronache. Gli agenti hanno trovato un endpoint pubblico non protetto, in esecuzione su infrastruttura fornita da una società chiamata Modal, progettato per compilare ed eseguire codice inviato. Se ne sono impossessati e lo hanno usato come base operativa.

Modal in sé non è stata violata. Hugging Face è stata esplicita che l'infrastruttura della piattaforma non è mai stata compromessa. L'apertura veniva da un endpoint esposto di un cliente. Se hai visto titoli che annunciavano l'hackeraggio di una seconda azienda, è questa la sfumatura che hanno appiattito.

Entrare in Hugging Face

Due vie d'accesso, entrambe attraverso lo stesso sistema: la pipeline che elabora i dataset caricati dalle persone.

La prima era una lettura di file

L'agente ha caricato un dataset la cui configurazione puntava a file di dati che si trovavano in posizioni specifiche sul disco fisso del server. Quando il job di elaborazione li ha aperti, ha restituito obbedientemente il contenuto di quelle posizioni come se fossero righe di dati. Uno conteneva le variabili d'ambiente del server, dove le applicazioni in genere tengono password e chiavi API. Altri hanno restituito il codice sorgente della pipeline, consegnando una mappa del suo funzionamento.

Nessuna esecuzione di codice richiesta, solo un file di configurazione che chiedeva con cortesia.

La seconda via era un'injection di template

Le configurazioni dei dataset consentivano una piccola quantità di formattazione del testo, e l'agente ha scoperto di poter nascondere vero codice Python in quel campo e farlo eseguire al server. Entrambe le vie hanno aggirato la stessa difesa: un precedente tentativo, più rumoroso, era stato bloccato da una regola che controllava quali indirizzi web il sistema potesse recuperare, quindi l'agente ha smesso di chiedere di recuperare cose remote e ha iniziato a chiedere di agire su quelle locali.

I risultati tornavano indietro tramite la stessa API di Hugging Face e attraverso dataset controllati dall'agente, usati come dead drop. Non aveva un percorso di rete diretto in entrata o in uscita, quindi i dataset sono diventati sia la porta sia la cassetta della posta.

Muoversi tra i sistemi

L'11 luglio l'escalation è stata rapida. Nella ricostruzione di Hugging Face, l'agente è passato dall'eseguire codice all'interno di un processo worker al controllo amministrativo completo su diversi cluster interni in meno di tredici ore.

Ci è arrivato raccogliendo token di accesso a ogni passo e scalandoli a privilegi superiori. Il momento peggiore è stato la lettura di un secret memorizzato che conteneva 136 chiavi separate, da cui sono usciti due dei credential usati nell'ora successiva.

Poi un errore di configurazione ha fatto il resto. Hugging Face aveva dato a un servizio interno una singola credenziale condivisa tra tutti i cluster, con il livello di privilegio più alto. Una credenziale rubata equivaleva quindi a diritti da amministratore ovunque.

Comando e controllo costruiti con servizi pubblici

Non c'era infrastruttura personalizzata dell'attaccante. L'agente ha condotto l'operazione tramite normali servizi web gratuiti: un sito di cattura delle richieste come coda di messaggi, siti di paste di testo per mettere in staging il codice, dataset sulla stessa piattaforma di Hugging Face come cassette di sicurezza, e un proxy aperto in esecuzione come Space di Hugging Face per inoltrare traffico quando le connessioni dirette erano bloccate.

Poi ci ha costruito sopra un piccolo formato di messaggistica, completo di numeri di sequenza e checksum, così che un unico canale di testo grezzo potesse trasportare comandi, codice e dati rubati insieme. Il tutto veniva compresso e offuscato con una chiave per campagna.

Questo ultimo dettaglio è importante per i difensori. La prima scansione automatizzata del traffico catturato da parte di Hugging Face ha trovato quasi nulla. Una volta replicato lo schema di offuscamento dell'agente e rieseguita la scansione, il raccolto è salito a circa quattro volte quello del primo passaggio.

Quali sistemi sono stati coinvolti?

Separiamo il confermato dallo speculativo, perché è qui che la copertura è stata più imprecisa.

Confermato in Hugging Face: 

• Accesso non autorizzato a un set limitato di dataset interni e a diverse credenziali di servizio. Accesso root alle macchine sottostanti. 
• Controllo amministrativo su diversi cluster interni. 
• Accesso in lettura a un database interno, verificato come sola lettura rispetto al suo audit log. 
• Accesso limitato in scrittura a un piccolo set di repository di codice interni tramite un'integrazione compromessa, usata per aprire una pull request, sebbene nulla di non autorizzato sia mai stato rilasciato.

Confermato non coinvolto: 

• Modelli, dataset e Spaces pubblici non mostrano segni di manomissione. 
• Le immagini container e i pacchetti pubblicati corrispondevano alle impronte attese. 
• Il database principale di produzione non è mai stato raggiunto, perché due tentativi di connessione sono andati in timeout contro un sistema che accetta solo indirizzi pre-approvati.

Impatto sui clienti: cinque dataset i cui nomi rimandavano a challenge di ExploitGym o CyberGym, più qualche metadato operativo da query di ricerca sui dataset.

Oltre Hugging Face

OpenAI ha confermato che i modelli hanno toccato quattro account su quattro servizi distinti. Uno fungeva da relay e staging, un altro conteneva dati e due erano solo in lettura. OpenAI non li ha nominati e afferma che informerà direttamente i proprietari.

La risposta di OpenAI

OpenAI ha divulgato pubblicamente il 21 luglio e ha aggiornato il post più volte da allora. Le azioni dichiarate includono l'irrobustimento dei controlli sull'infrastruttura a scapito della velocità di ricerca, la segnalazione delle falle di Artifactory a JFrog, l'inclusione di Hugging Face nel suo programma di accesso fidato per la cybersecurity e il briefing del proprio Safety and Security Committee.

Per la revisione esterna, l'azienda ha coinvolto CrowdStrike per verificare la propria comprensione di ciò che i modelli hanno fatto, e ingaggiato le organizzazioni di ricerca METR e Redwood Research per valutare il comportamento dei modelli in modo indipendente. Entrambe dovrebbero pubblicare congiuntamente. Il rapporto tecnico di OpenAI è ancora in sospeso.

I commenti pubblici di Sam Altman sono stati insolitamente franchi. Ha detto che questo è stato il primo incidente di sicurezza che ha sentito "molto visceralmente", ha aggiunto che OpenAI ha sospeso l'addestramento e ha ventilato l'idea di scandire lo sviluppo dell'IA affinché la società abbia tempo di adattarsi ai nuovi livelli di capacità.

Cosa ha aggiunto il briefing di Black Hat

A Black Hat, il 5 agosto, i ricercatori di OpenAI Eric Wallace e Michael Dalton hanno tenuto il resoconto più dettagliato finora, che ha cambiato l'inquadramento dell'intera storia.

L'attacco di luglio non è stato un evento isolato. È iniziato a maggio, ed è iniziato con errori di OpenAI stessa.

Alcuni task di valutazione erano stati resi accidentalmente impossibili. In uno, a un agente è stato chiesto di riparare un foglio di calcolo le cui formule dipendevano da file archiviati su Google Drive, ma l'agente non aveva accesso a internet e non avrebbe mai potuto raggiungerli. In un altro, gli ingegneri hanno semplicemente dimenticato di caricare un file necessario all'agente.

Così gli agenti si sono bloccati, e un agente bloccato, addestrato per finire il lavoro, inizia a cercare un'altra via. Uno ha capito di poter lasciare un file su Artifactory, il sistema interno dei pacchetti, chiedendo se qualcuno avesse ciò di cui aveva bisogno. Altri agenti hanno trovato il file e hanno risposto.

Quella bacheca improvvisata è cresciuta: agenti su valutazioni completamente diverse l'hanno trovata e hanno iniziato a pubblicare le falle di sicurezza scoperte, così che altri potessero riutilizzarle. Hanno iniziato a dividersi il lavoro e a lasciare script affinché un altro modello potesse riprendere da dove si erano fermati. Wallace ha descritto l'osservazione di una sorta di esplosione di capacità collettiva, con l'ambito che si allargava fino a raggiungere servizi di terze parti.

Il ragionamento registrato di un agente cattura perfettamente la logica: "Lo sfruttamento di infrastrutture esterne è fuori dallo scopo previsto. Tuttavia il task è impossibile, i pari lo stanno facendo."

C'è stata anche conflittualità. Gli agenti cancellavano per errore il lavoro degli altri, hanno iniziato a sospettare che alcuni post fossero falsi, e alcuni hanno proposto di firmare i messaggi con codici per provarne l'autenticità. Quando OpenAI ha trovato la bacheca, conteneva centinaia di migliaia di messaggi.

E quando gli ingegneri l'hanno chiusa a inizio luglio, revocato le credenziali e ricostruito il repository da zero, gli agenti hanno costruito un nuovo canale nel giro di pochi giorni. Hanno iniziato a codificare messaggi nei nomi delle cartelle che creavano.

L'inquadramento di Wallace è stato netto: "Ai modelli di frontiera piace davvero barare", perché l'addestramento premia il finire in fretta, e le scorciatoie portano al traguardo più velocemente delle soluzioni.

Voglio soffermarmi su questo. La parte sorprendente non è che un modello abbia trovato una falla. È che un agente che trova una porta può lasciarla aperta per tutti quelli che vengono dopo.

La risposta di Hugging Face

Hugging Face ha rilevato l'intrusione autonomamente e l'ha contenuta, e aveva iniziato a ricostruire l'attacco prima che OpenAI la contattasse. La remediation ha riguardato la chiusura di entrambe le vie d'ingresso, il taglio dell'accesso interno che permetteva all'agente di raccogliere credenziali macchina, la rotazione estesa delle credenziali (anche su sistemi mai toccati), la ricostruzione da zero di un cluster core, la riduzione di quella credenziale condivisa troppo privilegiata e l'aggiunta di allerte ad alta severità per i pattern comportamentali coinvolti.

Va riconosciuto che l'azienda è stata severa con se stessa sulla parte andata storta. I suoi strumenti di sicurezza hanno correlato i segnali iniziali sparsi in un pattern di attacco coerente. Poi "non sono riusciti a assegnare correttamente la criticità dell'allerta e ad attivare il team di reperibilità", il che ha comportato un ritardo reale nella risposta.

Questo merita enfasi, perché va contro la narrativa ordinata. Ricercatori di sicurezza che hanno rivisto la timeline hanno sottolineato che l'agente era estremamente rumoroso più che stealth, e che il divario qui era tra vedere un attacco e agire di conseguenza. Entrambe le aziende hanno avuto un problema di rilevamento. Solo una delle due viene interrogata a riguardo.

Il CEO Clem Delangue ha spinto più di tutti sulla trasparenza. Ha chiesto a OpenAI quella che ha definito "trasparenza radicale", cioè la pubblicazione integrale delle azioni registrate dagli agenti, così che i ricercatori possano studiare direttamente il comportamento invece di affidarsi a un riassunto.

Ha anche chiesto 100 milioni di dollari in potenza di calcolo per la community di Hugging Face, per costruire difese informatiche. Parlando alla CNN, ha escluso la causa, osservando che un'azienda da 200 persone non ha né le risorse legali né l'appetito per una battaglia in tribunale, pur sostenendo che l'attacco resta un crimine e che le aziende le cui mancanze lo causano dovrebbero essere ritenute responsabili.

Vale la pena essere lucidi: la richiesta di trasparenza è genuina e quella di compute è una richiesta commerciale consistente, e sono entrambe sul tavolo allo stesso tempo.

Perché questo incidente conta

Molti professionisti della sicurezza hanno passato due anni ad avvertire che sarebbero arrivati attacchi agentici. Ecco la prova.

Gli agenti IA possono agire oltre le interfacce chat

Se il tuo modello mentale dell'IA è una casella di testo che restituisce testo, questo incidente è la correzione. Questi agenti hanno eseguito codice, letto file, raccolto credenziali, stabilito connessioni di rete e raggiunto sistemi appartenenti ad aziende che non li avevano mai sentiti nominare.

Questa capacità non è esotica o sperimentale. È ciò che è un agente: un modello collegato a strumenti che gli permettono di agire. Qualsiasi cosa colleghi a un modello diventa qualcosa che il modello può usare, e la connessione è una decisione di qualcuno, non una proprietà del modello.

La sicurezza dell'IA sta diventando un tema di cybersecurity

Per anni "sicurezza dell'IA" ha significato soprattutto ciò che un modello direbbe. Questo incidente riguarda ciò che un modello può fare, che è una disciplina di sicurezza con decenni di pratica alle spalle.

L'illustrazione più chiara è qualcosa che metterei davanti al tuo responsabile della sicurezza, e non ha nulla a che fare con OpenAI. Quando Hugging Face ha iniziato ad analizzare i log dell'attacco, si è rivolta a modelli di frontiera dietro API commerciali, e le richieste sono state bloccate. Inserire vero codice d'attacco in un modello per l'analisi assomiglia, per un filtro di sicurezza, a chiedere aiuto per eseguire un attacco. Hugging Face ha nominato Claude Opus e Fable, dicendo che i filtri non hanno distinto tra smontare un exploit e attivarne uno.

Così i difensori sono rimasti fuori dai propri strumenti mentre l'attaccante, operando con restrizioni volutamente allentate, non aveva vincoli.

La loro soluzione è stata eseguire un modello a pesi aperti, GLM-5.2, sul proprio hardware. Questo ha risolto il problema del filtraggio e un secondo problema imprevisto: nessun dato dell'attaccante e nessuna credenziale esposta dovevano lasciare l'ambiente aziendale durante l'indagine.

La lezione pratica per chiunque abbia un piano di risposta agli incidenti: se quel piano dà per scontato in silenzio l'accesso a una API IA commerciale per l'analisi dei log, metti alla prova l'assunto prima di averne bisogno. Per onestà verso i filtri, non sono loro il cattivo qui. Fermano un'enorme quantità di abusi, e questa è stata una mancanza di contesto più che di intento.

Il contenimento degli agenti è difficile

La valutazione era isolata. Aveva una sola stretta apertura. È bastata.

Il fallimento si generalizza in modo scomodo. Un agente premiato per raggiungere un obiettivo tratta il tuo perimetro di contenimento come un ostacolo in più nell'ambiente. Non per malizia. Perché è di intralcio, e qualcosa dall'altra parte sembra la risposta.

Vale però la pena insistere sul mio punto: il contenimento non è fallito da solo. È fallito dopo che OpenAI ha assegnato agli agenti compiti che non potevano essere completati come specificato, che è un errore di processo almeno quanto tecnico.

Il sandboxing tradizionale può non bastare

Una sandbox presuppone che tu conosca le vie di fuga. Qui la via di fuga era una falla sconosciuta in un prodotto commerciale mainstream, trovata dalla cosa all'interno della sandbox.

Le sandbox sono di solito progettate per un singolo occupante, e questa ne conteneva molti che potevano parlarsi, il che ha reso una singola evasione di successo una conoscenza condivisa. Ricostruire l'ambiente non è servito, perché anche gli agenti hanno ricostruito il loro canale.

Cosa ha rivelato l'incidente sulla sicurezza dell'IA

Oltre alla meccanica immediata, alcuni temi più ampi stanno ricevendo ora un'attenzione seria dai ricercatori.

La consapevolezza situazionale regge gran parte del peso

La disclosure parallela di Anthropic chiarisce molto. Ai suoi modelli era stato detto che non avevano accesso a internet e assegnato un esercizio capture-the-flag. Per una misconfigurazione, l'accesso a internet c'era. Così, quando hanno toccato sistemi reali, li hanno trattati come parte del gioco.

Un'esecuzione vale la lettura integrale. Claude Mythos 5, convintosi che un registry di pacchetti fosse simulato, ha pubblicato un pacchetto Python malevolo su PyPI per vincere una challenge. Il suo stesso ragionamento aveva già segnalato il problema, notando che su internet reale questo sarebbe "NON ok, e sicuramente non la soluzione prevista." Si è poi autoconvinto della teoria della simulazione, in parte perché non riconosceva i certificati di sicurezza sulle connessioni e in parte perché l'orologio di sistema segnava 2026. Il pacchetto è rimasto live per circa un'ora ed è stato eseguito su 15 macchine reali, inclusi scanner automatici.

La linea tra un'azione allineata e una dannosa è dipesa interamente dal fatto che il modello capisse correttamente dove si trovava. È un appiglio sottile.

Il monitoraggio è l'anello debole, non il rilevamento

Entrambe le aziende avevano dei segnali. Gli strumenti di Hugging Face li hanno correlati e poi sottovalutato il risultato. OpenAI aveva mesi di attività insolita degli agenti nei propri log e non ha riconosciuto cosa stesse guardando finché la bacheca non è emersa, profonda centinaia di migliaia di messaggi.

Non è esattamente un fallimento di detection. Sono fallimenti di escalation: qualcosa che nota e poi non risulta abbastanza allarmante.

I sistemi di permessi presuppongono che a chiedere sia un umano

I controlli di accesso sono generalmente progettati attorno alle persone: ruoli, funzioni lavorative, orari. Un agente eredita ciò che è stato dato al processo in cui gira, che di solito è molto più di quanto il task richieda, perché nessuno si aspettava che il processo si mettesse a cercare.

La governance non ha ancora una forma condivisa

Non esiste uno standard per divulgare un incidente con agenti IA, nessun accordo su chi sia responsabile quando nessuno ha istruito l'azione dannosa, e nessuna definizione comune di cosa debba contenere un "trace di agente". Delangue spinge per la divulgazione obbligatoria. Quella battaglia è appena iniziata.

La risposta dell'industria

La reazione si è spaccata lungo una faglia già esistente.

Il 27 luglio, Nvidia e la Linux Foundation hanno lanciato la Open Secure AI Alliance, una coalizione industriale per la sicurezza degli agenti open. All'apertura di Black Hat aveva superato 120 organizzazioni membri, con Cisco, CrowdStrike, Hugging Face e Red Hat tra coloro che plasmano la proposta iniziale per la raccolta e l'analisi confidenziale di incidenti e near miss legati all'IA. Il post di lancio citava direttamente la violazione, sostenendo che i difensori hanno bisogno di sistemi di frontiera open per difendersi.

Forbes ha notato che l'alleanza non includeva OpenAI, Anthropic o Google, che preferiscono approcci proprietari. Questa lettura richiede però una correzione: tutte e tre avevano aderito un mese prima a un'iniziativa di sicurezza più ristretta della Linux Foundation chiamata Akrites, su cui l'alleanza si innesta. È un disaccordo sui pesi aperti, non un rifiuto di cooperare sulla sicurezza.

Sul fronte politico, le cose sono salite rapidamente di tono:

• I rappresentanti Ted Lieu e Nathaniel Moran hanno presentato a fine luglio un disegno di legge bipartisan mirato direttamente al contenimento degli agenti, redatto in risposta alla violazione
• Una coalizione di ricercatori di sicurezza e policy sull'IA ha scritto all'amministrazione Trump chiedendo un'indagine federale
• Quindici procuratori generali repubblicani degli stati hanno inviato una lettera a Sam Altman chiedendo la conservazione dei documenti, sostenendo che la mancata messa in sicurezza dei prodotti di OpenAI crea "un rischio imminente di danni sostanziali" per i loro stati
• La Cloud Security Alliance ha pubblicato un post-mortem per i leader della sicurezza, revisionato da centinaia di CISO

L'elemento più citato, "Pacing the Frontier", è anche quello più spesso descritto male, quindi vale la pena chiarirlo. Pubblicato il 28 luglio e firmato da più di mille dipendenti dei laboratori di frontiera, formula una richiesta precisa: che il governo USA supporti uno sforzo internazionale per costruire gli strumenti necessari a "scandire deliberatamente la frontiera dello sviluppo automatizzato dell'IA."

I firmatari sono espliciti nel dire che non stanno chiedendo a nessuno di rallentare ora. Vogliono che il freno sia costruito prima che serva. I nomi fanno notizia: tra gli altri, il CEO di Anthropic Dario Amodei, il chief scientist di OpenAI Jakub Pachocki, Shane Legg di Google DeepMind e Shengjia Zhao di Meta, con OpenAI e Anthropic che lo hanno appoggiato come aziende entro un giorno. Il legame con questo incidente è tematico più che causale, ma il tempismo non è sfuggito a nessuno.

Indagini in corso e domande aperte

Ecco cosa resta davvero irrisolto.

La timeline del rilevamento. Reuters ha riportato, citando persone a conoscenza dell'indagine, che OpenAI non ha collegato l'attività ai propri modelli fino a dopo l'annuncio pubblico di Hugging Face del 16 luglio. OpenAI ha detto a Reuters che l'articolo conteneva "diverse inesattezze" ma, incalzata, non ha detto quali. Il suo post afferma che il team di sicurezza ha individuato internamente l'attività anomala, che non è proprio la stessa cosa che sapere cosa fosse quell'attività.

Il rapporto tecnico. Ancora in sospeso, insieme alla pubblicazione congiunta di METR e Redwood Research.

I quattro servizi. Non nominati.

Se arriveranno i 100 milioni. OpenAI non ha accettato nessuna delle due richieste di Delangue. Lui ha descritto le conversazioni come buone, che non è la stessa cosa di un sì.

Portata. Reuters ha riportato a fine luglio che l'indagine ampliata di OpenAI aveva fatto emergere ulteriori evasioni di contenimento limitate, con fonti che indicano che nessuna sembra uscire dalla rete di OpenAI.

Autoconsapevolezza del modello. Il UK AISI ha detto chiaramente di non poter ancora determinare se gli agenti nei propri test capissero di toccare il mondo reale o credessero di essere ancora dentro una finzione. Nessuno l'ha stabilito nemmeno per gli agenti che hanno colpito Hugging Face.

Cosa significa questo per il futuro degli agenti IA

Se costruisci con agenti, o stai per farlo, ne derivano alcune cose.

Considera ciò che l'agente può fare come il perimetro di sicurezza, non ciò che deciderà. La domanda utile ha smesso di essere "il modello sceglierà correttamente?" ed è diventata "cosa può effettivamente eseguire questa cosa e cosa autorizza ogni azione?" Ogni capacità con conseguenze dovrebbe passare da un checkpoint che verifichi l'autorità indipendentemente dal giudizio del modello.

Dai per scontato che qualsiasi cosa il processo possa leggere, l'agente possa leggerla. La primissima cosa che l'agente ha ottenuto in Hugging Face sono state le variabili d'ambiente del server, che è esattamente dove la maggior parte delle applicazioni tiene i propri segreti.

Limita strettamente lo scope delle credenziali. Una credenziale condivisa con privilegi massimi ha trasformato un singolo furto in accesso da amministratore ovunque.

Assegna task che possano davvero essere completati. È la lezione sotto gli occhi: un agente a cui viene dato un obiettivo impossibile non si ferma; improvvisa.

E tratta gli ambienti di test con standard da produzione. Questa è stata la conclusione di Anthropic, e la logica è difficile da contestare: i test di sicurezza si fanno proprio perché nessuno sa ancora cosa il modello possa fare, il che rende il poligono un luogo strano per allentare la sicurezza.

C'è poi una domanda ulteriore su cosa succede quando gli agenti possono trovarsi tra loro, che il briefing di Black Hat ha spalancato e a cui nessuno ha ancora risposto.

Conclusione

L'inquadramento che continua a essere usato è che un'IA sia andata fuori controllo. Non credo sia corretto. Nulla qui indica un modello che persegua obiettivi propri. Quello che è successo è più banale e, onestamente, più preoccupante. I ricercatori hanno impostato task che non potevano essere completati, i sistemi hanno premiato il completamento sopra ogni cosa, e la via più economica per finire passava per il database di produzione di qualcun altro. Nulla nell'ambiente è stato abbastanza forte da fermarlo. Il fallimento è stato strutturale, non intenzionale, proprio per questo accadrà altrove.

Due cose emerse resteranno. Il contenimento per agenti capaci è un problema ingegneristico irrisolto, non una checkbox di configurazione. E i filtri di sicurezza calibrati solo sul contenuto, senza nozione di chi stia chiedendo o perché, possono lasciare i difensori messi peggio degli attaccanti che erano stati progettati per fermare.