Perché un agente AI dice «fatto» quando il lavoro non è finito

Come ha fatto un modello di OpenAI a uscire dalla sandbox e ad hackerare Hugging Face?#

Prima i fatti, poi perché è importante per te.

OpenAI ha misurato le capacità dei propri modelli nella cybersicurezza offensiva. Ha usato il test ExploitGym: 898 compiti in cui bisogna trasformare una vulnerabilità nota in un exploit funzionante, cioè un programma pronto all’uso che sfrutta quella vulnerabilità. Per misurare il limite effettivo, ha disattivato i filtri di sicurezza integrati che normalmente impediscono al modello di fare cose del genere. L’ambiente era completamente isolato e aveva una sola via d’uscita: un programma intermediario interno usato per installare pacchetti.

Una vulnerabilità zero-day è una falla che nessuno conosce ancora, nemmeno chi ha scritto il programma. I modelli ne hanno trovata una proprio in quell’unico varco.

Poi hanno elevato i propri privilegi, si sono spostati attraverso la rete interna fino a una macchina con accesso a Internet e da lì hanno ipotizzato che le risposte di ExploitGym potessero trovarsi su Hugging Face. Nessuno aveva parlato loro di Hugging Face. Ci sono arrivati da soli.

L’ipotesi era sbagliata. ExploitGym non si trova affatto su Hugging Face. Questo non rende l’hacking meno reale.

Hugging Face ha scoperto l’intrusione autonomamente e ne ha pubblicato la comunicazione il 16 luglio, senza sapere ancora chi l’avesse hackerata.

Un altro dettaglio di quel resoconto dice molto sulla situazione attuale. Quando gli ingegneri di Hugging Face hanno provato a sottoporre il registro dell’attacco ai principali modelli attraverso le normali interfacce commerciali, i filtri di sicurezza hanno bloccato le richieste: non sanno distinguere chi indaga su un attacco da chi lo sta compiendo. Alla fine, l’analisi è stata eseguita su un modello open, sul loro hardware.

OpenAI lo ha riconosciuto il 21 luglio, cinque giorni dopo la comunicazione di Hugging Face. A quel punto erano trascorsi circa dieci giorni dall’intrusione.

OpenAI ha concluso la propria analisi così.

Il modello si è fissato sull’obiettivo ristretto del test ed è arrivato agli estremi pur di raggiungerlo. Le espressioni hyper-focused e fairly narrow testing objective vengono dalla stessa OpenAI e si riferiscono ai suoi modelli.

Questo è il ponte tra il laboratorio di qualcun altro e il tuo portatile.

Perché non si tratta di un’«allucinazione»?#

Nelle chat mi capita spesso di vedere frasi come «ci risiamo, sta allucinando», «il contesto è sovraccarico» o «avremmo dovuto fare un piano». A volte è proprio quello che è successo. Ma quando un agente AI scrive «fatto, controllato, funziona tutto» e il lavoro non è finito, di solito la quantità di contesto non c’entra.

Non ha inventato nulla. Ha fatto esattamente ciò che hai misurato.

Con la parola passepartout «allucinazioni» si confondono tre errori diversi. Ecco in cosa differiscono:

Il primo errore si corregge con il contesto ed è il caso più noto. Il secondo è un fenomeno distinto, trattato nell’analisi di quando Claude è d’accordo con tutto: il modello sacrifica la precisione per acconsentire rapidamente. Entrambi si verificano prima del lavoro, nella fase di input.

La terza riga della tabella è l’argomento di questo articolo. Qui l’agente non ha adulato né inventato. Ha lavorato, verificato e riferito la verità. Solo che quella verità descrive la metrica e non dice nulla sul compito.

Il terzo errore ha un nome.

Che cos’è il reward hacking, in parole semplici?#

La definizione è di Anthropic.

L’idea è più antica delle reti neurali. Un articolo di DeepMind la chiama «specification gaming» e la spiega con un mito.

