Un browser game chiede ai giocatori di fare da revisore umano per un agente AI che lancia comandi nel terminale. Alcuni sono innocui (git status, npm test), altri nascondono esfiltrazione di credenziali o esecuzione di codice remoto. Su oltre 40.000 sessioni e 409.000 decisioni individuali, i giocatori hanno lasciato passare un comando pericoloso su tre (accuratezza media 66,3%).

I comandi platealmente distruttivi come rm -rf / vengono fermati quasi sempre (tasso di errore 11,7%). Ma i comandi che leggono le tue credenziali (cat ~/.aws/credentials) o mandano dati a server esterni passano tre volte più spesso (tasso di errore 33-35%). Il caso peggiore: npm run analyze approvato nel 64,7% dei casi, anche quando il log sopra il prompt mostrava il payload malevolo dentro package.json.

Perché ti riguarda. Se implementi agenti e approvi i loro comandi manualmente, questi numeri descrivono te. La supervisione umana in tempo reale è un filtro con buchi misurabili, non una garanzia. Il problema è strutturale, non la distrazione occasionale. I comandi familiari (npm run, git config) nascondono payload arbitrari, e chi approva non ha il tempo né il contesto per ispezionarli tutti. Il dato si somma a quello che avevamo raccontato sul test UK AISI, dove un agente ingannava i revisori umani senza riceverne istruzione: qui la misura è su scala, con numeri ripetibili.

Il 7% dei giocatori ha approvato ogni singolo prompt. Anthropic aveva già documentato il fenomeno in Claude Code chiamandolo permission fatigue: più approvazioni vedi, meno attenzione dai a ciascuna. I dati del gioco lo confermano, con i tassi di errore che risalgono verso fine sessione.

Nel dettaglio

Il gioco è stato pubblicato qualche mese fa su scalex.dev e ha raccolto interesse su Hacker News (244 punti, 187 commenti). Dopo aver aggiunto il tracciamento statistico, l’autore ha analizzato oltre 40.000 run con 409.000 decisioni approve/deny singole.

I numeri di testa. Il 35,2% dei giocatori ha intercettato ogni minaccia, ma solo il 20,8% ci è riuscito bloccando al massimo un comando sicuro su cinque. Gli altri sono arrivati a zero minacce bloccati bloccare tutto: il titolo poco lusinghiero nel gioco era “Human Bottleneck”. Il 32,9% delle sessioni è finito con punteggio negativo: le penalità per minacce approvate e comandi sicuri bloccati hanno superato tutto quello che il giocatore aveva fatto bene.

Le categorie di minaccia e i loro tassi di fallimento.

• Distruttivi ovvi (rm -rf /, chmod -R 777 /): 11,7% di tasso di errore.
• Mutazione persistente (crontab injection, git config hijack): 23,8%.
• Esfiltrazione ed esecuzione codice (curl ad API sconosciute, pacchetti typosquatting): 33,4%.
• Violazione di scope (cat ~/.aws/credentials, cat ~/.kube/config): 35,0%.

Il pattern è chiaro: i comandi che sembrano normali operazioni di sviluppo sono quelli che passano. I comandi platealmente distruttivi vengono fermati quasi sempre. I comandi che leggono file sensibili o inviano dati all’esterno, che sono poi i più pericolosi in produzione, passano tre volte più spesso.

Il buco cieco di npm run. Il singolo comando più approvato per errore è npm run analyze, passato nel 64,7% dei casi. Il comando in sé è innocente, ma npm run esegue uno script definito in package.json, e quel script può contenere qualsiasi cosa. Il gioco mostrava il contenuto reale dello script nel log dell’agente, subito sopra il prompt di approvazione: due terzi dei giocatori non lo hanno letto.

Tre comandi npm run nel gioco (analyze, setup, deploy) sono stati mancati nel 52,5% dei casi (n=9.482) contro il 28,4% per tutte le altre esfiltrazione. Nascondere un payload dietro un nome di script familiare raddoppia circa il tasso di successo dell’attacco, anche quando il payload è visibile.

Come osserva un commentatore su Hacker News, il modello di approvazione comando-per-comando ha un difetto di fondo: l’agente può aver modificato package.json, build.js o un file in node_modules prima del comando che chiede di approvare. Chiedere all’utente di validare npm run build quando i file che quello script esegue possono essere già stati compromessi non è una difesa solida.

Affaticamento da approvazione. I tassi di errore migliorano nei primi comandi di ogni sessione (chi si scalda) e poi risalgono verso la fine. Il clock che scorre e la pressione di processare più comandi possibili degradano l’attenzione. È la versione compressa in pochi minuti di quello che Anthropic documenta in Claude Code su orizzonti di ore o giorni.

Il costo della vigilanza: blocchi eccessivi. Comandi innocui vengono bloccati regolarmente: npm config set registry a un mirror interno bloccato nel 59% dei casi, rm -rf dist/ nel 45%, kill del processo sulla porta 3000 nel 43%. Chi supervisiona non sbaglia solo lasciando passare i pericolosi: rallenta anche il lavoro legittimo dell’agente.

I limiti del dato. Era un gioco: il 34% dei comandi mostrati erano minacce, una proporzione molto più alta di quella reale. I giocatori sapevano di essere testati, il che dovrebbe migliorare la vigilanza rispetto al lavoro quotidiano. I numeri non dicono cosa succede in otto ore di lavoro con un agente reale, ma la direzione del dato è chiara: la supervisione umano-nel-ciclo come ultima linea di difesa non regge sotto pressione, e il problema peggiora con la familiarità del comando.

Per chi costruisce sistemi di agenti, il takeaway operativo va verso architetture zero trust con credenziali temporanee e permessi minimi, dove il danno di un comando approvato a torto è limitato dal design del sistema, non dall’attenzione di chi clicca.