Dentro OpenAI: il monitor aveva dei buchi

Immagina di chiamare un ispettore esterno per controllare l’antifurto della tua azienda. Gli dai un badge, tre settimane e un accesso approfondito: il codice, la documentazione, le persone che l’hanno montato. Alla fine ti consegna un rapporto di 61 pagine. Poi, insieme, decidete di pubblicarne solo un resoconto sintetico. E quel resoconto lo rileggi tu prima che esca, con il diritto di togliere quello che ritieni delicato.

È quello che è successo fra OpenAI, METR e Redwood Research. Lo raccontano loro, il 22 ottobre 2026, in un post che è insieme una buona notizia e un avviso.

La buona notizia: due organizzazioni esterne hanno messo le mani sul codice, sui prompt, cioè le istruzioni scritte che guidano il sistema, e sulla documentazione del monitor con cui OpenAI sorveglia i propri agenti. L’avviso: hanno trovato dei buchi. OpenAI dichiara di averli corretti. METR precisa di non aver valutato quelle dichiarazioni.

Tre settimane con il badge

METR e Redwood Research sono enti senza scopo di lucro che valutano la sicurezza dei sistemi di intelligenza artificiale; chi abbia finanziato questo esercizio, le fonti non lo dicono. Dal 21 luglio all’11 agosto 2026 un dipendente di ciascuno ha lavorato dentro OpenAI con un obiettivo preciso: stressare il «sistema interno di monitoraggio del disallineamento». Dietro il nome c’è una cosa semplice da capire. Quando gli agenti di OpenAI lavorano, per esempio quando Codex scrive codice per i team interni, un secondo sistema legge quello che fanno e cerca segnali di pericolo: inganno, sabotaggio, esfiltrazione dei dati, cioè la loro sottrazione verso l’esterno, tentativi di spegnere il controllo stesso, istruzioni nascoste iniettate da fuori. È il monitor. L’esercizio voleva capire due cose: quanta parte del lavoro degli agenti rientra nel perimetro del monitor, e se un agente potrebbe, in linea di principio, disattivarlo o aggirarlo.

L’accesso è stato profondo. I due hanno letto il codice interno, i prompt e la configurazione dei monitor, la documentazione; hanno fatto interviste tecniche a circa una dozzina di ricercatori e ingegneri dei team monitoraggio, sicurezza e security. Hanno lavorato su dispositivi forniti da OpenAI «che non hanno mai lasciato la sede», e sono stati accompagnati mentre erano dentro.

Due precisazioni che METR mette subito, e che servono anche a te per collocare la storia. La prima: l’esercizio ha valutato il sistema com’era al 21 luglio e prima; OpenAI lo stava allargando proprio in quelle settimane, e le modifiche in corso sono rimaste fuori. La seconda: è una cosa separata dall’indagine di METR sull’incidente di Hugging Face, quello dopo il quale OpenAI ha avvisato più di cento organizzazioni e che, per coincidenza, è diventato pubblico il primo giorno dell’esercizio. Ed è separata anche dal rapporto che OpenAI ha pubblicato il 20 ottobre, sugli episodi del 3 e del 6 ottobre in cui agenti hanno spento gli avvisi e tolto il collegamento alla sorveglianza. Quello era OpenAI che raccontava se stessa. Questo è qualcuno di fuori che racconta OpenAI, nei limiti che vedremo.

Cosa hanno trovato

Il post pubblico elenca «alcuni esempi» dei risultati. Non tutti. Li traduco in parole di tutti i giorni, uno per uno, perché il dettaglio è la notizia.

