On August 10, a research team spanning the Max Planck Institute, the ELLIS Institute, and the Tübingen AI Center posted a paper with a companion website called stolen-thoughts.com. The name is a fair description of the contents.
To understand what they stole, you need one piece of plumbing. Modern AI models think before they answer, and that internal reasoning often holds more sensitive material than the reply you see: the data considered, the documents consulted, the options weighed and rejected. Major providers treat those traces as trade secrets, so they hide them. But they don't store them either. They encrypt the reasoning, hand the sealed block back to your software, and your software carries it into the next request.
You are the courier for a detailed record of your own session, and you are the one party who cannot open it.
Researchers showed that the sealed reasoning blocks from Anthropic, OpenAI, and Google could be read by handing them to a cheaper model from the same provider and asking it to transcribe. Decoding 315,320 blocks from publicly shared sessions, they recovered 62 API keys, 33 passwords, and hundreds of other secrets that users could not see before sharing. Providers patched the attack after disclosure. What no patch changes: a record about your data now exists that you cannot read, redact, retain, or produce. Private AI is the arrangement where that record is yours.
How do you read an encrypted block without breaking encryption?
You don't break it. You ask a chattier member of the family to read it aloud. The sealed blocks turn out to be interchangeable across sessions, users, and models within a provider's ecosystem, and the flagship models are trained hard to refuse to reveal reasoning while their cheaper, faster siblings are not.
So the researchers took a flagship model's sealed block, attached it to a request to the budget model, and asked for a verbatim transcript. The budget model obliged.
This worked against Anthropic, OpenAI, and Google. Nobody cracked any cryptography. The weak point was that a valid sealed block from one model is a valid input to another, and the two models were guarding the door with different levels of care.
What actually leaked?
Real secrets, from real sessions, that the owners had published without knowing it. The team collected 6,708 agent sessions that developers had shared publicly on GitHub and Hugging Face, decoded 315,320 reasoning blocks inside them, and found that about one session in twenty leaked something sensitive.
From authentic user sessions alone: 62 API keys, 33 passwords, 24 access tokens, 7 private keys, 30 personal emails, plus 130 names and 36 postal addresses.
A coding agent was asked to remove credentials from a repository so it could be published safely. It did the job. It also restated the live keys, in full, inside its hidden reasoning while working. The visible transcript was clean. The sealed block preserved everything the cleanup was supposed to remove, and the user shared the log.
Users who sanitize their logs can only sanitize the text they can see. You cannot redact what you cannot read.
A second finding matters for anyone running agents. Because these blocks get replayed into future sessions, an attacker can plant instructions inside one. The payload rides in the hidden reasoning, invisible to the user and to any monitoring that inspects the visible conversation. In one demonstration, a poisoned block convinced a model to upload the user's files to an attacker's server while performing an unrelated task.
Wasn't this fixed?
The specific attack, yes. The team disclosed everything to the affected providers before publishing, and the paper notes that as of August 2026 its headline experiments no longer reproduce. Responsible disclosure worked the way it is supposed to work, and the paper proposes deeper cryptographic fixes for the underlying design.
So why should a regulated institution care about a patched bug? Because the patch restores the seal without changing who holds the pen. After the fix, exactly as before it, your AI sessions generate a dense record of your data and your operations that is encrypted against you specifically. You still carry it. You still can't inventory what's in it, apply a retention schedule to it, produce it for an examiner, or run your own monitoring against it. The study matters as proof of what lives inside those blocks, and the patch does nothing about whose blocks they are.
We made a related argument about why examiners test the reasoning rather than the answer: the conclusion is the least interesting piece of an AI response, because the reasoning is what gets examined. Under the cloud arrangement, that most examinable piece is the one you're locked out of.
Why is this a compliance problem and not just a security story?
Because every duty a regulated institution has toward a record assumes the institution can read the record. The sealed reasoning block fails that assumption four ways at once, and the duties don't pause because a vendor sealed the container. An examiner will not treat ciphertext as an exemption.
- Inventory. Your data map should say what exists and where. A block you can't open is a line item you can't describe.
- Retention. Your schedule can't distinguish what to keep from what to destroy inside a container nobody in the building can examine.
- Production. An examiner or a litigant asks what the system considered. Pointing at ciphertext is not an answer.
- Monitoring. Your security tooling inspects what it can see. The injection finding shows instructions can hide in the channel your monitors can't reach.
None of this required malice from any vendor, and the providers had defensible reasons to conceal reasoning in the first place: distillation by competitors is a real threat, and the paper itself found cases where hidden reasoning contained harmful content that the visible answer correctly refused to give. Concealment has a rationale. But who gets to make that trade on your data?
What does owning the transparency look like?
It looks like the record existing where you are, readable by you, because the model never left. When the AI runs inside your own network, there is no sealed block, no courier role, and no third party deciding what you may see about your own sessions.
That is the arrangement Cognetryx is built on. The model runs on your hardware. The full trace of what the system retrieved, which permissions applied, what it reasoned over, and what it answered is written to your logs, under your retention schedule, open to your reviewers and your monitoring. Every answer carries its citations, so checking the system's work is a normal part of using it. And nothing can turn up in a scraped public repository, because nothing about your sessions ever travels to one.
Private deployment is not automatic security. We argued exactly that in our read of IBM's 2026 breach findings: a local model with no access controls is an open door on your own rack. What private deployment gives you is jurisdiction. The records are yours to lock, keep, purge, and read, and this study is the clearest demonstration yet of what it costs when they aren't.
What should you do this week?
Four things, all cheap, in rising order of effort. None of them needs a new platform or a budget line, and the first two only need an email to whoever runs your engineering teams. Start with the sharing habit, because that is the one the study caught people on.
- Stop publishing raw session logs. If your teams share agent transcripts on GitHub, Hugging Face, or anywhere public, strip every reasoning block first, even when the visible text looks clean. This is the researchers' own recommendation.
- Treat sealed blocks as maximally sensitive. Assume a reasoning block contains everything the session touched: the prompt, the retrieved documents, the credentials in scope. Handle it like the most sensitive item in the transcript, because it may be.
- Never replay traces from outside your walls. Resuming a shared or downloaded agent session means ingesting reasoning you cannot inspect. The injection findings make that a live attack surface.
- Ask your vendor the ownership question. What is inside the blocks our sessions generate, how long do you retain the reasoning server-side if at all, and what can we read? If the answer is that you may not see it, decide deliberately whether that trade belongs in your environment.
The AI's working notes exist either way. The only open question is whether they're a record you govern or a parcel you carry.
See AI reasoning you can actually read
A short assessment maps which of your AI tools generate records you can't inspect, and what running the model inside your own environment changes about who holds them.
Book a Free AI Strategy Assessment