Hidden reasoning is not a security boundary

You are halfway through a task with an agent. It needs to call an API you use, so you paste the key into the chat, because that is the fastest way to get unblocked. The tool collapses a grey block that says it is thinking, the work happens, the answer comes back, and the key scrolls out of view. Two weeks later you paste that session into a GitHub issue to show a maintainer what went wrong, or into a Hugging Face dataset of agent runs, or into a Slack channel with forty people in it. The visible part looks clean. The hidden part you never read.

That is the whole problem, and it has almost nothing to do with model safety. Every large provider hides some portion of what the model works through before it answers, and the documentation for that choice is short, specific and about the provider. Reading it carefully tells you exactly how much protection you are getting, which is less than the interface implies. This guide is for people who use hosted AI tools and occasionally hand them a real credential. If you run your own inference stack, or you have someone whose job is threat modelling, you already have a process and this is beneath you.

What the providers hide, and what they hide it for

Start with what the vendor documentation actually says, because the wording is unusually direct. OpenAI’s reasoning guide states that “we don’t expose the raw reasoning tokens emitted by the model,” and offers a summary parameter instead, with the most detailed summariser available when you set it to auto [2]. Anthropic is blunter still. Its thinking documentation says that summarised thinking “provides the full intelligence benefits of thinking while preventing misuse,” and then closes the door: “No display setting returns the raw chain of thought” [3]. Google’s Gemini API returns thought summaries only when you ask for them, since “by default, only the final output is returned” [4].

Three vendors, one behaviour, and only one of them gives a reason. Anthropic names misuse of the model’s reasoning [3]. OpenAI and Google simply decline to return the raw text and do not say why on the page where they decline it [2][4]. The one stated purpose on the table is about the model. It is not about protecting the contents of your session. Those are different goals that happen to produce the same visible behaviour, which is a grey box you cannot open. The gap between the two shows up in cost as well as in security. Anthropic notes that “the tokens Claude spends reasoning are billed as output tokens, even when the thinking text isn’t returned to you,” and OpenAI says the same thing about reasoning tokens occupying context and being billed as output [3][2]. You pay in full for text you are not allowed to read. That is a reasonable trade for the vendor. It is worth noticing that you are on the other side of it.

The models change under these rules constantly. Anthropic currently lists adaptive thinking on Claude Opus 5 and Claude Sonnet 5, with older manual extended thinking still available on Claude Opus 4.5 [3]. OpenAI’s reasoning guide names GPT-6 Astra and the GPT-5.6 models [2]. Google lists thinking on Gemini 3.8 Flash and its siblings [4]. The model names will have turned over again by the time you need this. What all three hand back in place of the raw reasoning has not changed: a summary you can request, or nothing [2][3][4].

An encrypted thinking block proves origin, not secrecy

The word that misleads people is encryption. All three providers wrap reasoning state in something encrypted, and it is tempting to read that as a promise of confidentiality. Read what the encryption is for instead. Anthropic returns full thinking content encrypted in a signature field, and the documentation explains the purpose: “The API uses the signature to verify that thinking blocks were generated by Claude when you pass them back” [3]. Modified blocks come back as a 400 error [3]. Google describes a thought signature as “an encrypted representation of the model’s internal reasoning state,” always present even when the model reasons minimally, and required to keep multi-turn context coherent [4]. OpenAI puts an encrypted_content property on reasoning items so you can pass them into future calls, which is how reasoning carries across turns in stateless mode and under Zero Data Retention [2].

Every one of those is an integrity and continuity mechanism. The provider needs to know a block came from its model and was not edited on the way back. None of that is the same claim as: nobody other than you can ever turn this back into readable text. A tamper-evident seal on an envelope tells you whether the envelope was opened. It does not stop someone else from opening it.

One 2026 paper priced the gap, and the patch does not unpublish anything

In August 2026, eight researchers published a paper demonstrating that the seal and the lock were being confused for each other in production [1]. Because encrypted reasoning blocks were compatible across models from the same provider, the researchers could take a block produced by a guarded model and feed it to a weaker sibling, which would decrypt it and print the contents. They call it a scalable decryption jailbreak, and it worked against Anthropic, OpenAI and Google [1].

The numbers are the part worth keeping. The team collected 6,708 publicly available agent trajectories from GitHub and Hugging Face, the ordinary output of people sharing what their agents did, and reconstructed 315,320 reasoning traces from them [1]. Out of those they recovered 367 personally identifiable information artifacts and 182 credentials [1]. Restricted to the genuine, non-benchmark sessions, the paper reports “62 distinct API keys, 33 passwords, 24 access tokens, 7 private keys, 30 personal emails” [1]. Nobody was breached in the usual sense. People shared logs, and the logs contained more than the logs appeared to contain.

