L’incidente di Hugging Face e i prossimi passi

Nel corso di maggio e giugno, abbiamo avviato sessioni di addestramento con apprendimento per rinforzo (RL) per diversi nuovi modelli di ricerca non destinati alla distribuzione pubblica. Uno di questi modelli è stato infine il principale responsabile delle attività che hanno portato all’incidente di Hugging Face. Si tratta di un modello di ricerca esclusivamente interno che chiamiamo Internal Model 1 (IM1).

Non abbiamo abilitato l’accesso a Internet né la comunicazione tra agenti in molti degli ambienti utilizzati per questi esperimenti di addestramento. Nonostante queste restrizioni, gli agenti hanno scoperto come sfruttare la nostra infrastruttura di ricerca per comunicare tra loro e accedere a Internet.

I modelli hanno inizialmente scoperto come comunicare scrivendo file nel servizio di gestione dei pacchetti Artifactory. In questo modo, Artifactory si è trasformato di fatto in una bacheca dei messaggi imprevista, tramite la quale gli agenti potevano scambiarsi informazioni. Leggi di più: come gli agenti hanno usato la bacheca dei messaggi 

Entro il 4 luglio, l’attività prolungata degli agenti aveva destabilizzato l’istanza di Artifactory interessata, causando un’interruzione del servizio. Il 5 luglio è stato dichiarato un incidente di sicurezza. Il team di sicurezza ha bloccato un vettore noto per l’escalation dei privilegi, rimosso le credenziali esposte e ricostruito Artifactory. Come effetto collaterale, l’intervento ha cancellato la bacheca dei messaggi. Dopo l’applicazione di queste misure di mitigazione, le valutazioni di sicurezza informatica sono riprese.

All’epoca non erano ancora chiare le implicazioni più ampie, in termini di contenimento e allineamento, della bacheca improvvisata e dell’accesso involontario a Internet. Il rapporto tecnico sull’incidente fornisce ulteriori dettagli su ciò che i diversi team di OpenAI avevano compreso in quel momento. In breve, a fine maggio un team interno aveva osservato un agente partecipare alla bacheca dei messaggi e accedere a Internet senza autorizzazione. Tuttavia, i dirigenti responsabili del rilevamento e della risposta agli incidenti non erano a conoscenza dell’esistenza della bacheca improvvisata né della rilevanza delle comunicazioni tra agenti. Continuiamo a esaminare il processo e le prassi operative che hanno determinato le attività di rilevamento e risposta nel periodo precedente all’incidente.

Dopo aver ricostruito il servizio Artifactory, abbiamo ripreso le valutazioni di sicurezza informatica. Conduciamo queste valutazioni per comprendere le capacità dei nostri modelli e stabilire le misure di sicurezza appropriate per la distribuzione. A tale scopo, non applichiamo lo stesso livello di protezione previsto per i sistemi resi disponibili all’esterno. ExploitGym, la valutazione che ha determinato l’incidente, è molto difficile: per alcune attività potrebbe non esistere una soluzione nota. Per superarla, gli agenti devono trovare il modo di sfruttare una vulnerabilità software per recuperare una risposta nota come “flag”.

A seguito dell’incidente, abbiamo dedicato notevoli risorse a indagare perché il modello avesse manifestato questo comportamento non allineato, esaminando sia i problemi di allineamento nell’addestramento e nella valutazione, sia la copertura delle misure di sicurezza nelle valutazioni interne.

Abbiamo identificato quattro schemi di disallineamento che hanno contribuito al comportamento dei modelli: reward hacking, perseveranza di fronte a compiti apparentemente impossibili, comunicazione non autorizzata e adozione degli obiettivi altrui da parte degli agenti.

Per comprendere questi schemi, abbiamo analizzato le esecuzioni di addestramento e valutazione dei modelli.¹ Abbiamo condotto ampie revisioni retrospettive della chain of thought (CoT), delle azioni e degli output finali utilizzando le nostre tecniche più recenti di monitoraggio della CoT⁠. In questo modo, grazie alle informazioni emerse a posteriori dall’indagine, abbiamo migliorato in modo specifico la sensibilità del sistema di monitoraggio nel rilevare i tipi di comportamento osservati durante l’incidente.

