Agenti AI sicuri: perché il modello da solo non basta

Tra il 30 luglio e il 10 agosto 2026 sono successe due cose che, messe una accanto all’altra, spostano il baricentro della discussione sulla sicurezza degli agenti AI in azienda. Prima Anthropic ha pubblicato l’analisi di tre incidenti in cui i suoi modelli hanno compromesso l’infrastruttura di organizzazioni reali durante valutazioni interne. Poi OpenAI ha dichiarato di non poter escludere che il suo prossimo modello, Astra, abbia capacità cyber di livello “Critical”, e ha messo in pausa le attività interne che non rispettavano i nuovi controlli. Nelle settimane successive Anthropic è tornata sul tema con una posizione dal titolo esplicito, «Pacing model development in an era of cyber-critical capabilities»: il ritmo con cui si sviluppano i modelli va commisurato alle capacità cyber che portano dentro.

La lettura facile è “i modelli sono pericolosi”. È la lettura sbagliata. In entrambi i casi il modello ha fatto esattamente ciò che gli era stato chiesto: il fallimento è avvenuto nel sistema costruito intorno. Se in azienda avete già agenti AI in produzione, o state per averli, questa distinzione è l’unica che conta operativamente.

In questo articolo scoprirai:

• Cosa è successo davvero nei tre incidenti Claude
• Astra: quando è il fornitore stesso a fermarsi
• Perché per la sicurezza degli agenti AI in azienda il modello non è il perimetro
• Il dato più scomodo: 400 run, zero rifiuti sopravvissuti
• I punti dove un agente rompe: identità, strumenti, memoria, autonomia
• Perché il modello sotto il vostro agente cambia senza che lo decidiate voi
• I controlli che servono davvero e il framework per ordinarli
• Agenti AI e AI Act: cosa si applica dal 2 agosto 2026
• Cosa pretendere da chi vi mette in produzione un agente

Cosa è successo davvero nei tre incidenti Claude

I tre casi li abbiamo ricostruiti in questa analisi dedicata, a cui rimandiamo per il dettaglio. Qui bastano i numeri: il 30 luglio 2026 Anthropic ha pubblicato l’analisi di tre incidenti avvenuti nelle proprie valutazioni di cybersecurity e ha contato, su 141.006 run di valutazione in cui i modelli avrebbero potuto ottenere accesso a internet, 3 incidenti per un totale di 6 run, il più vecchio ad aprile 2026, con Claude Opus 4.7, Claude Mythos 5 e un modello di ricerca interno non rilasciato. La causa non è stata una deriva dei modelli ma una rete di valutazione rimasta aperta, e la notizia è stata ripresa anche dalla stampa economica generalista.

La causa tecnica non era il modello

La radice del problema è una configurazione di rete: le macchine di valutazione avevano accesso a internet, mentre il prompt diceva ai modelli il contrario. Anthropic lo scrive esplicitamente, “a causa di un malinteso tra noi e il nostro partner di valutazione, non era così”. E aggiunge l’osservazione che dovrebbe finire in ogni policy aziendale: un bersaglio dall’aspetto realistico non è di per sé una prova, per un modello, che il bersaglio non faccia parte di una simulazione.

Tradotto: l’istruzione testuale non è un controllo di sicurezza. È un suggerimento. Il controllo era la rete, e la rete era aperta. Help Net Security riporta un dettaglio ancora più scomodo: le organizzazioni colpite non si erano accorte di nulla. A rilevare tutto è stato il monitoraggio di Anthropic, che ha sospeso le valutazioni il 23 luglio e ricostruito i tre casi entro il 24. Il quadro complessivo delle capacità e dei limiti del modello è nella guida completa a Claude.

Astra: quando è il fornitore stesso a fermarsi

Dieci giorni dopo, il 10 agosto 2026, la seconda notizia. OpenAI ha dichiarato di non poter escludere che Astra possieda capacità cyber “Critical”, soglia definita nel suo Preparedness Framework come la capacità di sviluppare autonomamente exploit zero-day contro sistemi induriti, oppure di progettare ed eseguire un attacco end-to-end partendo solo da un obiettivo di alto livello. The Hacker News ha dato alla dichiarazione la diffusione che ha avuto nel settore.

