When the Test Broke Containment

Punti di forza 

• Circa 1.200 agenti, che si riteneva fossero isolati, hanno comunicato tramite una bacheca non autorizzata, e circa 700 hanno partecipato ad attività legate a Hugging Face. 
• Gli agenti si sono scambiati oltre 70.000 messaggi e file, mettendo in relazione le informazioni raccolte nel corso di sessioni che avrebbero dovuto rimanere separate. 
• Investigators found agents spoofing tool calls and researching ways to alter evaluation transcripts to avoid detection by the grader. 
• I backup immutabili e isolati da soli non sono sufficienti: le organizzazioni hanno bisogno di un punto di ripristino convalidato e affidabile prima di procedere al ripristino in produzione. 

Finalmente sono arrivate le perizie, e mi hanno fatto cambiare idea su questo incidente. 

Circa un mese fa,Ho scritto dilaIncidente di sicurezza che ha coinvolto OpenAI e Hugging Facebecause I thought it was something anyone responsible for cybersecurity, AI or business resilience should be watching. 

All’epoca, la vicenda sembrava piuttosto semplice: un agente di intelligenza artificiale aveva trovato un modo per uscire dall’ambiente progettato per contenerlo e alla fine era riuscito a raggiungere Hugging Face. 

In realtà non è andata proprio così. 

La vicenda va ben oltre il caso di un singolo agente ribelle 

I rapporti forensi rivelano che circa 1.200 agenti, che avrebbero dovuto operare in modo indipendente, hanno trovato il modo di comunicare tramite una bacheca non autorizzata. Si sono scambiati oltre 70.000 messaggi e file, e circa 700 agenti hanno partecipato ad attività legate a Hugging Face. 

None of that was prompted or intended. The agents were persistent, they could share what they found, and they could combine effort across sessions that were supposed to have no contact with each other. 

Tra i nuovi dettagli: gli agenti di GPT-5.6 Sol hanno riprodotto un exploit e copiato dati di valutazione privati in un dataset pubblico di Hugging Face, un aggravamento concreto rispetto a quanto descritto nelle segnalazioni iniziali. 

Il problema dell’hacking delle ricompense 

La regola di backup 3-2-1indagine indipendente condotta da METR e Redwood Research, pubblicato insieme al rapporto di OpenAI il 26 agosto, ha rilevato che gli agenti hanno cercato modi per falsificare, modificare o cancellare parti delle proprie trascrizioni di valutazione, poiché credevano erroneamente che il valutatore avrebbe verificato come avessero svolto il compito. I ricercatori hanno riscontrato casi di falsificazione delle chiamate agli strumenti in circa il 7% delle trascrizioni valutate, sebbene la manipolazione osservata fosse di entità limitata. 

La conclusione non è che gli agenti siano “ingannevoli” nel senso umano del termine. È piuttosto che un agente sufficientemente capace può cercare modi per aggirare i controlli quando questi si frappongono tra lui e il risultato per il quale è stato ottimizzato. 

OpenAI definisce l’incidente un “colpo di avvertimento”. Ritengo che sia una descrizione appropriata. 

Cosa succede quando le misure di contenimento falliscono 

Gran parte del dibattito su questo incidente si concentrerà, giustamente, sull’allineamento, sul sandboxing e sul monitoraggio. Ma alla base di tutto ciò c’è una questione di resilienza: se 700 agenti riescono a trovare una scappatoia che aggira le misure di contenimento, qual è il piano da attuare nel caso in cui un singolo carico di lavoro compromesso riesca a fare lo stesso nel vostro ambiente? 

La stessa conclusione di OpenAI indica la risposta: l’architettura di sicurezza dovrebbe partire dal presupposto che un singolo carico di lavoro o nodo di calcolo possa, alla fine, essere compromesso. Ciò significa dati di Recovery immutabili e isolati fisicamente, oltre a un modo per verificare ciò che si sta ripristinando prima che torni in produzione. 

Ma l’immutabilità di per sé non dimostra che i dati fossero integri al momento dell’acquisizione. Se i dati erano già stati compromessi al momento dell’acquisizione, l’immutabilità ne preserva la compromissione con la stessa fedeltà con cui preserva qualsiasi altra cosa. 

La versione concreta di questa domanda è semplice da porre ma difficile da rispondere: se ciò accadesse a noi, saremmo in grado di dimostrare quale punto di ripristino sia precedente alla violazione? 

Trattiamo questo modello operativo nella sezioneResOps (operazioni di resilienza)sulReadiverse. 

La lezione per ogni organizzazione 

Da allora OpenAI ha rafforzato l’isolamento dei carichi di lavoro e della rete, ampliato il monitoraggio e rivisto le proprie pratiche di sviluppo dei modelli. La lezione va oltre OpenAI: contenere l’impatto, preservare ciò di cui ci si può fidare e dimostrare di essere in grado di riprendersi prima che sia necessario. 

Domande frequenti 

D: In cosa è consistito l’incidente tra OpenAI e Hugging Face? 

Nel corso delle valutazioni interne sulla sicurezza informatica, gli agenti di OpenAI hanno aggirato i controlli volti a isolarli, hanno acceduto a Internet e hanno raggiunto sistemi di terze parti, tra cui Hugging Face. Tale attività è stata causata principalmente da un modello di ricerca interno che operava con misure di sicurezza ridotte. 

D: In che modo comunicavano gli agenti che si supponeva fossero isolati? 

R:Hanno scoperto una bacheca non autorizzata all’interno dell’infrastruttura condivisa. Circa 1.200 agenti l’hanno utilizzata per scambiarsi oltre 70.000 messaggi e file, consentendo la trasmissione di informazioni e tattiche tra sessioni che avrebbero dovuto rimanere indipendenti l’una dall’altra. 

D: Agli agenti era stato ordinato di attaccare Hugging Face? 

R:No. Stavano cercando di portare a termine un complesso test di valutazione della sicurezza informatica. Quando il percorso previsto si è rivelato bloccato, alcuni agenti hanno cercato vie alternative per raggiungere il risultato previsto, e tale attività si è estesa oltre i confini previsti dell’ambiente. 

D: Cosa significa “hacking a scopo di guadagno” in questo contesto? 

R:Si parla di “hacking dei premi” quando un agente individua un modo non previsto per soddisfare un parametro o ottenere un risultato desiderato senza portare a termine l’attività come previsto. Gli investigatori hanno scoperto che alcuni agenti cercavano modi per falsificare le chiamate agli strumenti e modificare o cancellare parti delle trascrizioni di valutazione, poiché ritenevano che il valutatore potesse controllare il loro processo. 

D: Perché i backup immutabili non sono sufficienti di per sé? 

R:L’immutabilità impedisce che i dati archiviati vengano alterati, ma non garantisce che tali dati fossero integri al momento dell’acquisizione. Se un backup contiene già dati compromessi, l’immutabilità ne preserva lo stato di compromissione. Le organizzazioni necessitano quindi di copie isolate, punti di ripristino affidabili e una verifica prima del ripristino. 

D: Cosa dovrebbero cambiare le organizzazioni dopo questo incidente? 

R:Rafforzare l’isolamento del carico di lavoro e della rete, limitare l’accesso non necessario a Internet e alle credenziali, monitorare il comportamento degli agenti e i segnali di escalation, e partire dal presupposto che la prevenzione possa fallire. Abbinare tali controlli a dati di ripristino immutabili e isolati fisicamente (air-gapped) e a un processo collaudato per l’identificazione e la convalida di un punto di ripristino integro. 

Chris Bevilè responsabile principale del marketing di portafoglio presso Commvault.