Weaker Models Can Read a Frontier Model's Encrypted Reasoning

SINGAPORE, 15 AUG 2026 — Three of the largest AI providers encrypt the reasoning their models produce, hand the encrypted block back to the client, and expect it to be returned with the next request. Researchers have shown that block can be replayed into a different, weaker model, which will read it out in plain language.

The encryption was never broken. It did not need to be. The same block stays valid in another session, for another user, on another model from the same provider. That portability is the vulnerability.

What the paper says

The work is a preprint, Stealing Reasoning Traces from Proprietary LLM APIs, submitted on 10 August by Alexander Panfilov, David Schmotz, Ilia Shumailov, Luca Beurer-Kellner, Joachim Schaeffer, Ameya Prabhu, Jonas Geiping and Maksym Andriushchenko. It builds on earlier work by the Johns Hopkins cryptographer Matthew Green.

Each of those decoders is a smaller or cheaper model than the one whose reasoning it transcribes. The cheap model can do this because it holds the same key as the expensive one. Every model in the ecosystem does.

Why hidden reasoning is encrypted in the first place

Providers hide chain-of-thought for several reasons at once. It protects a commercial asset, since reasoning traces are the ideal training data for distilling a competitor's model. It avoids showing users intermediate steps that may be wrong, offensive or alarming on the way to a good answer. And it lets the model reason about hazardous material without displaying that reasoning.

But a stateless API cannot simply keep the trace on the server between turns without holding session state, so the trace goes back to the client in a sealed envelope that the client must return. The design treats the envelope as opaque to the client, which it is. What it did not account for is that the envelope opens for anyone inside the provider's own walls, including a model the attacker chooses.

What was actually recovered

The researchers did not need to attack a live system. They scraped published material.

From reasoning blocks found in public repositories — agent logs that developers had committed or posted — they decoded 315,320 blocks. The paper reports recovering 367 personally identifiable information artefacts and 182 credentials from that set.

Secondary coverage gives a partial breakdown of the credentials as 62 API keys, 33 passwords, 24 access tokens and 7 private keys. Those figures do not reconcile with the paper's totals, and we have used the paper's numbers as the primary count.

The provenance is the point. Nobody was breached. These were traces that people published themselves, believing the encrypted portion to be unreadable, and it was readable by anyone with an API key for the same provider.

Four things this enables

The paper identifies four distinct uses, and they do not point in the same direction.

Anti-distillation is the first casualty. If hidden reasoning is what stops a rival cheaply copying a frontier model's behaviour, that protection now depends on nobody replaying the blocks. Bulk extraction of private data is the second, which is what the 315,320 decoded blocks demonstrate.

Then there is hazardous content that the model reasoned through without showing. A refusal can look clean at the output while the trace behind it is anything but, and the trace is now readable.

The fourth is the most significant for defenders: invisible prompt injection carried inside an encrypted payload. Instructions hidden in a block that a human reviewer cannot read, and that a content filter examining the visible text will not see.

The exposure is in your logs, not your network

For anyone running agents, the practical consequence is narrow: check your logs, not your code.

If your systems store, ship or publish raw API responses that include reasoning blocks — in debug logs, in observability pipelines, in a shared bug report, in a public repository of agent traces — you have been treating those blocks as opaque. They were not. Anything the model reasoned about, including material it never printed, may sit inside them.

That reframes a question most teams have answered casually. Log retention policies are usually written around what the model said. The reasoning is a separate body of text, frequently longer than the output, and it has been travelling through the same pipelines without the same scrutiny.

Concretely, find out whether your logs contain these blocks. If they do, treat them with the same sensitivity as the prompts that produced them. That is a half-day of work in most organisations and it is worth doing before deciding whether the mitigations are sufficient.

A record you did not know you were keeping

There is a compliance edge to this that is worth separating from the security one.

In a regulated industry, what your systems record about a customer is a governed question. If an agent reasons at length about a customer's file before producing a short answer, that reasoning is text your systems generated about an identified person, and it has been travelling in your logs in a form you were told you could not read.

Whether that constitutes processing you should have disclosed is a question for your own counsel and not one this article can answer. It is worth putting to them, because the honest position for most organisations is that nobody considered it — the blocks were opaque, so they were treated as though they contained nothing.

Fixed, reportedly

The researchers disclosed to the providers, and report that the demonstrated attacks stopped working after mitigations were applied.

Two caveats apply. No public acknowledgement has come from any of the three providers, so the fix rests on the researchers' account of reproducibility rather than on a vendor statement. And it is unclear whether blocks already published remain decodable. This matters, because the 315,320 blocks in the study came from material that is still online.

A mitigation that stops new extraction does nothing about traces already in public repositories. If those remain readable, the exposure is historic and permanent rather than closed.

What we could not establish

What the mitigations actually are, when each provider deployed them, and whether previously published blocks can still be decoded. None of the three has commented publicly.

Also unestablished: whether the technique works across providers rather than only within one, whether any of this was exploited before disclosure, whether the credential counts represent live or expired secrets, and how the secondary breakdown of 62 API keys, 33 passwords, 24 access tokens and 7 private keys relates to the paper's totals of 367 artefacts and 182 credentials. This is a preprint and has not completed peer review.

What to watch

Whether any provider confirms the mitigation and describes it. Silence on a cross-vendor finding like this is telling. A published fix would let defenders reason about residual exposure.

Whether the already-public blocks get invalidated. That is the difference between a closed issue and a permanent one, and it is entirely within the providers' control.

And whether observability vendors respond. Agent logging is now a product category, and if reasoning blocks are sensitive by default, that is a change every one of those tools has to make.