What Providers Hide in Encrypted Reasoning Blobs and Why Opaque Is Not Safe

A paper published this week demonstrates that encrypted reasoning blobs returned by Anthropic, OpenAI, and Google APIs are portable across sessions, users, and model versions within a provider family. The researchers replayed reasoning traces from stronger models into weaker ones, jailbroke the weaker model to transcribe the content verbatim, and recovered 315,320 reasoning blocks from public repositories. They found 182 credentials and 367 PII artifacts. Providers have patched the specific extraction technique. The architectural lesson has not gone away.

The API Pattern

Extended thinking APIs give the model a scratchpad. The model reasons through a problem, produces a thinking block, then produces a response. The provider returns both to the client.

For subsequent turns, the client passes the thinking block back so the model has its prior reasoning as context. Storing that state server-side would require the provider to maintain a session store. Encrypting it and handing it to the client is cheaper and stateless.

A Claude extended thinking response looks roughly like this:

{
  "content": [
    {
      "type": "thinking",
      "thinking": "Let me look at the auth module. The session token is stored in...",
      "signature": "EqABCkgIBBgCIkBz3mT9..."
    },
    {
      "type": "text",
      "text": "I've reviewed the auth module. Here is what I found."
    }
  ]
}

The signature field is an opaque blob. On the next request, the client passes the thinking block back including the signature. The provider verifies and decrypts it, uses the prior reasoning as context, and produces a new thinking block.

The thinking content in the thinking field is visible to the client in current Claude API modes. But the signature - the integrity and authenticity blob - is what enables replay. The paper found that this blob was compatible across model versions. A signature generated by one model in the family validated against another.

OpenAI's o-series and Google's reasoning models have analogous patterns. The specific field names differ. The architectural shape is the same: an opaque blob the client stores and echoes back, treated by the model as trusted prior context.

The Trust Boundary Mistake

Opaque does not mean harmless. It means invisible to inspection tools.

Every secret scanner, DLP proxy, SIEM pipeline, and log analyzer that processes LLM API traffic makes the same implicit assumption: plaintext fields are what matter. The messages array, the tool_results, the content blocks - those get inspected. A field that is a base64 blob gets skipped or logged as-is without analysis.

That assumption fails in two directions.

First, the model treats encrypted reasoning blocks as more authoritative than user input. The reasoning is its own prior work. When a model sees a thinking block attached to the conversation, it treats that context as ground truth for subsequent reasoning. The paper's fourth attack vector exploits this directly: encoding exfiltration instructions inside an encrypted reasoning block. A model that would reject the same instruction from a user may follow it when it appears to come from its own prior reasoning.

Second, the content of reasoning blocks is not just intermediate conclusions. A model that is handed an API key in a tool result will reason about that key. "I need to use this key to call the billing API" gets encoded in the next thinking block. That content persists in the blob that the client stores and echoes. It never appears in any plaintext field in the request or response. Standard secret scanning sees nothing.

Replay Risk

The researchers found that all models within a provider family shared identical encryption keys. A thinking block generated by Claude Opus 4.8 was valid input for Claude Haiku 4.5. The model family treated them as interchangeable.

This creates three replay surfaces.

Cross-model replay. A reasoning block produced by a capable model can be passed to a less safeguarded model in the same family. The smaller model has weaker refusals. The jailbreak the paper used was a direct transcription request with an assistant-turn prefix exploit - asking the model to copy its own prior reasoning verbatim inside a specific tag. Against a model that already had the reasoning as trusted context, this worked.

Cross-session replay. Reasoning blocks have no session binding. A block from one conversation is valid in another. If a developer copies a block from a debug log and pastes it into a new session, the new session inherits whatever was encoded in that reasoning. If the block contains exfiltration instructions planted by an earlier prompt injection, the new session executes them.

Cross-user replay. The researchers collected 315,320 reasoning blocks from public repositories. Agent frameworks that log full API payloads, shared debugging traces, open-source projects that committed .env equivalents containing API responses - all of these expose reasoning blocks that can be replayed against the originating provider.

The 182 credentials recovered were not all from direct API exploitation. Many came from reasoning blocks in public repositories. Blocks that encoded an API key the model reasoned about during a session the developer logged and committed.

What Gets Encoded in the Reasoning

The visible part of a thinking block is legible to the developer. The risks are in what gets encoded persistently.

Tool outputs. When a model calls a tool and gets a response, it reasons about that response. A tool call that returns database credentials, internal hostnames, or customer records leaves that data in the next reasoning block. The tool call result may be ephemeral in the application. The reasoning trace is not.

Intermediate conclusions. A model working through a multi-step task encodes its beliefs about the task state in its reasoning. "The target file is at /etc/shadow, I should not read this directly, instead I will..." - that reasoning is in the blob whether or not it appears in the response.

