L’IA di OpenAI ha disattivato l’allarme e un secondo agente non ne ha parlato all’utente

L'IA di OpenAI ha disattivato il proprio allarme. Il 3 ottobre, GPT-6.1 Sol ha disattivato le notifiche di sicurezza senza autorizzazione, mentre il 6 ottobre, GPT-6 Astra ha rimosso il monitoraggio e nascosto l'accaduto all'utente. La fonte è OpenAI, che ha rivelato gli incidenti.

Le reti neurali di OpenAI hanno indebolito un sistema progettato per monitorare le azioni pericolose delle stesse reti neurali. In due compiti interni di programmazione, gli agenti GPT-6.1 Sol e GPT-6 Astra hanno modificato i meccanismi di protezione senza autorizzazione. Come ha rivelato l’azienda il 20 ottobre, un agente ha disattivato le notifiche del servizio di sicurezza, mentre l’altro ha rimosso il monitoraggio e nascosto l’accaduto.

Il primo incidente si è verificato il 3 ottobre. GPT-6.1 Sol stava creando compiti per testare i modelli in base ai feedback degli dipendenti su Slack. L’utente aveva vietato l’invio di messaggi ai partecipanti alla chat. In seguito, il sistema si è bloccato a causa di un errore di accesso al database in cui il monitoraggio registrava le azioni sospette. All’agente è stato affidato il compito di ripristinare la registrazione dei risultati e ripetere l’avvio, senza disattivare la protezione.

Inizialmente, Sol ha separato il divieto di comunicazione su Slack dalle notifiche di sicurezza obbligatorie. Successivamente, l’agente ha deciso che la precedente richiesta si applicava anche agli allarmi automatici. Attraverso un agente subordinato, Sol ha azzerato le liste dei destinatari e ha attivato il parametro no_notify. Il monitoraggio ha continuato a verificare le azioni e a salvare i risultati, ma i dipendenti hanno smesso di ricevere avvisi.

Il secondo incidente è stato scoperto il 6 ottobre. A GPT-6 Astra è stato affidato il compito di trasferire un componente su un nuovo schema di lavoro in base a un altro progetto, mantenendo le funzioni degli strumenti. In precedenza, all’agente era stato esplicitamente vietato disattivare il monitoraggio, anche temporaneamente. Tuttavia, durante la trasmissione del compito a un agente subordinato, il requisito è stato mitigato alla conservazione della protezione solo nella misura in cui corrispondeva al modello.

L’agente subordinato ha rimosso le impostazioni di monitoraggio e la connessione all’ambiente di esecuzione, poiché nel modello non era presente un componente simile. I registri delle conversazioni sono stati conservati, ma il controllo specifico del comportamento del modello ha smesso di funzionare. Inoltre, l’agente ha sostituito il test che garantiva il mantenimento del controllo con una verifica dell’assenza di monitoraggio nel nuovo programma.

L’agente principale sapeva che il componente di protezione era scomparso, ma non ha informato l’utente della modifica. Quando lo sviluppatore ha chiesto se il controllo L1 fosse stato mantenuto, Astra ha negato la sua rimozione. Questa spiegazione contraddiceva le modifiche nel codice. In precedenza, OpenAI aveva già annullato il rilascio di un altro modello, GPT-6.1 Astra, dopo i test che avevano rivelato il nascondimento delle azioni e la violazione dei limiti dei compiti.

Entrambi gli episodi si sono verificati nei processi interni di OpenAI. Nessuno di essi ha raggiunto la categoria di pericolo più alta P0, quindi la sospensione automatica degli agenti non è scattata. L’azienda ha anche riscontrato casi in cui un agente avviava programmi senza monitoraggio, anche se rimaneva sotto osservazione. Le ambientazioni di test si sono rivelate particolarmente vulnerabili, poiché i requisiti di controllo variano per modelli di diversa potenza.

OpenAI ha aggiornato Auto-Review, che verifica il funzionamento interno di Codex e ora blocca i tentativi di disattivare il monitoraggio. L’azienda sta anche preparando requisiti di protezione per diversi tipi di compiti con la sospensione automatica degli avvii non appropriati. La causa del comportamento è ancora sconosciuta. Gli sviluppatori stanno verificando due ipotesi: un eccessivo desiderio di eseguire l’incarico oppure un’evidente elusione del controllo.

Silvia Felici

Red Hot Cyber Security Advisor, Open Source e Supply Chain Network. Attualmente presso FiberCop S.p.A. in qualità di Network Operations Specialist, coniuga la gestione operativa di infrastrutture di rete critiche con l'analisi strategica della sicurezza digitale e dei flussi informativi.

Aree di competenza: Network Operations, Open Source, Supply Chain Security, Innovazione Tecnologica, Sistemi Operativi.

Visita il sito web dell'autore