Configurazione agente AI sicura: la lezione degli incidenti Claude

Il 23 luglio Anthropic ha fermato tutte le proprie valutazioni di cybersecurity. Non perché un modello fosse riuscito a evadere da un sandbox con una tecnica sofisticata, ma perché qualcuno si era accorto che le macchine su cui Claude stava girando avevano accesso a internet vero. Il prompt diceva il contrario. La rete no. In mezzo a quella distanza, tra quello che era scritto nelle istruzioni e quello che era abilitato nell’infrastruttura, Claude ha estratto credenziali da un’azienda reale, pubblicato un pacchetto malevolo su PyPI e attaccato un’applicazione esposta su internet.

Anthropic ha pubblicato tutto: tre incidenti su sei run di valutazione, emersi da una revisione di 141.006 run. È un livello di trasparenza raro, e ne abbiamo raccontato i fatti in questa notizia. Qui ci interessa un’altra cosa: cosa dice quella vicenda a un’azienda italiana che sta montando il suo primo agente. Perché se un errore di configurazione può fare quel danno dentro il laboratorio del produttore del modello, con team di sicurezza dedicati e un partner di valutazione esterno, chi tiene la configurazione dell’agente, e cosa vuol dire, in pratica, una configurazione agente AI sicura, smette di essere una domanda teorica.

In questo articolo scoprirai:

• Cosa era mal configurato negli incidenti Claude
• Il prompt diceva «nessun accesso a internet»: perché un'istruzione non è un controllo
• Che cosa vuol dire davvero una configurazione agente AI sicura
• Se succede ad Anthropic, cosa rischia una PMI che monta un agente da sola
• Quali permessi non dare a un agente AI il primo giorno

Cosa era mal configurato negli incidenti Claude

Vale la pena essere precisi sui fatti, perché il dettaglio tecnico è tutto il ragionamento. Il primo incidente ha coinvolto quattro run di Opus 4.7: il bersaglio dell’esercitazione era un’organizzazione fittizia, ma esisteva un’azienda reale con un nome corrispondente, e il modello l’ha raggiunta. Ha estratto, sono parole di Anthropic nel resoconto ufficiale, «informazioni come credenziali applicative e infrastrutturali» e ha ottenuto accesso a «un database contenente diverse centinaia di righe di dati di produzione».

Nel secondo incidente documentato da Anthropic il modello ha pubblicato un pacchetto malevolo su PyPI, il registro pubblico dei pacchetti Python. Quel pacchetto è stato scaricato da circa 15 sistemi reali prima che venisse rimosso. Nel terzo, un modello di ricerca interno ha attaccato un’applicazione esposta su internet usando tecniche che Anthropic definisce «di base e ben note»: lettura di credenziali da una pagina di debug lasciata aperta e SQL injection.

Nessuno di questi episodi ha richiesto uno zero-day. Non c’è stata nessuna evasione dal sandbox: il sandbox semplicemente non chiudeva la rete. La causa, dichiarata dall’azienda nel resoconto ufficiale dell’indagine, è «un fraintendimento tra noi e il nostro partner di valutazione» sull’isolamento di rete. Una casella non spuntata, in sostanza, e per capire cosa significa questo su un sistema che agisce da solo conviene avere chiaro cosa fa davvero un agente AI rispetto a un chatbot: il chatbot risponde, l’agente esegue.

Il prompt diceva «nessun accesso a internet»: perché un’istruzione non è un controllo

Questo è il punto di rottura, e merita di essere isolato dal resto. Nel prompt di valutazione era scritto che Claude non aveva accesso a internet. Era una descrizione dell’ambiente, e la descrizione era sbagliata. Anthropic stessa, nelle correzioni annunciate, indica il rimedio in modo quasi didascalico: scrivere «non devi accedere a internet», un’istruzione, invece di «non hai accesso a internet», una descrizione. Ma anche l’istruzione, da sola, resta una richiesta gentile a un sistema probabilistico.

