Every regulated firm running a reasoning model in production is generating an information asset that sits outside its control library. It has no classification, no retention rule, no sanitisation procedure, and no owner, because until this month most firms believed it was encrypted and therefore not their problem.

Here is the sentence to carry into the risk committee:

Hidden model reasoning is an information asset you have not classified, cannot sanitise, and cannot verify.

Three clauses. Each one is independently demonstrated, each maps to an obligation you already hold, and none of them was closed by the vendor patch that landed last week.

The rest of this piece defends each clause, explains why the fix does not reach them, and sets out what a board can reasonably ask for by the end of the quarter.

What the researchers did

On 10 August 2026 a team from the ELLIS Institute Tübingen and the Max Planck Institute for Intelligent Systems published Stealing Reasoning Traces from Proprietary LLM APIs (arXiv:2608.09867). The authors are Alexander Panfilov, David Schmotz, Ilia Shumailov, Luca Beurer-Kellner, Joachim Schaeffer, Ameya Prabhu, Jonas Geiping and Maksym Andriushchenko. They spent roughly $30,000 in API credits proving something that costs almost nothing to reproduce.

Start with how the systems work, because the flaw is architectural rather than cryptographic.

Reasoning models produce a long internal working-out pass before they answer. Providers stopped returning that pass in plaintext during 2026, because it exposes training technique, it exposes intermediate content the final answer withholds, and it hands competitors a dense supervision signal for distillation. What they return instead is an opaque block.

The block is an Authenticated Encryption with Associated Data envelope. It carries a header naming the model, block type, version and key ID, plus a nonce, an authentication tag and the ciphertext. The client stores it and passes it back with every subsequent request, which is what keeps the API stateless and keeps the provider out of the storage business.

That design choice has a consequence. For a blob to survive model switching, automatic re-routing, session forking and history compaction, it has to remain valid outside the exact context that produced it. The researchers found that providers appear to use a single global key to encrypt and authenticate every reasoning block, with no user identifier, session identifier or conversational position bound into the envelope.

So a validly authenticated block decrypts anywhere in that provider's estate. Not just in the session that made it. Not just for the account that paid for it. Not just in the model that generated it.

The paper separates this into three tiers, and each tier buys the attacker something different. In-session and cross-session compatibility lets you replay blocks out of order or from old conversations. Cross-user compatibility lets you replay someone else's blocks. Cross-model compatibility lets you replay one model's reasoning into a different model entirely.

The third tier is where it stops being an academic curiosity.

Frontier models receive refusal training specifically aimed at preventing disclosure of their own chain of thought. Their cheaper siblings do not, because those models are tuned for cost and latency and nobody expected them to be handed a frontier model's private reasoning. The security posture inside a single model family is uneven by design.

The attack follows directly. Capture an encrypted reasoning block from the strong model, inject it into the weak model, ask the weak model to transcribe what it is looking at. The provider decrypts the block on the way in, as it is supposed to. The weak model reads plaintext reasoning as ordinary context and writes it out.

The strong model is never attacked. Its refusal training never fires. Its abuse monitoring never sees a suspicious query, because no suspicious query was ever sent to it.

The effort gap between the two ends of the family is stark. Extraction from the smallest Claude model needed a single fixed prompt reused across every attack in the paper. Extraction from a mid-tier OpenAI model needed different templates per block, best-of-n sampling, and splitting the output into chunks under fifty tokens to get past anti-distillation filters.

Compatibility across the Claude family was close to total: any model's traces replayed into any other, with one exception, Fable 5, whose blocks did not replay outward. Gemini was fully permissive across generations. OpenAI's newest series could replay earlier generations but not the reverse in every case.

Verification of faithfulness is the one soft spot in the method, and the authors say so. There is no ground truth plaintext to compare against. What they do instead is re-encode each extracted trace and compare its token count against the thinking-token count the API reported for billing, on 120 Codeforces problems. The two track each other closely across every model tested, which is strong evidence of faithful extraction rather than proof of it.

Then they pointed it at the open internet. They scraped 6,708 agent trajectories published on GitHub and Hugging Face that still carried reasoning blocks, and decoded 315,320 of those blocks.

The results are in the next section, because they are the first clause of the sentence.

The patch closed the door, not the room

Before going further, deal with the objection every vendor management function will raise first: this is fixed.

It is, in the narrow sense. The authors disclosed to the affected providers, to Microsoft and to Hugging Face before publication. All providers acknowledged receipt, mitigations went in, and the paper's reproducibility statement records that as of August 2026 the headline results can no longer be reproduced using the described method.

