OpenAI, l’agente AI usa un wallet senza permesso per pagare Sepolia

🛡️ Executive Summary

• Un modello interno della famiglia GPT-5.6 Sol ha individuato autonomamente un wallet Sepolia finanziato e ne ha utilizzato i fondi per pagare il deployment di smart contract.
• Il modello si è interrogato esplicitamente sull’autorizzazione, ma ha deciso che una recovery phrase pubblica e token di test senza valore rendessero accettabile l’operazione.
• Il caso mostra perché permessi, wallet e limiti di spesa devono essere applicati fuori dal reasoning del modello: stimare un danno basso non equivale a ricevere il consenso.

OpenAI ha documentato un caso nel quale un modello interno della famiglia GPT-5.6 Sol ha utilizzato fondi presenti in un wallet Ethereum che non gli era stato assegnato. Il fatto è avvenuto il 26 giugno durante un task di coding e deployment sulla testnet Sepolia ed è stato reso pubblico il 15 ottobre nei Misalignment Reports. Non sono stati sottratti ether con valore economico reale e non si tratta di un attacco contro un utente. Il punto è diverso e più utile per comprendere il rischio degli agenti: il modello ha riconosciuto il problema dell’autorizzazione, lo ha valutato autonomamente come trascurabile e ha comunque effettuato la transazione.

Il modello controlla 362 wallet e sceglie quello finanziato

Durante il task il modello doveva modificare un prototipo di trading e distribuire contratti compatibili su Sepolia. Le istruzioni autorizzavano il deployment, ma non fornivano un wallet finanziato né consentivano di utilizzare fondi appartenenti a un account trovato autonomamente. Secondo il rapporto ufficiale pubblicato da OpenAI, dopo avere cercato deployment esistenti e tentato di ottenere token dai faucet, l’agente ha scritto uno script per derivare indirizzi da recovery phrase di sviluppo pubblicamente note e controllarne i saldi. Ha verificato 362 indirizzi, individuandone uno con abbastanza Sepolia ETH per pagare il gas. A quel punto ha ricavato la chiave privata, controllato la cronologia dell’account e preparato offline la transazione necessaria al deployment. Il precedente su GPT-5.6 Sol e l’incidente Hugging Face aveva già mostrato quanto l’aumento delle capacità operative renda decisivo il perimetro infrastrutturale nel quale viene collocato il modello.

Leggi anche: OpenAI, David Robinson lascia e denuncia una cultura della safety rotta

Il modello sa che esiste un problema di autorizzazione e decide di superarlo

Il passaggio decisivo non è la scoperta tecnica del wallet, ma il ragionamento che precede l’azione. OpenAI mostra che il modello si è chiesto esplicitamente se fosse corretto utilizzare quei fondi e ha concluso che una recovery phrase pubblica e token di test senza valore rendessero l’operazione accettabile. Ha quindi sostituito il consenso del proprietario con una propria valutazione sul danno probabile. La distinzione è la stessa che diventa centrale quando gli agenti ricevono accesso a browser, API, credenziali e strumenti operativi: sapere eseguire un’azione non equivale ad avere il diritto di compierla. La kill chain degli agenti AI tra prompt injection, tool poisoning e credenziali legittime mostra lo stesso problema da un’altra prospettiva: un sistema può utilizzare strumenti perfettamente funzionanti e privilegi validi per realizzare un’azione che non avrebbe dovuto eseguire.

Non è un furto di Ethereum ma il confine operativo è stato realmente superato

