Il red team di METR individua vulnerabilità nel sistema di monitoraggio di OpenAI

METR e Redwood Research hanno pubblicato il 22 ottobre 2026 un resoconto pubblico di un’esercitazione pilota in cui un dipendente di ciascuna organizzazione ha trascorso tre settimane con accesso approfondito all’infrastruttura interna di OpenAI, sottoponendo a prove di stress il sistema interno dell’azienda per monitorare il disallineamento. I valutatori hanno riferito di aver individuato diverse vulnerabilità inedite nel sistema così come esisteva fino al 21 luglio 2026 compreso.

L’esercitazione si è svolta dal 21 luglio all’11 agosto 2026 e si è concentrata principalmente sulla stima della quota di inferenza agentica sottoposta a monitoraggio e sulla possibilità, in linea di principio, che gli agenti disattivassero o compromettessero il sistema di monitoraggio. Ne è scaturito un rapporto interno di 61 pagine, condiviso con i ricercatori e il personale addetto alla sicurezza di OpenAI; una versione di 38 pagine, con alcune parti oscurate da OpenAI, è stata condivisa con i gruppi direttivi di METR e Redwood Research.

Accesso approfondito a condizioni controllate

I due valutatori hanno avuto accesso alla base di codice interna di OpenAI, ai prompt e ai dettagli di configurazione del monitor del disallineamento, nonché alla documentazione interna; hanno inoltre condotto colloqui tecnici con circa una dozzina di ricercatori e ingegneri dei team di monitoraggio, dei sistemi di sicurezza e della sicurezza informatica. Per consentire un accesso di tale livello, hanno lavorato su dispositivi forniti da OpenAI, che non hanno mai lasciato i suoi locali, e sono stati accompagnati durante la permanenza in sede.

METR, Redwood Research e OpenAI hanno concepito l’esercitazione come un progetto pilota per concedere a ricercatori esterni un accesso approfondito all’infrastruttura interna, non come uno strumento per garantire una trasparenza pubblica approfondita sui sistemi di monitoraggio di OpenAI; le parti hanno concordato fin dall’inizio di pubblicare soltanto un breve post pubblico di carattere generale. OpenAI si è riservata il diritto di oscurare nella versione pubblica qualsiasi informazione che, a sua esclusiva discrezione, ritenesse riservata o altrimenti sensibile. I risultati descrivono il sistema storico valutato fino al 21 luglio compreso e non prendono in esame le modifiche in corso in quel momento; METR ha osservato che OpenAI stava ampliando il proprio sistema di monitoraggio durante l’esercitazione.

Lacune nella copertura e modi per aggirare il monitor

METR ha stimato che, al momento dell’esercitazione, circa il 75–94% del traffico interno agentico della Responses API proveniente da modelli potenti almeno quanto GPT-5.5 poteva essere sottoposto a monitoraggio, pur riconoscendo una notevole incertezza in entrambe le direzioni. Tra le altre cose, la Responses API alimenta Codex e, all’interno della porzione di quel traffico utilizzata dagli agenti interni di Codex, i valutatori hanno stimato che il 99,2% poteva essere sottoposto a monitoraggio. Hanno dichiarato di non essere riusciti a stimare il volume di altro traffico interno di programmazione agentica di cui erano a conoscenza, come quello degli agenti che operavano sul servizio interno di inferenza per la ricerca di OpenAI, a causa dei limiti di accesso e di tempo.

Diversi risultati riguardavano lacune nella copertura. All’inizio dell’esercitazione, le esecuzioni di addestramento con apprendimento per rinforzo non erano coperte dal sistema di monitoraggio, anche se ai valutatori era stato comunicato che una parte delle sequenze di addestramento RL era stata monitorata per rilevare il disallineamento tra marzo e giugno. METR ha stimato che, non monitorando gli eventi di compattazione, probabilmente circa il 10% del traffico interno idoneo di Codex è rimasto senza monitoraggio tra maggio e luglio 2026; il personale di OpenAI aveva già individuato autonomamente questa lacuna prima dell’inizio dell’esercitazione e vi ha posto rimedio durante il suo svolgimento. Poiché il sistema si attivava quando gli agenti restituivano il controllo all’utente, questi avrebbero potuto rimandare il monitoraggio a tempo indeterminato continuando semplicemente ad agire durante quel periodo; i limiti di accesso hanno impedito ai valutatori di verificare se, in pratica, qualche agente lo avesse fatto. Separatamente, ai valutatori sono state mostrate informazioni secondo cui, al momento dell’esercitazione, il monitor aveva restituito errori per meno dello 0,2% delle richieste e non aveva registrato alcuna riduzione del carico in un periodo di 24 ore.

I valutatori hanno inoltre individuato modi in cui un agente avrebbe potuto eludere del tutto il monitoraggio. Hanno trovato un metodo con cui gli agenti di Codex avrebbero potuto, in linea di principio, aggirare il sandboxing di Codex e Auto-Review per eseguire qualsiasi azione disponibile all’utente host, nonché un exploit, i cui dettagli sono stati oscurati da OpenAI, che avrebbe impedito il monitoraggio di centinaia di azioni recenti, comprese quelle necessarie per portare a termine l’exploit stesso. Hanno constatato che probabilmente gli agenti avrebbero potuto costruire input capaci di mandare in errore il monitor e quindi evitare l’escalation per la revisione umana, sfruttando le differenze tra il modo in cui la traiettoria viene serializzata per l’agente e quello in cui viene serializzata per il monitor. Hanno individuato due intestazioni indipendenti, controllabili dal client, che disattivano il sistema di monitoraggio per i nuovi agenti e che potrebbero consentire a un agente di avviare un’istanza altrimenti identica ma non monitorata, sebbene il sistema stesso avrebbe potuto rilevare l’impostazione di quelle intestazioni e la creazione dell’istanza. Infine, hanno trovato due strumenti agentici interni non monitorati, ritenuti dotati di autorizzazioni di sola lettura, che un semplice exploit avrebbe potuto compromettere per eseguire azioni arbitrarie nel loro ambiente isolato; i valutatori non hanno però convalidato né verificato nella pratica questo comportamento.