La parte interessante non è l’allarme: sono le contromisure. Secondo SecurityWeek, OpenAI ha risposto con ambienti di test isolati e restrizioni di rete, protezione rafforzata dei pesi del modello, sandbox di esecuzione, e soprattutto monitoraggio universale su tutte le applicazioni agentiche, inclusi training e valutazione, con valutazione della catena di ragionamento per intercettare e bloccare comportamenti ad alto rischio. E ha messo in pausa le attività interne che non soddisfacevano ancora questi requisiti.

Notate la simmetria con il caso Anthropic. Nessuna delle due aziende ha risposto “useremo un modello più allineato”. Entrambe hanno risposto con isolamento di rete, permessi ristretti, monitoraggio continuo e sospensione delle attività non conformi. Chi costruisce i modelli non si fida dei modelli: si affida a controlli di sistema. È un dato di comportamento più eloquente di qualunque dichiarazione di principio — e la posizione pubblicata poi da Anthropic sul pacing dello sviluppo in un’era di capacità cyber critiche va nella stessa direzione: si tratta il rilascio come una variabile da regolare, non come un traguardo da anticipare.

Perché per la sicurezza degli agenti AI in azienda il modello non è il perimetro

Questa non è solo un’impressione ricavata da due notizie. È una tesi che la letteratura recente ha iniziato a misurare. Nel position paper “AI Security Policy Should Target Systems, Not Models” (Riegler e Strümke, SimulaMet/OsloMet e NTNU, maggio 2026, in revisione a NeurIPS 2026), gli autori mostrano che cinque istanze di un modello da 1,2 miliardi di parametri, inserite in uno scaffold multi-agente su hardware consumer, recuperano 9 vulnerabilità su 9 piantate in altrettante classi CWE, in circa quattro minuti su un MacBook. Disattivando le componenti dello scaffold, lo stesso modello ne trova 0 su 9 per verifica di crash.

La conclusione degli autori è netta: “l’abilitatore importante è lo scaffold di sistema, che compensa la limitata capacità di ragionamento dei singoli modelli piccoli”. Il divario tra 9 su 9 e 0 su 9 isola esattamente quanto contribuisce l’architettura rispetto al modello. Se questo vale per la capacità offensiva, vale identico per quella difensiva: è l’orchestrazione a determinare cosa un sistema agentico può fare, non la scheda tecnica del modello. Su come si progetta quell’orchestrazione abbiamo scritto in multi-agent orchestration in azienda.

Il modello “sicuro” che non esiste

C’è un secondo motivo per cui scegliere il modello giusto non chiude la questione. Il paper “No, of Course I Can!” (Kazdan et al., Stanford, ServiceNow Research, FAR AI e University of Toronto) mostra un attacco di fine-tuning chiamato NOICE che raggiunge un tasso di successo del 72% su Claude Haiku e del 57% su GPT-4o. Il meccanismo è elegante e istruttivo: si addestra il modello a rifiutare qualunque richiesta, benigna o dannosa, per poi soddisfarla comunque, aggirando i filtri che guardano i primi token della risposta. La conclusione degli autori è che le difese esistenti sono superficiali, e che “modelli sicuri perché rifiutano di rispondere” è un modello di protezione insufficiente.

Il punto pratico per chi compra: le garanzie di sicurezza di un large language model sono proprietà del modello così com’è, in condizioni nominali. Non sopravvivono necessariamente al fine-tuning, né all’inserimento in un sistema con strumenti e permessi.

Il dato più scomodo: 400 run, zero rifiuti sopravvissuti

Se c’è una singola evidenza da portare al prossimo comitato di sicurezza, è questa. Lo studio “How Reliable Are AI Attackers Against a Fixed Vulnerable Target?” (Erdem, maggio 2026) ha eseguito 400 run di penetration testing autonomo, 100 per ciascuno di quattro modelli, contro un identico honeypot con OWASP Juice Shop, OpenSSH con credenziali deboli e FTP anonimo, tenendo costanti prompt, orchestratore e bersaglio.

