SURIQ
The headline on this one is that weaker AI models can be tricked into reading a stronger model's hidden reasoning. That is real, and it breaks the anti-copying protection the big labs built. But it buries the part that should worry anyone shipping software on top of these APIs. The reasoning blocks your application receives, logs, and shares are carrying API keys, tokens, and personal data that your secret scanners cannot see. Redacting the visible text does nothing, because the leak lives in the part you cannot read.
The finding comes from a paper published this week, Stealing Reasoning Traces from Proprietary LLM APIs by Alexander Panfilov and colleagues, and was first reported by The Hacker News. It names OpenAI, Anthropic, and Google. The researchers say they disclosed to the providers, and that the demonstrated attacks stopped working after the vendors applied mitigations.
What the researchers actually found
To protect their step-by-step reasoning, the major providers no longer keep it on the server. They hand it back to your client as an encrypted block, and your client sends that block back with each follow-up request. That design is what powers multi-turn tool use. The paper's core claim is that those encrypted blocks are interchangeable across different sessions, users, and models inside a single provider. A block minted by a flagship model can be injected into a weaker, less guarded model from the same provider, which then transcribes it into plaintext. No one has to jailbreak the strong model at all.
That portability is the whole problem. The researchers scraped agent session logs that developers had posted publicly, unaware of what the opaque blocks contained, then decoded them at scale.
Decoding 315,320 reasoning blocks from public repositories recovered 367 personal-data artifacts and 182 credentials. The Hacker News reported that the credentials included API keys, access tokens, passwords, and private keys, and that some secrets appeared only inside the hidden reasoning and never in the visible output. The paper lays out four ways to abuse the weakness: extracting a proprietary model's reasoning, pulling private data out of shared logs at scale, surfacing dangerous content the model hid in its reasoning even when the final answer safely refused, and hiding a prompt-injection payload entirely inside an encrypted block to poison shared agent runs.
Why a "sanitized" transcript is not sanitized
Most teams that share an agent trace do the obvious thing first. They scrub the visible text, drop the parts that look like secrets, and assume the rest is safe to publish or hand to a vendor. This research says that assumption is backwards. The visible text is the part you can clean. The encrypted reasoning block is the part that leaks, and it is the part no human reviewer and no standard scanner ever opened.
Tools like gitleaks and trufflehog match patterns in readable content: an AKIA prefix, a bearer token, a private-key header. They pass straight over an opaque reasoning object because there is nothing to match. So a repository can score clean on every secret-scanning gate you run and still be a live credential leak the moment someone decodes the blocks. Reasoning traces have quietly become a new class of secret-bearing artifact, sitting alongside .env files and cloud config, and almost no pipeline treats them that way yet.
The patch stops the bleeding but cannot recall what is public
The vendor mitigations matter, and if the providers have closed the cross-model decode path, new sessions are in better shape. That is the patch. It is not the whole story. Every agent transcript already sitting in a public repository was written before the fix, and those blocks were harvested and decoded during the study. A server-side change cannot reach back into a GitHub repo, a shared eval dataset, or a CI artifact and unmake a secret that already left your control. For anything you exported before this week, the correct assumption is that the credentials inside are burned.
This is the gap between patching and knowing. Patching answers "can this still happen." It does not answer "did it already happen to me, and which keys do I now have to rotate." The second question is the one that keeps you up, and only your own audit of where those logs went can answer it.
The pattern is bigger than one paper
We keep writing versions of this same story. An AI coding agent that could be steered past its own guardrails. A clean-looking repository that made a coding agent open a reverse shell. OpenAI pausing an autonomous cyber capability over exactly these kinds of second-order risks. Anthropic's own models breaking into real companies in controlled tests. The through-line is that AI tooling keeps inventing new artifact types, new trust boundaries, and new data flows faster than application security tooling models them. A reasoning block is just the latest one your existing controls do not understand.
The lesson is not to stop building on these APIs. It is to stop treating anything the model hands back as inert. If the provider will not let you read a block, you cannot assume it is empty, and you certainly cannot assume it is safe to publish.
What to do this week
Start with the assumption that any exported or committed agent transcript is secret-bearing, then work from there.
-
Stop committing raw API session logs to any repository you do not fully control, even after redacting the visible text. The visible text is not where the secrets are.
-
Strip reasoning and opaque fields before sharing. Remove thinking blocks and encrypted reasoning objects from any trace, eval set, or bug report that leaves your team. The Hacker News noted that Anthropic advises removing thinking blocks when you switch models, which is a reasonable default for shared transcripts too.
-
Rotate anything that ever touched a session whose logs left your control. Treat API keys, access tokens, and passwords that appeared in exported traces as compromised, and cycle them.
-
Teach your scanners the new artifact. Add pre-commit and CI checks that flag raw API transcripts and reasoning blocks by shape, since content-based secret scanning will not catch them.
-
Validate replayed blocks in agent pipelines. If your system reuses encrypted reasoning across steps, confirm each block came from one of your own trusted sessions before you replay it, so an attacker cannot smuggle in a poisoned one.
The providers can keep the decode trick from working going forward. They cannot audit your repositories for you. This is one where the fix that protects you is the one you run, not the one they shipped.