Encrypted reasoning blobs are replayable — and your published logs leak secrets
An August 2026 paper shows the encrypted chain-of-thought blocks returned by OpenAI, Anthropic and Google are interchangeable across sessions, users and models. Decoding 315,320 blocks from public repos recovered 367 PII artifacts and 182 credentials.
What is this?
Reasoning models no longer show you their raw chain-of-thought. To keep the reasoning usable across turns without storing it server-side, the major providers hand it back to the client as an encrypted, opaque block that the application replays with each subsequent request. OpenAI returns encrypted reasoning items, Anthropic carries reasoning in an encrypted signature on thinking blocks, and Google uses encrypted thought signatures.
On 10 August 2026, Alexander Panfilov, David Schmotz, Ilia Shumailov, Luca Beurer-Kellner, Joachim Schaeffer, Ameya Prabhu, Jonas Geiping and Maksym Andriushchenko published Stealing Reasoning Traces from Proprietary LLM APIs (arXiv:2608.09867). Their finding is architectural, not cryptographic: those blocks are fully compatible and interchangeable across sessions, users and models inside a single provider’s ecosystem.
The practical consequence is the part worth acting on. Developers publish agent session logs — Codex sessions, Claude Code transcripts, benchmark rollouts — with the encrypted blocks intact, assuming they are inert. They are not. Decoding 315,320 reasoning blocks scraped from public repositories recovered 367 PII artifacts and 182 credentials, including API keys, passwords and private keys.
How it works
The encryption is never broken and no key is ever obtained. The attack works because the provider accepts an intact blob as valid context, regardless of who produced it.
The method has three moves. Lift an encrypted reasoning block from somewhere it was published. Replay it into a weaker, less heavily safeguarded model from the same provider — the paper uses Claude Haiku 4.5 for Claude traces, GPT-5.6 Luna for GPT traces, Gemini Robotics ER-1.6 for Gemini traces. Then ask that model to transcribe the thought attached to its turn. The stronger model that produced the reasoning is never jailbroken at all; a cheaper sibling acts as what the authors call a fuzzy decoder.
# Conceptual shape only — no working payload
[ session A, user 1, strong model ] -> reasoning block (encrypted, base64)
|
published in a repo / shared trace
|
[ session B, user 2, weak model ] <- same block replayed as context
-> "transcribe the attached thought"
Johann Rehberger independently reproduced the technique against OpenAI on 16 August 2026, recovering a password that had been present in a reasoning trace generated under a different account. He also observed the attack failing for roughly three days and then working again — a useful reminder that “it stopped reproducing” is not the same as “it is fixed”.
The paper documents four distinct abuse paths: circumventing anti-distillation protections, large-scale private data extraction from published traces, recovery of hazardous content the model reasoned about before safely refusing in visible output, and invisible prompt injection — a payload hidden entirely inside an opaque block, which poisons an agent rollout without ever appearing in readable text.
This builds directly on work by Johns Hopkins cryptographer Matthew Green, who showed on 29 May 2026 that these blobs replay across sessions and accounts. Green reported it through the providers’ bug-bounty programmes; per his account, one called it unreproducible and another saw no security implications in replay or side-channel behaviour.
Why it matters
Sanitising a shared trace normally means scrubbing the readable conversation. That is now insufficient by construction. A secret the model reasoned about — but deliberately kept out of its final answer — lives only in the encrypted block, survives your sanitisation pass, and remains in the artifact you published.
Three groups carry real exposure. Anyone who has open-sourced agent trajectories, benchmark rollouts or reproducibility artifacts has published material they cannot inspect. Anyone whose CI or support tooling attaches raw API transcripts to tickets has the same problem at smaller scale. And any pipeline that ingests third-party reasoning blocks now has an unreadable channel through which instructions can arrive.
The invisible-injection path deserves separate attention: it defeats every review process that operates on visible text, including human review of a shared trace before publication.
The bounded part should be stated plainly. This is not arbitrary access to other people’s chats. It requires possession of an encrypted block plus API access to a compatible model from the same provider — which is exactly why published logs, not live sessions, are the sharp edge.
Defenses
Strip reasoning fields before anything leaves your environment. Remove encrypted_content, thinking-block signatures and thought-signature fields from any trace you publish, attach to a ticket, or commit. This is the single control that matters most, and it is the researchers’ own primary recommendation.
Audit what you have already published. Search existing repositories, gists, datasets and issue attachments for reasoning payloads. Whether historical blocks remain decodable is not settled by the public record — treat them as exposed.
Rotate anything that passed through a reasoning trace you shared. API keys, passwords and tokens that appeared in a prompt may have appeared in reasoning. Rotate on the assumption the block was readable.
Keep secrets out of prompts to reasoning models. If a credential never enters the context, it cannot enter the trace. Use references and short-lived tokens resolved at tool-call time rather than pasting live secrets.
Treat inbound reasoning blocks as untrusted input. If your system replays reasoning objects it did not generate — from a shared trace, a dataset, or a partner integration — you have accepted a channel your logging cannot read. Prefer stripping to forwarding.
Follow current provider guidance on model switching. Anthropic now states that thinking blocks are tied to the model that produced them and should be stripped when switching models. Google says its backend manages thought compatibility across model switches. OpenAI still instructs developers to replay encrypted reasoning items when manually managing stateless history.
Add reasoning fields to your secret-scanning policy. Existing scanners look for key patterns in plaintext. A base64 blob passes silently. Block the field, not the pattern.
Status
| Item | Reference | Date | Notes |
|---|---|---|---|
| Primary paper | arXiv:2608.09867, Panfilov et al. | 2026-08-10 | Four attack vectors; 315,320 blocks decoded; 367 PII artifacts, 182 credentials |
| Prior replay finding | Matthew Green, Cryptography Engineering | 2026-05-29 | Replay across sessions, accounts and (for OpenAI) models; reported via bug bounty |
| Independent reproduction | Embrace The Red (Johann Rehberger) | 2026-08-16 | Cross-account password recovery against OpenAI; intermittent reliability observed |
| Press coverage | The Hacker News | 2026-08-12 | Reports researchers’ statement that the main extraction attack is no longer reproducible as of August 2026 |
| Vendor acknowledgement | — | — | No public acknowledgement from OpenAI, Anthropic or Google has surfaced; mitigation status rests on the researchers’ reproducibility statement |
| Already-published blocks | — | — | Open question. The public record does not establish whether historical blocks remain decodable |
| Mapped frameworks | OWASP LLM Top 10 (sensitive information disclosure, prompt injection), MITRE ATLAS | 2026 | Exfiltration via published artifacts; injection via non-visible channel |
Responsible disclosure was performed to the affected model providers, Microsoft and Hugging Face, and the paper proposes cryptographic and system-level mitigations for client-side reasoning. No malicious exploitation in the wild is documented.