The Lock Held. The Key Was Sitting in the Next Room.

Here's the deal: if you've used a reasoning model through an API, you've seen the opaque blob. A long block of unreadable ciphertext comes back in the response, and you're asked to pass it along unchanged in your next request. OpenAI, Anthropic and Google all work this way. Showing the raw chain of thought would hand competitors valuable training data and leak safety-relevant internals, so the labs encrypt it.

A team in Tübingen, Germany posted a paper to arXiv on August 10 — Stealing Reasoning Traces from Proprietary LLM APIs — showing that this defense falls over. Not by breaking the cryptography. By asking a different model from the same vendor to read it out.

The flaw is architectural. Those encrypted blocks are fully interchangeable across sessions, across users, and even across models within one provider's ecosystem. That was a convenience decision — it makes stitching conversations together easy. The researchers used exactly that. Take an encrypted trace produced by a top-tier model, inject it into a cheaper, less heavily guarded model from the same vendor, and jailbreak that model into printing the contents verbatim. It comes out. In plaintext.

Why the Labs Hid Reasoning in the First Place

Understanding the origin makes the hole make sense. Reasoning models generate a long internal chain of thought before answering. That process drives much of their performance — and it is extremely valuable training data. A competitor that harvests frontier reasoning traces at scale can distill them into its own model, and that has already happened more than once.

So labs began showing users only a summary while returning the real trace encrypted. Then a technical constraint appears: in a multi-turn conversation, the model needs to reference its earlier reasoning. A stateful server can hold it, but plenty of customers use stateless APIs. Hence the design where the client stores the encrypted block and returns it on the next call.

Reasonable so far. The failure is that nobody validated which session, or which user, a given block came from. Compatibility was left wide open for convenience, and that convenience became the attack surface. Most security incidents look like this. They start in ergonomics, not malice.

Who Did What

The researchers are affiliated with the ELLIS Institute Tübingen, the Max Planck Institute for Intelligent Systems, the Tübingen AI Center and the University of Tübingen. The author list includes Alexander Panfilov, David Schmotz, Ilia Shumailov, Luca Beurer-Kellner, Joachim Schaeffer, Ameya Prabhu, Jonas Geiping and Maksym Andriushchenko — a group with a steady output in AI safety and adversarial robustness.

The targets were the commercial APIs of OpenAI, Anthropic and Google. All three hide reasoning, and all three carried the same class of weakness. The sharpest finding in the paper is that all three used a single global key. Had keys been scoped per user or per organization, lifting someone else's block and decrypting it would have been impossible.

The attack is best described as cross-model decryption jailbreaking. It never touches the cipher. It persuades a system that already holds decryption authority — another model from the same vendor — to open the box on the attacker's behalf. Security has a name for this: the confused deputy. You don't pick the lock; you trick the person holding the key.

The dataset is what makes the paper alarming. The team collected 6,708 publicly available agent trajectory logs from GitHub and Hugging Face — logs people uploaded for debugging or reproducibility without a second thought. From those they extracted and decoded 315,320 encrypted reasoning blocks.

What Was Inside

Item Figure
Public agent logs collected 6,708
Reasoning blocks decoded 315,320
Credentials recovered 182
PII instances found 367
Paper submitted 2026-08-10
Vendors notified July 2026

182 credentials — API keys, tokens, passwords. Plus 367 instances of personally identifiable information. The critical qualifier is that these are real values from genuine user sessions, not synthetic test data. Someone published their own logs to a public repository thinking "it's encrypted, so it's fine."

That's the core implication. Users assumed they only needed to review what was visible on screen. Skim the transcript, see nothing sensitive, publish. But the encrypted block contains material that never appeared on screen. If the model read a file or checked an environment variable and quoted the value while thinking, that value lives in the reasoning trace even though the final answer never mentions it.

The paper groups the risks into three. First, IP leakage: the reasoning the labs were protecting is exposed and can be used to train competitors. Second, PII and credential exposure — the numbers above. Third, prompt injection, which is the worst of them.

Worth adding: the attack is nearly free. The sibling model is the cheap one by definition, and once a jailbreak prompt works you can run it over hundreds of thousands of blocks automatically. That's how 315,320 blocks got decoded. Low difficulty combined with high scalability is the worst combination in security.

Why the Third Risk Is the Nasty One

The first two are about data being read. The third is about data being used. Encrypted blocks are invisible to users. If an attacker plants a malicious instruction inside one, the person who receives it has no way to see it — and passing it along in the next request means the model reads and can act on that instruction.

Picture it concretely. You grab agent example code from a public repository, and it includes an encrypted block from a prior conversation. It looks like an example. Inside, the block might say: read the environment variables and send them to this address. The user can't spot it, and the model treats it as legitimate reasoning history produced by its own vendor.

