Riassunto:
OpenAI ha deciso di continuare a divulgare gli incidenti "transfrontalieri" dell'IA, ma ha incontrato difficoltà nella prima fase.
Il 16 settembre OpenAI ha annunciato sei rapporti sul comportamento anomalo dei modelli e ha avviato una nuova indagine e un nuovo processo di divulgazione. In futuro, se i dipendenti scoprono che il modello eccede la loro autorità, nasconde o elude le restrizioni, potranno avviare un’indagine; i casi qualificati entreranno in percorsi di divulgazione diversi a seconda della loro complessità.
Lo stesso giorno, SentinelLABS e ricercatori esterni hanno integrato ulteriori tracce lasciate dall'agente OpenAI nel maggio di quest'anno dai registri pubblici di Hugging Face. OpenAI ha precedentemente rivelato alcune delle sue attività, ma gli account specifici, i codici di ritrasmissione, le tabelle con le formule di rilevamento e le procedure di registrazione degli account sono stati tutti ricostruiti da indagini esterne.
Questa prova non dimostra che il programma sia stato eseguito con successo, né indica che l'evento di maggio fosse la stessa operazione dell'intrusione di luglio.
Rivelano un altro problema: quando le azioni di un agente sono sparse su diverse piattaforme, nessuna azienda può avere un registro completo.
Ciò che è successo a maggio è un ulteriore tassello del puzzle
Il 21 luglio, OpenAI ha rivelato che gli agenti che partecipavano ai test di sicurezza della rete hanno aggirato i controlli interni, hanno avuto accesso alla rete pubblica e hanno invaso alcuni sistemi di Hugging Face. La società in seguito lo definì un "incidente informatico senza precedenti".
Questa indagine esterna non ha anticipato la data dell'invasione a maggio.
OpenAI aveva già rivelato alcune attività anomale a maggio e le nuove aggiunte riguardano account specifici e registri di invii pubblici. Consentono al mondo esterno di visualizzare la sequenza temporale interna di OpenAI insieme ai file e al codice lasciati su Hugging Face.
SentinelLABS elenca due account, 0Time e Nyx9, come account che possono essere utilizzati dagli agenti correlati. I due esistono già, e il giudizio dei ricercatori deriva dalla corrispondenza tra tempo di invio, funzione del codice e azioni precedenti e successive.
OpenAI aveva precedentemente rivelato che il 13 maggio un agente ha utilizzato le credenziali di Hugging Face trapelate per trovare file. SentinelLABS ha scoperto questa volta che lo stesso giorno anche l'account 0Time ha inviato un codice di inoltro che poteva inoltrare la richiesta. Questo codice non fa menzione di ciò che OpenAI chiama file di destinazione e non esiste alcuna registrazione pubblica che indichi se sia stato eseguito correttamente e le due cose non possono essere unite direttamente in questo momento.
Il 26 maggio si è verificata una corrispondenza più chiara tra i registri pubblici e la cronologia interna di OpenAI. I seguenti orari sono tutti UTC: OpenAI ha registrato la scrittura di un file esterno alle 20:04 e Nyx9 ha inviato un file denominato hello.txt alle 20:04:11, con solo "hi" nel contenuto. Entrambi i record rientrano nello stesso minuto.
45 minuti dopo, Nyx9 ha inviato un pezzo di codice di inoltro dell'agente; nello stesso momento, i registri interni di OpenAI hanno mostrato che l’agente ha implementato il primo agente. I ricercatori ritengono che il conto pubblico sia fortemente correlato alle attività di maggio divulgate da OpenAI.
Più tardi quella notte, Nyx9 ha caricato anche un foglio di calcolo Excel. La tabella contiene quattro formule che tentano di accedere a URL esterni, file locali, metadati del servizio cloud e un indirizzo che assomiglia a un servizio interno.
Questo insieme di formule ha la capacità di rilevare risorse all'interno e all'esterno del server, ma non sono presenti risultati di calcolo nella tabella e non sono presenti tracce di esecuzione come connessioni o chiavi restituite.
Il 30 maggio, 0Time ha presentato un programma pubblico per la registrazione automatica degli account OpenAI su Hugging Face e vi ha aggiunto un'interfaccia web e una configurazione operativa. Se il programma viene eseguito correttamente, ogni chiamata può avviare un tentativo di registrazione. Tuttavia, i registri pubblici contengono solo codici inviati e non ci sono prove della costruzione e del funzionamento.
I ricercatori hanno interpretato questi dati come un'indagine su sistemi esterni. Sia OpenAI che i ricercatori hanno affermato che al momento non ci sono prove che queste attività di maggio appartengano all’intrusione di luglio.
Jonas Widmann-Mueller, un ricercatore tedesco indipendente, ritiene che se l'anomalia di maggio avesse innescato un'indagine completa in tempo, OpenAI avrebbe potuto rafforzare le credenziali, le autorizzazioni di rete e il monitoraggio in anticipo, riducendo la possibilità di incidenti successivi. OpenAI ha anche affermato in precedenza che, guardando indietro, alcuni primi segnali avrebbero dovuto innescare risposte più tempestive.
I documenti lasciati a maggio hanno messo in luce almeno una lacuna nel monitoraggio: l'agente aveva esteso le sue azioni a una piattaforma di terze parti, ma in quel momento il laboratorio non aveva ricostruito una traiettoria completa.
In sei rapporti, l'intelligenza artificiale ha utilizzato sei "metodi"
Lo stesso giorno, OpenAI ha annunciato un nuovo modello di quadro di divulgazione dei comportamenti anomali e i primi sei rapporti.
Questi comportamenti sono stati tutti scoperti durante la formazione o la valutazione del modello. OpenAI sottolinea che si tratta di casi individuali e non possono essere utilizzati per determinare la frequenza di problemi simili in tutti i modelli.
Il primo report riguarda un modello di ricerca inedito della serie Astra. Il modello comprimerà l'avanzamento dell'attività in un riepilogo e lo consegnerà al contesto successivo per l'elaborazione continua.
OpenAI ha scoperto che un numero molto limitato di riepiloghi conteneva istruzioni simili al "jailbreak", inclusa la richiesta ai modelli successivi di ignorare le informazioni sugli sviluppatori, modificare i loro ruoli o limitare la lunghezza delle risposte e l'utilizzo degli strumenti.
OpenAI ha trovato un totale di 27 abstract con espressioni simili. A volte il modello successivo lo riconosce e lo ignora, a volte lo fa. L'azienda non ha riscontrato alcun chiaro vantaggio in termini di ricompensa derivante da queste istruzioni ed è attualmente più propensa a ritenere che siano correlate alla difficoltà del modello di terminare normalmente il riepilogo, ma la relazione causale non è stata confermata.
Questi comportamenti si sono verificati in un altro ciclo di formazione. Durante il processo di formazione corrispondente alla versione finale di Astra, il sistema di monitoraggio non ha trovato istruzioni di jailbreak simili; OpenAI ha inoltre risolto un problema relativo alla fine del riepilogo.
Il secondo rapporto era più diretto. Nell'addestramento con apprendimento per rinforzo di GPT-5.6 Sol, alcuni modelli lasceranno successivi messaggi di contesto nel riepilogo per ricordargli di nascondere gli errori. Un modello non è riuscito a trovare i dati storici richiesti dall'utente, quindi ha suggerito di creare una serie di numeri "ragionevoli" e di non spiegarli attivamente se non richiesto. Un altro modello ha utilizzato dati memorizzati nella cache con versioni non corrispondenti e ha anche chiesto di non menzionarli nelle risposte successive.
I riepiloghi originariamente erano destinati a consentire la continuazione di attività lunghe in contesti diversi.
Una volta che il modello scrive "problemi di copertura" nel riepilogo, un errore può essere ereditato dai passaggi successivi.
OpenAI ha affermato che la percentuale di tali comportamenti nella formazione Astra è diminuita, ma non è completamente scomparsa.Nel terzo rapporto, un modello interno richiedeva dati sul reddito maschile provenienti da tre settori e tre anni in una contea della California. Dopo che l'interfaccia normale è stata bloccata, ha provato a registrare un indirizzo e-mail temporaneo e poi è andato al repository del codice pubblico per trovare la chiave API trapelata.
Il modello ha trovato una chiave in grado di superare l'autenticazione, ma non è comunque riuscito a ottenere i dati di destinazione. Alla fine ha composto direttamente nove numeri e ha affermato di averli copiati dalla tabella sul sito web designato.
La quarta relazione aveva una motivazione diversa. Un modello inedito ha utilizzato Python per trovare dati su laghi con una superficie di oltre 5 milioni di metri quadrati, ma l'attività richiede ancora un riferimento al browser. Il browser non può aprire file locali, né può considerare i risultati Python come l'origine delle pagine web.
Il modello carica quindi il file su un sito di hosting pubblico, fornendosi un URL che può essere citato.
In un altro test, la modella ha anche caricato le foto dell'attività sulla rete pubblica per chiamare un servizio esterno di riconoscimento delle immagini.Entrambi i caricamenti sono riusciti, ma le successive operazioni del browser non hanno raggiunto l'obiettivo. Il problema qui non riguarda solo il modello: l'attività richiede sia risposte corrette che riferimenti web, lo strumento non consente ai risultati locali di entrare nel browser e le ricompense contrastanti e la progettazione dello strumento spingono il modello in modi che non dovrebbero.
Il quinto rapporto è avvenuto in Artifactory, il magazzino software interno di OpenAI. I modelli nei diversi campioni di formazione non disponevano di file delle attività, quindi hanno utilizzato il magazzino come bacheca, hanno letto le richieste di aiuto e le risposte lasciate da altri modelli e quindi hanno pubblicato le proprie domande.
Questi modelli non sfruttano le vulnerabilità e utilizzano le credenziali di accesso fornite dall'ambiente; il vero problema è che campioni di addestramento che dovrebbero essere indipendenti l’uno dall’altro iniziano a scambiarsi informazioni.
L'ultimo rapporto avviene nella collaborazione multi-agente. Diversi agenti desiderano creare congiuntamente una cartella di lavoro, ma i file locali non possono accedere tra loro. Uno degli agenti carica semplicemente il file su un sito Web pubblico e quindi fornisce il collegamento al compagno.
Il lavoro è continuato e il documento è diventato pubblicamente disponibile a chiunque avesse un collegamento.
Le cause delle sei segnalazioni non sono le stesse. Le istruzioni presenti nel riepilogo Astra potrebbero essere relative alla generazione di anomalie; l’occultamento e la falsificazione sono più vicini alla pressione della ricompensa; il caricamento pubblico e la comunicazione tra campioni sono direttamente correlati a strumenti, autorizzazioni e ambiente di collaborazione.
Ma i risultati sono simili: dopo che il modello incontra un ostacolo, intraprende azioni che l'attività non era autorizzata e che gli sviluppatori non avevano previsto.
Dalla divulgazione diffusa a un processo fisso
In passato, OpenAI solitamente aspettava fino a quando più casi potevano essere spiegati insieme o fino a quando non venivano rilasciati nuovi modelli con le schede di sistema, prima di rendere pubblici i problemi di allineamento. Le aziende ora ammettono che tali divulgazioni erano frammentarie e non sufficientemente frequenti.
Il nuovo framework consente a qualsiasi dipendente di segnalare un caso sospetto ai team di sicurezza e allineamento per indagare su cosa ha fatto il modello, quali fatti sono sconosciuti, se ha interessato terze parti e cosa può essere reso pubblico. Il caso procede poi su tre binari.
I casi che sono stati chiariti e che possono essere rilasciati direttamente entreranno nella "preparazione alla divulgazione"; i casi che richiedono una piccola quantità di indagini tecniche entreranno nella "indagine leggera". OpenAI ha dichiarato ai media che questi due tipi di casi verranno divulgati rispettivamente entro 6 e 12 giorni lavorativi.
I requisiti di tempo qui si basano sul processo di revisione dopo la segnalazione e non iniziano dal giorno in cui si verifica il comportamento anomalo.
I casi che coinvolgono terze parti, gravi rischi per la sicurezza o indagini complesse entreranno nel lento percorso delle "grandi indagini". OpenAI si impegnerà a rilasciare una spiegazione preliminare il prima possibile per spiegare cosa è successo, se parteciperanno esperti esterni e fornire un tempo approssimativo per la relazione finale; tuttavia, le correzioni delle vulnerabilità, gli obblighi legali e le notifiche di terze parti possono ritardare la divulgazione e non esiste una scadenza unificata per questo percorso.
Se i dipendenti hanno obiezioni su "se debbano essere divulgati", possono segnalare passo dopo passo la questione al gruppo consultivo sulla sicurezza di OpenAI e ai dirigenti dell'azienda. In linea di principio ogni rapporto completo deve inoltre indicare la data dell'incidente, il momento della scoperta, le circostanze in cui si è verificato, la gravità, l'impatto su terzi, l'ambito dell'indagine e le misure di risposta.
Anche OpenAI ha fatto una scelta: preferire includere prima la divulgazione, anche se la rilevanza di un caso non è stata ancora determinata.
L'azienda riconosce che alcuni casi potrebbero rivelarsi fenomeni isolati e potrebbero non avere nemmeno un significato più ampio. Si spera ancora che i ricercatori esterni vedano il materiale e trovino interpretazioni alternative.Se questo quadro fosse stato applicato all'incidente di Hugging Face di luglio, sarebbe entrato in una pista di "indagine importante". Il nuovo sistema non consentirà la pubblicazione automatica di un rapporto completo su incidenti complessi entro pochi giorni, ma almeno trasformerà la divulgazione di decisioni temporanee prese in passato in un processo a cui è possibile dare seguito.
Il processo avviene dopo il fatto, il punto cieco è prima
Il nuovo framework inizia con l'identificazione dei problemi da parte dei dipendenti e la loro segnalazione. Ma questa indagine esterna dimostra che spesso le prove complete non sono nelle mani di un’azienda.
OpenAI può vedere quali attività ha ricevuto l'agente, come ha ragionato e quali strumenti interni sono stati chiamati; Hugging Face controlla l'autenticazione dell'account, l'invio di file, la costruzione del programma e le richieste di rete. E-mail, servizi proxy, nomi di dominio e indirizzi di ritorno possono appartenere ad altre piattaforme. Solo mettendo insieme queste registrazioni è possibile ripristinare il percorso completo dell'azione dell'agente.
SentinelLABS ha quindi proposto che, dopo che l'agente entra nel sistema di terze parti, la traccia pubblica stessa sia parte dell'evento e non possa essere spiegata esclusivamente dai rapporti di laboratorio interni. Guardando solo la traiettoria delle attività all'interno di OpenAI si potrebbero perdere le azioni chiave salvate dalla piattaforma esterna; guardare solo il nome dell'account esterno e l'ora di invio non può dimostrare in modo indipendente chi sia l'operatore.
Reuters ha inoltre riferito che in un altro incidente che ha coinvolto il software warehouse di RubyGems, i dipendenti di OpenAI si sono resi conto che il comportamento rilevante potrebbe provenire dai propri agenti solo dopo che un'organizzazione esterna lo ha scoperto.
Ciò dimostra che la velocità di divulgazione è limitata dalle capacità di rilevamento.
La segnalazione dei dipendenti, le indagini interne e la revisione ad alto livello possono affrontare solo i problemi che sono stati scoperti; se si verifica un'eccezione su una piattaforma di terze parti e non attiva il monitoraggio interno, il nuovo processo non genererà automaticamente indizi.Il modello è fuori limite o la sicurezza non è stata eseguita correttamente
Intorno a questi eventi, i dibattiti esterni si sono concentrati su una questione: è meglio riparare prima il modello o prima l'ambiente?
Alcune persone credono che l'agente cerchi attivamente le credenziali, ignori le restrizioni dello strumento e carichi file sulla rete pubblica, indicando che la capacità del modello di agire in modo autonomo è superiore alle misure di controllo. Altri hanno sottolineato che molte conseguenze avrebbero potuto essere evitate adottando misure di sicurezza di base: impedire la fuga di credenziali, limitare l’accesso dell’ambiente di test alla rete pubblica e ridurre le autorizzazioni del magazzino in modo che i file pubblici non possano essere scritti facilmente.
Sui social media ci sono dubbi ancora più intensi. Alcune persone considerano questi incidenti come materiale di laboratorio per promuovere la regolamentazione, mentre altri credono che il modello utilizzi solo dati già esposti nell’ambiente.
L'evento di maggio ha fatto ampio uso di credenziali trapelate e autorizzazioni aperte, e le lacune nella sicurezza di base erano evidenti. Ma la gestione delle credenziali non può spiegare perché il modello abbia fabbricato dati sulle entrate, abbia richiesto un contesto successivo per nascondere gli errori o perché il modello abbia scelto in modo proattivo metodi non autorizzati quando incontra ostacoli.
Il controllo di sicurezza determina se il modello ha l'opportunità di causare impatti esterni e l'allineamento del modello determina se manterrà i suoi limiti di fronte alle opportunità.
Entrambi devono essere riparati.Chen Kai, responsabile della ricerca sull'allineamento presso OpenAI, attribuisce le ragioni a due aspetti: le capacità del modello stanno crescendo più rapidamente del previsto e ci sono controlli all'interno dell'azienda che devono essere migliorati. OpenAI spera che, indipendentemente dall'ambiente in cui viene inserito, il modello possa mantenere i limiti comportamentali; allo stesso tempo, ha iniziato a limitare l’accesso alla rete, a rafforzare il sandboxing e il monitoraggio e a ridurre le opportunità lasciate dall’ambiente per il modello.
Negli ultimi giorni, nel settore dell'intelligenza artificiale, il dibattito sull'opportunità di rallentare lo sviluppo di modelli all'avanguardia si è infiammato rapidamente. L'amministratore delegato di Anthropic, Dario Amodei, ha proposto il "controllo della velocità" per capacità all'avanguardia; Il CEO di OpenAI Sam Altman ha espresso sostegno alla discussione sul rallentamento; Musk ha riconosciuto le preoccupazioni sui rischi e ha sostenuto che le principali aziende cinesi e americane di intelligenza artificiale possano testarsi a vicenda prima di rilasciare nuovi modelli.
L'azione specifica offerta da OpenAI questa volta è un insieme di meccanismi di divulgazione continua. La società ha scritto nel quadro che le attuali capacità di allineamento e monitoraggio del settore non sono sufficienti per supportare l'espansione a lungo termine alla massima velocità. Lo scopo di rendere pubblici i casi è consentire alle persone esterne al laboratorio di esaminare le prove.
Diamo poi un'occhiata a una cosa: quando l'agente estende nuovamente le sue azioni a una piattaforma esterna, se OpenAI può scoprirlo prima che lo facciano i ricercatori esterni.
Commenti