Encrypted Reasoning Envelopes Were Never Private. Every Provider Made the Same Mistake.

On Aug 10, 2026, four institutions — MATS Research, the ELLIS Institute Tübingen, the Max Planck Institute for Intelligent Systems, and Snyk — posted a paper called Stealing Reasoning Traces from Proprietary LLM APIs. The Hacker News covered it on Aug 12. Simon Willison wrote it up on Aug 11. Decrypt's headline put it plainly: "'Inner Thoughts' of Every Major AI Model Exposed in Massive Exploit."

The paper's finding is short. All three frontier reasoning-API providers — OpenAI, Anthropic, and Google — ship an "encrypted reasoning envelope" that the API caller hands back on the next turn so the model can continue its chain of thought without regenerating it. Each provider protected those envelopes with a single global encryption key — not bound to a session, user, or model. The encryption was designed to stop tampering, not replay.

What that means in practice

Two consequences follow immediately, and both landed in the paper.

Path one — a weaker sibling reads the envelope. Take an envelope produced by a strong model, hand it to a weaker, less guardrailed sibling in the same family, and ask it to read the block back. Because the key is global, the sibling decrypts it and prints the reasoning verbatim. Two API calls. Works across all three providers.

Path two — the historical corpus of public agent logs is already leaking. Developers routinely publish raw agent-session logs on Hugging Face spaces, GitHub gists, LangSmith trace shares, blog posts, YouTube walkthroughs. Those logs contain the encrypted envelopes verbatim. The authors scanned 6,708 public agent trajectories, decoded 315,320 reasoning blocks, and pulled out 182 developer credentials and 367 distinct pieces of PII.

The critical detail is what the leaked data was: much of it lived only inside the reasoning envelope and was never rendered in the visible assistant output. Developers who reviewed their logs before sharing had no way to see what they were about to leak. Their dashboards displayed the envelope as opaque bytes, exactly as the provider intended.

All three vendors patched the live extraction path between the paper's Aug 10 posting and the Aug 12 press cycle. The main attack, as originally described, no longer reproduces. But the historical corpus of already-published logs does not un-publish. Every envelope in it remains cross-decodable against any sibling model whose key rotation has not yet completed.

Encryption prevents tampering. That is not the same as privacy.

All three providers built the envelope with the same threat model — nobody should modify this state and hand back a doctored trace — and shipped a key policy that satisfied exactly that. What they did not do was bind the envelope to the specific session, user, or model that produced it. The boundary the encryption enforced was no one can change this, not only this session with this model can read this.

This is not a single vendor's implementation bug. Three independent frontier providers shipped the same architectural error at the same layer of the API contract, where a passive-looking descriptor (an opaque encrypted string) is actually active state that flows across sessions and models. Consumers treated it as ciphertext-at-rest. Attackers treated it as replayable state.

Same shape as GhostSplice two days earlier, where the passive-looking descriptor was an MCP tool schema. Same shape as CoreBreak the week before, where the descriptor was a tool-call-shaped block of JSON the SDK executed without asking the model whether the call was authorized. Each time, the consumer trusted an object the provider had not promised to make trustworthy.

The observable is provenance, not encryption

The vendor-side fix is straightforward and all three providers have deployed some version of it: bind the envelope to a session, user, and model, and rotate the key when any of those change. That closes the live extraction path.

It does not close the historical corpus. Every developer who published a session log containing an encrypted reasoning block should assume the block is decodable and rotate every credential that could have been in the model's private reasoning — not just credentials the model spoke out loud, but credentials it thought about: debug prompts, error messages containing keys, tool arguments referencing tokens, staging credentials the model used and did not surface.

The longer-run observable is not "was the ciphertext strong enough." It is "did this API state carry the provenance binding the consumer assumed it did." A runtime layer that treats every provider-returned envelope as sensitive by default and gates its appearance in log surfaces catches this class no matter which extraction path remains open next week.

What to do about it now

If you operate on top of any of the three reasoning APIs, audit your published agent traces. Any log containing an encrypted reasoning envelope from an unrotated key window is a potential credential exposure — the paper's corpus scan already extracted 182 credentials and 367 PII items from real developer traces.

If you build a product that logs agent sessions, treat the reasoning envelope like an API key: mask it in log surfaces, gate its export, and warn users before they publish it. The developers whose credentials landed in the paper's dataset did not know they were sharing anything sensitive; their tooling did not either.

Model-side controls — even ones that look like encryption — are not the boundary consumers thought they were buying. The boundary is one layer down, at the provenance binding between an API artifact and the session, user, and model that produced it.

SPR{K3 is a security research operation that pairs offensive vulnerability research with runtime behavioral defense. Defend is our runtime agent. To talk about a deployment, reach us at support@sprk3.com.