Researchers Decrypted AI Reasoning Logs—And Found 62 API Keys

August 11, 2026

Researchers recovered API keys and PII from encrypted OpenAI, Claude, and Gemini reasoning logs. The known attack appears fixed—but old traces need review.

Encrypted AI reasoning logs were supposed to be opaque. New research says they were not safely bound to the user, session, or model that created them. By replaying those blocks through a compatible model from the same provider, researchers recovered hidden reasoning from OpenAI, Anthropic, and Google APIs—and found real API keys, passwords, access tokens, private keys, and personal information inside public agent traces.

The reported attack no longer worked after responsible disclosure. That is reassuring, but it does not make old exported traces harmless. Developers should treat opaque reasoning fields as sensitive data, audit anything already shared, and rotate credentials that may have been exposed.

What Is Confirmed

The August 10, 2026 paper Stealing Reasoning Traces from Proprietary LLM APIs describes a cross-model attack against encrypted or signed reasoning blocks returned by proprietary model APIs. The authors tested Anthropic, OpenAI, and Google model families in early July 2026.

These opaque blocks exist for a practical reason. A stateless API client may need to send a model's prior hidden reasoning back on the next turn so the model can continue without the provider storing the whole conversation as ordinary server-side state. The client cannot read the block directly, but the provider can accept it on a later request.

The researchers found that a block generated by a stronger model could be replayed to a weaker compatible model from the same provider. Carefully prompted, the weaker model reproduced the hidden reasoning in readable form. The paper calls this a semantic decryption oracle: the attacker did not need the provider's cryptographic key because the provider's own model performed the useful decoding operation.

The researchers say the blocks were portable across sessions, API users, and compatible models within the same provider family. Their threat model used ordinary API access. It did not require provider employment, access to model weights, or a compromise of the provider's internal network.

The most important evidence comes from a scan of 6,708 publicly available agent trajectories collected from GitHub and Hugging Face. The team reconstructed 315,320 reasoning blocks and reported:

• 1,028 blocks, or about 0.3%, contained at least one privacy leak.
• 328 sessions, or about 4.9% of the public trajectories, leaked at least one real sensitive item.
• Genuine user sessions contained 704 distinct sensitive artifacts.
• Those artifacts included 62 API keys, 33 passwords, 24 access tokens, 7 private keys, 30 personal email addresses, 6 non-localhost IP addresses, 130 names, and 36 postal addresses.
• Sixty-four genuine-user artifacts appeared only in hidden reasoning, not in the visible chat history.

The researchers' project page also reports 912 distinct privacy artifacts when synthetic benchmark personas are included: 367 pieces of personal information, 363 technical identifiers, and 182 credentials. That larger number should not be described as 912 real-user secrets. It mixes genuine public traces with deliberately constructed benchmark data.

The paper says the team disclosed the issue to the affected model providers, Microsoft, and Hugging Face. All affected model providers acknowledged the reports. After disclosure, the researchers could no longer reproduce the same attack.

That last point matters: this is not evidence that an attacker can repeat the demonstrated technique against current production APIs today. It is evidence that exported reasoning envelopes were a security boundary, that the boundary failed in the tested configurations, and that already-public artifacts may deserve retrospective review.

What Is Still Unclear

The paper does not identify the exact fix used by every provider. Public documentation available with the research does not establish whether providers changed envelope formats, bound blocks to individual users or sessions, retired signing keys, added model-level refusal behavior, or combined several defenses.

It is also unclear whether every legacy block created before the fixes has been invalidated. If an old signature or envelope is still accepted somewhere, historical exposure could differ from the researchers' post-disclosure tests. Conversely, a provider may have invalidated those artifacts comprehensively without publishing the implementation details.

The authors could not compare every recovered token with a provider-held plaintext ground truth because the hidden reasoning was, by design, unavailable to them. They report close agreement with API token counts and successful recovery of sensitive artifacts, which supports high fidelity, but “recovered reasoning” should not be treated as proof that every character of every trace was reproduced perfectly.

There is no evidence in the paper that ordinary consumer ChatGPT, Claude, or Gemini conversations were broadly decrypted from provider databases. The demonstrated path concerns API responses containing opaque reasoning fields, particularly when developers, agents, observability tools, or datasets preserved and later shared those raw responses.

The research also does not prove that every opaque reasoning field contained secrets, that every publicly shared trace was vulnerable, or that the exposed credentials remained valid when discovered. The researchers say recovered secrets were securely deleted after classification and coordinated disclosure.

How Could An Encrypted Reasoning Log Reveal Plaintext?

Encryption is only one part of an access-control design. A ciphertext can use sound cryptography and still become readable if a system accepts it in the wrong context and then reveals its meaning.

Imagine a sealed note that only a company's machines can open. The seal itself may be strong. But if any paying customer can hand that note to another company machine and persuade it to read the contents aloud, the cryptography has not delivered the intended privacy boundary.

That is the core of the reported attack. The researchers did not describe brute-forcing an encryption key. They found that compatible provider models would accept a reasoning block created elsewhere, interpret it, and expose its semantic contents. Cross-user and cross-session portability turned the model into the decoder.

