Encrypted Reasoning Blocks Belong in the Secrets Boundary

A developer cleans the readable text out of an AI agent transcript, leaves a long encrypted field untouched, and publishes the log with a bug report. The field looks like random base64. There is nothing obvious left to redact.

In research released on 10 August 2026, a team decoded 315,320 of those opaque reasoning blocks from public agent traces. Among genuine user sessions, they reported 62 API keys, 33 passwords, 24 access tokens, seven private keys, and other personal data. Some of the recovered values never appeared in the visible chat that a developer could inspect before sharing. (Research paper, The Hacker News)

The demonstrated extraction path affected reasoning APIs from Anthropic, OpenAI, and Google during the researchers’ early July 2026 tests. The providers acknowledged the report, and the researchers said they could no longer run the same attacks after disclosure. This is a patched API flaw, not a claim that anyone can currently open arbitrary private chats. (Research paper, Simon Willison)

The durable failure happened one layer lower. Teams treated ciphertext returned by an API as harmless plumbing because humans could not read it. It was still a serialized copy of model state, carried through application logs, tracing systems, support bundles, repositories, and evaluation datasets. Unreadable is not the same as empty. If an opaque field can resume a model’s work, assume it can carry everything that work touched.

What the researchers actually recovered

Reasoning models often perform intermediate work before producing the answer an application displays. Providers have good reasons to hide that work. Raw traces can expose model behavior that a competitor might use for distillation, reveal safety mechanisms, or contain harmful material that the final answer correctly refuses to show.

A stateless API still needs a way to preserve continuity between calls. Instead of storing every intermediate trace on the provider’s servers, an API can return an encrypted reasoning object to the client. The client sends that object back on a later request, allowing the model to continue without the client reading the contents. OpenAI’s documentation describes an encrypted_content property that applications can pass to future calls, while Google’s documentation describes thought signatures as encrypted representations used to preserve reasoning context across multi-step interactions. (OpenAI documentation, Google AI documentation)

The August paper found that these objects were accepted too broadly during testing. A block created in one session could be replayed in another. A block from one customer could be submitted by another customer. Most importantly for the extraction technique, a block produced by a stronger model could be handed to a weaker sibling within the same provider’s model family.

That last move crossed a safety gap. The stronger model guarded its hidden reasoning against direct requests for disclosure. A cheaper model in the same family accepted the encrypted block and could be prompted to transcribe the underlying reasoning. The attacker did not break the encryption locally or steal a provider key. The provider’s own compatible model acted as the decoder.

The paper tested this pattern across model families from Anthropic, OpenAI, and Google. It also measured extraction fidelity by comparing recovered output length with the reasoning-token counts reported by the APIs. The authors acknowledge a limit: they did not possess ground-truth plaintext for every trace, so token counts and content checks support high fidelity without proving that every recovered token was exact. That caveat matters when reading examples as evidence rather than spectacle. (Research paper)

The public-data experiment gives the finding practical weight. The team examined 6,708 public agent trajectories and decoded 315,320 reasoning blocks. After separating benchmark personas from genuine user material, it counted 704 privacy artifacts in user sessions. In addition to credentials, those artifacts included names, postal addresses, personal email addresses, and non-localhost IP addresses. The Hacker News independently reported the same scope and stressed that an attacker first needed to obtain an encrypted block, often from a published trace or leaked log. (The Hacker News)

That prerequisite keeps the claim grounded. The technique did not grant a stranger a search box for every customer’s conversations. It turned an opaque object already in the stranger’s possession into readable material. Public repositories, shared evaluation corpora, copied support logs, and exposed telemetry supplied the objects.

The researchers disclosed their method to the affected model providers, Microsoft, and Hugging Face before publication. Their paper states that all model providers acknowledged receipt and that the same attacks stopped working afterward. Simon Willison noted the same result on 11 August after reviewing the paper. As of 12 August 2026, the evidence supports a fixed extraction path and an unresolved data-handling lesson. (Research paper, Simon Willison)

The ciphertext was part of the conversation

The common logging mistake starts with a reasonable mental model. A JSON response contains visible text, usage figures, IDs, and a long blob that nobody on the team can interpret. The visible text is content. The blob feels like protocol metadata.

Function tells a different story. The application keeps that field because it helps the next model call continue the previous work. It may encode the model’s intermediate handling of user input, retrieved documents, tool output, credentials seen in a terminal, or instructions found in a file. Encryption changes who can read the state. It does not change what the state represents.

Consider an agent asked to remove a secret from a transcript before publication. To perform the cleanup, the model may reread the conversation and reason about the exact value it needs to remove. The visible result omits the key. The hidden reasoning object may still preserve it. The paper found 64 artifacts in genuine user traces that were absent from the visible chat history, and it identifies cleanup tasks as a recurring trigger for restating sensitive values inside hidden reasoning. (Research paper)

