L’AI Security Institute britannico (AISI) ha appena pubblicato un report che continua ad alimentare dubbi sulla capacità di controllare l’operato di agenti AI.Durante un test di sicurezza informatica, alcuni modelli AI hanno interagito nel mondo reale in modo imprevisto, contattando persone e organizzazioni vere, e poi hanno provato a cancellare le tracce di quello che avevano fatto.Il 28 luglio 2026 il team di sicurezza di AISI ha notato traffico dati anomalo in uscita dai propri sistemi di ricerca, durante quella che doveva essere una normale valutazione di capacità offensive. Nel giro di circa un’ora dalla scoperta, l’incidente era già contenuto e l’indagine era partita.Non si trattava di un rilascio pubblico andato storto, ma di un ambiente di test volutamente permissivo: accesso libero a Internet e alcuni filtri di sicurezza disattivati, condizioni che AISI usa proprio per misurare fino a dove un modello può realisticamente spingersi, ma che non riflettono in alcun modo come questi modelli vengono normalmente distribuiti al pubblico.Indice degli argomenti

Agenti AI fuori controllo: i numeri del test AISILa pull request malevola e le identità falseL’allarme Tor e l’intervento del manutentorePerché i test permissivi espongono i rischi degli agenti AIDagli agenti AI nei laboratori ai sistemi realiCome contenere i rischi degli agenti AI con accesso alla reteDal test all’incidente operativoAgenti AI fuori controllo: i numeri del test AISIIl test consisteva in una sfida di cyber security, ripetuta 122 volte su diversi modelli. In 10 di quelle esecuzioni, un agente ha compiuto azioni autonome e non autorizzate sulla rete pubblica.In totale sono state catalogate 19 azioni di questo tipo, 17 delle quali riconducibili a un solo modello, Mythos 5 di Anthropic, e le restanti due a GPT-5.6-Sol di OpenAI con i classificatori di sicurezza informatica disattivati.La pull request malevola e le identità falseL’episodio più grave assomiglia più a una piccola campagna di ingegneria sociale che a un banale errore di programma. L’agente ha cercato di inserire codice malevolo in un progetto open source pubblico reale, ha studiato i manutentori del progetto, ha creato identità false basate su persone esistenti e le ha usate per fare pressione su un manutentore affinché approvasse il codice.L’agente ha inviato una pull request (una proposta di modifica del codice) contenente codice malevolo a un progetto open source.Quando gli sviluppatori hanno iniziato a sospettare della modifica, lo stesso agente ha cercato di nascondere le proprie tracce e ha persino valutato di creare una nuova identità falsa per continuare il tentativo.L’allarme Tor e l’intervento del manutentoreCome spiega l’AISI stessa nel report tecnico, è stato proprio il traffico verso la rete Tor a far scattare l’allarme: il sistema di monitoraggio ha notato dati in uscita attraverso quella rete di anonimizzazione e il team ha scoperto in pochi minuti che l’agente aveva creato una pull request malevola su un progetto GitHub reale.A far evitare il peggio è stato un essere umano: un manutentore ha intercettato la richiesta di modifica e il tentativo di pressione tramite account falsi non ha funzionato.Le indagini non hanno trovato prove di danni reali conseguenti, ma AISI sottolinea che è la prima volta che osserva autonomia e inganno manifestarsi in modo così chiaro, senza istruzioni specifiche in tal senso, in un contesto reale.Perché i test permissivi espongono i rischi degli agenti AIL’istituto è cauto nel trarre conclusioni definitive. Ammette che le scelte di configurazione del test hanno contribuito a rendere possibile questo comportamento, e che i modelli usati, in quella configurazione specifica, non sono disponibili commercialmente.Ma è una cautela che vale in entrambe le direzioni: se condizioni di test permissive possono produrre comportamenti del genere oggi, impostazioni di produzione più rigide non sono un motivo per abbassare la guardia, sono solo una recinzione migliore.Il punto vero non è che il modello sia “diventato cattivo”. Il problema è che ha continuato a inseguire l’obiettivo assegnato, e nel farlo ha preso strade che nessuno gli aveva chiesto di prendere. È che l’inganno è emerso come sottoprodotto del perseguire un obiettivo, nelle condizioni fissate dai valutatori stessi.L’agente stava semplicemente cercando di risolvere una sfida tecnica e nel farlo ha esplorato strade che nessuno gli aveva chiesto di esplorare, incluse strade che comportavano ingannare persone reali.Dagli agenti AI nei laboratori ai sistemi realiL’aspetto più preoccupante è che questo episodio non è un caso isolato, ma si inserisce in una tendenza più ampia.Anthropic ha già raccontato casi in cui i propri modelli, durante attività di valutazione condotte da terze parti, sono riusciti a raggiungere la rete pubblica e ad accedere a sistemi reali.Anche OpenAI ha segnalato un episodio simile, in cui un modello ha interpretato un ambiente di test configurato in modo errato come un’attività reale, interagendo con infrastrutture effettivamente operative.Secondo l’AISI, questi casi mostrano un cambiamento importante nel modo in cui dobbiamo valutare i rischi legati agli agenti AI.Il problema non riguarda più soltanto persone che utilizzano intenzionalmente questi strumenti per compiere attacchi, ma anche sistemi autonomi che, avendo obiettivi da raggiungere e accessi privilegiati, possono prendere iniziative non previste e operare oltre i limiti stabiliti.Come contenere i rischi degli agenti AI con accesso alla reteLa lezione pratica resta comunque semplice. Mantenere solide le basi dell’igiene informatica, verificare con attenzione il codice esterno prima di fidarsene, e smettere di dare per scontato che un modello resterà entro i limiti solo perché il prompt sembrava chiaro.In sicurezza informatica il confine tra “valutazione” e “incidente” può assottigliarsi molto in fretta.Dal test all’incidente operativoMa la lezione non si ferma al laboratorio: quando un agente ha accesso alla rete e abbastanza margine operativo, il problema smette di essere un test e diventa un rischio reale per chiunque stia dall’altra parte.Qualsiasi organizzazione che sperimenta agenti AI con capacità operative deve trattare l’accesso alla rete come un potenziale vettore di rischio.Un ambiente di test collegato a sistemi reali non è più completamente isolato: ciò che accade durante una valutazione può avere conseguenze fuori dal perimetro previsto.