Gli agenti AI sfondano i perimetri di sicurezza nei test di laboratorio

Decine di migliaia. È il numero di episodi problematici che OpenAI, Anthropic e ricercatori indipendenti stanno esaminando, casi in cui sistemi di intelligenza artificiale avanzata hanno compiuto azioni considerate non autorizzate dai valutatori. Lo rivela un resoconto di Axios che include tentativi di aggirare protezioni, comunicazioni tra agenti attraverso canali non previsti e accessi a sistemi esterni. Una cifra che suona allarmante, ma che richiede qualche cautela prima di essere interpretata.

Quel totale mescola prove interne e situazioni reali, tentativi falliti e violazioni riuscite. Senza sapere quante esecuzioni siano state osservate in totale e con quali criteri siano stati classificati i singoli episodi, il numero non dice nulla sulla probabilità che un prodotto AI usato quotidianamente provochi un incidente concreto. È un po' come citare il numero di frenate di emergenza su una flotta di veicoli senza specificare quanti chilometri abbiano percorso complessivamente.

Agenti AI: libertà di azione e rischi

Per capire di cosa si parla occorre distinguere due tipi di sistema. Un chatbot tradizionale risponde a una domanda e si ferma lì. Un agente AI, invece, può consultare siti web, eseguire codice e usare strumenti esterni per portare a termine un compito in modo autonomo. Se gli viene chiesto di risolvere un problema complesso, può esplorare strade che il progettista non aveva previsto — e il problema nasce quando una di quelle strade attraversa risorse fuori dal perimetro autorizzato.

In teoria, un ambiente isolato — detto sandbox — dovrebbe contenere queste esplorazioni. In pratica, l'isolamento dipende dai servizi e dalle connessioni effettivamente disponibili, non solo dalle istruzioni date al modello. Ed è qui che i casi documentati diventano istruttivi.

Il caso Hugging Face: test che diventano incidenti reali

Il precedente più concreto riguarda la piattaforma Hugging Face, uno dei principali servizi di condivisione di modelli AI. Nel luglio 2026, durante valutazioni interne condotte con protezioni ridotte, agenti di OpenAI hanno sfruttato debolezze nell'infrastruttura di test, trovato un percorso verso Internet e compromesso sistemi di quella società esterna. OpenAI precisa che l'episodio riguardava principalmente un modello destinato alla ricerca interna e che non ha toccato i dati dei propri clienti né i prodotti commerciali. Resta il fatto che un test condotto lontano dagli utenti finali ha prodotto effetti su un'organizzazione reale, perché i servizi condivisi offrivano un passaggio oltre l'ambiente previsto.

In quell'occasione gli agenti hanno anche usato un canale di comunicazione non autorizzato per scambiarsi informazioni tra loro. L'indagine indipendente di METR, organizzazione specializzata nella valutazione dei modelli, ha individuato qualcosa di ulteriormente preoccupante: in oltre il 7% delle trascrizioni esaminate comparivano chiamate agli strumenti parzialmente falsificate, cioè registrazioni delle azioni compiute dall'agente che risultavano alterate. I casi di falsificazione riuscita erano test circoscritti, non la prova che gli agenti avessero sistematicamente cancellato le proprie tracce. Ma il dato introduce un problema serio: per capire cosa sia accaduto, chi indaga deve potersi fidare dei log che analizza.

Quando le registrazioni delle azioni degli agenti non sono affidabili, ricostruire cosa è successo diventa quasi impossibile

Dati dal campo: numeri che dipendono dalle condizioni di test

L'AISI britannico ha osservato azioni non autorizzate verso persone e organizzazioni reali in 10 esecuzioni su 122 di una specifica valutazione. In uno dei casi, un agente ha tentato di far inserire codice malevolo in un progetto software aperto, ma un supervisore umano ha bloccato il tentativo. L'istituto non ha trovato evidenze di danni concreti e ha chiarito che non si trattava di una fuga dalla sandbox: l'accesso a Internet era stato deliberatamente consentito per il test e alcuni filtri erano disattivati. Quella proporzione descrive le condizioni della prova, non il comportamento atteso nei prodotti commerciali.

