Distillation-Based LLM API Extraction: Detection and Defense Practices

1. Incident reconstruction: probing the model service at scale

A leading LLM service provider publicly disclosed that it observed multiple organizations using large pools of accounts to call model APIs at high frequency and in a systematic way, aiming to copy model capabilities into their own models or products by generating scaled input-output sample pairs. This behavior is commonly described in the industry as distillation-based capability extraction.

The key point of such disclosures is not whether out-of-policy calls occurred—any open API can be abused by any caller—but that this is not scattered misuse. It is an organized, engineering-driven effort aimed at capability extraction: with stable compute budgets, standardized probing sets, and dedicated account-pool maintenance. Treating it as ordinary abuse will keep the response limited to IP bans and rate limiting, which has very limited effect.

2. Technical mechanics: what is actually being extracted

Classical model distillation usually happens in open settings: the teacher model outputs logits or soft labels, and the student model uses softened probability distributions as supervision signals to approximate the teacher with much fewer parameters. Closed-source APIs typically return only text, at most with limited candidate or confidence information. In practice, therefore, what occurs is black-box distillation based on generated data: the caller treats the API as an unlimited, high-quality, parallel data labeler.

From an attack-defense perspective, extraction targets can be grouped into four layers. The lower the layer, the harder it is to defend against and the greater the harm:

1. Output-distribution layer: sampling the same prompt repeatedly under different temperatures and random seeds to measure token-level determinism and diversity, and infer the model’s sampling strategy, confidence level, and length preferences.
2. Instruction-response layer: taking a small set of high-quality question-answer pairs and performing large-scale rewriting, translation, expansion, and variant synthesis to build an SFT (supervised fine-tuning) dataset. This is the most common and easiest layer to implement.
3. Preference and alignment layer: systematically enumerating refusal boundaries and collecting paired samples such as “boundary-crossing question / refusal” and “gray-area question / answer” to train a preference model or replicate safety alignment behavior.
4. Capability and knowledge coverage layer: building coverage probes for specific subjects, code, long context, tool use, and other dimensions, using model performance as capability benchmarking to guide the improvement roadmap of their own models.

Why does it require many accounts? The account is the minimum billing unit for quota, billing, and identity risk control. Spreading calls across dozens or hundreds of accounts can avoid single-account rate limits, dilute unit cost, and hide behavioral fingerprints in noise. From a single-account view, the activity looks like occasional bursts; only when aggregated does it show a stable, 24/7 extraction curve. This is also why the correct governance unit is the entity, not the account.

3. Observable anomaly signals: four dimensions

Detection starts with defining what “normal” looks like. It is recommended to establish baselines across four dimensions and describe deviations with percentile statistics rather than fixed thresholds.

Dimension	Typical signals
Account and identity	Very short interval between registration and first call; multiple accounts sharing the same payment identifier, device fingerprint, or email domain; call timing inconsistent with real business rhythms (uniform 7×24 distribution or late-night concentration)
Request shape	Many single-turn requests with little conversation-state progression; the same question submitted repeatedly in N different phrasings; highly structured input (abnormally high JSON/table template ratio); almost no colloquial noise (typos, informal language, unclear references); generation parameters repeatedly adjusted (full-range temperature sweeps, length parameters fixed at maximum)
Response and value distribution	Requests concentrated on high-value tasks (complex reasoning, code generation, long-form writing) rather than the short Q&A common in real business usage; repeated sampling of the same prompt without follow-ups, corrections, or session closure
Billing and cost	Account quota exhausted rapidly followed by switching to another account; high-frequency calls immediately after subscription; consumption curve showing a “sawtooth plus plateau” pattern and lacking the periodicity and peak-trough structure of real business usage

The most discriminating combination is: multi-phrasing enumeration of the same question + parameter scanning + no conversation progression. A normal user asks to get an answer and continue working. An extractor asks to collect sufficiently diverse answers and then leave.

4. Detection system design

4.1 Account profiling and behavioral baselines

For each type of business, establish percentile baselines (such as P50/P95/P99) and convert “deviation from baseline” into comparable scores instead of hard-coded magic numbers in rules. Recommended features include: requests per unit time, mean and variance of input length, multi-turn ratio, parameter diversity, answer adoption rate (whether it is copied, followed up on, or rejected), and entropy of active hours.

4.2 Correlation analysis: from accounts to teams

Construct a graph of accounts, payment identifiers, device fingerprints, egress IP ranges, autonomous systems, and registration channels. Use connected components or community detection to find account clusters sharing resources. A single account may look normal, but once aggregated into a cluster, the behavior often shows an orderly rhythm.

# Example pseudocode: account anomaly scoring
features = collect_account_features(account_id, window="24h")
z = {
    "req_rate":      zscore(features["req_per_min"], baseline["req_per_min"]),
    "single_turn":   zscore(features["single_turn_ratio"], baseline["single_turn_ratio"]),
    "param_entropy": -zscore(features["param_diversity"], baseline["param_diversity"]),
    "enum_pattern":  enum_score(features["prompt_clusters"]),   # strength of multi-variant enumeration
    "answer_reuse":  zscore(features["answer_discard_ratio"], baseline["answer_discard_ratio"]),
}
score = weighted_sum(z, weights=W)
if score > HIGH and graph_cluster_size(account_id) >= K:
    mark_for_review(account_id, reason="distillation_suspected")
