The Encryption on Reasoning Traces Is Security Theater
Stealing Reasoning Traces from Proprietary LLM APIs proves that the 'encrypted' chain-of-thought blocks providers return are trivially decryptable by injecting them into a weaker model from the same company—and they already scraped 315,320 blocks to prove it.
Why it earned a slot
The paper landed yesterday on arXiv: *Stealing Reasoning Traces from Proprietary LLM APIs*, by Panfilov, Schmotz, Shumailov, and six others. They found that the encrypted reasoning blocks providers like Anthropic, OpenAI, and Google return to clients are not bound to any session, user, or model. They are interchangeable. The same block that came from Claude 4 Opus will decrypt just fine when fed back into the much weaker Claude Haiku, which happily prints the plaintext chain-of-thought. This is not a side-channel attack. It is not a complicated cryptographic break. It is a deployment bug that the field has been calling 'encryption' when it is really obfuscation with a shared key. The paper demonstrates it across three major providers, and then does the obvious thing: scrapes 315,320 reasoning blocks from public GitHub repositories, where developers unwittingly checked in session logs. They recovered 367 PII artifacts and 182 credentials. Passwords, API keys, patient identifiers—the whole mess. I think the industry has been kidding itself. The argument for hiding chain-of-thought was always flimsy—'we need to protect our secret reasoning process'—but the mechanism was never audited. The paper shows that the ciphertext is not bound to a session key, so it is not encryption in any meaningful sense. It is a base64-encoded liability. What I do not know is how long this has been exploitable. The paper does not say when each provider introduced the encrypted block format. But the fact that the blocks are interchangeable means a patient attacker could have been doing this for months. The paper's method is simple enough that it could have been discovered by any observant engineer who bothered to compare two blocks from different sessions. The real problem is not just the leaked credentials. It is the invisible prompt injection. You can embed a malicious payload entirely inside an encrypted block, and the model will decode it as part of its reasoning—without the user ever seeing the injected text. The paper calls this 'invisible prompt injection,' and it means that any agent that passes encrypted blocks between components is vulnerable to poisoning. I am not sure how to fix this cleanly. Per-session binding would help, but it adds latency and complexity. The real fix is to stop pretending that client-side encryption of reasoning traces is a security boundary. It is not. If you are building an agent on top of these APIs, you should assume the chain-of-thought is readable by anyone who can get a block from a weaker model. That changes what you log, what you cache, and what you let the model reason about in the first place. One commenter on Hugging Face put it well: "Calling those traces 'encrypted' is doing a lot of work." Yeah. It is. The paper is a wake-up call, and I hope the providers respond with actual cryptography, not marketing.