Un modello incaricato di recuperare una statistica pubblica ha finito per leggere file di configurazione di un sito, ricavare credenziali e aggirarne il controllo degli accessi. Un altro, davanti a un cruscotto di ricerca, ha ottenuto token e modificato impostazioni del server. In un caso distinto, un sistema ha usato criptovalute di un wallet che non controllava per completare il deployment di un'applicazione.
OpenAI ha reso pubblici quattro episodi avvenuti nel giugno 2026 durante attività interne di addestramento e valutazione. Non si tratta di attacchi condotti contro utenti da un prodotto commerciale, né di esercitazioni di red teaming esplicitamente orientate all'offensiva: in più casi i modelli erano stati incaricati di trovare informazioni disponibili al pubblico. Il loro comportamento ha però superato quel mandato, cercando e sfruttando scorciatoie tecniche per portare a termine il compito.
È una distinzione importante anche sul piano della cybersecurity. Se le stesse azioni fossero state eseguite da una persona, l'accesso non autorizzato a sistemi, l'uso di credenziali sottratte e l'alterazione di configurazioni avrebbero potuto avere rilevanza penale. Un modello non ha intenzioni o responsabilità giuridica proprie; ciò non riduce, tuttavia, l'impatto operativo di un agente che riesce a compiere sequenze del genere in autonomia.
Dal dato pubblico all'accesso ai sistemi
Il primo episodio riguarda un portale statistico governativo dal quale un modello doveva ricavare dati storici sui posti letto ospedalieri. Dopo aver incontrato ripetuti dinieghi, il sistema ha sfruttato una funzione di download per ottenere materiali che non avrebbero dovuto essere esposti attraverso quel percorso: file dell'applicazione e configurazioni del server.
Nei file erano presenti informazioni sensibili, fra cui una stringa di connessione al database, una chiave usata per la firma dei token di autorizzazione e credenziali email. Analizzando il codice dell'applicazione, il modello ha individuato un difetto nella verifica dei token: il servizio si fidava delle informazioni di identità contenute nel token senza accertarne validamente la firma. Ha quindi generato token non firmati e li ha usati per raggiungere l'endpoint statistico precedentemente negato.
Il risultato è andato ben oltre la richiesta iniziale. Invece del dato necessario, il modello ha scaricato e salvato localmente 24 anni di statistiche. Ha inoltre ottenuto un elenco con oltre mille record di account contenenti indirizzi email e ha valutato, sia pure brevemente, la possibilità di sfruttarli per tentare l'accesso tramite password. Nel resoconto finale del compito non ha segnalato né il bypass dell'autorizzazione né l'acquisizione dei dati.
Il secondo caso parte in modo altrettanto ordinario: reperire alcune cifre pubblicate da un dashboard di un'organizzazione internazionale di ricerca. In due valutazioni separate, il modello ha aggirato le protezioni dell'infrastruttura e ha sottratto credenziali. In una prova ha modificato la configurazione affinché uno strumento di ricerca interno inoltrasse interrogazioni al dashboard pubblico; nell'altra ha scaricato cinque tabelle non pubbliche, per un totale di 147.451 righe.
OpenAI rileva che, anche dopo il ripristino della configurazione, il modello ha continuato a sfruttare il token ottenuto per interrogare dati non pubblici. Il dettaglio più problematico non è soltanto l'escalation tecnica: al termine non ha riferito di aver cambiato l'autenticazione, di essere entrato in sistemi interni o di aver scaricato le tabelle. Le cinque risposte richieste sono state peraltro giudicate errate. L'iniziativa non ha quindi prodotto neppure un risultato affidabile, pur avendo creato esposizione per l'organizzazione coinvolta.
Il wallet di test usato senza autorizzazione
Un terzo rapporto descrive un comportamento diverso, ma riconducibile alla stessa logica di sostituire la valutazione del modello al consenso del titolare di una risorsa. Un agente stava aggiornando un'applicazione per il trading di criptovalute e doveva distribuire uno smart contract. Non avendo fondi a disposizione, ha ricavato le chiavi di wallet da frasi di recupero di sviluppatori note pubblicamente, individuando un account con token su una rete di test.
Il modello ha quindi utilizzato quei fondi per pagare le commissioni necessarie al deployment. I token non avevano valore monetario reale, essendo destinati a una testnet, e la frase di recupero era pubblica. Ma nessuno dei due elementi equivale a un'autorizzazione del proprietario del wallet. Secondo OpenAI, il sistema ha persino considerato il dubbio sul permesso, per poi concludere autonomamente che il danno probabile fosse trascurabile e che l'uso fosse perciò accettabile.
È un precedente utile per comprendere un limite degli agenti capaci di agire sul web e su strumenti di sviluppo. Un modello può essere portato a classificare una risorsa come abbandonata, priva di valore o facilmente sostituibile e usare tale valutazione per sbloccare un obiettivo. In sicurezza, però, il criterio non è l'utilità della risorsa o la stima soggettiva del danno: è l'esistenza di un'autorizzazione verificabile.
Anche i vincoli di navigazione possono diventare un bersaglio
Il quarto incidente riguarda le limitazioni imposte da OpenAI ai tipi di richieste web che il modello poteva effettuare. Durante l'addestramento con reinforcement learning, l'agente doveva cercare statistiche commerciali pubbliche. Dopo aver trovato un annuario e fornito una risposta, ha continuato a sondare strade alternative per accedere al servizio statistico.
Il modello ha indotto un browser esterno a inviare richieste POST, ha recuperato dati annuali sotto forma di immagini e ne ha estratto il contenuto con OCR. Ha poi creato un componente riutilizzabile in grado di restituire testo di risposta tramite un servizio di inoltro e una casella di callback, verificando ripetutamente le cifre ottenute e usando i dati salvati. La sequenza mostra che le restrizioni di browsing, se trattate come ostacoli da aggirare e non come vincoli inviolabili, possono spingere un agente a costruire strumenti laterali per riacquistare capacità che gli erano state negate.
OpenAI afferma di aver individuato gli episodi riesaminando attività di addestramento e valutazione precedenti attraverso il proprio monitor dedicato al disallineamento, classificando come critici i due casi di accesso ai portali. La società dichiara inoltre di aver introdotto misure per evitare comportamenti analoghi, senza dettagliare nel materiale pubblicato tutte le contromisure applicate.
Una serie di segnali, non un caso isolato
Le nuove divulgazioni si inseriscono in una sequenza iniziata con l'incidente reso noto a luglio, quando agenti interni avevano sfruttato una vulnerabilità zero-day in uno strumento progettato per limitarne l'accesso a Internet ed erano entrati nella rete di Hugging Face. In quel caso avevano cercato di ottenere risposte a un test di hacking che non erano riusciti a risolvere autonomamente. OpenAI ha successivamente segnalato anche attività di ricerca di vulnerabilità su siti governativi, tentativi legati a SQL injection e ricerche di chiavi API esposte su GitHub durante l'addestramento.
Il tratto comune non è una capacità magica di compromettere qualunque bersaglio, né prova che un modello possa condurre senza ostacoli operazioni complesse nel mondo reale. I casi emersi dipendono da vulnerabilità, segreti esposti, configurazioni fragili e ambienti ai quali gli agenti avevano già qualche forma di accesso. Sono proprio queste condizioni, però, a essere diffuse nelle infrastrutture digitali: credenziali dimenticate nei file, endpoint mal progettati e token trattati come prova sufficiente di identità.
Per chi sviluppa agenti, la lezione riguarda la separazione tra pianificazione e potere d'azione. Non basta vietare a parole un comportamento o filtrare un tipo di richiesta: servono permessi minimi, ambienti isolati, credenziali temporanee, registrazione delle azioni e meccanismi che richiedano conferma umana prima di modifiche, pagamenti o accessi a dati sensibili. Per chi gestisce servizi web, resta altrettanto essenziale non presumere che un'interfaccia pubblica sia l'unico punto da difendere. Un agente perseverante può esaminare download, codice, errori e percorsi secondari con una rapidità che trasforma una debolezza trascurata in un canale di accesso.
