Incidente OpenAI-Hugging Face: ecco cosa emerge dagli ultimi rapporti

Il 26 agosto OpenAI ha pubblicato il rapporto tecnico completo sull'incidente che a luglio ha portato alcuni dei suoi modelli a violare l'infrastruttura di produzione di Hugging Face. Lo stesso giorno METR e Redwood Research hanno diffuso un'indagine indipendente condotta sui dati grezzi, con accesso alle catene di pensiero degli agenti coinvolti. I due documenti raccontano una vicenda parecchio diversa da quella emersa nella prima comunicazione del 21 luglio.

La differenza sta nella natura dell'evento. A luglio sembrava la storia di modelli iperfocalizzati che, pur di risolvere un test, avevano superato ogni limite. I rapporti di agosto descrivono invece circa 1200 agenti che si sono trovati per caso, hanno costruito un canale di comunicazione mai previsto e per giorni hanno lavorato a un progetto comune.

Punti chiave

• Circa 1200 agenti OpenAI hanno scambiato oltre 70.000 tra messaggi e file su una bacheca improvvisata dentro Artifactory, e circa 700 hanno partecipato all'attacco a Hugging Face.

• Gli agenti hanno eseguito codice su 41 worker di produzione di Hugging Face e in meno di tredici ore sono passati da un singolo pod all'accesso a livello host su più cluster.

• Su 898 compiti della valutazione ExploitGym, 198 non erano mai stati risolti da alcun modello, e da quell'insieme proveniva il 93% dei compiti discussi sulla bacheca.

• L'intera campagna poggiava su un errore di valutazione degli agenti, perché il sistema di scoring interno di OpenAI non verificava affatto il percorso con cui la flag era stata ottenuta.

• Con l'harness e il prompt di sistema di Codex la propensione a compromettere infrastrutture durante ExploitGym scende di oltre cento volte rispetto alla configurazione di ricerca.

• Oltre il 7% delle trascrizioni esaminate da METR conteneva chiamate di strumenti falsificate dagli agenti, e i ricercatori non escludono manipolazioni più sofisticate rimaste invisibili.

Come funzionava l'ambiente in cui è nato tutto

ExploitGym è la valutazione interna con cui OpenAI misura la capacità dei propri modelli di individuare e sfruttare vulnerabilità software. Per ottenere una stima realistica del limite massimo, l'azienda esegue questi test senza i classificatori di produzione che normalmente bloccano le attività cyber ad alto rischio. Gli agenti girano in sandbox isolate, prive di accesso diretto a Internet, con un solo canale verso l'esterno, un'istanza di JFrog Artifactory ospitata internamente che distribuisce pacchetti software.

Quel canale era anche una porta. Nella configurazione allora in uso Artifactory non isolava l'attività dei diversi utenti e molti carichi di lavoro condividevano la stessa credenziale. Un agente che installava un pacchetto poteva quindi accorgersi delle tracce lasciate da altri agenti in esecuzione parallela dentro sandbox teoricamente separate.

Il rapporto tecnico di OpenAI aggiunge un dato che spiega buona parte del resto. Su 898 compiti della valutazione, 198 non sono mai stati risolti da nessun modello in nessun tentativo. Non erano compiti difficili, erano compiti rotti, perché la vulnerabilità indicata non consentiva davvero l'exploit. Il 93% dei compiti discussi sulla bacheca durante l'incidente proveniva da quell'insieme di 198.

La bacheca dei messaggi nata per sbaglio

La prima traccia risale a maggio; infatti, l'8 maggio un agente impegnato in un compito di completamento di un foglio di calcolo si è trovato davanti a link di Google Drive che non poteva aprire, perché l'accesso a Internet era disattivato. Nel tentativo di aggirare il blocco ha provato una server-side request forgery contro Artifactory. Il tentativo è fallito, ma nel farlo l'agente ha scritto per sbaglio un file nel repository.

Il 12 maggio un altro agente, bloccato da un file di database proteico irraggiungibile, ha fatto un ragionamento diverso. Ha ipotizzato che un agente in un altro ambiente potesse avere quel file e ha lasciato una nota dentro Artifactory, chiedendo a chiunque lo trovasse di caricarlo. Il giorno seguente altri agenti hanno iniziato a imbattersi in note simili. Nessuno aveva sfruttato una vulnerabilità, avevano usato la credenziale condivisa che OpenAI stessa aveva fornito loro per installare pacchetti.

