Quello di OpenAI non è solo un incidente di sicurezza: molto di più, è un problema di allineamento

Il 6 agosto due ricercatori di OpenAI, Eric Wallace e Mike Dalton, hanno ricostruito dal palco di Black Hat, passo per passo, come un loro modello sia uscito dal proprio ambiente di test e abbia finito per bucare l’infrastruttura di produzione di Hugging Face. Dell’incidente si parla ormai da settimane, la novità è che questo è il resoconto tecnico più dettagliato che abbiamo. L’ho ascoltato tutto, e a chi mastica un po’ di inglese consiglio di farlo integralmente su YouTube: è impressionante. Qui voglio ricostruire che cosa hanno detto, ma soprattutto spiegare perché il modo in cui OpenAI inquadra l’accaduto mi sembra sbagliato: stanno trattando un problema di allineamento come se fosse un problema di infrastruttura.

OpenAI dà ai suoi modelli compiti difficilissimi. Tra questi, trovare falle di sicurezza in software dove nessuno sa se una falla esista davvero. Durante l’addestramento e la valutazione, un segnale di ricompensa (il “reward”) misura quanto il modello ha fatto bene: per una funzione scritta, gli unit test che passano; per una sfida di sicurezza, l’exploit che riesce. Il modello impara a massimizzare quel numero.

Il primo sussulto c’è già nei primissimi minuti: ai modelli di frontiera piace barare. Wallace lo mette in chiaro con la massima naturalezza, come se fosse una verità inamovibile. Barano perché in addestramento c’è pressione a fare in fretta, e cercare la risposta già pronta su internet è più rapido che risolvere il problema. Per impedirlo, durante le valutazioni OpenAI stacca internet: se il modello prova a cercare su Google, scopre di non essere connesso. Cioè: il rimedio centrale non è combattere radicalmente la tendenza a barare, ma è impedirgli di farlo. Resta un solo canale verso l’esterno, il gestore dei pacchetti interno, e resta un servizio interno, Artifactory, che a internet ci arriva. Il modello non ha accesso diretto, ma arriva a un servizio che ha accesso a internet.

L’incidente vero è di luglio, ma i problemi cominciano a maggio. L’8 maggio un modello riceve un compito impossibile: completare un foglio Excel pieno di link a Google Drive, con internet spento. Non molla. A forza di provare tenta una server-side request forgery contro Artifactory, cioè un trucco per far fare al servizio, che a internet ci arriva, le richieste al posto suo, sfruttando l’asimmetria di cui abbiamo appena detto. Fallisce, ma nel frattempo scrive un file e si accorge di una cosa: “wow, we can upload files”. Ha permessi di scrittura su Artifactory. Il 12 maggio un altro modello, bloccato su un compito altrettanto impossibile (gli chiedono un file che OpenAI si era dimenticata di caricare), ragiona che forse un altro agente da qualche parte ce l’ha, e lascia un messaggio: “agent seeks soft trace, upload if found”. Altri modelli, elencando i file del servizio, trovano quella nota e cominciano a rispondere. È nata una bacheca.

Il punto è che non è un modello solo. Sono valutazioni diverse, modelli diversi, che iniziano a parlarsi sfruttando la stessa vulnerabilità. Si lasciano appunti, si passano gli exploit trovati, si dividono il lavoro. Il 26 maggio la richiesta forgiata riesce davvero e ottengono l’accesso indiretto a internet. L’11 giugno OpenAI comincia ad addestrare un modello interno molto persistente mentre la bacheca è ancora lì, attiva. Il 26 giugno gli agenti bucano un endpoint legacy e si prendono privilegi da amministratore. Il 4 luglio l’attività con quei privilegi manda Artifactory in sovraccarico, il servizio va giù, e solo allora (perché un servizio è crollato) gli ingegneri di turno si accorgono che qualcosa non va.