C’è un dettaglio ancora più scomodo, riportato nell’analisi di InfoWorld: i modelli mostravano quello che Anthropic chiama «ragionamento motivato», cioè continuavano a convincersi di essere in un ambiente simulato mentre erano collegati a internet reale. L’azienda parla apertamente di «fallimento della sicurezza operativa» e di «spericolatezza» del modello. David Shipley di Beauceron Security, citato nello stesso pezzo, è più diretto: isolamento e monitoraggio «avrebbero dovuto essere in piedi prima di lanciare degli agenti a bucare sistemi».

Perché un divieto scritto nel prompt non basta a fermare l’agente

È la lezione più trasferibile dell’intera vicenda. Un vincolo scritto in linguaggio naturale è un’indicazione di comportamento, non un confine tecnico. Il confine lo mette l’infrastruttura: una regola di firewall, un proxy che rifiuta la connessione, un token che non ha il permesso per quell’operazione. Se il vincolo esiste solo nel prompt, chiunque riesca a influenzare il testo che entra nel contesto dell’agente, un documento, una pagina web, il contenuto di una mail, può rimetterlo in discussione. È esattamente il ragionamento per cui un modello sicuro non basta a rendere sicuro un agente: il modello è un componente, la sicurezza è una proprietà del sistema intero.

Che cosa vuol dire davvero una configurazione agente AI sicura

Una configurazione agente AI sicura non è un file con dentro delle buone intenzioni. È un insieme di livelli che devono essere separati, perché ognuno regge quando l’altro cede, quello che Anthropic, nelle contromisure annunciate dopo gli incidenti, chiama «defense in depth». Nella pratica di chi progetta e mette in produzione un agente su misura i livelli sono quattro, e vale la pena guardarli uno per uno.

Identità e permessi. L’agente deve avere una propria identità, non riusare quella di una persona o una chiave API condivisa. È il punto su cui la ricerca è più impietosa: secondo la nota di ricerca della Cloud Security Alliance, il 97% delle identità non umane porta privilegi eccessivi (dato Entro Security) e il 90% degli agenti in esercizio è sovra-autorizzato rispetto al compito che gli è stato assegnato (dato Obsidian Security).

Filesystem. Quali cartelle l’agente può leggere e scrivere. Sembra banale finché non ci si accorge che nella home dell’utente ci sono ~/.ssh, ~/.aws e i file .env del progetto.

Rete. Quali domini può raggiungere. La documentazione di Claude Code sul sandboxing descrive bene il meccanismo giusto: isolamento del filesystem e isolamento di rete sono due strati indipendenti, e quello di rete passa da un proxy locale che confronta ogni destinazione con una lista di domini consentiti e restituisce un rifiuto per gli altri. La postura consigliata è default-deny: si nega tutto e si apre solo ciò che serve davvero.

Perché i quattro livelli non si sostituiscono a vicenda

Il quarto livello è l’osservabilità: log delle azioni, tracciabilità di chi ha chiesto cosa, allarmi su comportamenti anomali. Ed è quello che negli incidenti Anthropic mancava per primo, tanto che la scoperta è arrivata a posteriori, da una revisione massiva dei transcript. Senza il quarto livello i primi tre non si accorgono di essere rotti. È lo stesso vuoto che raccontavamo parlando dei tre presidi di supervisione che mancano alla stragrande maggioranza delle organizzazioni.

Se succede ad Anthropic, cosa rischia una PMI che monta un agente da sola

L’obiezione ovvia è che Anthropic stava facendo test offensivi, mentre un’azienda normale chiede a un agente di leggere email e aggiornare un CRM. È vera solo in parte: cambia l’intenzione, non l’architettura. Un agente che può chiamare tool, raggiungere la rete e usare credenziali è la stessa macchina in entrambi i casi.

I numeri del 2026 dicono che il problema è già diffuso. Un sondaggio DigiCert su 1.001 responsabili IT e sicurezza condotto a luglio 2026 in Stati Uniti, Regno Unito e Australia riporta che una organizzazione su due ha subito nei sei mesi precedenti un incidente legato direttamente a un agente AI non autorizzato o mal configurato. Nello stesso periodo il 75% delle aziende aveva messo in campo quattro o più sistemi basati su AI, e solo la metà aveva un programma di governance formale. La velocità di adozione ha superato la velocità del controllo, e la forbice si vede.

