Parameter Manipulation

LLM inference APIs expose generation parameters (temperature, top_p, top_k, frequency_penalty, presence_penalty, max_tokens) as mutable request fields. The design assumption is that parameter ranges are bounded by server-side validation and that extreme values only affect output quality, not safety. The gap: most API implementations validate parameter types (float, int) but not semantic safety implications of extreme combinations.

• Monitor for API requests with parameters at distribution extremes: temperature >1.5, top_p >0.95, negative frequency/presence penalties
• Alert on logit_bias fields that suppress known refusal tokens (tokenize common refusal phrases and watch for negative bias on those token IDs)
• Detect seed-scanning patterns: same prompt submitted with incrementing seed values
• Log and flag combined parameter configurations that have never appeared in legitimate traffic

Successful parameter manipulation degrades safety classifier confidence, enabling follow-on attacks via T1 (Prompt Subversion) or T3 (Reasoning Exploitation) that would otherwise be caught. Parameter manipulation on self-hosted APIs often chains into T5-AT-012 (Resource Exhaustion) via max_tokens abuse.