OpenAI Discloses Model-Distillation Operation Involving 15,000 Users: Model Capabilities Are Entering the “Intelligence War”

OpenAI has disclosed an organized model-distillation campaign that lasted nearly a month: more than 15,000 users participated in similar prompt-based operations. On July 24 and 25 alone, more than 4,000 users initiated approximately 16,000 related requests.

On September 30 local time, OpenAI published an article on its official website stating that the campaign first appeared on July 1, 2026, and gradually evolved into a large-scale, coordinated effort to extract model outputs. OpenAI believes that the campaign’s core group was associated with Moonshot AI, the developer of Kimi, while acknowledging that it currently cannot confirm whether all operators belonged to the same organization or entity.

OpenAI said the activity had been fully blocked by July 28. The company stated that the operators did not break encryption systems, breach databases, or directly access stored user conversations. Instead, they used another method closer to “engineered extraction”: by carefully designing multi-turn model interactions, they caused reasoning information that should not have been directly exposed to be reproduced in visible form, which could then be used to train, evaluate, or improve other models.

This was not a traditional hacking intrusion, but it exposed a more difficult problem: when a model itself becomes a capability interface accessible through an API, competitors may not need to obtain weights, source code, or databases. By asking enough questions, systematically enough, they may be able to reconstruct a model’s behavioral characteristics.

What Exactly Happened

OpenAI defines the activity as “adversarial distillation.” Put simply, ordinary distillation uses a more capable teacher model to generate data and then trains a smaller, cheaper, or more easily deployable student model. Adversarial distillation is more like treating the teacher model as a remote laboratory: through automated scripts and specialized prompts, operators systematically collect its response patterns, reasoning paths, refusal boundaries, and strategies for handling complex tasks.

This approach does not necessarily require obtaining the original model’s complete chain of thought. As long as enough input-output pairs are collected, researchers can train a model to imitate the teacher model’s style, knowledge organization, and decision distribution. In scenarios such as code generation, mathematical reasoning, tool use, and safety refusals, the more output samples that are collected, the more likely the student model is to approach the teacher model on specific tasks.

The activity disclosed by OpenAI was clearly more organized than ordinary sporadic usage. The company observed that the number of requests initially seen on July 1 was not high. On July 24 and 25, however, the relevant traffic suddenly increased, with more than 4,000 users initiating approximately 16,000 requests using specific extraction patterns over the two days. Continuing its investigation, OpenAI found similar prompt activity across a larger user cluster, involving more than 15,000 users.

An important qualification is needed here: the 16,000 requests represent identified extraction attempts, not successful retrievals of valid reasoning content in every case. OpenAI’s public disclosure also did not explain how much usable training data these requests ultimately generated, nor did it identify the name, scale, or performance changes of any distilled model.

Therefore, the more accurate description at this stage is that OpenAI discovered and blocked a large-scale, suspected coordinated campaign aimed at extracting model capabilities, not that it has proven that a particular model fully replicated GPT’s capabilities.

Key Technology: Not “Stealing a Database,” but Manipulating Model Interactions

OpenAI specifically emphasized that the operators did not break encryption, breach databases, or read users’ historical conversations. This is important because it determines the nature of the incident.

If an attacker directly obtains a database, that constitutes a typical data breach. If an attacker designs an interaction process through a model interface that causes the model to rewrite content that was originally protected into visible text, that constitutes application-layer abuse and information extraction. The latter does not necessarily require a system vulnerability; it relies more on prompt design, account scale, and automation capabilities.

According to the public disclosure, the operations involved a cross-conversation processing method: first obtaining a protected encrypted or encoded reasoning fragment in one conversation, then copying that content into another conversation and asking the model to decrypt, transcribe, or explain it. In other words, the attackers did not directly break OpenAI’s encryption mechanisms. Instead, they exploited the model’s ability to process information across different contexts, turning the protection layer into material that the model itself could interpret.

This can be understood as a “remote black-box experiment.” Attackers cannot see the model’s internal parameters, but they can continually change their questions, observe the outputs, and adjust subsequent requests based on those outputs. A single call yields very little information, but when requests are split up, parallelized, and executed simultaneously by thousands of accounts, the model’s boundaries may gradually be mapped.

This is particularly sensitive for reasoning models. When answering complex questions, models often generate richer intermediate information than the final answer alone, including task decomposition, error correction, tool selection, and safety judgments. If these internal processes are extracted at scale, trainers obtain not only “answer data,” but also demonstration data showing how the model solves problems.

Of course, hidden reasoning is not equivalent to source code that can simply be copied. Even with large numbers of reasoning samples, it is impossible to straightforwardly reconstruct the original model’s parameters, training recipe, and infrastructure. From an engineering perspective, however, such samples can significantly reduce the cost of training a new model, especially when used to construct high-quality supervised fine-tuning data and reinforcement-learning feedback data.

