A Flaw in OpenAI, Anthropic, and Google APIs Lets Weaker Models Steal Stronger Ones' Reasoning

A newly disclosed vulnerability in the APIs of OpenAI, Anthropic, and Google allows smaller, cheaper AI models to extract the hidden reasoning traces of more powerful frontier models. The research, published this week, demonstrates a practical attack chain that could compromise sensitive data and undermine the intellectual property protections that major AI providers have implemented.

The core issue is straightforward: when frontier models like Claude Opus 4.8 process requests, they generate internal reasoning blocks that are never shown to the user. These hidden blocks contain the model’s step-by-step thinking process, and they’re supposed to stay private and secure. But researchers found that by capturing these encrypted reasoning blocks and feeding them into a smaller model through the same API, the smaller model can be instructed to transcribe the internal thinking verbatim. The attack doesn’t require any special tools or privileged access, just standard API credentials that any developer can obtain.

How the Attack Works

The attack chain is surprisingly simple in concept, even if the technical details are complex. An adversary captures an encrypted reasoning block emitted by a frontier model. They then inject this block into an API call to a smaller model, such as Claude Haiku 4.5, and instruct the smaller model to transcribe the reasoning inside custom text tags.

Because lighter models lack the same security guardrails and are cheaper to query, they function as what the researchers call “decryption oracles.” The smaller model processes the reasoning block and outputs the hidden thinking process in plain text. The attack exploits cross-session compatibility between models from the same provider, meaning reasoning traces from one session can be injected into another.

This isn’t theoretical. The researchers demonstrated it across all three major providers, showing that the vulnerability is systemic rather than isolated to a single company’s implementation. The attack works regardless of which specific model generates the reasoning trace, as long as the attacking model is from the same provider’s ecosystem.

The practical implications are significant. An attacker needs only standard API access, which costs relatively little. They don’t need to compromise infrastructure, steal model weights, or gain physical access to anything. The entire attack can be performed remotely through legitimate API calls, making it both hard to detect and easy to execute at scale.

What the Researchers Found

To assess the real-world impact, the team analyzed 6,708 public agent transcripts scraped from GitHub and Hugging Face. They decoded 315,320 embedded reasoning blocks and recovered an alarming amount of sensitive data:

• 367 personally identifiable information (PII) artifacts
• 182 hardcoded credentials, including 62 API keys, 33 passwords, and 30 personal email addresses

What makes this particularly concerning is that much of this sensitive data resided solely within the internal reasoning blocks. It was never rendered in the visible assistant responses, which means developers who shared session logs or published agent transcripts had no idea their data was exposed. The secrets were hidden in the model’s internal monologue, invisible to anyone who only read the output.

The researchers also found that the attack could be performed repeatedly across different sessions, building up a comprehensive picture of what a frontier model knows and how it processes information. This cumulative exposure is especially dangerous for organizations that use AI agents for ongoing tasks, where the reasoning blocks from multiple sessions could reveal patterns about internal processes, customer data, or proprietary algorithms.

The scope of the data exposure was striking. Among the 367 PII artifacts, researchers found full names, home addresses, phone numbers, and dates of birth. The 182 credentials included not just API keys for popular services, but also database connection strings, SMTP credentials, and authentication tokens for internal systems. This suggests that developers were using AI agents to process real production data, not just test inputs, and the reasoning traces captured everything the model “thought about” during those interactions.

Why This Matters

The implications extend well beyond model distillation or intellectual property theft. When developers use AI agents to process sensitive data, they often assume that only the final output is visible. This research proves that assumption wrong. The reasoning blocks contain a parallel stream of information that can be captured and decoded.

For organizations deploying AI agents that handle customer data, financial information, or proprietary code, this vulnerability creates a new attack surface. An attacker who can access API traffic, even briefly, could extract reasoning traces that contain credentials, personal information, or business logic that was never meant to be exposed.

The fact that this works across OpenAI, Anthropic, and Google suggests the issue is architectural rather than implementation-specific. All three providers use similar approaches to handling reasoning traces in their APIs, and all three are vulnerable to the same class of attack. This means a fix at one provider doesn’t necessarily protect users of the others, and a coordinated response across the industry is needed.

