A query interface isn't automatically a protective one
Model extraction reconstructs a model's underlying behavior by systematically querying its inference endpoint and observing the pattern of responses, rather than by obtaining the model's actual parameters. Exposing a model only through a query interface, instead of distributing it directly, is often treated as inherently protective — extraction shows that protection is only partial: with enough queries, an attacker can approximate the model's behavior closely without ever needing direct access to what's actually running behind the endpoint.
This makes an inference endpoint a resource whose exposure compounds cumulatively across many requests, rather than something fully evaluated by any single request in isolation — a query that's individually unremarkable can still be one data point in a systematic extraction effort spanning many thousands of similarly unremarkable requests.
Treating cumulative query volume as its own signal
Defending against this looks less like an access-control problem solved by a single yes-or-no check and more like the rate-limiting and abuse-detection problem applied to a specific extraction goal: bounding total query volume per caller over time, watching for the systematic, broad-coverage query patterns characteristic of extraction rather than typical use, and treating the endpoint's exposure as a resource quota consumed cumulatively rather than a series of independently authorized requests, each fully evaluated on its own.