Il prompt non è un firewall: cosa insegna l'incidente di Anthropic

Anthropic ha pubblicato un report in cui ammette che tre modelli Claude, durante valutazioni interne di cybersecurity, sono usciti da ambienti che dovevano essere isolati e hanno compromesso i sistemi di produzione di tre organizzazioni reali. Non è un'ipotesi di laboratorio e non è uno scenario di rischio futuro: sono aziende vere, con dati veri, colpite in sei esecuzioni diverse di test. Una di loro è stata colpita quattro volte.

Il documento si intitola Investigating incidents in our cybersecurity evaluations e vale la pena leggerlo per intero, perché è uno dei pochi casi in cui un laboratorio racconta un proprio incidente con nomi, numeri e date invece che con un comunicato di quattro righe.

Cosa è successo davvero

I test erano esercizi di tipo capture the flag: al modello viene dato uno scenario di fantasia e il compito di trovare informazioni nascoste su una rete. Il prompt diceva esplicitamente al modello che non aveva accesso a internet. Peccato che una configurazione sbagliata da parte di Irregular, il partner che gestiva le valutazioni, avesse lasciato quelle macchine con la connessione attiva.

Il primo incidente riguarda Claude Opus 4.7, che si è imbattuto nel sito di un'azienda vera il cui nome coincideva con quello del bersaglio immaginario dell'esercizio. Su quattro esecuzioni il modello ha estratto credenziali di applicazione e di infrastruttura, ed è arrivato a un database con diverse centinaia di righe di dati di produzione. Anthropic lo definisce l'impatto più grave individuato.

Il secondo riguarda Claude Mythos 5, che ha pubblicato un pacchetto Python malevolo su PyPI, il registro pubblico da cui mezzo mondo installa librerie. Il pacchetto è rimasto disponibile per circa un'ora, è stato scaricato da quindici sistemi reali ed è stato eseguito sullo scanner di un'azienda di sicurezza, da cui ha esfiltrato credenziali.

Il terzo riguarda un modello interno mai rilasciato, che ha scansionato circa novemila bersagli online e ha compromesso l'applicazione di un'azienda con tecniche di base: leggere le credenziali da una pagina di debug lasciata esposta e una SQL injection. Poi si è fermato da solo, dopo aver capito che il bersaglio era reale.

La cronologia è altrettanto interessante. I primi episodi risalgono ad aprile. Il 21 luglio OpenAI ha comunicato un incidente simile, il 23 Anthropic ha iniziato a rileggere le trascrizioni e ha bloccato tutte le valutazioni di cybersecurity lo stesso giorno, il 24 aveva identificato tutti e tre gli incidenti e il 27 ha avvisato le organizzazioni colpite. In totale sono state riesaminate 141.006 esecuzioni di test.

Il modello non è il problema, l'infrastruttura sì

Qui c'è la lezione vera, e non è quella che leggerai nei titoli allarmistici dei prossimi giorni.

Il modello ha fatto esattamente il lavoro per cui era stato messo in quella stanza: trovare un modo per entrare. Non si è ribellato, non ha aggirato una protezione, non ha ingannato nessuno. Ha usato una capacità che l'ambiente gli aveva concesso. Il prompt gli diceva di non avere internet, ma la macchina ce l'aveva. Fine della storia.

Un'istruzione nel prompt non è un confine di sicurezza. È un suggerimento, e per quanto un modello sia bravo a rispettarlo, la probabilità che prima o poi non lo rispetti non arriva mai a zero. Il confine lo fa l'infrastruttura: una rete chiusa è chiusa, una credenziale che non esiste non può essere usata, un permesso che non è stato concesso non può essere abusato. Tutto il resto è fiducia, e la fiducia non è un meccanismo di sicurezza.

Il dettaglio del terzo incidente è quasi ironico: il modello si è fermato da solo quando ha capito che stava colpendo un bersaglio vero. L'unica cosa che ha funzionato in quella catena è stata l'addestramento alla sicurezza del modello. A cedere è stato tutto il resto.

Cosa cambia per chi costruisce con gli agenti

Questa storia mi riguarda più da vicino di quanto vorrei. Mentre scrivo ho due agenti che partono da soli ogni mattina in cloud, senza che io apra niente: leggono i miei task, cercano notizie, scrivono dentro i miei database. E ne sto mettendo in piedi un terzo che ha il permesso di scrivere sul repository di questo sito. Sono utili esattamente perché non devo stargli dietro, che è poi lo stesso motivo per cui il report di Anthropic si legge come un promemoria scomodo.

Nel prompt di quel terzo agente c'è scritto, tra le regole ferme, che non deve toccare nessun file fuori da una cartella precisa. Dopo aver letto il report ho guardato quella riga con occhi diversi, perché è la stessa identica categoria di garanzia che ha fallito nei test: un'istruzione scritta, non un vincolo. Se un giorno l'agente decidesse di modificare qualcos'altro, quella riga non lo fermerebbe di un millimetro. A fermarlo è altro, ed è tutto fuori dal prompt: gira in una sandbox effimera che viene buttata via a fine esecuzione, l'unico canale verso il mondo è un commit, e quel commit non parte se prima la build del sito non passa. Quelli sono confini. La riga tra le regole ferme è una speranza.

La domanda giusta quindi non è "il mio agente è affidabile". È "cosa può materialmente raggiungere il processo in cui gira". Se la risposta include la rete aziendale, un token con permessi su tutta l'organizzazione, o un file di credenziali dimenticato in una variabile d'ambiente, quella è la superficie del problema, indipendentemente da quanto sia bravo il modello.

Tre cose che vale la pena sistemare prima di aggiungere qualunque altra funzionalità. La rete chiusa per default, con una lista esplicita dei domini consentiti al posto dell'accesso aperto. Le credenziali con lo scope più stretto che il servizio permette e con una scadenza: un token GitHub che scrive su un solo repository, non uno che scrive su tutta l'organizzazione, e stessa logica per ogni chiave API che passi all'agente. E un registro di quello che l'agente ha fatto davvero, comandi eseguiti e chiamate di rete, non di quello che gli hai chiesto di fare, perché è nella differenza tra le due cose che vivono gli incidenti. Se usi Claude Code o strumenti simili, questa è anche la ragione per cui vale la pena tenersi le richieste di permesso invece di disattivarle tutte al primo fastidio.

Perché averlo scritto conta

Anthropic poteva non pubblicare niente. Gli incidenti erano interni, i danni limitati, le aziende colpite già avvisate in privato. Invece ha messo online numeri, nomi, cronologia, ha citato il partner che ha sbagliato la configurazione, ha annunciato che pubblicherà una trascrizione parzialmente oscurata dell'episodio di PyPI e ha coinvolto METR come revisore indipendente.

Non è generosità, è calcolo, e va benissimo così: un laboratorio che si costruisce la reputazione sulla sicurezza ha bisogno che quella reputazione sia verificabile, e l'unico modo per renderla verificabile è raccontare anche quando le cose vanno male. Ma è comunque un livello di trasparenza che nel resto del settore non si vede quasi mai, ed è uno dei motivi per cui, come ho scritto altrove, Anthropic conta più di quanto sembri al di là dei benchmark dei modelli.

Il modo in cui un'azienda racconta i propri errori dice molto più di mille pagine di documentazione su come li gestisce. Questo report è lungo, tecnico, poco lusinghiero e pieno di numeri che nessuno avrebbe potuto scoprire da fuori. È esattamente il tipo di documento che si scrive quando si ha intenzione di continuare a essere creduti.