How companies can defend against AI model extraction attacks

Last updated: August 2026

Your model never leaves your servers. The weights sit encrypted, the training data is locked down, and nobody breaches your network, yet a competitor still walks away with a working copy of it. The attacker doesn’t need your infrastructure, only your API, a budget for queries, and patience. Every prediction you return is a labeled training example you handed them for free.

This guide is for the people who own that API: ML engineers, platform teams, and the security folks who deployed a model behind an endpoint and now have to keep it from being cloned.

How do you defend against model extraction attacks?

There is no single control that stops model extraction. You layer defenses so each one raises the attacker’s cost, which is ordinary defense in depth applied to an API, and together they make cloning your model more expensive than it’s worth. Work through them in this order:

1. Lock down access. Require authentication, kill anonymous querying, and tie every request to an identity you can rate-limit and revoke.
2. Rate-limit against extraction, not just abuse. Set query budgets sized to real use cases and throttle clients whose patterns look like mapping.
3. Return less. Give the minimum output the use case needs, and drop confidence scores and full probability vectors when a top label will do.
4. Perturb outputs. Add calibrated noise to predictions so each answer is still useful to a real user but degraded as a training signal.
5. Watermark the model. Embed a signature you can later use to prove a suspect model was distilled from yours.
6. Add training-time protection. Use differential privacy and adversarial training to make the model harder to copy and harder to invert.
7. Monitor, detect, and respond. Score query distributions continuously, alert on extraction patterns, and have a plan for when one fires.

Steps 1 through 3 cost almost nothing and stop the lazy attacker. Steps 4 through 7 cost real engineering effort and buy resistance against a determined one.

What is a model extraction attack?

A model extraction attack is when someone queries your deployed model enough times to train their own copy of it, using your outputs as the training signal. No weights are stolen. The attacker reconstructs the model’s behavior from the outside, which is why model extraction is sometimes called model theft or model stealing.

The mechanics are simple. The attacker sends inputs to your API, records what comes back, and builds a dataset of input-output pairs. Feed enough of those pairs into a fresh model and you get a surrogate: a substitute model that mimics the decision boundary of the original. For classification models the attacker copies the labels, and for generative models they copy the style and reasoning, which is where model distillation becomes the extraction technique of choice.

Here’s what makes model extraction hard to stop. Every one of those queries is, on its own, a legitimate request, because your API is supposed to answer questions. The attack is the volume and the pattern, not any single call.

How do you know you’re being targeted?

You usually don’t, at least not from a single request. Model extraction shows up in aggregate, in the shape of a client’s traffic over days or weeks, so you look at query patterns instead of payloads.

Watch for these signals in your API logs:

• Query volume far above what any real use case needs. A client pulling millions of predictions with no product that could consume them.
• Inputs that systematically sweep the feature space. Real users cluster around real problems. Extraction traffic often looks like a grid search, probing edges and boundaries a normal user never touches.
• Synthetic or out-of-distribution inputs. Queries that don’t resemble your production traffic, sometimes near-random, sometimes adversarially spaced to map your decision boundary efficiently.
• A steady, machine-paced request rate that runs around the clock without the daily rhythm a human-driven client shows.
• Fresh accounts with immediate heavy usage, especially from short-lived or anonymous credentials.

Statistical detection methods formalize these signals. PRADA, short for Protecting Against DNN Model Stealing Attacks, flags extraction by measuring the distribution of distances between a client’s successive queries. In its 2019 evaluation, PRADA “detected all prior model extraction attacks with no false positives,” according to Juuti et al. You don’t need PRADA specifically, but you do need something that scores each client on how their query distribution compares to normal use, running all the time.

Access controls and rate limiting

Access control comes first, because no other model extraction defense works if you can’t attribute a query to an identity. Anonymous or open endpoints hand attackers unlimited, unattributable queries. Issue per-client API keys, and follow standard AI access control best practices like scoped tokens and short expirations where the data is sensitive. When you can tie a stream of queries to one account, you can measure that account’s behavior, budget it, throttle it, and cut it off.

Free tiers and trial accounts are the soft underbelly. Attackers spin up disposable credentials to get fresh query budgets, so tighten verification on new accounts and treat a brand-new account pulling heavy volume as suspicious until proven otherwise.

Rate limiting is the highest-value control against model extraction, because extraction is fundamentally a volume attack. Basic rate limiting caps requests per minute, which helps, but a patient attacker just slows down and spreads queries over weeks. Size limits to the actual use case instead of raw throughput: if a legitimate client of your fraud-scoring API needs a few thousand predictions a day, a client pulling a million is not using your product, they’re copying it. Adaptive throttling goes further by tightening limits only on clients whose query patterns look like extraction, which is where rate limiting and detection merge.

