<- ALL CYBER NEWS
High
AI Security, LLM, OpenAI, Anthropic, Google, Reasoning, API, Data Leak

AI Reasoning Trace Theft Hits OpenAI, Anthropic, Google
An AI reasoning trace theft flaw in OpenAI, Anthropic, and Google APIs leaked keys and passwords from encrypted reasoning blocks. What it is and how to defend.
AI Reasoning Trace Theft Hits OpenAI, Anthropic, and Google APIs
Researchers have disclosed a flaw in how OpenAI, Anthropic, and Google carry hidden AI reasoning between API calls that let them recover the models' internal reasoning, and real secrets, from encrypted reasoning objects. A reasoning block created in one session could be replayed into another and, in testing, even handed to a weaker model in the same provider family to make it reveal the concealed content. Across 6,708 public agent trajectories the team decoded 315,320 hidden thinking blocks, surfacing 704 privacy artifacts from genuine user sessions, including 62 API keys, 33 passwords, 24 access tokens, and 7 private keys. The work, titled Stealing Reasoning Traces from Proprietary LLM APIs, was disclosed to the affected providers.
The providers hide these reasoning traces on purpose, both to stop competitors from copying frontier reasoning and to keep unpolished intermediate "scratchpad" thoughts out of view. The problem is how that concealment was implemented: the encrypted reasoning objects were not tightly bound to the session and model that created them, so an attacker who obtained one could move it somewhere it was never meant to go. That design turned a secrecy feature into a data-leak channel, because the hidden thoughts frequently contain exactly the secrets a developer passed into context, and users had no reason to treat an opaque encrypted blob as sensitive.
The researchers demonstrated four distinct abuse paths, and they matter to different audiences. One steals proprietary reasoning for model distillation, an automated, low-cost way for a competitor to harvest frontier reasoning without paying top-tier prices or tripping safety filters. A second extracts private data from other users' published traces. A third recovers harmful content that a model concealed behind a safe-looking visible answer. A fourth hides prompt injections inside opaque reasoning blocks, where a human reviewer skimming the visible answer would not notice them.
Can someone read my private ChatGPT or Claude sessions with this?
Not arbitrarily. The cross-user attack did not grant open access to other people's private chats. It required two things: obtaining an encrypted reasoning block, typically one that was published somewhere such as an agent log or a shared trace, and API access to a compatible model from the same provider. So the realistic exposure is not your live private conversation but any reasoning block your agents write into logs, tickets, or repositories, which may carry replayable secrets and be readable by anyone who gets the blob and a same-family model.
What should teams building on these APIs do?
Stop treating opaque reasoning blocks as safe to store or share. Scrub secrets before they ever reach the model's context, so bearer tokens, API keys, and environment variables are not sitting inside a reasoning step to begin with. Treat any logged or published reasoning object as sensitive material: keep it out of public version control, and add reasoning-block patterns to the secret-scanning rules you already run. Where a provider offers session- and model-bound encryption or server-side reasoning state, prefer it, so a block lifted from a log cannot be decrypted by a weaker model in another session.
Detail | Value |
|---|---|
Affected | OpenAI, Anthropic, Google reasoning APIs |
Weakness | Encrypted reasoning blocks not bound to session/model |
Decoded | 315,320 thinking blocks across 6,708 trajectories |
Secrets found | 62 API keys, 33 passwords, 24 tokens, 7 private keys |
Cross-user need | An obtained reasoning block + same-provider API access |
Abuse paths | Distillation, private-data theft, harmful-content recovery, hidden injection |
CVE | None assigned; disclosed to providers |
Our read
This is a supervised-adversary-simulation lesson about a trust boundary that was easy to overlook. The reasoning block looked encrypted, so it looked safe, and that assumption is exactly where the secrets leaked. The verifiable-by-design takeaway is that anything your agents emit, including opaque intermediate artifacts, is part of your attack surface and has to be tested and constrained like any other output, not trusted because it is unreadable to you. Redact secrets before they enter context, treat every logged reasoning trace as sensitive, and verify what your agent pipeline actually writes down, because a secret you cannot see is still a secret you can leak.
Reporting by The Hacker News, citing the paper "Stealing Reasoning Traces from Proprietary LLM APIs." Sources linked above.
Related: GhostSplice: malicious MCP servers exfiltrate agent secrets · Gemini CLI CVE-2026-12537 and Claude Code CI flaws