Researchers reported on August 10, 2026, that they could extract supposedly hidden reasoning traces from Anthropic, OpenAI, and Google API ecosystems by replaying encrypted reasoning blocks into weaker compatible models. The attack turned those models into decryption oracles: a stronger model’s opaque trace could return as readable plaintext.
The August 10 arXiv preprint also decoded 315,320 reasoning blocks collected from 6,708 public agent trajectories, finding 367 personal-information artifacts and 182 credentials. The work is not peer reviewed, and the authors say providers changed their systems after disclosure, preventing reproduction of the same attacks.
The Cross-Model Decryption-Oracle Attack
Reasoning APIs increasingly return opaque fields alongside a model response. Anthropic calls them signed thinking blocks; its documentation says the encrypted full thinking is carried in a signature field to preserve multi-turn continuity. OpenAI tells applications managing their own state to replay encrypted reasoning items, while Google’s Gemini API describes thought signatures as encrypted representations of internal reasoning.
Those fields were designed to be passed around, not read. The paper’s central finding is that portability can defeat opacity when a provider’s weaker sibling model accepts a block created by a stronger one and is willing to transcribe what it contains.
The researchers tested cross-session, cross-user, and cross-model replay paths in the three providers’ API families. Their technique supplied an encrypted block from one interaction to a compatible lower-capability model, then prompted that model to reveal the content it had evidently decoded to continue the conversation. In effect, the encryption protected the trace from the customer directly but not from another model endpoint willing to interpret it.
The paper calls this a cross-model decryption-oracle attack. It is less like breaking modern encryption and more like finding a service desk that will open a sealed envelope if the request is phrased correctly. The practical security boundary was the API’s acceptance rules, not the unreadability of the returned blob.
The authors evaluated extraction fidelity over 120 Codeforces programming problems, comparing extracted-token counts with each provider’s reported thinking-token counts. Those measures tracked closely, the authors report, though they could not compare results with ground-truth plaintext reasoning traces because the providers do not expose them.
That limitation matters: token counts are evidence that something substantial was recovered, not a full independent verification of every recovered sentence. But the reported cross-provider design flaw is concrete enough that CTOs should stop treating encrypted reasoning output as harmless logging material.
This is a different route from the Claude Code leak and its harness-level attack surface, where the problem sat in the surrounding agent environment. Here, the risky artifact is the reasoning-continuity data the API itself asks customers to preserve and replay.
Public Trace Scan Recovered Credentials and Personal Data
To see what such extraction could expose outside a lab, the researchers scanned 6,708 public trajectories from GitHub and Hugging Face. They decoded 315,320 encrypted blocks, about 47 blocks per trajectory, calculated from those two reported totals.
The scan found:
- 367 PII artifacts and 182 credentials across the decoded material.
- 1,028 blocks, or 0.3%, containing at least one privacy leak.
- 328 sessions, or 4.9%, containing at least one real sensitive item.
- 62 API keys, 33 passwords, and 30 personal email addresses from genuine user sessions.
The larger 367-artifact headline includes benchmark material, which contributed substantially to the personal-information count. That does not erase the real-user findings; it does mean the headline total should not be casually read as 367 live customer-data incidents.
The review was targeted rather than exhaustive. Public agent logs are also not a representative sample of all API traffic: they are disproportionately likely to include demos, benchmarks, debugging sessions, and people who published their workflow without expecting an opaque field to become legible later.
Still, that is precisely the operational lesson. A trace does not need to be deliberately published as plaintext to leak. It only needs to be retained in a broad-access observability system, copied into a benchmark repository, or handed to a vendor whose compatible endpoint can reinterpret it.
The exposure overlaps with the risk behind Claude’s prompt-injection exfiltration path: agent systems often move sensitive context through components that engineers assume are merely internal plumbing. “Encrypted” output is still output, and output tends to end up in logs.
The public-scan findings and attack demonstrations are reported by the paper’s authors; the brief provides no independent replication of their original vulnerable API behavior.
Provider Patches and Context-Bound Trace Design
The researchers said the providers acknowledged the responsible-disclosure report and that they could no longer reproduce the same extraction paths after fixes. The tests covered particular API versions and reasoning models in early July 2026, while providers can alter proprietary implementations without notice.
That is good news for the specific exploit. It is not a reason to resume dumping signed thinking blocks into every analytics store. A vendor-side patch can close one cross-model compatibility path; it cannot retract copies that customers already placed in logs, evaluation corpora, support tickets, or public repositories.
The paper proposes binding a reasoning block to its intended context: the relevant model, user, session, and conversation state should be part of what the API validates before accepting a block. A trace replayed into a different model or account should fail rather than silently become interpretable context.
For CTOs, the immediate policy is simpler than the cryptography:
- Classify encrypted reasoning fields and raw API transcripts as sensitive data.
- Limit retention and access as aggressively as for prompts and tool outputs.
- Keep such traces out of public benchmarks, debug bundles, and broad telemetry by default.
- Recheck integrations when an API provider changes its reasoning-continuity format.
The attack did not prove that every encrypted reasoning trace remains extractable today. It did show why “our engineers cannot read this field” is not a security classification. If a model can read it, the system has to assume somebody may eventually make it talk.
Key Takeaways
- Researchers reported replay attacks that extracted hidden reasoning traces from Anthropic, OpenAI, and Google API ecosystems.
- The technique used weaker compatible models as decryption oracles for opaque reasoning blocks.
- A public scan of 315,320 blocks found 367 PII artifacts and 182 credentials.
- The headline PII count includes benchmark material, while genuine user sessions contained API keys, passwords, and personal email addresses.
- The researchers said provider changes after disclosure stopped reproduction of the reported attacks.
Further Reading
- Stealing Reasoning Traces from Proprietary LLM APIs, August 10, 2026 preprint on cross-provider reasoning-trace extraction and public-trace scanning.
- Stealing Reasoning Traces from Proprietary LLM APIs, full paper, Methods, compatibility testing, fidelity evaluation, and mitigation proposal.
- Extended thinking, Claude Platform Docs, Anthropic documentation on signed thinking blocks and continuity.
- Model guidance, OpenAI API, OpenAI guidance on replaying encrypted reasoning items.
- Thought Signatures, Gemini API, Google documentation on encrypted internal-reasoning representations.