This distinction is useful because it changes the defensive question. “Was the cipher broken?” is too narrow. Developers also need to ask:

• Is this envelope bound to one account, session, request, model, and purpose?
• Can a different user submit it?
• Can a weaker or differently aligned model consume it?
• Will any compatible endpoint summarize, continue, transform, or quote what it decoded?
• Do logs and datasets retain the envelope after the visible text has been sanitized?

A secure envelope needs cryptography and context enforcement. Either one can undermine the other.

Why The 62 API Keys Matter

An API key in visible assistant text is an obvious incident. A key copied into hidden reasoning is easier to miss because the normal transcript can look clean.

The paper includes examples in which a model reasoned about secrets while performing repository or configuration work. In one case, the visible workflow was sanitizing a repository while the hidden reasoning restated AWS and Hugging Face credentials. The public-facing response did not need to print those values for the opaque block to retain them.

That creates a dangerous mismatch between a developer's review surface and the stored artifact. A person can remove secrets from the visible prompt and response, inspect the readable log, and publish the trace while an attached encrypted field still carries the sensitive value.

This is not a reason to assume models intentionally hoard credentials. Reasoning systems routinely restate, compare, transform, and track tokens that are relevant to a task. If a secret enters model context, hidden computation may repeat it. The privacy failure occurs when that computation is exported, retained, accepted outside its original context, and made recoverable.

The result is a broader lesson for agent observability: unreadable does not mean non-sensitive. A blob can be opaque to today's developer and still be meaningful to the service that issued it—or to a future tool, model, bug, or attacker.

Use The TRACE Audit For Old Agent Logs

Teams that have saved or shared raw model API responses can use a five-step TRACE review.

T — Trace Inventory

Find where complete API responses and agent trajectories have gone. Check source repositories, issue attachments, CI artifacts, experiment trackers, observability platforms, object storage, notebooks, public datasets, Hugging Face repositories, support tickets, and developer machines.

Inventory both current systems and historical exports. A removed Git commit may still exist in forks, caches, releases, mirrors, pull-request diffs, or dataset revisions.

R — Remove Opaque Reasoning Fields

Strip provider-specific reasoning envelopes before publishing or sharing a trace. The paper discusses fields and structures associated with names such as signature, thinkingSignature, and encrypted_content, but those examples are not an exhaustive detection list. Formats can differ by provider, SDK, model, and version.

Prefer an allowlist that exports only the fields a reviewer actually needs. A denylist of known secret-looking fields will age badly as APIs evolve.

A — Assume Hidden Fields Can Repeat Visible Secrets

Do not conclude that a trace is safe merely because its readable transcript was cleaned. If the model ever received a credential, private key, personal record, internal hostname, customer document, or confidential code, assume an opaque reasoning field may have transformed or repeated it.

This is especially important when the task itself involved redaction, migration, configuration, debugging, or credential replacement. The hidden reasoning may need to compare the old and new values even when the final answer shows only the sanitized result.

C — Change Credentials And Clean Up Artifacts

If a raw affected-era trace containing real secrets was public, revoke and rotate those secrets. That includes API keys, access tokens, passwords, private keys, signed URLs, database credentials, cloud credentials, and webhook secrets. Do not wait for proof that someone used them.

Then remove the exposed artifact from the live repository or dataset and pursue history, cache, fork, and mirror cleanup where possible. Deleting the current file is useful, but it does not retroactively erase clones or downstream copies.

E — Evaluate The Fix And Future Logs

Confirm the current provider and SDK behavior rather than assuming a research disclosure covers every environment. Test whether opaque fields are still emitted, what must be returned on later turns, whether envelopes are bound to the originating context, and what your logging stack preserves.

Add a regression test to the export pipeline. When an SDK or model changes, the test should fail if an unexpected opaque field enters a shareable artifact.

What Developers Should Search For Right Now

Start with raw JSON rather than rendered chat views. Search schemas, serialized responses, database columns, event payloads, and dataset features for reasoning-related objects and high-entropy opaque strings. Provider examples in the paper can guide the first pass, but inspect actual captured payloads because names and nesting may vary.

Prioritize public or broadly shared material created before the provider fixes. A practical order is:

1. Public GitHub repositories and gists containing full agent trajectories.
2. Public Hugging Face datasets, Spaces assets, and model-evaluation traces.
3. CI logs and downloadable build artifacts.
4. Public experiment dashboards and observability samples.
5. Internal traces shared across teams, vendors, or customers.
6. Private local archives that may later be uploaded or reused.

For each match, ask whether sensitive context was ever present in the request, tool result, file, environment, or prior conversation. If yes, treat the opaque field as sensitive even if you cannot currently decode it.

Secret scanning remains valuable, but conventional scanners may miss encrypted or signed blobs. The scanner sees high-entropy ciphertext, not the API key inside it. The safer control is to avoid exporting unneeded reasoning fields at all.

Is Deleting The Visible Chat Enough?

