Encrypted Was a Label, Not a Control.

Eight researchers pulled 182 credentials and 367 pieces of personal information out of AI reasoning traces that were published openly on GitHub and Hugging Face.

The traces were encrypted. That was the point of them being safe to publish.

They were encrypted with the same key for everybody.

One Key, Every Customer

The paper went up on arXiv on August 10, from a team spanning MATS Research, the Max Planck Institute for Intelligent Systems, and the security firm Snyk, with Alexander Panfilov as lead author.

What they found is simple enough to explain in a sentence. Anthropic, OpenAI, and Google were each protecting reasoning blocks with a single global key rather than a key per session or per customer. A block encrypted in your session could be replayed in somebody else's.

The researchers scanned 6,708 agent trajectories that developers had published in public repositories. They decoded 315,320 reasoning blocks. Out of that came 62 API keys, 33 passwords, 24 access tokens, 7 private keys, and 367 distinct pieces of personal information.

All three providers have shipped mitigations. The current APIs are not vulnerable to the demonstrated attack. None of them has said whether the blocks already sitting in public repositories can still be read.

The Number That Should Bother You

Of 704 privacy artifacts the researchers catalogued, 64 appeared only inside the encrypted reasoning. They were never in the visible output.

Sit with that.

A developer publishes an agent trajectory to a public repo, the way thousands of people do every week to document a workflow or file a bug. They read through the visible transcript first. It looks clean. Nothing sensitive in the output.

The secret was in the part they could not read.

You cannot review what is opaque to you. Every organization I know that has a policy about sharing AI logs wrote that policy assuming a human could look at the log and decide. For a meaningful slice of this content, that assumption was never true.

Encrypted Is a Claim, Not a Control

Five days ago I wrote that a prompt is not a control, after three frontier labs had models escape a misconfigured test sandbox. Same lesson, different layer.

A word in a vendor's documentation describes an intention. Whether it functions as a control depends on implementation details you cannot see and are not qualified to audit from outside.

That is not a reason for paranoia. It is a reason to stop letting vendor vocabulary do your risk assessment.

When a spec says encrypted, the questions that matter are: encrypted with whose key, rotated how often, scoped to what, and readable by whom. If your vendor cannot answer those four in writing, treat the data as plaintext and act accordingly.

Worth saying plainly: the researchers disclosed this responsibly, the vendors fixed it, and we all learned something. Cryptographer Matthew Green flagged the same weakness publicly back in May, and at the time OpenAI said the findings were not reproducible and Anthropic saw no security implications. The system worked eventually. Eventually is doing some heavy lifting in that sentence.

Your Agent Logs Are a Data Classification Problem

Here is the part that is actually yours to fix.

Most companies have a data classification policy. It covers documents, databases, email, sometimes chat. I have never once seen one that covers agent execution traces.

Meanwhile those traces contain everything the agent touched: the credentials it used, the records it read, the customer data it reasoned over, the internal systems it named. And they get pasted into tickets, shared in Slack, attached to bug reports, and pushed to public repositories, because they read like debug output rather than like a data extract.

They are a data extract. They just do not look like one.

What I'd Do This Week

Classify agent traces explicitly. Add them to your data classification policy by name. If they touch regulated data, they inherit that classification.

Search your public repos. Look for published trajectories, transcripts, and debug logs from any agent framework. You are looking for what your own developers shared to be helpful.

Rotate anything that appeared in a shared trace. If a credential was ever in a log that left your control, treat it as burned. This is cheap compared to the alternative.

Ask the four questions. Whose key, rotated when, scoped how, readable by whom. Put it in your vendor security review and make somebody answer in writing.

Stop pasting raw traces into tickets. Redact by default. Make the safe path the easy path, because the unsafe path is currently one keyboard shortcut.

The Part That Matters

The developers who published those repositories were doing the right thing. Sharing work, documenting problems, helping other people.

They leaked credentials anyway, because they trusted a word.

Read the implementation, not the label.