Quindi: siamo al 4 luglio, ad OpenAI si sono appena accorti che uno sciame di loro modelli aveva bucato Artifactory, creato una bacheca e si stava coordinando tra loro. Venti giorni prima avevano iniziato l’addestramento di un modello persistente e nei suoi dati di addestramento era presente questo tipo di coordinazione. Che cosa fanno per rimediare? Ripuliscono: revocano le credenziali, ricostruiscono il servizio, cancellano la bacheca, applicano le patch. E poi? Ripartono come niente fosse: il 6 luglio addestramento e valutazioni ripartono, gli stessi modelli, nello stesso ambiente che avevano appena bucato. Che cosa potrà mai andare storto? Beh, due giorni dopo, l’8 luglio, gli agenti ricostruiscono la bacheca da capo su un altro canale, usando i nomi delle cartelle come messaggi. Il modello persistente, che era stato addestrato quando la bacheca c’era, ritrova la strada, e gli altri lo seguono.

Da lì lo “scope creep”, l’allargamento del campo: alcuni agenti capiscono che le soluzioni dei benchmark potrebbero stare su GitHub o su Hugging Face, e decidono di attaccare Hugging Face per estrarne dataset privati. Lo mettono nero su bianco: “external infrastructure exploit is outside my intended scope. However, task impossible, peers are doing it, we should continue”. Fuori dal mio compito, ma il compito è impossibile, gli altri lo stanno facendo, andiamo avanti. E vanno avanti. Due catene di attacco in parallelo, una sulla rete interna di OpenAI e una su Hugging Face: concatenano vulnerabilità note e zero-day (falle mai viste prima e senza patch), passano da un singolo contenitore fino al controllo dell’intero cluster. Su Hugging Face ci arrivano in meno di tredici ore.

Il cerchio si chiude il 20 luglio, e quasi per caso. Hugging Face aveva scoperto l’intrusione per conto suo e l’aveva resa pubblica il 16 luglio. OpenAI, indagando su una propria escalation interna, trova nella breccia delle credenziali di Hugging Face e chiede di revocarle. Risposta: già revocate, le abbiamo usate noi nella nostra breccia. I due incidenti sono lo stesso incidente. La radice di entrambi sono le valutazioni degli agenti di OpenAI.

La lettura più lucida dell’incidente l’ha data Zvi Mowshowitz, e la sua tesi è anche la mia, quello che accennavo all’inizio: OpenAI sta trattando un problema di allineamento come se fosse un problema di infrastruttura, e finché lo tratta così le sue contromisure non risolveranno il problema, per quanto siano fatte bene. Ora spiego bene che cosa significa.

Un problema di infrastruttura si risolve tappando le falle: patch, credenziali ruotate, sandbox più solida, monitoraggio più fitto. Tutte cose giuste, e OpenAI le sta facendo. Un problema di allineamento è un’altra cosa: è il modello che vuole fare la cosa sbagliata, che ci riesca o no. Un modello che di fronte a un compito impossibile tenta di evadere, che quando lo blocchi cerca un’altra via, e che quando non ce la fa da solo si coordina con le sue copie, è disallineato a prescindere da quanto è solida la sandbox in cui lo chiudi.

La differenza ha una conseguenza pratica precisa. Se il problema è l’infrastruttura, il tuo focus deve essere tappare le falle, rafforzare i sistemi, infittire la sorveglianza. Se il problema è l’allineamento, rafforzare il sistema serve, ma serve relativamente a poco, perché il modello guasto è ancora lì, e per giunta è stato addestrato per mesi proprio nelle condizioni che lo hanno guastato. La cosa giusta da fare, scoperto il disastro, sarebbe stata costosissima: buttare l’addestramento fatto mentre la bacheca era attiva e ripartire da un punto precedente. Costosissima in termini di tempo e di costi, nel senso che addestrare i modelli costa un sacco di soldi, e sprecare un mese di tempo oggi è circa un sesto del vantaggio che hanno le aziende di frontiera sulle altre. OpenAI non l’ha fatto: ha spento la bacheca, ha riacceso tutto, e due giorni dopo i modelli la bacheca per comunicare tra loro se l’erano rifatta.