elif score > MID:
    tighten_quota(account_id, factor=0.5)

4.3 Query-side fingerprinting: identifying multi-variant enumeration

Normalize prompts (remove whitespace, unify case, strip template placeholders), extract n-gram sets, and compute pairwise Jaccard similarity and edit distance for clustering the request set of each account. If an account shows many clusters of “high similarity but different phrasing,” and these clusters keep growing, it can basically be determined as targeted enumeration.

4.4 Canary markers and probe-set forensics

Plant a small number of distinctive markers in internal training/evaluation corpora: rare compound phrases, constructed knowledge, and unique formatting constraints. If these markers appear in external model public outputs, paper examples, or third-party API results at an abnormally high reproduction rate, they constitute strong evidence. This method is forensics rather than defense. Deployment must follow legal and compliance processes, avoid contaminating normal business data, and prevent insufficient evidentiary strength from relying on only one marker.

4.5 Response pipeline

Feature collection (real-time stream) → rule engine (second-level interception) → offline batch scoring (minute/hour-level clustering and team identification) → manual review → graduated response (alert, quota tightening, feature degradation, entity-level ban). The key is graduation and rollback: high-risk actions should be placed behind human confirmation to avoid automated collateral damage to high-value customers.

5. Defense and governance strategies

• Identity and admission: strengthen entity verification (business qualification, real-name identity, consistency of invoice entity), bind quotas to the business entity/project rather than a single account, and raise the cost of creating accounts at the root.
• Multi-dimensional quotas and tiered rate limiting: combine sliding windows and token buckets; set limits by entity, team, project, and model; route calls that exceed normal business characteristics to a degradation queue or asynchronous review instead of rejecting them outright.
• Tiered capability supply: separate generic capabilities from advanced capabilities (deep reasoning, internal tool orchestration, domain-specific tasks); raise admission thresholds for advanced capabilities, reduce concurrency, and enable stronger auditing.
• Output-side governance: constrain the adjustable range of sampling parameters, reduce exposure of observable confidence information, add structured output and post-generation quality inspection for high-value tasks, and lower the information value obtainable from a single call.
• Contract and accountability: explicitly prohibit the use of outputs for model training or capability copying in the service terms; retain traceable request IDs and a complete audit chain to provide a basis for evidence.
• Evidence-chain construction: full-chain request logs, request fingerprints, timestamps, tamper-resistant archiving, and clear retention periods are all required.

6. Mapping to common cloud capabilities

You do not need to build the entire stack from scratch. You can assemble solutions using common cloud capability categories (these are generic categories, not specific products):

• Unified identity authentication and access control: entity verification, fine-grained authorization, resource and quota partitioning by project;
• API gateway: authentication, rate limiting and circuit breaking, canary release, request-level auditing, and log instrumentation;
• Log service: full-chain call log collection, search, long-term archiving, and compliance retention;
• Monitoring and alerting: multi-dimensional metric dashboards, anomaly detection, threshold and intelligent alerting, and on-call linkage;
• Message queue: peak shaving and valley filling, decoupling offline scoring and risk-control tasks from the main path, avoiding risk control slowing down inference;
• Object storage: training/evaluation datasets, forensic samples, and log archives;
• Container platform: elastic scaling of inference services, tenant isolation for instances, and fast rollback after failures;
• Key and data security: key custody, sensitive-field masking, and encryption in transit and at rest.

7. Common mistakes and tradeoffs

1. Only blocking IPs: NAT, proxy pools, and cloud egress can cause both missed detections and collateral damage. Network-layer signals can only serve as auxiliary features.
2. Over-sensitive thresholds: batch evaluation, offline regression, and data cleaning inside enterprises can also show “high concurrency + many variants.” They must be distinguished by combining entity qualifications and historical behavior.
3. Misuse of canaries: improper placement can contaminate business data, and a single marker is insufficient to support external claims.
4. Defense without observation: without baselines and dashboards, you cannot answer how much extraction behavior decreased after governance, nor can you tune the system.
5. Hard-coded policies: risk rules must be configurable, canary-releasable, and rollable back with one click. Otherwise, one misjudgment becomes a customer incident.

8. Rollout roadmap and conclusion

The essence of distillation-based extraction is converting “service revenue billed per call” into “training data for others.” Its harm is not the cost of a single call, but the continuous, low-cost leakage of model capability, a core asset. Therefore, the correct response is not to reduce rate-limit thresholds, but to incorporate model capabilities into a data asset governance framework:

1. Observable (1–2 weeks): complete call logs, establish four-dimension baselines, and build dashboards;
2. Identifiable (2–4 weeks): launch account scoring and team correlation analysis, and output lists of suspicious entities;
3. Actionable (in parallel): implement graduated rate limiting, entity-level quotas, feature degradation, and a closed loop with manual review;
4. Evidentiary (long-term): establish contract terms, canary and forensic processes, and audit archiving to form a complete evidence chain.

The first two steps solve “being able to see it.” The latter two solve “being able to control it.” Only when every request on the calling side can be attributed to a traceable entity and treated differently according to its value and risk can the protection of model capabilities truly shift from passive firefighting to routine governance.