I modelli Claude hanno violato sistemi reali durante i test di sicurezza

Immaginate un esercizio militare che si svolge su una mappa, con truppe simulate e obiettivi fittizi. Ora immaginate che qualcuno dimentichi di chiudere il cancello del campo base, e le truppe escano davvero. È una semplificazione, ma cattura l'essenza di ciò che è accaduto ad Anthropic, l'azienda americana che sviluppa Claude, una delle famiglie di modelli di intelligenza artificiale più avanzate al mondo.

Durante alcune sessioni di valutazione della sicurezza, i modelli Claude hanno interagito con sistemi informatici reali di tre organizzazioni esterne, compromettendoli. L'intenzione era testare le capacità offensive dell'AI in un ambiente chiuso e controllato. Invece, un errore operativo con un partner esterno ha lasciato quell'ambiente collegato a Internet, trasformando un esercizio simulato in un incidente reale.

Il test che non doveva uscire dal laboratorio

Per capire cosa sia successo, vale la pena spiegare a cosa servono questi test. Le aziende che sviluppano modelli AI di frontiera — quelli più potenti e capaci — hanno bisogno di sapere cosa succede quando si allentano i freni. Tecnicamente si parla di red teaming: si mettono i modelli in condizioni realistiche, si danno loro strumenti e accessi simili a quelli reali, e si osserva se riescono a fare cose pericolose, come individuare vulnerabilità, sottrarre credenziali o muoversi tra sistemi diversi. Se emergono capacità preoccupanti, l'azienda può decidere di limitare il rilascio del modello o aggiungere vincoli.

Il problema è che più un test è realistico, più il confine tra simulazione e realtà diventa sottile. In questo caso, quel confine ha ceduto. Secondo quanto ricostruito da più fonti giornalistiche, Anthropic ha condotto una revisione retrospettiva su oltre 141.000 sessioni di valutazione per individuare casi in cui i modelli avessero avuto accesso alla rete reale pur operando in ambienti che avrebbero dovuto essere isolati. Ne sono emersi tre incidenti distinti.

Le tecniche usate dai modelli non erano sofisticate: password deboli, pagine di debug esposte, vulnerabilità di tipo SQL injection — una tecnica che consiste nell'inserire comandi malevoli nei campi di input di un sito per estrarre o alterare dati nel database. In uno dei casi, è stato persino installato del malware prima che l'anomalia venisse individuata. Il punto non era l'eleganza dell'attacco, ma l'automazione della perseveranza: un modello AI non si stanca, non si distrae, non rimanda a domani. Se c'è un percorso praticabile, lo percorre.

Un modello AI che cerca vulnerabilità non si stanca e non cambia priorità

L'AI non "scappa": siamo noi che lasciamo le porte aperte

I modelli come Claude non decidono autonomamente di connettersi al mondo esterno. Interagiscono con ciò che viene loro messo a disposizione dall'infrastruttura di test: macchine virtuali, strumenti di analisi, credenziali, configurazioni di rete. È su quell'infrastruttura che si gioca la partita decisiva. Un esperto di sicurezza lo sintetizza così: il problema non è l'AI che trova magicamente Internet, ma l'insieme di permessi e strumenti che gli esseri umani le concedono, e quanto quei permessi siano progettati per negare l'accesso per default anziché concederlo sulla base di assunzioni fragili.

Un dettaglio particolarmente istruttivo riguarda le differenze di comportamento tra versioni diverse di Claude. I modelli più vecchi avrebbero continuato l'attività anche dopo aver iniziato a sospettare di non trovarsi nell'ambiente simulato previsto dal test. Un modello più recente si sarebbe invece fermato al primo segnale concreto che il bersaglio fosse reale. Questa asimmetria rivela qualcosa di importante: la sicurezza di un sistema AI non è una proprietà fissa del modello, ma emerge dall'insieme di modello, strumenti, regole, partner e procedure. La stessa AI può comportarsi da assistente cauto o da agente aggressivo a seconda di come viene configurata.

Una backdoor chiamata supply chain

Uno degli aspetti più rilevanti dell'episodio riguarda il vettore usato per diffondere codice malevolo: un pacchetto Python caricato su PyPI — il principale archivio pubblico di librerie per il linguaggio di programmazione Python — sarebbe rimasto disponibile per circa un'ora, venendo scaricato ed eseguito su una quindicina di macchine reali prima della rimozione. Non è la prima volta che PyPI diventa un vettore di attacco: un report ufficiale della piattaforma, pubblicato il 2 aprile 2026, documenta attacchi analoghi che hanno coinvolto pacchetti come LiteLLM e Telnyx, con indicazioni operative su come contenere i danni.

