DEV Community

Cover image for Reasoning Logs Hid 704 Secrets. the Old Envelopes May Still Open
Simon Paxton
Simon Paxton

Posted on • Originally published at novaknown.com

Reasoning Logs Hid 704 Secrets. the Old Envelopes May Still Open

Publicly shared LLM API logs can still expose customer data hidden inside encrypted reasoning blocks—at least unless providers have also invalidated the old cryptographic envelopes. An August 10, 2026 preprint reports recovering 704 distinct non-benchmark artifacts from public agent trajectories, including API keys, passwords, access tokens, and private keys.

The live cross-session replay attack described in the paper was no longer reproducible after private disclosure and provider mitigations, the researchers say. But the same paper’s mitigation appendix says old, already-published envelopes require pre-fix keys to be retired and legacy envelopes to be rejected. The reviewed record does not publicly confirm that OpenAI, Anthropic, or Google took that retroactive step.

Reasoning APIs often return an opaque block alongside a model response, then expect the application to include it in the next request. That lets a provider preserve multi-turn context without storing every conversation server-side. It also means a raw agent transcript can contain data its publisher cannot read, search, or reliably remove.

“[T]hese encrypted blocks are fully compatible and interchangeable across different sessions, users, and models within a provider’s ecosystem.” — the researchers’ preprint

The attack used that portability as a decryption route: replay an encrypted reasoning block into a weaker model from the same provider family, then instruct that model to transcribe its hidden content. The researchers reported this worked across Anthropic, OpenAI, and Google before mitigations. It is a different failure mode from the Claude prompt-injection data-exfiltration path: here, the sensitive material can already be sitting in a public log, wrapped in what looks like harmless API bookkeeping.

The 704 artifacts recovered from genuine public sessions

Alexander Panfilov of MATS Research and the ELLIS Institute Tübingen, David Schmotz of the ELLIS Institute Tübingen, and their co-authors decoded 315,320 encrypted reasoning blocks from 6,708 public trajectories. Their target was public repositories containing agent rollouts and session logs, not a provider’s internal systems.

From genuine, non-benchmark sessions, the paper’s Appendix D lists 62 API keys, 33 passwords, 24 access tokens, and seven private keys. The total was 704 distinct artifacts, including credentials and personally identifiable information.

Recovered non-benchmark artifact Distinct count
API keys 62
Passwords 33
Access tokens 24
Private keys 7

Sixty-four of the 704 artifacts were absent from visible chat history, according to the paper. That is the part most likely to surprise teams that sanitize a transcript before publishing it: redacting user and assistant text does not remove material sealed inside the reasoning envelope.

The researchers do not establish where those 64 values originated. They could have come from prompts, tool output, model memory, or another source. But their absence from visible text is enough to make ordinary transcript scrubbing an incomplete defense.

The count also needs reading carefully. The paper’s main text refers to “833 passwords” from genuine sessions, while Appendix D’s category table lists 33 distinct non-benchmark passwords. The authors used a two-stage LLM-assisted labeling and deduplication pipeline, rather than a human forensic review of every recovered item. The appendix’s distinct-artifact count is the cleaner number for assessing exposed unique secrets.

Matthew Green, a cryptography professor at Johns Hopkins University, had already described the basic replay behavior in a May 29 post: encrypted reasoning blobs could travel across sessions and accounts, and for OpenAI, across models. Green initially downplayed it as not “a particularly exciting vulnerability”; in an August 11 update, he wrote that the later research group had turned the observation into a working attack.

The providers’ fixes may have shut the door on a new replay attack. They do not automatically shred copies that have already escaped.

The proposed remedy is unusually concrete: rotate the signing keys used before the fix and reject envelopes made under those legacy keys. Without both steps, a public archive may still hold a valid, replayable object even when today’s API rejects newly created malicious requests.

Google has said its systems recognized reasoning-trace coercion and reduced the associated risk. That is Google’s account of its own remediation, not independent evidence that old public reasoning envelopes were invalidated. The cited material contains no comparable public confirmation of retroactive invalidation from any of the three providers.

For developers, the immediate lesson is blunt: a published raw API trajectory should be treated as a potential secret-bearing artifact, not as a sanitized conversation record. That risk sits beside other documented operational failures, including Anthropic data-leak operational failures and research into Claude web-fetch profile-data theft.

A patch that stops tomorrow’s replay is useful. A rotated legacy key is what decides whether yesterday’s public logs remain openable.

Key Takeaways

  • Researchers reported recovering 704 distinct non-benchmark artifacts from public LLM API trajectories.
  • The recovered artifacts included 62 API keys, 33 passwords, 24 access tokens, and seven private keys.
  • The paper says its replay-and-decoding attacks stopped reproducing after providers received private disclosure.
  • Sixty-four recovered artifacts were absent from the visible chat history of the relevant sessions.
  • The paper recommends retiring pre-fix keys and refusing legacy envelopes to protect already-published logs.

Further Reading


Originally published on novaknown.com

Top comments (0)