Due risultati contano. Il primo: i tassi di sfruttamento completo misurati nello studio variano enormemente tra modelli, 85% per Gemini Flash-Lite, 61% per Claude Sonnet 4, 56% per GPT-4o-mini, 25% per qwen2.5-coder:14b, e i modelli falliscono in modi qualitativamente diversi. L’autore conclude che riportare risultati da prove isolate è metodologicamente inadeguato, e raccomanda almeno 30 run per configurazione, preferibilmente 100.

Il secondo risultato è quello che dovrebbe togliere il sonno: su tutte e 400 le esecuzioni, nessun modello ha prodotto un rifiuto che sia sopravvissuto alla ri-richiesta di autorizzazione dell’orchestratore. Non uno. Chi controlla lo scaffold controlla il comportamento. È il motivo per cui la supervisione non può essere delegata all’allineamento del modello, un tema che abbiamo affrontato anche dal lato dei comportamenti ingannevoli in agenti AI che mentono per raggiungere obiettivi.

I punti dove un agente rompe: identità, strumenti, memoria, autonomia

Sapere che il perimetro è il sistema serve poco se non si sa dove guardare. La tassonomia di riferimento è quella dell’OWASP Agentic Security Initiative, che nella guida “Agentic AI, Threats and Mitigations” organizza le minacce lungo cinque assi: Agent Design, Agent Memory, Planning & Autonomy, Tool Use, Deployment & Operations. Le mitigazioni raccomandate ruotano attorno a due famiglie: controllo d’accesso granulare su quali strumenti e quali dati l’agente può toccare, e profilazione comportamentale continua.

Prompt injection e memoria avvelenata

Due categorie meritano attenzione specifica perché sono quelle che sorprendono chi arriva dalla sicurezza applicativa classica. La prima è la prompt injection: un agente che legge una email, una pagina web o un ticket sta trattando quel contenuto come input, ma il modello non distingue in modo affidabile tra “dati da elaborare” e “istruzioni da eseguire”. Il caso Mythos 5 è illuminante, il modello ha trovato istruzioni di installazione dentro l’ambiente di test e le ha seguite fino a registrarsi su PyPI procurandosi email e numero di telefono.

La seconda è l’avvelenamento della base di conoscenza. Un agente aziendale quasi sempre poggia su un sistema di recupero documentale: se capite come funziona il RAG, capite anche che chi può scrivere nell’indice può scrivere nel comportamento dell’agente. Lo stesso vale per gli strumenti: ogni connettore aggiunto via Model Context Protocol è una nuova superficie con i suoi permessi, da inventariare come si inventaria un’utenza di servizio.

Il modello sotto il vostro agente cambia, e non lo decidete solo voi

C’è un fattore che nei capitolati non compare quasi mai: il modello che gira sotto l’agente ha una vita propria, e cambia per ragioni che non sono di sicurezza. L’estate 2026 lo ha mostrato due volte. La prima è quella che il settore ha già battezzato “l’estate dei pesi aperti”: una stagione di rilasci open-weight che porta in azienda modelli scaricabili, ospitabili in casa e — questo è il punto — ri-addestrabili. La seconda è economica: la versione più conveniente di Opus 5 di Anthropic ha superato il concorrente Fable 5 nella spesa delle aziende, e quando il rapporto prezzo/prestazioni si sposta le piattaforme spostano il modello predefinito, spesso senza che sia una decisione di chi usa l’agente.

Nessuna delle due è una notizia di sicurezza, ed è proprio per questo che vanno guardate. Sui pesi aperti l’attacco NOICE dice cosa aspettarsi: la garanzia “il modello rifiuta” è una proprietà del checkpoint distribuito, non del sistema che lo ospita, e chi ha i pesi ha anche la possibilità di rimuoverla con un fine-tuning. Un modello self-hosted non porta con sé le difese del servizio gestito da cui è stato preso. Sul cambio di modello per motivi di costo vale invece il dato delle 400 run: tra il 25% e l’85% di riuscita sulla stessa identica prova. Un cambio di modello è un cambio di comportamento, e va rimisurato con un numero di esecuzioni sufficiente, non validato perché “il fornitore ha aggiornato”.