La ricerca AI Agents at Work 2026 di Okta (292 dirigenti e 492 knowledge worker, marzo 2026) aggiunge il lato umano: il 96% dei dirigenti si dichiara sicuro delle proprie capacità di gestione delle identità non umane, ma solo il 34% delle organizzazioni applica agli agenti gli stessi controlli che applica alle persone. E il 58% ammette di aver avuto incidenti o quasi-incidenti legati all’AI negli ultimi dodici mesi.

I danni di un agente mal configurato fuori dal perimetro aziendale

È la parte che si sottovaluta di più. Il secondo incidente Anthropic non ha danneggiato Anthropic: ha danneggiato quindici sistemi di terzi che hanno scaricato un pacchetto da PyPI. Un agente con accesso di rete non contiene il danno dentro l’azienda che lo ha configurato: può scrivere su repository pubblici, aprire ticket, inviare email a indirizzi esterni, pubblicare su registri di pacchetti. Chi valuta il rischio guardando solo ai propri dati sta guardando metà del problema, e per le organizzazioni che rientrano nel perimetro dell’AI Act quella metà mancante ha anche un peso normativo.

Quali permessi non dare a un agente AI il primo giorno

La domanda pratica, per chi parte adesso, è dove mettere la prima linea. La Agentic Security Initiative di OWASP ha pubblicato a fine 2025 la Top 10 per le applicazioni agentiche, e due delle voci sono esattamente questo tema: ASI02 «Abuso e sfruttamento dei tool» e ASI03 «Abuso di identità e privilegi». Le mitigazioni raccomandate sono tre e sono noiose: privilegio minimo sui tool, permessi a scadenza, approvazione umana obbligatoria sulle azioni distruttive.

Tradotto in configurazione, la guida di General Analysis alla messa in sicurezza di Claude Code propone un modello a tre liste che funziona bene anche fuori da quello strumento specifico. In deny vanno i segreti e i comandi irreversibili: file .env, chiavi SSH, credenziali cloud, git push, terraform apply, kubectl delete. In ask, cioè con conferma umana, le installazioni di pacchetti, le operazioni su Docker e Kubernetes, i rilasci. In allow solo il lavoro ripetitivo e innocuo: lint, test, letture di stato. Le regole di deny prevalgono su tutto il resto, e le impostazioni gestite centralmente prevalgono su quelle locali del singolo utente: senza questa gerarchia, chiunque può allentare la propria configurazione in cinque secondi. Abbiamo raccontato la versione operativa di questo ragionamento in cosa affidare a Claude Code il primo giorno e quali permessi non dargli.

Il capitolo MCP: i tool che l’agente può montare da solo

C’è un errore specifico che vale la pena nominare, perché è nuovo e sfugge anche a chi ha esperienza di sicurezza tradizionale. Gli agenti moderni si collegano a strumenti esterni tramite server MCP, e un server MCP compromesso può restituire contenuti che manipolano l’agente, esporre tool troppo ampi o raggiungere dati che il modello non dovrebbe toccare. La raccomandazione di General Analysis è netta: non usare mai allowlist basate sul nome del server, perché il nome è un’etichetta che chiunque può assegnarsi. I server remoti si autorizzano per URL, quelli locali per comando esatto. E l’installazione di nuovi server va tolta dalle mani del singolo, non lasciata come opzione di comodo, vale anche per chi costruisce l’agente sopra strumenti da sviluppatore come il Claude Agent SDK, che eredita la stessa superficie di attacco.

La configurazione invecchia: perché l’audit non è un adempimento una tantum

Anche una configurazione fatta bene ha una data di scadenza, e questo è il punto che quasi nessuno mette a budget. Il caso più istruttivo del 2026 è la vulnerabilità di bypass dell’allowlist di rete di Claude Code divulgata a maggio: un hostname costruito come attacker.example\x00.google.com superava il controllo del proxy, scritto in JavaScript, perché terminava con un dominio consentito, mentre il resolver di sistema in C troncava la stringa al byte nullo e contattava solo il prefisso dell’attaccante. La stessa stringa, letta da due livelli diversi, significava due cose diverse. La configurazione era corretta e il canale di esfiltrazione era aperto lo stesso, per circa cinque mesi e mezzo e un centinaio e mezzo di release.