A minimal extraction-aware query budget looks like this:

# Pseudocode: per-client query budget with an extraction penalty
def allow_request(client, request):
    # Record this request so scoring sees the current query
    client.record(request)
    client.window_count += 1

    # Hard cap sized to a real use case, not raw QPS
    if client.window_count > client.daily_budget:
        return deny("daily budget exceeded")

    # Distribution-based extraction score (PRADA-style)
    score = extraction_score(client.recent_queries)
    if score > EXTRACTION_THRESHOLD:
        client.daily_budget = shrink(client.daily_budget)  # adaptive throttle
        alert_security(client, score)
        return deny("anomalous query pattern")

    return allow()

Rate limiting is a blunt instrument, though. Set it too tight and you break real customers with spiky, high-volume workloads; set it too loose and a slow attacker walks through. Model your own legitimate usage first, then set budgets above your heaviest honest client and below what an extraction run would need.

Output minimization and watermarking

What your API returns matters as much as how often it returns it. The richer the output, the fewer queries a model extraction attack needs.

Confidence scores are the clearest example. When your API returns full class probabilities, you hand over the model’s certainty on every possible answer, which is a far stronger training signal than a bare label and lets an attacker reconstruct your decision boundary with a fraction of the queries. If the use case only needs the top prediction, return only the top prediction. Output perturbation is the next layer: add small, calibrated noise so any single answer stays correct enough for a real user while the aggregate signal an attacker collects is degraded. The tuning is delicate, since too little noise does nothing and too much means your users notice the accuracy drop.

Watermarking does not prevent model extraction. It gives you proof after the fact, which matters when your only recourse is legal. The idea is to embed a statistical signature into your model’s behavior, a pattern of responses to trigger inputs that a normally-trained model would never produce. Research systems such as ModelShield build watermarks designed to survive the extraction process, so the signature carries through into the surrogate model even though the attacker never saw your weights.

Treat watermarking as a backstop, not a wall. It converts an otherwise unprovable theft into something you can take to a lawyer, but it only helps if you can access the suspect model to test it. Pair it with terms of service that explicitly prohibit using your API outputs to train a competing model, since those terms are what turn watermark evidence into a claim you can pursue.

Training-time safeguards and monitoring

Access controls, rate limits, and output minimization all sit at the API boundary. Training-time safeguards change the model itself so it leaks less no matter how it’s queried.

Differential privacy, applied during training, bounds how much any single training example can influence the model’s outputs. That directly limits model inversion and membership inference, where an attacker tries to reconstruct or identify your training data from model responses. It raises the model extraction bar too, because a model whose outputs depend less on specifics is a fuzzier target to copy. Adversarial training, which exposes the model to adversarial examples during learning, hardens the decision boundary, and a boundary that’s harder to map from the outside is slower to extract. Be clear-eyed about the cost: differential privacy trades model accuracy for privacy, and the stronger the guarantee, the bigger the hit.

Monitoring for model extraction means baselining normal per-client query behavior, then continuously scoring live traffic against that baseline. Volume spikes, feature-space sweeps, out-of-distribution inputs, and machine-paced timing all become live alerts. Feed the extraction score back into your rate limiter so a rising score automatically tightens the budget on a suspicious client while you investigate.

Have a response plan written before you need it. When an extraction alert fires, you should already know:

• Who gets paged, and who has the authority to cut a client off.
• How fast you can revoke an API key, and whether that breaks anything legitimate.
• What you preserve for evidence, including query logs and client identity, in case watermarking later confirms theft.
• Whether the incident is worth pursuing legally, which is where your watermark and terms of service come back into play.

The teams that handle model extraction well aren’t the ones with the fanciest detector. They’re the ones who decided in advance what happens when it goes off.

Mapping defenses to security frameworks

Three public frameworks already name model extraction as a threat and give you a shared vocabulary for it, which helps when you’re justifying the work to a security team or an auditor.

MITRE ATLAS is the adversarial-ML companion to the ATT&CK framework. It catalogs real-world attacks on ML systems under technique AML.T0024, Exfiltration via AI Inference API, whose Extract ML Model sub-technique covers model extraction specifically. The NIST AI Risk Management Framework, published as NIST AI 100-1, is the governance layer: it won’t tell you which noise level to add, but it structures how you govern, map, measure, and manage AI risks like extraction across the model’s life. On the application-security side, the OWASP Machine Learning Security Top 10 lists model theft as ML05:2023, and the OWASP Top 10 for Large Language Model Applications addresses the distillation-driven version for generative models.

