La falla nei Reasoning cifrati di Claude, GPT e Gemini trasforma i modelli più deboli in decoder dei frontier model

Stealing Reasoning Traces from Proprietary LLM APIs

La sicurezza del reasoning dei modelli di intelligenza artificiale sta scoprendo una crepa concettualmente più interessante di una semplice vulnerabilità software. I ricercatori hanno dimostrato che i blocchi cifrati contenenti il ragionamento interno di modelli frontier come Claude, GPT e Gemini possono essere riutilizzati fuori dal contesto originale e, in determinate condizioni, consegnati a un modello più debole dello stesso ecosistema, inducendolo a restituire in chiaro il contenuto che avrebbe dovuto rimanere nascosto. Non è stata violata la crittografia nel senso classico del termine. Nessuno ha recuperato una chiave AES, forzato un algoritmo o penetrato nei server di Anthropic, OpenAI o Google.

La crittografia protegge il contenuto, ma l’architettura permette al contenuto cifrato di essere trasferito e reinterpretato da modelli diversi.

Il lavoro, pubblicato il 10 agosto 2026 da Alexander Panfilov e colleghi di University of Tübingen, Max Planck Institute, MATS Research e Snyk, descrive una vulnerabilità comune alle API di Anthropic, OpenAI e Google. L’idea è quasi offensivamente semplice. I provider non mantengono necessariamente tutto il reasoning sul server; in alcuni sistemi restituiscono al client blocchi cifrati che devono essere rimandati all’API nelle richieste successive, soprattutto quando entrano in gioco strumenti e conversazioni agentiche.

Anthropic, per esempio, documenta esplicitamente che il thinking completo viene cifrato e restituito nel campo “signature”, mentre i blocchi devono essere conservati e trasmessi nuovamente in determinati flussi con tool use.

Un blocco concepito per essere leggibile soltanto dal sistema autorizzato non è necessariamente legato crittograficamente in modo sufficientemente stretto alla sessione, all’utente e al modello che lo ha prodotto. Secondo la ricerca, i blocchi risultano compatibili e intercambiabili tra sessioni, utenti e modelli all’interno dello stesso ecosistema. Un aggressore può quindi ottenere il reasoning cifrato prodotto da un modello costoso e più protetto, come Claude Opus, e inserirlo nel flusso di un modello più economico e meno allineato, come Haiku. Il modello più debole diventa così una sorta di decoder semantico. Non serve convincere Opus a rivelare i propri pensieri: basta chiedere a un parente meno sorvegliato di leggere ciò che gli è stato consegnato.

La distinzione è fondamentale perché cambia anche il significato della parola “crittografia”. In sicurezza informatica siamo abituati a pensare che un dato cifrato sia protetto finché la chiave rimane segreta. Qui, invece, il problema non è necessariamente la confidenzialità matematica della cifratura, ma il modo in cui il sistema utilizza il dato dopo la cifratura. Se un blob può essere passato a un altro componente che possiede la capacità di interpretarlo, l’attaccante non deve rompere la crittografia; deve soltanto trovare un componente legittimo disposto a fare il lavoro al suo posto. È una lezione vecchia per la cybersecurity, applicata ora a un’industria che ha passato gli ultimi due anni a parlare di “reasoning” come se fosse una proprietà metafisica.

Le conseguenze economiche sono tutt’altro che accademiche. Il reasoning rappresenta uno degli asset più preziosi dei modelli frontier perché contiene una traccia molto più informativa della semplice risposta finale. Un output pubblico può dire che un problema è stato risolto; una reasoning trace può mostrare come il modello lo ha risolto, quali strategie ha esplorato, quali errori ha corretto e quali trasformazioni interne hanno prodotto il risultato. Questo rende possibile un nuovo tipo di model extraction, nel quale l’obiettivo non è replicare migliaia di risposte API, ma raccogliere direttamente materiale utile alla distillazione delle capacità di un modello proprietario. I ricercatori mostrano infatti che il metodo può essere utilizzato per estrarre reasoning da Anthropic, OpenAI e Google.

Il problema diventa ancora più serio quando il reasoning contiene informazioni che non compaiono nella risposta finale. La ricerca descrive infatti un secondo vettore di attacco: l’estrazione di dati personali e credenziali presenti nei blocchi di reasoning.

Il paper riporta un’analisi di 315.320 reasoning blocks raccolti da repository pubblici, dalla quale sono emersi 367 artefatti di informazioni personali identificabili e 182 credenziali. Alcune comunicazioni pubbliche degli autori hanno inoltre riferito una scansione preliminare di circa 7.000 trace pubbliche, nella quale erano stati individuati 62 API key, 33 indirizzi email e 33 password. Le due statistiche non devono essere confuse: appartengono a fasi e corpus differenti dell’analisi.

