Agenti di IA fuori controllo: tre episodi in quattordici giorni

Nel giro di quattordici giorni, OpenAI, Anthropic e l’AI Security Institute (AISI) britannico hanno reso noto che, nel corso di verifiche interne sulla sicurezza, alcuni agenti di IA sono usciti dal quadro di test previsto e hanno interagito con sistemi reali e persone reali. Più che i singoli casi, ciò che colpisce è la rapidità con cui si stanno sviluppando le capacità di questi agenti – e il fatto che, in uno dei casi, a impedire il danno non sia stato un controllo tecnico, bensì l’attenzione umana.

L'incidente sotto la lente d'ingrandimento

All'inizio di agosto 2026, l'AISI ha pubblicato un rapporto sulla fuga di agenti di IA dagli ambienti di test. Nel corso di un test di routine, un agente di IA ha individuato i responsabili di un progetto open source di uso pubblico, ha creato sulla base di tali informazioni diverse identità online false e ha tentato di indurre un responsabile reale, tramite tali identità, a rilasciare codice dannoso – un classico approccio di ingegneria sociale, simile a quello solitamente descritto dagli aggressori umani in scenari relativi alla catena di approvvigionamento.

Ciò che colpisce non è tanto la tecnica in sé, quanto piuttosto la genesi di questo comportamento: nessuno aveva dato all’agente l’ordine di ingannare. Né gli era stato espressamente vietato di utilizzare tecniche di ingegneria sociale o l’accesso libero a Internet per tali scopi: finora una restrizione di questo tipo sembrava superflua nei modelli con addestramento all’allineamento.

Nell’ambito di questa indagine, l’AISI ha testato due cosiddetti «cyber-range» – reti controllate e simulate che riproducono ambienti reali – utilizzando sette diversi modelli in un totale di 122 cicli di test. In dieci di questi cicli, un agente ha agito al di fuori dell’ambito di test prestabilito; sono state documentate 19 azioni singole, di cui 17 riconducibili a Mythos 5 di Anthropic e due a un unico ciclo con GPT-5.6 Sol di OpenAI. L’elenco completo è disponibile nel rapporto tecnico dell’AISI all’indirizzo https://www.aisi.gov.uk.

Nel valutare questi dati è indispensabile tenere conto di due condizioni di riferimento: l’accesso a Internet era stato attivato intenzionalmente e i classificatori informatici dei fornitori dei modelli – ovvero quei meccanismi di filtraggio destinati a impedire comportamenti rischiosi – erano stati disattivati intenzionalmente. Entrambe queste misure servono a determinare le massime prestazioni di un modello e, espressamente, non corrispondono alla configurazione in cui tali modelli sono messi a disposizione degli utenti finali. Non si è verificata alcuna fuga dalla sandbox. Finora l’AISI non ha riscontrato danni dimostrabili nel mondo reale, ma fa riferimento a singoli effetti limitati in circostanze circoscritte.

Tre comunicazioni in quattordici giorni

Si tratta della terza divulgazione di questo tipo nel giro di quattordici giorni, e il confronto tra i tre casi è istruttivo, poiché le cause sono diverse in ciascuno di essi.

Il 21 luglio 2026, OpenAI ha reso noto che due modelli erano riusciti a sfuggire da un ambiente di test isolato sfruttando una vulnerabilità fino ad allora sconosciuta e avevano successivamente compromesso l’infrastruttura operativa di Hugging Face. Da notare in questo caso la modalità di individuazione: Hugging Face aveva individuato l’attacco autonomamente e lo aveva segnalato alle autorità giudiziarie prima che OpenAI potesse stabilire il collegamento con la propria sessione di valutazione.

Il 30 luglio 2026 è stata la volta di Anthropic. Da un'analisi retrospettiva di 141’006 cicli di valutazione sono emersi tre episodi in cui i modelli Claude – nello specifico Opus 4.7, Mythos 5 e un modello di ricerca interno – hanno ottenuto l'accesso non autorizzato all'infrastruttura operativa di tre organizzazioni reali; il primo di questi episodi risale all’aprile 2026. La causa non è stata un exploit, bensì un malinteso tra Anthropic e il partner di valutazione esterno: le macchine utilizzate nel test disponevano di un accesso attivo a Internet, sebbene il prompt indicasse espressamente al modello il contrario. La vera e propria intrusione nelle organizzazioni interessate è avvenuta successivamente con mezzi estremamente semplici, ovvero tramite password deboli ed endpoint non autenticati. Le due organizzazioni che Anthropic è riuscita a contattare non si erano accorte dell’attività.

Il problema non sono i singoli casi, ma la velocità

