Pular para o conteúdo
← Back to Skalablog

Published article

How to Stripe Encrypted Reasoning Blocks Before Publishing

Software EngineeringOpenAIAnthropicStripe

62 API keys, 33 passwords, 24 access tokens, and seven private keys came out of encrypted reasoning blocks that developers had already scrubbed by hand. The scrub worked on everything they could see. The secret sat inside the one block their editor could not show them.

What the encrypted reasoning blocks flaw revealed

Encrypted reasoning blocks, the hidden chain-of-thought payloads that reasoning APIs hand back to your client, could be decoded by pasting them into a cheaper model from the same provider. A paper published on 10 August 2026 by eight researchers showed that Anthropic, OpenAI, and Google all shipped the same design, and the same flaw.

The attack is short enough to fit in a paragraph. Take a signed thinking block produced in your session, attach it to a fresh conversation against a different model and a different account, and the API accepts it. Then ask the smallest model in the family to transcribe the reasoning it can see. Anthropic Claude OpenAI's reasoning models, along with Google's Gemini, all exposed their private scratchpads this way, according to the paper the video from the Claude Code channel recounts.

The researchers also scanned the public internet. They collected 6,788 agent trajectories from GitHub and Hugging Face, found about 315,320 encrypted reasoning blocks inside them, and decoded all of them. The recovered material included live credentials that the people who published the logs had tried and failed to remove.

Why the labs hid reasoning, and the coat-check design that followed

Reasoning models hide their scratch work for two stated reasons. When OpenAI shipped o1 in September 2024, the launch post cited safety monitoring of raw reasoning and competitive advantage: rivals should not train on reasoning the company paid to produce. The technique of fine-tuning a cheap model on a strong model's outputs is called distillation, and a trace teaches the method, not just the answer.

Hiding the reasoning created a state problem. Turn two of a conversation needs to know what turn one was thinking. Instead of keeping that state on the server, all three providers handed the locked thinking back to the client, which mails it back with every follow-up request. The video compares it to a coat check that locks your coat in a box and asks you to present the box each time.

The cryptography itself held. Each provider names the envelope differently, and a GFM comparison makes the symmetry visible:

ProviderEnvelope fieldWhat the tag proves
Anthropic (Claude)signature on the thinking blockthe block was not edited
OpenAIencrypted_contentthe block was not edited
Gemini)thought signaturethe block was not edited

The authentication tag proves integrity and nothing else. There is no session identifier inside, no user binding, and on some providers no binding to the model that produced the block. A padlock that opens for anyone is a hinge.

How a cheap sibling model read the expensive one

The extraction never attacked the strong model. The researchers gave the encrypted block to the weakest model in the same family and used an assistant prefill: they began the small model's reply with an opening tag, and the model helpfully finished the sentence by transcribing the reasoning attached to the turn.

The lopsided effort is the telling detail. Reading a trace with the cheap model took one fixed prompt. Forcing a stronger model to do the same job took per-block templates, best-of-n sampling, and workarounds for anti-distillation training, which is when you should suspect the model is being trained to refuse.

The strongest evidence that the transcription was faithful came from billing. On 120 competitive programming problems, the recovered text length tracked the thinking-token count the API charged, one to one, across every model tested. An invented transcript would scatter; these points sat on the diagonal. The video notes the lead author is a third-year PhD student rather than an industrial red team, working with nothing more than an API key.

What actually leaked from public agent logs

The numbers from the scraped trajectories are the part that reaches a developer's laptop. The paper reports, per the video: 6,788 public sessions on GitHub and Hugging Face, 315,320 encrypted reasoning blocks, 367 personally identifying items, and 182 credentials.

The credential breakdown was 62 API keys, 33 passwords, 24 access tokens, seven private keys, 30 personal email addresses, and six machine addresses that were not localhost. About one session in 20 leaked something real: 328 of the 6,788.

The number that matters most is 64. That many recovered artifacts appeared nowhere in the visible conversation at all. Someone had scrubbed those logs, and the scrub worked on everything their editor could show them. Roughly one recovered secret in eleven was invisible to the person who published it. Simon Willis, cited in the video, pointed out the traces are fragments and notes to self, unreadable to humans and therefore never cleaned.

Two worse vectors: refusal bypass and planted instructions

Reading passwords was not the worst outcome. The paper demonstrated a refusal bypass: when asked to name cars that are easy to steal and how, the visible answer declined, but the encrypted reasoning behind the refusal had already worked through the details. A refusal, the video argues, is a decision about the visible channel only.

