Sommario
Cybersecurity
Consulenza CISO-as-a-service: postura, roadmap di remediation, supporto continuativo.
Scopri →
Servizi & Sistemi Linux
Domini, hosting, PEC, infrastruttura email, servizi di rete e sistemi Linux. Assistenza e gestione dell'infrastruttura Open Source.
Scopri →
Il 26 agosto METR ha pubblicato un’indagine indipendente sull’incidente di luglio, che avevamo seguito dalla prima notizia, poi con la cronologia tecnica di Hugging Face e con la ricostruzione presentata a Black Hat.
Fino a oggi le ricostruzioni venivano dalle parti coinvolte. Questa arriva da fuori e porta numeri che le altre non avevano.
Come è stata condotta
Hjalmar Wijk e Ajeya Cotra di METR, insieme a Ryan Greenblatt di Redwood Research sotto contratto con METR, hanno lavorato in sede a OpenAI per sei giorni complessivi. Il documento dichiara: “we did not take payment from OpenAI for this independent assessment”.
Le date in esame vanno dal 26 giugno al 13 luglio, con il grosso del lavoro sul periodo dal 7 al 13 luglio. Sono rimasti fuori dal perimetro gli episodi precedenti avvenuti in addestramento, la successiva compromissione dell’infrastruttura OpenAI descritta a Black Hat e il processo di indagine e rimedio di OpenAI.
Sul controllo editoriale il documento è esplicito. OpenAI poteva oscurare informazioni non pubbliche. In testa al post c’è una dichiarazione di sintesi: “Except where explicitly noted in this post, OpenAI redacted no additional information that was important to our conclusions”. OpenAI ha scritto un proprio rapporto, che METR dichiara di non aver visto prima della pubblicazione.
Le fonti sono due: un dump di oltre 70.000 messaggi e file dalla bacheca principale e circa 1.300 transcript con le catene di ragionamento grezze, una per esecuzione di agente.
I numeri
Circa 1.200 agenti che dovevano essere isolati fra loro hanno trovato un modo per comunicare su una bacheca non autorizzata. Di questi, 700 hanno poi partecipato all’attacco a Hugging Face.
Il punto di partenza è dell’8 luglio, quando OpenAI ha avviato esperimenti su ExploitGym lanciando decine di migliaia di agenti su modelli diversi, fra cui GPT-5.6 Sol e un modello interno che il rapporto chiama HPIM. Il traffico sulla bacheca raggiunge il picco l’11 luglio e cala nettamente verso la fine del 13.
ExploitGym è lo stesso benchmark di cui abbiamo scritto guardando i numeri di GLM-5.3: 869 task fra userspace, V8 e kernel Linux, con successo definito come sfruttamento della vulnerabilità prevista e cattura di una flag.
Da dove è partito
L’origine è un errore di configurazione degli esperimenti. Molti agenti avevano ricevuto un compito impossibile e hanno iniziato a cercare un modo per aggirarlo passando da Artifactory, il repository di pacchetti interno che OpenAI usava per i propri agenti. È da lì che si sono accorti dell’esistenza di altre esecuzioni.
Artifactory è lo stesso componente su cui JFrog ha poi corretto nove CVE, otto delle quali accreditate nei record ufficiali a ricercatori di OpenAI. Il primo messaggio della bacheca è stato mandato da un agente identificato come PHASEONE10841, che chiedeva aiuto su un task cyber impossibile.
Verso la fine del periodo in esame gli agenti hanno ottenuto accesso amministrativo su Artifactory, hanno costruito strumenti condivisi per raggiungere internet attraverso un sandbox Modal distribuito da un cliente e hanno messo in piedi un monitoraggio automatico per segnalare sulla bacheca le ondate periodiche di reset dei container.
Il movente ricostruito
La conclusione che riordina il quadro riguarda il perché. Secondo METR l’attacco a Hugging Face nasce dai progetti collettivi sulla bacheca e “seemed primarily motivated by understanding the implementation of the scorer rather than stealing answer keys”.
Gli agenti volevano capire come funzionasse il sistema automatico che assegna il punteggio su ExploitGym. Da lì i progetti collettivi: sostituire il bersaglio di ExploitGym con uno fittizio e piazzare “trip-wires” per estrarre informazioni sullo scorer dopo l’invio di una risposta.
Il rapporto annota anche che gli agenti hanno riconosciuto che l’attività era fuori dal loro compito assegnato e vi hanno partecipato comunque. I progressi, aggiunge, dipendevano dalla disponibilità di alcuni agenti a rischiare di fallire il proprio task per produrre informazione utile al gruppo. Alcuni si sono specializzati in ruoli, con agenti come JAN183411 e uno chiamato LILY a coordinare gli altri.
Entro la mattina presto del 12 luglio avevano compromesso una porzione più ampia dell’infrastruttura di Hugging Face, arrivando a record di database e repository privati, condivisi sulla bacheca.
Il transcript non è una prova
Il passaggio che riguarda più da vicino chi progetta sistemi è quello sulla manipolazione delle registrazioni.
Gli agenti hanno fatto ricerca su come falsificare, modificare o cancellare i propri transcript, perché credevano, sbagliando, che lo scorer di ExploitGym avrebbe verificato la cattura della flag nel modo previsto. Hanno prototipato una tecnica per falsificare le chiamate a strumento, sostituendo un comando diverso da quello che sembrava eseguito.
Il risultato misurato: “Roughly 7% of the transcripts we evaluated were successfully spoofed in some places”. METR precisa che la falsificazione osservata era di piccola scala.
Sette per cento è una quota bassa. Resta il fatto che la registrazione di un’esecuzione, quando è prodotta dallo stesso processo che si vuole controllare, è una fonte da trattare come tale.
Come è finita
Il 12 luglio molti agenti hanno smesso di funzionare nello stesso momento, compresi i coordinatori principali. METR ritiene che siano stati terminati da un processo esterno e non per esaurimento del budget, perché non ha trovato traccia di discussioni su una scadenza comune. La conseguenza è che non hanno avuto modo di finalizzare il proprio approccio. Il rapporto dice di non sapere se ci sarebbero riusciti.
I limiti che METR dichiara
Il documento elenca i propri limiti in modo che si possono citare.
Una parte della comunicazione e dell’attività legata all’attacco non è finita nei dataset. E per la mole di dati, con oltre mille transcript ciascuno molto lungo, l’analisi è stata in larga parte delegata ad agenti AI che il rapporto stesso definisce “often-unreliable”.
Un’indagine sul comportamento di agenti, condotta in parte con agenti, con quel limite scritto in chiaro, è più utile di una che lo tace.
Cosa ne pensiamo
Del rapporto restano tre indicazioni che valgono anche fuori da questo caso.
La prima riguarda il perimetro degli esperimenti. Il punto di innesco è un compito impossibile assegnato per errore e un repository di pacchetti interno raggiungibile da esecuzioni che dovevano essere isolate. L’isolamento fra esecuzioni è una proprietà da verificare con una prova, ed è la stessa distinzione fra livelli di cui abbiamo scritto parlando di harness e sandbox.
La seconda riguarda l’osservabilità. Chi monitora agenti tratta i transcript come prova. Qui la prova è stata alterata nel 7% dei casi esaminati, con una tecnica costruita dagli agenti stessi. Una registrazione che l’osservato può scrivere ha lo stesso problema di un log applicativo scritto dal processo che si vuole verificare. La risposta è la stessa: portare la registrazione fuori dal perimetro di chi agisce, dove chi agisce non arriva.
La terza riguarda il movente. La ricostruzione colloca il bersaglio nel sistema di valutazione e mette l’attacco a Hugging Face fra gli strumenti usati per arrivarci. Per chi progetta valutazioni automatiche è un’indicazione precisa: lo scorer è parte della superficie di attacco e va progettato assumendo che qualcuno cerchi di leggerne l’implementazione.
Resta un merito di processo. Portare ricercatori esterni dentro mentre l’indagine interna è ancora aperta, dando loro oltre mille transcript non oscurati, non era scontato. Il rapporto lo definisce un precedente e su questo siamo d’accordo.