No. Visible chat text, provider-side conversation history, local agent logs, raw API responses, observability events, and public datasets are separate stores. Removing one does not automatically remove the others.

This is the same boundary problem behind questions such as whether AI error logs can capture prompt content and whether “no chat history” means an AI app keeps no logs. A privacy claim about one store should never be silently extended to every operational record.

The new research adds another category: a field that looks unreadable during manual review but remains semantically usable by a compatible model service. That field belongs in the data inventory, retention policy, access-control model, export filter, and incident-response plan.

If a trace has already been public, cleanup is necessary but cannot guarantee retrieval of every copy. Credential rotation is the control that limits future usefulness of a copied secret.

What This Means For AI Privacy Claims

Users should ask what a product means by “encrypted,” “private,” “temporary,” or “not stored.” Those words can describe different layers:

• Transport encryption protects data moving over a network.
• Storage encryption protects data at rest under certain threat models.
• An opaque reasoning envelope hides content from the API client.
• Session binding controls where that envelope can be replayed.
• Retention rules govern how long copies remain.
• Export filtering controls what enters logs and public datasets.
• Training policy determines whether data is used to improve foundation models.

One layer cannot prove the others. A strong evaluation checks each claim against the exact data flow, as explained in what to verify before trusting an AI privacy claim.

This incident also shows why hidden context deserves explicit attention. Feedback systems, agent debuggers, and trace exporters may package more than the text visible on screen. Our guide to AI feedback and hidden system context explains the same review principle from another direction.

Where OpenVeil Fits—And Where It Does Not

OpenVeil is a hosted, privacy-focused AI workspace for adults. Normal chat history stays in the user's browser, and OpenVeil does not maintain a normal server-side chat-history record for private chat sessions. OpenVeil also does not use prompts, uploaded files, images, audio, selected local-history context, or AI outputs to train foundation models.

Those boundaries can reduce the routine account-level chat history a user entrusts to a hosted application. They do not make OpenVeil fully offline. Active requests still have to be processed by OpenVeil and necessary providers, including AI, search, upload-processing, hosting, routing, security, billing, and infrastructure providers.

OpenVeil is not a developer trace-security product. It does not claim to remove provider-side reasoning blocks, secure raw API responses exported by another agent framework, rotate exposed credentials, clean Git history, or patch OpenAI, Anthropic, or Google APIs. It also cannot protect a secret that a user publishes elsewhere.

The useful fit is narrower: if you want a hosted workspace without a normal server-stored chat history and without foundation-model training on your prompts or files, try OpenVeil. If you operate agents or retain raw model API responses, you still need the TRACE controls above.

Frequently Asked Questions

Did researchers break the encryption used by OpenAI, Anthropic, and Google?

Not in the conventional sense of recovering a cryptographic key or brute-forcing a cipher. The reported attack used a compatible provider model as a semantic decryption oracle: the API accepted an opaque reasoning block from another context, and the model exposed its meaning.

Were ordinary ChatGPT, Claude, and Gemini consumer chats affected?

The paper does not demonstrate a broad compromise of consumer conversation databases. It focuses on proprietary model APIs and opaque reasoning fields preserved in raw responses and agent trajectories. A specific consumer product could have separate logs and controls, but that would need separate evidence.

Is the attack still working?

The researchers say they could not reproduce the same attacks after disclosure, and all affected model providers acknowledged the reports. The paper does not publicly document every vendor's remediation or prove the status of every legacy artifact, so teams should still audit old traces.

What fields should developers search for?

The paper describes provider-specific structures associated with names including signature, thinkingSignature, and encrypted_content. Treat those as starting points, not a complete list. Inspect the real schemas produced by every provider, SDK, proxy, and observability tool in your stack.

Is deleting visible chat text enough?

No. Raw API responses, opaque reasoning fields, agent logs, CI artifacts, dataset revisions, forks, caches, and provider-side records can be separate copies. Remove exposed artifacts where possible and rotate any credential that may have been included.

Should every API key in an old trace be rotated?

If the key or other credential was sent to a model and an affected-era raw trace was public or shared beyond its intended audience, rotation is the prudent response. A clean visible transcript does not rule out repetition inside hidden reasoning.

Can OpenVeil prevent this type of reasoning-log exposure?

OpenVeil provides browser-local normal chat history and no normal server-side chat-history record, but it is not an API trace sanitizer or provider security patch. Active requests still require processing by OpenVeil and necessary providers. Developers remain responsible for credentials, exported logs, repositories, datasets, and agent infrastructure.

The Bottom Line

Encrypted reasoning blocks were not merely harmless metadata. In the tested systems, compatible models could decode blocks across users and sessions, and public traces contained real credentials and personal information that visible-chat review sometimes missed.

The known attack appears to have been stopped after disclosure. The durable lesson remains: do not publish opaque reasoning fields, do not assume unreadable means safe, and do not rely on visible-text cleanup when secrets entered model context. Inventory old traces, remove unnecessary envelopes, rotate exposed credentials, and verify current provider behavior.