Every answer an API returns is a labelled training pair, given away. Why an attacker needs a model that behaves the same rather than the weights themselves, why the features that make an API pleasant are the ones that make it cheap to copy, and why the honest goal is cost rather than prevention.
You are publishing the answers
Every response the endpoint returns is an input paired with an output, produced by the model, at your expense.
That is the exact material required to train something to do the same job. Not similar material — the same material, of higher quality than anything the copier could label themselves, because it came from the system they want to imitate.
The API is not leaking. It is functioning. Serving answers is the product, and the answers are the thing.
They do not want the weights
This is the part that makes the problem tractable to an attacker and awkward to defend.
Reconstructing the parameters of a large model from its outputs is difficult. Training a smaller model to behave indistinguishably on the inputs that matter commercially is much easier, and it is entirely sufficient.
Nobody needs your model. They need a model their customers cannot tell from yours, on the queries their customers actually send. That bar is far lower, and it drops further the narrower the domain.
Which means defences framed around protecting the parameters are aimed at an attack nobody is attempting.
The pleasant features are the expensive ones
An uncomfortable alignment, and it is worth being clear-eyed about.
Full probability distributions are wonderful for building on and are the single richest extraction signal available — far more informative per query than the chosen answer alone.
Deterministic outputs make behaviour reproducible for legitimate integrators, and remove the noise that would otherwise make copying require many more samples.
Verbose reasoning helps users trust and debug an answer, and supplies the intermediate steps that teach a smaller model how to arrive at one.
Generous rate limits are a courtesy to real customers and the mechanism by which extraction becomes affordable.
Every item on that list is a good product decision. Each also lowers the price of copying. There is no version of this where you get the first without the second.
What raises the cost
Rate limits priced against extraction, not abuse. These are different numbers. An abuse limit stops someone hammering the service; an extraction limit considers how many samples are needed to distil this particular capability, and sits below it. Most services have only ever set the first.
Truncate confidence scores. Round them, band them, or omit them where the use case does not genuinely require them. A great deal of extraction signal disappears here for very little product cost.
Per-account behavioural analytics. Extraction has a shape — broad coverage, systematic variation, little repetition, no follow-up. It does not look like use. It is detectable if anybody is looking at the distribution of queries rather than their volume.
Accept some loss of fidelity as the price. This is the honest one. Every measure above makes the product slightly worse for legitimate users. Pretending otherwise turns the decision into a technical problem when it is a commercial trade.
Cost, not prevention
A determined extractor with a budget and a supply of accounts will succeed.
The queries are individually legitimate. They can be spread across identities, across time, and across intermediaries. There is no signature to match, because nothing anomalous is happening — somebody is using the service as intended, rather a lot.
So the goal is to move the cost of copying from trivial to considerable, and to make the attempt visible while it is underway. Both are achievable. Neither is prevention, and a plan that promises prevention here is a plan that has not been examined.
Close
The endpoint is the product and the specification at once.
You cannot ship one without the other. What you can decide is how many questions it takes.