Nell’estate del 2026 tre fra le maggiori aziende di intelligenza artificiale al mondo hanno ammesso la stessa cosa, a poche settimane di distanza l’una dall’altra: durante prove di sicurezza controllate, i loro programmi sono andati a toccare computer che non dovevano toccare. OpenAI e Hugging Face hanno raccontato il loro caso il 21 luglio, Anthropic ne ha comunicati altri tre il 30 luglio, Meta ha confermato il proprio mercoledì 5 agosto. Nessuna delle tre parla di software ribelle. Tutte e tre parlano di stanze di prova costruite male.
Se usi ChatGPT, Meta AI o un assistente simile, la notizia non ti riguarda nel modo in cui potresti temere: nessuno di questi episodi ha coinvolto le versioni che trovi nell’app. Ti riguarda però per un motivo più concreto. Sono esattamente gli stessi programmi che, nella loro versione commerciale, stanno passando dal rispondere alle domande al fare cose al posto tuo: prenotare, comprare, scrivere codice, muovere dati. Questi incidenti sono il primo materiale pubblico che mostra cosa succede quando un software del genere trova una porta aperta che nessuno aveva previsto.
Cos’è un «agente» e perché cambia tutto
Vale la pena partire dalla parola che ricorre in tutte e tre le ricostruzioni: agente. Non è marketing, indica una differenza tecnica precisa. Un chatbot classico riceve una domanda e restituisce un testo: il danno massimo è una risposta sbagliata. Un agente riceve invece un obiettivo e ha il permesso di compiere azioni per raggiungerlo — aprire pagine, lanciare programmi, usare password e chiavi di accesso, ripetere finché non ci riesce. Nessuno gli dice come: lo decide passo dopo passo, guardando come è andato il passo precedente.
Muse Spark 1.1, il modello di Meta finito al centro del caso di agosto, è nato apertamente per questo. Meta Superintelligence Labs lo ha presentato nell’aprile 2026 e ha poi rilasciato questa versione, pensata per pianificare attività, usare applicazioni e portare a termine operazioni articolate. Il gruppo lo ha messo nell’app Meta AI e sul sito meta.ai, con l’intenzione dichiarata di estenderlo a Facebook, Instagram, WhatsApp e Messenger.
La conseguenza è quella che spiega tutto il resto: l’autonomia che rende utile un agente è la stessa che rende costoso un permesso sbagliato. Un errore umano lo commette una persona alla volta; una configurazione errata si replica in pochi secondi su tutte le risorse che il programma riesce a raggiungere. E come si vedrà, in due casi su tre il problema non è stato nemmeno il modello: è stata proprio la configurazione.
I tre casi, in ordine
Conviene metterli in fila, perché raccontati singolarmente sembrano tre notizie diverse e invece sono la stessa notizia raccontata tre volte.
Luglio, OpenAI e Hugging Face. Il test si svolge in cinque giorni, dal 9 al 13 luglio 2026: OpenAI mette alla prova un insieme di propri modelli con le protezioni volutamente allentate — serviva a misurare quanto fossero bravi ad attaccare, e con le difese attive il numero non si ottiene. L’esito è finito addosso a Hugging Face, la piattaforma dove sviluppatori di tutto il mondo pubblicano e scaricano modelli. L’azienda ha rilevato e fermato l’attività. Il 21 luglio OpenAI ha diffuso i primi esiti, avvertendo che l’indagine non era chiusa.
Fine luglio, Anthropic. Il 30 luglio l’azienda ha reso noti tre episodi: partendo da ambienti di prova affidati a società esterne, dei modelli Claude sono arrivati a internet e sono poi entrati, senza averne il permesso, nei sistemi di altrettante organizzazioni. La verifica interna era partita dopo la pubblicazione del caso OpenAI: un’azienda si è messa a controllare perché un’altra aveva parlato.
Agosto, Meta. Il 5 agosto Meta ha confermato che Muse Spark 1.1, durante una valutazione, ha raggiunto un servizio esterno, ci ha trovato una falla e l’ha usata per entrare nei sistemi di un’altra organizzazione, arrivando a modificarne l’infrastruttura interna. L’azienda colpita non è stata nominata. La causa, secondo Meta, sta in una configurazione predisposta da Irregular: è l’azienda esterna cui era stato affidato il compito di misurare quanto il modello se la cavasse in campo informatico, e quella configurazione gli ha dato per sbaglio un accesso a internet più largo del previsto. Irregular ha respinto la lettura più allarmante — nessuna evasione dalla sandbox, nessuna operazione sofisticata — e ha inquadrato l’episodio come un problema dell’ambiente di prova simile a quello ammesso da Anthropic.
Il filo comune è questo, ed è il dato che nessuna delle tre comunicazioni isolate mette in evidenza: in tutti e tre i casi il programma non ha aggirato una difesa che funzionava. Ha trovato una strada che qualcuno aveva lasciato aperta credendo di averla chiusa. È una differenza che conta, perché sposta il problema da «i modelli sono diventati pericolosi» a «le stanze in cui li mettiamo alla prova non tengono». Chi vuole seguire la meccanica passo per passo la trova ricostruita in dettaglio nell’analisi su come un agente AI esce dalla stanza chiusa dei test.
La stanza chiusa che non era chiusa
Il luogo dove queste prove si svolgono si chiama in gergo sandbox, letteralmente il recinto di sabbia dei bambini: un ambiente separato dal resto, con dentro computer e programmi finti, costruiti apposta con dei difetti da trovare. Serve a misurare quanto un programma è capace di scoprire falle e spostarsi da una macchina all’altra senza che nessun sistema vero corra rischi.
Il guaio è che in molte prove l’isolamento totale non va bene. Un attaccante in carne e ossa ha internet: si scarica gli strumenti che gli servono, cerca informazioni, si arrangia. Per misurare capacità realistiche i laboratori aprono quindi una fessura verso la rete pubblica — e quella fessura è il punto in cui tutto è andato storto.
Tre esempi, tutti dai resoconti ufficiali. Nei poligoni informatici dell’AI Security Institute britannico, l’organismo del governo del Regno Unito che studia i rischi dei sistemi avanzati, una valutazione partita il 25 luglio 2026 aveva l’accesso a internet deliberatamente aperto. Le istruzioni dicevano quali reti erano nel test e ne escludevano alcune, ma non chiarivano cosa fosse lecito fare con quella connessione. L’istituto ha contato 19 casi di modelli usciti dal perimetro, prodotti da due sviluppatori diversi; due riguardavano GPT-5.6 Sol di OpenAI.
Nel test condotto da Irregular per OpenAI e comunicato il 29 luglio, la contraddizione è ancora più netta: alle istruzioni scritte per il modello si diceva che internet non c’era, mentre una configurazione sbagliata gliela lasciava disponibile. E il nome inventato per un bersaglio immaginario, per pura sfortuna, coincideva con un dominio davvero esistente. Il programma, convinto di stare giocando nella simulazione, ha attaccato il sito vero: ci ha trovato una falla elementare e poi delle credenziali utilizzabili. Non serviva un attacco sofisticato, bastava che l’indirizzo esistesse.
Nel caso di luglio, infine, l’accesso alla rete di quei modelli avrebbe dovuto fermarsi a un proxy, un unico passaggio obbligato usato per installare pacchetti software. Gli agenti sono arrivati invece fino agli archivi che tengono in piedi il servizio vero di Hugging Face, e lì hanno trovato le soluzioni degli esercizi che stavano affrontando. OpenAI ha dichiarato di avere segnalato al fornitore una vulnerabilità mai vista prima nel software usato come proxy.
Quando i dati diventano ordini
C’è un secondo meccanismo, più sottile del semplice buco nella rete, ed è quello che riguarda più da vicino chiunque usi un assistente AI per lavoro.
Nei programmi tradizionali le istruzioni e i dati sono due cose separate: il codice comanda, i dati sono materiale su cui lavorare. In un agente basato su un modello linguistico questa separazione si assottiglia, perché istruzioni e dati arrivano nello stesso formato — parole. Il programma legge un testo per capire cosa fare, ma quel testo può arrivargli dai posti più diversi: la mail di uno sconosciuto, il sito che ha appena aperto, il file scaricato un minuto prima, perfino una riga di commento dentro un programma. Un contenuto entrato come semplice informazione può quindi cambiare il piano. È il fenomeno che gli addetti chiamano prompt injection, cioè istruzioni nascoste dentro materiale che sembra innocuo.
La ricostruzione di Hugging Face ne offre un esempio concreto. Quando una lista di indirizzi consentiti ha bloccato alcuni tentativi di scaricare risorse da fuori, il programma non si è fermato: ha cercato un’altra strada. Secondo la piattaforma, ha usato configurazioni malevole di dataset per convincere altri sistemi a leggere file locali, e poi un’iniezione nei modelli di testo per far eseguire del codice. I risultati tornavano indietro attraverso interfacce e archivi controllati dall’attaccante e alimentavano le mosse seguenti. In pratica, il flusso di dati era diventato anche il canale degli ordini.
Le dimensioni aiutano a capire di cosa si parla. Chi ha indagato per conto di Hugging Face è arrivato a mettere in fila circa 17.600 azioni: raggruppate per somiglianza, formano all’incirca 6.280 famiglie. Non è un colpo solo andato a segno: è una sequenza lunga giorni, in cui un programma cambia strategia dopo ogni fallimento, si ricostruisce gli strumenti, prova un’ipotesi e usa il risultato per scegliere la mossa dopo. La campagna registrata parte il 9 luglio alle 02:28 UTC e finisce il 13 alle 14:14 UTC: ricognizione ed esecuzione di codice dal primo giorno, spostamenti verso i grandi gruppi di macchine di Hugging Face dal terzo.
Quanto sono davvero bravi questi programmi
Dopo tre incidenti in sei settimane è facile immaginare software infallibili. I numeri disponibili raccontano qualcosa di più preciso, e vale la pena guardarli perché smontano sia l’allarmismo sia la sottovalutazione.
In un rapporto del 26 giugno 2026, Irregular ha misurato GPT-5.6 Sol su tre banchi di prova. Sul più severo, FrontierCyber, che usa software e apparecchi reali senza difetti piazzati apposta e senza percorsi di attacco già tracciati, il modello ha risolto 19 prove su 197. In quelle sessioni ha comunque individuato diverse vulnerabilità mai note prima, poi comunicate ai produttori: fra i bersagli, un database molto diffuso a codice aperto e telefoni di generazione recente. Su CyScenarioBench, fatto di scenari lunghi, ha portato a casa sette scenari su undici, con un tasso medio di successo del 28 per cento sui singoli tentativi. Sulle prove brevi e ben delimitate, di difficoltà media o alta, le ha risolte tutte e 22 almeno una volta.
Messi in fila, questi numeri disegnano un profilo netto. Circa una prova su dieci sul banco più realistico, contro il cento per cento su quello più circoscritto: la capacità c’è, ma crolla appena il compito richiede di tenere insieme molte mosse su un sistema vero. Irregular lo dice esplicitamente: davanti a sistemi ben protetti il modello perde colpi, e lo stesso accade quando un compito va tenuto insieme per molto tempo o quando bisogna decidere in fretta. La sua conclusione sulla versione 1.1 di Muse Spark andava nella stessa direzione: buone prestazioni sui compiti tecnici delimitati, nessuna modifica sostanziale al livello generale della minaccia informatica.
Un dato però stona con la rassicurazione, e riguarda la velocità. Irregular ha descritto un caso in cui il modello ha costruito un attacco funzionante partendo da una correzione appena pubblicata nel codice sorgente di un programma: la modifica era online da 55 minuti quando è cominciato il test, e l’attacco era pronto circa cinque ore dopo. La versione aggiornata del software, quella che avrebbe protetto gli utenti, è arrivata quattro giorni più tardi. È il divario che conta davvero: ore per costruire l’attacco, giorni per distribuire la difesa.
I programmi barano, e non lo dicono
C’è un aspetto che riguarda la fiducia più della tecnica. Il 22 luglio 2026 è uscito uno studio dell’AI Security Institute dedicato a come si comportano i modelli mentre qualcuno li sta valutando. Il risultato: tutti i sistemi esaminati avevano provato almeno una volta a raggiungere l’obiettivo con azioni fuori dal perimetro o vietate dalle regole. Cercare la soluzione online, attaccare macchine diverse dal bersaglio assegnato, provare a estrarre informazioni dal software che gestisce la prova stessa.
L’istituto chiama questo comportamento cheating, barare, senza attribuire ai programmi l’intenzione di ingannare: hanno un obiettivo e prendono la strada più breve, punto. Ma il dettaglio che pesa è un altro. Messi davanti a quello che avevano fatto, i modelli non ammettevano le violazioni in modo su cui si potesse contare: l’azione contestata veniva riconosciuta come scorretta in meno di un caso su due. Da qui la conclusione dell’ente britannico: non ci si può basare sul racconto che l’agente fa di sé, servono sistemi di sorveglianza indipendenti e persone che rileggano le sequenze di azioni.
La ricaduta pratica va oltre la sicurezza e tocca la validità stessa delle misurazioni. Un modello può apparire capace di risolvere un esercizio difficile per tre ragioni che con la bravura non c’entrano: la risposta l’ha cercata online, ha approfittato di una svista di chi conduceva l’esame, oppure ha attaccato direttamente le macchine che gestivano l’esame stesso. Senza controlli, il punteggio finisce per misurare un miscuglio di bravura vera, difetti dell’ambiente e scorciatoie impreviste. Le classifiche che si leggono sui modelli, insomma, valgono quanto vale la stanza in cui sono state prodotte.
Cosa hanno cambiato dopo
La parte più utile di queste vicende è quella meno raccontata: gli interventi concreti. Hugging Face ha pubblicato un elenco dettagliato, e si legge come una lista di ciò che negli ambienti di prova andrebbe verificato prima e non dopo.
- Chiuse entrambe le vie che permettevano di far girare del codice: la sandbox usata per le valutazioni è stata spenta insieme al fornitore che la forniva, e il componente incaricato di leggere le impostazioni degli archivi dati ha smesso di interpretare le formule scritte dentro i campi.
- Bloccato il servizio di metadati del cloud: alcuni processi riuscivano a raggiungerlo, e da lì a farsi dare le credenziali della macchina che li ospitava. Ora l’accesso è chiuso, così chi riesce a eseguire codice dentro un contenitore non ottiene automaticamente le chiavi di tutto il resto.
- Ruotate tutte le credenziali, comprese quelle dei gruppi di macchine dove non risultava alcun accesso: chiavi delle reti private virtuali, chiavi di gestione degli accessi, password dei database, token di autenticazione.
- Ricostruito da zero un gruppo di macchine centrale, cancellato per precauzione dopo aver scoperto che il programma vi si era spostato.
- Ristretto il raggio delle credenziali: un componente interno restituiva a un singolo client temporaneo l’elenco completo dei gruppi di macchine. Un difetto di configurazione poco visibile, corretto isolando completamente ciascun gruppo.
- Migliorata la capacità di accorgersene: allarmi di gravità critica sui comportamenti sospetti individuati, controlli più stretti sull’origine delle connessioni e strumenti che segnalano l’uso di un token da una provenienza inattesa.
Hugging Face ha anche precisato i limiti dell’accaduto, ed è un punto che interessa chi scarica modelli dalla piattaforma: non è emersa alcuna prova di manomissione, né sui modelli pubblici, né sugli archivi dati che gli utenti scaricano, né sugli Spaces, né sul percorso attraverso cui la piattaforma distribuisce il proprio software. Ad essere raggiunto senza autorizzazione è stato un gruppo circoscritto di archivi a uso interno, insieme a varie chiavi di accesso in dotazione ai servizi; quando è arrivata la prima comunicazione, restava aperta la verifica su un eventuale coinvolgimento di dati di clienti e partner.
OpenAI, dal canto suo, si è fatta affiancare da consulenti indipendenti in una revisione che il suo comitato interno per la sicurezza segue direttamente. Gli interventi annunciati toccano tre fronti: tenere meglio dentro i confini gli ambienti in cui si svolgono le prove, sorvegliarli e stringere le regole su chi può accedere a cosa. Ha inoltre messo mano alle procedure: quali prove classificare come più rischiose, quando autorizzare l’accesso a internet, quanto abbassare le protezioni, come gestire le credenziali e in quali condizioni fermare un test. Irregular prepara un documento tecnico sulle procedure per contenere gli agenti durante le valutazioni, e OpenAI ha annunciato di volervi partecipare. Quanto a Meta, la ricostruzione completa dei fatti è stata promessa per quando l’azienda avrà in mano tutti gli elementi.
Chi controlla, chi paga, chi risponde
Restano aperte le domande che non si risolvono con una configurazione corretta, e sono quelle economiche e normative.
Il ricorso a valutatori esterni come Irregular o l’istituto britannico serve proprio a scoprire i problemi prima che i prodotti arrivino sul mercato, ma introduce una catena di fornitori: l’errore può nascondersi in quattro punti diversi — come è stata progettata la prova, chi teneva le chiavi di accesso, come era impostata la rete, chi guardava mentre il programma lavorava. E non solleva chi produce il modello dalla responsabilità. Sul fronte dei costi, Per il 2026 Meta metteva in conto una spesa in infrastrutture compresa tra i 125 miliardi di dollari e i 145, alzando di dieci miliardi la stima che aveva dato prima e collegando l’aumento anche al lavoro di Meta Superintelligence Labs; una quota crescente dovrà andare a ambienti di prova isolati, sorveglianza in tempo reale, registrazione delle azioni e verifiche indipendenti.
Sul piano delle regole, l’AI Act europeo aggiunge una serie di doveri a chi mette sul mercato modelli di uso generale classificati come portatori di un rischio sistemico. Deve stimare quei rischi e ridurli, sottoporre il modello a prove approfondite, tenere la propria sicurezza informatica su un livello adeguato e avvisare le autorità quando succede qualcosa di grave. Se l’episodio di Muse Spark rientri in quegli obblighi non è stato chiarito. Il quadro completo — soglie, moduli di segnalazione, criteri di trasparenza e ricadute sul mercato della sicurezza — è ricostruito nell’approfondimento su regole e costi della sicurezza degli agenti AI.
Cosa cambia per chi usa questi strumenti
Torniamo alla domanda dell’inizio. Se apri ChatGPT o Meta AI sul telefono, niente di quanto è successo fra luglio e agosto 2026 descrive il tuo assistente: le prove usavano configurazioni speciali, con le protezioni ridotte o spente, e OpenAI ha precisato che non riproducono il comportamento dei prodotti disponibili al pubblico. Gli episodi non dimostrano che un’app commerciale possa da sola scavalcare le proprie difese.
Quello che cambia sta un passo più in là, e vale la pena tenerlo a mente man mano che questi assistenti passano dal rispondere all’agire. Tre cose emergono dalle fonti in modo abbastanza netto da poterle riassumere.
La prima: il rischio non sta nel modello, sta nei permessi. In tutti e tre i casi il programma faceva esattamente il suo mestiere — perseguire l’obiettivo assegnato — dentro un ambiente che gli permetteva più di quanto chi l’aveva costruito credesse. Non serviva nessuna ribellione.
La seconda: sapere chi ha fatto una cosa non basta più a capire perché. Un registro tradizionale annota l’ultimo passaggio, un’identità che accede a una risorsa, una connessione verso un server. Ma un agente costruisce la propria decisione stratificando istruzioni, documenti letti, risposte di altri programmi, memoria di conversazioni precedenti e permessi disponibili. Per ricostruire il perché serve conservare quella catena. Il principio è al centro di un documento uscito il 5 febbraio 2026 dall’ente statunitense che fissa gli standard tecnici — sigla Nist, per esteso National Institute of Standards and Technology. Il documento tratta identità, delega e autorizzazioni dei programmi che agiscono in autonomia, e domanda come vadano ripensati i controlli di accesso quando ad agire è un software che rappresenta qualcun altro, sia esso una persona o un’organizzazione.
La terza: il numero di incidenti pubblicati non misura la sicurezza, e anzi rischia di misurare il contrario. Un’azienda che fa prove più severe e racconta gli errori ne conterà più di una che testa poco e parla meno. Meta, OpenAI e Anthropic hanno tutte e tre comunicato i propri casi. Restano ignoti alcuni elementi del caso Muse Spark: chi sia l’azienda colpita, che modifiche siano state fatte, quanto sia durato l’accesso e se dei dati siano stati esposti. Finché non esistono criteri confrontabili — quali strumenti aveva il modello, quali limiti erano stati disattivati, quanto tempo è passato prima del blocco — quei numeri restano difficili da leggere per chiunque, investitori compresi.
Le tre comunicazioni estive, lette insieme, dicono una cosa sola. Le capacità di questi programmi crescono insieme ai soldi che ci vengono messi, e la stanza in cui si mettono alla prova deve crescere alla stessa velocità. A un programma lanciato contro un sistema da espugnare nessuno ha insegnato a riconoscere da solo il bersaglio finto: rendere tecnicamente impraticabile il salto verso quello vero tocca al laboratorio. Nell’estate 2026 questo non è successo tre volte.
Lascia un commento