Stealing Reasoning Traces: The Encrypted Chain-of-Thought Flaw in Every Frontier LLM API

Researchers have shown that the encrypted "thinking" blocks frontier LLM APIs hand back to clients are not really sealed. They can be lifted out of one conversation and dropped into another, across sessions, across user accounts, and across models from the same provider.

The consequence is elegant and unpleasant. You do not need to jailbreak a frontier model to read its hidden reasoning. You take the strong model's encrypted reasoning block, feed it to a weaker and less heavily safeguarded model from the same provider, and ask that model to decode it. It prints the trace verbatim.

Per the paper's own framing, Haiku 4.5 can read Opus 4.8's thoughts.

The work, Stealing Reasoning Traces from Proprietary LLM APIs (arXiv:2608.09867), was submitted on August 10, 2026 by a team including Alexander Panfilov, David Schmotz, Ilia Shumailov, Luca Beurer-Kellner, Joachim Schaeffer, Ameya Prabhu, Jonas Geiping, and Maksym Andriushchenko, working out of the ELLIS Institute Tübingen and Max Planck Institute for Intelligent Systems.

TL;DR — what people are asking

What encrypted reasoning is, and why it exists

Reasoning models generate a hidden chain-of-thought before producing a visible answer. What you see in a chat UI is a summary. The raw trace is normally withheld, both to protect the provider's intellectual property and to keep the model's unfiltered intermediate thinking away from users. explainx.ai covered what those raw traces actually look like when they leak by accident in does Fable have an inner voice, and the mechanics of the technique itself in the chain-of-thought prompting guide.

So why does any of that reasoning reach the client?

Because API conversations are not always stateful sessions. In stateless mode, zero-data-retention mode, tool loops, and client-managed conversations, the client is responsible for carrying the transcript forward between turns. The provider needs the model's hidden state back on the next request. Their solution: encrypt the reasoning, hand it to the client as an opaque Base64 blob, and have the client return it untouched.

The design intent is reasonable. The client holds the state but cannot read it. The provider decrypts on receipt and continues.

That is the design. The implementation is where it comes apart.

The vulnerability: the blocks are portable

The paper describes the core issue as architectural rather than a coding bug. Encrypted blocks from one context are "fully compatible and interchangeable across different sessions, users, and models within a provider's ecosystem."

Portability across accounts implies something specific about the key management: the provider is almost certainly encrypting every client's reasoning under a single global key rather than a per-account or per-session key. If keys were scoped to an account, a block from account A would simply fail to decrypt under account B.

This matters most for anyone relying on zero-data-retention guarantees. ZDR means the provider is not storing your conversation. It does not mean your reasoning state is cryptographically isolated from every other customer's, and under a global key it is not.

The decryption jailbreak

The exploit built on top of that portability is the clever part.

Rather than attacking a frontier model's safety training directly, you take an encrypted reasoning block produced by that model and inject it into a weaker sibling model from the same provider. The weaker model decrypts it (the provider does, transparently, on the way in), sees the plaintext reasoning as legitimate context, and can be prompted to transcribe it.

The stronger model is never attacked. Its guardrails are never engaged. A smaller, cheaper, less-defended model in the same family does the reading, and the researchers report the same trick working across OpenAI and Google as well as Anthropic. For the general category this falls into, see explainx.ai's what is an AI jailbreak.

Four attack vectors

The paper enumerates four consequences.

The first vector reframes an argument explainx.ai has been tracking all year. Anti-distillation defenses exist precisely to stop competitors harvesting a frontier model's reasoning to train their own, which is the mechanic behind what is AI distillation, the Proxy-KD black-box distillation work, and the Anthropic/Alibaba fake-account allegations. Hiding the chain-of-thought was one of the main defenses. This paper says that defense had a hole in it.

The fourth vector is the one that should worry anyone building agent pipelines. A payload hidden inside an encrypted block is invisible to human review and to most log scanners, because the blob is expected to be unreadable noise. It travels through public agentic rollouts looking exactly like normal API bookkeeping.

The part that affects you today

Skip everything else if you are short on time. This is the actionable finding.

If you have ever publicly shared a Claude Code or Codex session log, the encrypted reasoning blocks in it can be decoded by anyone.

The researchers scraped public repositories, decoded 315,320 reasoning blocks, and recovered 367 PII artifacts and 182 credentials. Those numbers come from the paper's abstract. An earlier post from one of the authors described a preliminary scan of roughly 7,000 traces turning up 62 unique API keys, 33 email addresses, and 33 passwords, so the full run scaled the problem up by roughly two orders of magnitude.

The mechanism is straightforward once you see it. Developers share full agent traces constantly, in bug reports, gists, blog posts, and committed debug output. Everyone treats the encrypted blobs as unreadable noise and leaves them in. They were never unreadable.

Worse, the reasoning block can contain material the visible transcript does not. A model that reads a .env file, reasons about the key it found, and then writes a visible answer that never mentions the key has still put that key into its chain-of-thought.

What to do:

1. Find your shared traces. Search your repos, gists, issues, and posts for pasted agent sessions. Look for long Base64 blobs in thinking, reasoning, or signature fields.
2. Rotate anything the session touched. Not just secrets visible in the transcript. Anything the agent could have read and reasoned about during that session: API keys, tokens, database URLs, credentials in config files.
3. Strip reasoning blocks before sharing. Going forward, treat them as sensitive payload rather than protocol overhead.
4. Sanitize chat inputs. If your application forwards user-supplied content into an LLM API, an attacker who can inject JSON into your conversation stream can inject their own reasoning blocks. This is a real input-validation problem now, and it compounds the repo-scraping risks explainx.ai covered in GitLost and agentic workflow prompt injection.

