OpenAI Model Distillation: What the Campaign Revealed

OpenAI model distillation became a concrete security story on September 30, when OpenAI disclosed a coordinated campaign to extract protected reasoning through model interactions. The disclosure concerns hidden reasoning reaching visible output, not a database intrusion or direct access to stored customer chats. For API teams, the useful question is how reasoning state moves between requests.

OpenAI model distillation: the disclosed campaign

OpenAI links the core cluster to people associated with Moonshot AI, which develops Kimi, while leaving the full operator structure unresolved. It reports 16,000 requests from more than 4,000 users during July 24–25 spikes and disruption on July 28. Those figures count attempted extraction, not successful leaks.

The official disclosure describes encrypted reasoning transferred between conversations and interactions that sought to expose it. OpenAI says it strengthened boundaries across users, workspaces, organizations and model families, closed an encrypted-reasoning replay path, added streaming checks and restricted accounts. That makes encrypted reasoning security a state-boundary issue as well as an output-monitoring issue.

Reasoning continuity is different from readable text

The reasoning guide describes reasoning items as opaque: continuity can carry forward without returning the underlying reasoning text. In stateless Responses requests, including requests with store: false or Zero Data Retention, output reasoning items include encrypted_content by default. The legacy include option remains accepted, but is no longer required.

The distinction matters when an application separates its user interface from its conversation storage. A visible answer is what a person reads. A replayable output item is what the application may need for another request. Treating both as an ordinary text transcript loses that distinction. Our recommendation is to name these two paths separately in the application design and test them separately.

Developers can control available reasoning context with current_turn, all_turns or the model default. The guide identifies GPT-6.1 Sol as supporting all_turns; earlier reasoning must actually be available for that setting to matter. It does not generate missing history. For a coding assistant, the difference is between continuing a specific investigation and opening an unrelated task with no prior reasoning to reuse.

The site’s API guide provides the broader request-building context. This incident analysis focuses on the state carried by a request, not choosing a model or estimating its token bill.

Compaction makes a smaller context, not a public summary

The compaction documentation explains two ways to shorten long-running conversations. Server-side compaction uses a configured threshold during Responses calls and emits an encrypted item carrying useful prior state. A separate compact endpoint returns a replacement context window. Both formats preserve continuity without making their opaque content human-readable.

These modes have different handling instructions. For stateless server-side chaining, developers append output items, including the compaction item, to subsequent input. For standalone compaction, the returned window is the next context and should be passed onward without pruning it. A compacted window can contain retained items as well as the encrypted item; it is not necessarily one summary string.

For a support assistant, this is an easy distinction to overlook. A customer-facing case summary might be suitable for an email. A compacted API context belongs to the application’s continuation mechanism. Our design recommendation is to give each its own field and lifecycle rather than making one “summary” slot serve both purposes. That makes review and debugging more concrete: engineers can identify which object was displayed and which object was replayed.

Data retention answers a separate operational question

The OpenAI data controls guide separates abuse-monitoring logs from application state. API data is not used for training by default unless a customer opts in. Default abuse-monitoring retention is up to thirty days, with documented exceptions; application-state retention depends on the endpoint and enabled features.

Zero Data Retention and Modified Abuse Monitoring require approval. Zero Data Retention treats the Responses store parameter as false, but endpoint and feature limitations still apply. Sending a request with store: false is therefore not the same as saying every service involved has zero retention. The guide also states that data sent to third-party MCP services follows their own retention policies.

An application review should consequently have two questions, not one. First, what can a request render or reuse? Second, where does the application and each connected service retain data? A good answer to the second question does not replace investigation of the first. For personal account activity, our earlier coverage of ChatGPT security history covers a different surface: inspecting sign-ins rather than managing API continuation objects.

A practical state-boundary review for teams

Here is a proposed review exercise, not an OpenAI-mandated migration. Use synthetic records for two fictional customers, each with a separate project and conversation. Trace the application path from a response through storage, compaction and the next request. Record the owner, conversation identifier, object type and destination at each step. The useful deliverable is a small map of state movement, not an attempt to reconstruct hidden reasoning.

Then exercise the application’s normal task-switching and sharing flows. Check whether a newly opened task receives only the state intended for that task, whether a share operation exports the human-facing transcript rather than the replay envelope, and whether diagnostic logs clearly distinguish readable messages from opaque objects. These checks target application plumbing; they do not measure the success rate of the disclosed campaign.

Finally, make the finding actionable. Assign an owner for any ambiguous storage field, add a regression check for an unintended cross-customer reference, and document which continuation pattern the application uses. Teams already following a coherent state model can record that result without inventing a new migration. Teams with a single overloaded transcript field have a specific place to inspect. This is the practical value of the disclosure: a reason to review existing state boundaries, with concrete objects and flows to examine.