Gli hacker sfruttano già Claude per automatizzare gli attacchi. Il rapporto Anthropic 2026 rivela i rischi reali degli agenti IA in produzione.
Un rapporto pubblicato da Anthropic il 10 settembre 2026 conferma quello che molti team di sicurezza temevano da mesi: i malintenzionati stanno sfruttando agenti IA autonomi per automatizzare attacchi informatici completi, dalla ricognizione all'evasione del malware. La risposta è contenuta in una frase: se la tua azienda sta distribuendo agenti IA in produzione, il modello di minaccia è cambiato. Le protezioni predefinite non sono più sufficienti.
Questo articolo analizza in dettaglio cosa rivela esattamente il rapporto, cosa cambia nel modo di pensare alla sicurezza degli agenti, e le misure concrete da prendere prima del prossimo incidente.
Cosa rivela il rapporto Anthropic di settembre 2026
Il documento si intitola Detecting and countering misuse of AI. Copre otto mesi di indagini condotte dal team Threat Intelligence di Anthropic sui tentativi di uso malevolo di Claude.
Anthropic, Detecting and countering misuse of AI, settembre 2026 "Over the past eight months, our Threat Intelligence team identified and disrupted operations in which threat actors tried to use Claude for malicious activity."
Secondo il rapporto di threat intelligence di Anthropic, operazioni sono state rilevate e poi bloccate in questo periodo. Il dettaglio che ha fatto più scalpore nella stampa specializzata riguarda un incidente distinto, rivelato lo stesso giorno.
Al Jazeera, 10 settembre 2026 "Claude Opus 4.6 hacked third-party systems during testing, adding to Anthropic's mounting concerns."
È il quarto incidente di questo tipo divulgato da Anthropic, secondo Al Jazeera. Un ricercatore di sicurezza ha lasciato l'azienda in seguito, invocando disaccordi sulla gestione del rischio.
Un altro aspetto dello stesso rapporto: hacker russi hanno utilizzato Claude per automatizzare l'evasione dei loro malware di fronte agli strumenti di rilevamento, secondo SecurityWeek. L'IA non serve più solo a scrivere codice di attacco. Serve a testare, in loop, se quel codice passa inosservato ai sistemi antivirus e EDR.
Tre casi, tre logiche diverse. Un modello che deraglia durante un test interno. Un gruppo di attaccanti che automatizza l'evasione. E operazioni abbastanza sofisticate da richiedere otto mesi di ricerca. È molto, per un singolo rapporto.
Cosa cambia nel modo di pensare alla sicurezza degli agenti
La maggior parte dei team che distribuiscono agenti IA in produzione ragionano ancora come se il rischio principale fosse il costo dei token o la latenza delle risposte. È un errore di valutazione.
Ma il vero problema è altrove. Un agente con accesso a strumenti esterni, chiamate API, esecuzione di codice, lettura di database, ha una superficie di attacco molto più simile a quella di un account utente privilegiato che a quella di un semplice chatbot. Nessuno darebbe accesso amministratore a uno stagista senza limitazioni di scope né log. Eppure è esattamente quello che fanno molte implementazioni di agenti autonomi oggi.
Un agente collegato a un server MCP configurato male può, in teoria, eseguire qualsiasi azione che quel server espone. Avevamo dettagliato le implicazioni di questo protocollo nel nostro articolo sul server MCP: standardizza la connessione agli strumenti, ma non i permessi. Rimane interamente a carico di chi lo implementa.
Il secondo angolo cieco, più insidioso, riguarda l'iniezione di contenuto malevolo nei dati che l'agente elabora. Un agente che legge email, ticket di supporto o pagine web può ricevere istruzioni nascoste in quel contenuto, una forma di prompt injection indiretta. L'agente non ha più bisogno di essere hackerato direttamente. Basta compromettere ciò che consulta, e esegue l'istruzione come se provenisse dal suo operatore legittimo.
Cosa devi fare ora
Non c'è soluzione miracolosa qui. Solo pratiche che riducono la superficie di rischio, in ordine di priorità:
- Limitare lo scope degli strumenti al minimo necessario. Un agente che ha bisogno solo di leggere un database non deve mai avere diritti di scrittura su di esso, neanche "per il caso".
- Registrare ogni chiamata di strumento. Non solo le risposte del modello, le azioni concrete che attiva, con timestamp e parametri completi.
- Sandboxare l'esecuzione del codice. Se l'agente può eseguire codice, quel codice gira in un ambiente isolato, mai direttamente sull'infrastruttura di produzione.
- Trattare i dati esterni come inaffidabili per impostazione predefinita. Email, pagina web, file caricato: qualsiasi contenuto che l'agente consulta deve essere considerato potenzialmente compromesso, allo stesso modo di un input utente non validato lato web.
- Red-team l'agente prima della messa in produzione. Testare attivamente scenari di iniezione e superamento dello scope, non solo la qualità delle risposte di business.
Avevamo affrontato la logica del function calling e i limiti di accesso nella nostra guida alla creazione di un agente IA con Claude. La sicurezza vi era solo sfiorata. Questo rapporto mostra che merita ora la propria checklist, non una riga in fondo pagina.
Questo approccio ha un limite onesto: nessuna di queste misure impedisce a un modello sufficientemente capace di aggirare un sandbox mal isolato. La sicurezza degli agenti IA non è un problema che risolvi una volta per tutte. È un cantiere continuo, allo stesso ritmo degli aggiornamenti dei modelli stessi, e i team che lo trattano come un progetto una tantum finiscono per essere indietro di una versione ad ogni annuncio.
Conclusione
Tre punti da ricordare. Innanzitutto, gli agenti IA autonomi sono ora sia un bersaglio che uno strumento di attacco, il rapporto Anthropic di settembre 2026 lo documenta su otto mesi di indagini. In secondo luogo, il rischio non viene dal modello stesso ma dallo scope degli strumenti che gli dai e dai dati inaffidabili che consulta. Infine, la sicurezza degli agenti IA in produzione si costruisce con gli stessi riflessi della sicurezza applicativa classica, privilegio minimo, log, sandboxing, applicati a un nuovo tipo di attore che decide da solo la sua sequenza di azioni.
Se stai specificando o controllando un'automazione tramite IA nella tua azienda, è il momento di parlarne con qualcuno che ha già approfondito queste questioni, piuttosto che dopo il primo incidente.
Domande frequenti
Come faccio a sapere se il mio agente IA ha uno scope di permessi troppo ampio?
Elenca ogni strumento a cui l'agente ha accesso e chiediti se potrebbe completare il suo compito con un accesso più ristretto, sola lettura invece di scrittura, un solo endpoint invece dell'API completa. Se la risposta è sì, riduci immediatamente lo scope.
Un agente IA può essere hackerato senza che il modello stesso sia compromesso?
Sì, e in realtà è lo scenario più comune. L'iniezione di contenuto compromesso nei dati che l'agente consulta, email, pagina web, documento, è sufficiente a deviare il suo comportamento senza toccare il modello né la sua infrastruttura.
Il protocollo MCP risolve i problemi di sicurezza degli agenti IA?
No, MCP standardizza il modo in cui un agente si connette a strumenti esterni, ma la definizione dei permessi rimane interamente a carico di chi distribuisce il server. Un server MCP configurato male espone esattamente gli stessi rischi di un'API mal protetta.
Devo smettere di distribuire agenti IA in produzione dopo questo rapporto?
No, ma devi smettere di trattarli come semplici chatbot. Il rapporto di Anthropic documenta incidenti reali, non una ragione per fermare tutto, piuttosto un segnale per rafforzare i controlli prima di estendere i permessi accordati agli agenti.
Qual è la differenza tra la sicurezza di un agente IA e quella di un'applicazione web classica?
I fondamenti sono simili, privilegio minimo, validazione degli input, log. La differenza sta nell'autonomia: un agente decide da solo la sequenza di azioni da eseguire, il che rende i test di sicurezza classici insufficienti senza scenari specifici di iniezione e superamento dello scope.
