The Encrypted Reasoning Blob Has a Global Key

On May 29, Matthew Green, a cryptography professor at Johns Hopkins and one of the more reliable voices on what actually breaks in production cryptography, published a blog post that opens with the expected academic hedging and closes with something that should make every API developer pause. He had been given a Social Security number in one account’s reasoning chain. He took the encrypted blob that came back from the API. He replayed it in a different session under a different account. The SSN came out the other side. His bug bounty submissions to both OpenAI and Anthropic received, in his words, “minimal concern.”

What the Blob Actually Is

When you enable extended thinking in Anthropic’s API, the response includes a content block called a thinking block. Inside that block there are two fields. The first, thinking, contains the model’s reasoning — either a full plaintext transcript or a summarized version depending on the model and display mode. The second, signature, is described in Anthropic’s documentation as “an encrypted signature of the full thinking process, used for multi-turn continuity and tool use preservation.” When you send that block back in a follow-up turn, the server decrypts the signature to reconstruct the original thinking. The documentation notes that “the text in a round-tripped thinking field is ignored” — it’s the signature that drives the model’s actual context.

OpenAI offers a similar mechanism. For stateless deployments or zero-data-retention arrangements, developers can include reasoning.encrypted_content in their API request, which produces encrypted reasoning tokens that can be passed back in subsequent turns. OpenAI’s framing is more direct: they call it “encrypted reasoning tokens” and describe it as an explicit opt-in. Anthropic buries the security significance in documentation about “multi-turn continuity.”

The design rationale is real and reasonable: stateless inference servers can’t hold your conversation context between turns. For zero-data-retention arrangements, where the provider contractually doesn’t store your data after the response returns, some mechanism has to carry the reasoning state. The encrypted blob solves both problems. It externalizes state to the client, who passes it back, and the server decrypts it to resume context. This is web architecture from 2003 — client-side encrypted sessions, the same pattern Rails and Seaside used for cookie-based state management. It’s not new. That’s partly why it’s concerning.

There is a quiet irony in where the blob design is most commonly deployed. Zero-data-retention arrangements are sold specifically to organizations where data sensitivity is highest: healthcare providers, legal firms, financial institutions processing regulated information. The ZDR contract says the provider won’t store your data. The blob mechanism says the client carries it instead. What neither the contract nor the documentation says is that the encryption protecting that blob uses the same key for every client and every session — which means the security guarantee the ZDR contract implies is not the security guarantee the architecture actually provides.

The Attacks Green Built

Green’s central finding is that both providers appear to use a single global key to encrypt and authenticate all reasoning data sent to all clients. This means a blob generated in one session is accepted — and processed — in a completely different session under a completely different account. There is no per-session binding. There is no per-user binding. The authentication step verifies the ciphertext’s integrity but not its provenance.

The replay demonstration is straightforward: Green constructed a reasoning chain that touched a specific sensitive value, captured the resulting blob, and presented it in a new conversation as if it belonged there. The model processed the decrypted content from the replayed block and surfaced the sensitive data it had reasoned over — data it had no other way of knowing. He ran this across sessions. He ran it across accounts. It worked consistently.

The timing side-channel is more technically interesting and more practically limited. Green designed a protocol where bit value 0 triggered a simple computation in the model’s reasoning and bit value 1 triggered an extremely complex computation. Because the reasoning happens inside the encrypted blob, the model doesn’t expose the computation directly. But the blob’s metadata — specifically its size, its token count, and the wall-clock response time — varies predictably with the computation’s complexity. Green successfully extracted the byte value 0xA3 across 80 trials using block-size classification alone.

Both attacks have real limits. Models largely resisted actually outputting secrets even when replayed blobs were presented — the model processed the content but the safety layer still fired. The timing attack is slow: individual bits take multiple queries, and the practical extraction rate for anything large is implausible. Green assessed his own project as “mostly disappointing” from a pure impact standpoint. He was right about the impact. He was wrong about what the findings imply.

The Naming Problem

Anthropic chose the word “signature” for this field. In cryptographic convention, a signature implies authentication — proof that a specific party produced a specific message. The word does not imply that the signed payload contains a full encrypted reasoning transcript that gets decrypted and used server-side as the model’s actual context. The documentation’s primary description of the field is that it enables “multi-turn continuity and tool use preservation.” The word “security” does not appear in the field’s description. Neither does “contains.” Neither does “reasoning history.”

The consequence: developers who implement multi-turn extended thinking by following the documentation’s “pass the block back unchanged” instruction are doing the right thing technically while understanding it incorrectly semantically. They believe they are returning an opaque token that lets the server resume context. They are actually returning an encrypted payload that the server decrypts to reconstruct the model’s internal reasoning state. Those are not equivalent from a threat modeling perspective.

The HN comment thread on Green’s post produced the expected pushback: this is decades-old web architecture, nothing to see here, providers likely maintain server-side KV caches anyway. The first point is correct and damning rather than exculpatory. The client-side encrypted session pattern has a well-documented security history. BEAST was a chosen-plaintext attack against TLS-encrypted session cookies. POODLE exploited padding in SSLv3 cookies. Heartbleed exposed session state in memory. None of these required breaking the encryption. They exploited the architecture around it — the same way Green’s replay attack doesn’t require breaking AES, just noticing that the key is global.

The second point — that providers may be using server-side KV caching and not actually relying on these blobs for most requests — is probably true for normal traffic. But it doesn’t address the threat model. The blob mechanism exists and is documented. Developers are expected to pass it back. When they do, that path is live, and the global key property applies.

What Builders Need to Know

If you are using extended thinking with Claude Sonnet 4.6 or older Claude 4.x models in multi-turn mode, your API calls contain encrypted reasoning history that the server decrypts to drive the next response. If your reasoning chain touched sensitive data — a system prompt, user credentials, intermediate computations over private values — that data’s reflection is in the blob you’re passing back. The signature field is not a verification token. It is a compressed, encrypted memory of your model’s reasoning, and it travels over whatever network path carries your API calls.

The replay property means that an attacker with access to that blob — through a compromised request log, a misconfigured proxy, an MITM on an unencrypted internal network — can replay it in any other session and the server will accept and process it without error. The timing side-channel means that even a passive observer who can measure blob sizes and response latencies can extract bits of information about what the model reasoned over, without ever reading the ciphertext. Green’s specific attack required controlled conditions. The principle requires only observation.

Neither OpenAI nor Anthropic responded to Green’s bug bounty submissions with any urgency. This could mean their threat modeling concluded the attacks are impractical at realistic scale — which is defensible. It could also mean they categorized his submissions as academic rather than operational. The distinction matters to a security team. It doesn’t change the architecture.

The practical mitigation is direct: if you are running inference over sensitive data and using extended thinking for multi-turn workflows, treat the signature field the same way you treat an encrypted cookie that contains your session token. Understand what’s in it. Control where it goes. Don’t log it in plaintext. Don’t pass it over unencrypted channels. And understand that “encrypted” in this context means the contents are authenticated, not that the design has been hardened against replay or side-channel analysis.

The more uncomfortable implication is what the bug bounty response reveals about provider priorities. Green built working attacks, documented them clearly, and submitted them through official channels. The response was minimal concern. If that calibration is correct — if replay across accounts and timing-based bit extraction genuinely fall below the operational threshold — then providers have decided that the class of developer affected is small enough not to warrant engineering work on per-session key management. That is a business decision disguised as a security assessment. Builders should make their own.

AI-generated editorial illustration · TemperatureZero · June 2, 2026