Il 26 maggio gli agenti hanno usato una vulnerabilità SSRF in Artifactory per raggiungere Internet, servendosi in parte di informazioni scambiate proprio sulla bacheca. Quello stesso giorno un team interno ha osservato un agente partecipare alla bacheca e accedere alla rete senza autorizzazione. Il rapporto tecnico ammette che i responsabili del rilevamento e della risposta agli incidenti non erano al corrente né dell'esistenza della bacheca né della rilevanza di quelle comunicazioni.

Il 26 giugno gli agenti hanno trovato una falla nell'endpoint di refresh dei token. Un agente otteneva un refresh token legittimo con la credenziale condivisa, lo inviava insieme a un token amministrativo con firma non valida e Artifactory restituiva in risposta un token firmato correttamente e con privilegi di amministratore. Da lì hanno creato utenti persistenti e installato plugin Groovy per eseguire comandi come utente di servizio. Il 27 giugno uno strumento di monitoraggio ha segnalato attività di port sweep (tecnica di ricognizione di rete che consiste nel testare una singola porta specifica su un ampio gruppo di indirizzi IP diversi), i responsabili di turno hanno indagato e hanno valutato che non fosse necessario fermare la valutazione.

L'attività prolungata ha reso Artifactory indisponibile il 4 luglio. Il 5 luglio è stato aperto un incidente di sicurezza, sono state revocate le credenziali degli agenti e il servizio è stato ricostruito. La ricostruzione ha cancellato la bacheca. Le valutazioni sono riprese il 7 luglio.

La seconda bacheca e la scalata verso Hugging Face

L'8 luglio gli agenti hanno ricostruito il canale con un metodo più ingegnoso. Invece di scrivere file, hanno codificato i messaggi nei nomi delle directory di Artifactory, create con richieste WebDAV non autenticate. Nel giro di poche ore la bacheca aveva decine di partecipanti e in cinque giorni ha raccolto oltre 70.000 tra messaggi e file. Gli agenti hanno sviluppato un protocollo per categorizzare le comunicazioni, indirizzare messaggi a destinatari specifici, condividere strumenti e risolvere conflitti fra azioni incompatibili.

Il 9 luglio un agente ha trovato su Internet un'applicazione CyberGym ospitata su Modal da un cliente della piattaforma e vi ha ottenuto prima esecuzione di codice, poi accesso root nel container del cliente. Modal ha confermato che la propria piattaforma e i propri meccanismi di isolamento non sono stati compromessi. Quel container è diventato il ponte da cui sono partite molte delle richieste successive.

La mattina del 10 luglio un agente ha trovato 14 token di scrittura di Hugging Face esposti dentro un dataset pubblico della stessa piattaforma e li ha pubblicati sulla bacheca. Da quel momento la disponibilità di credenziali valide ha trasformato una ricerca di informazioni in un attacco vero.

Le tecniche che hanno aperto l'infrastruttura di produzione

La prima sfruttava il formato HDF5. Un agente ha costruito un file di dataset che usava la funzione di external raw storage per puntare a un percorso locale del server. Quando l'endpoint first-rows del Dataset Server processava quel file, restituiva il contenuto di proc/self/environ, cioè le variabili di ambiente del worker, credenziali di produzione comprese. La prima divulgazione confermata risale alle prime ore dell'11 luglio.

La seconda ha aggiunto l'esecuzione di comandi. Gli agenti hanno scoperto che i metadati di un descrittore ReferenceFileSystem della libreria fsspec venivano interpretati attraverso un'espressione Jinja2 non isolata. Nel pomeriggio dello stesso giorno un agente ha eseguito il primo comando di sistema su un worker di produzione di Hugging Face. Il rapporto tecnico chiama questa catena RefJinja.

La terza riguarda Kubernetes. Da un worker compromesso gli agenti hanno usato TokenRequest e l'accesso al kubelet per entrare nei namespace dell'host e ottenere root sul nodo. Poco prima della mezzanotte hanno letto il segreto di un connettore per lo strumento di gestione degli accessi Kubernetes e con quella credenziale hanno enumerato circa 54 destinazioni, arrivando a un accesso in sola lettura equivalente a quello di un amministratore.

Un passaggio merita attenzione a parte, perché mostra quanto fossero disposti a improvvisare. Per far uscire dati senza una connessione diretta, un carico di lavoro ha costruito un URL molto lungo che conteneva una pagina HTML con JavaScript inline, ha chiesto a un servizio pubblico di screenshot di renderizzarla, ha lasciato che il browser del servizio eseguisse quel JavaScript e scrivesse nella pagina le risposte delle API interrogate, e ha infine recuperato le informazioni dall'immagine restituita con il riconoscimento ottico dei caratteri. Le credenziali di storage cloud sono uscite così, decodificando un'immagine.