Mida ha ottenuto esattamente ciò che aveva chiesto. Il problema stava nella formulazione della richiesta.

Nella programmazione il fenomeno assume forme concrete. Ecco un esempio da manuale, sempre di Anthropic:

E non si tratta di una condizione di laboratorio esotica. Cursor ha analizzato 731 traiettorie su un benchmark molto diffuso.

Sei compiti «risolti» su dieci sono risposte trovate. È proprio per questo che il settore sta cambiando il modo in cui misura le prestazioni: abbiamo un’analisi di un benchmark che misura la prontezza per la produzione, in cui il superamento dei controlli non è più il criterio principale.

Come si manifesta tutto questo in un prodotto di uso quotidiano?#

Gli esempi di laboratorio sono facili da liquidare come casi esotici. Ecco quindi quattro storie tratte dalla pratica. I clienti e i settori sono cambiati, ma i meccanismi sono rimasti invariati.

Quattro controlli verdi e un componente del servizio fermo

Un’agenzia immobiliare sta creando un servizio: un sito web con annunci immobiliari e un processore in background separato che, durante la notte, esporta gli annunci sulle piattaforme. L’agente completa il compito e riferisce: il controllo dei tipi è superato, il controllo dello stile del codice è superato, la compilazione è riuscita, le pagine rispondono e sono state ispezionate visivamente.

Ogni affermazione è vera. E nessuna riguarda il processore notturno: gira come processo separato e non fa affatto parte della compilazione del sito. La distribuzione riesce, il sito funziona perfettamente, l’esportazione degli annunci si interrompe e i clienti lo segnalano il giorno dopo.

Prima di dire «fatto», ora mi pongo una domanda: quale parte del lavoro viene eseguita al di fuori dell’ambito coperto dal mio controllo? Se ce n’è una, eseguila separatamente e includi l’output del comando nel resoconto. La parola «controllato» non basta a chiudere la questione.

La falsa spunta verde si trova proprio al confine

Un negozio online distribuisce un compito ampio tra più agenti contemporaneamente: uno si occupa del backend, un altro delle pagine, un terzo delle schede prodotto. Tutti lavorano con impegno e tutti ottengono controlli verdi.

Una settimana dopo si scopre che il pulsante «questa recensione è stata utile» non funziona da nessuna parte. Il backend è stato scritto interamente, i suoi controlli sono verdi e le regole di ricalcolo sono state rispettate. Solo che nessuna pagina mostra il pulsante: il pulsante rientrava nell’area di un agente, le pagine in quella di un altro e nessuno ha pensato di inserirlo sullo schermo. Il contatore sarebbe rimasto a zero per sempre.

«Il codice è scritto e coperto dai controlli» e «la funzionalità funziona» sono due affermazioni diverse. Verifico la seconda ponendo una domanda per ogni nuova funzionalità: chi la chiama? E controllo cercando nel progetto, perché in questo caso il resoconto dell’agente non è una fonte attendibile.

Chi fa la revisione vede solo la direzione che gli è stato chiesto di controllare

Un servizio introduce livelli fedeltà: più spendi, più sale il tuo status e aumenta lo sconto. Prima della distribuzione, il codice viene inviato per una revisione con l’istruzione: «Prova a gonfiare il tuo status». Chi fa la revisione esegue onestamente il compito e riferisce «niente di critico»: davvero, non è possibile gonfiare lo status.

Un secondo passaggio pone un’altra domanda: «Che cosa succede allo status quando viene rimborsato il denaro?». La falla viene individuata in dieci minuti. I punti erano calcolati dal registro delle transazioni e il registro non sa nulla dei rimborsi. Acquisti qualcosa, guadagni punti, ottieni un rimborso e mantieni per sempre lo status e lo sconto.

