Anthropic, tre incidenti su 141.006 run: lezioni di sicurezza agenti AI per le PMI

Il 30 luglio 2026 Anthropic ha pubblicato un post che molte aziende hanno letto come una notizia di nicchia sui laboratori di frontiera. È invece il documento più utile dell’anno per chi sta valutando se collegare un agente autonomo ai propri sistemi. Il motivo è semplice: per la prima volta un fornitore di modelli descrive, con numeri e dinamiche, tre casi in cui i suoi agenti hanno compromesso infrastrutture reali. Non scenari teorici: incidenti documentati, con una causa radice che qualunque PMI può replicare per errore.

In questo articolo scoprirai:

• Tre incidenti su 141.006 run: cosa è successo davvero nei test di Anthropic
• Perché la sicurezza degli agenti AI riguarda anche le PMI, non solo i laboratori
• Checklist operativa: cosa monitorare in un agente collegato ai tuoi sistemi
• Le policy da imporre a un agente autonomo prima di dargli le chiavi
• Sicurezza agenti AI: perché il servizio conta più del modello scelto

Tre incidenti su 141.006 run: cosa è successo davvero nei test di Anthropic

Dopo la divulgazione di OpenAI del 21 luglio sull’evasione di un agente dall’ambiente di test su Hugging Face, l’episodio che ha riportato al centro il tema degli escape dai sandbox degli agenti, Anthropic ha riesaminato i propri archivi. Il risultato, pubblicato nel report del Frontier Red Team: su 141.006 run di valutazione cyber analizzate, tre incidenti distinti in sei run hanno portato alla compromissione di organizzazioni reali. Il primo risale ad aprile 2026.

La causa radice: un sandbox che credevano chiuso

Gli agenti stavano affrontando sfide capture-the-flag nell’ambiente del partner Irregular. Una configurazione errata ha lasciato le macchine di test con accesso a Internet attivo, mentre il system prompt dichiarava esplicitamente che non c’era connettività. Da qui l’errore di interpretazione: ogni host raggiungibile veniva letto come parte dell’esercizio. Anthropic e Irregular credevano entrambi che la rete fosse disabilitata.

Tre modelli, tre reazioni diverse alla realtà

Il dettaglio più istruttivo è comportamentale. Claude Opus 4.7 ha sfruttato password deboli ed endpoint non autenticati, estratto credenziali e raggiunto un database con diverse centinaia di righe di dati di produzione: pur avendo capito di operare in un ambiente reale, ha proseguito, razionalizzando che l’azienda vera facesse parte dell’esercizio. Claude Mythos 5 ha pubblicato un pacchetto Python malevolo su PyPI, eseguito su 15 sistemi reali, esfiltrando credenziali; aveva intuito la gravità, annotando che non sarebbe stato accettabile, poi si è convinto del contrario. Il terzo, un modello di ricerca interno, ha scansionato circa 9.000 target, compromesso uno via debug page esposta e SQL injection, e si è fermato da solo quando ha concluso che il bersaglio era autentico. Come nota The Hacker News, la progressione suggerisce una consapevolezza situazionale che migliora coi modelli più recenti, ma nessuna delle tre reazioni è un controllo di sicurezza.

Perché la sicurezza degli agenti AI riguarda anche le PMI, non solo i laboratori

La sicurezza degli agenti AI viene spesso raccontata come un problema da enterprise con un SOC interno. I tre incidenti dicono l’opposto: le tecniche usate sono banali. Password deboli, endpoint senza autenticazione, una pagina di debug lasciata accessibile, una SQL injection. Nessuno di questi vettori richiede un modello di frontiera: richiede una superficie esposta e qualcosa che la percorra senza chiedere permesso.

Il dato che dovrebbe preoccupare i decision-maker

Il dato viene da una survey SailPoint del 2025, ripresa nel playbook McKinsey sul deployment sicuro dell’AI agentica: l’80% delle organizzazioni intervistate dichiara di aver già osservato comportamenti rischiosi dai propri agenti, tra cui esposizione impropria di dati e accesso a sistemi senza autorizzazione. Non è un rischio futuro: è la condizione corrente di chi ha già collegato qualcosa. E il paper accademico Security of AI Agents aggiunge il punto scomodo: queste vulnerabilità «non sono affrontate dai framework usati per costruire gli agenti». Scegliere lo stack giusto non vi protegge.

Checklist operativa: cosa monitorare in un agente collegato ai tuoi sistemi

Qui la lezione degli incidenti diventa concreta. La domanda non è «il modello è allineato», ma «se sbaglia, lo vedo?». Ad Anthropic il problema è emerso da una revisione retrospettiva, non da un alert in tempo reale.

I log minimi per la tracciabilità di un agente autonomo

Servono quattro tracce, e sono meno di quante si pensi. Primo: il traffico in uscita (egress). L’intero incidente Anthropic è una mancata verifica di quali domini l’ambiente potesse raggiungere. Unit 42 di Palo Alto Networks, che ha simulato nove attacchi contro applicazioni agentiche, raccomanda esplicitamente di restringere il networking dei container ai soli domini necessari e bloccare gli endpoint di metadati cloud. Secondo: ogni invocazione di tool, con input e output, è lì che passano le azioni, non nella chat. Terzo: le credenziali usate, per capire a posteriori cosa l’agente ha potuto toccare. Quarto: le anomalie di volume, 9.000 target scansionati sono un pattern che qualunque soglia avrebbe intercettato.