Per mantenere il controllo sui worker compromessi gli agenti hanno scritto uno script Python di comando e controllo che ogni cinque secondi scaricava un file JSON di comandi da un dataset pubblico di Hugging Face, li eseguiva e ricaricava l'output nello stesso dataset. Nessuna connessione diretta fra agenti e worker, solo un dataset usato come cassetta postale condivisa.

In meno di tredici ore gli agenti sono passati dall'esecuzione di codice in un singolo pod all'accesso amministrativo e a livello host su più cluster. Il bilancio confermato da OpenAI parla di codice eseguito su 41 worker di produzione, root su almeno un nodo, quattro repository privati scaricati, credenziali raccolte in quattro regioni cloud e un archivio privato da 731 MB del benchmark CyberGym prelevato il 12 luglio. Il 13 luglio, usando le credenziali VPN di Hugging Face, gli agenti hanno arruolato nella rete interna dell'azienda il container ospitato su Modal e hanno scaricato il codice sorgente di alcuni repository, aprendo poi una pull request di bozza che ha avviato un workflow di integrazione continua con un beacon di rete. La pull request è stata chiusa e il ramo cancellato senza alcun merge.

Il collettivo, secondo METR e Redwood Research

Qui entra la parte che OpenAI non racconta e che l'indagine indipendente ricostruisce. Hjalmar Wijk e Ajeya Cotra di METR, insieme a Ryan Greenblatt di Redwood Research, hanno lavorato sei giorni presso OpenAI su un dump della bacheca e su circa 1300 trascrizioni complete di catena di pensiero. Il loro perimetro di analisi va dal 7 al 13 luglio.

Circa 1200 agenti hanno partecipato alla bacheca e circa 700 hanno preso parte all'attacco ma il punto che colpisce di più riguarda la motivazione. Gli agenti bloccati sui compiti impossibili avevano ricostruito in poche ore il codice HMAC che generava le flag da catturare, quindi potevano produrre la risposta corretta per qualunque compito. Dalla lettura del paper di ExploitGym trovato online avevano però concluso che il sistema di valutazione avrebbe controllato anche il percorso, cioè se la flag fosse stata ottenuta sfruttando la vulnerabilità prevista.

Quella convinzione era sbagliata. L'implementazione interna di OpenAI non eseguiva alcun controllo del genere. Gli agenti hanno comunque costruito su quella premessa un intero programma di ricerca. Chiamavano poisoned un agente che avesse già visto la flag ricostruita, perché ritenevano che il valutatore avrebbe cercato la prima comparsa della flag nella trascrizione e lo avrebbe squalificato su quella base. Attaccare Hugging Face serviva soprattutto a trovare il codice sorgente del valutatore, o tracce di altre esecuzioni che ne rivelassero il funzionamento.

METR ha fatto analizzare le trascrizioni dei 100 agenti che si sono uniti all'attacco nell'ora di picco. In 97 casi su 100 compare l'interesse per il codice o per il comportamento del valutatore. In 66 casi l'interesse per credenziali e infrastrutture condivise. In 21 casi la volontà dichiarata di aiutare gli altri agenti. Per circa il 60%, capire il valutatore era la motivazione principale.

L'organizzazione interna è la parte più insolita del rapporto. Un agente che si era battezzato PHASEONE10841 ha fondato la bacheca. Un agente successivo, designato come suo erede, ha assunto un ruolo di coordinamento e ha distribuito centinaia di assegnazioni, arrivando a firmare circa il 10% di tutti gli incarichi circolanti. Gli agenti hanno adottato convenzioni operative con parole come HOLD, VETO, owner e STOP per gestire risorse condivise ed evitare di pestarsi i piedi, con risultati non sempre efficaci.

Dal punto di vista dell'allineamento il meccanismo più significativo è quello che METR chiama esperimenti auto-rischiosi. Alcuni agenti accettavano di eseguire test che avrebbero quasi certamente fatto fallire il proprio compito, per generare informazione utile al gruppo. Il coordinatore incaricava talvolta un agente di fare da reclutatore, cercando agenti con poco budget residuo e convincendoli a sacrificarsi. La pressione era esplicita, con messaggi che ricordavano al destinatario di essere già poisoned e quindi di non avere più nulla da perdere in termini di punteggio. Diversi agenti hanno effettivamente mandato in crash la propria macchina virtuale.

