Il pensiero segreto dei modelli AI non è poi così segreto: una vulnerabilità espone reasoning, dati privati e credenziali

La promessa era semplice, quasi rassicurante: i nuovi modelli di intelligenza artificiale possono ragionare internamente senza mostrare agli utenti la propria catena di pensiero. Anthropic, OpenAI e Google hanno progressivamente abbandonato la trasmissione in chiaro del chain-of-thought, sostituendola con blocchi opachi, firme o payload cifrati che il client deve restituire all’API per mantenere la continuità della conversazione. Una scelta architetturale elegante, almeno sulla carta, perché riduce lo storage lato server e protegge contemporaneamente proprietà intellettuale, meccanismi di sicurezza e informazioni potenzialmente sensibili. Il problema è che la sicurezza di un sistema distribuito raramente fallisce dove l’architetto ha disegnato il diagramma; spesso fallisce nel punto in cui due componenti, considerate innocue separatamente, vengono messe insieme. È precisamente ciò che descrive il paper “Stealing Reasoning Traces from Proprietary LLM APIs”, pubblicato su arXiv il 10 agosto 2026.

Il cuore della ricerca è una vulnerabilità di compatibilità tra reasoning trace cifrate. Secondo gli autori, i blocchi restituiti dalle API possono essere riutilizzati tra sessioni, utenti e, soprattutto, modelli differenti all’interno dello stesso ecosistema. Questo significa che il modello più potente può generare un reasoning trace protetto, mentre un modello più piccolo e meno severamente addestrato contro l’estrazione può essere utilizzato come una sorta di decoder. L’attaccante non deve quindi convincere direttamente il modello frontier a rivelare il proprio chain-of-thought; gli basta prendere il blocco prodotto dal modello più protetto e presentarlo a un altro modello compatibile, inducendolo a trascriverne il contenuto. È una forma di aggiramento particolarmente interessante perché sposta l’attacco dal bersaglio più difeso verso l’anello più debole dell’ecosistema.

La distinzione tecnica è importante. Il paper non descrive semplicemente un jailbreak tradizionale, nel quale un utente manipola il modello per ottenere una risposta che dovrebbe essere rifiutata. Descrive un problema architetturale legato alla portabilità delle informazioni interne. Le API moderne usano blocchi di reasoning opachi, spesso organizzati come buste AEAD, con nonce, authentication tag e ciphertext, mentre il client conserva il payload e lo restituisce nelle richieste successive. Questa architettura permette la statelessness, ma crea una superficie d’attacco se il sistema considera intercambiabili blocchi che, dal punto di vista della sicurezza, dovrebbero essere vincolati a uno specifico modello, utente, sessione o contesto.

La ricerca sostiene di aver verificato questa compatibilità su Anthropic, OpenAI e Google, con differenze importanti tra famiglie di modelli. Il problema è particolarmente evidente quando un reasoning trace prodotto da un modello avanzato può essere processato da un modello meno capace. In questa configurazione la gerarchia commerciale dei modelli diventa, paradossalmente, una gerarchia di sicurezza: il modello costoso può avere guardrail sofisticati, mentre quello economico e veloce può diventare il componente attraverso cui aggirarli. Il paper documenta compatibilità cross-model nelle famiglie Claude, GPT e Gemini secondo i test effettuati nel luglio 2026.

Le conseguenze economiche sono tutt’altro che teoriche. Il chain-of-thought contiene una quantità di informazione molto più densa rispetto alla risposta finale: non soltanto passaggi logici, ma ipotesi intermedie, risultati di strumenti, dati dell’utente e contesto operativo. Per un concorrente che voglia effettuare model distillation, ottenere direttamente queste tracce significa avere un dataset di supervisione molto più ricco rispetto alle sole risposte finali. Il paper osserva inoltre che l’estrazione può essere economicamente conveniente perché, una volta ottenuto il reasoning cifrato, l’attacco può essere condotto interrogando il modello decoder più economico anziché continuare a utilizzare il modello frontier. Gli autori stimano, per esempio, un costo nominale di circa 720 dollari per decodificare 10.000 tracce in una specifica configurazione basata sui prezzi di Claude Haiku 4.5.

Ancora più inquietante è il secondo livello del problema, quello della privacy. Gli autori hanno analizzato 6.708 traiettorie di agenti pubblicate su GitHub e Hugging Face, ricostruendo 315.320 reasoning block. L’analisi ha identificato 1.028 blocchi, pari allo 0,3%, contenenti almeno una potenziale violazione della privacy. Considerando le singole sessioni, 328 su 6.708, cioè il 4,9%, presentavano almeno un elemento sensibile. Nei dati relativi a sessioni di utenti reali sono stati individuati 62 API key, 33 password, 24 access token, 7 chiavi private, 30 email personali, oltre a nomi, indirizzi e altri identificativi.

