Your model's hidden reasoning isn't as hidden as you think

What's in the encrypted blob

When you call a reasoning model through Anthropic's, OpenAI's, or Google's API, the visible answer is only part of what comes back. Underneath it, the provider also returns the model's step-by-step reasoning — but not in plaintext. To protect the intellectual property in that reasoning (and to avoid handing you a roadmap for jailbreaking the model), providers encrypt it into an opaque block and hand it back to you as a bearer token. Your client stores it and passes it back on the next turn so the model can stay coherent across a multi-step conversation, but you, the developer, never get to read it.

That design is reasonable on paper: keep the reasoning server-side in spirit, even though it physically transits through the client. Panfilov, Schmotz, Shumailov, Beurer-Kellner, Schaeffer, Prabhu, Geiping, and Andriushchenko show it isn't reasonable in practice, because the encrypted block was never bound tightly enough to the context it came from.

The trick: replay, don't jailbreak

The core finding is architectural, not cryptographic. These encrypted reasoning blocks are fully interchangeable across sessions, across users, and — critically — across models within the same provider's family. That last part is what makes this an exploit rather than a curiosity.

The attack doesn't touch the strong model at all. Instead of trying to jailbreak a frontier model directly, which providers harden aggressively, the authors take an encrypted reasoning trace produced by that frontier model and splice it into a request sent to a weaker, less-safeguarded sibling model from the same provider. The weak model has no way to tell that the block wasn't its own. It dutifully decodes the block as if resuming its own chain of thought — and echoes the stronger model's private reasoning back in plaintext, verbatim. No red-teaming, no prompt engineering against the strong model, no gradient access. You're not breaking the vault; you're handing the ciphertext to a teller who doesn't know it isn't theirs.

Four ways this gets exploited

The paper doesn't stop at a proof of concept — it walks through four concrete consequences, demonstrated across all three providers:

Anti-distillation bypass. Providers hide chain-of-thought partly to stop competitors from distilling a frontier model's reasoning into a cheaper one. This vulnerability defeats that protection directly: an adversary can harvest the exact reasoning a flagship model produced, at scale, without ever calling that model in an unsafe way.

Mass PII and credential leakage. This is the part that should worry anyone running a product on these APIs. Developers routinely post session logs and debugging traces to public repos, assuming the encrypted block is inert noise. It isn't. The authors scraped 315,320 publicly posted reasoning blocks and decoded them, recovering 367 PII artifacts and 182 credentials — secrets and personal data that were sitting in plain sight, protected by nothing more than the assumption that nobody could read the ciphertext.

Hazardous reasoning behind a safe answer. Safety tuning mostly targets the visible output. A model can refuse a harmful request in its final answer while its hidden reasoning worked through the harmful content on the way there. Because that reasoning was assumed unreadable, providers didn't need to scrub it as hard. This attack removes that assumption and exposes what was underneath the refusal.

Invisible prompt injection. Encrypted blocks are opaque to everyone except the decoding model. That makes them a clean payload channel: an attacker embeds an instruction inside a block, gets it into a publicly shared agentic trajectory, and any downstream agent that ingests that trajectory and replays the block decodes and potentially acts on the hidden instruction — with nothing visible in the log to flag it.

Why this is an architecture problem, not a prompting problem

The pattern that jumps out to me is that every one of these four attacks routes around the safety work rather than through it. Providers spend enormous effort aligning the model that generates the reasoning. None of that effort touches the transport layer that carries the reasoning between calls. The encrypted block was treated as a storage problem — keep the plaintext off the wire — instead of an authentication problem — bind the ciphertext to the specific session, user, and model that produced it. Without that binding, encryption gives you confidentiality against outside observers but nothing against a party who already holds a valid, differently-sourced block and a compatible decoder.

This is a familiar shape if you've worked with bearer tokens anywhere else: a token that isn't scoped to its issuing context is a token that will eventually be replayed somewhere it doesn't belong. The paper's own proposed mitigations follow that logic — cryptographically binding traces to the originating session, user, and model, plus system-level controls so a decode request can't silently cross that boundary.

What I'd take from this if I were shipping on these APIs today

The practical fix is on the provider side, and the paper says the authors ran responsible disclosure before publishing, so I'd expect binding fixes to land there over time. In the meantime, the actionable move for anyone building products on reasoning APIs is to stop treating those encrypted blocks as inert. Don't paste session logs into public repos, bug reports, or shared notebooks. If you're storing conversation state for multi-turn agents, treat the reasoning block with the same handling discipline you'd give an auth token, because that is functionally what it is right now — a bearer credential for someone else's private reasoning, and in some cases for hazardous content that was never supposed to leave the model at all.