Researchers extract hidden reasoning from LLM APIs. Proprietary model internals are leaking.

You are querying a reasoning model through an API. The request comes back in under two seconds. Buried in the response, if the provider has not suppressed it, is a field that shows the model's work: the chain-of-thought trace, the intermediate steps, the hedging and backtracking before the final answer. Most engineers glance at it once and move on. Security researchers, according to a paper now circulating on Hacker News, treat it as an attack surface.

The research, published at stolen-thoughts.com, documents methods for extracting internal reasoning traces and model capabilities from proprietary LLM APIs. The concern is not theoretical. Reasoning traces expose how a model was trained to think, not just what it was trained to say. For a provider that has invested heavily in a custom post-training pipeline, that is commercially sensitive information. For a user whose system prompt is being processed, it is a potential privacy leak. Both problems are real, and neither has a clean fix.

A decision tree for teams building on top of proprietary reasoning APIs

The exposure varies depending on how you are using these APIs, and the right response is different in each case. Here is how to think through your situation.

If you are an enterprise team passing sensitive customer data through a reasoning model API, the first question is whether the provider exposes reasoning traces in the response at all. Some do by default, some require an opt-in parameter, and some suppress them entirely. Check the documentation for the specific model you are calling. For context, models like Claude and those behind the OpenAI API have different defaults on this, and those defaults can change between versions. If reasoning traces are returned and your payload contains PII or confidential business data, you should be treating the trace field with the same sensitivity as the main response.

If you are a developer building an agent pipeline where user-supplied text goes directly into the model context, prompt injection is the more immediate threat. The research covers this explicitly: a carefully crafted input can cause a model to include attacker-controlled content in its reasoning trace, which then leaks back to the caller. If X is that user input is passed without sanitization, do A: add a sanitization layer before the model call and never surface raw reasoning traces to end users. If Y is that your pipeline only processes inputs you control, the injection risk is lower, but the IP exposure concern still applies to your own system prompts. If Z is that you are evaluating a reasoning model's capability in a research or benchmarking context, the traces are often the point, and you can proceed with full awareness of what you are logging.

If you are an AI provider worried about competitors extracting your training signal through systematic API queries, the paper describes several fingerprinting approaches. The practical response is rate limiting on structured trace extraction patterns and monitoring for queries that look more like capability probes than production usage.

Why reasoning trace extraction is less dangerous than the IP theft framing suggests

Here is the argument against treating this research as urgent: reasoning traces are not model weights. Extracting a chain-of-thought trace tells you how the model approached a specific prompt. It does not give you the parameters, the training data, or the fine-tuning procedure. You cannot rebuild Claude Opus 5 from its reasoning traces any more than you can rebuild a human expert's judgment from a single explanation they gave a client.

The IP theft framing also relies on an assumption that is increasingly shaky: that reasoning behavior is actually proprietary. The gap between top models on most reasoning benchmarks has compressed significantly over the past eighteen months. DeepSeek V4 and GPT-5.6 are not running fundamentally different reasoning algorithms. They are running similar architectures with different training mixtures. If your competitive moat is a reasoning trace pattern rather than scale, infrastructure, or proprietary data, you have a fragile moat regardless of this research.

On the prompt injection angle, the attack requires the model to faithfully reproduce attacker content in its trace and then for that trace to be forwarded to a caller who should not see it. That is a multi-step failure chain. Any pipeline that forwards raw model internals to untrusted consumers already has deeper architectural problems than this paper can solve.

The more honest reading of this research is that it is useful for security teams doing threat modeling, not for anyone claiming the proprietary LLM business model is about to collapse from trace leakage.

What the Hacker News thread surfaced

"The interesting part isn't the IP concern, it's that reasoning traces leak information about the system prompt in ways that the main completion doesn't. You can often reconstruct significant chunks of a provider's system prompt just from trace analysis across a batch of queries." - HN commenter on the stolen-thoughts.com discussion thread

This is the sharper version of the vulnerability, and it deserves more attention than the IP framing. Providers building products on top of foundation models invest heavily in crafting system prompts: instruction sets that shape the model's behavior, enforce safety guardrails, define persona, and restrict topic scope. Those prompts are trade secrets in the same way that a SaaS company's business logic is a trade secret. If reasoning traces allow systematic reconstruction of those prompts through repeated querying, that is a meaningful attack on a product's competitive differentiation.

