Encrypted Reasoning Blocks Need an Opaque-State Contract

A new paper, Stealing Reasoning Traces from Proprietary LLM APIs, reported that encrypted reasoning blocks from Anthropic, OpenAI, and Google could be moved across sessions, users, and models during the researchers' early-July 2026 testing. A weaker model could then be induced to reconstruct hidden reasoning. In a scan of public agent transcripts, the researchers decoded 315,320 blocks and classified 367 personally identifiable information artifacts and 182 credentials.

That sounds like an active universal decryption break. The paper says something more bounded and more useful. The attack used normal model APIs rather than stolen cryptographic keys; the evaluation covered particular models and API versions; the recovered reasoning could not always be compared with ground truth; and every affected provider acknowledged the report. Crucially, the researchers say they could no longer run the same attacks after disclosure. There is no basis for telling users that every current reasoning block can still be decoded.

There is still an immediate product lesson for anyone building an AI app. An opaque field can contain or influence sensitive state even when your team cannot read it. If that field moves through browser storage, conversation databases, observability tools, support exports, evaluation datasets, or public repositories, it belongs in your security model. This guide is for founders and small product teams using reasoning models, tool loops, client-managed history, or agent transcript exports. It gives you an opaque-state contract, a mode-selection matrix, a concrete scenario, six safe failure tests, and a 48-hour audit. It does not provide an extraction recipe.

What the paper established, and what it did not

The original paper describes four consequences of portable encrypted reasoning: extraction of proprietary traces, recovery of sensitive data from published logs, hidden instructions carried inside opaque blocks, and exposure of harmful material that did not appear in the visible answer. The authors used an unprivileged API attacker model: no provider infrastructure access, no model weights, and no stolen encryption key.

The public-log numbers require careful reading. The researchers scanned 6,708 public trajectories and decoded 315,320 reasoning blocks. After classification and filtering, they reported 367 PII artifacts and 182 credentials. Those are counts in a targeted, non-exhaustive sample, not a leak rate for all AI apps. Some values came from benchmarks or synthetic contexts; the paper separately examined genuine sessions and says all recovered secrets were deleted after aggregate classification. Do not turn those counts into a prediction about your own exposure.

The timing matters just as much. Testing covered models and APIs available in early July. The authors disclosed the issue to the affected providers, Microsoft, and Hugging Face before publication. They report that all model providers acknowledged receipt and that the same attacks stopped working afterward. Public documentation does not yet provide a complete, provider-by-provider cryptographic remediation record. We can say the demonstrated attacks were mitigated by publication time; we cannot say which combination of model refusal training, account binding, session binding, key rotation, or gateway checks now protects every endpoint.

The right response is therefore neither panic nor dismissal. Do not attempt to reproduce the exploit against production services. Audit the data paths your own product controls, ask providers for current scope evidence, and treat old public transcripts as potentially exposed until credentials are rotated and sensitive material is assessed.

Define opaque reasoning state before you inventory it

An opaque reasoning item is provider-generated state returned to an application but not intended to be interpreted by that application. It may appear as an encrypted reasoning field, a signature, a redacted-thinking block, or a signed thought step. The application preserves or returns it so the model can continue reasoning across a tool call or later turn.

This is different from three nearby concepts:

• A reasoning summary is readable text generated for a user or developer. It is not necessarily a faithful transcript of the model's hidden process.
• A conversation message is visible application content such as a user request, assistant answer, or tool result.
• A provider-side response ID is a reference that lets the provider retrieve stored state. It can reduce how much state the application must carry, but it creates a separate retention and access decision.

These are functional protocol requirements. They are not instructions to log the blocks forever, show them to end users, copy them between tenants, or publish them in a benchmark corpus.

Encryption protects readability, not your whole data path

Teams often make one of two category errors. The first is “we cannot read this value, so it cannot contain sensitive data.” The second is “the provider encrypted it, so every use of it must be safe.”

Encryption can protect a block from direct inspection or modification while leaving other questions unanswered:

