Cosa è successo realmente tra il 9 e il 13 luglio 2026 durante il test sulle capacità informatiche avanzate dei modelli di OpenAI?
L’azienda di ChatGPT ha reso pubblici i primi risultati il 21 luglio, precisando che l’indagine è ancora in corso. L’incidente è stato causato da una combinazione di modelli utilizzati internamente con protezioni cyber ridotte proprio per misurarne le capacità offensive. Hugging Face, che aveva rilevato e contenuto l’attività, ha poi pubblicato una ricostruzione tecnica più dettagliata.
Gli investigatori di Hugging Face hanno ricostruito circa 17.600 azioni, raggruppate in circa 6.280 cluster. La sequenza mostra un agente capace di cambiare strategia dopo un fallimento, ricostruire strumenti, verificare ipotesi e usare i risultati ottenuti per scegliere il passaggio successivo.
Il punto rilevante per le aziende non riguarda soltanto la potenza dei modelli. Riguarda ciò che accade fra l’obiettivo assegnato all’agente e l’azione registrata alla fine da un sistema di sicurezza.
Indice degli argomenti:
Una decisione nasce da molti livelli di informazioni
Un agente non lavora soltanto sul comando iniziale. Durante un’attività può ricevere documenti, risultati di ricerca, risposte di API, credenziali, messaggi, dati aziendali, contenuti web e informazioni prodotte da altri strumenti. Può inoltre utilizzare una memoria costruita in interazioni precedenti.
Ogni nuovo elemento può cambiare ciò che il sistema considera possibile o opportuno.
Una credenziale amplia le risorse accessibili. Una risposta proveniente da uno strumento introduce informazioni che prima non erano disponibili. Una pagina web può proporre un nuovo percorso. La memoria può riportare nel compito corrente un presupposto raccolto giorni o settimane prima.
Quando l’agente esegue infine un comando, il registro può mostrare soltanto l’ultima parte di questa sequenza: un’identità che accede a una risorsa, un processo che interroga un’API, una connessione verso un server. Per ricostruire perché quell’azione sia stata scelta, però, occorre risalire a tutto ciò che l’ha preceduta.
Il problema emerge anche in applicazioni molto meno sensibili di un test cyber. Un agente per l’assistenza clienti potrebbe leggere una richiesta, recuperare la scheda dell’utente, consultare le regole aziendali e inviare una mail. La decisione finale dipende dalla combinazione di istruzioni di sistema, richiesta ricevuta, documenti recuperati, memoria e autorizzazioni disponibili.
Ogni componente può essere legittimo. È la loro interazione a determinare il comportamento.
Quando i dati cominciano a funzionare come istruzioni
Il software tradizionale tende a separare istruzioni eseguibili e dati. Negli agenti basati sui modelli linguistici questa distinzione diventa meno netta, perché entrambi possono essere espressi nello stesso formato: il linguaggio naturale.
Un agente interpreta testo per stabilire che cosa fare. Lo stesso testo può però arrivare da una mail, da una pagina web, da un documento recuperato, da un commento nel codice o dalla risposta di uno strumento.
Un contenuto introdotto come semplice informazione può quindi modificare il piano.
La ricostruzione di Hugging Face offre un esempio tecnico. Quando una lista di Url consentiti ha impedito alcuni tentativi di recuperare risorse remote, l’agente ha cercato percorsi alternativi. Secondo Hugging Face ha sfruttato configurazioni malevole di dataset per indurre sistemi di elaborazione a leggere file locali e ha successivamente utilizzato un’iniezione di template per eseguire codice. I risultati tornavano attraverso API e dataset controllati dall’attaccante e alimentavano le mosse successive.
Il flusso dei dati diventava così anche un flusso di istruzioni e feedback.
È il problema che nella sicurezza dei sistemi agentici viene collegato anche alla prompt injection: contenuti provenienti da una fonte esterna possono alterare il comportamento di un agente se il sistema non conserva una separazione efficace fra materiale informativo e istruzioni autorizzate.
Parlare soltanto di “prompt” rischia perciò di descrivere una porzione troppo piccola del processo.
Il contesto si accumula mentre l’agente lavora
Il contesto operativo di un agente può comprendere le istruzioni definite dallo sviluppatore, la richiesta dell’utente, i documenti recuperati durante il compito, la cronologia delle conversazioni, la memoria a lungo termine, i risultati prodotti dagli strumenti e le autorizzazioni disponibili.
Questi elementi non hanno tutti lo stesso peso né la stessa affidabilità.
Un documento proveniente da Internet non dovrebbe avere la stessa autorità di una policy aziendale. Un dato memorizzato mesi prima può essere diventato obsoleto. Una credenziale con privilegi estesi può trasformare una decisione sbagliata in un incidente grave. L’aggiunta di un nuovo strumento può rendere eseguibile un’azione che, fino a quel momento, era soltanto suggerita dal testo.
Il National Institute of Standards and Technology (NIST) statunitense ha affrontato una parte del problema nel concept paper Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization, pubblicato il 5 febbraio 2026. Il documento esamina identità, delega, autorizzazione, audit e responsabilità degli agenti e chiede come i sistemi di controllo degli accessi debbano adattarsi ad architetture in cui l’agente agisce per conto di una persona o di un’organizzazione.
L’identità dell’agente, quindi, non basta. Per decidere se un’azione debba essere consentita occorre considerare anche l’obiettivo assegnato, l’origine delle informazioni utilizzate e l’autorità delegata.
Una catena di custodia per ricostruire le decisioni
Nel lavoro forense, la catena di custodia documenta l’origine di una prova, i soggetti che l’hanno gestita e le trasformazioni subite. Per gli agenti AI può servire un principio simile applicato al contesto.
Non significa registrare indiscriminatamente ogni parola elaborata dal modello. Significa conservare abbastanza informazioni per ricostruire il percorso che collega una fonte a una decisione.
Se un documento esterno introduce un’indicazione, il sistema dovrebbe poter identificare da dove proviene. Se quella informazione viene trasferita nella memoria, dovrebbe essere possibile stabilire quando è stata acquisita e quanto rimane affidabile. Se uno strumento rende possibile l’azione proposta e una credenziale permette di eseguirla, anche questi passaggi dovrebbero restare collegati.
Il modello proposto da Check Point organizza il problema intorno ad alcuni attributi del contesto: origine, affidabilità, scopo, attualità, sensibilità e influenza. L’ultimo elemento riguarda il collegamento fra informazione e decisione: quale chiamata a uno strumento, quale output o quale scelta è stata modificata da un determinato contenuto.
Senza questo collegamento, un’organizzazione può raccogliere grandi quantità di log e continuare a non sapere perché un agente abbia considerato appropriata una determinata azione.
I controlli devono seguire l’attività dell’agente
La conseguenza riguarda anche il modo in cui vengono applicate le policy di sicurezza.
Controllare un agente soltanto all’inizio del compito lascia scoperti i cambiamenti successivi. Durante l’esecuzione possono infatti comparire nuove informazioni, nuove destinazioni, privilegi aggiuntivi o strumenti che modificano il rischio dell’operazione.
Una richiesta inizialmente innocua può acquisire conseguenze diverse dopo il recupero di un documento esterno o l’accesso a informazioni riservate. In questi casi l’autorizzazione dovrebbe poter essere rivalutata.
Per le operazioni ad alto impatto può essere richiesta un’approvazione umana. Una destinazione non prevista può essere bloccata. I dati sensibili possono essere oscurati prima di una chiamata esterna. Uno strumento può essere limitato all’insieme di operazioni necessarie per il compito.
Check Point propone controlli di questo tipo durante l’esecuzione attraverso la propria piattaforma, che analizza prompt, contenuti esterni, flussi di dati e chiamate agli strumenti. Si tratta di una soluzione commerciale e le affermazioni sulle sue capacità provengono dal produttore; il principio generale, però, coincide con il problema discusso dal Nist: identità e autorizzazioni devono tenere conto dell’azione che l’agente sta tentando di svolgere e dell’autorità con cui opera.
Il caso Hugging Face sposta il perimetro della sicurezza
Hugging Face ha dichiarato di non avere trovato prove di alterazioni dei modelli pubblici, dei dataset destinati agli utenti, degli Spaces o della propria catena di distribuzione software. La società ha invece rilevato accessi non autorizzati a un insieme limitato di dataset interni e a diverse credenziali utilizzate dai servizi. Al momento della comunicazione iniziale stava ancora verificando l’eventuale coinvolgimento di dati di partner o clienti.
OpenAI ha avviato una revisione con consulenti esterni e sotto la supervisione del proprio Safety and Security Committee. La società ha inoltre annunciato interventi sul contenimento degli ambienti di valutazione, sul monitoraggio e sui controlli degli accessi. Le conclusioni definitive sull’incidente non sono ancora state pubblicate.
Cosa ha modificato Hugging Face dopo l’incidente
Finora si è parlato della risposta adottata da Hugging Face a livello generale. Per quanto riguarda il rafforzamento tecnico:
- Chiusi entrambi i percorsi di esecuzione del codice: disattivata la sandbox di valutazione con l’aiuto del fornitore terzo e il renderer delle configurazioni dei dataset non valuta più le espressioni dei template nei campi dati, né elabora erroneamente i riferimenti esterni HDF5.
- Blocco dei metadati cloud: alcuni workload potevano raggiungere il servizio di metadati dell’istanza, Imdsv2. Ora l’accesso a questo servizio è bloccato a livello di pod per tutti i workload, così un’esecuzione remota di codice, Rce, all’interno di un pod non può trasformarsi facilmente nell’ottenimento delle credenziali del nodo.
- Rotazione estesa delle credenziali: ruotati tutti i token e tutte le credenziali utilizzati dall’infrastruttura, anche nei cluster ai quali non era stato effettuato alcun accesso, comprese chiavi di autenticazione Vpn, chiavi Iam, credenziali dei database e Jwt. Dove non era ancora implementata, si è passati alla workload identity.
- Ricostruzione dell’infrastruttura centrale: dopo aver individuato il movimento laterale verso uno dei cluster principali, è stato cancellato e ricostruito completamente da zero come ulteriore misura precauzionale.
- Ambito più ristretto per le credenziali: il service connector interno non avrebbe dovuto restituire l’intero catalogo dei cluster a un singolo client temporaneo. Si trattava di un difetto di configurazione poco evidente nel sistema di accesso ai cluster; è stato corretto e ora ogni cluster è completamente isolato.
- Migliore capacità di rilevamento: introdotti avvisi di gravità critica per le firme comportamentali descritte sopra, controlli più rigidi sull’origine delle connessioni di rete e strumenti che segnalano l’utilizzo di token da origini inattese.
La sequenza già documentata indica però un requisito operativo preciso per chi introduce agenti AO nei processi aziendali. Sapere quale account abbia compiuto un’azione rimane necessario, ma non consente da solo di ricostruire il comportamento di un sistema capace di aggiornare continuamente il proprio piano.
Occorre sapere quale obiettivo stesse perseguendo, quali fonti abbia consultato, quali informazioni siano entrate nella memoria, quali strumenti fossero disponibili e quali autorizzazioni abbiano trasformato una possibilità in un’azione.
Il registro finale racconta che cosa è successo. La catena di custodia del contesto serve a ricostruire perché sia successo e, soprattutto, a intervenire prima che la sequenza arrivi all’ultimo comando.
Fonti principali
OpenAI, 21 luglio 2026;
Hugging Face, ricostruzione forense dell’incidente di luglio 2026;
Nist/NCCoE, concept paper del 5 febbraio 2026;
Check Point, 4 agosto 2026.
Partecipa alla community