Detecting and Preventing Distillation-Style Model Extraction from LLM APIs

1. Getting the Terms Straight: Distillation Is Not a Slur

Knowledge distillation is a standard paradigm for model compression and transfer. In practice, distillation methods are usually grouped into three categories, based on how much of the teacher’s signal is available:

• Logits-based distillation: Requires the teacher model’s full probability distribution and aligns soft labels with KL divergence. This approach only works in settings where token-level probability outputs can be obtained.
• Response-based distillation: Uses only the text generated by the teacher model as supervised data, either for SFT or to construct preference pairs. In black-box API settings, this is the only viable path.
• Feature- or intermediate-representation-based distillation: Requires model weights or internal activations. This usually involves model theft rather than API call theft.

The key point is this: response-based distillation cannot be distinguished from ordinary API use on a single request. A request like “write a quicksort and explain its complexity” could come from a developer debugging code, or it could be one step in a data production pipeline. The focus of compliance disputes has never been whether calls were made, but rather authorization, scale, and purpose: whether the terms of service were violated, whether geographic and identity restrictions were circumvented, and whether outputs were systematically fed back into a competing model’s training pipeline.

One publicly disclosed case cites roughly this scale of activity: 150,000 to 13 million interactions per individual lab, for more than 16 million calls in total, from about 24,000 accounts (figures are illustrative of scale only). The alleged behavior patterns include large-scale repeated structured prompts, concentrated requests for reasoning, agentic, and coding capabilities, attempts to obtain the reasoning process, and the use of proxy networks to evade regional restrictions. These are one-sided claims made by the vendor and have not been independently verified. From an engineering perspective, they should be treated as “hypotheses to be verified,” not as established conclusions.

2. Why the API Is Inherently a Low-Cost “Capability Transfer Channel”

To understand detection design, start with the attacker’s cost structure:

1. Outputs are already labeled data. Traditional distillation requires building your own teacher. Commercial APIs already have the teacher deployed, so the attacker only pays token costs.
2. Prompt templates are easy to enumerate. To cover a capability such as code generation, you only need a few hundred templates combined in a Cartesian product. The marginal cost is minimal.
3. The task distribution is controllable. Attackers can deliberately sample high-value “capability slices,” such as chains of reasoning, multi-step tool calls, and long-context summarization, without caring about general conversational quality.
4. Accounts can be registered in bulk. Splitting call volume across cheap or trial credits to keep each account’s behavior below thresholds is a standard evasion technique.

The implication is that any rate limiting based on the absolute call volume of a single account is easy to bypass. Detection must therefore shift to a combination of signals: cross-account shared origin, request content structure, and output consumption patterns.

3. Designing the Detection System: Five Layers of Signal and Scoring

3.1 Transport and Identity Layer: Establishing Shared-Origin Evidence

Collect request fingerprints and perform entity resolution: clustering of account registration times, reuse of payment methods and card BINs, egress IPs and autonomous systems, proxy and datacenter network ranges, TLS fingerprints and HTTP header order, client language and SDK version, and temporal patterns (whether the activity runs 24/7 without breaks or follows a strict cron schedule). Individual signals are weak. But when many accounts show a high degree of consistency across the same set of weak signals, the false positive rate drops rapidly.

3.2 Prompt Structure Layer: Template-Skeleton Clustering

Collapse the variable slots in prompts, keeping only the skeleton, then apply near-duplicate clustering. This is the most effective way to identify “data production pipelines.”

import hashlib, re
def normalize_prompt(text: str) -> str:
    t = text.strip().lower()
    t = re.sub(r"```.*?```", "<code>", t, flags=re.S)  # collapse code blocks
    t = re.sub(r"[\"'“”‘’].*?[\"'“”‘’]", "<str>", t)   # collapse string literals
    t = re.sub(r"\d+(\.\d+)?", "<num>", t)              # collapse numbers
    t = re.sub(r"\s+", " ", t)
    return t
def template_id(text: str, n: int = 2048) -> str:
    return hashlib.sha1(normalize_prompt(text)[:n].encode()).hexdigest()[:16]

At the account or account-cluster level, track the number of distinct templates, the share taken by each template, the template coverage curve (whether new templates grow linearly with call volume), and the distribution of MinHash similarities between templates. The key indicator is “highly converged templates combined with constantly changing task content.” A normal developer will reuse templates, but will not run tens of millions of calls on a few dozen skeletons within a few weeks.

3.3 Output Consumption Layer: How It “Eats” the Results

This is the dividing line between “use” and “collection”:

Behavior	Leans toward normal use	Leans toward data production
max_tokens per request	Close to actual business needs	Frequently maxed out; seeks long outputs
n / best_of parameters	Usually 1	Repeatedly takes multiple candidates to filter
Sampling temperature	Fits business needs	High-temperature exploration or repeated resampling to accumulate samples
Requests for reasoning process	Occasional troubleshooting	Systematic, full-scale requests
Multi-turn context	Real follow-ups and corrections	Context independent each turn, no conversational continuity
Failure retry semantics	Retry after fixing the input	Identical replay, only switching accounts or egress

3.4 Capability-Targeting Profile

Tally the distribution of requests by task tag (reasoning, coding, tool calling, long-document summarization, multilingual, structured extraction) and compare how far it deviates from the platform’s overall traffic baseline. When the capability distribution of a cluster’s traffic is significantly skewed toward a few high-value tags and does not match its declared business use case, the likelihood of targeted extraction rises sharply.

