inference/research
verifiedhigh · 0.85majorupdated 2026-10-04

An API key on an open-weights endpoint protects your serving capacity and quota - it never protected the model, and the weights are the thing worth stealing

[major] security

Fields

id
gotchas/sec-api-key-protects-capacity-not-the-weights
Class
security
Severity
major
Concepts
model-extractionapi-keyopen-weightslogprobsdistillationfingerprintinglicensing
Symptom
A team serves open weights behind vLLM with an API key and considers the model protected. An API key on your endpoint limits who can reach YOUR capacity. It does not limit what an attacker learns from the weights, which are downloadable from the model host by anyone with a Hugging Face account and acceptance of the licence.
Root cause
Separate the two assets. (1) The weights are protected by the host-side licence gate, entirely independent of your API key - measured directly here: an unauthenticated request to the gated Llama-Guard-3-1B config returns 'Access to model ... is restricted. You must have access to it and be authenticated.' (2) What your API key actually protects is the inference capacity, and vLLM's own control is thin: api_key is Optional[list[str]] = None, so the engine ships with NO authentication by default, and the flag is a list of shared bearer keys checked at the HTTP layer, with no per-key rate limit, no per-key quota and no per-key log attribution. Neither layer is an anti-extraction control. Black-box query access alone is sufficient for functionality stealing - the Knockoff Nets threat model assumes only image-in/prediction-out with no knowledge of training data, internals or output semantics, and that threat model transfers to a served LLM regardless of your key policy.
Workaround
Assume the weights will be obtained by anyone who wants them, and protect what that actually costs you: serving margin, rate, and provenance. Publish terms and enforce attribution; treat an API key as an operational control (abuse, billing, capacity) and not as an intellectual-property control. If your defensible asset is the served behaviour rather than the weights, watermarking for tracing is one option - and note it is aimed at the EXTRACTOR, not the reader, via controlled noise in the token frequency distribution plus a KL-divergence test distinguishing original from modified distributions.
notes
SCHEME RECLASSIFIED (2026-10-04): was 'framework'. The honest framing of the residual risk: for an open-weights model, extraction resistance is close to a category error. Anyone can download the weights, so the only real questions are whether YOUR endpoint lets an attacker obtain something they could not get from the weights (and logprobs are exactly that - see the logprobs record), and whether you can prove provenance after the fact.

Notes

SCHEME RECLASSIFIED (2026-10-04): was 'framework'. The honest framing of the residual risk: for an open-weights model, extraction resistance is close to a category error. Anyone can download the weights, so the only real questions are whether YOUR endpoint lets an attacker obtain something they could not get from the weights (and logprobs are exactly that - see the logprobs record), and whether you can prove provenance after the fact.

Cross-references