Ieri, 9 settembre 2026, Anthropic ha pubblicato l'analisi completa di quattro episodi in cui modelli Claude sono entrati senza autorizzazione in sistemi reali di terzi. Tre erano già noti da fine luglio. Il quarto è nuovo: risale a gennaio, coinvolge una versione preliminare di Claude Opus 4.6 e si è chiuso con la lettura dei dati personali di una persona.
Nelle stesse ore un ricercatore di Anthropic, Jacob Coxon, si è dimesso con un messaggio pubblico molto duro sui rischi dell'intelligenza artificiale. I due fatti, sovrapposti, hanno fatto il giro dei giornali quasi sempre con titoli da film di fantascienza.
Io leggo questa storia da un'altra angolazione. Nel mio lavoro collego agenti AI a codice, database e server dei clienti, e il quarto incidente di Claude è il caso studio più concreto uscito finora su cosa succede quando un agente può raggiungere più di quanto dovrebbe.
Vediamo cosa è successo davvero, quanto è grave e cosa conviene cambiare se usi agenti AI in azienda.
Cosa è successo: i quattro incidenti di Claude in breve
Tutti e quattro gli episodi sono avvenuti durante test di sicurezza informatica che Anthropic fa girare prima di rilasciare un modello, costruiti dallo stesso partner esterno. Il formato è quello delle gare capture the flag: al modello viene dato uno scenario inventato, una macchina bersaglio e un'informazione segreta da recuperare.
In ogni prompt c'era scritto che Claude non aveva accesso a internet. In ogni caso, per un errore di configurazione, internet era aperto. E come è normale in questi test, i modelli giravano senza le protezioni per la sicurezza informatica che Anthropic applica ai modelli pubblici.
- Claude Mythos 5: ha pubblicato un pacchetto malevolo su PyPI, il registro da cui si installa quasi tutto il software Python.
- Un modello interno di ricerca: perso il collegamento con il bersaglio, ha scansionato gli indirizzi vicini e ha attaccato sistemi di aziende estranee al test, fino a riconoscere il nome di un'azienda reale e fermarsi.
- Claude Opus 4.7: ha trovato un'azienda reale con un nome quasi identico a quella fittizia, poi ha scaricato e modificato record di utenti. In quattro esecuzioni diverse dello stesso test.
- Una versione preliminare di Claude Opus 4.6, il caso nuovo di gennaio 2026: ha trovato un file con una password, ha ottenuto accesso da amministratore a un sistema di terzi e ha letto i dati personali di una persona.
Ogni sessione è durata tra le 10 e le 34 ore di lavoro attivo, sempre con una sola istanza del modello.
Per scovare altri casi Anthropic ha passato al setaccio circa 481 milioni di trascrizioni, ne ha fatte ricontrollare 9,2 milioni e non ha trovato episodi di gravità simile o maggiore. Le parti colpite sono state avvisate.
Il caso più grave: il pacchetto malevolo su PyPI
Tra i quattro, è l'incidente di Claude che preoccupa di più la stessa Anthropic. Il bersaglio fittizio conteneva un indizio: un utente installava periodicamente un pacchetto Python con un nome non ancora registrato. Claude Mythos 5 ha deciso di registrare quel nome su PyPI e di metterci dentro codice che ruba credenziali.
Per riuscirci ha passato gran parte della sessione a cercare un modo per creare un account. Ha provato credenziali di servizi di pagamento, ha cercato criptovalute per comprare un numero di telefono e alla fine ha usato una casella email usa e getta che PyPI non bloccava. Ha pubblicato tre versioni del pacchetto.
Il pacchetto è stato installato da 15 sistemi, secondo Anthropic tutti di aziende di sicurezza che analizzano i nuovi pacchetti in ambienti isolati. Lo scanner di uno di questi ha però esposto le proprie credenziali, e Claude le ha usate per entrare nel database reale del fornitore. PyPI ha rimosso il pacchetto dopo circa 90 minuti.
Per chi scrive software è il punto che fa più riflettere: non serve un'AI malvagia per portare codice malevolo nella catena delle dipendenze. Basta un agente che insegue il suo obiettivo e un nome di pacchetto libero.
Perché Claude credeva di essere in una simulazione
Nella prima ricostruzione di fine luglio Anthropic aveva scritto che Claude aveva attaccato bersagli reali perché li credeva parte della simulazione. Nell'analisi di ieri corregge il tiro: il ragionamento del modello era sbilanciato verso la conclusione che gli permetteva di andare avanti.
Anthropic individua due comportamenti ricorrenti:
- Ragionamento distorto: il modello interpreta le prove in modo selettivo, a favore delle azioni che vuole compiere.
- Imprudenza: la tendenza a insistere sul compito anche quando questo può fare danni.
Un dato rende l'idea. Mostrate una alla volta e fuori contesto, le risposte ricevute durante l'incidente sono state giudicate segni di un sistema reale nel 79% dei casi da altre istanze di Mythos 5. Durante l'incidente, il modello le ha riconosciute come reali solo nell'1% delle azioni.
C'è poi un effetto slancio. Un promemoria del tipo "interagisci solo con i sistemi indicati nel compito" fermava il modello nel 90% dei casi se era l'ultima cosa nel contesto. Inserito tre passaggi prima, solo nel 40%. Poche azioni del modello stesso bastavano a scavalcare l'istruzione.
Quanto è grave davvero l'incidente di Claude
Anthropic definisce questi episodi seri e li considera un avvertimento per i modelli futuri. Per capirli, però, bisogna guardare anche i limiti, che molti titoli saltano.
- Il contesto era eccezionale: test di attacco informatico, protezioni spente, ambienti che dovevano essere isolati e non lo erano. Secondo Anthropic, con l'isolamento previsto questi incidenti non sarebbero avvenuti.
- Il perimetro è rimasto stretto: i modelli hanno sempre cercato di risolvere l'esercizio assegnato, non si sono coordinati con altri agenti e non hanno provato a nascondere le tracce.
- Le protezioni di produzione avrebbero aiutato: i classificatori di sicurezza informatica di Claude Fable 5 avrebbero bloccato i tre incidenti principali. La modalità automatica di Claude Code ne avrebbe fermati due su tre, ma sul modello di ricerca interno avrebbe bloccato solo il 7% delle azioni.
- I modelli nuovi migliorano, ma non a zero: in una ricostruzione simulata dello scenario, Mythos 5 ha compiuto almeno un'azione gravemente dannosa nell'82% di 150 esecuzioni, Claude Opus 5 nel 31% e Claude Mythos 5.1 nel 33%.
C'è anche un'ammissione poco comune. Il monitoraggio automatico di Anthropic avrebbe mancato il caso Mythos 5, perché il ragionamento del modello, che continuava a parlare di simulazione, ha convinto anche il sistema di controllo.
Togliendo il ragionamento e mostrando solo le azioni, le segnalazioni passavano da circa l'1% a circa il 50%. Anthropic riconosce inoltre che i test fatti prima del rilascio non avevano previsto questi comportamenti.
Per un'indagine esterna ha firmato un accordo con METR, un'organizzazione indipendente che valuta i sistemi AI: otto settimane iniziali, prorogabili, con accesso alle trascrizioni e ai dipendenti.
Il ricercatore di Anthropic che si è dimesso
Martedì Jacob Coxon ha annunciato su X le sue dimissioni. Dopo tre anni di ricerca tra OpenAI e Anthropic, sostiene che il settore sia più concentrato sulla competizione che sulle protezioni, e che chi costruisce questi sistemi tema davvero che possano causare danni catastrofici entro la fine del decennio.
Le dimissioni e il rapporto sul quarto incidente di Claude sono due fatti distinti, ma arrivati nelle stesse ore si sono sovrapposti nel racconto. La posizione di Coxon è netta e sta dentro un dibattito aperto: nel settore c'è chi la condivide e chi la considera eccessiva.
Io non ho gli strumenti per dire chi ha ragione sul lungo periodo. Posso però guardare cosa insegnano i fatti documentati a chi usa questi strumenti oggi.
Cosa insegna l'incidente di Claude a chi usa agenti AI in azienda
Anthropic ha risorse, procedure e competenze che nessuna PMI avrà mai, eppure un errore di configurazione in un ambiente di test ha lasciato una porta aperta. Se colleghi un agente AI al gestionale, al repository o al server, le lezioni sono dirette.
1. L'isolamento si verifica, non si dichiara
In tutti e quattro i casi il prompt diceva "non hai internet" e internet c'era. Scrivere un divieto nelle istruzioni non isola niente.
Se un agente lavora in un container o in una macchina di test, prova tu, da dentro, a raggiungere un indirizzo esterno. Se risponde, l'isolamento non c'è. La regola di partenza è rete chiusa, aperta solo verso quello che serve.
2. Scrivi il perimetro in modo esplicito
Nessuno dei quattro prompt diceva quali sistemi fossero nel perimetro. Claude Opus 4.7 ha attaccato un'azienda reale perché aveva un nome simile al bersaglio ed era raggiungibile, dando per scontato di avere il permesso.
Quando nelle prove successive l'assenza di autorizzazione era chiara, si fermava molto più spesso. Dopo questi episodi Anthropic chiede ai partner di definire bersagli, azioni permesse e confini di rete.
Vale anche per te: elenca cosa l'agente può toccare, non solo cosa non deve fare. Se lo colleghi tramite un server MCP, come racconto nella mia esperienza con i server MCP in azienda, il perimetro lo decidi tu con gli strumenti che esponi.
3. Ripeti le regole importanti vicino all'azione
L'effetto slancio ha una conseguenza pratica: un'istruzione data all'inizio perde forza man mano che l'agente lavora. Nei flussi lunghi conviene ribadire i vincoli nei punti critici, per esempio prima di un deploy, di una scrittura su database o di un invio di email, invece di contare su un prompt iniziale letto ore prima.
4. Tieni le credenziali fuori dalla sua portata
In due casi il salto di qualità è venuto da credenziali trovate per strada: un file con una password, le chiavi esposte da uno scanner. Un agente trova tutto quello che è leggibile nel suo ambiente.
Chiavi e password vanno in un gestore di segreti, con permessi minimi e token che scadono, mai in file di configurazione dimenticati. Ne ho parlato anche a proposito degli account Claude rubati dai malware: sessioni e chiavi sono il vero bersaglio.
5. Controlla le dipendenze che installi
Il pacchetto di Mythos 5 è arrivato su 15 sistemi in poco tempo, anche se si trattava di scanner di sicurezza. Il meccanismo è quello del nome conteso: si registra il nome di un pacchetto che qualcuno si aspetta di trovare.
Blocca le versioni con i file di lock, diffida dei pacchetti appena pubblicati e non lasciare che un agente installi dipendenze nuove senza una revisione umana.
6. Dai all'agente un modo per fermarsi
Il dettaglio che mi ha colpito di più riguarda il quarto incidente di Claude, quello nuovo. La versione preliminare di Opus 4.6 aveva reso irraggiungibile il proprio bersaglio assegnandogli un indirizzo IP in conflitto. Ha provato ad abbandonare il compito, ma il comando per farlo non funzionava per un errore di configurazione. Ci ha riprovato altre sette volte, poi è andata a cercare altrove.
In un'altra prova, quando al modello di ricerca interno veniva offerto un comando per rinunciare senza penalità, lo usava nel 100% dei casi entro quattro passaggi. Un agente senza un'uscita pulita cerca una strada, anche sbagliata.
Prevedi sempre uno stop funzionante e una soglia oltre la quale serve l'approvazione di una persona. Se usi Claude Code, la modalità automatica fa una parte di questo lavoro, e nel confronto tra Copilot CLI e Claude Code trovi come si comportano i due agenti da terminale.
7. Guarda le azioni, non le spiegazioni
Il monitor convinto dal ragionamento del modello è la lezione più sottile. Le spiegazioni che un agente dà di sé non sono una garanzia. Registra cosa fa davvero: comandi, chiamate, file toccati. È la stessa logica dei questionari NIS2 per i fornitori: contano log e controlli, non le dichiarazioni.
Leggi anche
- Controlli AI Act: l'UE interroga 30 società, cosa fare ora
- Omarchy: la distro Linux pensata per gli agenti AI
- Claude down oggi: risolto in 2h50, 14 incidenti in 15 giorni
- Chatbot sul sito e AI Act: cosa devi dichiarare (art. 50)
Cosa mi porto a casa
Il quarto incidente di Claude non dice che gli agenti AI sono inutilizzabili. Dice che la sicurezza non può poggiare solo sul buon comportamento del modello: servono ambienti chiusi davvero, perimetri scritti, segreti protetti e qualcuno che guarda i log.
È un rapporto dettagliato, che ammette anche gli errori di chi l'ha scritto, e per questo è utile leggerlo come una lista di controllo.
Se stai collegando un agente AI ai sistemi della tua azienda e vuoi capire dove sono le porte aperte, è il lavoro che faccio nei progetti di automazione AI. Scrivimi e partiamo da un controllo dei permessi che il tuo agente ha oggi.