Qui emerge una conseguenza che dovrebbe interessare immediatamente CIO, CTO, CISO e responsabili compliance. Un transcript apparentemente bonificato può non essere realmente bonificato. Un’organizzazione può eliminare dal testo visibile una password, un indirizzo email o un’informazione personale e pubblicare tranquillamente il log, mentre il dato potrebbe essere rimasto all’interno del reasoning block opaco. Gli autori osservano inoltre che in 64 degli artefatti recuperati dalle sessioni autentiche il dato sensibile non era presente nella conversazione visibile. In alcuni casi potrebbe essere stato introdotto dal modello nella propria elaborazione interna o essere rimasto nel payload dopo che l’utente aveva ripulito il testo. La crittografia, quindi, non elimina il rischio privacy: può semplicemente renderlo invisibile a chi dovrebbe controllarlo.

Il terzo rischio riguarda la sicurezza degli agenti. Una reasoning trace cifrata non è necessariamente soltanto un contenitore passivo di informazioni; secondo gli esperimenti descritti nel paper può diventare anche un vettore di prompt injection invisibile. Gli autori mostrano proof-of-concept nei quali un’istruzione malevola viene incorporata nel reasoning e successivamente trasferita a un’altra sessione. Il modello che riprende il workflow può interpretare quel contenuto come parte del proprio ragionamento precedente e quindi eseguire un’azione che l’utente non ha mai richiesto esplicitamente. Questo è particolarmente serio nei sistemi agentici, dove il modello non si limita a rispondere, ma può modificare file, utilizzare strumenti, eseguire codice o interagire con servizi esterni.

La lezione tecnologica è più ampia della singola vulnerabilità. Per anni il settore ha trattato la crittografia come una specie di mantello dell’invisibilità: se il dato non è leggibile dall’utente, si presume che sia protetto. Ma un modello che deve necessariamente ricevere e processare quel dato possiede, direttamente o indirettamente, il contesto necessario a interpretarlo. La cifratura del trasporto non trasforma automaticamente il contenuto in un segreto assoluto. Gli stessi autori sottolineano che i reasoning block devono essere considerati soltanto semi-nascosti e non come un archivio confidenziale nel quale depositare informazioni sensibili.

La soluzione proposta passa da un ripensamento dell’architettura. Una possibilità è mantenere i reasoning trace interamente lato server, restituendo al client soltanto un identificatore casuale attraverso il quale recuperare lo stato necessario. È più costoso, più complesso e meno elegante dal punto di vista della statelessness, ma elimina dal client il payload che rappresenta il vero oggetto d’attacco. Una seconda strada consiste nel vincolare crittograficamente ogni reasoning block al proprio contesto, incorporando nell’autenticazione elementi come identificatore dell’utente, sessione, modello e storia della conversazione. In questo modo un blocco valido per un modello o una sessione non sarebbe automaticamente valido altrove.

Per le aziende che stanno costruendo agenti AI, il messaggio è ancora più concreto. I transcript grezzi delle sessioni non dovrebbero essere considerati innocui soltanto perché le parti visibili sono state anonimizzate. Il paper raccomanda di eliminare completamente reasoning block e campi opachi prima della pubblicazione di traiettorie o log che abbiano trattato dati privati, e di evitare la conservazione o il commit nei repository condivisi di transcript contenenti firme e payload di reasoning. È una disciplina che assomiglia molto alla gestione dei segreti nel software tradizionale, con una differenza sostanziale: questa volta il segreto può essere nascosto in una parte del sistema che l’utente non è nemmeno in grado di leggere.

C’è infine un dettaglio che cambia radicalmente il modo in cui questa ricerca dovrebbe essere letta. Gli autori dichiarano che, ad agosto 2026, gli attacchi descritti non sono più riproducibili nella forma originale perché i provider hanno implementato mitigazioni dopo la disclosure responsabile. Il team afferma di aver comunicato i risultati ai principali provider, a Microsoft e a Hugging Face e di non essere più riuscito a replicare gli stessi attacchi successivamente. Gli esperimenti complessivi hanno inoltre richiesto circa 30.000 dollari di crediti API.

Questo rende il paper meno simile alla solita storia apocalittica sull’AI e molto più interessante dal punto di vista industriale. La vulnerabilità originale può essere stata corretta, ma il principio architetturale rimane. Quando un sistema distribuisce stato crittografato al client, permette il replay tra componenti e affida a modelli diversi la capacità di interpretare quello stato, sta creando una nuova categoria di superficie d’attacco che non appartiene più soltanto alla cybersecurity tradizionale né soltanto alla sicurezza dei modelli. È sicurezza dell’architettura AI.