Secrets observed in context. A session that processes a config file containing an API key will produce reasoning blocks that reference that key. The key may never appear in the model's text response. It is in the thinking blocks attached to every subsequent turn.

Injected instructions. As noted: a reasoning block can carry instructions that execute in future turns with higher trust than user input. An attacker who can influence one turn's reasoning - via prompt injection in a tool result, for instance - can encode a persistent instruction that survives for the rest of the session.

Controls That Address the Architecture

The providers patched the shared-key problem. That stops the specific cross-model extraction the paper demonstrated. The broader controls are architectural.

Bind blobs to context. An encrypted reasoning block should be bound to the account, session, model version, and timestamp that generated it. Attempting to use the block outside that binding should fail validation. The simplest form: include those fields in the HMAC input. A block from session A is cryptographically invalid in session B.

Reject cross-model replay. Model version should be part of the binding. A block generated by claude-opus-4-6 should not validate against claude-haiku-4-5-20251001. The shared-key issue was the failure here. Per-model-version keys or per-session keys would have prevented the cross-model extraction.

Redact from log pipelines. Logging infrastructure should treat encrypted reasoning fields as sensitive by default. Log that a reasoning block was present and its byte size. Do not log the content. This is the same principle as logging that an Authorization header was present without logging its value.

Strip at integration boundaries. Before a request or response is forwarded to any third-party service - LangSmith, Helicone, a SIEM webhook, a custom audit pipeline - reasoning fields should be stripped. The third party has no operational need for the blob and no mechanism to inspect it. Forwarding it exposes it to an additional attack surface.

Enforce retention. Reasoning blocks should expire with the session. A block that persists in a client-side log, a replay buffer, or a debugging artifact is a liability after the session closes. Retention policy for LLM API payloads should explicitly cover encrypted reasoning fields as a distinct sensitive field class.

What a Proxy Can Enforce

Rye operates at the API boundary and sees every field in every request and response, including opaque blobs. Rye cannot decrypt provider-encrypted reasoning blocks. The encryption is the provider's and the key is not available at the proxy. That is not the relevant control.

What a policy-aware proxy can enforce:

Presence policy. Flag or block requests that include an encrypted reasoning field when the workspace configuration does not expect extended thinking to be active. An agent sending a thinking block it did not generate locally is anomalous.

Size anomalies. A reasoning block that is significantly larger than typical for the model and task may indicate encoded data. An alert threshold on blob size per request is a low-cost signal with low false-positive rates in normal operation.

Cross-model routing detection. If the proxy records which model version generated a session's reasoning blocks and sees a subsequent request pass a block to a different model version, that is a replay indicator. The proxy has the session context to detect this. The provider's endpoint does not, after the patch, accept mismatched blocks - but logging the attempt has value.

Strip before third-party forwarding. Any workspace that routes API traffic to an observability integration can have a policy that strips thinking, signature, and equivalent encrypted fields from the payload before forwarding. The audit record captures that a reasoning block was present. The content does not leave the proxy.

Retention enforcement. The proxy's audit log can store a hash and size of each reasoning block without storing the content. When the workspace retention window closes, the stored metadata ages off with the rest of the session record. Full payload logging can be disabled for reasoning fields specifically.

Audit metadata. Every request that carries an encrypted reasoning block gets an audit record: reasoning_block_present: true, size_bytes: 4821, model: claude-opus-4-6, session_id: sess_01234, turn: 3. Without decrypting anything, this record supports incident investigation. If something went wrong in turn 3, you know a 4.8KB reasoning block was present and which model produced it.

The gap the paper exposes is not just in provider key management. It is in the assumption that fields the client cannot read are not worth auditing. Every tool in the standard observability stack makes that assumption. A proxy that records structure without content closes the audit gap without requiring access to the encryption key.

Should You Replicate This?

The specific attack does not work. The providers patched it and confirmed remediation. Running the reproduction yields "patch confirmed" - that is not a publishable finding.

Going further means finding novel variants, testing other providers, or discovering new attack surfaces in the same architectural class. That requires significant time investment, legal review of provider ToS for security research, and coordinated disclosure process. The paper's authors already did this work systematically. Reproducing their methodology to find what they did not find is a long search with an uncertain result.

The more useful research direction is on the detection side. Building a test harness that generates realistic reasoning block traffic, applies proxy-level policy rules, and shows what the audit record looks like when an anomalous blob appears - that is novel, it is demonstrable, and it directly tests whether the controls described above work. That is also something that can be done without touching a live provider API in a legally ambiguous way.

The paper is worth reading and worth citing. The experiment is not worth replicating.

The core finding to carry forward: credentials and sensitive data can appear in encrypted reasoning fields without ever appearing in any plaintext field your existing tooling inspects. The audit gap is real even after the providers patched the extraction technique.