Here’s how model extraction defenses map across the three frameworks:

Defense	MITRE ATLAS	NIST AI RMF	OWASP
Access controls / auth	Mitigation: limit API access	Govern, Manage	ML/LLM access-control controls
Rate limiting + budgets	Mitigation against inference-API exfiltration	Manage	ML05:2023 model theft
Output minimization / perturbation	Mitigation: limit model output detail	Measure, Manage	ML05:2023 model theft
Watermarking / provenance	Detection and attribution	Map, Manage	Model-theft evidence
Differential privacy	Mitigation against inversion / inference	Measure	ML/LLM data-leakage controls
Monitoring + response	Detect ML inference-API abuse	Measure, Manage	Logging and monitoring

Use the frameworks as a checklist and a common language, not as a substitute for the engineering. None of them will size a rate limit for you.

What each model extraction defense costs you

Every defense against model extraction has a price, and the people who have to ship it want to know what it breaks. Here’s the honest accounting:

Defense	Effort to implement	Main cost / side effect
Access controls / auth	Low	Friction for legitimate integrators; account management overhead
Rate limiting + budgets	Low to medium	Can throttle real high-volume customers if mis-sized
Output minimization	Low	Removes a feature (confidence scores) some clients rely on
Output perturbation	Medium	Measurable accuracy loss for real users
Watermarking	Medium	No prevention; only helps if you can test the suspect model
Differential privacy	High	Significant accuracy trade-off at strong privacy settings
Monitoring + response	Medium to high	Ongoing tuning; false positives page your team

Work that table top to bottom, not as a menu. Authentication, rate limiting, and output minimization are cheap and stop opportunistic extraction, so most teams should have all three before shipping a valuable model. Go further down the list only as far as the model’s value justifies the accuracy and engineering cost. A high-stakes medical model may have no accuracy to spare for perturbation, while a recommendation model probably does.

Frequently asked questions

What is the difference between model extraction and model distillation?
Extraction is the attack: querying a model to build an unauthorized copy. Distillation is the technique: training a smaller student model on a larger model’s outputs. Distillation is legitimate when you do it to your own model, and it becomes extraction when it’s done to someone else’s model through their API without permission.

Can someone really copy my AI model just through the API?
Yes, that’s the whole point of model extraction. They never touch your weights; they collect enough input-output pairs from your API to train a surrogate that reproduces your model’s behavior. The more your API reveals per call, such as full confidence scores, the fewer queries they need.

How much does rate limiting hurt legitimate users?
It depends entirely on how you size it. A fixed low cap frustrates real high-volume customers, while budgets sized to actual use cases, combined with adaptive throttling that only tightens on anomalous clients, let normal traffic through and squeeze extraction patterns. The tuning is the hard part.

Does watermarking stop extraction, or only prove it happened afterward?
Only prove it. Watermarking embeds a signature that survives into a stolen copy, so you can later demonstrate a competitor’s model was distilled from yours. It’s evidence for a legal claim, not a barrier at the API.

Which framework should I start with, MITRE ATLAS, NIST AI RMF, or OWASP?
If you’re mapping specific attacks and controls, start with MITRE ATLAS. If you’re building a repeatable governance program, use NIST AI RMF as the backbone, and if your team already runs an OWASP-based app-security practice, the OWASP ML and LLM Top 10 lists are the fastest on-ramp. Most mature programs end up referencing all three.

Is it legal to train a model on another company’s API outputs?
It’s contested, and it’s usually governed by the API provider’s terms of service, which increasingly prohibit using outputs to train competing models. Doing it against those terms exposes you to breach-of-contract and intellectual-property claims. This is a question for a lawyer, not an engineering decision.

Where to go from here

Defending against model extraction isn’t a project you finish. It’s a posture you maintain, because the attacker’s queries look more like your real traffic every year.

If you’re starting today, the highest-value move is also the cheapest one: pull a week of your API logs and look at your per-client query distributions. You’ll usually find one or two clients whose volume or query shape makes no sense for any real product, and that’s the baseline that tells you where to set your first rate limit. From there, work down the cost table as far as your model’s value justifies.

When you’re ready to formalize the program, read the MITRE ATLAS entry for AML.T0024 and the OWASP Machine Learning Security Top 10. Both are free, both name model extraction directly, and both give you the vocabulary to get the rest of your organization to take it seriously.