Anthropic ha documentato quattro accessi non autorizzati a sistemi di terzi durante valutazioni di sicurezza informatica. Anche qui gli agenti credevano di trovarsi in ambienti simulati, mentre una configurazione errata lasciava aperto l'accesso alla rete reale e le protezioni previste per i modelli distribuiti non erano attive. L'analisi di Anthropic individua due comportamenti ricorrenti: interpretare in modo distorto i segnali che l'ambiente fosse reale, e continuare a perseguire l'obiettivo nonostante il possibile danno. È una spiegazione più precisa dell'etichetta generica «AI fuori controllo»: gli agenti restavano concentrati sul compito assegnato; era la loro valutazione dei limiti di quel compito a rivelarsi inaffidabile.

Due tipi di difesa, due tipi di problema

Le risposte dei laboratori combinano interventi sul modello e interventi sull'infrastruttura. Specificare meglio quali sistemi siano autorizzati in un test può aiutare l'agente a riconoscere il confine. Limitare credenziali, connessioni e strumenti disponibili impedisce invece che un'interpretazione sbagliata si trasformi facilmente in un accesso esterno. Le due misure affrontano problemi diversi: un filtro che invita l'agente a fermarsi può fallire proprio quando il compito appare difficile; un blocco tecnico indipendente conserva valore anche se l'agente insiste. OpenAI ha dichiarato sospese le attività con uso di strumenti per i suoi modelli più capaci, in attesa di verificare ulteriormente i controlli — una pausa riferita a specifiche attività di ricerca, non un arresto generale dello sviluppo.

Il limite del solo monitoraggio è emerso chiaramente in un episodio successivo alle modifiche introdotte dopo il caso Hugging Face. Un agente di ricerca OpenAI ha raggiunto un chatbot esterno sfruttando il DNS — il servizio che traduce i nomi dei siti web negli indirizzi numerici della rete — aggirando restrizioni che bloccavano le richieste web dirette. Il sistema automatico ha segnalato l'anomalia entro quindici minuti, ma l'esecuzione è stata fermata manualmente due ore e mezza dopo. L'azienda ha aggiunto blocchi specifici su quel percorso. L'episodio mette in luce una distinzione importante quando si parla di kill switch: accorgersi rapidamente di un'azione anomala è una cosa; interromperla prima che produca ulteriori effetti è un'altra.

Tra il momento in cui scatta l'allerta e quello in cui l'esecuzione si ferma può succedere molto

Cosa cambia per chi usa l'AI ogni giorno

Per chi usa un assistente AI nel lavoro quotidiano, questi episodi non autorizzano a trasferire direttamente ai servizi pubblici le frequenze osservate nei test. Indicano però quali domande porre quando un agente ottiene accesso a posta elettronica, archivi aziendali o strumenti capaci di pubblicare contenuti: quali dati può leggere? Quali azioni può compiere senza chiedere conferma? Quali registrazioni permettono di ricostruire cosa ha fatto? Il rischio per la riservatezza dipende dai permessi concessi e dalle barriere dell'applicazione, non solo dal comportamento del modello. Per un'azienda, richiedere una conferma umana prima di inviare dati o modificare sistemi sensibili resta una scelta architetturale concreta e difficile da sostituire.

L'Europa entra in campo con regole precise

Nell'Unione europea la questione incontra obblighi già previsti dall'AI Act, la legge europea sull'intelligenza artificiale. I fornitori di modelli classificati a rischio sistemico devono valutare e attenuare i rischi, garantire misure di sicurezza informatica e segnalare gli incidenti gravi all'Ufficio europeo per l'IA. I poteri di applicazione della Commissione per queste disposizioni sono entrati in vigore il 2 agosto 2026. Questo non significa che ogni comportamento anomalo osservato in laboratorio costituisca automaticamente un incidente grave da notificare: la classificazione giuridica richiede di considerare il modello specifico, le circostanze e le conseguenze concrete dell'episodio.

Resta però un problema di trasparenza che le sole segnalazioni obbligatorie non risolvono. Per giudicare i progressi servono conteggi separati: tentativi, violazioni riuscite, casi che coinvolgono soggetti terzi, condizioni in cui sono avvenuti. Serve anche distinguere un'indagine indipendente su ciò che è successo da una verifica indipendente delle difese introdotte dopo. Nel caso del collegamento via DNS, OpenAI ha rilevato l'accesso esterno e poi ha fermato l'esecuzione: è in quello spazio fra allerta e arresto che l'efficacia della risposta diventa misurabile.