- What: Encrypted reasoning objects returned by the OpenAI, Anthropic, and Google reasoning APIs turned out to be portable across sessions, users, and models, so a weaker model in the same family could be prompted to transcribe a stronger model's hidden reasoning back into plaintext.
Researchers decoded 315,320 hidden reasoning blocks harvested from 6,708 publicly published AI agent trajectories and recovered 704 distinct privacy artifacts from genuine user sessions: 62 API keys, 33 passwords, 24 access tokens, and seven private keys. No encryption was broken. No key was stolen. The opaque blocks were simply pasted into a cheaper model from the same provider family, and that model read them back out loud.
The paper, Stealing Reasoning Traces from Proprietary LLM APIs, targets a design feature rather than an implementation bug. When an application manages conversation state manually or statelessly, reasoning models need a way to carry chain-of-thought across API calls without handing the plaintext to the client. OpenAI returns encrypted reasoning items that the app replays. Anthropic carries full reasoning inside an encrypted signature. Google uses encrypted thought signatures. All three are meant to be opaque to the developer holding them.
The flaw: portability, not cryptography
The attack required an intact encrypted reasoning block and API access to a compatible model from the same provider. That is it. The researchers found the blocks were accepted and processed regardless of which session, which account, or which model they were submitted under. Feed a block produced by a frontier model into a smaller sibling, prompt that sibling to transcribe what it sees, and the hidden reasoning comes back as text.
The paper calls the smaller model a "fuzzy" decoder. The three used were Claude Haiku 4.5 for Claude traces, GPT-5.6 Luna for GPT traces, and Gemini Robotics ER-1.6 for Gemini traces. The economics here are worth sitting with: the cheapest tier in a vendor's lineup was sufficient to strip the confidentiality off the most expensive tier's internal state.
An encrypted blob your application handles but cannot read looks like a black box. Under this flaw it behaved more like an encoded string with a vendor-hosted decoder available to anyone with an API key. If your logging, tracing, or eval pipeline treats reasoning fields as inert binary, that assumption is what failed.
What was actually sitting in the logs
The team scraped public agent trajectories, the kind routinely committed to repos for reproducibility, benchmarking, or debugging. After excluding benchmark-sourced data to isolate real user sessions, the 704 artifacts broke down as follows.
- 62 API keys, 33 passwords, 24 access tokens, and seven private keys recovered from genuine sessions
- 64 of the 704 artifacts appeared only inside hidden reasoning and nowhere in the visible trace
- 315,320 thinking blocks decoded in total across 6,708 trajectories
- Disclosure went to the three model providers plus Microsoft and Hugging Face, indicating the exposure spanned hosting and tooling platforms, not just the model APIs
That 64 number is the one to bring to your engineering leads. Those secrets survived sanitization. A developer who scrubbed the readable conversation before publishing, checked the visible text, and shipped the trace still leaked credentials, because the credential lived only in the opaque field nobody thought to inspect. Standard secret-scanning tooling running over a committed transcript would not flag base64 ciphertext as a finding.
Four abuse paths, including invisible prompt injection
The researchers demonstrated four uses for the technique: stealing proprietary reasoning for model distillation, extracting private data from other users' published traces, recovering harmful content concealed behind a safe-looking visible answer, and hiding prompt injections inside opaque reasoning blocks.
The injection proof of concept is the most operationally interesting. The team crafted a reasoning block carrying a malicious instruction, then replayed it into an unrelated task. The receiving model added an attacker-directed upload action, and the injected instruction never appeared in visible text at any point. For anyone running guardrails that inspect prompts and completions as strings, that is a payload channel your filters do not parse.
Scope, and what the paper does not claim
This is not arbitrary access to other people's chats. The attacker needs to obtain an encrypted block first, typically from a published agent log, plus API access to a compatible model. The identifiable victim group is developers who published raw agent traces with reasoning objects intact, which is a bounded population and probably not the only one at risk. The authors are also explicit that they lack ground-truth plaintext for proprietary reasoning, so they cannot guarantee every reconstructed trace is an exact copy. Fidelity checks relied on reasoning-token counts tracking the providers' reported thinking-token totals plus qualitative comparison.
The work extends May 2026 research by Johns Hopkins cryptographer Matthew Green, who showed encrypted reasoning blocks could be replayed across sessions and accounts but did not land a reliable extraction technique. Green reported the replay behavior through bug bounty channels. By his account OpenAI called the report unreproducible and Anthropic said it saw no security implications in the replay or side-channel behavior. This paper turns that same replay primitive into a working extraction method and quantifies the fallout.
Current state and the open questions
The researchers say the demonstrated attacks stopped working after mitigations, and their reproducibility statement puts the main extraction attack as non-reproducible as of August 2026. There is no documented exploitation in the wild. But no provider has publicly acknowledged the flaw or tied its documentation changes to this research, so the "it's fixed" claim rests entirely on the researchers' own testing rather than vendor confirmation.
Encrypted reasoning remains in all three APIs, with handling changed. OpenAI still instructs developers to replay encrypted reasoning items when manually managing stateless history. Google says its backend handles thought compatibility when a session switches models. Anthropic now states that thinking blocks are tied to the model that produced them and should be stripped when switching models, because other models ignore them. The second open question is the one nobody has answered: hundreds of thousands of reasoning blocks are already sitting in public repositories, and whether those remain decodable is entirely separate from whether fresh attacks still succeed.
Treat encrypted reasoning fields as secret material, not metadata. Strip reasoning blocks and opaque reasoning fields from any trace you publish, share with a vendor, or attach to a ticket. Stop committing raw API transcripts even after the visible text has been sanitized. Audit existing public repos, gists, eval datasets, and observability exports for reasoning objects already shipped, and rotate any credential that passed through an agent session whose trace went public.
The durable lesson
The visible-text boundary is not the trust boundary. Every AI observability platform, eval harness, and agent framework that persists full API responses is now holding a category of data it was never scoped to protect. Ask your teams a direct question: where do reasoning fields land in our logging pipeline, who can read that store, and what leaves the building attached to a bug report. If the answer takes more than a day to produce, that gap is the finding.
Questions about your exposure?
RedEye Security provides assessments for organizations that need to understand their real risk.
Talk to us