- 01The economic threshold matters more than the technical barrier. Your defenses succeed when the cost of extracting your model exceeds the cost of training a comparable model from scratch.
- 02Output restriction is the highest impact single control. Withholding logprobs, confidence scores, and full probability distributions dramatically increases the number of queries required for effective distillation.
- 03Watermarking, canary inputs, and honeypot labels are the forensics layer. They provide evidence of extraction after it occurs and create legal ground for action.
- 04Authentication and rate limiting are necessary but not sufficient. A well resourced adversary can operate under multiple authenticated identities. Behavioral analysis at the account graph level is needed to detect distributed extraction campaigns.
Model extraction through API queries is a form of model theft that requires no credential access to weight files. The adversary queries the production API systematically, collects input output pairs, and uses those pairs to train a substitute model that approximates the behavior of the target. Given sufficient queries, a capable adversary can produce a substitute that is competitive with the original for the tasks that matter to them.
The key insight for defense is that perfect prevention is not the goal. The goal is economic deterrence. If extracting a usable substitute costs more in API query spend than training a comparable model from scratch, the rational adversary will train from scratch. Your defenses succeed when they raise the extraction cost above that threshold.
Output Restriction Controls
The single highest impact control is restricting what the API returns. Full probability distributions and logprobs are ideal distillation targets. Each query with full distribution is worth many times more to an extraction campaign than a query with only the top output.
- 01Return only top one or top three labels for classification endpoints, never the full distribution
- 02Suppress logprob and confidence score fields entirely for public tier API users
- 03Add calibrated noise to any numeric score that must be returned to preserve product functionality
- 04Truncate long form generation outputs at a length that serves legitimate use cases but limits information per query
- 05Rotate output formats periodically so that a trained substitute becomes stale as the target model evolves
Suppressing logprobs multiplies the query count needed for effective extraction by a large factor.
When only top label output is available, extraction campaigns must rely on hard label distillation, which requires substantially more queries to achieve the same substitute model quality as soft label distillation from full distributions. This single control can shift the extraction budget from practical to economically unattractive for many adversaries.
Authentication, Rate Limiting, and Behavioral Analysis
Authentication and rate limiting are the floor of API security, not the ceiling. A well resourced adversary can register multiple accounts and distribute queries across them to stay below per account rate limits. The detection layer must therefore operate at the behavioral level across account clusters, not just at the per account level.
The behavioral signature of an extraction campaign is low semantic diversity at high volume. Legitimate users ask diverse questions. Extraction campaigns cover the input space systematically, which produces a distinctive pattern of high coverage and low diversity relative to account age and stated purpose.
/Layered API Security Controls for Extraction Defense
| Layer | Control | What it addresses |
|---|---|---|
| Authentication | Verified identity required for API access | Removes anonymous extraction |
| Rate limiting | Per account per hour query ceiling | Raises cost for single account campaigns |
| Behavioral detection | Per account semantic diversity scoring | Detects systematic coverage sampling |
| Graph analysis | Account clustering by shared infrastructure | Detects distributed multi account campaigns |
| Canary inputs | Known inputs with monitored outputs | Detects substitute model deployment after extraction |
Watermarking and Forensics
Behavioral detection aims to stop extraction while it is happening. Watermarking and forensic canaries provide evidence after the fact, when a stolen model appears in a competitor product or is discovered in a breach.
Output watermarking encodes a statistical signal that survives distillation into a substitute model. If you discover a model in the wild that was potentially extracted from yours, watermark detection can provide evidence of origin. Canary inputs are known inputs that produce distinctive outputs. If a suspect model produces the same distinctive output for your canary input, that is a strong signal of extraction.
These forensic layers do not prevent theft. They create the evidentiary foundation for legal action and for the internal post mortem that determines how the extraction occurred and what controls to improve.
Canary inputs should be rotated and the old ones retained.
A canary input that is too widely known loses its forensic value. Maintain a library of canary inputs, rotate the active set periodically, and retain historical canaries for use in post incident analysis. Document the expected output for each canary so detection can be automated.
Metrics and Closing Actions
Track four metrics. Per day extraction anomaly alerts fired and confirmed captures the detection pipeline's sensitivity. Average semantic diversity score across API accounts tracks the baseline against which anomalies are measured. Output restriction coverage shows what fraction of API endpoints are compliant with the output restriction policy. Canary input monitoring coverage shows what fraction of canaries have automated alerting.
The closing action is to audit your API response payloads and identify every endpoint that returns a probability distribution, confidence score, or logprob. For each such endpoint, document whether the score is required for the product use case or is incidental. Endpoints returning scores that are not required by the product should have those fields stripped in the next release cycle.