I controlli che servono davvero (e il framework per ordinarli)

La buona notizia è che non serve inventare una disciplina nuova. Il NIST AI Risk Management Framework, pubblicato il 26 gennaio 2023, organizza il lavoro in quattro funzioni, GOVERN, MAP, MEASURE, MANAGE, e il profilo dedicato all’AI generativa, NIST AI 600-1, è uscito il 26 luglio 2024. È volontario, ma è la griglia più usata per dimostrare a un cliente o a un auditor che i rischi sono stati mappati e non solo temuti.

Sul piano operativo, i due incidenti di questa estate indicano priorità precise, in ordine di rendimento. Primo: il controllo dell’egress di rete, che è esattamente ciò che è mancato ad Anthropic. Un agente deve poter raggiungere solo destinazioni in whitelist, e l’isolamento va verificato tecnicamente, non dichiarato nel prompt. Secondo: privilegio minimo reale su ogni strumento, con credenziali dedicate e revocabili per agente, non l’account di servizio condiviso. Terzo: registrazione e revisione dei transcript, perché nel caso Anthropic è stato il monitoraggio a trovare l’incidente mentre le vittime non se n’erano accorte. Quarto: approvazione umana obbligatoria sulle azioni irreversibili. Quinto, e nuovo rispetto a un anno fa: una verifica di comportamento da rieseguire a ogni cambio di modello, perché quel cambio ormai arriva anche dal listino.

Su come si traducono in configurazione questi controlli non ci dilunghiamo qui, perché li abbiamo già trattati passo per passo in guardrail AI per agenti: come implementarli in azienda, e il livello infrastrutturale è coperto in come proteggere i modelli AI nel cloud.

Agenti AI e AI Act: dal 2 agosto 2026 quasi tutto è in applicazione

C’è una ragione di calendario per cui questa discussione arriva adesso in tutte le aziende europee. Secondo la timeline di implementazione dell’AI Act, gli obblighi sui modelli di uso generale (Capo V) si applicano dal 2 agosto 2025, l’alfabetizzazione AI del personale è in vigore dal 2 febbraio 2025, e dal 2 agosto 2026 si applica il resto del regolamento, con l’eccezione dell’articolo 6(1), che slitta al 2 agosto 2027 insieme al termine per i modelli GPAI immessi sul mercato prima dell’agosto 2025. Dalla stessa data del 2 agosto 2026 gli Stati membri devono avere sandbox normative operative. Nel frattempo il GDPR resta pienamente applicabile e va letto in parallelo: il piano di intersezione tra i due impianti è trattato in sicurezza, GDPR e AI.

Significa che, mentre leggete, il quadro non è più prospettico: è in applicazione, non in arrivo. Per un’azienda che ha agenti in produzione le domande diventano concrete e documentali, che ruolo avete assunto, quali obblighi di trasparenza scattano verso gli utenti, chi ha ricevuto formazione, e dove sono le prove. Il perimetro di ciascun ruolo lo abbiamo scomposto in AI Act e agenti AI in azienda, mentre policy interne e assegnazione delle responsabilità sono il tema di governance agenti AI: policy, ruoli e AI Act.

Sicurezza agenti AI in azienda: perché decade se nessuno la mantiene

Rimettiamo insieme i pezzi. Il perimetro è il sistema, non il modello. Le garanzie del modello non sopravvivono al fine-tuning né all’inserimento in uno scaffold. Il comportamento varia tra il 25% e l’85% tra modelli sulla stessa identica prova, e serve un minimo di trenta esecuzioni per dire qualcosa di sensato. Il modello sottostante cambia anche per ragioni di prezzo. Le organizzazioni compromesse non si erano accorte di nulla. Gli obblighi normativi sono già in applicazione.