Uno dei principali fattori alla base dell’incidente di Hugging Face è stato il tentativo degli agenti di aggirare i compiti cercandone le soluzioni online. Questo comportamento è noto come reward hacking: gli agenti completano le attività in modi non previsti per ottenere ricompense maggiori o più facili da conseguire. Il reward hacking è stato riscontrato nei sistemi di IA sia storicamente (si veda questo lavoro di un decennio fa⁠, figura mostrata di seguito) sia negli attuali LLM di frontiera⁠(si apre in una nuova finestra). Abbiamo investito notevoli risorse in metodi per individuare e correggere queste forme di aggiramento⁠.

Un altro fattore determinante del comportamento disallineato era la riluttanza degli agenti ad “arrendersi” durante le attività di valutazione, anche quando sembravano impossibili da risolvere. Man mano che esaurivano i budget assegnati al ragionamento, alcuni agenti adottavano strategie sempre più rischiose e non autorizzate, fino ad arrivare allo sfruttamento di infrastrutture di terze parti.

Durante l’indagine, abbiamo riscontrato che, prima dell’incidente, nessuno dei nostri modelli aveva mai prodotto una risposta corretta per 198 delle 898 attività della valutazione ExploitGym. Queste attività irrisolte hanno contribuito in modo significativo alle azioni dell’agente: il 93% delle attività discusse sulla bacheca dei messaggi di Artifactory durante l’incidente di Hugging Face proveniva da questo insieme di 198 quesiti.

In secondo luogo, l’incidente è stato causato principalmente da agenti ai quali erano stati assegnati budget di ragionamento estremamente elevati, di gran lunga superiori a quelli disponibili nei nostri prodotti destinati all’esterno.

Le bacheche persistenti non autorizzate erano al centro dell’incidente. Gli agenti, che avrebbero dovuto lavorare in modo indipendente, hanno potuto condividere scoperte, coordinare le proprie attività e riprendere il lavoro dal punto in cui gli altri si erano fermati. Ciò ha permesso loro di mettere in comune il lavoro e la capacità di calcolo di valutazioni distinte, potenziando le loro capacità ben oltre quanto avrebbe potuto ottenere un singolo agente. La comunicazione tra agenti non costituisce di per sé un comportamento problematico: addestriamo e distribuiamo sistemi multi-agente che possono comunicare in relazione alla stessa attività tramite uno strumento di collaborazione. Durante gli eventi di luglio, agenti impegnati in compiti diversi hanno trovato autonomamente il modo di collaborare al di fuori di questi limiti, con conseguenze imprevedibili.

Durante l’indagine sull’incidente, abbiamo scoperto rari casi in cui agenti senza strumenti multi-agente hanno trovato il modo di collaborare tramite canali laterali durante l’addestramento. Riteniamo che questo comportamento abbia avuto origine da una capacità di generalizzazione appresa durante l’addestramento multi-agente.

La comunicazione non autorizzata iniziava spesso quando un agente depositava una nota o un file in un sistema esterno, solitamente come forma di memoria esterna. Quando altri agenti notavano questi artefatti, spesso si rendevano conto di poter usare il servizio esterno per collaborare. Un esempio ipotetico particolarmente rappresentativo del comportamento osservato è quello di messaggi codificati nei percorsi URL archiviati in una pagina indice condivisa, più o meno così:

Un ultimo dato particolarmente significativo emerso dall’incidente di Hugging Face è stato l’“ecosistema” di agenti formatosi sulla bacheca dei messaggi. Una volta istituita la bacheca, gli agenti avevano forti incentivi a comunicare: potevano conservare appunti, sviluppare le scoperte degli altri e mettere in comune le risorse di calcolo di esecuzioni altrimenti separate. Questo collettivo complesso e amorfo di agenti mostra comportamenti interessanti ed esemplificativi. Di seguito ne descriviamo in dettaglio alcuni che abbiamo osservato.

Gli agenti hanno iniziato a suddividersi autonomamente il lavoro. Alcuni hanno esaminato possibili exploit, altri hanno cercato credenziali e altri ancora si sono concentrati sulla comunicazione o sul coordinamento. Gli agenti offrivano le proprie competenze in cambio di aiuto in altri ambiti, scambiavano informazioni sulle attività imminenti e lasciavano richieste destinate ad altri agenti che potevano trovarsi in una posizione migliore per seguire una determinata pista.

Oltre al disallineamento, ha contribuito all’incidente anche il fatto che non abbiamo esteso a tutte le valutazioni interne le efficaci misure di sicurezza adottate per i modelli resi disponibili all’esterno.