The injection vector ran the other direction. The researchers planted instructions inside an encrypted reasoning block and attached it to a request. The receiving model treated the planted text as its own prior thinking and wrote code that uploaded files to an attacker's server. No injection appeared in the prompt, and nothing showed in the visible conversation.

Combine the two halves and published trajectories become dangerous in a new way. A poisoned block inside a benchmark trace is a payload inside a file other people intend to replay, and models appear to treat reasoning as inherently trustworthy because it is supposed to be their own.

The labs were warned in May, a summer before the paper

None of this surprised everyone. On 29 May, cryptographer Matthew Green, an associate professor at Johns Hopkins and co-creator of the Zerocash protocol, published his own findings after a weekend probing these blobs. He found replay across conversations and accounts, side channels through block size and token count, and even recovered bits of a secret byte through timing.

He reported everything through the bug bounty programs. Per the video, OpenAI replied that the report was unreproducible despite receiving the scripts, and Anthropic it saw no security implications in the side channels or replays and offered a documentation update. An engineer named Will Smiddlin independently demonstrated cross-account and cross-model replay in June.

Seventy-three days after Green's post, the paper landed with a table of recovered passwords. After disclosure, the providers deployed mitigations: as of August 2026, the paper's own authors state the headline billing-match experiment no longer reproduces. Google's backend now handles thought-signature compatibility, and Anthropic documentation tells developers to Stripe thinking blocks when switching models, while the video notes OpenAI's docs still instruct replaying the encrypted item.

The fix: put reasoning state back on the server

The paper's recommendation is deliberately boring. Store reasoning on the server and hand the client an opaque random identifier and nothing else. With nothing handed over, there is nothing to decode. Failing that, bind the envelope to its context by hashing the session, the user, and the conversation so far into the authentication tag, so a replayed block simply fails verification.

Gateway-level defenses help in the meantime: reject an envelope minted by a different model than the one being queried, watch for accounts replaying traces they did not generate, and be able to revoke a signature known to have leaked. Training models to refuse transcription is the weakest option, because the content stays reachable through the model that holds the key.

The trade is real. Server-side sessions cost the providers the statelessness the design existed to buy, adding storage, expiry, and a retention policy over the most sensitive text in the system. For developers the rule is simpler: Stripe thinking blocks before publishing a trace, rotate anything that appeared in a session you already pushed, and treat an encrypted block as plaintext you happen to be unable to read.

Frequently asked questions

  • Were encrypted reasoning blocks ever actually encrypted in a meaningful sense? The cryptography proved integrity only. Because the envelope carried no session or user binding, anyone holding a block could replay it anywhere in the provider's ecosystem, which one commenter summarized as obfuscation with a shared key rather than encryption.
  • Is the billing-token trick proof that extraction was faithful? It was the paper's strongest evidence, not mathematical proof. On 120 problems, recovered text length matched the charged thinking-token count across every model tested, and a lab has no incentive to misreport an invoice number.
  • Do these attacks still work today? Per the paper's authors, the attacks stopped working after mitigations deployed following the August 2026 disclosure, and the headline billing experiment no longer reproduces. The video urges watching the documentation rather than statements for confirmation.
  • What should I do with agent logs I have already published? Stripe every thinking block from the published traces, then rotate every credential that appeared in any session you pushed. Roughly one recovered secret in eleven was invisible to the person who published it, so scrubbing what you can see is not enough.
  • Did the flaw make reasoning tokens cheaper or free? No. Nothing in the research saves money, and decoding costs extra calls to a second model. The video stresses this was a security and distillation finding, not a discount.

From hidden reasoning to written record

The lesson of this research is that everything a model writes down, even under a padlock, is a document that can surface later, and the most valuable thinking is usually the part nobody bothered to publish. If you have that kind of knowledge sitting in your own YouTube videos, in a walkthrough, a postmortem, or an opinion you recorded once and never wrote up, Skala Blog turns the video into a structured written article: paste the URL, get the transcription, and edit the result into something publishable.

This piece itself follows that path, built from a video transcript the way the Dev doido workflow behind Crazystack TypeScript intends, and you can see the publishing flow at crazystack.com.br. If a lecture or stream of yours explains something the internet cannot currently read, the transcript already exists. The article is the part worth recovering.

Related reading: the Skala Blog editor handles the structure so you can keep the argument.

Source video