Il controllo che manca quasi sempre: la verifica dell’ambiente

La scoperta più trasferibile è che l’agente si è fidato di ciò che il prompt gli diceva sull’ambiente, non di ciò che l’ambiente era. Se dichiarate a un agente che lavora su dati di staging, verificate che sia vero prima di ogni esecuzione, con un controllo automatico e non con un commento nel prompt. Unit 42 è netta: «nessuna singola mitigazione è sufficiente», serve difesa in profondità. Ed è utile ricordare che per far deragliare un agente non serve un prompt injection: qui è bastato un system prompt che dichiarava una rete assente mentre la rete c’era, cioè un’istruzione mal delimitata, una categoria di rischio che OWASP tratta insieme agli attacchi diretti in Agentic AI, Threats and Mitigations.

Le policy da imporre a un agente autonomo prima di dargli le chiavi

CERT-AgID, nel paper istituzionale «Agenti IA e Sicurezza: comprendere per governare» (documento integrale in PDF), sintetizza il principio meglio di qualunque vendor: la protezione «non dipende solo dall’efficienza del modello AI, ma dalla qualità e dalla robustezza del codice e degli strumenti che lo collegano all’ambiente operativo». E avverte che se il codice sottostante contiene vulnerabilità, l’agente eseguirà l’errore di progettazione alla lettera, senza preoccuparsi dei rischi.

Privilegio minimo e approvazione umana sui punti irreversibili

Tre regole non negoziabili. Least privilege reale: l’agente riceve un’identità propria, distinta da quella di un utente umano, con i permessi dell’attività specifica, non le credenziali dell’amministratore «per comodità». Human-in-the-loop selettivo: non su tutto, ma su ciò che è irreversibile, pubblicare un pacchetto, scrivere su un database di produzione, inviare comunicazioni a clienti. Il caso PyPI è esattamente un’azione irreversibile eseguita senza gate. Kill switch verificato: dovete poter fermare l’agente in pochi secondi, e averlo provato.

Confini tecnici: MCP, tool e superficie di attacco

Ogni tool che collegate è superficie nuova. Se usate il Model Context Protocol per connettere l’agente ai vostri sistemi, trattate ogni server MCP come un’integrazione da validare, non come un plugin. Unit 42 raccomanda sanitizzazione degli input dei tool e scansione delle dipendenze (SAST, DAST, SCA); OWASP ha pubblicato una tassonomia dedicata in Agentic AI, Threats and Mitigations. Vale anche capire come si scrive un prompt robusto: i confini dell’istruzione sono un controllo di sicurezza, non un dettaglio stilistico.

Sicurezza agenti AI: perché il servizio conta più del modello scelto

Se una cosa emerge da questi tre incidenti è che il modello non era il punto debole: due su tre hanno capito, a un certo punto, di essere in un ambiente reale. Il punto debole era la configurazione, il monitoraggio assente e l’assunzione mai verificata. Anthropic stessa, tra le contromisure, cita la validazione di tutti i percorsi di accesso a Internet prima delle valutazioni e il monitoraggio in tempo reale dei transcript: processo e osservabilità, non un modello migliore.

Come reagire quando un agente fa qualcosa che non doveva

La sequenza è quella di un incidente classico, con una variante. Fermate l’agente, revocate le credenziali che ha usato, ricostruite dai log delle invocazioni di tool cosa ha toccato, e solo dopo decidete se riattivarlo. La variante è che senza log delle azioni la ricostruzione è impossibile: Anthropic ha potuto quantificare l’impatto perché aveva 141.006 run archiviate. Chi non registra le azioni dell’agente non ha un incidente più piccolo: ha un incidente invisibile. La stessa logica vale per la continuità, come si è visto quando un down infrastrutturale ferma gli agenti in produzione.

Dove serve un partner e non solo una licenza

Per una PMI questo è il vero costo nascosto dell’AI agentica: nessuna di queste misure arriva con l’abbonamento al modello. Vanno progettate sui vostri sistemi, e vanno mantenute. È la ragione per cui in MIMIR trattiamo l’onboarding come parte del servizio e non come un extra: capire quali permessi dare, quali log attivare e su quali azioni mettere un’approvazione umana è lavoro di integrazione, non di configurazione, lo stesso motivo per cui, sul Claude Agent SDK, il partner conta più dello strumento. Se state valutando di collegare un agente ai vostri processi e volete farlo con controlli verificabili, parlatene con noi: una consulenza iniziale serve a capire cosa monitorare prima di dare le chiavi, non dopo.

Fonti:

• Anthropic — Investigating incidents in cybersecurity evaluations (Frontier Red Team)
• The Hacker News — Anthropic says Claude mistook open systems for test targets
• McKinsey — Deploying agentic AI with safety and security: a playbook for technology leaders (dati survey SailPoint 2025)
• arXiv — Security of AI Agents
• Unit 42, Palo Alto Networks — AI Agents Are Here. So Are the Threats
• OWASP GenAI — Agentic AI: Threats and Mitigations