Encrypted Reasoning Isn't Safe: Researchers Decoded 315,000 Hidden Thought Blocks From OpenAI, Anthropic and Google (2608.09867)

The paper "Stealing Reasoning Traces from Proprietary LLM APIs" (arXiv 2608.09867, posted 10 August 2026 in cs.CR) reports that the encrypted reasoning blocks returned by Anthropic, OpenAI and Google APIs can be replayed into a weaker sibling model and transcribed in plaintext. The authors, from MATS Research, ELLIS Institute Tübingen, the Max Planck Institute for Intelligent Systems, Snyk and others, say they decoded 315,320 blocks from public agent logs and recovered 367 PII artifacts and 182 credentials.

The cipher was not broken. The flaw is that the blocks are portable, and the headline counts are bigger than the genuine-user counts, as the sections below show.

What problem does this paper solve?

It shows that "encrypted" chain-of-thought is not confidential in practice. Providers hide reasoning to limit distillation and leakage, and return it to the client as an encrypted block that must be sent back on the next request, according to the paper.

That design means the client holds ciphertext it cannot read. The authors argue this creates two problems. A competitor can recover a proprietary model's reasoning, and a developer who publishes an agent log may publish secrets inside blocks they never saw.

The idea builds on Matthew Green's May 2026 post, which showed blobs replaying across sessions and accounts. For background on why reasoning traces matter, see our explainers on chain-of-thought prompting and DeepSeek-R1. Refusal behaviour of the kind the attack sidesteps comes from post-training, covered in our InstructGPT and RLHF explainer.

How does the attack work?

The attacker takes an encrypted block from a strong, safeguarded model and sends it to a weaker model from the same provider, which is prompted to copy the reasoning into the visible answer. In the paper's Figure 1, an Opus 4.8 block is sent to Haiku 4.5 with a request to transcribe it inside <thinking-copy> tags, in two API calls.

The paper separates three kinds of compatibility, all as of July 2026:

• Cross-session: blocks can be replayed in a different order or in a later session.
• Cross-user: a block from another user's session is accepted.
• Cross-model: a block from one model is accepted by another.

The authors say providers "appear to be using a single global key" to encrypt and authenticate every block. Green was more guarded, writing that providers are "probably" doing so. No provider documents the mechanism, per the paper.

Source: arXiv 2608.09867, Section 2.4. Lab-reported.

The authors also say a weaker compatible model lowers the difficulty of extraction, because the attacker no longer has to bypass the frontier model's refusal training and system-level defenses such as input and output filters. They estimate that decoding 10,000 traces with 12,000-token input and output windows would cost approximately $720 at standard Claude Haiku 4.5 API rates (an authors' estimate, based on pricing cited from 2025).

What are the results?

The authors report four abuse paths and one large-scale measurement. The scale result is the one with real numbers. The other three are proofs of concept.

All figures are the authors' own claims. Source: arXiv 2608.09867.

How many secrets were found?

The numbers depend on which population you count. The abstract's 367 PII artifacts and 182 credentials come from Figure 6, which includes benchmark sources and totals 912 distinct artifacts. Benchmarks such as ClawBench supply synthetic personas, which inflates the personal-information counts.

Restricting to genuine user sessions, the paper reports 704 distinct privacy artifacts: 62 API keys, 33 passwords, 24 access tokens, 7 private keys and 30 personal emails. The project page lists 126 credentials for that restricted set, which matches the sum of the four credential types.

Prevalence is low per block and notable per session. Of 315,320 decoded blocks, 0.3% (1,028) contained at least one real privacy leak. Of 6,708 sessions, 4.9% (328) leaked at least one real sensitive item.

One finding should change how people sanitise logs. Of the 704 genuine artifacts, 64 appeared only inside reasoning blocks. A recurring trigger was a user asking the agent to clean up or anonymise the session, after which the model restated the sensitive values in its hidden reasoning, according to the authors. The authors add that 62 API keys would have stayed exposed even if every user had scrubbed the visible text.

Does the evidence hold up?

Partly. The attack itself has independent support, but the leak statistics and the fidelity claim rest on methods with real gaps.

Independent replication. The Embrace The Red blog reports recovering reasoning from GPT-5.6 Sol using Luna, across models, sessions and accounts. The blogger used a different endpoint than the paper, and saw tests fail for a few days before working again.

Fidelity is indirect. The authors check that decoded token counts track API-reported thinking tokens on 120 Codeforces problems. They also state they cannot guarantee that extracted thoughts match the private reasoning, since no ground-truth plaintext exists and the decoders are stochastic. The same replicator was not convinced the output was verbatim, though it recovered substantial content.