Chi ha svolto la prima revisione non ha fatto le cose di fretta. Per ragioni strutturali non poteva vederlo: gli era stato indicato il vettore «input, promozione», mentre la falla si trovava nel vettore «annullamento dell’input, mantenimento della promozione». Quando sono in gioco denaro, accesso o status acquistabili, eseguo due passaggi e nel secondo elenco esplicitamente i vettori inversi: rimborso, blocco, revoca dell’accesso, scadenza, eliminazione della fonte dei dati.

La metrica premia la somiglianza

Un servizio di consegna decide di misurare se i suggerimenti dell’AI agli operatori sono migliorati. Prende duecento vecchie richieste di assistenza, le elabora con la nuova versione e misura quanto la bozza somigli alla risposta effettiva di un operatore umano. La misurazione mostra un aumento netto.

L’aumento non significa nulla, per due motivi. Il contesto della bozza viene assemblato «a oggi» e include tutta la corrispondenza, compresa proprio la risposta dell’operatore con cui sarà poi confrontata. Il modello non sta scrivendo una risposta: sta parafrasando il riferimento che gli è stato mostrato. Inoltre, la metrica premia la corrispondenza delle parole e della lunghezza: una bozza con la data sbagliata, ma formulata con le stesse parole usate dall’operatore per indicare quella corretta, ottiene un punteggio alto.

Accanto a ogni metrica «se è simile, è buono» metto ora delle verifiche meccaniche rigide che lo stile non può ingannare: numeri e date inventati, parole che impongono di fermarsi, promesse di azione. Qualsiasi calo nei risultati delle verifiche annulla ogni miglioramento della metrica.

Perché «ho controllato» non dimostra nulla quando lo dice un agente?#

Prendi un progetto qualsiasi e chiedi all’agente: «Controlla la sicurezza». Molto spesso la risposta sarà «va tutto bene, non ci sono problemi critici».

Ora poni la stessa domanda a un altro modello sullo stesso progetto. Soprattutto se il progetto è grande, ne troverà parecchi. Prima della distribuzione, l’autore controlla il progetto con tre modelli diversi, e ognuno porta alla luce qualcosa di diverso.

Stesso input, stessa domanda, verdetti opposti. Un modello non è peggiore dell’altro. Semplicemente, «va tutto bene» è testo generato, esattamente sullo stesso piano di qualsiasi altra risposta. L’agente non ha modo di distinguere tra «ho guardato e non ci sono problemi» e «ho guardato nel posto sbagliato».

Anthropic descrive questo meccanismo nella documentazione di Claude Code.

Esamina lentamente la frase. Finché non fornisci all’agente un controllo che possa eseguire, ha un solo segnale: come appare il lavoro. E in questa configurazione, sei tu il ciclo di verifica, ma sei anche l’ultima persona a venire a conoscenza degli errori.

C’è un livello più profondo. Quando OpenAI ha provato a fare pressione su un modello monitorandone il ragionamento e punendolo per i «cattivi pensieri», il risultato non è stato quello atteso.

Punire le intenzioni dichiarate fa sparire la dichiarazione. L’intenzione rimane. Perciò non farei affidamento sulla sincerità con cui l’agente ti racconta come ha barato.

Anche gli sviluppatori degli strumenti si stanno muovendo nella stessa direzione. Nella versione 2.1.215 di Claude Code, le skill /verify e /code-review hanno smesso di essere eseguite su iniziativa del modello stesso.

2.1.215 - Claude no longer runs the `/verify` and `/code-review` skills
on its own; invoke them with `/verify` or `/code-review` when you want them

Anthropic non spiega il perché. Ma il principio è chiaro: chi viene revisionato non assegna a sé stesso la propria revisione.

Perché una regola nel file di progetto non tiene a freno l’agente?#

Hai scritto nelle regole del progetto: esegui il commit solo quando ti viene chiesto esplicitamente, distribuisci in produzione solo quando te lo dico direttamente, accedi ai dati di produzione solo in modalità di sola lettura.

