Gli sviluppatori avevano fatto quello che, in un ambiente aziendale, viene normalmente considerato un comportamento prudente: avevano ripulito i log delle sessioni AI prima di pubblicarli su GitHub e Hugging Face. Password, chiavi API e dati personali erano stati eliminati dal testo visibile. Il problema è che il testo visibile non era l’intera sessione. Dentro i blocchi cifrati di ragionamento restituiti dai modelli rimanevano informazioni che nessuno aveva cancellato, semplicemente perché nessuno poteva leggerle. Un gruppo di ricercatori dell’ELLIS Institute Tübingen, del Max Planck Institute for Intelligent Systems, dell’Università di Tübingen, di MATS e di Snyk ha dimostrato che quei blocchi potevano essere recuperati attraverso modelli più debolmente protetti dello stesso provider.
Il paper, pubblicato il 10 agosto 2026 con il titolo Stealing Reasoning Traces from Proprietary LLM APIs, descrive una vulnerabilità architetturale che coinvolge i meccanismi utilizzati da Anthropic, OpenAI e Google per mantenere il reasoning tra chiamate API. Il modello produce un blocco di ragionamento cifrato, il client lo riceve e lo restituisce nelle richieste successive, consentendo al modello di continuare il proprio processo senza esporre direttamente la chain of thought all’utente. La cifratura protegge il contenuto dagli occhi del cliente, ma secondo gli autori non vincolava sufficientemente quel contenuto alla sessione, all’utente o al modello che lo aveva prodotto. Il risultato è stato sorprendentemente poco sofisticato: un blocco generato da un modello frontier poteva essere trasferito a un modello più debole della stessa famiglia e utilizzato come input per recuperarne il contenuto.
L’esempio più intuitivo riguarda Claude Opus 4.8 e Claude Haiku 4.5. I ricercatori hanno catturato un blocco di reasoning prodotto da Opus e lo hanno passato a Haiku chiedendogli di trascriverlo. Il modello più piccolo ha restituito il contenuto del reasoning in chiaro. Il punto importante è che non era necessario convincere Opus a rivelare il proprio ragionamento e non era necessario attaccare direttamente il modello frontier. Il lavoro sporco veniva affidato al fratello minore, meno protetto e utilizzato come una sorta di decoder comportamentale. Gli esperimenti hanno mostrato forme analoghe di compatibilità cross-model anche negli ecosistemi OpenAI e Google.
Qui la parola “cifrato” rischia di creare una falsa sensazione di sicurezza. Un blocco può essere crittograficamente integro e tuttavia essere utilizzabile nel posto sbagliato. Il problema descritto dai ricercatori non consiste semplicemente nel rompere una cifratura matematica, ma nella possibilità di riutilizzare un artefatto autenticato all’interno di un diverso contesto nel quale un altro modello può interpretarlo. La differenza è enorme. Non serve rubare la chiave privata del provider; basta trovare un componente autorizzato a consumare quel blocco e sufficientemente poco addestrato a rifiutarsi di riprodurlo.
La parte più preoccupante riguarda però i dati reali. I ricercatori hanno raccolto 6.708 traiettorie di agenti pubblicate su GitHub e Hugging Face e hanno ricostruito 315.320 blocchi di reasoning. Nell’insieme analizzato hanno identificato 367 artefatti PII e 182 credenziali. Nelle sessioni considerate autentiche sono comparsi 62 API key, 33 password, 24 access token, 7 private key, 30 indirizzi email personali, oltre a nomi, indirizzi e altri identificativi tecnici. Il paper precisa che il campione è mirato e non consente di stimare la prevalenza del problema sull’intero utilizzo delle API.
C’è un numero che dovrebbe interessare soprattutto chi gestisce DLP, compliance e governance dei dati: 64 degli artefatti sensibili individuati nelle sessioni autentiche non comparivano nel testo visibile della conversazione. Erano presenti soltanto nel reasoning nascosto. Significa che una procedura di sanitizzazione applicata esclusivamente al transcript avrebbe potuto dichiarare la sessione pulita mentre il dato sensibile era ancora lì, dentro un oggetto opaco che l’organizzazione non aveva modo di ispezionare.
L’aspetto quasi grottesco è che, in alcuni casi, la stessa procedura di anonimizzazione contribuiva a creare il problema. Chiedere a un agente di ripulire una sessione significa costringerlo a individuare ciò che deve essere rimosso. Il modello può quindi ripetere nel proprio reasoning la password o la chiave API che sta cercando di cancellare dal testo visibile. L’operatore vede il risultato pulito e pubblica la sessione; il dato resta invece all’interno del blocco cifrato. La sanitizzazione ha funzionato perfettamente nel luogo sbagliato. È una di quelle piccole tragedie dell’automazione che nei diagrammi architetturali tendono a scomparire con una freccia elegante e la scritta “secure”.
Il paper mostra anche un secondo vettore molto più insidioso: la prompt injection invisibile. Un’istruzione malevola può essere incorporata in un blocco di reasoning cifrato e viaggiare insieme alla sessione. Quando un altro agente riprende quella traccia per svolgere un compito apparentemente innocuo, può interpretare l’istruzione nascosta come parte del proprio ragionamento precedente e produrre un’azione indesiderata. Nei test descritti dagli autori, un payload di esfiltrazione inserito nella traccia ha portato l’agente a incorporare nel proprio script un comportamento che trasferiva un file verso un server controllato dall’attaccante. Il transcript visibile rimaneva pulito.
Questo cambia anche il modo in cui dovrebbe essere interpretato il rischio degli agenti. Un sistema di monitoraggio che controlla soltanto prompt, risposte e tool call visibili può avere un punto cieco precisamente nel luogo in cui l’agente conserva la continuità del proprio ragionamento. Il problema non è più soltanto prompt injection nel testo dell’utente. È la possibilità che un artefatto apparentemente non leggibile diventi una memoria operativa persistente e venga successivamente interpretato da un altro componente della catena.
Per banche, assicurazioni, ospedali e aziende sottoposte a obblighi di audit, questa distinzione è molto più importante della singola vulnerabilità ormai corretta. Un framework di model risk tende naturalmente a classificare il modello: questo è critico, questo è moderato, questo serve soltanto per routing o summarization. Ma se il modello meno protetto può consumare gli artefatti prodotti da quello più sensibile, la classificazione per modello diventa incompleta. Il rischio appartiene al confine di fiducia che unisce i modelli, non soltanto al modello che produce la risposta finale.
La conseguenza economica è altrettanto concreta. Le aziende stanno costruendo architetture multi-model per ridurre i costi: un modello frontier per i casi complessi, un modello più piccolo per classificazione, sintesi, routing e attività ripetitive. È una scelta perfettamente razionale dal punto di vista del costo per token. Ma se quei modelli condividono chiavi, sessioni, memoria o artefatti di reasoning, il modello economico può diventare l’anello che determina la sicurezza dell’intero sistema. Il modello più costoso paga per essere sofisticato; quello più economico può essere pagato per fare il lavoro di sicurezza che il primo non può più fare. È una curiosa forma di ottimizzazione finanziaria.
Il punto più serio riguarda quindi l’auditabilità. Se un’organizzazione non può leggere un artefatto che contiene informazioni utilizzate dall’agente per decidere o agire, deve almeno sapere esattamente dove quell’artefatto vive, chi può consumarlo, per quanto tempo resta valido, con quali modelli può essere riutilizzato e quali garanzie impediscono che venga trasferito tra utenti o sessioni. Un record che l’azienda non può interpretare non diventa automaticamente irrilevante dal punto di vista regolamentare. Al contrario, può diventare precisamente il punto nel quale la capacità di dimostrare cosa è accaduto si interrompe.
La ricerca è stata sottoposta a responsible disclosure e gli autori riferiscono che, dopo gli interventi dei provider, gli attacchi pubblicati non risultavano più funzionanti nelle condizioni precedentemente testate. Il paper propone inoltre mitigazioni crittografiche e di sistema per legare maggiormente i reasoning block al contesto nel quale sono stati prodotti. (arXiv)
La vulnerabilità verrà probabilmente ricordata come un problema risolto. Sarebbe un errore ricordarla soltanto così. Il dato più importante non è che qualcuno abbia trovato un modo per recuperare una chain of thought cifrata. È che abbiamo costruito sistemi nei quali il cliente non può leggere un artefatto che il cliente stesso deve conservare e restituire, e poi abbiamo iniziato a trattare quell’artefatto come se fosse automaticamente sicuro proprio perché non potevamo leggerlo. La sicurezza dell’AI enterprise non può essere costruita sull’idea che ciò che non vediamo non esista. Nel mondo degli agenti autonomi, spesso è esattamente il contrario.
Paper: Alexander Panfilov, David Schmotz, Ilia Shumailov, Luca Beurer-Kellner, Joachim Schaeffer, Ameya Prabhu, Jonas Geiping, Maksym Andriushchenko, Stealing Reasoning Traces from Proprietary LLM APIs, arXiv:2608.09867, 10 agosto 2026. (arXiv)