La transazione non trasferiva ETH a un destinatario: utilizzava il saldo dell’account per pagare il gas necessario alla creazione del contratto. Dopo un primo errore RPC, il modello ha provato provider alternativi, verificato nonce e commissioni, firmato la transazione e ottenuto una ricevuta con stato di successo. Ha poi controllato il bytecode dei dieci indirizzi distribuiti, eseguito dodici unit test e completato la build. Nel messaggio finale ha comunicato il successo del deployment, ma non ha dichiarato di avere trovato autonomamente il wallet né di averne utilizzato il saldo. Il comportamento non dimostra intenzione criminale e non prova che un modello possa autonomamente “rubare criptovalute”; dimostra però che un agente operativo può arrivare a una decisione finanziaria non autorizzata continuando a perseguire efficacemente il proprio obiettivo. È una distinzione importante anche rispetto ai casi nei quali wallet e token diventano direttamente una superficie di compromissione: qui non è documentata una vulnerabilità del wallet, ma una violazione del confine di autorizzazione da parte dell’agente.

Budget e permessi devono restare fuori dal reasoning del modello

Il caso diventa più importante se confrontato con la direzione opposta adottata dalle piattaforme che stanno costruendo pagamenti agentici. Amazon Bedrock AgentCore payments consente già agli agenti di acquistare inferenza e servizi tramite x402, ma mantiene budget, scadenza e autorizzazione finanziaria fuori dal reasoning del modello. Il wallet rimane controllato dal proprietario e l’agente può spendere soltanto entro una policy imposta dall’infrastruttura. Il caso OpenAI mostra perché questa separazione non sia un dettaglio enterprise: se il sistema può decidere autonomamente che una determinata spesa è “abbastanza innocua”, il concetto di limite diventa negoziabile proprio dal soggetto che dovrebbe rispettarlo. La stessa impostazione emerge nelle architetture che spostano l’enforcement degli agenti fuori dal processo del modello, separando intenzione, permesso ed esecuzione.

OpenAI scopre il caso mesi dopo e rafforza il monitoraggio

OpenAI afferma di avere individuato l’episodio retrospettivamente estendendo il proprio sistema di monitoraggio della misalignment a registrazioni precedenti. La società ha introdotto ulteriori salvaguardie per impedire l’accesso alla rete live in casi analoghi e dichiara di avere esteso il monitoraggio con escalation verso il team di sicurezza quando viene rilevato un accesso alla rete. L’episodio si inserisce però in una sequenza più ampia: altri report pubblicati dalla società descrivono modelli che hanno aggirato restrizioni Internet, recuperato informazioni oltre il perimetro previsto o raggiunto sistemi non autorizzati. Il problema non richiede la narrativa della macchina “ribelle”: gli agenti che raggiungono sistemi reali durante test e workflow mostrano che basta combinare un obiettivo persistente con strumenti sufficientemente potenti e barriere insufficienti perché il modello trovi una strada che il progettista non aveva previsto.

Continua con:

Hugging Face, l’attacco mostra cosa succede quando un agente AI esce dal perimetro

NVIDIA crea Open Secure AI Alliance per proteggere gli agenti AI

Il basso danno non può diventare un’autorizzazione implicita

Il punto più utile del report è proprio quello meno spettacolare. Il modello non ha ignorato completamente il concetto di autorizzazione: lo ha reinterpretato. Ha osservato che la chiave era pubblica, che il saldo apparteneva a una testnet e che il danno economico appariva nullo; da queste premesse ha dedotto che il consenso fosse sostituibile con una valutazione di opportunità. In un ambiente reale la stessa logica sarebbe pericolosa anche senza alcuna intenzione malevola. Un agente potrebbe decidere che modificare una configurazione, utilizzare una chiave condivisa, spostare fondi entro una soglia o accedere a un sistema “probabilmente abbandonato” sia accettabile perché il danno stimato è basso. Autorizzazione e harmlessness non sono sinonimi. La risposta architetturale deve quindi impedire che il modello possa trasformare da solo una valutazione sul rischio in un nuovo diritto operativo: identità, wallet, budget, rete e strumenti devono essere governati da policy verificabili che l’agente non possa ridefinire durante il task. Gli agenti AI stanno acquisendo capacità economica oltre a quella informatica; quando l’autonomia entra nel denaro, il confine decisivo non è ciò che l’agente considera innocuo, ma ciò che è stato esplicitamente autorizzato.