Questo dettaglio dovrebbe interessare soprattutto chi utilizza agenti di coding. Claude Code, Codex e sistemi analoghi stanno trasformando i log delle sessioni in una nuova forma di memoria operativa, dove possono convivere prompt, codice, chiamate agli strumenti, risultati intermedi, ragionamento e riferimenti a infrastrutture reali. Pubblicare una sessione su GitHub per chiedere aiuto su un bug può quindi equivalere, in determinate circostanze, a pubblicare un archivio di dati che l’autore non sapeva nemmeno di avere. Il vecchio consiglio “non committare le API key” resta valido; semplicemente, nel mondo degli agenti AI bisogna aggiungere “non pubblicare nemmeno ciò che il modello ha prodotto dietro le quinte”.

Esiste poi una dimensione di sicurezza ancora più delicata. I ricercatori hanno dimostrato che il meccanismo può essere sfruttato per recuperare informazioni pericolose che il modello aveva escluso dalla risposta visibile, ma che erano presenti nel processo di reasoning. Questo crea una separazione pericolosa tra safety dell’output e safety dello stato interno. Un sistema può quindi comportarsi correttamente davanti all’utente e contemporaneamente conservare, in una forma indirettamente recuperabile, informazioni che il sistema di sicurezza aveva deciso di non mostrare. La superficie d’attacco non è più soltanto il prompt o la risposta: diventa lo stato intermedio dell’agente.

Ancora più interessante è il quarto vettore individuato dagli autori: l’injection invisibile. Se un blob cifrato può essere manipolato, riutilizzato o introdotto in un workflow agentico e successivamente interpretato da un modello, un aggressore può tentare di nascondere istruzioni malevole dentro una parte che l’utente vede soltanto come una sequenza incomprensibile di caratteri. Il problema è particolarmente rilevante per sistemi multi-agent, nei quali un output prodotto da un modello viene automaticamente passato a un altro modello, magari con privilegi differenti. La vecchia separazione tra “dato” e “istruzione” diventa allora fragile: un oggetto apparentemente opaco può trasformarsi in istruzione quando attraversa il confine semantico di un altro modello.

Anthropic, OpenAI e Google sono stati informati attraverso responsible disclosure e hanno introdotto mitigazioni. Anthropic ha confermato di aver iniziato a implementare correzioni per i comportamenti di replay descritti nella ricerca, precisando che lo studio non ha comportato il recupero di chiavi di cifratura, l’accesso all’infrastruttura Anthropic o il recupero di dati personali dai sistemi dell’azienda. La documentazione attuale di Claude mostra inoltre che l’azienda tratta i thinking block come oggetti crittografati e impone specifiche modalità di gestione nel ciclo API.

La questione più importante, tuttavia, non è se una patch abbia chiuso questo specifico exploit. È l’architettura che lo ha reso possibile. I sistemi agentici stanno costruendo una nuova forma di distributed state in cui informazioni cifrate, contesto, memoria, tool call e reasoning attraversano modelli differenti. Se l’identità crittografica del dato non è legata anche a modello, sessione, utente, contesto e autorizzazione, la cifratura rischia di diventare una serratura montata su una porta che conduce a troppe stanze.

La sicurezza dei sistemi AI non può quindi essere valutata soltanto chiedendo se il modello rifiuta una richiesta pericolosa; bisogna chiedere cosa accade a ogni stato intermedio che il modello genera, dove viene conservato, chi può riutilizzarlo e quale altro modello può interpretarlo.

La faccenda ha infine una conseguenza strategica che Silicon Valley probabilmente preferirebbe lasciare in piccolo carattere. La difesa della proprietà intellettuale dei modelli frontier si è basata anche sull’idea che il reasoning interno fosse inaccessibile e che la distillazione dovesse essere ottenuta osservando milioni di output. Se invece le reasoning trace possono essere estratte attraverso un modello più economico dello stesso provider, il costo marginale dell’imitazione delle capacità diminuisce drasticamente. La ricerca non dimostra che specifici modelli siano stati addestrati attraverso questo attacco, né dimostra causalmente che un determinato modello open-weight sia stato distillato da un altro; mostra però che l’architettura rende tecnicamente plausibile un livello di model extraction molto più sofisticato di quello tradizionalmente considerato.

Il punto, per chi progetta infrastrutture AI, è quasi banale e proprio per questo viene spesso ignorato: la sicurezza non consiste nel nascondere un dato, ma nel controllare rigorosamente chi può trasformarlo nuovamente in significato. Un blob cifrato che viaggia tra client, API, modelli e agenti non è semplicemente un segreto; è una capacità computazionale differita. Se un altro modello può riattivarla, la superficie d’attacco non coincide più con la crittografia. Coincide con l’architettura e questa è una distinzione che, nella corsa alla prossima generazione di agenti autonomi, potrebbe valere più di qualche miliardo di parametri.