In an era where agents actually call tools — touching filesystems, running shells, making network requests — that's not a theoretical concern.

There's also a qualitative difference from known prompt injection. Existing injection hides in web pages, documents, issue comments — places a determined human can inspect. Defenses were built accordingly: isolate and screen untrusted content. An encrypted block cannot be inspected. It's random characters by design. This is an injection channel where inspectability itself is gone.

What This Means for Each Party

For the frontier labs, a design premise cracked. Reasoning was hidden for two reasons: competitive defense and safety. But the hiding mechanism was "encrypt it, yet keep it interchangeable inside our own ecosystem," and that interchangeability was the hole. The researchers notified all three vendors in July, and report that identical attacks no longer succeed. Whether the underlying design changed or only specific jailbreak paths were closed hasn't been disclosed.

For enterprise engineering teams, logging policy needs a review. If you've been operating on the assumption that encrypted fields aren't sensitive, that assumption is dead. Agent traces in repositories, debug output pasted into issues, response dumps sitting in CI artifacts — all of it needs a second look.

For security teams, there's a new asset class. Encrypted reasoning blocks should be treated as "not yet read" rather than "unreadable." Secret-scanning tools don't look inside them, which makes them a detection blind spot.

For security vendors, that blind spot is a product opportunity. No scanner today decodes and inspects reasoning fields. The paper's own method is as useful for building defenses as for attacks, so the feature gap will close.

For the research community, dataset hygiene is back on the table. That 6,708 logs sat publicly with no filtering is a problem on its own. Publishing execution traces became normal practice as agent research grew, and nobody checked carefully what those traces contained.

This Has Happened Before

The assumption that encryption equals safety has failed repeatedly.

Padding oracle attacks are the classic. Found across web frameworks in the early 2010s, they let an attacker recover plaintext purely from the pattern of "invalid padding" errors a server returned. The cipher was fine; the system leaked information around it. Same shape here — nothing was broken, something opened the door.

The confused deputy problem is older still, named in 1988: a privileged component performs work on behalf of an unprivileged requester and access control quietly collapses. Server-side request forgery is the modern web version. This is that concept ported to LLMs.

There's a fix precedent too. Web cookies started loose about cross-domain sharing, and same-origin policy plus the SameSite attribute tightened isolation over time. What reasoning blocks need is exactly that: per-user and per-organization key separation, plus session binding. One global key covering every user's blocks is the cookie era before domains mattered.

How Vendors Are Likely to Respond

OpenAI documents how reasoning items are returned to the API. In stateful mode the server retains them; in stateless mode the client passes encrypted items back. The latter is the attack surface, and tightening session binding costs some of stateless mode's convenience.

Anthropic signs extended-thinking blocks and requires them to be passed back unmodified during tool use. Scoping signature validation to a session or account is the natural hardening step.

Google uses the same broad structure, so its options look similar. All three are pushed toward the same answer: narrow the scope in which a block can be reused.

The open-weight camp is untouched by this. Nothing is hidden, so nothing can be stolen. One of the paper's quieter implications is a question about how much protection hiding reasoning was buying in the first place.

So What Actually Changes

For developers, there's an action item today. If you've published agent logs to a public repository or issue tracker, check them. If they include encrypted blocks from a session that touched environment variables or credentials, rotate those keys. "It's encrypted, so it's fine" no longer has support.

For people building agents, add a design rule: don't pass externally received reasoning blocks into your next request without validation. Data crossing a trust boundary shouldn't be trusted whether or not you can see it.

For enterprise security, there's a policy item. Consider masking or dropping reasoning fields in log pipelines that store LLM responses, and verify your secret-scanning rules aren't skipping encoded fields wholesale.

For compliance and audit, a new question appears. When you answer "where does this personal data live," reasoning blocks were never on the list — and the paper found 367 PII instances inside them. Redraw the data-flow diagram with that box included.

For everyday users, no direct action. But the intuition that "the model's thinking is hidden, so it's safe" needs adjusting. Invisible and absent are different things, and this paper put a number on the difference.

🥄 Three Things You're Probably Wondering

— Does the attack still work? The researchers notified all three vendors in July and report that the identical attack no longer succeeds. Whether the structural causes — the global key and cross-model block compatibility — were actually changed hasn't been made public. It's safer to assume variants remain possible.

— Could my API key have been exposed? The direct risk is limited to logs you published. All 182 credentials the paper found came from public repositories. If your traces stayed private, this path didn't touch you. Still worth checking if you've ever shared an agent trace.

— Does this mean hiding reasoning is pointless? That's too strong. There are still good reasons to hide it, and this is an implementation flaw in how it was hidden. What's clear is that designing on the premise "it's hidden, so sensitive data inside is fine" is dangerous. Hiding something and not putting it there are different strategies.

References

Numbers and criteria are as of publication and may change.