Somewhere in your API logs right now, there's a set of requests that look completely unremarkable — properly authenticated, well-formed, arriving at a normal pace. And yet, taken together, they could be quietly reconstructing your model, one response at a time. No alert fires. No firewall trips. The requests aren't malicious in any way your monitoring is built to recognize. They're just... thorough.
This is the uncomfortable reality of model extraction: it doesn't exploit a bug. It exploits design decisions — choices about what your API returns, how much it trusts a given account, and whether anyone is watching the shape of the traffic rather than just its volume. The encouraging part is that these are decisions you actually control. Unlike a zero-day vulnerability, this isn't something you patch once and move on from — it's an architecture you can deliberately harden. This piece walks through exactly where those decisions live, and how to get them right.
Why "It's Just an API" Is the Wrong Mental Model
Security teams have spent years hardening APIs against familiar threats — injection attacks, broken authentication, data scraping. Those defenses matter, but they weren't designed with model extraction in mind, because the "damage" here isn't a data record leaving your database. It's your model's behavior leaving through thousands of individually harmless-looking responses.
A recent practical extraction exercise conducted by security researchers at Praetorian is a useful illustration of just how little it takes. Their team successfully built a working replica of a target model using roughly 1,000 queries — a volume that, in their own words, should have triggered anomaly detection but didn't. That's not a nation-state-scale campaign. That's a volume many legitimate integrations generate in a single day.
A quick honesty check before we go further: not everything below carries the same level of real-world validation. Output design and rate limiting are mature, widely deployed practices — you'll find them in the security guidance of every major model API provider today. Behavioral monitoring for extraction-specific patterns is newer but gaining real traction, with dedicated tooling now emerging from AI security vendors. Output perturbation and watermarking, by contrast, are still largely the domain of active academic research — genuinely promising, published in peer-reviewed venues, but with fewer large-scale production deployments and known trade-offs that haven't been fully resolved. We'll flag this distinction as we go, because knowing which controls are battle-tested versus emerging should shape how much weight you put on each one.
Option #1: What Your API Returns
This is the single highest-leverage decision you'll make, and most teams get it wrong by default — not out of negligence, but because rich outputs are genuinely useful to legitimate users.
The problem: A model that returns full confidence scores, probability distributions across every class, or token-level logits is handing an attacker a detailed map of its decision boundary with every single response. Research consistently shows richer outputs dramatically reduce the number of queries an attacker needs.
The fix:
* Prediction truncation — return only the top prediction, or top-k results, rather than the full probability distribution. Less information per query means an attacker needs substantially more queries to reconstruct the same decision boundary.
* Hard labels over soft scores — where your product doesn't strictly need a confidence value displayed to the user, don't expose one through the API at all.
* Selective richness — if certain partners genuinely need detailed scores (for legitimate business reasons), gate that level of access behind a higher trust tier with tighter monitoring, rather than exposing it by default to every API consumer.
This is almost always the cheapest fix in this entire list, and it's often the one with the biggest impact on extraction difficulty.
Option #2: Output Perturbation
The idea: Add carefully calibrated noise to your model's outputs — enough to meaningfully degrade an attacker's ability to train an accurate surrogate, but not enough that legitimate users notice a difference in quality.
Academic research has developed increasingly sophisticated versions of this approach. Rather than perturbing every response uniformly, newer techniques like adaptive misinformation selectively add stronger noise specifically to queries that look like they're probing the boundary of the model's behavior — precisely the queries an attacker relies on — while leaving typical, in-distribution user queries largely untouched.
The honest caveat here: every perturbation technique involves a trade-off between security and accuracy for legitimate users, and getting that balance wrong can quietly degrade your product experience. This is not a "set it and forget it" control — it needs to be tuned and monitored, which is exactly the kind of exercise worth running under professional guidance before it ships to production.
Option #3: Rate Limiting — Done Properly
Almost every API has some rate limiting. The problem is that most implementations are tuned for abuse prevention — stopping denial-of-service attempts or credential stuffing — not extraction, which looks nothing like a traditional abuse pattern.
What generic rate limiting misses: An attacker running a patient, low-and-slow extraction campaign across multiple API keys, spread over days or weeks, will sail under thresholds designed to catch bursts of traffic.
What effective rate limiting for extraction actually looks like:
* Query budget caps tied to account trust level, not just request frequency
* Limits that account for cumulative volume over longer windows (days, not just minutes)
* Escalating friction — CAPTCHAs, proof-of-work challenges, or manual review — triggered by patterns rather than raw volume alone
Option #4: Behavioral and Query Pattern Monitoring
This is the control most organizations don't have at all today, and it's arguably the most important one, because it's the only layer that catches an attacker who's already designed around your rate limits and output restrictions.
Extraction campaigns have a statistical fingerprint, even when no single request looks suspicious:
* Systematic coverage — inputs that methodically sweep across the input space (varying one field at a time, in sequence) rather than reflecting organic, real-world usage
* Unusual diversity — a single account submitting a far broader range of inputs than a typical legitimate user would ever generate
* Boundary-probing behavior — repeated queries clustered suspiciously close to known decision thresholds
Detection-based research approaches, such as analyzing the statistical distance between successive queries, have been proposed specifically to catch this kind of pattern. Vendors and security teams are increasingly building this into API gateways directly, alongside more conventional behavioral analytics.
This is genuinely difficult to build well in-house, particularly for teams whose monitoring stack was designed around traditional web application traffic. It's also precisely the kind of gap a structured security assessment is designed to surface — testing not just whether extraction is possible against your API, but whether your current monitoring would ever notice it happening.
Option #5: Watermarking
Watermarking takes a different philosophy from the other controls on this list: it doesn't try to prevent extraction. It ensures that if extraction succeeds, you can prove it.
The technique involves embedding subtle, detectable signals into your model's outputs or behavior — patterns that a legitimate user would never notice, but that persist even after an attacker has distilled your model into their own surrogate. If a suspiciously similar competing model later appears, those embedded signals can serve as evidence of theft.
Important caveat: watermarking is not a prevention control, and it shouldn't be your only line of defense. By the time a watermark is detected, the surrogate model has typically already been trained and is already in an attacker's hands. Think of it as insurance and evidence, not a lock on the door — valuable for IP disputes and legal recourse, but not a substitute for the controls above.
Putting It Together: Defense in Depth, Not a Single Fix
No single control on this list stops a determined attacker on its own. Prediction truncation without behavioral monitoring just forces an attacker to send more queries. Rate limiting without pattern detection just teaches attackers to slow down. The organizations that handle this well layer these controls together — output design, calibrated perturbation, extraction-aware rate limiting, behavioral monitoring, and watermarking as a backstop — so that defeating one control still leaves an attacker facing the next.
The good news is that none of this requires rebuilding your product from scratch. Output truncation and rate-limit tuning can often be implemented in days. Behavioral monitoring and calibrated perturbation take more work, but they're additive layers on top of an existing API rather than a redesign.
The real starting point isn't picking a control off this list at random — it's finding out, under controlled and safe conditions, exactly how exposed your current API actually is. That's the difference between guessing at your risk and knowing it.
The Model That Never Knew It Was Being Copied
Here's the strange thing about model extraction: your model cooperates with its own theft, faithfully, every single time. It doesn't withhold effort for suspicious-looking requests. It doesn't get suspicious. It just does exactly what it was built to do — answer the question in front of it, as accurately as possible — without ever knowing whether the question came from a customer or a competitor.
That's not a flaw in the model. It's a gap in everything around it. The five decisions in this piece are how you close that gap — not by making your model less helpful, but by making sure helpfulness isn't the same thing as blind trust.
The uncomfortable version of this piece could be summed up in one sentence: if your API has never been tested against extraction, you don't actually know which side of "trivial to clone" versus "expensive to attack" you're currently standing on. The reassuring version is just as short: that's a knowable thing, not a guess — and it's far cheaper to find out on your own terms than to find out from a competitor's product roadmap.