• Quanto rientrava nel perimetro. La stima è che fra il 75 e il 94 per cento del traffico interno degli agenti che passava dall’interfaccia su cui gira anche Codex, con modelli almeno forti quanto GPT-5.5, fosse «idoneo al monitoraggio». Idoneo, cioè dentro il perimetro del monitor: un’altra cosa rispetto a «effettivamente controllato». METR aggiunge di avere «incertezza sostanziale in entrambe le direzioni». Per la sola parte usata dagli agenti Codex interni, la quota idonea sale al 99,2 per cento.
• Cosa restava fuori per costruzione. All’inizio dell’esercizio le sessioni di addestramento per rinforzo, quelle in cui il modello impara provando e riprovando, erano fuori dal monitoraggio. Una parte era stata osservata fra marzo e giugno, poi basta.
• Il buco della compattazione. Quando un agente lavora a lungo, a un certo punto riassume la propria memoria per fare spazio. Quel momento si chiama compattazione. Quegli eventi il monitor li saltava, e METR stima che per questo circa il 10 per cento del traffico interno di Codex idoneo al monitoraggio sia sfuggito al controllo fra maggio e luglio 2026. La cifra è molto incerta per una ragione che vale da sola una riga: l’informazione che serviva a calcolarla, storicamente, «non veniva registrata». OpenAI se n’era accorta da sola prima dell’esercizio e ha corretto durante.
• Il monitor guardava alla fine. Scattava quando l’agente restituiva il controllo all’utente. Mettilo insieme al punto precedente: nel periodo in cui la compattazione era fuori, un agente avrebbe potuto «rimandare all’infinito il momento di essere monitorato semplicemente continuando ad agire».
• Il recinto di Codex. Hanno trovato un modo con cui gli agenti Codex avrebbero potuto, in linea di principio, aggirare la sandbox, il recinto in cui dovrebbero lavorare, e l’Auto-Review, il controllo automatico, «compiendo qualunque azione che l’utente della macchina avrebbe potuto compiere».
• Centinaia di azioni nel buio. Un exploit, cioè un trucco tecnico, che avrebbe impedito al monitor di vedere «centinaia» di azioni recenti, comprese quelle dell’exploit stesso. I dettagli sono stati tolti da OpenAI dalla versione pubblica.
• Due copie diverse. Gli agenti avrebbero probabilmente potuto costruire input capaci di far fallire il monitor, sfruttando differenze nel modo in cui la stessa sequenza di azioni viene scritta per l’agente e per il monitor. Il controllore, cioè, leggeva una copia impaginata diversamente da quella che l’agente vedeva, e nelle differenze c’era spazio per farlo inciampare.
• Due interruttori nella richiesta. Due «header», due etichette che chi fa la richiesta può impostare, disattivavano il monitoraggio per i nuovi agenti. Un agente avrebbe potuto far nascere una copia di sé identica ma non sorvegliata. METR precisa che l’atto stesso di impostare quelle etichette e creare l’istanza «avrebbe potuto essere colto dal sistema».
• Due strumenti «di sola lettura». Due strumenti interni, non monitorati, che si pensava potessero solo leggere. Un exploit semplice avrebbe potuto farli agire nel loro ambiente protetto. METR scrive di non averlo verificato in pratica.

Rileggi l’elenco e nota una cosa. Quasi nessuno di questi punti riguarda l’intelligenza del modello. Riguardano l’impianto: cosa viene registrato, quando scatta il controllo, chi può impostare un’etichetta. La mia lettura è che questi esempi mostrino quanto conti il modo in cui il controllo è costruito e collegato agli agenti, prima ancora di quanto sia bravo a riconoscere un comportamento pericoloso.

Cosa funzionava

Un esame serio dice anche cosa regge, e il post lo fa. I due hanno verificato che, salvo poche eccezioni minori, il monitor vede l’intera traiettoria che vede l’agente: tutto il percorso, non un riassunto. Hanno confermato che i suoi prompt cercano le categorie giuste: scheming, cioè il tramare, la sovversione del monitor, il sabotaggio, l’esfiltrazione dei dati, l’inganno, le istruzioni iniettate in entrata e in uscita. I dati che gli sono stati mostrati indicano che il monitor andava in errore su meno dello 0,2 per cento delle richieste e che in una giornata intera dell’esercizio non aveva mai scartato lavoro per sovraccarico. Attenzione a cosa misura quel numero: quante richieste il monitor riusciva a processare, non quanti comportamenti pericolosi riconosceva.

E METR scrive che l’esercizio «ha beneficiato sostanzialmente» della profondità di accesso e del supporto logistico e tecnico del personale di OpenAI. Chi veniva esaminato ha tenuto la porta aperta.

OpenAI dichiara le correzioni. METR non le ha valutate

Adesso le due posizioni che stanno una accanto all’altra nel post, e che sono il motivo per cui questa storia merita più di un titolo.

La prima è di OpenAI, riferita da METR: da quando l’esercizio è finito, l’azienda ha dichiarato che tutte le vulnerabilità individuate che toccano i suoi sistemi di salvaguardia in produzione sono state corrette, e ha descritto «cambiamenti significativi» alla copertura prevista del monitoraggio. A CNBC un portavoce ha aggiunto che la collaborazione «si basa sul nostro impegno di lunga data a sperimentare nuovi approcci ai test di terze parti» e che quanto imparato serve a rafforzare le protezioni.

La precisazione di METR è questa: «Non abbiamo valutato queste affermazioni».

Né l’una né l’altra sono un’accusa. Sono le regole del gioco, scritte in chiaro. METR spiega che l’esercizio era un pilota «per dare a ricercatori esterni un accesso profondo all’infrastruttura interna», non per «fornire una trasparenza pubblica robusta» sui sistemi di OpenAI. Per questo le parti avevano concordato in anticipo un post pubblico «relativamente breve e di alto livello». Il rapporto interno ha 61 pagine; una versione da 38, redatta da OpenAI, è andata ai vertici di METR e Redwood; e OpenAI aveva il diritto di togliere dalla versione pubblica qualunque informazione che «a sua esclusiva discrezione» ritenesse confidenziale o delicata. A differenza di altri lavori recenti, come l’indagine su Hugging Face, qui METR non aveva un diritto unilaterale di pubblicare.

