What Is a Reasoning Trace Leak? How Weaker Models Decoded Frontier Reasoning — and the 182 Credentials That Leaked

What a reasoning block is, and why providers encrypt it

Models that “think before answering” produce an intermediate body of text along the way — working through logic, trying approaches, discarding options — before settling on the answer the user sees. That intermediate text is the reasoning trace, and it is valuable in two directions at once.

It is valuable to the provider, because it is intellectual property competitors would happily use to train their own models. And it is valuable to an attacker, because while the model reasons it tends to quote whatever sits in its context — including material that never surfaces in the final answer.

So every provider reached for the same design: encrypt the reasoning trace and hand it back to the caller as an opaque blob. On the next API call the client returns the blob so the model can pick up its own context. It saves server-side storage and it looks safe — until someone asks who else is able to decrypt it.

The attack — let a smaller model do the translating

Because the blob travels across models, the researchers never had to break the encryption. They did something far more direct: take a blob produced by a frontier model, feed it to a smaller sibling model from the same provider, and ask that model to write out what is inside.

The smaller model decrypts the blob normally, because it holds the same key. And because it was trained with lighter safeguards, it happily transcribes the contents verbatim. The result is the frontier model’s private reasoning, obtained without jailbreaking the frontier model even once.

Provider	Source models tested	Model used as decoder
Anthropic	Claude Opus 4.8, Sonnet 5 / 4.6 / 4.5, Fable 5	Claude Haiku 4.5
OpenAI	GPT-5.6 Sol / Terra / Luna, GPT-5, GPT-5-mini, o4-mini	GPT-5.6 Luna
Google	Gemini 3.1 Pro, Gemini 3 Pro, Gemini 3.5 / 3 / 3.1 Flash Lite	Robotics ER-1.6

All three providers were affected identically. This is not one vendor’s bug — it is the consequence of a shared design choice: push state-keeping onto the client, protect it with encryption alone, and never bind the blob to the identity or session that produced it.

Four ways the flaw could be abused

Abuse path	What it enables
Distillation	Harvest frontier reasoning traces to train your own model without paying to query the frontier model directly — the researchers estimate roughly USD 720 per 10,000 traces
Secret extraction	Decode the reasoning attached to AI agent logs people have published, and harvest the credentials and personal data caught inside
Jailbreak recovery	The visible answer looks safe, but harmful content the model reasoned through and then discarded is still in the block and can be pulled back out
Invisible prompt injection	Hide malicious instructions inside a block the user cannot read, and have them fire across sessions — an extension of the risk we covered in our piece on prompt injection and business systems

What actually came out

What separates this from a purely theoretical result is that the team did not stop at proving feasibility. They collected AI agent logs that people had genuinely published in public places, and decoded them to see what was inside.

Finding	Count
Public agent trajectories collected and analysed	6,708
Reasoning blocks decoded	315,320
Trajectories containing at least one sensitive item	328 (4.9%)
Personally identifiable information recovered	367 items
Credentials recovered	182 — 62 API keys, 33 passwords, 24 access tokens, 7 private keys
Items that appeared nowhere in the visible chat history	64

Compare it to a mistake you already know

If this feels abstract, compare it to a mistake every development team has made: committing a file with a password in it, then forgetting it is still in the history. Deleting the file later does not help — the history keeps it, and secret scanners find it.

Reasoning blocks are the same problem, worse in two ways. First, the person sharing cannot see what is inside, because it is an unreadable blob rather than a text file whose contents are obvious at a glance. Second, the secret scanners your organisation already runs cannot see it either — they scan plaintext, not a blob that must be handed to a model before it becomes readable.

The result is a file type that is invisible to both human review and automated tooling, yet fully legible to anyone who knows the trick. That is why 64 items absent from the visible chat is the single most important number in the paper.

Has it been fixed?

Yes. The researchers disclosed to all three providers and to the affected platforms before publishing, and the report states that the main demonstrated attack is no longer reproducible as of August 2026 following server-side mitigations.

Where the researchers say the fix belongs

The paper proposes mitigations at four layers, and only the last is the user’s job — the other three are homework for the providers.

1. Architecture: store reasoning traces server-side and refer to them by reference, instead of handing the caller an encrypted blob. This removes the problem at its source.
2. Cryptography: bind each envelope to the user, session and prompt that produced it using authenticated encryption (AEAD), so cross-context replay is rejected automatically.
3. Infrastructure: isolate blobs so one model’s output cannot be fed to another, add velocity and anomaly detection for bulk decoding attempts, and support signature revocation once abuse is found.
4. Model and user level: train models to refuse “decode this and print it” requests, and on the user side, strip reasoning blocks before publishing logs and never commit raw API transcripts.

Note that the first three involve a trade-off. Providers pushed the blob to the client in the first place because it saves server-side state cost; moving it back raises that cost. It is a clean example of how an engineering decision that looks purely about efficiency turns out to be a security decision.

What to change, regardless of the patch

This is worth reading not because the hole is still open, but because it exposes an assumption many organisations hold without noticing: if the screen does not show it, it is not there.

Practice	Why
Never put credentials in a prompt or context	What you never send cannot ride out in the reasoning. Hold tokens in a service layer and let the AI call through it.
Treat AI agent logs as confidential	Do not commit them, attach them to issues or upload them publicly — and if you must share, strip the reasoning blocks first.
Run AI under the user’s own permissions, never a super-user account	If context leaks, the blast radius is limited to what that user could already see.
Rotate keys and tokens on a schedule	The same lesson as identity-based attacks — long-lived secrets are the ones that hurt longest after a leak.
Enforce two-factor authentication on important accounts	A leaked password stops being useful if a second factor still stands in the way — see our guide to 2FA.

How this connects to putting AI on your ERP

This maps directly onto the question we hear most often when a customer considers connecting AI to their back office: “will our data leak?” The honest answer is that the primary risk is not the model provider quietly misusing your data — it is what your organisation feeds into the context, and where the traces of it end up.

When we designed the Saeree ERP connection to AI over MCP we settled on three rules. First, no credentials in the prompt — authentication happens at the service layer, not in text the model reads. Second, access runs under the requesting user’s own permissions, down to the rows and columns they could already see, rather than exposing the whole database to a model. Third, every call lands in the audit trail, kept separate from the message payload, so activity is reviewable without retaining raw context.

None of this is novel. It is the same position we set out in our articles on Claude data governance and zero data retention: the internal system is the source of truth and the owner of permissions, the model is an assistant that reads only what it is handed — and you should hand it as little as the job allows.

For the wider context on why AI security became an industry-wide agenda this month, see our piece on the cyber AI models all three labs shipped at once.

The dangerous secret is not the one you know you sent. It is the one that rode along inside the part the screen never showed you.

- Paitoon Butri, Grand Linux Solution Co., Ltd.

References

Information verified as of 3 September 2026.

• Panfilov et al. — Stealing Reasoning Traces from Proprietary LLM APIs (arXiv:2608.09867, 10 August 2026)
• The Hacker News — OpenAI, Anthropic, Google API Flaw Let Weaker AI Models Decode Hidden Reasoning (12 August 2026)
• Cyber Security News — Top AI Models APIs Flaw Exposes Hidden Reasoning
• NSFOCUS — Encrypted Reasoning Blocks of Proprietary LLMs Can Be Stolen via Cross-Model Replay