What the researchers found
Researchers at Max Planck and ELLIS Tübingen published a paper last week that showed how to read the reasoning of frontier models from Anthropic, OpenAI, and Google. The exploit was simple. Each of these model providers returns a “chain of thought” to the calling application as an encrypted block. Applications pass the block back and forth on later calls. The LLM-connected application that asked for an idea or an answer isn’t actually able to read this block. It’s encrypted by the model vendor. But the researchers found that the blocks are not bound to a session, a user, or even the model that produced them. Encrypted reasoning generated by Claude Opus 4.8, handed to Claude Haiku 4.5, came back decoded in plaintext, and the same exchange worked between GPT-5.6 Sol and GPT-5.6 Luna.
The security research team scanned public code repos for blocks that developers had committed alongside their application code. They collected roughly 6,700 public agent sessions and reconstructed more than 315,000 reasoning traces from them. Hidden within, thanks to the eager help of the less expensive models, they were able to expose 62 API keys, 33 passwords, and other personal data.
The protection on reasoning traces was refusal training: the expensive models were trained heavily against disclosing it, while cheaper models in the same family were trained less strongly. Because the blocks themselves remained valid inputs to other models the provider offered, it was possible to take protected data from one model and have it revealed by another. Confidentiality that was supposed to come from encryption was, in practice, also dependent on the training behavior of whichever model received the block.
I think this problem generalizes well beyond “chain of thought” traces. The average enterprise runs several models in almost every agent pipeline, routing between these models for different levels of work: a frontier model for hard problems and cheaper models for easier problems. If the rules for that data are whatever each model was trained or prompted to do, then the protection changes every time the data moves to a different model. Given this, enterprise security teams should ask a more practical question: how do they handle AI application data they cannot inspect but know may contain sensitive information?
What enterprise security teams can do
There are two things an enterprise security team can do to reduce this class of data-loss risk. The first is data hygiene. Treat any encrypted block an application carries as containing the full conversation, since that may include prompts, retrieved documents, tool outputs, and whatever secrets passed through them. Sanitizing the visible text alone does not help. The paper's guidance is to strip reasoning blocks from any transcript before sharing it and to keep raw API exchanges out of shared repositories entirely.
The second important investment is an infrastructure-level check: reject an encrypted block when it arrives at a different model than the one that produced it, and flag an account replaying the same payload across unrelated sessions.
None of this requires decrypting the reasoning. The application already knows which model produced the block, which model is receiving it, which user or agent is making the request, and whether the same artifact has appeared somewhere else. That is enough information to enforce a security policy before the model sees it. The protections that failed in this incident were all trained into models. What a security team has is the traffic itself and that can be enough to detect or interrupt this class of attack.