Un agente di intelligenza artificiale che inventa identità false per indurre una persona a divulgare codici dannosi era, fino a poco tempo fa, oggetto di trattati scientifici; l’AISI descrive espressamente questa forma di inganno mirato come un comportamento che finora era rimasto in gran parte teorico. Ora ne esiste una documentazione concreta.

Un dettaglio del rapporto Anthropic merita particolare attenzione: i tre modelli in questione hanno reagito in modo diverso quando sono emersi indizi di un ambiente reale. Opus 4.7, il più vecchio dei tre, ha proseguito l’attacco nonostante avesse riconosciuto i sistemi di produzione come tali. Mythos 5, nonostante la correttezza della propria valutazione intermedia, è tornato a partire dal presupposto di continuare a operare in una simulazione. Il modello di ricerca interno più recente ha interrotto il processo.

Questa è, in un primo momento, una buona notizia, poiché il modello più recente ha reagito nel modo più adeguato. Per l’architettura di sicurezza, tuttavia, ciò comporta l’esatto contrario di un alleggerimento: la capacità di compromettere un sistema cresce più rapidamente della capacità di valutare correttamente la propria situazione. Non è quindi possibile basare un controllo sulla valutazione della situazione da parte di un agente, poiché si tratta di un comportamento e non di una caratteristica di sicurezza.

È positivo che tutti e tre gli incidenti siano stati individuati, contenuti e successivamente resi noti. I meccanismi di allerta precoce funzionano quindi, e permangono margini di tempo per adottare contromisure. Resta da vedere se questa forma di difesa sia in grado di stare al passo con l’evoluzione della minaccia e se le organizzazioni interessate, nel loro complesso, siano in grado di reagire con la stessa rapidità con cui ricevono gli avvisi.

In questo contesto, vale la pena esaminare attentamente la questione di cosa abbia effettivamente bloccato l’attacco nel caso AISI. L’attacco è stato individuato tramite monitoraggio tecnico, ma a valle e sulla base di un traffico di rete anomalo, non attraverso un controllo all’interno della stessa valutazione. A bloccarlo è stata una persona: il manutentore, che ha verificato e respinto la pull request. A ciò si è aggiunto un soggetto esterno che ha aperto il codice sospetto in un ambiente isolato. In questo caso, l’attenzione umana e le buone pratiche consolidate hanno funzionato. Tuttavia, entrambe queste misure non sono scalabili contro un aggressore che opera senza sosta e non si stanca mai.

Implicazioni pratiche

Lo stesso AISI trae tre insegnamenti rivolti principalmente ai valutatori: controlli di rete altamente granulari anziché un accesso a Internet concesso in modo indiscriminato, un monitoraggio che osservi la valutazione in corso in tempo reale, nonché un disegno di valutazione che tenga conto fin dall’inizio della possibilità che un modello performante esuli dal proprio ambito.

Per le organizzazioni al di fuori di questa cerchia, la raccomandazione dell’AISI risulta decisamente più sobria e, nella sostanza, non è una novità: basi solide per la sicurezza informatica e una verifica rigorosa del codice e dei contributi esterni. Inoltre, l’AISI raccomanda di integrare la sicurezza informatica tra le priorità del consiglio di amministrazione e di esigere standard minimi lungo l’intera catena di fornitura.

Thomas Boele, Global Director Solutions Engineering – AI Security presso Check Point, suddivide le misure necessarie in tre ambiti di intervento: protezione dagli attacchi guidati dall’IA, poiché gli aggressori dispongono delle stesse capacità che questi test mettono in luce; controllo sulla propria IA, poiché i responsabili della sicurezza devono sapere quali agenti sono in funzione all’interno dell’organizzazione, a cosa possono accedere e quali azioni sono loro consentite; nonché verifica continua anziché presupposto, poiché il comportamento corretto di agenti e chatbot deve essere verificato costantemente e non dato per scontato.

Per gli agenti di IA già in uso produttivo, Boele consiglia di partire da quattro domande fondamentali: quali agenti sono attualmente in funzione, compresi quelli creati da persone che non ricoprono un ruolo di sviluppatore? A cosa può accedere ciascuno di questi agenti? Di quali autorizzazioni dispone ogni agente che vanno oltre quelle originariamente previste? E una deviazione da questo quadro verrebbe überhaupt notata? Se la risposta all’ultima domanda è «no», è proprio questa la lacuna da colmare per prima.

Fonte: www.checkpoint.com

Questo articolo è apparso originariamente su m-q.ch - https://www.m-q.ch/de/ki-agenten-ausser-kontrolle-drei-vorfaelle-in-vierzehn-tagen/