The researchers disclosed to the affected providers, Microsoft and Hugging Face before publishing, and report that as of August 2026 their attacks are no longer reproducible after provider mitigations [1]. Treat that as good news and as the exact limit of good news. A fix to a decryption path does not delete a single one of those 6,708 public transcripts, and it does not invalidate a key that was sitting inside one. The vulnerability had a patch. The exposure does not.

Your secret leaves in the transcript, not in the model

Once you separate the two claims, the practical risk relocates. The dangerous artifact is not the model and not the encryption scheme. It is the transcript, which is a file, and which behaves like every other file you have ever shared by accident. It gets pasted into issues, attached to bug reports, uploaded into eval datasets, screenshotted into Slack, and quoted in blog posts by people demonstrating what a tool can do.

Provider retention is the second copy. OpenAI states that data sent to the API “is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us),” and separately that abuse monitoring logs “are generated for all API feature usage and retained for up to 30 days, unless longer retention is required by law” [5]. Zero Data Retention exists, but it is “subject to prior approval by OpenAI,” and it does not cover every endpoint: /v1/chat/completions and /v1/responses are eligible, while /v1/conversations and /v1/assistants are not [5]. None of that is unreasonable. It does mean that a credential you paste has a defined minimum lifetime somewhere other than your machine, and you should know the number for the tools you actually use rather than assume it is zero.

The useful mental model is a chain of custody with three links. You type the secret. The provider processes and logs it under a published policy. Then you, or a colleague, move the record somewhere public. The first two links are governed by contracts and documentation you can read. The third link is the one that leaks, it is entirely under your control, and it is the one nobody audits.

Credentials that expire beat credentials you have to trust people with

The fix that survives every future change of vendor policy is to make the leaked artifact worthless. AWS says it plainly in its IAM best practices: “Where possible, we recommend relying on temporary credentials instead of creating long-term credentials such as access keys,” and it repeats the instruction for humans, “Require your human users to use temporary credentials when accessing AWS,” alongside least-privilege permissions and regular removal of unused credentials [8].

Translate that to a two-person shop with a Zapier account and an agent that reads a spreadsheet. Generate a token that only does the one thing the task needs, give it the shortest expiry the service offers, and let it die on schedule. When a token expires in seven days, a transcript published in October carries a key that stopped working in June, and the entire incident becomes a paragraph you never have to write. Where a service only offers long-lived keys, put the secret in an environment variable or a connector the tool reads on your behalf, so it never appears in the message body that becomes the transcript. It is slower to set up once and cheaper every day after.

Scanners catch the leak you already made

Assume some secrets are already out. Scanning is the cheap sweep. GitHub runs secret scanning automatically and for free on public repositories, raises an alert on the repository’s Security and quality tab when it finds an exposed credential, and tells you to “rotate the affected credential immediately to prevent unauthorized access” [6]. Push protection is the version that stops the mistake before it lands: it blocks detected secrets in pushes from the command line, in commits made in the GitHub UI, in file uploads, in REST API requests, and in interactions with the GitHub MCP server on public repositories [7].

Note where the coverage ends. Push protection covers pushes to a repository. It does not cover the transcript you paste into a forum thread, a Notion page shared with a link, a support ticket, or a screenshot. For those, the only control is reading the whole session before it leaves your systems, thinking blocks included, and rotating anything that appears in one. Rotate on the fact of publication, not on evidence of misuse. Evidence arrives late.

What still goes wrong

The biggest hole is the one you cannot see from your side. You can read every retention policy and still not know how a third-party tool in the middle stores its copy of the session, because the wrapper around the model has its own logs, its own vendors and its own idea of what counts as sensitive. When a workflow runs through Make, n8n or a browser extension before it reaches Claude, ChatGPT or Gemini, the provider’s published policy describes only the last leg of the trip.

Expiring tokens also fail in a specific and annoying way: services that do not offer them. Plenty of small SaaS products issue one permanent key per account and nothing else, and no amount of good practice on your side turns that into a scoped credential. In that situation the only real controls are a separate account with a limited plan, and rotation on a calendar rather than on suspicion. That is worse than the AWS-style advice and it is often the best available [8].

Finally, the 2026 paper is one snapshot of one attack that the providers say they have mitigated [1]. The next gap will not look like it, and it will probably be found the same way, by an outside team building the exploit rather than describing it. So do not calibrate on this specific incident. Calibrate on the pattern behind it: features described in vendor documentation are promises about the vendor’s goals, and any protection they extend to you is a courtesy that can be redesigned in the next release. Design for the day the courtesy is withdrawn, and the news cycle stops mattering to you.