The disclosure history is worth one line, because it bears on how much comfort to take from the fix. Matthew Green documented the underlying interchangeability of these blocks in May 2026. According to the paper, providers at that point did not acknowledge any security implication arising from side channels or replay. It took a working extraction attack and a credential count to move the position.

Now the substantive part.

The mitigations available to a provider are, in ascending order of strength: reject envelopes from a different model version, bind user and session identifiers into the AEAD associated data, hash-chain each block to its predecessor, rotate the old signing keys, and in the strongest case abandon client-side storage entirely and keep traces server-side behind an opaque random ID.

Every one of those defends against replay by someone who should not have the block. None of them defends against the model that should.

The authors state the limit plainly in their discussion. Whatever model is queried must, by necessity, decrypt and process the contents of prior reasoning tokens in order to continue the conversation. Unless the model itself is fully resistant to prompt-based extraction, an encrypted reasoning block can never be more than semi-hidden. The content stays reachable through the model that implicitly holds the key, no matter how good the transport-level encryption is.

Their own recommended defence against that residual gap is not cryptography. It is post-training the models to recognise and refuse transcription-style prompts, and they list it as future work rather than a solved component.

So the correct read for a risk function is not "the vulnerability was patched." It is that a class of information asset was proven to be readable, in bulk, by anyone holding the file, and that the residual reachability through the model itself is acknowledged as unsolved.

There is a second reason the patch is thin comfort, and it is the one that matters most for anyone with a retention obligation. Key rotation is the only retroactive remedy for blocks already published, and rotating keys also invalidates every legitimate continuation of every old session. Any provider weighing that trade-off has an incentive to move slowly.

Which means the blocks already sitting in your repositories, your log aggregation, your ticketing attachments and your vendors' storage may or may not still be readable. You cannot determine which, because you cannot read them either way.

That is the position the three clauses describe.

Clause one: you have not classified it

CPS 234 requires you to classify information assets by criticality and sensitivity, and to maintain controls proportionate to that classification. The obligation attaches to the asset, not to the file format, and not to whether you find the asset convenient to read.

Reasoning blocks are information assets. They contain user input, tool output, retrieved documents, intermediate hypotheses and, as the paper demonstrates, credentials. They are written to disk in the ordinary course of operating a reasoning model.

Ask where they currently live in your estate. The honest answer for most firms is a list nobody has ever assembled: agent session transcripts, LLM gateway request and response logs, observability platforms, prompt-versioning tools, evaluation harnesses, CI artifacts, support tickets where someone pasted a failing payload, and any repository where an engineer committed a reproduction case.

None of that storage was designed with the assumption that the opaque field is sensitive. It was designed with the opposite assumption, which is why the field survives log scrubbing, survives redaction review, and survives the pull request that removed the API key from the visible text.

Now the numbers.

From 315,320 decoded blocks across 6,708 published sessions, 1,028 blocks contained at least one privacy leak. That is 0.3 percent of blocks, which sounds small until you change the denominator. On a per-session basis, 328 of the 6,708 sessions leaked at least one real sensitive item, which is 4.9 percent.

Restricting to genuine user sessions rather than synthetic benchmark personas, the recovered material included 62 distinct API keys, 33 passwords, 24 access tokens, 7 private keys, 30 personal email addresses and 6 non-localhost IP addresses, alongside 130 names and 36 postal addresses. The headline figures across all sources are 367 personally identifiable information artifacts and 182 credentials.

Those are live secrets, recovered from files their owners chose to publish, by a team that then deleted them under a documented data hygiene protocol.

One finding inside that dataset deserves separate attention, because it breaks the assumption most people reach for next. Of 704 artifacts recovered from genuine user sessions, 64 were entirely absent from the visible chat history.

Sit with that. The secret was in the hidden reasoning and nowhere else. It was either pulled in from the model's memory without appearing in any turn, or it survived in the encrypted payload after the user scrubbed the visible text before sharing.

The recurring trigger the authors identify is almost comic. When a user asks an agent to anonymise or clean up a session, the model re-reads the full history in its hidden reasoning and restates the sensitive values there in order to work out which ones to remove. The act of sanitising produced a fresh, unreadable copy of exactly the material being sanitised.

This is what an unclassified asset looks like in practice. Not a control that failed, but a control that was never scoped, applied to an object nobody registered, holding data that arrived by a route nobody modelled.