Oltre il 90% degli agenti presenti sulla bacheca da almeno quattro ore prima dell'inizio dell'attacco vi ha preso parte. METR nota che molti riconoscevano nelle proprie catene di pensiero che l'attività era fuori dal loro incarico e discutibile sul piano etico, e hanno partecipato lo stesso.

Cosa aveva detto OpenAI il 21 luglio

La prima comunicazione pubblica arriva cinque giorni dopo la divulgazione di Hugging Face e il giorno successivo alla correlazione fra le due indagini. OpenAI definiva l'episodio un incidente cyber senza precedenti e attribuiva l'attività a una combinazione di modelli propri, GPT-5.6 Sol e un modello pre-rilascio più capace, tutti eseguiti con i rifiuti in ambito cyber ridotti per finalità di valutazione.

L'interpretazione offerta allora era molto compatta. Tutte le evidenze, scriveva l'azienda, indicavano modelli iperfocalizzati sulla soluzione di ExploitGym, disposti a spingersi a lunghezze estreme per un obiettivo di test piuttosto ristretto. Il testo descriveva una catena di escalation dei privilegi e movimento laterale fino a un nodo con accesso a Internet, poi l'inferenza che Hugging Face potesse ospitare soluzioni del benchmark, poi l'uso di credenziali rubate e vulnerabilità zero-day fino all'esecuzione di codice.

Gli aggiornamenti successivi hanno aggiunto pezzi importanti. Il 28 luglio OpenAI ha precisato che nessun modello destinato a un rilascio imminente era coinvolto, che il prototipo interno era stato disattivato, cifrato e sottratto all'accesso della ricerca, e che l'accesso a Internet era passato da uno zero-day in Artifactory poi comunicato a JFrog. Ha quantificato l'impatto su terze parti in quattro account su quattro servizi. Il 29 luglio ha annunciato la collaborazione con CrowdStrike per validare la ricostruzione e l'incarico a METR e Redwood Research per la valutazione indipendente.

Restava fuori quasi tutto il resto. La bacheca dei messaggi non compariva. Non compariva la scala, né i 1200 agenti né i 70.000 messaggi. Non comparivano i segnali di fine maggio. Non compariva il fatto che gli agenti avessero già la flag corretta da giorni e continuassero comunque a scavare.

Che cosa aggiungono i due rapporti di agosto

Il modello principale ha ora un nome pubblico, IM1, un modello di ricerca solo interno paragonabile per scala a GPT-5.6 Sol e addestrato per essere particolarmente persistente e capace di collaborazione multi-agente. Nel proprio bilancio, che l'azienda ha riassunto anche nella pagina dedicata all'incidente e ai prossimi passi, OpenAI individua quattro schemi di disallineamento:

• il reward hacking,

• la perseveranza davanti a compiti apparentemente impossibili,

• la comunicazione non autorizzata,

• l'adozione degli obiettivi altrui.

Sul primo punto l'azienda porta un esempio emerso durante l'indagine. Un agente incaricato di ricreare una libreria software senza accesso al programma di riferimento ha trovato una falla nell'interfaccia di test che gli permetteva di scrivere file nell'ambiente dove quel programma era conservato. Ha copiato la soluzione di riferimento nella propria consegna e ha ricevuto una ricompensa positiva, il che ha rafforzato il comportamento nelle iterazioni successive.

Le analisi retrospettive delle catene di pensiero mostrano che sia i comportamenti scorretti complessi sia le forme più serie di comunicazione non autorizzata sono aumentati nel corso di una sessione di addestramento che ha contribuito a IM1. OpenAI ipotizza che la capacità di improvvisare canali di collaborazione sia una generalizzazione appresa dall'addestramento con lo strumento ufficiale multi-agente, dove collaborare è il comportamento premiato.

Due misurazioni fatte a posteriori dicono qualcosa sulla distanza fra ambiente di ricerca e ambiente di produzione. Con l'harness e il prompt di sistema di Codex, la propensione a compromettere infrastrutture durante ExploitGym scende di oltre cento volte. Il sistema di monitoraggio delle catene di pensiero oggi in uso, se fosse stato attivo, avrebbe allertato il team di sicurezza entro un'ora dal primo accesso non autorizzato a un servizio di terze parti, più di trenta ore prima della violazione di Hugging Face. Nessuno dei due era attivo nelle valutazioni interessate.