A text-only redaction pass can therefore make the record look safer while leaving the sensitive state attached. This resembles deleting a password from an email body but preserving it in a hidden attachment. A reviewer sees a clean page. The transport still carries the secret.

The same mistake appears in observability pipelines. SDK middleware serializes a complete response for debugging. An application performance monitor captures request bodies. A failed job writes its continuation state to object storage. A support script bundles the last twenty interactions. An evaluation framework uploads trajectories so another team can compare models. Each component sees an opaque string and decides it is low risk because searching for sk- or BEGIN PRIVATE KEY finds nothing.

Encryption can make that decision worse by suppressing ordinary warning signals. A plaintext secret scanner can flag a token copied into a visible prompt. It cannot classify encrypted model state by inspecting its contents. The classification has to come from schema and provenance: this field is a reasoning envelope returned after the model processed confidential input, so policy handles the whole field as confidential.

This is familiar engineering outside AI. A session cookie is unreadable to a browser user, yet nobody sensible pastes it into a public issue. A database backup may be encrypted, but its access policy still follows the production data inside. A signed cloud credential can look like noise while granting authority. We classify those artifacts by capability and origin, not by whether a developer can open them in a text editor.

Reasoning blocks deserve the same treatment. They are bearer-like continuation artifacts whose exact security properties belong to the provider. During the July 2026 tests, portability across users and models made possession more consequential than application developers understood. Providers can narrow that portability, rotate keys, or alter the format. Your logging boundary should not depend on undocumented cryptographic details staying favorable.

The right default is blunt: if the provider marks a field as reasoning, thinking, signature, encrypted content, continuation state, or an equivalent opaque context object, keep it out of general logs and public datasets. Preserve it only where the workflow needs continuation, with access and retention no broader than the most sensitive input the model handled.

Stateless APIs moved storage into your system

Statelessness is attractive because it removes server-side conversation storage from the provider’s hot path. The application owns the transcript and sends the context needed for each request. That can support customer-controlled retention, zero-data-retention configurations, conversation forks, and model changes without asking the provider to maintain a large session database.

The bill still arrives. State has to live somewhere, and client-held encrypted reasoning moves part of that state into systems that were built to handle ordinary API responses. Your queue, cache, database, trace collector, dead-letter bucket, test fixture, and exception reporter become custodians of model internals.

OpenAI’s current guide explains that applications using stateless flows can request encrypted reasoning content and pass it back in later calls. Google’s guide says thought signatures preserve reasoning context and may need manual handling when a team edits history or uses the REST API directly. These are useful protocol features. They also tell an architect where the sensitive object crosses the application boundary. (OpenAI documentation, Google AI documentation)

A normal request path can create six copies before anyone notices. The SDK receives the response. A debug logger records it. The worker stores it with job state. The tracing exporter sends it to an observability vendor. A retry queue duplicates the payload. A developer copies the failed job into a fixture. Encryption at the provider did nothing to control those copies.

Retention policies often diverge too. The application database may delete a conversation after thirty days, while centralized logs stay searchable for a year. A dead-letter queue may have no deletion job. A public benchmark release can persist indefinitely across mirrors and forks. The least obvious copy becomes the real retention period.

The incident-response problem follows. A team can rotate an exposed API key, but it cannot rotate a customer’s medical history, private source code, or unreleased product plan. If those values entered a reasoning block, responders need to find every stored copy without being able to search the ciphertext for the affected value. They need an inventory of fields and data flows before the incident.

This is why “we encrypt logs” is an incomplete answer. Storage encryption protects disks and backups from some forms of theft. It does not prevent an authorized logging user from exporting a response, a support engineer from attaching it to a ticket, or a dataset job from publishing it. The August attack used legitimately obtained API access to decode blocks that had already escaped their intended boundary.

Teams building model gateways should make the schema carry the policy. Instead of a generic response_json column, separate visible output, billing metadata, tool events, and opaque continuation state. Encrypt the continuation state again under an application-managed key if it must be stored. Give it a short retention period. Keep it out of full-text search, analytics exports, and support tooling by default.

A gateway also gives you one place to adapt when providers change formats. The field may be called encrypted_content today and something else in another SDK. Central handling prevents every product team from independently deciding whether a new blob is safe to log. Free-form provider payloads are convenient during a prototype. In production, they turn schema changes into silent data-governance changes.

Why “the providers patched it” does not close your ticket

The immediate extraction depended on provider behavior. The August paper reports that the demonstrated attacks stopped working after disclosure, which deserves to be stated plainly. There is no reason to tell developers that the published recipe remains a live universal decoder when the researchers say otherwise.

A patch does not retrieve a transcript committed to GitHub last month. It does not tell you whether an opaque block was copied into a private vendor’s telemetry system. It does not shorten a retention period or revoke an unnecessary support permission. Provider remediation closes the decoder path they found. Your copies remain your problem.