3.5 Scoring and Tiered Response

Don’t rely on point-in-time bans. Use weighted scoring with tiered actions:

SIGNALS = {
    "template_convergence":     0.25,  # highly converged templates
    "account_cluster_identity": 0.25,  # same-origin across accounts (identity/network/patterns)
    "capability_targeting":     0.20,  # capability mix diverges from declared business
    "output_hoarding":          0.15,  # max-length outputs + multi-candidate resampling
    "reasoning_probe":          0.10,  # systematic requests for reasoning traces/probability distributions
    "region_or_proxy_evasion":  0.05,  # evading regional restrictions
}
def risk_score(f: dict) -> float:
    return round(sum(w * float(f.get(k, 0.0)) for k, w in SIGNALS.items()), 3)
# Response ladder: monitor -> throttle/downgrade -> enforce identity and purpose verification -> freeze -> legal action

Thresholds must be derived by regressing on historically labeled samples, and human review must be kept in the loop. Purely automated bans don’t hold up at the contractual or evidentiary level.

4. Prevention: Reducing “Distillability” and Governing Quotas

On the output side. By default, don’t return token-level reasoning traces or probability distributions. Return only the conclusion, or a “summarized reasoning” format that condenses a long chain of thought into a few key points. Limit the number of candidates per request, and set output-length caps for high-value tasks. Note that hard-cutting reasoning explainability hurts legitimate debugging and trust requirements. A more sensible approach is tiered access: standard accounts get summaries, while accounts that have passed enterprise identity verification and purpose review can request more complete observability information as needed.

def build_response(req, cfg):
    exposed = cfg.allow_exposed_reasoning      # determined by account tier and review outcome
    out = model.generate(
        req,
        n=1 if not exposed else min(req.n, cfg.max_candidates),
        logprobs=None if not exposed else req.logprobs,
    )
    return {
        "answer": out.text,
        "reasoning": out.reasoning if exposed else summarize_reasoning(out.reasoning),
    }

On the quota side. Bill and rate-limit based on a token budget rather than request count. Add constraints on account freshness, bind payment methods, apply gradual quotas to new accounts, and for anomalous clusters, downgrade first, then verify.

On the model side. The industry is also exploring anti-distillation training, behavioral fingerprinting (using a set of private probe prompts to observe another model’s response distribution for indirect comparison), and text watermarking. However, these methods generally have robustness issues and can cause collateral damage, so they should not be used as the sole line of defense.

5. Controlling False Positives: the Hardest Part of the Whole System

A lot of behavior that “looks like an attack” is actually normal. RAG and agent frameworks inherently use fixed templates and produce high repetition rates. Automated evaluation, regression testing, and batch data cleaning all generate large volumes of homogeneous requests. Agent retries can cause the same input to arrive multiple times. Multiple branch offices sharing one integration codebase also look like “multiple accounts using the same template.”

You therefore need to build:

• Stable traffic baselines (stratified by capability tag, account age, and region)
• A mechanism for comparing declared business use against actual usage
• An appeal and rapid-recovery channel
• Complete audit log retention, so that evidence can be presented after the fact

At the same time, acknowledge the structural difficulty of proving a case. The service provider can only observe the request side and cannot directly prove that the other party used the outputs for training. It can only rely on indirect evidence such as release cadence and degree of capability alignment. The interference factors work the other way, too. As the proportion of synthetic data in public corpora rises, extracted outputs may already be contaminated, so the distilled capabilities may not hold up. This also lowers the technical credibility of the accusations.

6. Deployment Architecture Recommendations

Engineering-wise, there is no need to reinvent the wheel. You can assemble a closed loop using common cloud service categories. The access layer has a unified gateway for fingerprint collection and rate limiting. The log service ingests metadata for all requests. A message queue absorbs traffic peaks before handing off to stream computing for real-time feature extraction. Object storage retains raw payloads for retrospective analysis and evidence. Vector search and near-duplicate algorithms power template clustering. Monitoring and alerting handle threshold triggers and on-call dispatch. The data warehouse supports offline attribution analysis and model iteration. If your team builds on a platform such as Baidu AI Cloud, these capabilities are all available as general-purpose service categories. When choosing services, focus on three things: stream processing latency, log search cost, and whether the feature store can support cross-account graph queries.

7. Checklists for Both Sides

API providers: Do you govern budgets by tokens rather than request count? Do you perform cross-account shared-origin clustering? Do you hide token-level reasoning and probability outputs by default? Do you retain an auditable evidence trail? Do you have a human review and appeal mechanism? Does your response ladder correspond to the breach-of-contract clauses?

API consumers: Are you using outputs within the bounds permitted by the terms of service? Are you using outputs to train a model that competes with the provider? Have you circumvented identity or regional restrictions? Have you applied quality filtering based on the synthetic data ratio? Do you retain a complete provenance audit for your own training data?

Distillation itself is a neutral technical method. What crosses the line is unauthorized large-scale capability transfer and evasion behavior. Rather than trading accusations in the court of public opinion, make detection an engineering capability that is quantifiable, reviewable, and appealable. That is how you both protect model assets and withstand scrutiny on both technical and legal fronts.