THE WARNING IN MAY, AND THE TWO ANSWERS THAT DISMISSED IT
When a frontier model reasons through a hard problem, the provider now hides that step-by-step chain-of-thought rather than showing it raw — partly to stop the reasoning itself from being copied into a cheaper rival model, partly to keep anything ugly in the scratch work away from the visible answer. What the client actually gets back is an encrypted block of text, which it is expected to pass along unread with each following request in the conversation. In May, Matthew Green — a working cryptographer, not a red-teamer poking at jailbreak prompts — found that these blocks could be replayed outside the context that produced them and reported it to the labs. OpenAI's response was that the behavior was unreproducible. Anthropic's was that it saw no security implications in the replay or side-channel behavior he had described. Both answers treated the finding as a curiosity about how the plumbing worked, not as a way to get at what was inside the pipe.
HOW A CHEAPER SIBLING MODEL BECAME A DECODER RING
The August 10 paper, titled "Stealing Reasoning Traces from Proprietary LLM APIs" and posted to arXiv by Alexander Panfilov, David Schmotz, Ilia Shumailov, Luca Beurer-Kellner, Joachim Schaeffer, Ameya Prabhu, Jonas Geiping, and Maksym Andriushchenko, explains what Green's report actually implied: the encrypted blocks are "fully compatible and interchangeable across different sessions, users, and models within a provider's ecosystem," because each provider protects them with one encryption key shared across its whole model line rather than a key scoped to the session or the model that produced them. The researchers' exploit follows from that directly. Take an encrypted reasoning block produced by a flagship model — Claude Opus 4.8, in one of the paper's examples — and feed it into a smaller, less-guarded sibling from the same family, such as Claude Haiku 4.5. Because the cheaper model holds the same key, it can decrypt the block; a simple ad-hoc jailbreak is enough to talk it into transcribing that reasoning back out in plaintext, token by token. The flagship model is never touched. The attacker never has to break its encryption, guess its key, or jailbreak the model that actually did the thinking — only the weaker one asked to read it aloud.
WHAT WAS ALREADY SITTING IN PUBLIC LOGS
The researchers didn't stop at demonstrating the mechanism; they pointed it at what was already public. Encrypted reasoning blocks from agent sessions get published constantly, embedded in bug reports, demo transcripts, and benchmark logs people push to GitHub and Hugging Face without a second thought — because an encrypted block looks like inert ciphertext, not like a transcript worth scrubbing. Scraping 6,708 of those public agent trajectories, the team decoded 315,320 individual reasoning blocks and combed the plaintext for anything sensitive. They found 367 personally identifiable artifacts and 182 working credentials — 62 of them live API keys, the rest passwords, access tokens, and private keys — sitting in logs their owners had every reason to believe were unreadable to anyone without proprietary access to the model that wrote them.
FOUR WAYS TO ABUSE ONE ARCHITECTURAL CHOICE
Credential harvesting from old logs is the most immediately damaging use of the flaw, but the paper lays out four distinct abuse paths that follow from the same shared-key design. One is exactly what the labs built the encryption to prevent in the first place: stealing a proprietary model's reasoning wholesale to train a cheaper competitor through distillation. A second is pulling private data out of other users' published traces, which is what the credential harvest amounts to at scale. A third is recovering content a model's safety training kept out of its visible answer but left sitting, unfiltered, in the reasoning that produced that answer. A fourth is hiding a prompt injection inside an opaque reasoning block, where neither a human reviewer nor an automated filter watching the visible conversation would ever see it. One architectural shortcut — a single key instead of one scoped to each session — is what makes all four possible at once.
THE PATCH COVERS THE PIPE, NOT WHAT ALREADY LEAKED
All three providers deployed mitigations after the coordinated disclosure that accompanied the paper, and the researchers say the main extraction attack they demonstrated no longer reproduces against current APIs. The specifics differ by vendor: Anthropic now says thinking blocks are tied to the model that produced them and should be stripped out when a session switches models, since other models are supposed to ignore them; Google says its backend now manages compatibility itself when a session's model changes; OpenAI's developer documentation still instructs clients to replay encrypted reasoning items when manually managing stateless history, with the cross-model exploit path closed elsewhere in the stack. None of the three has publicly committed to the fix researchers consider the actual answer — per-session or per-user key scoping rather than one key for an entire model family — or to an independent audit confirming the patch holds. And a server-side fix, however solid, cannot reach backward: the 315,320 blocks already decoded, and whatever multiple of that remains undecoded in public repositories the researchers didn't scrape, stay exactly as readable as they were before anyone thought to check, because the credentials sitting in them were never rotated on the strength of a paper most of their owners will never read.
WHAT THIS MEANS FOR TEAMS BUILDING ON AI
The specific bug is patched, but the pattern that produced it isn't specific to one provider, and it's worth carrying into how you evaluate any vendor's "encrypted" claim going forward. Anthropic and OpenAI's first response to a real report — from a cryptographer, not a script kiddie — was to call it a non-issue, and it took a scaled proof-of-concept with real live keys in it to get an architectural fix out of any of them; a "we investigated and found no security implications" from an AI vendor is a claim about their threat model, not a guarantee about yours. More concretely: if your team has ever published an agent transcript, a benchmark run, or a debugging session that included a model's reasoning tokens from before this month, treat any credential that could plausibly have appeared in that reasoning as compromised and rotate it — the fact that the block reads as gibberish to you doesn't mean it read as gibberish to a cheaper model from the same provider family asked nicely to translate it.