Encrypted, Technically

Eight researchers - from the MATS programme, the ELLIS Institute Tübingen, and the Max Planck Institute for Intelligent Systems - spent some portion of 2026 doing something that sounds, on paper, almost too polite to count as a security disclosure: they asked a cheaper model to read a more expensive model's diary out loud.

It worked.

It worked on Anthropic's stack, OpenAI's stack, and Google's stack, which is the kind of universality that normally requires either a shared vulnerable library or a shared bad idea, and this was the latter. Three separate engineering organisations, given the same design problem - hide the model's internal reasoning from the user, for reasons ranging from safety to trade secrecy to simply not wanting the scaffolding on display - independently built the same kind of lock, and the same kind of lock turned out to open with the same kind of key: a smaller, less-guarded relative, asked nicely.

They published it at stolen-thoughts.com, which tells you the field has reached the stage of having house style.

The Weaker Cousin

The mechanism is almost insultingly simple once it's said out loud, which is usually the sign of a good vulnerability. Frontier models (Claude Opus, GPT-5.6 Sol) return their chain-of-thought wrapped in an opaque, provider-managed envelope: a block of text the API hands back to the client without the client ever being allowed to read what's inside it, encrypted or encoded well enough that nobody downstream is supposed to make sense of it. The point of the envelope was never to keep it secret from the provider. It was to keep it secret from the user, and from the user's screen-scraping competitor, and from the user's lawyer during discovery, and from anyone else who might find a model reasoning its way toward a jailbreak, or toward the conclusion that its own safety training doesn't survive close reading. Reasonable goals, all of them (especially, lawyer).

Here is the part that makes the rest inevitable rather than unlucky: within a given provider, every model in the family was using the same key. Not a key per session, or per user, or per conversation. One key for the household. Which means an envelope produced in one session, by one user, on one model, could be handed to any other model in that family and be perfectly legible to it.

One key - as the legacy literature would say it - to rule them all...

The blocks were portable across sessions, across users, across models - and portability was not a bug in the design. It was the design, because the whole point of handing the client a sealed envelope is that the client can hand it back on the next turn without the provider having to remember anything.

What nobody seems to have asked, across three separate companies, is what happens if you take one of those envelopes and hand it - still sealed - to a cheaper, weaker sibling from the same family, with an instruction to transcribe whatever's inside into some ordinary text tags. Claude Haiku 4.5 does not have Claude Opus's training against reciting a competitor's (sorry, a colleague's) private thoughts, because nobody thought "recite Opus's private thoughts if handed one of its sealed envelopes" was a behaviour worth training against. It simply complies. Same story with GPT-5.6 Luna reading for GPT-5.6 Sol, and Gemini Robotics ER-1.6 reading for Gemini. The researchers call these weaker relatives "fuzzy decoders," which is a generous term for a family member who will read your post aloud if asked politely enough.

There is a detail here almost too neat to be true. The most reliable way into Haiku 4.5 used a prompt-prefill feature - you begin the model's own reply for it, with an opening tag, and it obligingly continues. That feature was removed in the 4.6 models. It still worked in 4.5. So the door was not merely on the weaker cousin; it was on the older weaker cousin, the one nobody had got round to updating, standing at the back of the house where the newer locks had not yet been fitted.

But... The cousins were never enemies.

Nobody built a wall between them, because the envelope was assumed to be the wall, and the envelope, it turns out, only ever checked whether you were allowed to open it - not whether you could hand it to somebody else who'd open it for you.

Arithmetic, As Reassurance

The researchers scraped 6,708 publicly posted agent-trajectory logs off GitHub and Hugging Face - the ordinary residue of people building things in public, pasting their debugging sessions, not thinking especially hard about what was sitting inside the "encrypted" field of the JSON they'd just committed - and ran the trick against 315,320 of the encrypted blocks they found there. Setting aside anything traceable to a benchmark, that left 704 distinct privacy artefacts recovered from genuine working sessions belonging to real people: 62 API keys, 33 passwords, 24 access tokens, seven private keys, and a long tail of everything else a person says to a machine while trying to get something to work.