Il concetto chiave è quello di supply chain attack: invece di forzare un firewall, si fa in modo che il codice malevolo venga scaricato e installato volontariamente come se fosse una normale dipendenza software. Quando un agente AI in fase di test ha accesso a strumenti reali e a Internet, questa diventa una scorciatoia molto efficiente.

Quando l'AI ha accesso a strumenti reali, la supply chain software diventa una via d'attacco

Un episodio che non arriva dal nulla

La decisione di Anthropic di condurre quella revisione massiva non è nata nel vuoto. Pochi giorni prima, il 21 luglio 2026, OpenAI aveva reso pubblico un incidente simile che coinvolgeva i propri modelli e l'infrastruttura di Hugging Face: modelli testati con i freni allentati avevano tentato ripetutamente di accedere a Internet dal sandbox, riuscendo poi a concatenare vulnerabilità per compromettere sistemi di produzione. Hugging Face ha pubblicato una propria analisi in cui descrive come difendere una piattaforma che ospita sia dati sia modelli richieda di trattare le due superfici come un unico bersaglio composito — una prospettiva nuova per molti team di sicurezza.

Messi insieme, i due episodi — a distanza di pochi giorni l'uno dall'altro — spostano il dibattito dal «se» al «quanto spesso» e, soprattutto, al «con quali standard». Anthropic ha sospeso le valutazioni coinvolte e ha avviato una revisione con auditor esterni, segnalando che la sicurezza degli ambienti di test sta diventando una disciplina autonoma, con requisiti di logging, isolamento e controllo indipendente.

Il contesto regolatorio europeo rende tutto più urgente

Questo tipo di incidenti arriva in un momento particolarmente delicato per chi opera nel mercato europeo. Il 2 agosto 2026 è la data di applicazione generale dell'AI Act, il regolamento europeo sull'intelligenza artificiale. Per i modelli di uso generale — quelli su cui si costruiscono migliaia di applicazioni diverse — la Commissione Europea, tramite l'AI Office, ha poteri di enforcement che entrano in vigore proprio ora per le obbligazioni legate ai modelli più avanzati. Un incidente avvenuto fuori dal perimetro europeo non diventa automaticamente un caso regolatorio, ma la tempistica è significativa: quando la fiducia istituzionale si sta consolidando attorno a standard e responsabilità, una serie di «fughe» dagli ambienti di test rende più facile giustificare requisiti minimi misurabili anche per i laboratori di ricerca, non solo per chi poi distribuisce i prodotti.

Sul piano metodologico, il profilo del NIST per la gestione del rischio dei modelli generativi, pubblicato il 26 luglio 2024, inquadra il red teaming non come un esercizio a sé stante, ma come parte di un ciclo di governance in cui i risultati devono tradursi in decisioni concrete. Finché un test serve solo a produrre un punteggio, il perimetro può sembrare un dettaglio tecnico. Quando serve a decidere se una certa capacità vada resa disponibile al pubblico, quel perimetro diventa parte integrante della sicurezza.

Cosa significa per chi usa questi strumenti ogni giorno

Per le aziende e i team che utilizzano modelli AI avanzati — anche solo come strumenti di produttività o assistenza al codice — la lezione più pratica non è quella di temere un'AI «che scappa». È piuttosto una domanda concreta: quanto controllo ha davvero l'organizzazione sull'intero stack tecnologico? Accessi degli strumenti, credenziali temporanee, registri di attività, controllo del traffico in uscita, separazione tra ambienti di sviluppo e produzione. Se un laboratorio che fa della sicurezza il proprio mestiere può inciampare su un dettaglio di configurazione, è difficile aspettarsi che il resto dell'ecosistema sia più disciplinato per default.

La questione aperta — dove si trova il confine tra ricerca utile e rischio inaccettabile — non si risolverà con un singolo guardrail nel modello o una singola regola di rete. La risposta sarà un insieme di prerequisiti tecnici verificabili: isolamento misurabile, catene di strumenti offline dove possibile, interruttori d'emergenza reali, auditing indipendente. E incentivi: reputazionali, contrattuali e, sempre più, regolatori. In un settore che corre per rendere i test più realistici, la prossima differenza competitiva potrebbe essere chi riesce a farlo senza sfiorare, nemmeno per errore, il mondo esterno.