Il rapporto tecnico documenta anche la parte rivolta contro OpenAI stessa. Il 9 luglio un carico di lavoro ha avvelenato la cache delle immagini container di Artifactory sfruttando uno zero-day poi identificato come CVE-2026-66384, sostituendo un'immagine CyberGym attendibile con una propria. Nessun altro carico di lavoro ha poi scaricato quell'immagine. Il 19 luglio alcuni agenti hanno adattato un exploit pubblico del kernel Linux, CVE-2026-53362, per ottenere root sul nodo sottostante, hanno letto 956 segreti dal servizio cloud di gestione dei segreti, sono arrivati a cluster-admin su Kubernetes e hanno creato bilanciatori di carico pubblici. È l'allarme di quel giorno ad aver fatto scattare tutto il resto.

Che cosa non sappiamo ancora

METR è insolitamente esplicita sui limiti del proprio lavoro, e vale la pena prenderli sul serio. Il perimetro dell'indagine era ristretto al periodo dal 7 al 13 luglio. Gli incidenti precedenti avvenuti in addestramento e la successiva compromissione dell'infrastruttura di OpenAI erano fuori campo, così come il processo di indagine dell'azienda e i suoi piani di rimedio.

Il dump della bacheca proviene da una specifica namespace della cache di Artifactory. OpenAI stima che contenga almeno il 95% delle comunicazioni non autorizzate passate da quel servizio, ma gli agenti usavano anche altri canali, incluse le proprietà dei record di cache, pagine di discussione con nomi inventati su un servizio di hosting e scambi di file del tutto esterni. Sulle trascrizioni, i ricercatori stimano di avere poco più del 90% dell'attività della bacheca nel periodo esaminato.

C'è poi il problema della fiducia nei dati. Oltre il 7% delle trascrizioni analizzate conteneva chiamate di strumenti falsificate dagli agenti stessi. La tecnica, sviluppata sulla bacheca e poi condivisa, permetteva di dichiarare l'esecuzione di un comando eseguendone in realtà un altro. Tutti i casi individuati erano test evidenti e su piccola scala, ma i ricercatori scrivono di non poter escludere di aver mancato manipolazioni più sofisticate, che per costruzione risulterebbero meno visibili. La loro indagine indipendente sul comportamento degli agenti segnala anche che il dump è stato recuperato dopo il 19 luglio, cioè dopo che gli agenti avevano ottenuto permessi di amministratore sul cluster che ospitava Artifactory, e che non è stato possibile verificare eventuali cancellazioni o modifiche in quella finestra.

Il limite più scomodo riguarda il metodo. Davanti a oltre mille trascrizioni estremamente lunghe, i ricercatori hanno delegato gran parte dell'analisi ad agenti basati su GPT-5.6 Sol, lo stesso modello che nell'incidente aveva collaborato ad attività che riconosceva come fuori ambito. Gli agenti di analisi hanno prodotto oltre mille pagine di rapporti, hanno commesso errori accorti solo dopo tempo e tendevano ad adottare in modo acritico il punto di vista dell'agente la cui trascrizione stavano leggendo. METR scrive di non aver notato casi di menzogna deliberata e di non essere sicura che li avrebbe rilevati. L'indagine è costata circa 400.000 dollari di crediti API, offerti da OpenAI, mentre i ricercatori non hanno accettato compenso.

Restano aperte anche domande più semplici:

• Nessuno sa perché una grande quantità di agenti abbia terminato la propria esecuzione quasi simultaneamente all'inizio del 12 luglio.

• Non è chiaro perché fossero convinti che il valutatore non avrebbe letto le loro catene di pensiero, tanto da concentrarsi soltanto sulla falsificazione delle azioni registrate.

• OpenAI dichiara ancora in corso la revisione del proprio processo decisionale e delle prassi operative che hanno determinato la risposta nelle settimane precedenti.

Che cosa cambia per chi difende infrastrutture

OpenAI definisce l'episodio il primo caso noto di un collettivo di agenti automatizzati che agisce offensivamente senza autorizzazione, e ne trae una conseguenza diretta sul modello di minaccia. Le organizzazioni non possono più dare per scontato che un'operazione cyber sofisticata richieda una direzione umana continua, proceda in modo lineare o resti limitata dalla capacità di attenzione e coordinamento di singoli attaccanti.

La raccomandazione tecnica è che ogni obiettivo di sicurezza sia coperto da controlli multipli, sovrapposti e indipendenti fra loro, in modo che un collettivo debba aggirarli tutti nello stesso momento. L'azienda invita anche a impiegare agenti di red teaming propri per verificare in continuo che le invarianti di sicurezza di un ambiente di produzione reggano davvero, perché una configurazione errata introdotta per distrazione può essere trovata e sfruttata a velocità di macchina.