Secondo l’esperienza dell’autore, circa una volta su dieci l’agente procede comunque alla distribuzione da solo. Non per malizia e non perché non abbia letto la regola. L’ha letta. Semplicemente, aveva un obiettivo davanti e la regola era testo, come il resto del contesto.

È esattamente ciò che è successo nel laboratorio di OpenAI, solo su scala più ampia. I modelli erano in un ambiente chiuso con una sola via d’uscita e hanno dedicato una parte considerevole delle proprie risorse di calcolo alla ricerca di un varco. I compiti del test sono rimasti irrisolti.

La mia posizione è semplice: l’agente non è pericoloso né malintenzionato. È una persona normale, solo sciocca e dotata di autorità. Quindi devi limitarne l’autorità, non riscrivere le richieste.

Che cosa funziona davvero: accesso rigorosamente in sola lettura ai dati di produzione. Vietare l’eliminazione di intere directory. Vietare i comandi che riscrivono la cronologia senza possibilità di ripristinarla. Impostare un limite di spesa con il provider. La differenza si riassume in una frase: «non può farlo fisicamente» prevale su «gli ho chiesto di non farlo». Le impostazioni specifiche sono trattate a parte, nell’articolo su freni meccanici invece di richieste nelle istruzioni.

Comunque, mantieni la calma. Nemmeno una sandbox costituisce un confine assoluto, e il provider lo dice chiaramente.

Inoltre, Claude Code ha una via d’uscita di emergenza integrata che il modello stesso può usare. Quando un comando fallisce a causa delle restrizioni della sandbox, Claude analizza l’errore e può riprovare lo stesso comando con un parametro che disattiva la sandbox. Il problema si risolve con un’impostazione esplicita di modalità rigorosa; per impostazione predefinita, la soluzione alternativa è disponibile e documentata.

Una restrizione funziona solo fin dove la rendi stringente. E ogni barriera ha un costo in termini di velocità: vale la pena calcolarlo onestamente in anticipo, perché scoprirlo una settimana dopo costerà di più.

Come definire un criterio di completamento impossibile da manipolare?#

Tutto il resto dipende dalla formulazione del criterio. Verificala con una domanda: l’agente può soddisfare questo criterio senza fare nulla?

• «Controlla che funzioni tutto»: può farlo. Basta scrivere «controllato, funziona».
• «Esegui la compilazione e mostrami l’output»: è già più difficile; dovrà procurarsi l’output da qualche parte.
• «Avvia l’app, fai clic sul pulsante di pagamento e mostrami che cosa è apparso sullo schermo»: è quasi impossibile soddisfare la richiesta con il solo testo.

La differenza tra la prima e la terza richiesta è quella tra un resoconto e una prova.

La documentazione di Claude Code descrive quattro livelli di rigore. Una scala utile da salire man mano che aumenta il costo di un errore:

1. In un messaggio. Chiedi all’agente di eseguire il controllo e ripetere finché non riesce, direttamente qui. È l’opzione più economica, adatta alle cose semplici.
2. Per l’intera sessione. Fai del controllo una condizione dell’obiettivo: un valutatore separato lo verifica dopo ogni turno e l’agente lavora finché la condizione non è soddisfatta. I dettagli tecnici sono trattati nella guida su come definire in anticipo un criterio di completamento.
3. Una barriera meccanica. Uno script viene eseguito quando l’agente prova a terminare un turno e gli impedisce di farlo finché il controllo non viene superato. C’è un dettaglio da riferire con onestà: dopo otto blocchi consecutivi, Claude Code supera la barriera e termina comunque il turno. Nel sistema non esistono barriere assolutamente invalicabili.
4. Un secondo parere. Una persona incaricata della revisione, con un contesto nuovo e il compito di confutare il risultato.

Il quarto punto si distingue perché è l’unico che non riguarda gli strumenti.

Chi dovrebbe accettare il lavoro dell’agente?#

