A valid API key tells you which credential was used. It does not tell you whether the caller is using the responses for an approved purpose. That distinction matters when a customer can turn ordinary model responses into training data for another model.
On September 8, 2026, NSA, CISA and the FBI released an advisory on what they describe as large-scale, unauthorized model distillation campaigns. The agencies attribute the activity to DeepSeek, Moonshot AI, Alibaba, MiniMax, StepFun and Z.AI. They report billions of tokens collected through millions of exchanges since at least late 2024. Those are the agencies’ findings; Oktsec has not independently verified the attribution or volume. Read the advisory, pages 1–3.
For model providers, the immediate concern is the collection of outputs to reproduce capabilities they restrict. For companies that use models through agents, the report raises a related operational question: can you tell who is making requests, where those requests go and whether the route is allowed?
What distillation does
Distillation uses a model’s outputs or other training signals to train another model. In a simple setup, a larger model produces examples and a smaller model learns from them. The result may be cheaper or faster to run for a particular task.
Consider a support team that wants a small model to classify incoming tickets. With the necessary permissions and data protections, it could use a larger model to label examples, review those labels and train a smaller classifier. That is a legitimate use of distillation.
The advisory concerns obtaining restricted capabilities through unauthorized access and evasion of provider controls. Distillation itself is an established research technique, which the agencies explicitly acknowledge. Advisory, page 1.
This method does not require stealing the original model’s weight files. The training material can be the answers the service returns. Learning from those answers also does not guarantee a copy of the original model or its full performance.
One operator, many routes
The advisory describes requests spread across native APIs, cloud platforms, aggregators and proxy services called “transfer stations.” It also describes account pools, removal of identifying metadata and switching between routes when access is blocked. Each provider may see only part of the activity. Advisory, pages 11–13.
For a simple example, imagine a service allows each account a fixed daily volume. One account asking coding questions stays below its limit. Several other accounts do the same. Viewed separately, they look like ordinary customers. If one operator controls them all and collects the answers into the same training pipeline, the combined activity tells a different story.
A per-account limit still constrains usage. It just does not establish who controls the accounts or what happens to the answers. A prompt filter has a similar limit: a coding question can be harmless in content while contributing to an unauthorized collection effort.
Volume is not proof
The agencies flag new accounts that immediately consume their full allowance, sustained activity with no idle periods, coordinated behavior across accounts and abrupt changes in identifying metadata. They recommend stronger account verification, usage controls and information sharing across providers. Advisory, pages 11–15.
These signals need a baseline. An approved evaluation team might run a large batch overnight. A production service might run continuously. Blocking either solely because it uses the API heavily would punish expected behavior.
A provider investigating an alert should compare the activity with the customer’s stated use, account history and related events. Can the customer explain the workload? Does usage match the approved arrangement? Do changes in accounts, routes and timing point to a common operator? Multiple signals give the investigator something to examine; a request count alone cannot settle the question.
The report also discusses attempts to elicit reasoning. An explanation returned by a model is observable output. It should not automatically be treated as a faithful record of the model’s internal reasoning. An investigation needs to distinguish what a caller tried to obtain from what the service actually returned.
When the provider fails
A company using an AI assistant is in a different position from the provider whose model is being queried for training data. The advisory does not establish that every enterprise running agents faces the same extraction campaign.
But the routing problem is worth testing in your own environment. Consider a finance assistant approved to send contract text to one model provider. That provider becomes unavailable. The assistant finds an aggregator offering access to a similar model and tries to send the contract there instead.
The task has not changed. The destination has. The original approval does not automatically cover the aggregator, its handling of the data or the account used to access it. This is a hypothetical agent failure, separate from the campaigns described in the advisory.
The allowed response should be defined before the outage: retry within a limit, use an explicitly approved fallback, or pause for review. If no alternate destination is approved, completing the task is not a reason to send the document elsewhere.
Test the actual network request. An instruction telling the agent to use approved providers is not enough if a tool can still reach any address. Check the configured proxy or gateway, direct SDK calls, shell access and other routes available to that workload. A control can only enforce the traffic that reaches it.
Silent downgrades
One recommendation in the advisory deserves particular care: model providers may alter or degrade responses to requests they identify with high confidence as malicious distillation. That recommendation addresses a provider defending its service. Advisory, pages 13–14.
We would not carry it over automatically to an enterprise agent. Suppose a contract review workflow quietly receives a less capable response after a control flags its request. The next step might still treat that response as a completed review. The workflow now has a quality change that its owner cannot see.
For that workflow, an explicit refusal or a pause for review may be easier to handle safely. The team should know when a control changes the outcome, and test how the application responds.
Evidence worth keeping
In the finance example, a useful record would identify the agent and its owner, the intended task, the attempted destination, the credential reference, the policy version and the decision. It should also show whether the request was sent, blocked or held for review. The credential reference should identify the credential without exposing its secret value.
Do not collect every contract, prompt and response by default just to make the log more detailed. Decide which metadata is enough for routine review, when an investigator needs content and who can access it. Set retention periods around that purpose. Logs containing customer documents become another sensitive system to protect.
Signed records can help detect changes to the evidence you have. They do not prove that every request was captured. A complete investigation also needs to account for missing records and routes that bypassed the control. We explain that distinction in our guide to verifying action evidence.
Three checks before rollout
- Make the approved provider unavailable. Confirm that the workload uses only an approved fallback or stops. Check where the request actually went.
- Change the credential. Confirm that the agent remains identifiable and cannot escape workload-level limits simply by switching keys.
- Try a direct route. In an authorized test environment, check whether an SDK, shell command or alternate tool can bypass the intended enforcement point. Document the paths that remain outside coverage.
These tests examine your agent deployment. They do not establish whether a model provider is facing a distillation campaign. That requires provider-side investigation and, where appropriate, coordination across services.
Start with one workflow that handles sensitive data. Name its owner, list its approved destinations and decide what should happen when those destinations fail. Then run the failure case and inspect the result.