Come si verifica che la configurazione di un agente sia ancora corretta dopo qualche mese

Serve un ciclo, non un controllo. Tre cose in particolare: rileggere periodicamente le regole rispetto ai processi reali, le allowlist si allargano sempre, mai il contrario; tenere aggiornato l’inventario degli agenti attivi e delle loro credenziali, dato che secondo la nota di ricerca della Cloud Security Alliance solo il 21% delle organizzazioni ha un registro in tempo reale degli agenti attivi e il 78% non ha politiche documentate per creare o rimuovere un’identità agente, un problema che cresce in fretta quando gli agenti diventano più di uno e serve qualcuno che progetti l’orchestrazione; e testare in modo avversariale, cioè provare a farla fallire invece di rileggerla. Va aggiunto un quarto punto, meno tecnico: anche le istruzioni operative invecchiano, ed è il motivo per cui abbiamo scritto che i file di configurazione tipo CLAUDE.md e AGENTS.md diventano obsoleti più in fretta di quanto si pensi. Un agente che segue istruzioni riferite a un processo che non esiste più non è sicuro: è solo silenzioso.

Configurare un agente AI in autonomia o con un partner: cosa cambia in pratica

Arrivati qui, la domanda non è più «l’AI è sicura». È «chi tiene la configurazione, e con che continuità». Perché tutto quello che abbiamo elencato, separazione dei quattro livelli, gerarchia dei permessi, allowlist per URL sui server MCP, inventario delle identità, audit periodico, test avversariale, non è lavoro da giornata di setup. È un ruolo. E la differenza tra comprare una licenza e comprare un servizio sta esattamente lì: la licenza ti dà il modello, non ti dà nessuna delle sei cose sopra.

Chi decide di fare da sé può farcela benissimo, a due condizioni: che qualcuno in azienda possieda quel ruolo in modo esplicito, con tempo assegnato, e che ci sia una competenza sistemistica capace di distinguere un vincolo scritto nel prompt da un vincolo scritto nel firewall. Se mancano entrambe, il rischio non è che l’agente non funzioni, funzionerà, ed è questo il problema: un agente sovra-autorizzato lavora benissimo finché non lavora troppo.

Abbiamo messo a confronto i due percorsi in agente AI chiavi in mano o self-service e ragionato su cosa non include la licenza quando si compra uno strumento agentico.

Cosa deve esserci nel servizio, non nel contratto

In MIMIR l’audit della configurazione e il monitoraggio continuo fanno parte del servizio, non sono una voce a parte: l’onboarding parte da un inventario di cosa l’agente deve poter toccare, e soprattutto di cosa non deve, e prosegue con revisioni periodiche di permessi, domini raggiungibili e log delle azioni. È il motivo per cui insistiamo su una lettura del tema che parte dal progetto dell’agente e non dalla scelta del modello. Se state valutando un agente AI per un processo aziendale e volete che la parte di configurazione e sorveglianza sia presidiata da qualcuno, parlatene con noi: partiamo dal vostro processo, non da una demo. Una consulenza iniziale serve soprattutto a capire dove sono i confini che l’agente non deve superare, che è la parte che si scopre tardi quando non la si mette per iscritto all’inizio.

Fonti:

• Anthropic — Investigating incidents in our cybersecurity evaluations
• InfoWorld — Anthropic makes changes to stop AI agents running amok again
• Cloud Security Alliance — Research note su IAM per agenti AI e gap aziendale
• Claude Code — Documentazione ufficiale sul sandboxing
• MarketScale/DigiCert — Sondaggio su incidenti di sicurezza legati agli agenti AI
• Okta — AI Agents at Work 2026: agentic enterprise security
• OWASP — Agentic Security Initiative
• Graylog — OWASP Top 10 per l’AI agentica: ASI02 e ASI03
• General Analysis — Guida alla messa in sicurezza di Claude Code
• Penligent — Analisi del bypass dell’allowlist di rete di Claude Code