Adversarial Robustness · Model-Extraction Defense
Cap sampling settings callers can change
Verify that inference endpoints constrain sampling and decoding parameters supplied by untrusted callers (e.g., temperature, top-k, top-p, logit bias, candidate/n count) to server-side approved ranges and defaults, rejecting out-of-policy values.
OWASP AISVS v1.01, requirement 11.3.5
In plain English
Generation settings such as temperature, top-k, top-p, logit bias and the number of candidates change how a model behaves. Extreme values can help an attacker bypass safety behaviour or extract the model faster. Limit what untrusted callers can set to ranges you have approved, and reject anything outside them.
What good looks like
- Each parameter a caller may set has an approved range and a default.
- Out-of-range values are rejected with an error. They are not silently clamped.
- Parameters you do not want callers to control, such as logit bias, are not exposed.
- The policy is enforced on the server.
How teams usually do it
- Validation in your API layer before the model is called, driven by a parameter policy file.
- Fixed values for user-facing features, with settings tuned by you.
- A cap on the number of candidates and on any log-probability options.
Suggested evidence
- The parameter policy.
- Tests with out-of-policy values, showing rejection.
Common mistakes
- Passing the caller's parameters straight through to the model API.
- Enforcing ranges in the client application only.
- Accepting unknown parameters and forwarding them.
Not sure which requirements apply to your system? Take the assessment, or browse every guide in this chapter.
Requirement text from the OWASP AI Security Verification Standard, licensed under CC BY-SA 4.0. This guidance is shared under the same licence.