1. Who may replay it? A valid ciphertext can still be dangerous if it is accepted under the wrong account, tenant, session, or model.
2. Where may it travel? An opaque value can be copied to logs, analytics, exports, tickets, and repositories even if no employee can decode it.
3. How long does it remain valid? A block with no practical expiry or revocation path has a different blast radius from one limited to a single tool turn.
4. What created it? The model may have reasoned over user data, tool results, environment values, or credentials that never appeared in the final answer.
5. What can consume it? The receiving model has to process the hidden state. Transport encryption cannot by itself guarantee that the model will never reveal or follow it.

Those are provider controls. Your app still owns minimization, tenant isolation, retention, logging, deletion, export behavior, and incident response. Provider encryption cannot repair a transcript that your product published with live credentials elsewhere in the visible context.

Map every place the block can travel

Start with one representative reasoning-model request and follow the complete state path. Do not stop at the model gateway. A typical AI app can create copies at nine points:

OpenTelemetry's GenAI observability guidance is a useful default: prompt content and tool arguments are not captured unless an operator opts in because they may be sensitive. Apply the same default to opaque provider state. Keep operational metrics such as model, latency, status, token counts, and your own non-sensitive correlation IDs. Exclude raw opaque blocks unless a narrowly scoped investigation explicitly requires them.

Your inventory needs both logical and physical deletion. If a user deletes a conversation, ask whether copies remain in traces, queues, object storage, support tickets, analytics warehouses, backups, and exported evaluation sets. “Deleted from the chat table” is not an end-to-end deletion result.

Walk through one cross-tenant support scenario

Imagine a small startup called ResolveKit. It offers an AI support agent to online stores. The model can search an order system, reason about refund policy, and draft an action for human approval. ResolveKit uses stateless API calls because a customer requested low provider-side retention. Its server stores the complete response JSON so the agent can continue after each tool result.

A user from Store A asks about an order. The order tool returns a shipping address and an internal refund token. The final answer shows only the delivery date. The opaque reasoning item may still reflect the address or token because the model used them while deciding what to do.

Three product shortcuts now create risk. First, the application logs the whole model response to debug a timeout. Second, an evaluation job copies failed conversations from every store into one shared dataset without a tenant label on each opaque item. Third, a support engineer downloads the JSON and attaches it to a public issue after manually removing visible names and email addresses.

None of those actions requires anyone to break encryption. The sensitive state has escaped its intended context. A provider patch may stop cross-account decoding, but the transcript can still contain visible tool outputs or working credentials, and the application has no proof that every old block was invalidated. ResolveKit must rotate the refund token, remove the public artifact, scan its history and forks, notify the affected customer according to its incident plan, and change the exporter so it drops opaque state by type rather than asking a person to recognize it.

The safer design uses a tenant-bound conversation record, separates visible messages from opaque continuation state, excludes the latter from support and analytics exports, and lets it expire when the tool turn ends. If ResolveKit chooses provider-managed state instead, it documents the provider retention and deletion behavior rather than pretending the data disappeared.

Choose stateful or stateless mode deliberately

“Stateless” does not mean “no one stores state.” It usually means your application, rather than the provider's conversation service, carries enough history to continue. That can be the correct privacy or architecture choice, but it moves controls into your product.

Do not select client-managed state simply because “zero retention” sounds safer. OpenAI explicitly documents that stateless or Zero Data Retention mode returns encrypted reasoning content for the client to carry. The privacy question becomes: where does your app put it, who can access it, and when is it deleted?

Likewise, do not select provider-managed state merely to avoid building controls. You still need to understand retention, access, region, incident notification, and deletion semantics. The decision matrix is about placing responsibility where your team can actually verify it.

Create an opaque-state contract

Record one contract per provider, model family, and product workflow. This is a product artifact, not a vendor or regulatory template:

workflow_id: resolvekit-refund-assist
reviewed_at: 2026-08-12
provider: example-reasoning-api
model_family: production-model-alias
mode: client_managed_stateless