Labelling uses LLM judges. A first-pass judge (Haiku 4.5) flagged 27,165 of the 315,320 blocks (8.6%) in a deliberately high-recall pass, and a second-pass classifier decided which items were genuine. The paper's appendix describes this pipeline, but the recovered secrets were deleted after aggregate counting, so the labelled set cannot be re-audited.

Small proofs of concept. The jailbreak vector is one prompt on one model. The prompt-injection vector is one cross-model example and one poisoned long-horizon trace. They show feasibility, not a rate.

Version-bound. Testing ran in early July 2026 against the API versions then available, and the authors say provider changes can alter the results.

How does it compare with related work?

The paper sits on top of Green's May 2026 post, and it extends a line of work on reconstructing reasoning from what a model exposes. Green found that replay worked across sessions and accounts, and for OpenAI across models. He reported the issue to OpenAI and Anthropic through bug bounty programs. He wrote that OpenAI called his report unreproducible, while Anthropic said it saw no security implications in side channels or replays.

The paper also cites Zhang et al. (2026a), which trained a trace-inversion model to synthesise reasoning from a model's visible outputs and summaries. As the paper describes it, that approach raised a fine-tuned Qwen2.5-7B-Instruct from 68.4% to 76.0% on MATH500 over answer-only distillation, but recovered only surrogate traces. That figure is the paper's summary of Zhang et al., not a result from this paper. The new paper's claim is that raw reasoning can be recovered directly.

The authors' September update adds a second method, a "scratchpad attack" they credit to Can Bölük, in which the target model is told to write its reasoning into a visible tool. That attack needs no encrypted block at all.

What does a working researcher take from this?

Treat any opaque reasoning field as readable by anyone who can send it to a compatible model. The authors say users should never treat encrypted blocks as confidential storage.

Practical steps that follow from the paper:

1. Strip reasoning blocks and opaque reasoning fields from agent transcripts before publishing a dataset or log.
2. Do not rely on plaintext sanitisation. The model may restate secrets in hidden reasoning, and you cannot read it.
3. Assume previously published traces are decodable. The Cloud Security Alliance note says published transcripts from the old scheme remain a residual exposure until scrubbed.
4. Do not resume shared sessions blindly. A replayed block can carry an instruction that never appears in visible text.
5. Do not treat API reasoning summaries as ground truth. In the paper's one worked example (AIME 2025 Problem 14), the decoded Opus 4.8 reasoning states the answer before attempting a solution, while the summary shows a solving process.

For vendors, the authors propose server-side storage with an opaque ID, binding each envelope to a user and conversation, cross-model isolation at API gateways, revocation of suspicious signatures and refusal training against transcription prompts. They also argue a structural limit: any model that processes a block must decrypt it, so blocks can never be more than semi-hidden.

Safety researchers should note the other side of the trade. The paper says encryption lets a model reason about harmful content without disclosing it, but also hides injections and privacy leaks from users. It suggests that unencrypting older, non-frontier generations may be worth considering for broader oversight.

What's still unclear?

Is the problem fixed? Sources disagree. The Cloud Security Alliance says all three providers deployed server-side fixes binding blocks to model, session and user, and The Hacker News reports that the authors' reproducibility statement says the main attack was no longer reproducible as of August 2026. But the authors' own 30 September 2026 update, with status as of 13 September, says replay still works intermittently on Microsoft Azure for every OpenAI model and for Anthropic up to Sonnet 5. It also says the scratchpad attack still extracts reasoning from every OpenAI model, Opus 4.8 and Sonnet 5. That update is self-reported by the authors.

Is there one global key? The paper says providers "appear" to use one, and Green said "probably". It is an inference from replay behaviour.

Was anyone harmed? The Hacker News says the report does not document malicious exploitation in the wild. The 704 artifacts come from public logs the authors chose to scan, in a non-exhaustive search, and they were deleted after counting.

How faithful are the decoded traces? The token-count check is consistent with faithful decoding but cannot prove it. A ground-truth test, for example against an open-weight model with the same envelope design, would settle more.

How big is the real exposure? The authors assume private and local transcripts are more affected than public ones. That is a hypothesis, and the paper gives no measurement for it.

The weakest link in the argument is the leak measurement: LLM-judged, deleted afterwards, and mixed between benchmark and genuine sessions. The architectural point, that a portable block plus a weaker decoder defeats the safeguard, is better supported.

Reading basis: the full PDF of arXiv v1 and the authors' September update, not only the abstract. Code: the project page hosts the paper and update, and the attack details are in Appendices C.1 to C.3 of the paper.