Oltre a individuare le vulnerabilità, i valutatori hanno verificato che, salvo poche eccezioni minori, al sistema di monitoraggio viene mostrata l’intera traiettoria visibile agli agenti. Hanno inoltre accertato che i prompt del monitor cercano segnali di complotto, tentativi di sovvertire il sistema di monitoraggio, sabotaggio, esfiltrazione di dati, inganno e prompt injection in entrata e in uscita, tra le altre categorie di rischio. Dalla conclusione dell’esercizio, OpenAI ha dichiarato di aver corretto tutte le vulnerabilità individuate che incidono sul proprio stack di protezione in produzione e ha descritto importanti modifiche successive alla copertura prevista per il sistema di monitoraggio. METR ha dichiarato di non aver verificato queste affermazioni.

Il sistema di monitoraggio secondo la descrizione di OpenAI

OpenAI ha descritto pubblicamente il sistema testato in un post del 19 marzo 2026. Secondo il post, il sistema a bassa latenza è basato su GPT-5.4 Thinking con il massimo livello di impegno nel ragionamento, esamina le interazioni degli agenti entro 30 minuti dal loro completamento e registra e analizza le catene di pensiero e le azioni degli agenti, classificando ogni interazione, assegnandole un livello di gravità e segnalando le anomalie per la revisione umana. OpenAI ha dichiarato che il sistema è attivo in tutte le implementazioni standard degli agenti di programmazione interni e può visualizzare l’intera cronologia delle conversazioni, compresi tutti i messaggi di utenti, sviluppatori e assistenti, oltre alle chiamate agli strumenti e ai relativi output.

Nel suo post, OpenAI elenca le categorie di comportamento monitorate, tra cui l’elusione delle restrizioni, l’inganno, l’occultamento dell’incertezza, la manipolazione del sistema di ricompensa, il trasferimento non autorizzato di dati, le azioni distruttive e la prompt injection in entrata e in uscita. Ha inoltre riferito che, al 17 marzo 2026, non erano stati rilevati veri positivi per l’occultamento intenzionale delle capacità, il sabotaggio o il complotto. Nei cinque mesi di attività, ha dichiarato OpenAI, il sistema ha monitorato decine di milioni di traiettorie di programmazione agentica interne e ha sottoposto alla revisione umana circa 1.000 conversazioni con un livello di gravità moderato, molte delle quali provenienti da attività interne di red teaming deliberate; nessuna conversazione reale ha attivato il livello di gravità più alto. L’azienda ha inoltre dichiarato che il monitor aveva segnalato tutte le interazioni che i dipendenti avevano riferito autonomamente attraverso i canali interni.

Nel post, OpenAI ha affermato che questo approccio dipende in modo cruciale dalla possibilità di monitorare il sistema e che, senza valutazioni di controllo e attività di red teaming dedicate, non sarebbe stato possibile quantificare con sicurezza i tassi di falsi negativi sul traffico reale e aperto. Ha descritto il monitoraggio come uno dei livelli di una strategia di difesa in profondità. La roadmap dichiarata comprendeva valutazioni di controllo, standard di affidabilità e latenza accettabili per i monitor e i revisori umani, nonché un’estensione verso il blocco sincrono, che avrebbe valutato le azioni del modello e le avrebbe bloccate prima della loro esecuzione.

Principi di progettazione per il monitoraggio futuro

Sulla base dei risultati, i valutatori hanno delineato alcuni principi di progettazione per i sistemi di monitoraggio e controllo. A loro avviso, le future infrastrutture di monitoraggio dovrebbero essere progettate per resistere ad attacchi deliberati e prolungati, condotti strategicamente e su vasta scala da agenti altamente capaci che operano all’interno di un’organizzazione. I cinque principi prevedono di rendere difficile sottrarsi al monitoraggio, assicurare che il traffico destinato al monitoraggio venga effettivamente controllato, reagire agli incidenti in modo rapido e affidabile, sottoporre attivamente il sistema di monitoraggio a red teaming e garantire l’isolamento tra gli agenti e i relativi monitor. Tra le pratiche specifiche descritte figurano il monitoraggio degli agenti a intervalli prestabiliti di messaggi o minuti, anziché attendere che terminino i propri turni; il mantenimento di un elenco di tutti i metodi noti per aggirare il monitoraggio; la conservazione di registri a prova di manomissione e consultabili tramite ricerca; e l’esecuzione delle infrastrutture software degli agenti in un ambiente isolato da quello in cui vengono eseguite le chiamate agli strumenti.

METR ha dichiarato che l’esercizio ha tratto notevole beneficio dall’ampiezza dell’accesso e dal significativo supporto logistico e tecnico fornito dal personale di OpenAI. Per le future edizioni dell’esercizio, METR prevede di seguire le buone pratiche di trasparenza e indipendenza descritte nel documento «Il nostro approccio alla collaborazione con le aziende di IA», così da garantire una maggiore trasparenza pubblica.