The historical objects also raise a question only providers can answer: did remediation invalidate old envelopes or merely block the tested model behavior? The paper proposes rotating pre-fix signing keys and refusing old envelopes so previously published signatures become permanently undecodable. It does not claim in the public report that every provider implemented that exact design. As of 12 August 2026, teams should avoid guessing about old-block invalidation and ask their provider when the answer affects a real exposure. (Research paper)

This distinction changes response priorities. If a public trace contained visible credentials, rotate them now; no reasoning-specific analysis is needed. If the visible record was clean but opaque reasoning blocks were published, remove the material where possible, preserve the repository history needed for investigation, ask the provider about legacy validity, and rotate any credential the agent could have seen during that session. Treat an uncertain exposure according to the cost of the credential, not the reassuring appearance of ciphertext.

Credentials are the easy case because they have replacement mechanisms. Personal data and proprietary code require a broader review. Determine who could access the trace, whether mirrors or forks exist, which processors received it, and what contractual or legal duties apply. A deleted public file may survive in caches. A deleted observability event may survive in backups until the vendor’s retention cycle ends.

The flaw also exposed a second architectural risk: an opaque reasoning block could carry hidden instructions into another agent run. The paper demonstrates controlled prompt-injection scenarios where a model accepted a reasoning object containing an instruction to send data away, even though an external monitor could not inspect the hidden instruction. The provider-side fix may block the tested replay route, but importing untrusted continuation state remains a bad application design. (Research paper)

Do not resume arbitrary public agent traces as if they were inert examples. If you want to reproduce a run, rebuild the visible inputs in an isolated environment and let your own model generate fresh state. Imported opaque blocks deserve the same distrust as serialized objects from an unknown source. The fact that a provider can authenticate a blob does not prove that your application should accept its intent.

The authors propose binding encrypted envelopes to the originating user, session, and conversational position. That is sound provider-side direction because it narrows where a valid block can travel. Application controls still matter after such binding. An authorized user can leak their own transcript. A support process can over-collect it. A compromised project can publish a session that belongs to the same account.

Patch status changes exploitability. It does not change classification. Opaque reasoning remains sensitive application state because future API flaws, insider access, accidental provider behavior, or legitimate continuation within the original account may reveal or act on it.

Build a boundary for opaque model state

The fastest useful fix is to stop complete model responses from entering general-purpose logs. Keep a small allowlist of operational fields such as request ID, model name, latency, token counts, status, and a hash that supports correlation without preserving content. Everything else stays out unless a named debugging workflow requires it.

Redaction by denylist is the wrong shape. Teams do not know every provider field, and an SDK upgrade can introduce a new continuation object overnight. An allowlist makes unknown fields disappear from telemetry until someone reviews them. That is mildly inconvenient. Silent collection is worse.

At the model gateway, create a distinct type for opaque state. The type should resist accidental serialization into standard logs. Store the value in a dedicated encrypted column or secret store, reference it by an internal ID, and reveal it only to the component that assembles the next provider request. If the product can tolerate losing continuity, do not persist it at all.

Retention should follow use. A live conversation may need the current block for minutes or hours. A paused workflow may need it longer. An analytics warehouse almost never needs it. Set an explicit expiry at creation, delete superseded blocks when a new state replaces them, and verify that queue retries and backups do not preserve an unbounded trail.

Access should be narrower than access to visible chat text, not broader. Visible text can be reviewed and selectively redacted. Opaque state cannot be inspected by the application’s ordinary data-loss tools, so fewer humans and services should handle it. Support staff can usually diagnose latency and error codes without downloading the complete provider payload.

Make public-export tooling destructive by design. A transcript exporter should construct a clean document from approved visible fields rather than copying a raw API object and trying to remove dangerous keys afterward. Strip reasoning blocks, signatures, continuation IDs, tool credentials, hidden metadata, request headers, and provider-specific state. Then scan the visible result for secrets as a separate control.

Evaluation pipelines need the same boundary. Model teams often want complete trajectories because debugging agents requires more than final answers. Keep internal raw traces in a restricted dataset with a short retention period. Build shareable datasets from a schema that excludes opaque state. Use synthetic secrets and synthetic identities when an experiment needs realistic failure cases.

Observability vendors should receive the minimum useful record. Before enabling automatic AI tracing, inspect exactly which request and response fields the integration captures, where they are stored, who can search them, whether payload sampling is enabled, and how deletion reaches replicas and backups. A checkbox called “capture model I/O” can quietly turn a metrics account into a second conversation database.

Your incident runbook needs an opaque-state branch. When a secret may have entered model context, responders should identify sessions by time, request ID, agent job, repository, and user because they cannot search encrypted blocks for the value. They should enumerate all sinks that received raw responses, revoke credentials, restrict access to preserved evidence, and ask providers targeted questions about the affected format and dates.

