Published
- 5 min read
By Allan D - Editor, AI Security Wire
Shared Encryption Key Exposed Hidden Reasoning Across Major AI APIs
When reasoning models started encrypting their chain-of-thought, the pitch was clear: the model thinks privately, you get the answer. The encryption looked like a security boundary. It wasn’t.
Researchers from MATS Research, the ELLIS Institute Tübingen, Max Planck, and Snyk published findings this week showing that the encrypted reasoning objects returned by major AI provider APIs — OpenAI, Anthropic, and Google — shared a global encryption key rather than using per-session or per-user keys. The consequence: any encrypted reasoning block could be replayed in another session, decoded by a weaker model, or used to extract content that providers intended to keep hidden.
The finding has two distinct impact areas. The first is model security: the shared key enables a cheap form of model distillation, where a weaker model is fed a stronger model’s encrypted reasoning trace and can extract the intellectual content behind the answer without paying for the stronger model directly. That’s a commercial and intellectual property concern for providers. The second impact area is developer privacy, and it’s the one that bites immediately.
What Developers Published Without Knowing
The research team scanned 6,708 publicly available agent trajectories — run logs, evaluation datasets, session transcripts shared on GitHub, Hugging Face, and similar platforms. Many of these came from developers building or benchmarking AI agents, publishing their results as reproducibility artifacts.
What they found inside: 704 privacy artifacts from real user sessions. The breakdown includes 62 API keys, 33 passwords, 24 access tokens, 7 private keys, and assorted PII. These were recoverable from logs where the reasoning blocks had appeared encrypted to the developer who published them.
This is the real damage. A developer runs an agent, reviews the output, decides the plaintext looks clean, and publishes the log. The encrypted reasoning block goes along for the ride, assumed to be opaque. It isn’t. Anyone with the shared key — or anyone who can replay the block into a model that knows the key — can read it. If the original session touched a credential, a user email, a confidential document, that content may be sitting in a public repository right now.
The Four Attack Paths
The paper documents four ways the flaw could be exploited:
Model distillation theft. Feed a frontier model’s encrypted reasoning trace into a weaker sibling model from the same provider family. The weaker model, which shares the encryption scheme, can process and extract the hidden reasoning, effectively bootstrapping a cheaper model with expensive thinking. Providers charge significant premiums for frontier model reasoning; this attack lets someone proxy that capability without paying for it.
Cross-user private data extraction. Replay an encrypted reasoning block from one user session in another. If the original session contained user-specific data, credentials, or PII, the replayed block may expose it in a context the original user never intended.
Recovery of concealed harmful content. Reasoning models sometimes generate intermediate thoughts that include content they would normally refuse to output in the final response — the refusal happens at the presentation layer, not the reasoning layer. The encrypted reasoning block may contain that refused content verbatim, recoverable via the shared key.
Hidden prompt injection concealment. An attacker could embed prompt injection instructions in a reasoning trace that appear inert in the visible response but carry instructions that execute in subsequent reasoning steps. The encrypted block provides a persistence mechanism that survives the visible conversation boundary.
What Vendors Have Said (Which Is Nothing)
As of the research publication this week, no public statement has been issued by OpenAI, Anthropic, or Google. Researchers note that the specific cross-session replay attacks they demonstrated stopped working following mitigations applied by providers, but with no public disclosure there is no way for affected developers to know which mitigations were applied, when, or what residual exposure exists.
The silence creates a practical problem. Developers cannot assess their own exposure without knowing what the vendors know. If an organisation ran reasoning API calls during a period when the shared-key vulnerability was exploitable, and published any logs from those sessions, they have no vendor-sourced guidance on whether to treat those logs as compromised.
The Structural Problem
The shared encryption key design reflects an assumption that encrypted-but-returned reasoning objects would remain within the control of the session that generated them. That assumption doesn’t hold once developers start publishing logs, sharing traces, or storing reasoning outputs in systems accessible to multiple parties.
It’s a version of the same mistake made in early TLS session key implementations: the encryption is sound, but the key management architecture creates a surface that undermines it. Per-session or per-user derived keys would have prevented replay across sessions. That design is more complex but straightforwardly eliminates the cross-session exploitation path.
For developers actively using reasoning APIs: stop treating encrypted reasoning blocks as opaque and therefore safe to share. Audit your published agent trajectories and evaluation datasets. Rotate any credentials that were in scope during sessions where you published raw API responses. Until providers issue public statements confirming the full scope of the vulnerability and the completeness of their mitigations, treat published reasoning logs as potentially compromised regardless of their encryption state.
References
Frequently Asked Questions
- What was the shared encryption key flaw in AI reasoning APIs?
- Reasoning APIs from OpenAI, Anthropic, and Google encrypt their models' chain-of-thought before returning it to callers, ostensibly to hide internal model reasoning. Researchers found that the encryption used a single global key shared across all users and sessions rather than per-session keys. This meant encrypted reasoning blocks from one session could be replayed and decoded in a different session entirely, including by feeding a frontier model's encrypted reasoning into a weaker model to extract the content.
- How were real credentials and PII exposed by this vulnerability?
- When developers publish agent run logs, session transcripts, or evaluation data, they sometimes include raw API responses. Because the reasoning blocks appeared encrypted, developers often assumed they were safe to share. The shared-key flaw meant those 'encrypted' blocks were recoverable. Researchers scanned 6,708 publicly available agent trajectories and found 704 real privacy artifacts: 62 API keys, 33 passwords, 24 access tokens, 7 private keys, and additional PII from real user sessions that had been published by developers under the assumption the reasoning content was protected.
- Have the vendors patched this, and what should developers do now?
- Researchers state the cross-session replay attacks stopped working after vendor mitigations applied as of August 2026 — though no public vendor acknowledgment has been issued. The irreversible problem is credentials and PII already embedded in published logs. Developers should audit any shared agent trajectories, evaluation datasets, or session logs for raw API responses that include reasoning blocks, and treat those logs as potentially compromised regardless of whether the reasoning appeared encrypted at the time of publication. Do not commit raw API transcripts to public repositories.