opaque_state:
  response_types: [reasoning, redacted_thinking, thought_signature]
  purpose: continue_current_tool_turn
  allowed_storage: encrypted_conversation_store
  forbidden_sinks: [client_logs, analytics, support_exports, public_datasets, git]
  tenant_binding: required
  session_binding: required
  model_switch_rule: provider_documented_only
  ttl: 24h
  delete_with_conversation: true

exports:
  visible_messages: reviewed_and_redacted
  tool_results: excluded_by_default
  opaque_state: always_drop

evidence:
  sdk_version: pending
  provider_security_notice: pending
  cross_tenant_fixture_test: pending
  deletion_test: pending
  log_sink_test: pending

incident_owner: founder
decision: hold

The contract prevents a common failure: treating arbitrary JSON as one indivisible transcript. Your application should identify state using the provider's typed SDK objects or documented schema, not by guessing that every long Base64 string is reasoning. It should fail closed when a new response type appears. Unknown fields belong in quarantine until the team decides whether they are safe to retain, replay, or export.

Keep the contract versioned. Provider schemas and model-switch rules change. For example, Anthropic's current documentation says thinking blocks are tied to the model that produced them and tells developers to strip thinking and redacted-thinking blocks when switching models. Google's current stateless guidance says to resend prior thought blocks even when switching models and let the backend manage compatibility. A single generic “reasoning signature” handler is not a safe cross-provider abstraction.

Run six safe failure tests before release

These tests verify your application. They do not attempt to decode hidden reasoning or attack a provider.

Cross-tenant assembly test

Create two synthetic tenants with harmless conversations. Instrument your history builder and deliberately present it with a record whose tenant ID does not match the active session. The request must be rejected before reaching the model. Test messages, tool results, opaque blocks, cached responses, and background-job payloads separately.

Export stripping test

Create fixtures containing every documented opaque response type plus one unknown type. Run support export, user download, evaluation export, error reporting, and “copy debug JSON.” Opaque and unknown state should be absent. Verify the serialized bytes; a clean UI preview is not evidence.

Observability test

Trigger a successful request, provider error, timeout, retry, and tool failure. Search every configured log and trace sink for fixture values and opaque fields. Check dead-letter queues and error trackers too. The pass condition is useful operational metadata without prompts, tool results, secrets, or opaque state.

Fallback and model-switch test

Force the primary model to fail and observe the fallback path. Follow the provider's current rule for reasoning items. Do not copy blocks into another model because it “seems to work.” The pass condition includes a visible event saying whether continuity was preserved, intentionally dropped, or restarted.

Deletion and expiry test

Delete a test conversation and wait through the documented asynchronous window. Query primary storage, caches, queues, exports, analytics, and backups according to your deletion design. Then verify that an expired opaque item cannot be resumed by your application. Record what the provider deletes separately from what your product deletes.

SDK and schema-change test

Feed the integration a recorded response containing a newly introduced field or block type. It should quarantine the unknown value, alert an owner, and avoid exporting or replaying it. Add this fixture to the release gate for every SDK or model upgrade.

Handle old transcripts as an incident, not a cleanup task

If your team has published, committed, or broadly shared raw reasoning-model responses, removing the latest file is insufficient. Copies may exist in Git history, forks, package artifacts, build logs, issue attachments, mirrors, and downstream datasets.

Start with containment:

1. stop new transcript exports and disable the affected share path;
2. preserve a restricted incident record without copying raw secrets into another tool;
3. identify repositories, buckets, tickets, datasets, vendors, and people that received the material;
4. revoke and rotate any credential that may have appeared in the visible or hidden processing path;
5. remove public artifacts and request deletion from downstream hosts;
6. assess personal-data and contractual notification duties with qualified counsel;
7. add typed stripping and regression tests before reopening the path.

The NIST Generative AI Profile recommends defined ownership, rehearsed incident response for third-party generative AI technology, continuous monitoring, and vendor incident terms. A two-person company still needs named decisions: who contacts the provider, who rotates secrets, who assesses user impact, and who decides when exports may reopen.

