Encrypted Reasoning Was Never a Control

There is a particular kind of control that shows up in every AI assurance conversation I have. It is the control that everyone accepts, nobody tests, and no one can produce evidence for. It usually arrives in a vendor datasheet as a single adjective.

This week that adjective was "encrypted".

On 10 August 2026 a group of researchers published a paper called Stealing Reasoning Traces from Proprietary LLM APIs. The finding is straightforward enough to explain in a sentence. When a reasoning model thinks, the major providers do not keep that thinking on their own servers. They hand it back to you as a block of encrypted text, and your client passes it back with the next request so the model can pick up where it left off. Those encrypted blocks turn out to be portable. You can take a block produced by a large, well defended model and paste it into the context window of a smaller, cheaper sibling from the same family, and that smaller model will obligingly transcribe the contents in plain text.

No jailbreak of the frontier model. No breach of the provider. Just a design that assumed the envelope would only ever be opened by the party that sealed it.

What the researchers actually found

The team tested the technique across models from Anthropic, OpenAI and Google. They then went looking for real material. They collected 6,708 publicly available agent trajectories from GitHub and Hugging Face, decoded 315,320 reasoning blocks, and found 367 personally identifiable information artefacts and 182 credentials. Among the genuine user sessions that produced these, they counted 62 API keys, 33 passwords and 30 personal email addresses. Roughly 4.9 per cent of sessions, 328 of them, leaked at least one real sensitive item.

The economics are the part that should worry a risk committee. The paper puts the nominal cost of decoding a corpus of 10,000 traces at around $720 at current prices for a small model. This is not an adversary with a supercomputer. This is a laptop and a credit card.

The researchers group the consequences into four categories: circumventing anti distillation protections, extracting private data, surfacing hazardous content that the model reasoned about but did not say, and injecting instructions into a block that a future model will treat as its own prior thinking. Their own summary of the architecture is the line worth pinning to a wall. A design that hides a user's own data from them, while leaving it entirely available to a third party, provides neither privacy nor security.

The governance question is not the security question

The security response here is obvious and the providers will ship it. Bind the reasoning envelope to a user identity. Hash chain the blocks to a session. Rotate signing keys so old traces stop decoding. Enforce isolation between models at the API gateway. The paper sets all of this out, and the disclosure was responsible. Within a few months this specific attack will be uninteresting.

That is exactly why it is worth writing about now. The specific attack is not the lesson. The lesson is what your organisation was able to say about this control before Monday.

Ask yourself the honest version of the question. If a regulator, an auditor or a customer had asked you last month where your model's intermediate reasoning was stored, who could read it, and what evidence you held that the claim was true, what would you have produced? For most organisations the answer is a vendor page and a line in a risk register. Not a test result. Not a contractual commitment with a remedy attached. Not a data classification decision that treated reasoning traces as a distinct asset class.

That gap is not a security failure. It is an assurance failure, and it is entirely ours.

Three things this quietly breaks

Your data classification is incomplete. Most organisations have classified prompts and outputs. Very few have classified the intermediate reasoning, because the reasoning was presented as an internal implementation detail that nobody could see. It is now demonstrably a data asset that can carry credentials and personal information, that gets committed to public repositories inside agent trajectories, and that survives outside the session that created it. If your data map does not have a row for it, your map is wrong.

Your logging posture is inverted. Many teams have been comfortable publishing agent trajectories for debugging and reproducibility, precisely because the reasoning blocks looked like noise. They were not noise. They were a compressed record of everything the model considered, including material the visible output deliberately omitted. Anything published in this shape over the past year deserves a look, and the look should be a search, not an assumption.

Your vendor assurance process accepted a description. This is the one that generalises. Somewhere in your supplier questionnaire there is a question about encryption in transit and at rest, and somewhere there is a tick. The tick was accurate and useless, because the threat model was never about interception. It was about who else the ciphertext would open for. A control statement that does not name the adversary is not a control statement. It is marketing that has been allowed into a compliance artefact.

What to do about it, in order

Start by writing the question down. Which of the AI controls you currently rely on could you evidence within a week if someone insisted? Not describe. Evidence. For most teams the honest list is short, and the shortness of the list is the finding.

Then treat reasoning traces as in scope. Classify them, decide where they may be stored, decide whether they may leave your tenancy, and decide whether they may be published. Put that decision in the same place you keep your other data handling decisions, so it is discoverable later by someone who was not in the room.

Then change one question in your vendor process. Instead of asking whether a capability is protected, ask what evidence the provider will supply that the protection held, how often, and what happens contractually when it does not. Providers who have thought about this will answer. Providers who have not will send you a datasheet, and that response is itself the assessment result.

Finally, build the habit of asking what a control looks like when it fails. Encrypted reasoning failed silently. Nothing in any log anywhere said "this block was read by someone else". A control that cannot fail loudly cannot be monitored, and a control that cannot be monitored cannot be defended after the fact.

The pattern underneath

We are going to keep meeting this shape. A capability ships. It carries an implicit safety property that nobody stated formally. Everybody builds on the property. Somebody publishes a two step attack. The property was never tested because it was never written down as a claim that could be tested.

The organisations that will come through this era well are not the ones with the strictest AI policy. They are the ones that can answer three questions about any AI control they depend on. What is the claim, precisely. Who verified it, and when. What would we show a regulator if it turned out to be false.

Encrypted reasoning is a good place to start practising, because the answer is currently embarrassing for almost everyone, and the fix is cheap while the topic is still theoretical. It gets considerably more expensive once the question arrives in writing from someone who is entitled to an answer.