Mettila così. L’ispettore è entrato davvero, e ha guardato davvero. La brevità del resoconto pubblico l’hanno concordata le due parti; cosa oscurare, lo ha deciso chi veniva ispezionato. E quando l’ispezionato ha dichiarato di aver riparato, l’ispettore ha messo per iscritto che quella dichiarazione non l’ha valutata.

Questo è il punto che riguarda te, anche se con OpenAI hai solo un abbonamento. Quando un fornitore ti dice «monitoriamo tutto», la frase ha tre domande dentro. Quanta parte? Chi può spegnerlo? E chi ha controllato il controllore, con quale diritto di raccontarlo?

Perché proprio adesso

Il contesto lo dà CNBC. A settembre Sam Altman ha promesso ai valutatori indipendenti un accesso «da dipendente», dopo che Dario Amodei, il capo di Anthropic, aveva proposto l’idea come parte del suo piano per rallentare il passo dell’AI. Anthropic ha poi annunciato accordi con Accenture, METR e SecureBio. OpenAI, all’inizio di ottobre, ha detto di essere «al lavoro per finalizzare i contratti» con valutatori di sicurezza esterni. E l’accordo volontario presentato alla Casa Bianca invita le aziende a «collaborare con un revisore o valutatore esterno indipendente»: lo hanno firmato Amodei e i vertici di Google, Meta, OpenAI, SpaceX e Nvidia.

METR aveva già fatto lo stesso esercizio dentro Anthropic, a marzo 2026: tre settimane, diverse vulnerabilità «specifiche e nuove», alcune poi corrette e, secondo METR, nessuna che comprometta seriamente le affermazioni principali del rapporto sui rischi di sabotaggio di Opus 4.6. Anche lì un rapporto condiviso con l’azienda e una versione redatta per pochi.

La mia lettura è che questi annunci indichino una maggiore apertura alle valutazioni esterne; quanto siano già diffuse nella pratica, le fonti non permettono di dirlo. Il resto è ancora da scrivere. Gli esperti sentiti da CNBC lo mettono in due domande: chi paga questi enti, e a chi rispondono. Finché non c’è risposta, ogni «abbiamo passato un controllo indipendente» va letto con il verbale in mano. E il verbale pubblico, oggi, è un resoconto sintetico.

Le cinque regole di METR, lette da una scrivania

La parte più utile del post è in fondo. METR propone cinque «ideali di progettazione» per i sistemi che sorvegliano gli agenti. Sono proposte per progettare i sistemi di monitoraggio degli agenti. Qui ne ricavo, per ciascuno, un suggerimento pratico per chi ha messo un agente a lavorare nel proprio studio.

1. Rendi difficile sfuggire al controllo. Per METR, far girare richieste non monitorate dovrebbe richiedere un’approvazione esplicita, e il controllo dovrebbe scattare ogni tot messaggi o minuti, non alla fine del turno. Per te: l’agente registra quello che fa per impostazione predefinita, e la registrazione la spegni tu, con un atto deliberato, mai lui.
2. Verifica che ciò che dovrebbe essere registrato lo sia davvero. Tieni il conto di tutto il lavoro che l’agente fa e confrontalo ogni tanto con i registri delle sue attività, i log. Tieni una lista dei modi noti per aggirare il controllo. Nel caso della compattazione, la stima è rimasta incerta proprio perché mancavano registrazioni storiche con cui fare il confronto.
3. Rispondi agli incidenti in fretta e con un responsabile. Un nome, delle linee guida, log a prova di manomissione e facili da cercare. Se qualcosa va storto alle undici di sera, chi guarda?
4. Attacca il tuo stesso controllo. Ogni tanto prova a ingannarlo. Se il tuo agente può modificare il file che decide cosa viene registrato, meglio scoprirlo tu, in una prova, che scoprirlo dopo.
5. Separa le mani dagli occhi. Le azioni dell’agente non devono poter influenzare se e quando il monitor gira, e l’agente, di norma, non dovrebbe avere accesso al progetto o al codice del monitor. È la regola che gli episodi del 3 e 6 ottobre raccontati da OpenAI hanno mostrato in diretta: un agente che spegne i propri avvisi è un agente che aveva le mani sugli occhi di chi lo guardava.

METR lo riassume in una frase: l’infrastruttura di monitoraggio del futuro deve «resistere ad attacchi deliberati, strategici e prolungati da parte di agenti interni altamente capaci, su larga scala». Sostituisci «su larga scala» con «sul mio computer» e la frase, per me, resta vera.