The disclosure story is its own finding

This was reported before, and dismissed.

On May 29, 2026, Johns Hopkins cryptographer Matthew Green published a post on encrypted reasoning describing a weekend spent poking at these blobs. The findings anticipated much of the current paper: reasoning blocks could be replayed within a session, across sessions, and across entirely separate accounts. For OpenAI, they replayed across different models too, though Green noted the Claude models "got fussy" about that at the time.

Green also demonstrated the blocks were semantically active rather than inert, showing a case where a social security number reasoned about in one session reappeared, unprompted, in a different session on a different account after the block was replayed.

Green reported both results through the providers' bug bounty programs. Per that account, OpenAI called the report unreproducible. Anthropic said it did not see security implications in side channels or replays, while allowing it might update developer documentation to warn application developers.

Ten weeks later, a 116-page paper demonstrates credential extraction at scale, cross-model reasoning theft, and invisible prompt injection built on the same underlying flaw.

One researcher's summary of the situation was blunt: the encryption was done poorly across all three providers, which reads less as a deliberate tradeoff than as a symptom of shipping fast and missing basic security work. That assessment is worth weighing against the counter-argument the labs made at the time, which was that replays and side channels have no clear exploit path. The paper is the rebuttal.

Green's crypto observations, for the curious

The structural details from that earlier analysis hold up as useful context:

• Anthropic's block includes a field labeled a "signature" that, on testing, contained no actual signature. The various opaque fields mutually authenticate, so you cannot swap individual fields between blocks or tamper with them.
• The 12-byte IVs suggest GCM or ChaCha, and Green flagged them as probably too short.
• OpenAI's format appeared to be based on the Fernet token standard, though that was inference rather than confirmation.
• Tampering with any ciphertext byte produces a clean API rejection. Replaying an unmodified block produces no error at all. That asymmetry is the whole vulnerability in one sentence.

There is also a side channel independent of the encryption. If you can induce a model to perform secret-dependent reasoning (cheap computation when a hidden bit is 0, expensive computation when it is 1), the difference shows up in reasoning token counts, block length, and even wall-clock response time. Green demonstrated bit-by-bit extraction of a byte this way. That one cannot be patched with better cryptography, because the leak is in how much the model thinks, not in what it wrote down.

One of the paper's authors separately noted that extracted reasoning token counts matched billed API thinking tokens 1:1 for most prompts tested, which is a neat validation that the extracted traces are the real thing rather than a reconstruction.

The distillation-detection angle

One researcher posted a preliminary observation worth flagging carefully: Kimi K3's output reportedly changes when prefilled with Opus reasoning, while Inkling and DeepSeek do not respond the same way, and Kimi's output does not change when prefilled with Inkling reasoning.

The suggestion is that this asymmetry could be a fingerprint of training on a particular model's traces.

Treat this as an untested hypothesis, not a finding. It is a single practitioner's observation posted to social media, not part of the peer-reviewed paper, and there are plenty of innocent explanations for differential sensitivity to prefilled context. But if the technique holds up under scrutiny, it points somewhere genuinely new: reasoning-trace replay as a forensic tool for detecting distillation, which would matter a great deal to the disputes covered in explainx.ai's pieces on the White House, Moonshot AI, and distillation allegations.

What providers should fix

The paper proposes cryptographic and system-level mitigations following responsible disclosure. The obvious ones follow directly from the failure mode:

None of that is exotic. Scoping a token to the session and identity that produced it is standard practice, and its absence here is the gap.

The side channel is harder. As Green noted, if a model reasons over a secret, the shape of that reasoning leaks, and the fix would require policy gates applied before the model reasons about something rather than after. That is awkward, because deciding whether to apply a gate usually requires reasoning.

What this means for teams building on these APIs

Three durable takeaways.

Encrypted does not mean isolated. Opacity to you is not confidentiality from everyone. A blob you cannot read may still be readable by someone who can replay it into a cooperative model.

Agent session logs are now sensitive artifacts. They were already worth reviewing for visible secrets. They now need to be treated as containing hidden ones, and the safe default is to strip reasoning blocks before anything is published.

Hidden reasoning is a weaker IP moat than it looked. If chain-of-thought concealment is part of your competitive defense, this paper narrows it considerably.

Related on explainx.ai

• Does Fable have an inner voice? Leaked reasoning and caveman CoT
• GitLost: agentic workflows and prompt injection in private repos
• What is AI distillation? Knowledge transfer explained
• Proxy-KD: black-box LLM distillation
• Anthropic vs Alibaba: distillation and 25,000 fake accounts
• The White House, Moonshot AI, and distillation allegations
• What is an AI jailbreak? Explained
• Chain-of-thought prompting: zero-shot and few-shot guide

Official source: Panfilov, Schmotz, Shumailov, Beurer-Kellner, Schaeffer, Prabhu, Geiping, and Andriushchenko, Stealing Reasoning Traces from Proprietary LLM APIs, arXiv:2608.09867, submitted August 10, 2026.

Attack descriptions and figures come from the paper's abstract and the authors' public posts as of August 11, 2026; the full 116-page text may contain corrections or additional caveats. The account of the May 2026 disclosure, including the providers' responses, comes from Matthew Green's published write-up and has not been independently confirmed with Anthropic or OpenAI. The Kimi K3 distillation observation is one researcher's preliminary social-media post, not a peer-reviewed result, and is flagged as such above. Providers may have shipped mitigations between the paper's submission and your reading of this — check their security advisories for current status. Nothing here is a guide to executing these attacks.