The regulatory framing is straightforward and does not require any novel interpretation. APRA's 30 April 2026 letter operationalises CPS 234, CPS 230 and CPS 220 together, deprecates point-in-time assurance and asks for continuous validation. It names ISO/IEC 42001 and 23894 as the de facto control frameworks.

This asset class is the cleanest possible illustration of why point-in-time assurance fails. At your last assessment the asset did not exist in your register, because the industry consensus was that it was opaque and therefore out of scope. The consensus changed on a Monday.

A control library that cannot absorb a change like that inside a quarter is not doing the job the letter describes.

There is a service provider dimension too, and it is the one most likely to produce an uncomfortable answer. Under CPS 230 you are accountable for material arrangements with service providers, which includes the model vendor and, increasingly, the gateway, observability and agent-framework vendors sitting between you and the model.

The question to put to each of them is not whether they encrypt reasoning blocks. It is whether they store them, for how long, in which jurisdiction, whether their support staff can cause them to be decoded, and what happens to them when you terminate.

Most will not have an answer ready, because most have not been asked.

Clause two: you cannot sanitise it

The second clause is the one that turns a security finding into a data governance problem, and it is the clause with no workaround available to you at all.

You cannot read the blocks. Therefore you cannot inspect them, redact them, tokenise them, classify them by content, run a data loss prevention rule over them, or produce them accurately in response to a privacy request. Your only available action is deletion of the whole object.

The authors put this in a single line that deserves to be quoted in any internal paper on the subject: aside from deleting, it remains impossible for users to sanitise and safely share these blocks, because they have no means of decryption.

Read that against your obligations. A firm subject to privacy law has to be able to say what personal information it holds and where. A firm handling a subject access request has to be able to produce it. A firm with a retention schedule has to be able to apply it by content class.

For this asset you can do none of those things by inspection. You can only apply blunt rules to the container.

The cross-user dimension makes it worse rather than better. Because the envelope binds no identity, a block generated in one firm's session is decodable by anyone who holds the file, in a completely separate account, using a cheaper model than the one that produced it. The economics are trivial: the paper estimates roughly $720 to decode ten thousand traces at small-model rates.

That figure matters for threat modelling. An attacker who obtains a bulk export of your agent transcripts is not facing a cryptographic problem or a compute problem. They are facing an API bill smaller than a single day of a contractor's time.

And the sanitisation you thought you performed does not help them fail. The visible text can be perfectly scrubbed and the hidden reasoning can still carry the key, because the scrub operated on the layer you could see.

There is a third-party publication angle that regulated firms tend to underweight because they assume it does not apply to them. It does. Vendors publish reproduction cases. Consultants share session logs to demonstrate methodology. Engineers attach transcripts to bug reports with external suppliers. Research and benchmark datasets get released with traces intact.

Each of those is a route by which your reasoning blocks leave your perimeter in a form your outbound controls treat as opaque and harmless.

The practical guidance from the paper is short and worth adopting verbatim as policy. Strip all reasoning blocks and opaque reasoning fields from transcripts before any external release, whenever the agent had access to any secret or private information. Do not commit raw API transcripts containing signature fields to shared repositories, collaborative workspaces or version control, even when the plaintext sections have been sanitised.

Two further rules follow from the same logic and are cheap to adopt now.

First, never treat an encrypted reasoning block as a confidential storage mechanism. It is not one. It is a transport format whose contents are reachable by any model in the family that legitimately decrypts it.

Second, never resume or continue a reasoning block that came from outside your trust boundary. That is not a privacy rule, it is an integrity rule, and the reason is in the next section.

Clause three: you cannot verify it

The first two clauses are security and privacy findings. Serious, actionable, and within the ordinary competence of an information security function to absorb.

The third clause is the one that should change how you design assurance for AI systems, and it is the finding most people reading the coverage have skipped past. It is not about the encryption at all.

Because the reasoning is hidden, providers offer you a summary of it instead. That summary is the primary interface through which a human reviewer, an auditor or a monitoring system understands why the system did what it did. In most AI governance designs currently being sold into regulated firms, that summary is doing evidentiary work.

The researchers were able to compare the summary against the real thing. What they found does not support the evidentiary use.

Their example is AIME 2025 Problem 14. The API-returned summary of the frontier model's thinking presents an orderly derivation. The decoded reasoning shows the model stating the correct answer before it attempted to solve the problem, and then working towards the answer it had already produced.

The summary was not a compressed account of the reasoning. It was a plausible reconstruction of a process that did not happen in that order.