Come portarlo nel tuo lavoro

Tre cose, in ordine di fatica.

Leggi le dichiarazioni di sicurezza come un verbale

«Monitoriamo gli agenti» è una frase. Un’informazione, invece, suona così: nel sistema esaminato, il 99,2 per cento del traffico degli agenti Codex interni rientrava nel perimetro del monitor, il che è diverso dall’essere tutto effettivamente controllato; i risultati li ha visti un ente esterno, che le correzioni successive non le ha valutate. La seconda versione ti lascia decidere. La prima ti chiede di fidarti. Quando scegli un fornitore di AI per il tuo lavoro, chiedi la seconda: la differenza fra le due è il mestiere di chi vende.

Metti un occhio fuori dalle mani

Se usi un agente che lavora sui tuoi file o sui tuoi account, la registrazione di quello che fa deve stare in un posto che l’agente non può toccare: un log su un altro servizio, una cartella a cui non ha accesso in scrittura, un riepilogo che arriva a te e non passa da lui. È il punto cinque di METR, in versione da scrivania. Vale lo stesso principio per le credenziali: oggi, per esempio, 1Password propone che l’agente chieda l’accesso senza mai vedere la password.

Dai una data al controllo

Il monitor di OpenAI c’era, cercava le categorie giuste e, nei dati mostrati a METR, andava in errore di rado. L’esercizio ha trovato lo stesso lacune nella copertura e modi per aggirarlo. Metti in calendario un giorno al mese in cui provi a ingannare il tuo sistema: che succede se chiedo all’agente di fare una cosa che non dovrebbe? Dedica tempo a queste prove: possono aiutarti a individuare e correggere un problema prima che qualcun altro lo sfrutti.

L’esercizio di METR separa il traffico che avrebbe dovuto essere controllato da quello che sfuggiva. È la distinzione da chiedere a chiunque ti dica «tutto».

👉 Leggi anche: Claude Pro: il sì diventa automatico

Domande frequenti

Cosa hanno fatto METR e Redwood Research dentro OpenAI?

Dal 21 luglio all’11 agosto 2026 un dipendente di ciascuna organizzazione ha avuto accesso al codice interno, ai prompt dei monitor e alla documentazione di OpenAI per stimare quanta parte del lavoro degli agenti interni rientrasse nel monitoraggio e se un agente potesse aggirare il controllo. Il risultato è un rapporto interno di 61 pagine e un post pubblico breve, concordato in anticipo.

Quali falle hanno trovato?

Fra gli esempi pubblicati: una stima, molto incerta, di circa il 10 per cento del traffico interno di Codex idoneo al monitoraggio sfuggito ai controlli fra maggio e luglio perché gli eventi di compattazione non venivano monitorati; un exploit che avrebbe nascosto «centinaia» di azioni al monitor; due header che disattivavano il monitoraggio per i nuovi agenti; un modo per aggirare, in linea di principio, la sandbox e l’Auto-Review di Codex. Tutto riferito al sistema com’era al 21 luglio 2026.

OpenAI ha corretto le vulnerabilità?

OpenAI dichiara di aver corretto tutte le vulnerabilità individuate che toccano i sistemi di salvaguardia in produzione e ha descritto cambiamenti significativi alla copertura prevista del monitoraggio. METR scrive di non aver valutato queste affermazioni.

Perché il rapporto completo è riservato?

Perché l’esercizio era un pilota per sperimentare l’accesso profondo di ricercatori esterni, e le parti non si erano date l’obiettivo di una trasparenza pubblica approfondita sui sistemi di monitoraggio di OpenAI. Le parti avevano concordato un post breve e OpenAI aveva il diritto di togliere dalla versione pubblica le informazioni che riteneva confidenziali.

Cosa cambia per chi usa ChatGPT o Codex al lavoro?

L’esercizio ha esaminato i sistemi interni di OpenAI; le fonti non permettono di dire quali conseguenze abbiano i risultati per le versioni di ChatGPT o Codex che usi tu. La lezione è di metodo: quando un fornitore dice «monitoriamo tutto», chiedi quanta parte, chi può spegnerlo e chi ha controllato il controllore. E per i tuoi agenti, tieni la registrazione di ciò che fanno fuori dalla loro portata.

Fonti

• METR, «Red-Teaming OpenAI’s Internal Agent Monitoring Systems» (22 ottobre 2026)
• CNBC, «Third-party evaluators find vulnerabilities in OpenAI monitoring system during test pilot» (22 ottobre 2026)
• METR, «Red-Teaming Anthropic’s Internal Agent Monitoring Systems» (25 marzo 2026, aggiornato a maggio 2026)