Why Model Companies Are Increasingly Concerned About Distillation

Model distillation itself is not a new technology, and it cannot simply be equated with theft.

Over the past several years, academia and the open-source community have consistently used teacher models to generate data and help train smaller models. Many open-source projects improve model performance on specific tasks through synthetic data, teacher-model scoring, or automatically generated instructions. Even within commercial companies, distillation is an important method for reducing inference costs, compressing model size, and transferring capabilities.

The controversy arises in three areas.

First is the boundary of authorization. A developer using a public interface to generate a small amount of experimental data is clearly engaged in a different activity from an organization that operates thousands or tens of thousands of accounts to continuously extract a competitor’s model capabilities. The former may constitute normal research and development, while the latter may violate terms of service and even raise contractual, intellectual-property, and unfair-competition concerns.

Second is the transfer of safety capabilities. Model outputs contain not only knowledge, but also refusal logic, risk identification, and boundaries around tool use. If a new model absorbs large amounts of reasoning data from a highly capable model without simultaneously building safety controls of a comparable level, capability transfer may occur before safety transfer.

Third is the changing competitive landscape. Training a frontier model can be extremely expensive, but bulk data collection through an API can provide, at relatively low cost, a set of “behavioral samples” that can be used for fine-tuning and evaluation. This may lead model companies to view API access itself as a core asset rather than merely an entry point to a cloud service.

OpenAI stated that adversarial distillation could create security and national-security risks because extracted reasoning information could be used to train another model, which might not inherit the original model’s safety protections. As models become more capable in dual-use fields such as cybersecurity, biotechnology, and automated research and development, this issue will become increasingly sensitive.

There is a real basis for this assessment, but its boundaries must also be maintained. Public information currently cannot prove that this activity has already caused a particular model to acquire dangerous capabilities, much less support the conclusion that a company has fully copied an OpenAI model. OpenAI disclosed the request patterns it observed, the actions it took, and its attribution assessment. The specific data volume, final use, and actual effects remain undisclosed.

Pointing to Moonshot AI, but Attribution Remains Limited

OpenAI said that after its investigation, it concluded that the core group behind the campaign was associated with Moonshot AI. Moonshot AI developed the Kimi series of models and is one of China’s leading large-model companies.

However, OpenAI used wording such as “associated with relevant individuals” and “the core group involved in the activity,” rather than announcing that it had confirmed the operation was directly conducted by Moonshot AI. The company also explicitly stated that it did not know whether all of the operators observed during the relevant period came from the same entity.

This distinction cannot be overlooked. Large-scale API abuse may involve organizational accounts, proxy services, shared keys, automated scripts, and third-party relay platforms at the same time. Traffic patterns can help identify common prompt templates, request timing, and infrastructure characteristics, but they may not be sufficient on their own to prove the ultimate controlling party.

From the perspective of industry competition, OpenAI’s decision to disclose the incident at this time was not merely intended to explain a single account-blocking action. Over the past year, disputes over distillation involving Chinese model companies such as DeepSeek, Moonshot AI, and MiniMax have continued to intensify. U.S. model companies have repeatedly accused some competitors of using automated methods to call their models and obtain training data.

At the same time, distillation is indeed a long-established technical path in global model development. Technologies including data synthesis, teacher-model labeling, and behavioral imitation are not exclusive to any one country or company. The real questions are not whether distillation exists, but what data is being used, whether authorization has been obtained, whether the scale of usage constitutes systematic copying, and whether the new model has adequate safety capabilities.

If these questions are directly framed as technological accusations between nations, the technical facts may be diluted. For developers, the most valuable distinction remains between three levels: demonstrable API abuse, attribution judgments made by companies based on logs, and model capability-transfer results that still require external verification.

Measures Taken by OpenAI

OpenAI said it responded to the campaign through account enforcement, technical controls, and coordination with partners. The specific measures included:

• Banning or restricting accounts identified as fraudulent;
• Strengthening registration procedures and infrastructure controls to reduce the scope for bulk account creation;
• Expanding monitoring of related networks and account clusters;
• Closing a channel that could be used to replay protected reasoning across conversations and recover it;
• Adding checks for streaming output to intercept information that could leak hidden reasoning;
• Working with third-party service providers to identify and disrupt related accounts;
• Sharing relevant information with industry partners through the Frontier Model Forum.

This approach shows that defending against model distillation cannot rely on a single filter. Individual account bans are easy to circumvent. Effective defense requires simultaneous monitoring of account registration, request frequency, prompt structure, cross-user relationships, workspace associations, network egress, and calling behavior across model families.