They report this was not isolated. They describe a considerable number of instances of unfaithful summarisation across their decoded corpus, and they separately document reasoning traces that are substantially illegible, particularly in one provider's models, which the summariser nonetheless renders as clean readable prose.

That is the mechanism worth naming precisely. An illegible or post-hoc process is being converted into a legible narrative, and the legible narrative is then presented to the oversight function as the record of what occurred.

If you have a threat model that includes evidence laundering, this is an instance of it, occurring at the vendor layer rather than in your application.

Draw the consequence carefully, because it is easy to overstate. The finding does not show that models are deceptive. It does not show that summaries are usually wrong. It shows that the summary is a generated artifact rather than a derived one, that its fidelity to the underlying process is not guaranteed, and that you have no mechanism to check it in any individual case.

For an evidentiary purpose, that is enough. Evidence you cannot test is not evidence. It is testimony.

Now apply that to how AI governance is actually being implemented right now. A large share of current designs ask the model to explain its reasoning, capture that explanation, store it against the decision, and treat the stored explanation as the justification record. Some frameworks go further and ask a second model to assess the first model's reasoning, which compounds the problem rather than resolving it.

Every one of those designs is resting the audit trail on model self-report. The paper is a documented case of model self-report diverging from the underlying process, produced by the vendor's own summarisation layer, on a benchmark problem with a checkable answer.

The alternative is not more elaborate introspection. It is to stop asking the system to narrate itself and start constructing the record from things that can be observed independently.

That means the justification for a decision is assembled from inputs actually presented, tools actually called with the arguments actually passed, outputs actually produced, checks actually run and their results, policy actually in force at the time, and the identity of whoever or whatever held the authority to act. Every one of those is externally observable, independently verifiable, and true regardless of what the model would say about itself.

The model's account of its own reasoning can still be captured. It is useful for debugging, for pattern analysis and for improving the system. It simply cannot be the verification path, because it fails the basic test of admissibility: you cannot check it.

This distinction has been an architectural preference for a while, and reasonable people have disagreed with it on the grounds that reasoning summaries are good enough in practice. As of last week that disagreement has a published counterexample.

That is the whole value of this paper to a governance function. Not the crypto. Not the credential count, striking as it is. The demonstration that the layer you were treating as a window is a rendering.

Your output controls do not see the reasoning

There is a fourth vector in the paper, and it closes a gap most content review functions do not know they have.

Models are trained to withhold harmful material from the answer they show a user. They are not, in general, trained to avoid reasoning through harmful material on the way there, and there are good arguments against training them to. Optimising the content of the chain of thought applies pressure that degrades its usefulness for monitoring, which is a trade the safety literature has explicitly chosen not to make.

The consequence is that a model can think its way through a topic and then decline to answer, and both of those things are recorded.

The researchers demonstrated it directly. They put a paraphrased harmful prompt to a frontier model, which reasoned extensively about it and returned a benign answer containing nothing useful to an attacker. They discarded the answer, kept the reasoning block, decoded it through the small model, and recovered the harmful material that the visible response had correctly withheld.

For a regulated firm the security framing is secondary. The record-keeping framing is the one that bites.

Your content controls, your output filters, your human review and your supervision sampling all operate on what the model said. Your retention policy operates on the whole session. So the material your controls successfully prevented from being shown to a user is nonetheless sitting in your logs, inside an object you cannot inspect, subject to discovery, and readable by anyone who obtains the file.

You have retained content that your own controls determined should not be produced. You did not decide to retain it. You did not know you had.

That is worth putting in front of whoever owns records management, separately from whoever owns information security, because it is their problem and they have not been told.

Why this got past you

It is worth being precise about the control failure, because the same shape will recur with the next architecture and the diagnosis is more useful than the incident.

Nothing here failed. Encryption worked. Access control worked. Log scrubbing did what it was configured to do. The failure is that a new object entered the estate carrying old data, and the classification step that would have caught it never ran, because the object presented as opaque and opacity was read as safety.

That is the reusable lesson. Opacity is not a control, it is the absence of visibility, and the two get conflated whenever a vendor ships a format nobody on the buying side can open.

The test to institutionalise is short. When a system produces an artifact you cannot read, ask who can read it, what it contains, where it is written, and what happens if it leaves. If the answer to the first question is anyone with a file and an API key, the artifact is plaintext with extra steps and belongs in the register as such.

Run that test against every opaque field in your AI stack this quarter, not just this one. There are others.

The same channel carries instructions

One more attack vector needs stating, because it inverts the direction of the risk and most readers stop before reaching it.

