Encrypted Reasoning Blocks Are Bearer Secrets: What 315,320 Decoded Traces Exposed

A 2026 security study reconstructed 315,320 encrypted reasoning blocks collected from public agent traces. The headline sounds like a cryptographic break. The more useful diagnosis is narrower: encryption protected the blocks from direct reading, while weak context binding let a compatible model inside the same provider ecosystem act as a decryption oracle.

That distinction matters. The paper's original attacks were no longer reproducible after responsible disclosure, according to its authors. The lasting issue is therefore an engineering contract, not a claim that Anthropic, OpenAI, and Google remain exploitable today. Any opaque reasoning state held by a client must be treated as sensitive, transferable ciphertext whose authorization boundary requires explicit identity, session, model, sequence, expiry, revocation, and replay controls.

Calling these blocks bearer secrets is a security analogy. They are not API keys and do not authenticate a caller. In the July 2026 systems studied, however, possession of a valid block plus ordinary access to a compatible model was enough to make the provider process and sometimes disclose its hidden content.

What the APIs were trying to achieve

Reasoning models generate internal work before producing a visible answer. Providers may return only a summary while packaging the fuller state in an opaque field that clients send back during later turns. Current documentation still illustrates this general architecture:

• Anthropic's thinking documentation describes a signature carrying an encrypted copy of full reasoning and instructs clients to preserve relevant thinking blocks.
• OpenAI's reasoning guide documents encrypted_content on reasoning items for stateless or manually managed context.
• Google's thought-signature documentation describes encrypted representations used to preserve reasoning context across multi-step interactions.

This design serves three legitimate goals. Confidentiality prevents a client from reading proprietary reasoning directly. Integrity lets the provider reject a modified block. Client-side storage also supports stateless APIs without keeping every reasoning trace in a server database.

Confidentiality and integrity do not automatically provide authorization or replay resistance. A ciphertext can be authentic and unmodified while still appearing under the wrong user, session, model, or position in a conversation.

What the researchers demonstrated

The August 10 preprint, Stealing Reasoning Traces from Proprietary LLM APIs, tested API behavior available in early July 2026. It distinguished three portability boundaries:

1. Cross-session: a block could be reordered or reused in a different conversation.
2. Cross-user: a block obtained from another user's published trace could be replayed through the attacker's API session.
3. Cross-model: a block from one model could be processed by another compatible model from the same provider.

The third boundary created an asymmetry. A frontier model might resist requests to reveal hidden reasoning, while a smaller sibling model had weaker anti-extraction behavior. The researchers replayed a valid block into that weaker model and prompted it to transcribe the content.

The experiments covered models from Anthropic, OpenAI, and Google. They did not show that a Claude block could be decoded by an OpenAI or Google model. Compatibility was demonstrated within each provider ecosystem, and the matrix was not symmetric for every model pair.

This was also not a single deterministic decrypt operation. The weaker models acted as fuzzy decoders. The pipelines used repeated samples, token-count comparisons, filtering, and reconciliation models. The authors compared reconstructed length with provider-reported reasoning-token counts across 120 Codeforces problems and found close tracking, but they did not possess plaintext ground truth. The results support high-fidelity reconstruction, not a guarantee that every recovered token exactly matched the original hidden trace.

Reading the 315,320 figure correctly

The researchers collected 6,708 public agent trajectories from GitHub and Hugging Face and reconstructed 315,320 reasoning blocks. Those numbers describe the scanned dataset, not 315,320 users or 315,320 confirmed leaks.

Their privacy pipeline reported:

Benchmark traces matter because datasets such as ClawBench supply synthetic personas containing names, passports, and payment details. The headline totals therefore cannot be described as entirely real-user secrets.

After excluding benchmark sources, the authors found 704 distinct artifacts. Sixty-four were present only in hidden reasoning and absent from the visible chat history. Reported examples from genuine user sessions included 62 API keys, 33 passwords, 24 access tokens, seven private keys, 30 personal email addresses, and six non-localhost IP addresses.

The public scan was targeted rather than exhaustive, and the classification depended on an LLM-as-a-judge pipeline. Its rates should not be extrapolated to all agent logs. The evidence establishes that real leakage occurred and that plaintext sanitization alone could miss it.

Four security consequences

The paper organized the impact into four paths.

Reasoning extraction and distillation. A cheaper model could expose a stronger model's intermediate solution process. Monitoring only the frontier endpoint could miss extraction performed through a sibling model.

Private-data recovery. Developers may publish raw traces after removing visible secrets while leaving opaque reasoning fields untouched. The hidden state can repeat values encountered during repository cleanup, tool calls, or conversation history.

