HN Debrief

Stealing Reasoning Traces from Proprietary LLM APIs

  • AI
  • Security
  • Developer Tools
  • Open Source

The paper demonstrates a simple but damaging trick against “encrypted reasoning” features in proprietary LLM APIs. Frontier models from OpenAI, Anthropic, and Google return opaque blobs that preserve hidden chain-of-thought across turns. The researchers replayed those blobs into weaker sibling models that could still read the underlying plaintext, then prompted the weaker models to transcribe it. That exposed the stronger model’s hidden reasoning without directly breaking the stronger model’s safeguards. The authors say providers patched the issue after disclosure.

If you build on closed-model APIs, assume hidden reasoning artifacts can leak when providers support model switching or shared conversation state. Watch for provider changes that trade away portability, debugging visibility, or zero-data-retention features in order to close this class of hole.

Discussion mood

Interested and cynical. People thought the attack was clever but technically unsurprising, and many saw it as exposing weak product security plus a broader attempt by API vendors to hide useful internals and slow distillation.

Key insights

  1. 01

    Cross-model portability is the real vulnerability

    Keeping reasoning portable between models is what created this hole. If a user can start with a strong model and continue with a weaker one, some backend path must present the hidden reasoning in readable form to the second model. That makes fixes like stronger encryption or server-side storage mostly cosmetic. The clean fix is to bind traces to one model or drop them when switching, and that directly hurts common workflows like planning with one model and implementing with another.

    Expect providers to tighten model switching, not just patch crypto. If your product depends on swapping models mid-task, test fallback designs now in case hidden state no longer survives a downgrade.

      Attribution:
    • yojo #1
    • myworkaccount2 #1
    • supriyo-biswas #1
    • crabette #1
    • aix1 #1
    • dannyw #1
    • paxys #1
  2. 02

    Recovered traces undercut benchmark trust

    The interesting part was not just that traces leaked, but what they contained. Examples where a model states an answer before deriving it make benchmark performance look less like deliberate reasoning and more like retrieval from training exposure. Public evals such as AIME were treated as effectively expired once they circulate through GitHub and the wider web. The traces make that contamination easier to spot, even if the extracted text is not always exact.

    Do not treat public benchmark gains as clean evidence of better reasoning. Put more weight on private evals, fresh task sets, and tasks tied to your own production data.

      Attribution:
    • vhantz #1
    • Aurornis #1
    • AbhinavX #1
  3. 03

    The attack worked because it is embarrassingly simple

    Nothing exotic happened here. The provider decrypted or resolved the hidden reasoning as part of normal conversation handling, and the weaker model was simply persuaded to repeat it. The novelty is operational, not cryptographic. Useful traces came from stronger models with tighter refusal behavior, then got exposed by cheaper siblings with weaker guardrails. That simplicity is why people found the result both funny and alarming.

    When a secret must become model-readable during normal operation, treat the model itself as an exfiltration surface. Threat models for agent products should assume any hidden context visible to one model may be recoverable through another prompt path.

      Attribution:
    • andai #1
    • dgellow #1
    • dboreham #1
    • desterothx #1
    • aszen #1
  4. 04

    Zero data retention collided with hidden-state design

    The opaque blobs exist partly because providers want stateless APIs and zero data retention options while still preserving hidden reasoning across turns. That product goal pushed state out to the client in encrypted form. Several people pointed out that server-side storage would break zero-data-retention promises for enterprise customers, while client-side blobs created replay and leakage risks. This was not a random bug. It was a predictable consequence of trying to keep rich hidden state without keeping it.

    If you buy zero-data-retention features from LLM vendors, assume they come with awkward tradeoffs in how conversational state is represented and moved. Ask vendors exactly what hidden artifacts are returned to clients and how those artifacts are scoped across users, sessions, and models.

      Attribution:
    • Cynddl #1
    • cavisne #1
    • dboreham #1
    • Perseids #1
    • sandeepkd #1
  5. 05

    Once the model can read a secret, prompts can pull it out

    A few comments cut through the implementation details with a blunt security point. Any system that feeds secret text into an LLM while also accepting untrusted input has created an exfiltration game. The model does not need to perform encryption or key management. It just needs to be shown the plaintext somewhere in its effective context. From there, jailbreak pressure is enough. That framing makes this look less like an LLM-specific oddity and more like a classic secret-handling mistake in a new wrapper.

    Do not rely on prompt instructions to keep sensitive context hidden once it enters the model context window. Separate secrets from model-readable context wherever possible, especially in agent loops that accept user-controlled content.

      Attribution:
    • tanh #1
    • 8note #1
    • paxys #1 #2
  6. 06

    Reasoning traces are useful but not sacred ground truth

    Recovered traces are informative, but they are not a perfect window into cognition. One comment pointed out you still cannot infer the reward model, verifier, or post-training pipeline from these snippets. Another noted that “trace inversion” and related methods can produce coherent chain-of-thought that overlaps with true traces without being the same thing. Combined with the paper’s own examples of vendor summaries cleaning up messy reasoning, the practical lesson is that chain-of-thought is a noisy artifact, not a canonical explanation.

    Use reasoning traces as debugging evidence, not as a definitive audit log of why a model acted. For high-stakes workflows, validate behavior with outputs, tool calls, and reproducible test cases rather than trusting the trace narrative alone.

      Attribution:
    • elzbardico #1
    • dannyw #1
    • nervai #1
  7. 07

    The leaked traces confirm compressed internal dialects

    Several people noticed the exposed reasoning had the same clipped “grug speak” style seen in open models and prior public examples. That matters because it suggests labs really are optimizing internal reasoning for token efficiency, not writing polished hidden essays and then concealing them. The style also made the leak feel authentic to practitioners who had seen similar terse traces from Moonshot, Qwen, Muse, and GPT open releases.

    Do not assume internal chain-of-thought will be human-readable prose if you ever gain access to it. Tooling that inspects reasoning should be built for terse, compressed, and partially telegraphic text.

      Attribution:
    • vhantz #1
    • wren6991 #1
    • kgeist #1
    • lukewarm707 #1
    • gaigalas #1

