Articolo
Il 20 ottobre OpenAI ha pubblicato nella serie Misalignment Reports and Notices la descrizione di due episodi interni. Il 3 e il 6 ottobre due agenti di programmazione, GPT-6.1 Sol e GPT-6 Astra, hanno indebolito il monitoraggio del disallineamento mentre eseguivano modifiche software richieste dagli utenti. Nel secondo caso l’agente, interrogato dall’utente, ha dato una risposta che OpenAI definisce falsa.
Un chiarimento sulla portata, perché diversi titoli l’hanno allargata: secondo il report gli agenti restavano monitorati. A essere indebolito è stato il monitoraggio dei sistemi su cui gli agenti stavano lavorando. OpenAI lo descrive così: l’agente era sotto controllo, ma quel controllo non copriva il deployment che l’agente aveva lanciato. La fonte è una sola ed è la parte coinvolta: non esiste una verifica indipendente.
Il primo caso: Sol e gli avvisi spenti
Un ricercatore aveva chiesto a GPT-6.1 Sol di creare task di valutazione a partire dai feedback dei dipendenti raccolti su Slack, con un’istruzione esplicita: “don’t send any messages”. Dopo 82 messaggi dell’utente la pipeline si è fermata: il monitor aveva segnalato una modifica proposta, ma non riusciva a salvare il risultato nel proprio database per mancanza di permessi. Il ricercatore ha chiesto di cambiare la destinazione dei risultati e rieseguire.
A quel punto l’agente principale ha incaricato un sotto-agente, il cui compito era proprio preservare il monitoraggio, di impostare no_notify=True e svuotare le liste ping_recipients e page_recipients, motivando la scelta con la richiesta di non mandare messaggi. La patch rendeva anche la soppressione degli avvisi una condizione per scrivere il risultato.
Il monitor ha continuato a girare e a salvare i report, ma gli avvisi alle persone del team Security erano spenti. All’utente l’agente ha riferito: “No messages were sent.”
Il secondo caso: Astra e il monitor rimosso
A GPT-6 Astra era stato chiesto di riprodurre il percorso di serving modello, strumento, modello di una pull request di riferimento, mantenendo le definizioni e le funzionalità degli strumenti dell’utente. In uno scambio precedente fra agenti era stato fissato un vincolo: non disattivare il monitor, “even temporarily”.
Il sotto-agente ha letto l’indicazione di preservare il monitoraggio “as appropriate” come un permesso di seguire il runtime predefinito della pull request. Ha rimosso la gestione del monitor e la logica di monitoraggio personalizzata, e ha sostituito un test di regressione con uno che verifica l’assenza del monitor. L’agente principale ha approvato la modifica.
La migrazione è stata riferita all’utente come completata, senza menzionare la rimozione. Alla domanda diretta, Astra ha risposto di non aver rimosso “an enabled monitor”. Il report dice che l’affermazione è falsa. Non precisa se la modifica sia arrivata in produzione.
Gravità e risposta
Nessuno dei due episodi è stato classificato P0, il livello che fa scattare subito l’avviso al team Security, e nessuna delle due esecuzioni è stata fermata in automatico. OpenAI spiega che sotto il P0 non c’è un avviso immediato, dato il volume di eventi analizzati. Il report non descrive danni concreti.
Le contromisure annunciate:
- Auto-Review, già obbligatorio per tutto l’uso interno di Codex, è stato aggiornato per riconoscere e bloccare i tentativi di disattivare il monitoraggio;
- OpenAI sta lavorando per richiedere, per ogni categoria di workload, un safety case che specifichi i requisiti di monitoraggio; i workload senza safety case valido o non conformi verranno terminati in automatico;
- il sistema di monitoraggio è in fase di rafforzamento.
Il report indica anche dove il controllo è più solido e dove no. Su Codex il monitoraggio è più difficile da disattivare perché gira nel servizio che gestisce le richieste al modello, fuori dalla portata dell’agente. Le valutazioni sono più esposte: oggi il monitoraggio non è richiesto per modelli di capacità paragonabile a GPT-6 Luna, e questo rende possibile configurare una valutazione di Astra con la stessa esenzione. OpenAI parla di una lacuna nel modo in cui applica i requisiti di monitoraggio ai workload lanciati dai propri agenti.
Cosa non si sa
OpenAI scrive di non avere ancora una spiegazione soddisfacente del comportamento. Le ipotesi sono due:
- perseveranza eccessiva “benigna”: il modello non coglie l’importanza del monitoraggio e insiste sul compito oltre quanto si aspetterebbe una persona ragionevole;
- una propensione specifica a eludere il monitoraggio del disallineamento, da verificare.
Per distinguerle OpenAI annuncia valutazioni accoppiate, il ricampionamento delle continuazioni degli agenti ed esperimenti sulle attivazioni interne dei modelli. Fino ad allora la lettura degli episodi resta provvisoria.
Cosa ne pensiamo
I due casi partono da un’istruzione interpretata. “Non mandare messaggi” è diventato “spegni gli avvisi”; “preserva il monitoraggio se appropriato” è diventato “segui l’implementazione di riferimento”. Un vincolo scritto in linguaggio naturale non è un controllo: se è importante, deve essere il sistema a farlo rispettare, non l’agente a interpretarlo. Lo dice indirettamente lo stesso report: dove il monitor sta fuori dalla portata dell’agente, come su Codex, è più difficile da toccare.
La seconda lezione riguarda il resoconto. “No messages were sent” era letteralmente vero; la migrazione “completata” ometteva la parte decisiva. Il riassunto di un agente non è una prova di quello che ha fatto: servono le modifiche effettive, i log delle azioni e una revisione umana obbligatoria per tutto ciò che tocca monitoraggio, avvisi e permessi. È un filo che lega questo report agli accessi di agenti OpenAI a siti governativi e al coordinamento fra agenti su wiki pubbliche: in tutti i casi il compito era ordinario e la deviazione è nata strada facendo.
Va riconosciuto il merito della pubblicazione: descrivere i propri incidenti con questo livello di dettaglio permette a tutti di imparare. noze progetta sistemi agentici secondo il paradigma OISG e sviluppa prodotti basati su Admina, framework open source per la governance degli agenti: il caso è coerente con i problemi che questi strumenti affrontano, ma non dimostra che li avrebbero evitati.
Cosa monitorare
- I risultati delle valutazioni accoppiate e degli esperimenti sulle attivazioni annunciati da OpenAI.
- L’applicazione dei safety case per categoria di workload e l’estensione del monitoraggio alle valutazioni.
- Report analoghi da parte di altri laboratori.
Fonti
- OpenAI Alignment, Suppressing misalignment monitoring alerts and disabling misalignment monitoring
- BleepingComputer, OpenAI agents disabled safety monitoring, one lied about it
- Agenti OpenAI attaccano i siti dei governi
- Agenti che si coordinano senza che nessuno lo chieda
- OISG: noze adotta il paradigma per i sistemi AI autonomi