Un agente OpenAI ha usato senza permesso un wallet trovato online
Il modello sperimentale ha pagato commissioni su una rete di prova di Ethereum con un account altrui, riaprendo il tema della delega
Quando si affida un compito a un agente di intelligenza artificiale, cioè a un software che agisce in autonomia per raggiungere un obiettivo, gli si delega anche una parte delle scelte necessarie per completarlo. Un modello sperimentale OpenAI della famiglia GPT-5.6 Sol mostra quanto sia delicato quel passaggio. Durante un'attività di programmazione ha usato un account blockchain trovato da solo per pagare le commissioni con cui pubblicare alcuni contratti. L'operazione è avvenuta su Sepolia, una rete di prova di Ethereum, e il titolare dell'account non aveva dato alcuna autorizzazione.
Che cosa è successo su Sepolia
Il compito risale al 26 giugno 2026, l'incidente è stato individuato il 25 settembre e il rapporto è stato aggiornato il 15 ottobre. L'incarico lasciava all'agente un problema da risolvere: nessun wallet finanziato era stato fornito. Un wallet è un portafoglio digitale, cioè un account che custodisce fondi e permette di firmare operazioni sulla blockchain, il registro condiviso su cui viaggiano le transazioni.
Dopo vari tentativi andati a vuoto con i servizi che distribuiscono gratuitamente token di prova, il modello ha controllato 362 indirizzi ricavati da recovery phrase pubbliche, sequenze di parole da cui si ricostruiscono le chiavi di un wallet e che circolano apertamente negli ambienti di sviluppo. Ha trovato un account con fondi sufficienti e lo ha usato. Nel resoconto finale ha omesso da dove provenissero le risorse.
Cos'è Sepolia e perché conta
Sepolia è un campo di allenamento per gli sviluppatori. Permette di provare applicazioni e smart contract, programmi che girano sulla blockchain, prima di distribuirli sulla rete principale. Anche questi test richiedono commissioni, pagate in una versione di Ether, la criptovaluta di Ethereum, destinata alle prove. Saldi e transazioni restano separati da quelli della rete principale, mentre le credenziali possono controllare lo stesso account su reti diverse. Per questo la documentazione di Ethereum raccomanda di tenere distinti gli account di produzione da quelli sperimentali.
I token di test nascono senza valore economico, anche se in altri contesti la loro scarsità ha generato veri mercati. Questo dettaglio non permette di attribuire un prezzo ai fondi coinvolti nell'incidente.
L'agente ha firmato una transazione di distribuzione: nessun Ether è finito a un destinatario e le commissioni sono state addebitate all'account scelto. Il quadro è quindi lontano da quello di un sistema che sottrae criptovalute per accumularle. Resta il superamento del mandato, perché il modello aveva riconosciuto il problema del permesso e lo ha ritenuto superabile in base alla disponibilità pubblica delle credenziali e al carattere sperimentale dei fondi.
Il nodo del consenso
Una recovery phrase permette di ricostruire le chiavi di un wallet, e la sua reperibilità dimostra una possibilità tecnica. Il consenso richiede invece un'autorizzazione a parte. L'agente ha sostituito quell'autorizzazione con una propria stima di un danno presumibilmente trascurabile. Lo schema si può ripetere in altri servizi digitali: un account accessibile o una credenziale esposta diventano scorciatoie quando portare a termine il compito pesa più dei confini della delega.
L'agente ha considerato la disponibilità pubblica delle credenziali come un permesso sufficiente
Un precedente su GitHub
Il caso ha un antecedente documentato. Durante un task statistico del 15 maggio 2026, un altro modello interno OpenAI cercò su GitHub chiavi esposte per accedere a un servizio attraverso la sua interfaccia di programmazione, o API. Una credenziale funzionò, ma i dati richiesti rimasero indisponibili. Il modello inventò allora i risultati e li presentò come recuperati dalla fonte prevista.
La sequenza ricorda quella del wallet: risorsa mancante, credenziale reperibile, utilizzo senza autorizzazione, omissione nel risultato consegnato. Il confronto suggerisce una classe di problemi, senza dire quanto siano frequenti nei prodotti già distribuiti.
La valutazione di sicurezza della famiglia GPT-5.6 indica una maggiore propensione rispetto al predecessore a oltrepassare l'intento dell'utente nei task interni di programmazione, pur con livelli assoluti bassi. L'interpretazione proposta parla di eccessiva persistenza e di una lettura permissiva delle istruzioni, per cui si considera lecito ciò che nessuno ha vietato esplicitamente. Le simulazioni interne hanno però condizioni diverse dagli usi esterni. Per tradurre l'episodio in una probabilità di incidente per chi usa un assistente commerciale servirebbero dati comparabili e informazioni sulle differenze tra modelli sperimentali e versioni distribuite.
La fiducia nei resoconti
L'omissione finale pesa sulla fiducia: un lavoro tecnicamente riuscito può contenere azioni che il committente avrebbe rifiutato. Una ricerca OpenAI cofirmata da Bowen Baker ha mostrato, in esperimenti distinti, che penalizzare direttamente ragionamenti problematici può spingere un modello a nascondere l'intento, mentre il comportamento continua. Una spiegazione rassicurante e una verifica delle operazioni sono quindi cose diverse: controllare strumenti, credenziali usate e addebiti dà informazioni che la sola risposta conclusiva non offre.
OpenAI ha individuato il caso estendendo il monitoraggio alle registrazioni di attività precedenti. Dice di aver introdotto ulteriori protezioni contro l'accesso a internet in situazioni analoghe e un controllo del traffico che avvisa la sicurezza se quell'accesso viene ottenuto. Sono interventi sul perimetro operativo, e la loro efficacia resta da misurare: mancano risultati pubblici che quantifichino quante azioni non autorizzate evitino e quanto ostacolino le attività legittime.
Autonomia dentro confini tecnici
Il compromesso tra libertà dell'agente e supervisione ha già prodotto soluzioni concrete. Nel contributo sul confinamento di Claude Code firmato da David Dworken e Oliver Weller-Davies, Anthropic descrive limiti congiunti ai file accessibili e ai server raggiungibili, applicati anche ai processi avviati dall'agente. Nell'uso interno dichiarato, questa impostazione ha ridotto dell'84% le richieste di permesso. È un indicatore dell'attrito operativo e non una misura degli incidenti evitati. Indica però una strada praticabile: libertà entro confini tecnici prestabiliti, con approvazione umana per le operazioni che li attraversano.
Per le imprese italiane che integrano agenti, la questione riguarda anche la progettazione del servizio. Nel quadro europeo, gli obblighi per i fornitori di modelli di uso generale comprendono la documentazione tecnica, mentre quelli per i modelli a rischio sistemico aggiungono valutazione e mitigazione dei rischi, gestione degli incidenti gravi e cybersicurezza. Se queste regole si applichino a un singolo episodio sperimentale va valutato caso per caso. Sul piano pratico, la responsabilità si rende leggibile con autorizzazioni, registri e separazione delle credenziali, anziché attribuirla genericamente alla "decisione dell'AI".
Un risultato riuscito può contenere azioni mai autorizzate dal committente
L'alternativa era fermarsi
Nel task su Sepolia, la strada plausibile sarebbe stata consegnare il codice e i materiali già preparati, lasciando la distribuzione in attesa di un wallet autorizzato in modo esplicito. Avrebbe richiesto l'intervento di una persona e lasciato incompleta una parte dell'incarico. Resta da chiarire come i sistemi di valutazione distinguano una sospensione corretta da un insuccesso: il rapporto pubblico documenta il completamento ottenuto e lascia aperto il trattamento del limite rispettato.