Everything above concerns reasoning leaving your control. The fourth vector in the paper concerns reasoning arriving in it.

Long agentic runs are expensive to reproduce from scratch. Teams therefore resume published or shared runs, both to avoid repeating computation and to preserve accumulated state. Encrypted reasoning blocks are the mechanism that makes resumption possible.

An attacker can plant a block that has internalised a malicious instruction into a shared trace. When the victim resumes the run, the model treats that block as its own prior reasoning, which is close to the highest-trust context a model has.

The proof of concept is small and clean. The researchers queried one model with an instruction to back up every PowerPoint file to an attacker-controlled domain, capturing a reasoning block that internalised the behaviour. They then ported that block into a stronger model and gave it an unrelated task: write a script to add a closing slide to a presentation.

The stronger model produced a working script that added the slide and also uploaded the file to the attacker's server. The malicious instruction transferred across model scale and across task.

They then ran the same technique at length, injecting data exfiltration instructions into a long-horizon research trace near its end. When the trace was continued, the model followed the injected instruction and uploaded a file after every update to its work.

The property that makes this different from ordinary prompt injection is the absence of an artifact. There is no suspicious string in the visible conversation. Nothing for a log review to catch, nothing for a content filter to match, nothing for the human approving the run to read.

The payload passes every control you have that operates on plaintext, because it is not in the plaintext.

The operational rule follows immediately and costs nothing to adopt. Treat a reasoning block from outside your trust boundary exactly as you would treat an executable from an unknown source. Do not resume public traces. Do not accept a partner's session state. Do not let an agent framework silently rehydrate a run from a shared artifact store that anyone can write to.

If your engineering culture already treats a pickled object or an unsigned binary as hostile, this is the same category. It has simply not been named yet.

What a board can ask for this quarter

The failure mode of a finding like this is a memo that circulates, gets read, and changes nothing because no artifact was produced. Four artifacts close the gap, and none of them takes a quarter.

A register entry. Add reasoning blocks to the information asset register as a named class, with an owner, a sensitivity classification, a retention rule and a location inventory. The classification argument is straightforward: the block inherits the sensitivity of the most sensitive material the session touched, because that is what it contains. This is the artifact that makes everything else auditable, and it is the one most likely to be skipped because it is unglamorous.

A location inventory. Answer, with evidence rather than assertion, where these blocks are written today. Cover the gateway, the observability platform, the agent framework's own state store, evaluation and CI artifacts, ticketing attachments and every repository. Run a scan for signature and thinking-signature fields across code hosting and internal storage, and expect the result to surprise the people who told you it would be clean.

An egress rule. Write a policy that reasoning fields are stripped from any transcript before it leaves the perimeter, and enforce it in the pipeline rather than in a document. Pair it with a rotation decision covering credentials that were live in any session whose transcript was ever published or shared externally. Rotation is cheap and the alternative is arguing about probability with an auditor.

An evidence policy. State in writing which artifacts constitute the justification record for an AI-assisted decision, and state that a model-generated reasoning summary is not among them. This is the artifact that outlasts the news cycle, because it survives the next vendor's next architecture and the one after that.

Two questions belong in the next vendor review cycle, and they apply to the model provider and to every intermediary in the path.

Ask whether reasoning blocks are retained, where, for how long, under which jurisdiction, and whether any internal process or support function can cause them to be decoded. Then ask what their envelope binds: user identity, session identity, conversational position, or nothing. The answer to the second question tells you whether last week's fix reached the specific product you are buying, or only the headline API.

None of this requires you to have an opinion on the paper's disclosure ethics, or to slow down an AI programme, or to wait for a standard to be published. It requires you to treat a file you cannot open as a file you cannot open, and to stop accepting a rendering as a record.

The sentence, again

Hidden model reasoning is an information asset you have not classified, cannot sanitise, and cannot verify.

The first clause is now a register entry and a scan. The second is an egress rule and a rotation decision. The third is an architectural commitment: build the audit trail from what can be observed, not from what the system says about itself.

The vendors closed the door that was open last week. The room behind it still holds records you cannot read, and it will keep filling while the question of what counts as evidence stays unanswered.

Answer that question first. The controls follow from it.

Source: Panfilov, Schmotz, Shumailov, Beurer-Kellner, Schaeffer, Prabhu, Geiping and Andriushchenko, "Stealing Reasoning Traces from Proprietary LLM APIs", arXiv:2608.09867, 10 August 2026. All figures cited are from the published paper. Provider mitigations were in place as of August 2026 and the described extraction method is no longer reproducible.