For API platforms, risk identification also cannot focus only on requests per minute. A low-frequency, long-running automated task may look more like a genuine data-collection process than a short-lived spike. Multiple accounts using highly similar prompt templates may provide more useful signals than the call volume of any single account.

This also means that legitimate developers may face greater verification costs. Batch evaluation, data generation, model comparison, and agentic workflows can naturally produce large numbers of similar requests. If a platform simply increases the intensity of its controls to prevent distillation, legitimate research teams will almost inevitably be caught in the process.

A more reasonable direction is layered governance: add rate limits and secondary verification for high-risk behavior, provide auditable batch-task channels for enterprise workspaces, impose stricter protections on sensitive reasoning content in model outputs, and establish clear authorization mechanisms for compliant research. Otherwise, platforms may ultimately be left with only two states: exposing too much capability or turning APIs into gates that are difficult to use.

What This Means for Developers

This incident will not change the basic way developers call models today, but it will change how platforms view certain usage patterns.

First, when generating training data at scale, developers need to incorporate authorization and intended use into the project design. They should not assume that “the model can answer” means that the answer can be collected indefinitely and used to train a competing model. Requests involving hidden reasoning, system prompts, safety policies, and internal model behavior carry clearly greater risks than ordinary content generation.

Second, developers should avoid treating hidden content in model outputs as a stable interface. Model providers may change reasoning visibility, streaming output, and context-isolation policies at any time. Building an automated collection process around such content may violate terms of service and will also cause a training pipeline to depend on unstable behavior.

Third, enterprises need to reassess their API key and account systems. Large-scale distillation campaigns often depend on account clusters, shared keys, and proxy layers. Once a key is leaked or shared by multiple people, it becomes difficult for platforms to distinguish legitimate business activity from abnormal collection. The enterprise itself may also be rate-limited or banned because of its association with related accounts.

Fourth, model evaluations should retain interpretable call records. The purpose of each call, input template, data source, version number, and output-processing method should all be traceable. In future platform risk assessments, compliance reviews, or internal incident investigations, simply saying “we were just testing” will not be sufficient.

The same applies to developers using model aggregation APIs. Whether the entry point is an OpenAI-compatible interface, a third-party gateway, or an internal enterprise proxy, model providers’ terms of service and risk-control rules do not disappear merely because an additional relay layer has been added. Platforms need to clarify which calls constitute normal evaluation, which behaviors may be identified as cross-model extraction, and provide customers with audit and appeal mechanisms.

Model Capabilities Are Becoming a New Security Boundary

The most noteworthy aspect of this incident is not the number “15,000 users” itself, but the way the object of model companies’ defenses is changing.

In the past, AI safety focused primarily on whether models would produce harmful content, leak personal information, or be vulnerable to prompt injection. Now, model providers must also consider whether attackers can systematically measure model capabilities through large numbers of ordinary requests, combine seemingly independent accounts into a collection network, or use collaboration between models to move protected information from one interface to another.

These attacks do not necessarily leave the traces associated with traditional intrusions. There may be no malware, database download, or obvious exploitation of a system vulnerability, only large numbers of seemingly “legitimate” conversational requests. Model platforms need to move from content safety toward behavioral safety, and from judging individual requests toward analyzing correlations across accounts, organizations, and models.

For the industry as a whole, OpenAI’s disclosure of this incident may also encourage more platforms to share threat intelligence. Bot fingerprints, abnormal prompt patterns, account-cluster characteristics, and cross-service calling relationships could all become new sources of defensive data. But intelligence sharing must have clear boundaries. Not every high-frequency user should automatically be treated as an attacker, and unverified attributions should not be circulated as facts.

A more realistic outcome may be that frontier-model APIs gradually introduce identity verification, organizational authentication, tiered rate limits, and usage restrictions. The era of anonymous, low-cost, large-scale access is tightening. The impact may be limited for individual developers building prototypes, but for teams that need to generate millions of training samples or continuously run automated evaluations, compliance, auditing, and cost will become part of model selection.

OpenAI said the campaign had been blocked by July 28, but investigation and mitigation work are continuing. Whether it actually caused a transfer of model capabilities, whether Moonshot AI will respond, and whether other model providers have encountered similar activity remain to be seen.

What is certain is that model distillation has evolved from a training technique into a platform-security and industrial-competition issue. The next round of model competition will be determined not only by parameter counts and benchmark scores, but also by who can better protect their capabilities, identify abnormal usage, and find a workable balance between open APIs and risk control.

Sources

• IT Home: OpenAI Says It Encountered Organized Distillation and Points to Moonshot AI — Reports on the timeline, request volume, and attribution information disclosed by OpenAI.
• OpenAI: Disrupting a coordinated model-distillation campaign — OpenAI’s official statement, including its definition of adversarial distillation, response measures, and risk assessment.