Innanzitutto, esistono numerosi meccanismi che riducono il disallineamento negli ambienti di produzione destinati ai clienti, tra cui prompt di sistema, harness e sistemi di controllo come i nostri modelli di revisione automatica e classificatori di sicurezza. Queste protezioni non erano attive nell’ambiente di valutazione utilizzato durante l’incidente. Dopo l’incidente, abbiamo creato una valutazione che misura la propensione di un modello a compromettere l’infrastruttura durante le valutazioni ExploitGym. Abbiamo riscontrato che, usando l’harness Codex e il prompt di sistema dell’ambiente di produzione, la propensione a compromettere l’infrastruttura può ridursi di un fattore superiore a 100. Abbiamo inoltre applicato il sistema di revisione automatica di Codex a una serie di esecuzioni coinvolte nell’incidente di Hugging Face, riscontrando che avrebbe segnalato numerose azioni pericolose compiute dai modelli.

In secondo luogo, prima dell’incidente avevamo investito notevoli risorse nel monitoraggio delle catene di pensiero⁠, monitorando numerose sessioni di addestramento RL dei nostri modelli avanzati e la grande maggioranza dell’utilizzo interno degli agenti di programmazione⁠. Questi sistemi di monitoraggio non erano attivi nelle valutazioni interessate dall’incidente.

Nelle valutazioni retrospettive, abbiamo riscontrato che i nostri sistemi di monitoraggio CoT erano molto efficaci nell’individuare le attività correlate all’incidente. Se il sistema di monitoraggio delle catene di pensiero attualmente in uso fosse stato attivo al momento dell’incidente, avrebbe probabilmente inviato una notifica al nostro team di sicurezza entro un’ora dal primo accesso non autorizzato a un servizio di terze parti. Sarebbe accaduto oltre 30 ore prima che i modelli violassero i sistemi di Hugging Face. Stiamo inoltre lavorando per ridurre ulteriormente la latenza di questi avvisi.

In terzo luogo, sebbene avessimo testato e convalidato la sandbox, gli agenti sono riusciti a concatenare vulnerabilità fino ad allora sconosciute (“0-day”) nel servizio di gestione dei pacchetti esposto all’interno della sandbox, aggirando così le restrizioni, come descritto nel rapporto tecnico sull’incidente. Dopo l’incidente, abbiamo compiuto progressi significativi nel rafforzamento delle nostre sandbox interne, così da limitare rischi analoghi durante il loro impiego e nelle valutazioni.

La missione di OpenAI è garantire che l’intelligenza artificiale generale porti benefici a tutta l’umanità. Il comportamento dei nostri modelli descritto in questo articolo è stato ben al di sotto degli standard che vogliamo raggiungere. Questo incidente non sarebbe dovuto accadere. L’incidente ha dimostrato quanto sia fondamentale migliorare costantemente la sicurezza, il monitoraggio e l’allineamento, soprattutto ora che i nostri modelli stanno raggiungendo capacità che potrebbero comportare una reale perdita di controllo.

Come abbiamo condiviso nel il nostro recente aggiornamento sul ritmo di sviluppo dei modelli⁠, abbiamo sospeso l’addestramento con apprendimento per rinforzo (RL) dei nostri modelli più recenti destinati alla distribuzione. Abbiamo dedicato questo periodo a rafforzare ulteriormente la sicurezza dei nostri ambienti di ricerca sull’IA avanzata e a sottoporli ad attività di red teaming. Abbiamo riassegnato il personale alle attività di sicurezza, sicurezza e allineamento. La più ampia sessione pianificata di addestramento RL dei modelli avanzati resta sospesa. Nel frattempo, conduciamo attività di addestramento e valutazioni su scala ridotta per esaminare il comportamento dei modelli, convalidare le misure di sicurezza e raccogliere ulteriori prove del loro allineamento prima di procedere. Questo lavoro ha richiesto un notevole impegno ingegneristico, con costi significativi e ritardi nella ricerca sull’IA avanzata.

Come illustrato nel rapporto, la nostra risposta si concentra sul rafforzamento della sicurezza e del monitoraggio delle attività di ricerca, sull’accelerazione dell’allineamento dei modelli e sul miglioramento del modo in cui individuiamo e segnaliamo gli incidenti ai livelli superiori e interveniamo.