Hazardous-content recovery. A visible answer may safely refuse a request while hidden reasoning has already developed sensitive details. Output filtering then protects the visible channel without protecting the encrypted state.

Invisible prompt injection. A malicious instruction can be embedded inside a valid opaque block and later replayed by another workflow. Monitors that inspect only visible text cannot evaluate the payload. This expands the same context-quarantine problem discussed in our document-borne AI worm playbook: untrusted state needs provenance and an execution boundary even when humans cannot read it.

Why encryption was not the whole contract

An encrypted envelope usually answers two questions: can an outsider read the bytes, and can they modify the bytes without detection? An agent workflow needs additional answers:

• Which user is allowed to replay the block?
• Which conversation and predecessor turn does it belong to?
• Which model or model class may consume it?
• Can it be replayed twice or moved out of order?
• When does it expire?
• Can a provider revoke a single block or a compromised key generation?
• What telemetry detects anomalous reuse?

Without those properties, an opaque block is closer to portable capability-bearing state than passive ciphertext. Its security depends on the provider's acceptance logic as much as on the cipher.

This also clarifies why integrity was insufficient. A MAC can prove that the provider created a block. It cannot prove that the current caller, session, model, and position are authorized unless those attributes are cryptographically bound and checked.

A defensive contract for providers

The paper proposes a defense-in-depth design rather than one patch.

The strongest architectural option is server-side reasoning storage, with clients holding only random lookup identifiers. This removes the ciphertext payload from client control but increases storage, state, and migration complexity.

For stateless APIs, envelopes should bind the user, session, model, turn order, previous block, and relevant history into authenticated context. API gateways can reject cross-model blocks, detect a signature appearing across accounts or sessions, and rate-limit repeated decode failures. Providers also need key rotation, legacy-block rejection, targeted revocation, and a safe migration path for legitimate archived sessions.

Model refusal training remains useful, but it is the final layer. A protocol should not rely on every current and future model being perfectly resistant to transcription prompts.

A negative-test matrix for reasoning state

Security promises become trustworthy when they are executable tests. A provider or enterprise gateway should freeze representative conversations and verify both acceptance and rejection behavior.

The matrix has to preserve legitimate compaction, tool use, routing, and approved model switching. Security that silently breaks normal recovery will be bypassed by clients. Compatibility and isolation must be designed together.

What application teams should do now

The paper says the original attack stopped working after disclosure. That reduces immediate exploitability, but it does not make old logs safe by inspection.

Application teams should inventory every field used to carry opaque reasoning state, including signature, encrypted_content, and thoughtSignature. Raw transcripts should be classified as sensitive even when visible text has been sanitized. Before publishing traces, fixtures, issues, telemetry dumps, or research datasets, remove the entire opaque state rather than trying to clean what the client cannot read.

If historical traces containing secrets were shared, delete accessible copies where possible and rotate exposed credentials. Current provider documentation should be checked before implementing replay, compaction, or model switching because behavior changed after the July experiments and can change again.

Finally, logging should distinguish user-visible content from provider-issued opaque state. The latter needs retention limits, access control, provenance, and deletion workflows comparable to credential-bearing debug logs.

FAQ

Did the researchers break the encryption algorithm?

The paper does not report a conventional cryptographic break. It exploited provider-side processing: a compatible model accepted a valid encrypted block and was induced to reveal reconstructed content.

Were 315,320 secrets exposed?

No. The number is the total decoded blocks. The paper classified 1,028 blocks as containing at least one real sensitive artifact in its targeted public dataset.

Were all 367 PII artifacts from real people?

No. The headline figure includes benchmark traces with synthetic personas. The paper separately reports 704 distinct artifacts after excluding benchmark sources.

Could blocks move between Anthropic, OpenAI, and Google?

The study demonstrated compatibility within each provider ecosystem, not across providers.

Is the attack still working?

The authors state that after responsible disclosure they could no longer launch the same attacks, and that the Figure 1 results were no longer reproducible by August 2026. Providers did not publicly document every mitigation, so legacy-block status and the exact repair layer remain unclear.

Why delete encrypted state if visible logs are already sanitized?

Hidden reasoning can restate secrets that were removed from visible text or contain values absent from the visible history. A client cannot reliably sanitize opaque content it cannot inspect.

References

• Stealing Reasoning Traces from Proprietary LLM APIs
• Stolen Thoughts research project
• Matthew Green: Fooling around with encrypted reasoning blobs
• Anthropic thinking documentation
• OpenAI reasoning guide
• Google thought signatures