Many AI providers no longer show users a model’s full chain of thought. That protects trade secrets and is meant to keep sensitive material in internal reasoning from spilling out. A new research paper now suggests that this precaution can fail elsewhere: in the encrypted reasoning traces that some APIs return to their customers. This is not a minor issue for development teams that store, share, or publish session logs.
Key takeaways
- A study describes an attack on encrypted reasoning blocks in APIs from OpenAI, Anthropic, and Google.
- According to the researchers, the issue is not broken encryption but blocks that may be too interchangeable across sessions, users, and models.
- The team found personal data and credentials in publicly accessible logs.
- For companies, reasoning data belongs in the same protection class as logs containing tokens, customer data, or internal instructions.
The sealed envelope travels through the session
Reasoning models often create a longer internal work trace for difficult tasks. Providers usually expose only a summary of it. For multi-turn API conversations, encrypted reasoning elements can also be returned to the client so it can send them back with the next request. OpenAI explicitly documents this approach for certain Responses API configurations. The client is meant to preserve and resend earlier output items so the conversation context remains available. That is practical. It also moves security-relevant data from a controlled server environment into applications, log files, browser storage, and integrations.
The newly published paper by Alexander Panfilov and other researchers examines exactly this design. According to the team, encrypted blocks within a provider ecosystem were compatible enough to be used across sessions, accounts, and models. A less protected model from the same provider could then be induced to output such a block in readable form. The researchers call this a decryption jailbreak. The distinction matters: the study does not claim to have mathematically broken standard encryption. It describes a flaw in which party accepts encrypted content and under which conditions a model turns it back into plaintext.
Why this is about more than protecting model secrets
The most obvious harm would be extracting the reasoning traces of a more capable model. Those traces are valuable to providers because they can expose training and safety methods and make targeted distillation easier. But the research project identifies a second danger that is more immediate for customers. Developers often publish debugging material, sample projects, or complete sessions on GitHub, in tickets, or in forums. What looks like an unreadable data block is easily treated as harmless. In 315,320 blocks collected from public repositories, the authors say they found 367 artifacts containing personally identifiable information and 182 credentials.
Those numbers are a warning sign, not a general measurement of all AI logs. The study is new and its results need independent review. Even so, it illustrates a familiar information-security pattern: encryption protects data in transit or at rest only if decryption is strictly bound to the right identity, session, and authorization. A ciphertext that any suitable application can turn back into plaintext is not a harmless placeholder. In practice, the key question is not merely whether a field looks encrypted, but which component accepts it and what privileges that component brings to the task.
Invisible instructions can become an entry point too
Beyond data leakage and possible model distillation, the authors describe another effect: hidden prompt injections. A manipulated reasoning block could contain instructions that become active again in a later processing step without being visible in an ordinary interface. This is especially sensitive for agents that combine conversation histories, tools, and external data sources. In that setting, a session log is not just archive material. It becomes part of the next work order. That is why an agent should not blindly treat context data taken from public or external sources as trusted state of its own.
The issue connects to the debate about AI watermarks that we covered recently. As with a watermark, a label alone does not establish safety or truth. An encrypted block can look confidential and still be classified incorrectly. The key question is not whether a model exposes its reasoning trace, but whether the entire chain of API, client, storage, and follow-on model cleanly separates what belongs to each session and each user.
What developers should check now
Users without their own API integration have no reason to panic. For teams building AI products, however, the work is concrete. Reasoning elements, full responses, and debug exports should not automatically reach public tickets, chat histories, or code repositories. Test data should stay separate from real customer data, and credentials should never appear in prompts or tool output. Anyone continuing an API session manually should use only the provider-supported flow and should not import encrypted context blocks from other sessions. Logging also needs short retention periods, access controls, and checks for tokens, email addresses, and internal instructions.
On the provider side, hiding the full reasoning trace from the user interface is not enough. Secure systems need to bind encrypted elements cryptographically or server-side to the account, model, session, and expected conversation history. They should reject foreign or stale blocks before a model processes them and detect unusual reuse. The researchers propose corresponding cryptographic and system-level measures in their paper. The public information does not show how far the affected providers may already have changed their implementations.
Outlook: Context becomes an attack surface
The more AI applications solve multi-step tasks, the more valuable their context becomes. It contains more than the latest user question: files, tool results, safety rules, and sometimes traces of model work. The right response to the new study is therefore neither to condemn reasoning outright nor to archive encrypted data carelessly. It is a reminder that context in agent systems is a security-critical data type. Treating it like a password log or production log removes a preventable share of risk. Treating it as harmless technical clutter leaves the next surprise to the next debug export.