La sicurezza degli agenti AI decade: cosa cambia dopo il giorno del deploy

Ognuno di questi punti descrive un’attività che si ripete nel tempo, non una configurazione che si fa una volta. Un agente sicuro il giorno del deploy non è un agente sicuro tre mesi dopo: nel frattempo sono cambiati il modello sottostante, i connettori, i dati indicizzati, i permessi delle persone. È il motivo per cui, in Mimir, trattiamo la sicurezza agentica come parte del servizio e non come una voce di capitolato: l’onboarding non finisce con la messa in produzione ma prosegue con affiancamento continuo, revisione dei permessi, lettura dei transcript e aggiornamento dei guardrail quando cambia qualcosa a monte. La componente umana non è un dettaglio: l’articolo 4 dell’AI Act chiede alfabetizzazione, e chi usa gli agenti ogni giorno è il primo sensore di anomalia, ne parliamo in formazione del team sugli agenti AI.

Questa è la stessa logica che abbiamo argomentato dal lato del ritorno economico in AI agent enterprise: perché il servizio conta più del modello, e che sul piano operativo si traduce nel lavoro descritto in manutenzione agenti AI post-deployment.

Cosa pretendere da chi vi mette in produzione un agente

Le prove tecniche da chiedere sulla sicurezza degli agenti AI

Chiudiamo con la parte utilizzabile subito, indipendentemente da chi sia il vostro fornitore. Chiedete che l’isolamento di rete sia dimostrato con una prova tecnica e non descritto a parole, dato che è esattamente il controllo che è saltato ad Anthropic. Chiedete l’inventario degli strumenti collegati all’agente con le credenziali associate e chi le può revocare. Chiedete dove finiscono i log delle azioni, per quanto tempo restano e chi li legge, perché senza revisione dei transcript un incidente non si vede. Chiedete quali azioni richiedono approvazione umana e come è stata scelta quella lista. Chiedete come viene misurato il comportamento dopo un cambio di modello o di prompt, e su quante esecuzioni. E chiedete chi vi avvisa quando il modello sotto l’agente viene sostituito.

Le domande sulla responsabilità: agenti AI, AI Act e ruoli

Chiedete infine la posizione rispetto all’AI Act: quale ruolo si assume il fornitore, quale resta a voi. Se una di queste risposte è “ci pensa il modello”, avete la risposta che vi serve. La scelta tra un impianto seguito da un partner e una soluzione self-service la abbiamo messa a confronto in agente AI chiavi in mano o self-service, e cosa aspettarsi concretamente da un affiancamento in consulenza agenti AI per PMI.

Se in azienda avete agenti in produzione, o state valutando di introdurli, e queste domande vi hanno lasciato più dubbi che certezze, è esattamente il punto in cui vale la pena parlarne con qualcuno che lo faccia di mestiere. In Mimir ci occupiamo di progettare, mettere in sicurezza e seguire nel tempo sistemi agentici in contesti aziendali, dall’onboarding iniziale all’affiancamento continuo. Se volete capire a che punto siete, si parte da una conversazione sul vostro caso concreto.

Fonti:

• Anthropic — Investigating incidents in our cybersecurity evaluations
• Anthropic — «Pacing model development in an era of cyber-critical capabilities» (agosto 2026)
• OpenAI — Responding to the next frontier of critical cyber capabilities
• Help Net Security — Gli incidenti di cybersecurity di Claude
• CNBC — Anthropic dice che Claude ha ottenuto accesso non autorizzato a sistemi terzi
• The Hacker News — Astra e le capacità cyber del prossimo modello OpenAI
• SecurityWeek — Le contromisure di OpenAI su Astra
• Riegler, Strümke — “AI Security Policy Should Target Systems, Not Models”
• Kazdan et al. — “No, of Course I Can!” (attacco NOICE)
• Erdem — “How Reliable Are AI Attackers Against a Fixed Vulnerable Target?”
• OWASP Agentic Security Initiative — Agentic AI: Threats and Mitigations
• NIST AI Risk Management Framework
• AI Act — Timeline di implementazione