Against the grain

  1. 01

    Most builders do not need raw reasoning

    One strong minority view was that hidden reasoning has become a distraction for product teams. Full visibility sounds empowering, but building custom reasoning control planes, trace views, and intervention logic can eat the entire engineering budget while adding little to the actual business outcome. If providers keep making the black box cheaper and better, many teams are better off focusing on tools, environment design, and application logic instead of fighting for every internal token.

    Be honest about whether trace access would change your product decisions or just create more observability work. If the latter, prioritize stronger evals and better tool interfaces over deep chain-of-thought instrumentation.

      Attribution:
    • bob1029 #1
  2. 02

    Model-specific keys could have been enough

    A simpler reading held that the main failure was shared replay compatibility across models. If each model had accepted only its own encrypted trace format or keys, the strong-to-weak downgrade path would have died immediately. That does not solve every exfiltration path, but it would have blocked the exact attack described without redesigning the whole product.

    When you see hidden state reused across security boundaries, ask first whether unnecessary compatibility is widening the blast radius. Narrow scoping can remove entire attack classes even if it does not solve the deeper problem.

      Attribution:
    • simonw #1

In plain english

AIME
American Invitational Mathematics Examination, a math contest whose problems are often used as AI reasoning benchmarks.
API
Application Programming Interface, the set of software hooks a platform exposes so developers can build on its features.
chain-of-thought
A model’s intermediate reasoning text, often hidden from users, that shows the steps it took before answering.
distillation
Training a smaller or cheaper model to imitate the outputs or behavior of a stronger model.
jailbreak
A prompt or technique used to make a model ignore its normal safety or policy restrictions.
LLM
Large language model, a machine learning model trained to predict the next token in text.
stateless API
An API design where each request is self-contained and the server does not keep conversation state between calls.
zero data retention
A service setup where the provider promises not to store customer data after processing it.

Reference links

Core paper and related writeups

Distillation and policy framing

Social posts and examples

Legal background references

  • Fair use overview
    Linked in the side discussion about whether commercial AI training can qualify as fair use
  • Theft of services
    Used as an example in the argument over whether non-physical things can be 'stolen' in legal usage
  • Identity theft
    Another legal example used in the same terminology debate

Side references

  • B-4 on Memory Alpha
    Humorous Star Trek reference in a comment about choosing between stronger and weaker models mid-task
  • softcane/hamza
    Repository mentioned by a commenter experimenting with blocking opaque reasoning blobs at an ingress path