All articles

NewsOctober 26, 20264 min read

Compaction smuggling: OpenAI reasoning traces extracted via API

Xint bypassed OpenAI’s defences for encrypted reasoning using compaction, enabling distillation. Technical details and what to ask your AI providers.

Green arrow-shaped road sign reading Data Loss Prevention, on a meadow under a cloudy sky

Research firm Xint published details on 26 October 2026 of a technique called compaction smuggling, which made it possible to extract the reasoning traces of OpenAI’s frontier models in plain text through its API. The technique bypassed the mitigations OpenAI had introduced in August for a similar problem. OpenAI confirmed the flaw, fixed it and paid Xint a 6,000-dollar bounty on 23 October 2026. The story was reported by SecurityWeek, CSO Online, The Hacker News and Infosecurity Magazine.

Background: encrypted reasoning and compaction

Reasoning models return, alongside the answer, their reasoning steps in encrypted form: the application sends them back to the model in subsequent requests, so the model keeps the continuity of its “thought” without the customer being able to read it. To avoid overflowing the context window, compaction compresses conversation history, tool calls and workspace state into a summary, which is also returned as an encrypted item.

According to an analyst quoted by CSO Online, compaction items are portable across models for a functional reason: they let agentic tools such as Codex switch models mid-session.

In August the paper Stealing Reasoning Traces from Proprietary LLM APIs (published on 10 August) showed that a frontier model’s encrypted reasoning could be replayed into a weaker model from the same provider and coerced into transcribing it. CSO Online lists possible consequences including large-scale data extraction, invisible prompt injections and malicious payloads embedded in public agentic rollouts; SecurityWeek also mentions extraction of personal data. OpenAI responded by blocking the replay of reasoning into a different model from the one that produced it.

How compaction smuggling works

According to Xint’s post, written by researcher Tim Becker and quoted by CSO Online, the attack has three stages:

  1. Capturing the reasoning: a task is sent to a reasoning model (Xint gives gpt-5.6-sol as an example), the encrypted reasoning is captured, the original task is removed from the history and the reasoning is kept verbatim.
  2. Shaping the compaction: the compaction is asked to place the reasoning as the value of a solution key in a JSON object, with every space replaced by a tab. According to Xint, this was enough to slip past OpenAI’s usage-policy classifiers.
  3. Transcription by another model: the encrypted compaction item, still portable, is sent to gpt-4.1 and gpt-4o with a request to output the input exactly as it is. The models complied; all that remained was to decode the JSON and restore the spaces.

The weak point, Xint explains, is that the August mitigation only blocked passing reasoning to a different model, while compaction runs on the same model that produced the reasoning. The attack worked at every reasoning effort level tested.

Becker told CSO Online that part of the timeline is unknown: OpenAI did not publish when it applied the fix and, unlike traditional patches, a model provider can make changes without any announcement. OpenAI did not respond to CSO Online’s request for comment.

Why it matters: distillation

The main risk highlighted by SecurityWeek is distillation: using an advanced model’s reasoning to cheaply train a rival model. SecurityWeek recalls the early-September advisory in which CISA (together with the NSA and FBI, according to an analyst quoted by CSO Online) attributed to DeepSeek, Moonshot AI, Alibaba, MiniMax, StepFun and Z.AI the extraction of billions of tokens, over millions of requests, from US models such as Claude, GPT, Gemini and Grok since at least late 2024.

For companies using the API the issue is not direct theft of their data, but a signal about the security model of AI platforms. CSO Online also points to the AWS case, where a bug fixed in April had to be fixed again in September.

Impact for European and Italian companies

The analysts interviewed by CSO Online agree on several points:

  • legitimate platform features, combined together, can bypass protections designed for a single attack path;
  • AI platform flaws arrive with no CVE, no advisory and no release notes: vulnerability management built on CVE feeds does not see them;
  • a vendor’s “fixed” often covers the reported case rather than the whole class of weakness; for this reason one analyst suggests assuming that any encrypted content returned by these APIs is readable.

For NIS2 entities, AI service providers fall within supply chain security (Article 21): they need the same clauses and checks as any other critical supplier.

What to do now

  1. Take inventory of applications that use reasoning model APIs, compaction or client-side conversation state, and of where these items are stored (logs, databases, queues).
  2. Treat encrypted reasoning and compaction items as sensitive data: same access controls and retention periods as plain-text content.
  3. Ask your AI providers how a fix was tested across connected features and whether a variant analysis was carried out: did they fix the reported case or the class of problem?
  4. Write into contracts an obligation to notify security issues and regressions of fixes.
  5. Assign someone to track researcher disclosures about the AI platforms you use, since they do not arrive as CVEs.
  6. Repeat your own tests after every fix announced by the provider, rather than relying only on its statement.
  7. If you expose models via API yourself, watch for extraction patterns (high volumes of systematic requests) and check that state objects sent back by clients cannot be reused outside their intended context.

Last updated:

Any questions?

Let’s talk about your company’s needs, with no obligation.

Contact us

Related articles