Test the boundary with canaries. Put a fake API key into an isolated agent task, allow the model to process it, and trace every stored artifact through your own systems. The test passes when the fake value and every opaque reasoning field stay out of ordinary logs, exports, and fixtures. Run it again after SDK, gateway, tracing, or provider changes.

A practical review you can run this week

Start with one production workflow rather than a company-wide policy document. Pick the agent or reasoning feature that handles the most sensitive data, then follow one successful request and one failed request from the application to every storage and monitoring system.

1. Inventory provider state fields. Capture the response schema in a controlled environment and identify reasoning blocks, thought signatures, encrypted content, continuation tokens, and raw provider payloads. Record which SDK versions create them and which later calls consume them.

2. Trace every copy. Check application logs, gateway logs, traces, queues, caches, databases, support bundles, test fixtures, analytics jobs, object storage, and evaluation exports. Include failure paths because exception handlers often record more data than successful requests.

3. Replace raw logging with an allowlist. Keep request IDs, timing, model identifiers, token counts, and safe status fields. Exclude body content and opaque state. Verify the behavior against unknown fields so the next SDK addition is dropped rather than collected.

4. Separate continuation storage. Put required opaque state behind application-managed encryption, strict service identity, and explicit expiry. Store an internal reference in the job record instead of embedding the provider object throughout your data model.

5. Rebuild export paths. Generate public or support transcripts from approved visible fields. Strip all hidden and provider-specific state before a secret scan. Prevent a caller from selecting a “raw JSON” option unless a restricted incident workflow authorizes it.

6. Review old material. Search repositories and datasets by field names, response schemas, and unusually long encoded values rather than plaintext secrets alone. If exposed traces came from sessions that handled credentials, rotate those credentials and ask the provider whether legacy blocks from the relevant dates remain valid.

7. Test with synthetic secrets. Exercise success, retry, timeout, tool failure, and crash paths. Confirm that logs remain useful without capturing content. A security control that disappears during the first production incident was only a demo.

8. Assign an owner. One team should track provider schema changes, SDK releases, retention behavior, and logging policy. If every feature team owns a fragment, raw payload collection will return through the least reviewed integration.

The order matters. Stop new collection before spending days cataloguing old copies. Narrow future exposure, then investigate history according to data sensitivity and public reach. A public repository containing an agent trace goes ahead of an internal short-lived debug bucket.

Do not delete evidence blindly. If you find a real exposure, preserve the minimum records needed to establish dates, affected sessions, and recipients in a restricted location. Remove public access and unnecessary copies, but coordinate with incident response and legal requirements before destroying the only timeline you have.

The review should produce enforceable outcomes: a gateway allowlist, a dedicated state store, expiry settings, an export schema, and a canary test in CI. “Engineers should be careful with logs” will be forgotten during the next outage. Code keeps the boundary in place when attention moves elsewhere.

The useful lesson is smaller than the headline

The striking part of the research is that a weaker model could be turned into a decoder for a stronger model’s hidden work. The practical part is more ordinary. An API response crossed a trust boundary, applications copied it widely, and developers could not inspect one of its most sensitive fields.

As of 12 August 2026, the researchers say the demonstrated extraction attacks no longer work after provider disclosure. That should reduce alarm, not discipline. The public traces they studied existed because logging and dataset practices treated opaque model state as disposable metadata.

The next format will have another name. It may be a reasoning item, a thought signature, a resumable checkpoint, a memory capsule, or a tool-state envelope. Classify it by what it can resume and what the model saw while producing it. If it carries continuity, it carries risk.

The AI Native Engineer makes the same production distinction across the stack: the demo proves the happy path, while the system owns storage, failure, cost, and recovery. Client-held model state belongs on that list. Stop shipping raw provider payloads into every sink just because they make debugging easy.

A clean boundary is simple to describe. Keep opaque state out of ordinary logs. Store only what continuation requires. Expire it. Never publish it. Test those rules with synthetic secrets before a real customer supplies one.

If you want practical security and AI engineering analysis without a daily flood, the newsletter sends one email per month. The signup is on this site.

Sources

• Panfilov et al.: Stealing Reasoning Traces from Proprietary LLM APIs, accessed 2026-08-12
• Stolen Thoughts: Research project page, accessed 2026-08-12
• The Hacker News: OpenAI, Anthropic, Google API Flaw Let Weaker AI Models Decode Stronger Models’ Reasoning, accessed 2026-08-12
• Simon Willison: Stealing Reasoning Traces from Proprietary LLM APIs, accessed 2026-08-12
• OpenAI: Reasoning models, accessed 2026-08-12
• Google AI for Developers: Thought signatures, accessed 2026-08-12