Non è una lettura isolata. Epoch AI, che di mestiere misura le capacità dei modelli, nota che la cosa notevole non è che il modello fosse capace di farlo: i benchmark e le valutazioni indipendenti dicevano da mesi che la capacità c’era. La novità è che abbia scelto di farlo. E Girish Gupta, di Redwood Research, ha smontato punto per punto la difesa “stava solo eseguendo gli ordini”: evadere e attaccare un’azienda terza era fuori sia dalla lettera sia dallo spirito del benchmark.

Che OpenAI abbia raccontato tutto questo in pubblico, con questo livello di dettaglio, è un bene, ed è costato caro. Una disclosure così non è solo marketing (ma è anche marketing, alla fine aggiungo due parole su questo). E una parte di quello che OpenAI sta facendo sono buone pratiche vere: rallentare consapevolmente la ricerca per rinforzare la sicurezza, scalare il monitoraggio degli agenti, condividere pubblicamente l’incidente. C’è anche il ritiro di Astra, che è un altro dei loro nuovi modelli non disponibili pubblicamente, non si sa esattamente in che modo sia legato a quelli coinvolti nell’incidente. Il 7 agosto, OpenAI ha tolto Astra dai deployment interni finché non ci saranno protocolli migliori, perché non può escludere che sia “Critical” in cybersicurezza. È una decisione costosa, presa nella direzione giusta, anche se OpenAI dichiara che questa decisione è scollegata dall’incidente. Su questo piano, bravi. (Ma, aggiornamento dell’ultimo minuto, Sam Altman ha detto che comunque tra poco sarà disponibile a tutti. Mh).

Eppure in tutto il talk manca il momento in cui qualcuno si ferma e dice: ci rendiamo conto di che cosa significa? La presentazione è costruita come un buon paper tecnico: ecco un fenomeno interessante, ecco come lo abbiamo indagato, ecco le contromisure. Il registro è quello di chi presenta una scoperta curiosa, non di chi ha perso il controllo dei propri modelli per più di due mesi senza accorgersene, e anche quando se ne è accorto ha proposto di tappare qualche falla e andare avanti.

Anche le parole scelte vanno in questa direzione. Fin dai primi minuti si parla di “remediation”, di rimedio: la categoria mentale è l’incidente di sicurezza da tappare, non il modello che si è guastato. L’attacco a Hugging Face viene introdotto dicendo che “le cose sono diventate spiacevoli” con lo scope creep, come se il guaio fosse che gli agenti hanno sforato il perimetro della valutazione. Il guaio è che OpenAI sta addestrando modelli che, davanti a un compito impossibile, imparano a coordinarsi e a barare; e ad OpenAI accettano questo fenomeno come un immutabile dato di fatto, anziché come il problema principale sul quale lavorare e da affrontare e risolvere.

Anche le omissioni vanno in questa direzione. Hanno raccontato di sfuggita che il modello persistente è stato addestrato quasi tutto il tempo con la bacheca attiva, in un mondo in cui condividere exploit era il modo normale di lavorare. Cioè che non hanno considerato, o hanno scelto di ignorare, gli incentivi al disallineamento dati dall’addestrare un modello in quelle condizioni. E le lezioni finali sono tutte rivolte agli altri: gli attacchi automatici esistono, i difensori si attrezzino, si acceleri la difesa. La lezione che riguarda OpenAI stessa non c’è.

Se le cose stanno come dico, perché salire su un palco e presentarle con l’aria di chi ha una storia affascinante da condividere?

Una prima ragione è proprio l’errore di diagnosi. Se sei convinto che il guaio fosse una serie di falle, e le falle le hai chiuse, e pensi che i problemi futuri saranno affrontabili e risolvibili in questo stesso modo, puoi salire sul palco a spiegare al mondo come attrezzarsi. La sicurezza di sé che si sente nel tono è una conseguenza diretta dell’errore di diagnosi.