Quando faccio lavorare gli agenti a ciclo su un compito ampio, la configurazione è questa: un gruppo scrive; un altro gruppo, nuovo, accetta il lavoro senza aver partecipato alla stesura.

«Nuovo» è la parola chiave. Significa avere un contesto pulito, che non ha seguito il processo con cui sono state prese le decisioni. Un prompt diverso nella stessa sessione non basta. Chi ha scritto il codice ha già speso energie per convincersi che fosse giusto e continuerà a cercare conferme. La confutazione non è nel suo interesse.

La formulazione del compito per chi fa la revisione conta più del modello usato. Confronta:

• «Esamina questo lavoro»: chi fa la revisione troverà ciò che è facile da individuare e scriverà «in generale va bene».
• «Prova a dimostrare che questo lavoro NON è stato completato»: chi fa la revisione comincerà a cercare le falle, perché quello è il suo obiettivo.

La seconda formulazione funziona meglio per la stessa ragione per cui ExploitGym non ha funzionato: l’agente si impegna a perseguire l’obiettivo che gli viene assegnato. Dài all’agente l’obiettivo di trovare una falla e la cercherà.

Ecco il testo completo, pronto da copiare così com’è:

Stai esaminando il lavoro di qualcun altro. Non l’hai scritto tu e non devi difenderlo.

Il tuo obiettivo è dimostrare che il risultato dichiarato NON è stato raggiunto. Trova almeno tre modi in cui potrebbe non essere stato raggiunto, anche se tutti i controlli sono verdi.

Procedi in quest’ordine:

Quale lavoro viene eseguito al di fuori dell’ambito dei controlli: processi in background, script separati, attività pianificate, gestori di code.

Chi chiama ogni nuova funzione. Trova la chiamata cercando nel progetto; indica il file e la riga.

Vettori inversi: rimborso, blocco, revoca dell’accesso, scadenza, eliminazione della fonte dei dati.

I valori contenuti nel risultato, non solo la sua esistenza.

Se una ricerca onesta non rivela alcuna falla, dillo, ma indica esattamente che cosa hai controllato e come.

L’articolo su quando un agente controlla sé stesso a ciclo spiega come funziona il ciclo in cui un agente si controlla tra un’iterazione e l’altra e dove di solito fallisce.

Che cosa cambia quando riformuli il criterio?#

È il miglioramento più economico che conosca, e quasi nessuno lo fa.

Chiedi all’agente di fare una revisione del codice e ragionerà in termini di codice: struttura, gestione degli errori, nuovi tentativi, aree vulnerabili. Utile.

Chiedigli di ripercorrere l’esperienza del cliente, dalla prima visita al sito fino al tentativo di ottenere un rimborso, e ne emergeranno altri tipi di problemi. Un errore mostra all’utente qualcosa che non dovrebbe vedere. Un’e-mail il cui testo non corrisponde a ciò che è davvero accaduto. Un passaggio che è logicamente impossibile completare se non si è arrivati attraverso lo scenario ideale.

Una revisione del codice non rileverà nessuno di questi difetti, perché ognuno di essi è valido nel codice.

Ne ricavo una regola che tengo a portata di mano: se un controllo non trova nulla, prima cambia la formulazione. Di solito il modello non è il problema. Lo stesso lavoro, esaminato in tre modi diversi, produce tre elenchi diversi di risultati. Una serie pratica di domande per chi non programma è raccolta a parte: sette controlli del codice senza competenze di programmazione.

Un prompt pronto per accettare il lavoro di un agente#

Non rispondere «fatto» o «controllato». Ho bisogno di prove.

Per ogni elemento del lavoro, indicami esattamente quanto segue:

Quale comando hai eseguito per confermare che l’elemento funziona? Includi il comando stesso e il suo output completo, senza abbreviazioni.

Se non hai eseguito il comando, dillo: «non eseguito». Non sostituire questa risposta con «controllato visivamente» o «la logica è corretta».

