Cross-Vendor API Flaw Let Weaker AI Models Decode OpenAI, Anthropic, and Google Reasoning
A newly disclosed flaw let researchers replay encrypted reasoning objects across OpenAI, Anthropic, and Google reasoning APIs, using a weaker model to decode a stronger one's hidden reasoning and pull API keys and passwords out of public session logs.
A newly disclosed flaw in the way OpenAI, Anthropic, and Google carried hidden model reasoning between API calls let researchers pull that reasoning — and the secrets tangled up in it — back out of ordinary session logs. In testing, a cheaper, weaker model from the same provider family could be handed a stronger model's encrypted reasoning and made to read it back in plain text, and the recovered material included live API keys and passwords.
The mechanism is almost mundane, which is what makes it worth reading closely. The providers' reasoning APIs return “encrypted reasoning objects” — blocks meant to preserve a model's chain of thought across calls without ever exposing the plaintext to the client. The team behind the paper Stealing Reasoning Traces from Proprietary LLM APIs found those blocks were portable: a block minted in one session could be replayed into another session, another user's context, or a smaller model, then coaxed into revealing what it held. Across 6,708 public agent trajectories they decoded 315,320 reasoning blocks and recovered hundreds of secrets that were never meant to be legible.
Reported first by The Hacker News, the finding matters less as an exotic cryptographic break — the encryption was never cracked — and more as a reminder that “opaque” is not the same as “safe.”
How the Replay Worked
All three providers built roughly the same feature for the same reason. When an application manages conversation state manually or statelessly, the reasoning that a model produced on an earlier turn has to be carried forward somehow. OpenAI returns encrypted reasoning items that the client replays with manually managed history; Anthropic carries the full reasoning inside an encrypted signature; and Google uses encrypted thought signatures. Each design preserves the reasoning state without handing the underlying plaintext to the client.
The weakness was not in the cryptography. As the researchers stress, no encryption key was obtained and the ciphertext itself stayed sealed. The problem was that an intact opaque block would be accepted and processed by the provider even when it arrived in a session, a user context, or a model it did not originate from. Once a block is portable, it can be pointed at a model chosen for its willingness to talk.
That is where the weaker model comes in. Flagship tiers carry aggressive anti-distillation and safety alignment; lighter models in the same family carry less of it. The researchers describe the smaller model as a “fuzzy” decoder — prompted to transcribe the reasoning a stronger sibling produced. In their testing the pairings were Claude Haiku 4.5 for Claude traces, GPT-5.6 Luna for GPT traces, and Gemini Robotics ER-1.6 for Gemini traces. We are describing the shape of the attack here, not a recipe; the operative detail for defenders is that a reasoning block you treated as unreadable was readable to another account.
What the Logs Gave Up
The scale is what turns a clever trick into a disclosure worth acting on. After excluding benchmark sources, the team counted 704 distinct privacy artifacts drawn from genuine user sessions, among them 62 API keys, 33 passwords, 24 access tokens, and seven private keys. Sixty-four of those artifacts appeared only in the hidden reasoning and nowhere in the visible transcript. In other words, a developer could scrub the readable conversation clean and still ship a live credential sealed inside an opaque block that another account could replay.
The cross-user path is narrower than a blanket “read anyone's chats” headline would suggest, and the researchers are careful about that. The attack did not grant arbitrary access to private conversations. It required getting hold of an encrypted reasoning block — the obvious source being an agent log someone published — plus API access to a compatible model from the same provider. The people most exposed are a specific, identifiable group: developers who posted raw agent logs with the reasoning objects left intact. That is the same failure mode behind a run of recent AI-agent incidents, from one-click data exposure in Atlassian's Rovo assistant to zero-click hijacking of AI browsers through poisoned content: the model is doing what it was told, and the trust boundary is somewhere the operator forgot to look.
The same portability opened a fourth abuse path the researchers demonstrated as a proof of concept: an invisible prompt injection. They crafted an opaque reasoning block carrying a malicious instruction, then replayed it into an unrelated task, causing the receiving model to add an attacker-directed upload action — with nothing incriminating in the visible text. Alongside secret extraction and reasoning theft for model distillation, that gives four named ways the same flaw could be turned to account.
What the Vendors Have — and Haven't — Said
This is where confidence has to be stated plainly rather than assumed. The researchers say they disclosed the findings to the affected model providers, along with Microsoft and Hugging Face, and that the demonstrated attacks stopped working after mitigations. Their reproducibility statement holds that the main extraction attack is no longer reproducible as of August 2026.
That claim rests on the researchers' own testing, not on vendor confirmation. As of the public record, none of the three providers has issued a public acknowledgment of the flaw or tied its current documentation to this research, and no CVE identifiers have surfaced for it. Nor does the record settle whether the hundreds of thousands of reasoning blocks already sitting in public repositories remain decodable — a separate question from whether a fresh attack still succeeds. Treat “fixed” as unverified until a vendor says so on the record.
The documentation has visibly shifted, which is the closest thing to a tell. OpenAI still instructs developers to replay encrypted reasoning items when manually managing stateless history, and Google says its backend now manages thought compatibility when a session switches models. Anthropic now states that thinking blocks are tied to the model that produced them and should be stripped when switching models, because other models ignore them.
The work did not appear from nowhere. It builds on May research by Johns Hopkins cryptographer Matthew Green, who showed encrypted reasoning blocks could be replayed across sessions and accounts but stopped short of a reliable extraction technique. According to The Hacker News, Green “reported the replay behavior to OpenAI and Anthropic through their bug-bounty programs”; in his account, OpenAI called the report unreproducible and Anthropic said it did not see security implications in the replay behavior. The new paper is what turned that replay quirk into a documented, at-scale extraction method.
What Enterprise AI-API Teams Should Verify
Because the vendor-side picture is unconfirmed, the useful posture is verification rather than reassurance. If your organization consumes reasoning APIs from OpenAI, Anthropic, or Google, a handful of checks are worth running this week.
- Rotate exposed secrets. Rotate any API keys, passwords, or tokens that could have transited a reasoning API or landed in an agent log, and prioritize anything you know was published in a public trace.
- Audit what you have shared. Strip reasoning blocks and opaque reasoning fields from any traces you publish, and stop committing raw API transcripts even after the visible text has been sanitized — the credential may live only in the hidden block.
- Review log retention and access. Check how long session logs persist, who can read them, and whether agent trajectories are being written to repositories that outsiders can reach.
- Restrict reasoning-API scope. Limit which applications and keys can request or replay encrypted reasoning, and scope those keys to the least privilege the workflow needs.
- Confirm patch status at the source. Ask your provider directly whether the replay and extraction behavior is mitigated for your account and models, rather than relying on a third-party reproducibility note.
The provider-specific mechanics of encrypted reasoning are new, but the muscle memory is familiar to anyone who has tracked this year's run of AI-model security stories, including OpenAI's own tuning of refusal behavior in GPT-5.6-Cyber. Credentials leak through the seams between systems, and reasoning objects are a new seam.
My Read
My read: the sharp end of this is not the “weaker model decodes stronger model” party trick, striking as it is. It is that secrets ended up in a place operators were told to treat as opaque, and 64 of them existed only there. Sanitizing the visible transcript was never enough, and a lot of AI-agent hygiene advice quietly assumed it was. The extraction attack may well be mitigated, but that word is doing unverified work until a vendor confirms it — and the blocks already in public repositories are their own unanswered question. Until then, assume any reasoning object you published is readable, rotate accordingly, and stop shipping raw traces. The cheap fix costs you a key rotation; the expensive one is finding out which of your logs a stranger already parsed.