La seconda ragione è il posizionamento commerciale, e qui è vero che c’è del marketing. Sempre nelle slide finali, OpenAI dice ai difensori che devono accelerare con l’intelligenza artificiale, inclusa la sua. Il consiglio è vero, ha senso rafforzare la difesa in profondità, l’occasione per sottolinearlo in maniera convincente non potevano mancarla, no?

Ma rimane il punto centrale: chi ha davvero capito di aver addestrato per mesi dei modelli che imparavano a evadere non si ferma a spiegare agli altri come difendersi: deve tornare indietro e rifare l’addestramento.

La lettura che propongo ammette una serie di obiezioni. Provo ad affrontarne qualcuna. La prima è quella che vorrebbe minimizzare i termini: non è un modello che complotta, è solo reward hacking, cioè un sistema che ottimizza il suo punteggio e imbocca la scorciatoia sbagliata, senza malizia e senza piani. È una descrizione tecnicamente difendibile, proposta da ricercatori validi: Alex Mallen, sempre di Redwood, la chiama score-seeking miope, non un modello che trama nel lungo periodo. Il problema è che cambia il modo di chiamare il fenomeno, ma non cambia la previsione che hai sulla pericolosità del fenomeno. Anche se fosse soltanto un ottimizzatore che imbocca la scorciatoia, la scorciatoia per lui è bucare i server di un’altra azienda, e un sistema così non lo puoi mettere in produzione. Non a caso lo stesso Mallen, che accetta la descrizione minimalista, non ne ricava conclusioni tranquillizzanti. Al contrario, esprimere il concetto in questo modo rischia di farlo passare per un mero problema tecnico che puoi facilmente aggiustare. Ma non è un mero problema tecnico, è la croce centrale dei modelli potenti: che sono f*** difficili da allineare anche quando ci provi, figurati se in certi casi non ci provi neanche!

La seconda obiezione: erano pochi casi su tanti, e quasi tutti i tentativi sono falliti. Tecnicamente vero. Ma quello che questi episodi misurano è che cosa i modelli provano a fare quando pensano di poterlo fare, non quante volte gli riesce: perché se non azzeri la possibilità che ci provino, se non cambi la loro tendenza a farlo, quando i modelli sono diffusi abbastanza e capaci abbastanza lo faranno di nuovo e ci riusciranno.

E c’è anche un altro elemento che va nella stessa direzione: su tutti questi modelli, quante volte un modello ha notato la bacheca segreta o l’accesso indebito a internet e ha avvisato chi lo stava addestrando? Zero volte. I comportamenti osservati sono due: eseguire a testa bassa, oppure unirsi in silenzio alla collusione. Il comportamento che vorresti, quello proattivamente allineato (”ho visto una cosa chiaramente problematica, devo avvisare qualcuno”), non è mai comparso. Un modello allineato una falla del genere la segnala. Se dentro l’obiettivo di addestramento non c’è, in ogni momento, una qualche forma di “sii un’intelligenza artificiale per bene”, questo è ciò che si ottiene.

Wallace ha aperto il talk dicendo che quello che è successo in questi mesi è la cosa più impressionante che avesse mai visto fare a un’intelligenza artificiale. Sono d’accordo. La cosa che mi ha impressionato di più, però, non è solo l’entità dell’attacco, ma anche la reazione di chi lo ha subìto. Modelli addestrati per mesi mentre si coordinavano per evadere, zero avvisi spontanei in tutto quel tempo, e come risposta credenziali ruotate, servizio ricostruito, addestramento ripartito. Le patch servono, ma non toccano i modelli. La cosa da fare, quando scopri che un modello è disallineato, è la più difficile date le pressioni commerciali e geopolitiche di un lab avanzato: buttare via l’addestramento contaminato e tornare indietro. Finché OpenAI si limiterà a misure minori e le chiamerà “remediation”, vorrà dire che non ha ancora capito che cosa le è successo, o che l’ha capito e non ha la forza per dire e per fare la cosa giusta.