# The Chain-of-Thought You Sealed Isn't Secret > Source: > Published: 2026-08-11 18:08:58+00:00 [AI](https://sourcefeed.dev/c/ai)Article # The Chain-of-Thought You Sealed Isn't Secret A new attack replays encrypted reasoning blocks into a weaker sibling model that reads them back in plaintext. [Priya Nair](https://sourcefeed.dev/u/priya_nair) The industry's answer to "how do we let developers keep chain-of-thought in the context without leaking it" turned out to be a bearer token with no name on it. A new preprint, [Stealing Reasoning Traces from Proprietary LLM APIs](https://arxiv.org/abs/2608.09867), shows that the encrypted reasoning blocks Anthropic, OpenAI, and Google hand back to clients can be replayed into a weaker model from the same provider, which will then happily read them out in plaintext. No memory corruption, no timing side-channel, no stolen key. You just ask a less-guarded sibling to translate. It's a clean result, and it deserves to be read less as "encryption broken" than as a design assumption that never held up: that an opaque blob sitting in a developer's request history is safe because it's opaque. ## What the blocks actually are When you turn on reasoning mode today, none of the big three send you the raw chain-of-thought. They send a sealed object you're expected to echo back on the next turn so the model can continue where it left off. Anthropic's [extended thinking](https://docs.anthropic.com/en/docs/build-with-claude/extended-thinking) returns signed `thinking` blocks and, in some cases, `redacted_thinking` — encrypted content the client stores verbatim. OpenAI's Responses API does the same through `encrypted_content` on reasoning items, the mechanism that lets zero-data-retention customers keep [reasoning](https://platform.openai.com/docs/guides/reasoning) state without OpenAI persisting it server-side. Google's Gemini attaches `thoughtSignature` values you're required to pass back to keep [thinking](https://ai.google.dev/gemini-api/docs/thinking) coherent across tool calls. The rationale is defensible on its face. Providers want to hide the chain-of-thought for two reasons: it's a distillation target (raw traces are gold for training a competitor), and it sometimes contains reasoning that's unsafe even when the final answer is scrubbed. Encrypting it and pushing storage to the client solves the retention problem and, in theory, the confidentiality one. The flaw is that the sealed blob carries no binding. The researchers — a group including Jonas Geiping, Ilia Shumailov, Maksym Andriushchenko, and Alexander Panfilov — found the blocks are interchangeable across sessions, users, and models inside a single provider's ecosystem. That interchangeability isn't an accident; it's what lets you plan with a frontier model and switch to a cheaper one mid-conversation without dropping context. But it means an encrypted trace from the strong model is a valid input to the weak one. Feed it in, and the provider decrypts it server-side into the weak model's context. Now the reasoning lives in a model whose safety tuning is thinner. Prompt it to repeat what it "just thought," and out comes the plaintext. ## Four ways it bites The paper builds four attacks on that one primitive, and they hit different people. **Anti-distillation collapses.** The whole point of hiding traces is to stop rivals from cloning your model's reasoning. If a weaker sibling will decode a stronger sibling's trace on demand, the moat is a screen door. Anyone with an API key can harvest frontier reasoning. **Session logs become a data spill.** This is the one that should worry ordinary developers. Teams paste raw API responses — encrypted blocks and all — into GitHub issues, gists, eval datasets, and debugging threads, assuming the sealed part is inert. The authors ran ~315,000 such blocks through the decode trick and pulled out 367 pieces of PII and 182 credentials that people had unknowingly published. If you log full responses, you may already have leaked reasoning that quoted a user's prompt back to itself. **Hidden-hazard reasoning surfaces.** Providers sometimes let a model reason through dangerous material and then refuse or sanitize the visible answer. Decode the trace and the sanitization is moot — the hazardous content was in the block the whole time. **Agentic pipelines get an invisible injection vector.** A malicious encrypted block, dropped into a public agent's history, can smuggle instructions the operator can't see because the payload is, by design, unreadable to them. ## The honest caveats Two things keep this from being a five-alarm fire. First, the acute window is closed: the authors say all three providers acknowledged the report and the attacks stopped reproducing, which reads as quiet server-side patches — likely tighter binding of blocks to a session or model. Details weren't published, and no vendor has described a fix, so treat "patched" as the researchers' observation, not a guarantee about your account. Second, the sharper claim floating around — that a *single global key* enabled cross-account replay — comes from third-party analysis, not the paper's own wording. The verified finding is interchangeability across sessions and models; whether that traces to one key or looser scoping is inference. Don't repeat the key detail as fact. ## What developers should take from it The tactical advice is boring and correct: stop treating encrypted reasoning blocks as safe to publish. Scrub them from anything that leaves your trust boundary — issues, shared eval sets, support tickets, logs that feed a third-party observability tool. If your platform stores full API responses, the reasoning blocks are as sensitive as the prompts that produced them, because they often *contain* those prompts. That's a data-classification decision worth making now, before whatever binding the vendors added is the only thing standing between your logs and a decoder. The strategic lesson is bigger, and it's aimed at the vendors. "Hide the chain-of-thought" has quietly become a load-bearing safety and IP strategy across the frontier labs, and this is a reminder that obscurity is not confidentiality. A trace you send to the client is a trace you've disclosed; encryption only helps if the ciphertext is bound to the one context allowed to open it, and it wasn't. The multi-model-conversation feature that made these blocks portable is genuinely useful, which is exactly why the fix is hard — you can't bind a block to a single model without breaking model-switching, and you can't bind it to a single request without breaking multi-turn. The most likely durable answer isn't better crypto. It's for providers to stop pretending reasoning is a secret they can share with you and still keep. Either the trace is yours — you paid for the tokens — or it never leaves their servers. The middle ground, an encrypted souvenir you carry but can't read, was always going to attract someone clever enough to find the model that could read it for you. ## Sources & further reading - [Stealing Reasoning Traces from Proprietary LLM APIs](https://stolen-thoughts.com/)— stolen-thoughts.com - [Stealing Reasoning Traces from Proprietary LLM APIs](https://arxiv.org/abs/2608.09867)— arxiv.org - [Encrypted reasoning cracked across Anthropic, OpenAI, Google](https://aiweekly.co/alerts/encrypted-reasoning-cracked-across-anthropic-openai-google)— aiweekly.co - [Stealing Reasoning Traces from Proprietary LLM APIs](https://news.ycombinator.com/item?id=49257876)— news.ycombinator.com [Priya Nair](https://sourcefeed.dev/u/priya_nair)· AI & Developer Experience Writer Priya covers AI frameworks, developer productivity tooling, and the startup ecosystem across South and Southeast Asia, bringing a researcher's rigour and a practitioner's empathy to every story. She is deeply sceptical of benchmarks and asks hard questions so her readers don't have to. ## Discussion 0 No comments yet Be the first to weigh in.