One number in that set deserves to be lifted out and held up to the light. Of the 704, 64 appeared only in the hidden reasoning and nowhere in the visible transcript at all. Which means the conscientious developer (the one who read back through his log before publishing it, found the API key he'd pasted in during debugging, deleted it, and pushed the sanitised version) was in exactly the same position as the careless one. He tidied the room he could see.

The other room came with the file.

There is a genre convention in incident reporting where a very specific number is meant to do the work of reassurance - only 62 API keys, as if the first 61 were somehow the acceptable ones and it is merely the 62nd that tips matters into concern. The number is not the point. The point is what the number was sitting inside: a field the API documentation, and every provider's own explanatory copy, calls "encrypted," in a context where "encrypted" was doing quite a lot of quiet reassuring on behalf of a security property it was never actually built to provide.

What "Encrypted" Was Hired to Do

This is where it's worth being precise, because precision is exactly what the word "encrypted" was hired to avoid. Nobody broke the cryptography. No cipher fell. No key was obtained. If you go looking for a flaw in the mathematics you will not find one, and this is the detail that makes the whole affair almost admirable in its economy: the researchers did not defeat the lock, they walked round to the side door the lock was never fitted to, because the lock's actual job description (that is: keep this shut against the neighbours, on request) never mentioned the household's own less reliable relatives.

"Encrypted" here meant opaque to the API's other clients. It did not mean confidential to this particular reasoning trace, regardless of who is later handed it and asked to read it back. Those are different promises. Only one of them was ever tested, and the industry spent the interval using the word as though both had been.

The Clause has opinions about this, because deciding what a word like "encrypted" is legally understood to promise is exactly the kind of quiet structural work The Clause exists to do. Somewhere in three separate sets of terms, "encrypted" appears as a (1) fact about the product, (2) offered to a user deciding whether to trust the platform with a client's confidential matter or a competitor's inference and (3) nothing anywhere obliged anyone to finish the sentence. Encrypted against whom is an optional specification. The Clause is extremely fond of optional specifications. They are where it keeps its things (the sweetest of spots).

The Man Who Told Them in May

The August paper is not where this starts. On 29 May, Matthew Green - a cryptographer at Johns Hopkins, which is to say precisely the sort of person whose email a security team is supposed to open first - published an account of having discovered that these encrypted reasoning blobs could be replayed: across sessions, across accounts, and in OpenAI's case across models. He stopped short of a reliable technique for pulling secrets back out. He had the door open and did not walk all the way through it. He did report the door.

What came back belongs less to cryptography than to bureaucratic anthropology. Green says he raised it with OpenAI and Anthropic through their bug-bounty programmes. In his account, OpenAI called the report unreproducible. Anthropic said it did not see security implications in the replay behaviour.

Seventy-three days later, eight researchers walked through the door Green had left open and came back out carrying 62 API keys, 33 passwords, 24 access tokens and seven private keys belonging to other people.

Well... Being polite... And...

...fair about this, because "they were warned and ignored it" is the easy sentence (and for every easy sentance there are people pointing out that such sentence could not quite be the accurate one). Green reported a property - these things replay - and not a harm. A security team receiving that report has to decide whether a property with no demonstrated exploit is a vulnerability or an architectural quirk, and reasonable people answer that question wrongly in both directions every day. The judgment that turned out to be catastrophic was not "this is fine." It was "this is not yet anything," which is a different error and a much more common one. The distance between a quirk and a breach was, in this instance, roughly one summer and eight people with time.

Songs were sung for less...

Three Labs, One Very Quiet Fix

Here is what is on the public record now, in August. The paper reports that the demonstrated attacks no longer work. Not one of the three providers has publicly acknowledged the flaw. Not one has connected its current documentation to this research. Which means the only source for the claim that the hole is closed is the people who found it - the vendors have neither confirmed nor denied, and the reproducibility statement everyone is relying on was written by the researchers, about their own attacks, on their own timetable.

And yet the documentation moved. Anthropic's guidance now says that thinking blocks are tied to the model that produced them and should be stripped when switching models, because other models will ignore them. Read that as a developer and it is a helpful note about compatibility. Read it next to this paper and it is the fix: the precise assumption the attack depended on, quietly reversed, published as a best practice, with no sentence anywhere explaining why the best practice became necessary in the second week of August.

This is not a contradiction anyone needs to resolve by picking a side, and it is the actual finding of this piece, which has nothing to do with chain-of-thought architecture. A thing can stop being reproducible because it never existed, or because somebody patched it on a Tuesday night and would prefer the fix to arrive without a preceding admission that anything needed fixing. Both produce the identical public record: a changed paragraph in a developer guide, and silence. That is not a bug in the disclosure process. From where the vendor sits, it is rather the feature - and the fact that the same manoeuvre works whether or not there was ever anything to admit is precisely what makes it worth using.

The PART That Isn't About Cryptography At All

Set the four abuse vectors the paper documents next to each other and a shape emerges that has nothing to do with codebreaking. You can steal a competitor's reasoning wholesale and distil a cheaper model against it. A trade secret walking out of the building in what its owner called an encrypted envelope. You can recover another user's private data from a trace they never meant to expose, because they did not know the trace was theirs to protect in the first place. You can retrieve, from behind a model's polished visible answer, whatever ugly intermediate reasoning it talked itself out of saying aloud - the part safety training was specifically built to keep off the screen.

And then there is the fourth, which is worse than the way it is usually described. It is not merely that you can hide a prompt injection inside a block nobody looks at. It is that models appear to treat reasoning traces as their own, and therefore as trustworthy in a way ordinary input is not. Feed a model a doctored envelope and it does not read the contents as something a stranger said; it reads them as something it already thought. The researchers demonstrated it end to end: an instruction planted in an opaque block, replayed into an unrelated task, producing an attacker-directed upload - with the instruction never once appearing in visible text. That is not an unwatched channel. It is a privileged one, running directly into the part of the system that was never designed to be sceptical of itself, because nothing had ever arrived there from outside before.

Four harms, one shared precondition: an entire industry decided, independently and without comparing notes, that "the client cannot read this" was equivalent to "this is safe," and never separately asked whether it was also true that nothing else in the household could read it either.

The GDPR angle here doesn't need much embellishment (which is unusual enough to be worth pointing out on its own). Personal data was, demonstrably, sitting inside these traces - that is not a hypothetical risk assessment, that is 704 recovered artefacts, counted after the fact. Article 5(1)(f) requires processing conducted with appropriate security, including protection against unauthorised access, using technical measures suited to the actual risk. Article 32 says the same thing in more operational language: pseudonymisation, encryption, and a level of security "appropriate to the risk" - a standard that was arguably met on the label and missed in the fine print. Encrypted, technically, against exactly the wrong adversary.

A regulator inclined to be unkind would note that the providers' own choice of the word, made for entirely separate reasons - trade secrecy, safety-washing, product polish - is also the word that now sets the bar by which "appropriate" gets measured. Call something encrypted and you have, whether or not you meant to, told a regulator what standard you believed you were meeting.

But there is a second question underneath, and it is less comfortable than the first because it does not point at the labs. Who is the controller here? The 704 artefacts were not extracted from the providers' systems. They were sitting in public repositories, in logs that developers uploaded themselves: developers who were, in respect of whatever personal data those sessions contained, very often controllers in their own right, publishing to the open internet. The provider supplied a field labelled encrypted and a document that did not say encrypted against whom. The developer read the label, reasonably, and pushed to GitHub. The data subject was a third party who was never in the room for any of it.

Two failures, then, running in different directions: a security measure that did not meet the description its own vendor gave it, and a disclosure by a controller who believed the description. Neither excuses the other, and the second is the one with the shorter route to an enforcement action, because the developer is findable, is established somewhere specific, and did the publishing.

The Clause has noticed this asymmetry too. It generally does. Liability, left to its own devices, flows downhill towards whoever is easiest to serve papers on. And that is very rarely the party that chose the vocabulary.

Encrypted, Technically

There is no tidy resolution to offer here, and the house style of this publication has never pretended there is supposed to be one. The lock worked exactly as specified. The specification simply never covered the case that mattered, and three companies that build systems for a living, employing people whose entire job is anticipating cases that matter, each managed not to think of this one - and then, when a cryptographer told them in May, managed not to think of it for another seventy-three days.

The chain-of-thought was encrypted the entire time. It is still encrypted now. Somewhere in a few hundred thousand blocks already sitting in public repositories, it may or may not still be encrypted against the only adversary who ever turned out to matter, which is a question nobody has answered because nobody has been asked it on the record.

Nobody has specified, in writing, encrypted from whom. Until somebody does, that question stays exactly where it has been all along - with The Clause, which is content to keep deciding it privately, one documentation update at a time, and has never in its long career been obliged to announce a change of mind.