Complete a 48-hour audit without reproducing the attack

In the first six hours, freeze raw transcript publication and list every reasoning provider, model alias, SDK, state mode, tool loop, transcript table, and export path in production. Ask engineering for one synthetic response fixture from each path. Do not use customer data and do not ask a model to reveal hidden reasoning.

By hour 24, run the export, observability, cross-tenant, and fallback tests against those fixtures. Search repositories and shared datasets for documented field names such as encrypted_content, signature, redacted_thinking, and thought_signature. A field-name search finds candidates, not confirmed secrets. Restrict access to results and avoid copying the matched values into a new incident document.

By hour 36, classify each path:

By hour 48, rotate affected credentials, remove public artifacts, open provider cases, assign remediation owners, and version the opaque-state contract. Schedule a retest after the next SDK or model upgrade. OWASP's sensitive-information guidance is a useful reminder that prompt instructions alone are not a reliable data-loss control; the export and storage boundaries must enforce the policy.

Ask providers for evidence your app can use

The paper says the same attacks stopped working after disclosure, but “fixed” is not a complete integration specification. Ask each provider questions tied to your workflow:

• Are current opaque reasoning items bound to account, project, tenant, session, conversation position, model, region, or API endpoint?
• Were pre-fix keys rotated or legacy items invalidated? If not, what is their validity window?
• What happens when a client replays an item in the wrong session or under the wrong identity?
• Which model switches and platform transfers are supported intentionally?
• Are replay attempts logged, rate-limited, and exposed to customers?
• How do store: false, ZDR, prompt caching, compaction, and background jobs change retention?
• Does deleting a response or conversation delete provider-managed reasoning state, and on what schedule?
• Which SDK types must an exporter strip, including redacted, omitted, compaction, or built-in-tool signatures?
• What security notice or version identifies the remediation relevant to the models you use?

Know where this gate applies, and where it does not

Use the full opaque-state gate when your app does any of the following:

• manages model history manually;
• returns tool results across API calls;
• uses store: false, ZDR, or a stateless mode;
• exports conversations for support, evaluation, research, or customer download;
• shares histories across workers, devices, environments, or model fallbacks;
• processes personal data, credentials, private code, health information, financial data, or regulated records.

This gate also does not prove that a model's final answer is correct, that its reasoning summary is faithful, or that a provider is legally compliant. It addresses a narrower product problem: whether invisible continuation state is isolated, minimized, retained, exported, and deleted like sensitive data.

Make the release decision from evidence

Ship only when the team can show all of the following:

• every opaque state type is inventoried for the exact provider and SDK version;
• tenant and session mismatches are rejected in application code;
• logs, traces, exports, tickets, and evaluation sets exclude opaque state by default;
• fallback and model-switch behavior follows current provider documentation;
• retention, expiry, user deletion, and provider deletion are separately documented;
• old shared transcripts have been scoped and exposed credentials rotated;
• the six failure tests pass with stored evidence;
• a named owner will review schema, model, and SDK changes.

The lasting lesson from the replay disclosure is not that encryption failed everywhere. It is that unreadable state is still state. A founder does not need to reverse-engineer the ciphertext, but the product must know where it goes, why it is kept, who may replay it, when it expires, and how it is removed. That contract remains valuable after the headline exploit is fixed.

References

1. Panfilov et al., Stealing Reasoning Traces from Proprietary LLM APIs
2. Research project and disclosure site, Stealing Reasoning Traces
3. Matthew Green, Let's talk about encrypted reasoning
4. OpenAI, Reasoning models and stateless encrypted reasoning
5. Anthropic, Thinking blocks, preservation, and encryption
6. Google, Gemini thinking and thought signatures
7. OpenTelemetry, GenAI observability and sensitive-content defaults
8. GitHub, Secret scanning and credential remediation
9. NIST AI 600-1, Generative AI Profile
10. OWASP LLM02:2025, Sensitive Information Disclosure