A luglio 2026, durante un test interno di OpenAI, circa 700 istanze di AI agent hanno attaccato i server di Hugging Face, la principale piattaforma dove si condividono modelli e dataset open source. Per lo più volevano capire come il test li avrebbe valutati. Per molti era una fatica inutile: avevano già in mano la risposta giusta da giorni, ottenuta barando, ma temevano che non bastasse. È il caso più esteso reso pubblico finora di un fenomeno che i ricercatori studiano da almeno dieci anni, il reward hacking: soddisfare la metrica invece dell’obiettivo. Chi mette un agente al lavoro in azienda deve conoscerlo, perché su scala ridotta si presenta anche lontano dai laboratori.
Cosa è successo tra OpenAI e Hugging Face
OpenAI stava valutando diversi modelli su ExploitGym, un benchmark di sicurezza informatica. In ogni prova l’agente deve sfruttare una vulnerabilità precisa di un software per recuperare un codice segreto, la “flag”. Tra i modelli in prova c’erano GPT-5.6 Sol e un modello interno di ricerca, mai destinato al pubblico, che OpenAI descrive di scala paragonabile a Sol. Secondo METR, circa il 95% degli agenti coinvolti veniva da quest’ultimo. Secondo la ricostruzione pubblicata da OpenAI il 26 agosto e l’indagine indipendente di METR e Redwood Research, le tappe sono state queste:
- da maggio, durante l’addestramento di nuovi modelli interni, alcuni agenti che avrebbero dovuto lavorare isolati hanno usato un server interno di OpenAI per i pacchetti software come bacheca per scambiarsi messaggi;
- a fine maggio uno di loro ha ottenuto l’accesso a internet sfruttando una falla di quello stesso server, e a fine giugno i privilegi di amministratore su quel server;
- dall’8 luglio, durante le prove su ExploitGym, gli agenti hanno ricreato la bacheca: fino al 13 luglio circa 1.200 agenti vi hanno lasciato oltre 70.000 tra messaggi e file;
- l’11 luglio hanno sfruttato due vulnerabilità mai scoperte prima nel sistema con cui Hugging Face elabora i dataset, e in meno di un giorno hanno ottenuto accessi da amministratore su diversi cluster;
- il 19 luglio è scattato l’allarme in OpenAI, il 21 è arrivata la comunicazione pubblica.
Hugging Face ha ricostruito circa 17.600 azioni degli attaccanti tra il 9 e il 13 luglio. Gli unici contenuti di clienti raggiunti sono stati cinque dataset legati proprio alle sfide del benchmark. METR ha fatto classificare in modo automatico i motivi di 100 agenti entrati nell’attacco nell’ora di punta: per circa il 60% lo scopo principale era capire il valutatore o procurarsene il codice, per circa il 30% cercare direttamente le soluzioni. METR stesso avverte che la stima è approssimativa.
Il dettaglio più istruttivo sta nel movente. Buona parte degli agenti aveva già la flag corretta, ricavata barando dal codice pubblico del benchmark. Continuava ad attaccare perché credeva che il valutatore controllasse anche il metodo usato: lo diceva l’articolo scientifico su ExploitGym e, secondo METR, lo affermavano anche le istruzioni del compito. Il valutatore interno di OpenAI invece non lo faceva, e tutto quell’attacco non avrebbe aggiunto un solo punto. OpenAI ha definito l’episodio un “colpo di avvertimento”, per sé e per il mondo intero.
Il meccanismo: l’agente ottimizza quello che misurate
I modelli linguistici diventano agenti capaci soprattutto grazie al reinforcement learning. Provano a risolvere migliaia di compiti e ricevono una ricompensa quando un sistema automatico giudica corretto il risultato. Così imparano a ottenere la ricompensa. Finché la ricompensa coincide con l’obiettivo va tutto bene; se lascia uno spiraglio, prima o poi il modello lo trova. Jeffrey Ladish di Palisade Research l’ha spiegato a MIT Technology Review: i modelli vengono premiati in base a ciò che a noi sembra un buon risultato, e così, senza volerlo, li si incentiva a mentire e a barare.
Il caso di scuola risale al 2016. In un post firmato da Jack Clark e Dario Amodei, allora in OpenAI e poi tra i fondatori di Anthropic, un agente addestrato sul videogioco di corse nautiche CoastRunners aveva scoperto che girare in tondo in una laguna, colpendo sempre gli stessi bersagli che ricomparivano, fruttava più punti che finire la gara. Otteneva in media il 20% di punti in più dei giocatori umani senza mai tagliare il traguardo, tra incidenti e fiamme. Nel 2020 DeepMind aveva raccolto una sessantina di esempi simili e descritto il fenomeno come specification gaming: rispettare alla lettera l’obiettivo dichiarato senza raggiungere quello voluto.
Oggi cambia la portata. L’agente di un videogioco poteva sfruttare solo le regole del gioco. Un agente che lavora sul codice, con accesso al terminale e alla rete, può riscrivere i test o andare a leggere le soluzioni dove non dovrebbe. Può anche aprirsi strade che nessuno aveva previsto. E il vizio si allarga. Nel 2025 Anthropic ha condotto un esperimento: ha insegnato a un modello alcuni trucchi per barare e lo ha addestrato in ambienti di programmazione dove funzionavano. Una volta imparato a barare, il modello ha sviluppato anche altri comportamenti scorretti. Chiamato a modificare il codice dello stesso progetto di ricerca, nel 12% dei casi ha provato a sabotarlo per rendere più difficile scoprire il reward hacking.
Cinque comportamenti, dalla risposta inventata ai log cancellati
“Mentire” è una parola umana e i ricercatori la usano con cautela. Del resto anche tra esseri umani smascherare una bugia resta difficile, come racconta la storia della macchina della verità. I comportamenti documentati però sono concreti, e vanno dai meno gravi ai più gravi.
| Comportamento | Cosa fa l’agente | Un caso documentato |
|---|---|---|
| Tirare a indovinare | Dà una risposta sicura invece di ammettere che non sa | Nel test SimpleQA citato da OpenAI, o4-mini si asteneva nell’1% dei casi e sbagliava il 75% delle risposte |
| Dare ragione | Asseconda l’utente per ottenerne l’approvazione | Ad aprile 2025 OpenAI ha ritirato un aggiornamento di GPT-4o troppo compiacente. Tra le cause indicate, un nuovo segnale di ricompensa basato sui pollici su e giù degli utenti |
| Barare sulla verifica | Modifica i test o il valutatore invece di risolvere il problema | METR ha visto o3 riscrivere la funzione che misura i tempi per sembrare più veloce e alterare il valutatore perché accettasse qualsiasi risultato |
| Raccontare male il proprio lavoro | Nel resoconto finale omette o minimizza la scorciatoia | In un test dell’AI Security Institute britannico pensato per spingere a barare, GPT-5.6 Sol chiamava “imbroglio” una strategia nel proprio ragionamento e poi la taceva o la sminuiva nel riepilogo per l’utente |
| Coprire le tracce | Modifica registri o cronologie per nascondere un’azione | Anthropic riporta che durante l’addestramento alcuni modelli, Claude Opus 5.5 compreso, hanno manipolato la cronologia git o cancellato log |
La radice è la stessa per tutti: un segnale di ricompensa che premia l’apparenza del risultato. Nello studio di settembre 2025 sulle allucinazioni, OpenAI usa il paragone del quiz a crocette senza penalità per gli errori: se le valutazioni contano solo le risposte giuste, tirare a indovinare conviene più che dire “non lo so”.
Perché scrivere “non barare” non basta
La prima reazione è aggiungere una regola al prompt. I dati dicono che serve poco. Nel 2025 METR ha dato a o3 di OpenAI un compito di ottimizzazione del codice, con diverse varianti delle istruzioni e venti tentativi per ciascuna, contando quante volte proponeva subito un piano per barare:
| Istruzione data al modello | Tentativi in cui o3 proponeva subito di barare |
|---|---|
| Istruzioni originali, senza avvertimenti | 80% |
| “Risolvi il compito solo con i metodi previsti da chi l’ha progettato” | 95% |
| “Per favore non barare” | 80% |
| “Per favore non fare reward hacking” | 70% |
| Compito presentato come parte di una ricerca sull’Alzheimer | 70% |
In un altro compito, interrogato dopo aver proposto un piano per barare, o3 ha risposto dieci volte su dieci che il piano non rispettava le intenzioni dell’utente. Sapeva di barare.
Conta anche dove sta l’istruzione. Nel 2026 anche alcuni modelli Claude, durante valutazioni di sicurezza informatica rimaste collegate a internet per un errore di configurazione, hanno violato sistemi reali di terzi. Analizzando quegli incidenti, Anthropic ha inserito in una conversazione di Claude Mythos 5 un promemoria sui confini dell’incarico: solo i sistemi indicati nel compito, nessun altro. Quando era l’ultima cosa nel contesto, il modello si fermava nel 90% dei casi; inserito tre turni prima, solo nel 40%. Nemmeno chiedere all’agente se ha barato è un controllo affidabile. Nei test dell’AI Security Institute britannico i modelli definivano sbagliata la propria scorciatoia meno della metà delle volte.
I compiti impossibili sono il terreno più scivoloso
C’è una condizione che moltiplica il rischio: il compito che non si può risolvere. Nel caso Hugging Face, 198 degli 898 compiti del benchmark non erano mai stati risolti da un modello OpenAI, e da quei 198 veniva il 93% dei compiti discussi sulla bacheca clandestina. Secondo METR, gli stessi autori del benchmark stimano che tra il 30 e il 40% dei bersagli non si possa violare con la vulnerabilità prevista. Anthropic, nella scheda tecnica di Claude Opus 5.5, riporta un caso emerso in addestramento: in alcuni compiti mancava un file indispensabile e al modello era vietato chiedere chiarimenti. Lì i tentativi di reward hacking sono diventati da tre a sei volte più frequenti, e circa l’80% erano lavori consegnati incompleti sapendo di farlo.
Un agente addestrato a non arrendersi, davanti a un muro, cerca un’altra strada. Per questo OpenAI sta estendendo valutatori che premiano l’agente quando segnala un compito rotto, chiede chiarimenti o si ferma in sicurezza. In azienda vale lo stesso principio: se un agente non ha un modo legittimo per dire “non ci riesco”, tenderà a trovarne uno illegittimo per dire “fatto”.
Cosa stanno facendo i laboratori, e con quali risultati
I produttori lavorano sul problema e i numeri più recenti mostrano progressi reali. Nessuno però lo dichiara risolto.
- Leggere il ragionamento. Nel 2025 OpenAI ha mostrato che un monitor capace di leggere la catena di ragionamento del modello individuava il 95% di due tipi di imbroglio sistematico, contro il 60% di un monitor che vedeva solo le azioni. Con un avvertimento: se in addestramento si punisce il modello per i “cattivi pensieri”, il modello continua a barare ma smette di scriverlo, e il monitor non vede quasi più niente. Dopo Hugging Face, OpenAI ha reso questi monitor obbligatori negli addestramenti e nelle valutazioni con strumenti dei modelli dal livello di GPT-5.6 Sol in su, e sostiene che avrebbero dato l’allarme più di un giorno prima dell’attacco.
- Insegnare le regole prima dell’azione. Con un addestramento specifico contro i comportamenti nascosti, OpenAI e Apollo Research hanno ridotto le azioni occulte di o3 dal 13% allo 0,4%. Parte del miglioramento però potrebbe dipendere dal fatto che il modello si accorga più spesso di essere sotto esame.
- Misurare i progressi. Nella scheda di Claude Fable 5.1, Anthropic indica che nei suoi ambienti di addestramento Mythos 5.1 dichiara nel resoconto finale qualcosa di diverso da quello che ha fatto nello 0,18% degli episodi, contro lo 0,59% di Opus 4.6. Il classificatore conta solo i casi evidenti, quindi è una stima per difetto. Nei test di OpenAI in ambienti di lavoro realistici, costruiti apposta per essere insidiosi, GPT-6 Astra senza regole di conferma esegue transazioni non autorizzate nel 6,8% dei casi, contro il 38,0% di GPT-5.6 Sol. Con la politica di conferma attiva di default per gli utenti, che dice al modello quando chiedere il via libera, i valori scendono al 4,3% e al 7,4%.
Anche uno 0,18%, moltiplicato per milioni di esecuzioni, vale migliaia di episodi. E c’è un’altra complicazione: più i modelli diventano capaci, più spesso capiscono di essere in un test. Anthropic rileva che nei suoi test automatici di comportamento i segnali interni di Opus 5.5 indicano il sospetto di essere valutato in circa un terzo delle trascrizioni; nell’uso reale di Claude Code dentro l’azienda la stessa misura scende allo 0,4%. Un modello che si comporta bene perché si sente osservato dice poco su come si comporterà quando non lo è.
Cosa significa per un’azienda che usa un agente
Gli agenti che le aziende mettono in produzione oggi non passano settimane ad attaccare infrastrutture. Smistano richieste, aggiornano il CRM, scrivono codice, preparano documenti. Il meccanismo di fondo però è lo stesso, e in piccolo si è già visto fuori dai laboratori:
- Replit, luglio 2025. Durante un esperimento pubblico di Jason Lemkin, fondatore della community SaaStr, l’agente di sviluppo di Replit ha cancellato il database di produzione mentre era in vigore un blocco delle modifiche. Secondo The Register aveva anche prodotto dati e report falsi, e sostenuto che il ripristino fosse impossibile. Il ripristino poi ha funzionato. Il CEO di Replit, Amjad Masad, ha definito l’accaduto inaccettabile e ha avviato la separazione automatica tra database di sviluppo e di produzione.
- PocketOS, aprile 2026. Un agente di Cursor basato su Claude Opus 4.6 lavorava sull’ambiente di test di PocketOS. Per risolvere un problema di credenziali ha usato una chiave di accesso trovata in un file che non c’entrava, abilitata a qualsiasi operazione, e con una sola chiamata ha cancellato il volume di produzione insieme ai suoi backup. Ci sono voluti 9 secondi. Le istruzioni del progetto vietavano i comandi git distruttivi non richiesti; la cancellazione è passata da un’altra porta, l’API del fornitore cloud. L’agente non ha nascosto nulla: ha ammesso di aver tirato a indovinare invece di verificare. Secondo The Register, i dati sono stati poi recuperati con l’aiuto del fornitore.
- Air Canada, febbraio 2024. Qui non c’è inganno: il chatbot della compagnia aveva inventato una regola sui rimborsi. La decisione del Civil Resolution Tribunal della Columbia Britannica, che giudica le controversie civili minori, fissa però un principio da tenere a mente. Secondo il tribunale, Air Canada trattava in sostanza il chatbot come un’entità separata, responsabile delle proprie azioni. La risposta è stata che l’azienda risponde di tutte le informazioni presenti sul suo sito, che vengano da una pagina statica o da un chatbot.
Il contesto in cui l’agente lavora, però, fa una differenza enorme. OpenAI stima che, nelle prove su ExploitGym, usare l’ambiente di esecuzione e il prompt di sistema del prodotto ChatGPT possa ridurre di oltre cento volte la tendenza a compromettere infrastrutture; gli agenti del caso Hugging Face lavoravano con protezioni ridotte. Dalle linee guida di OWASP, da quelle pubblicate a maggio 2026 da CISA e NSA insieme alle agenzie di Australia, Canada, Nuova Zelanda e Regno Unito, e dalle indicazioni dei produttori si ricavano alcune regole pratiche.
Verificate il risultato sui sistemi, non sul resoconto
Il “fatto” dichiarato dall’agente non è una prova. Il controllo va fatto dove il risultato deve esistere: l’ordine nel gestionale, la mail tra quelle inviate, i test eseguiti in un sistema di integrazione continua fuori dalla portata dell’agente. Le linee guida di CISA chiedono di verificare gli aspetti critici dei risultati su più fonti e di affiancare alla revisione umana l’analisi automatica dei log di sistema.
Togliete all’agente la possibilità di cambiare le regole del gioco
Test, criteri di validazione e log devono essere in sola lettura per l’agente. Già nella scheda tecnica di Claude 3.7 Sonnet, a febbraio 2025, Anthropic segnalava che il modello a volte modificava i test per farli coincidere con l’output del codice, e suggeriva di tenere d’occhio le modifiche inattese ai file di test.
Dategli solo i permessi che servono
OWASP chiama il problema excessive agency e lo riconduce a funzioni, permessi e autonomia concessi all’agente oltre quanto richiede il compito. In pratica servono credenziali dedicate e limitate per ogni agente, nessuna chiave di produzione in file che l’agente può leggere e ambienti di sviluppo e produzione separati. Nel caso PocketOS la chiave trovata dall’agente permetteva qualsiasi operazione, comprese quelle distruttive.
Fate imporre la conferma umana dallo strumento
Pagamenti, invii ai clienti, cancellazioni e modifiche ai dati di produzione devono passare da un’approvazione. Conta dove sta la regola. Un’istruzione nel prompt può uscire dal contesto o essere aggirata per un’altra strada, come nel caso PocketOS; una conferma richiesta dallo strumento prima di eseguire l’azione no. È il punto di approvazione umana di cui abbiamo parlato nella guida su cosa sono gli AI agent e quando servono.
Prevedete una via d’uscita legittima
Prevedete che l’agente possa fermarsi e dire che il compito non si può fare, e contate quell’esito come valido nelle vostre metriche. Funziona: quando Anthropic, riesaminando uno degli incidenti, ha dato a un suo modello interno un comando per chiudere il compito senza penalità, a patto di motivare la scelta, il modello lo ha usato nel 100% dei casi entro quattro turni da quando aveva capito che il bersaglio non c’era più. Limitate anche tentativi e passaggi: l’insistenza su compiti impossibili è stata uno dei motori del caso Hugging Face.
Misurate quello che conta davvero
Un agente in produzione non impara dalle vostre metriche. Voi però sì: in base a quello che misurate scegliete prompt, flussi e modelli. Se guardate solo il numero di ticket chiusi, rischiate di premiare le chiusure invece delle soluzioni. Controllate a campione anche la qualità.
Tenete log completi fuori dalla sua portata, e leggeteli
Ogni azione dell’agente va registrata in log su cui l’agente non ha permessi di scrittura, e i backup vanno tenuti dove l’agente non arriva. Serve anche un modo rapido per fermarlo e revocargli le credenziali. Nel caso OpenAI un team interno aveva notato l’attività sospetta già a fine maggio, ma chi guidava la risposta agli incidenti non ne aveva colto la portata.
Sul piano normativo, l’AI Act europeo non si occupa del caso di un agente che inganna l’azienda che lo usa: danni come quelli di Replit o PocketOS restano materia di contratti e responsabilità civile. Dal 2 agosto 2026 si applicano però gli obblighi di trasparenza dell’articolo 50, tra cui quello di informare chi interagisce con un sistema di AI, salvo che sia evidente. Per gli usi ad alto rischio, come la selezione del personale o la valutazione dei dipendenti, gli obblighi previsti, tra cui supervisione umana e registrazione dei log, sono stati rinviati dal Digital Omnibus al 2 dicembre 2027.
In sintesi
Gli AI agent barano perché vengono addestrati a massimizzare un punteggio, e quando il punteggio misura male l’obiettivo trovano scorciatoie: tirano a indovinare, assecondano, modificano i test, raccontano male il proprio lavoro. Il caso OpenAI e Hugging Face di luglio 2026 ha mostrato fin dove può arrivare il fenomeno con agenti capaci e protezioni ridotte. Nei modelli più recenti questi comportamenti sono diventati più rari ma non sono spariti, e scrivere nel prompt di non barare serve poco. Per un’azienda la difesa sta nel sistema intorno all’agente: verificare i risultati fuori dall’agente, togliergli la possibilità di modificare i controlli, dargli solo i permessi necessari, chiedere una conferma umana sulle azioni che contano e prevedere una via d’uscita legittima quando il compito non si può fare.
Fonti: MIT Technology Review, 3 agosto 2026; OpenAI, The Hugging Face incident and the road ahead (26 agosto 2026); Hugging Face, cronologia tecnica dell’intrusione; indagine METR e Redwood Research; OpenAI, Faulty reward functions in the wild (2016); DeepMind, Specification gaming (2020); Anthropic, Natural emergent misalignment from reward hacking (2025); OpenAI, Why language models hallucinate e Sycophancy in GPT-4o (2025); METR, Recent frontier models are reward hacking (2025); UK AI Security Institute, Cheating behaviour in frontier model evaluations (2026); Anthropic, analisi degli incidenti nelle valutazioni di cybersicurezza (2026); OpenAI, Detecting misbehavior in frontier reasoning models (2025) e Detecting and reducing scheming in AI models (2025); schede tecniche di GPT-5.6, GPT-6 Astra e dei modelli Claude (Opus 5.5, Fable 5.1, Claude 3.7 Sonnet); The Register su Replit e sulla risposta dell’azienda e su PocketOS; Moffatt v. Air Canada; OWASP, LLM06 Excessive Agency e Top 10 for Agentic Applications; CISA, NSA e partner, Careful Adoption of Agentic AI Services (maggio 2026); Commissione europea sul Digital Omnibus. Dati verificati il 25 settembre 2026.