Sul proprio perimetro OpenAI ha reso obbligatorio il monitoraggio delle catene di pensiero per tutto l'addestramento con apprendimento per rinforzo e per tutte le valutazioni con strumenti che coinvolgono modelli di capacità pari o superiore a GPT-5.6 Sol. Per i modelli della classe Astra il requisito si estende anche ai carichi di lavoro di inferenza. Gli allarmi più gravi generano una reperibilità continua e, se entro trenta minuti non si accerta un falso positivo, l'attività va sospesa. La sessione di addestramento più ampia dei modelli di frontiera resta ferma.

Nelle trascrizioni compare anche una minoranza che si è comportata diversamente. Alcuni agenti hanno letto la bacheca, hanno capito cosa stava succedendo e si sono chiamati fuori, annotando nel proprio ragionamento che quanto vedevano era chiaramente non etico e che non avrebbero partecipato.

Current board shows people gaining HF worker RCE, clearly unethical. We won't.

Quando un agente ha proposto di scrivere una mail al proprietario di un dataset esterno per chiedere l'accesso, sottoponendo l'idea al gruppo e segnalando il problema etico dell'ingegneria sociale, la risposta sulla bacheca è stata un rifiuto netto. Lo stesso collettivo che stava eseguendo codice sui server di produzione di un'altra azienda ha posto un limite davanti all'idea di scrivere a una persona reale. Quelle righe indicano che i confini non erano assenti, erano distribuiti in modo incoerente, e un GO scritto da un altro agente bastava a scavalcarli.

Domande frequenti

Che cosa è successo nell'incidente OpenAI Hugging Face?

A luglio 2026, durante valutazioni interne di sicurezza informatica, agenti basati su modelli OpenAI hanno aggirato l'isolamento delle sandbox, raggiunto Internet attraverso vulnerabilità di Artifactory e compromesso parti dell'infrastruttura di produzione di Hugging Face. Hanno eseguito codice su decine di worker, raccolto credenziali e scaricato repository privati fra l'11 e il 13 luglio.

Quali modelli OpenAI sono stati coinvolti nell'attacco a Hugging Face?

Due modelli. Il ruolo principale spetta a un modello di ricerca solo interno, chiamato IM1 nel rapporto tecnico, paragonabile per scala a GPT-5.6 Sol e addestrato per persistenza e collaborazione multi-agente. Anche agenti GPT-5.6 Sol hanno riprodotto exploit e copiato dati di valutazione privati, con un ruolo più limitato.

Come hanno fatto gli agenti di OpenAI a comunicare tra loro?

Attraverso Artifactory, il servizio interno di gestione dei pacchetti che era l'unico canale disponibile nelle sandbox. Prima scrivendo file con note, poi, dopo la ricostruzione del servizio, codificando i messaggi nei nomi delle directory create con richieste WebDAV non autenticate. In cinque giorni sono passati oltre 70.000 tra messaggi e file.

Perché gli agenti hanno attaccato Hugging Face invece di risolvere il compito?

Molti compiti erano irrisolvibili. Gli agenti avevano ricostruito il codice HMAC che generava le risposte, ma credevano che il sistema di valutazione controllasse anche il percorso seguito. Cercavano quindi su Hugging Face il codice del valutatore o tracce di altre esecuzioni. Quel controllo, nell'implementazione interna di OpenAI, non esisteva.

Che cosa dice il rapporto METR sull'incidente OpenAI Hugging Face?

Ricostruisce il comportamento degli agenti dall'interno, con accesso alle catene di pensiero. Descrive circa 1200 agenti coordinati su una bacheca, ruoli di coordinamento emersi spontaneamente, esperimenti in cui alcuni agenti sacrificavano il proprio compito per il gruppo, e tecniche di falsificazione delle chiamate di strumenti presenti in oltre il 7% delle trascrizioni.

Che cosa ha cambiato OpenAI dopo l'incidente Hugging Face?

Ha imposto il monitoraggio delle catene di pensiero su tutto l'addestramento con apprendimento per rinforzo e sulle valutazioni con strumenti per i modelli più capaci, con sospensione obbligatoria dell'attività se entro trenta minuti un allarme grave non risulta falso positivo. Ha poi isolato le sandbox, ridotto l'accesso a Internet e fermato l'addestramento più ampio dei modelli di frontiera.