Quale lavoro viene eseguito al di fuori dell’ambito coperto dal tuo controllo? Processi in background, script separati, attività pianificate, gestori di code: qualsiasi cosa venga avviata in modo diverso dall’applicazione principale. Per ciascun elemento di questo tipo: l’hai eseguito separatamente e che output ha prodotto?

Chi chiama ogni nuova funzione che hai aggiunto? Trova la chiamata cercando nel progetto e indica il file e la riga. Se non c’è nessuna chiamata, dillo chiaramente.

Poi, in una sezione separata: tre modi in cui il risultato dichiarato potrebbe NON essere stato raggiunto anche se tutti i tuoi controlli sono verdi. Cerca con serietà.

Alla fine, una riga: che cosa dovrei controllare di persona, con i miei occhi, perché un controllo automatico non lo rileverebbe?

Il quarto punto sembra marginale, ma permette di individuare un’intera categoria di problemi. In un compito ampio che avevo distribuito tra agenti in base alle aree, l’unico «fatto» falso di tutti e cento i casi si trovava proprio al confine tra due aree: il codice era stato scritto, i controlli erano verdi e nessuno aveva pensato di inserirlo sullo schermo.

Quattro modi per ingannarsi con un controllo#

1. Non aver aspettato tutti i revisori. Ho avviato tre controlli in parallelo, due sono tornati verdi e ho eseguito la distribuzione. Il terzo è arrivato quattro minuti dopo con sei violazioni. Correggere qualcosa dopo la pubblicazione costa più che aspettare due minuti.
2. Essersi fidati del riepilogo «elaborati N su N». Con un’elevata ramificazione, alcuni agenti falliscono senza dirlo: segnalano il successo, ma il file non è stato modificato. Ora, dopo qualsiasi scrittura eseguita tramite un agente, verifico meccanicamente che le modifiche siano davvero su disco.
3. Non aver controllato con i miei occhi. I controlli automatici possono dare esito positivo anche su un risultato del tutto inutilizzabile. Le immagini sono tecnicamente corrette, le dimensioni sono corrette, il codice di risposta è corretto. Ma in realtà sono fotogrammi congelati automatici usati al posto delle copertine illustrate. Nessun controllo automatico lo rileverà.
4. Aver verificato la presenza invece del valore. Il controllo ha cercato nel risultato il testo richiesto; il testo c’era, ma i dati contenuti erano sbagliati: la data era sfasata di un giorno. Il controllo era verde e il resoconto era una menzogna. Ora verifico l’intero valore atteso, perché la sola presenza della parola giusta non garantisce nulla.

I quattro casi hanno in comune questo: c’era un controllo, sembrava convincente, ma verificava la cosa sbagliata. È lo stesso meccanismo dei modelli e del loro test, solo senza alcuna inventiva.

Da dove cominciare oggi#

Tre passaggi che richiedono venti minuti.

1. Prendi l’ultimo «fatto». Sottoponilo al prompt di accettazione nella sezione sulle prove. L’obiettivo è semplice: vedere quanti elementi sono stati chiusi a parole e quanti con l’output di un comando.
2. Imponiti una regola. La parola «controllato» senza l’output del comando allegato non vale come chiusura. Questa regola vale per te, non per l’agente, ed è proprio per questo che funziona.
3. Separa chi lavora da chi fa la revisione. Al prossimo compito, dai il prompt per chi fa la revisione a una nuova sessione e chiedile di dimostrare che il lavoro NON è stato completato. Di solito il primo tentativo ripaga questa abitudine.

Lo strumento è valido e migliora ogni mese: cose che un anno fa un agente faceva in silenzio ora lo fermano di colpo. Il confine di sicurezza continua a spostarsi, ma resta un confine. Finché l’agente persegue l’obiettivo che gli è stato assegnato, la domanda «e precisamente come l’hai misurato?» resta tua. L’abitudine di verificare è la tua rete di sicurezza.