The HN thread also surfaced something the paper hints at but does not center: the problem compounds with agentic systems. A model taking multi-step actions generates far more trace data per session than a single-turn completion. More trace data means more signal for reconstruction. Teams building autonomous agents on top of APIs like those powering Devin or similar coding agents should think carefully about what gets logged and where, because the trace volume in agentic workflows is an order of magnitude higher than in standard completions.

A specific scenario: a B2B SaaS company using a reasoning model as a core feature

Consider a legal tech startup. They have built a contract review product on top of a reasoning model API. The system prompt is long: it instructs the model to identify specific risk clauses, apply the firm's risk scoring methodology, flag jurisdiction-specific issues, and output structured JSON. That prompt took six months and significant legal expertise to develop. It is, practically speaking, their product.

A competitor's developer signs up for a free trial. They do not try to brute-force the system prompt directly. Instead, they submit fifty contracts, each designed to probe a different edge case, and they collect the reasoning traces from each response. The traces show the model's internal deliberation: "this clause appears to be a limitation of liability, checking against the scoring rubric for tier-2 risk..." That rubric language did not appear in the final JSON output. It appeared in the trace.

After fifty queries, the competitor has a rough map of the scoring methodology. Not a perfect copy, but enough to inform their own prompt engineering. The startup's system prompt is partially reconstructed without the competitor ever seeing it directly.

This scenario requires the startup to be returning traces to the API caller, which is a configuration choice. But many developers do not audit this. They call the API, they get a response object, they parse the fields they care about, and they do not check whether other fields are being forwarded through their own stack to logs, to clients, or to third-party monitoring tools like LangWatch. That is where the leak actually happens, less often from a sophisticated attacker and more often from a developer who did not realize the trace field existed.

Steps to audit and harden your API integration against trace leakage

1. Log a raw response object from your model API call and inspect every field. Do not rely on documentation alone. Providers add and rename fields between model versions, and a field called reasoning, thinking, or internal_steps may appear without a changelog entry. As of August 2026, check this any time you upgrade to a new model version.
2. Search your codebase for every location where the full response object is passed downstream: to logging pipelines, to client-facing API responses, to third-party observability tools. Map the data flow before you assume traces are contained.
3. Explicitly strip trace fields before forwarding responses. Do not rely on the provider to suppress them. Write a response normalization function that whitelists the fields you intend to return and drops everything else. Something like sanitized = {k: v for k, v in response.items() if k in ALLOWED_FIELDS} is a starting point, though your implementation should be more explicit than a generic allowlist.
4. For system prompts that represent genuine IP, consider prompt obfuscation techniques. These are imperfect, but they raise the cost of reconstruction. At minimum, avoid using proprietary terminology or scoring rubric language directly in the prompt if that language is what you are trying to protect.
5. If you are running an agentic workflow with multi-turn reasoning, audit your logging retention policy. Traces from fifty-step agent runs are large and revealing. Treat them with the same retention controls you apply to database query logs.

Verification test: after implementing step three, make a live API call and print the full response object your application receives downstream of the normalization function. If you see any field you did not explicitly allowlist, the sanitization layer is not in the right place in your call stack.

A prediction for the next six months

By February 2026, at least one major foundation model provider will ship an explicit API parameter that gives callers fine-grained control over trace exposure: full trace, summary only, or suppressed. Right now this is handled inconsistently, sometimes through model-specific flags, sometimes through account-level settings, sometimes not at all. The research coming out of work like this will accelerate that standardization. If no provider has shipped a documented, stable trace-control parameter by that date, this particular security concern will fade into the background noise of LLM ops hygiene rather than driving any structural change. That is the falsifiable version of the claim, and it should be clear within six months which direction it goes.

In the meantime, the practical work is unglamorous: audit what your API responses actually contain, map where those responses travel, and treat reasoning traces as sensitive data until you have confirmed they are not. Teams already thinking carefully about what AI tools actually expose in production will find this a short checklist. Teams that have not started that conversation have a reason to start it now. For a broader look at how reasoning models compare on capability and transparency controls, the Claude vs Gemini comparison covers some of the relevant API-level differences.