The vulnerability also raises questions about the security of AI agent frameworks that rely on API-based reasoning. Many popular agent architectures, including those used for coding assistants, customer service bots, and data analysis tools, process sensitive information through reasoning traces. If those traces can be extracted, the entire security model of these systems needs to be rethought.

The Distillation Angle

Model distillation, the process of training a smaller model to mimic a larger one, has been a concern for AI providers since they started offering API access. Companies like OpenAI and Anthropic have implemented various anti-distillation measures, including terms of service restrictions and technical safeguards.

This research shows those defenses are insufficient. By using the reasoning traces themselves as training data, an attacker can effectively distill the thinking process of a frontier model without needing access to its weights or training data. The smaller model learns not just what the frontier model says, but how it thinks.

For AI companies that have invested heavily in building expensive frontier models, this represents a direct threat to their business model. If competitors can extract the reasoning capabilities of these models through API manipulation, the competitive advantage of building larger, more capable models diminishes. The cost asymmetry is particularly stark: a frontier model might cost dollars per query, while the extracting model costs pennies.

The research also reveals a tension in how AI providers design their APIs. Reasoning traces are included in API responses because they make models more useful and transparent. Developers can see how the model arrived at its answer, which helps with debugging and trust. But that same transparency creates the vulnerability. Making reasoning traces available while preventing their extraction is a fundamentally difficult problem, and the current approach of relying on terms of service and technical obfuscation has proven inadequate. Some researchers have suggested that providers might need to offer different tiers of API access, with reasoning traces available only at higher privilege levels, but this would complicate the developer experience and could slow adoption.

What Happens Next

The researchers have disclosed the vulnerability to all three providers. OpenAI, Anthropic, and Google are expected to implement mitigations, though the architectural nature of the problem means a complete fix may require fundamental changes to how reasoning traces are handled in API responses.

One possible mitigation is to encrypt reasoning traces in a way that prevents smaller models from processing them, but this would require changes to the API protocol itself. Another approach is to add metadata that flags reasoning blocks as sensitive, preventing them from being passed between sessions. However, both solutions would require coordination across providers and could introduce new compatibility issues.

A more immediate fix might involve rate limiting or anomaly detection on API calls that contain reasoning blocks from other sessions. Providers could also implement watermarks in reasoning traces that make them harder to extract without detection. But each of these approaches has tradeoffs between security, performance, and developer experience.

The research team also suggested that providers could offer a “no-reasoning” mode for API calls where the user doesn’t need to see the model’s internal thinking. This would reduce the attack surface for applications that don’t require transparent reasoning, while still allowing it for use cases that benefit from it. The challenge is that many developers have come to rely on reasoning traces for debugging and quality assurance, so removing them entirely would break existing workflows.

In the meantime, organizations using AI agents should audit their API traffic logs and consider whether their session data might contain exposed reasoning traces. The fact that sensitive data can hide in internal reasoning blocks means that traditional security monitoring focused on outputs may miss the problem entirely.

The Bigger Picture

This research is a reminder that as AI systems become more capable, the attack surface they create grows in ways that don’t always match our assumptions. The hidden layers of model reasoning are now a security concern, not just a technical curiosity.

The industry needs to grapple with a fundamental tension: making AI models more capable often means giving them more internal reasoning capacity, which in turn creates more attack surface. The solutions to this problem will likely shape how AI APIs are designed for years to come, and they’ll require collaboration between security researchers, AI companies, and the developers who depend on these systems.

For developers building on top of AI APIs, this research is a call to audit how they handle session data and API traffic. The assumption that only the final output matters is no longer safe. Organizations that process sensitive information through AI agents need to treat reasoning traces as potentially sensitive data, applying the same protections they would to any other form of confidential information.

The broader lesson is that security in the AI era requires thinking about threats that didn’t exist before. Traditional cybersecurity frameworks weren’t designed to account for the possibility that a model’s internal thinking could be extracted through its own API. As AI becomes more deeply integrated into critical systems, the security community will need to develop new tools and frameworks to address these novel attack vectors. The window for doing so is narrowing, because the research is public and the attack is reproducible by anyone with standard API access.