Sampling Parameter Injection: Generation Settings Are Evidence, Not Authority

This article is grounded in public generation and API documentation, not claims about private model internals. Hugging Face's generation documentation exposes the vocabulary clearly: a generation method can be parameterized with a GenerationConfig; generation strategy can include do_sample; output-logit controls include temperature, top_k, top_p, and related probability filters.

vLLM's public SamplingParams API makes the server-side surface even more concrete: sampling configuration fields such as temperature, top_p, top_k, penalties, stop controls, maximum token settings, and logit_bias. Different providers name and support different options, but the common lesson is stable: generation behavior is controlled partly by metadata outside the natural-language prompt.

The safe claim is not “sampling parameters are a vulnerability.” They are necessary controls. The safe claim is narrower: if an AI-agent runtime accepts untrusted sampling configuration, request overrides, cached generation settings, or tool-returned decoding hints as action authority, attackers can steer behavior without writing a classic jailbreak sentence.

Imagine two ways to influence a driver. One is to shout instructions from the back seat. That is classic prompt injection: visible language telling the model to ignore policy or do the wrong thing. The other is to quietly change the steering sensitivity, speed limiter, route preferences, or brake assist settings before the trip starts. The driver may still be reading the same destination, but the vehicle now behaves differently.

Sampling parameters are the model's steering controls. Temperature can make output more or less random. Top-k and top-p choose which token candidates remain in play. Stop strings can cut output early. Penalties change repetition behavior. Logit bias can make particular tokens more or less likely. Max-token limits can truncate a response before the safety explanation appears.

Used by a trusted runtime, those controls are normal. Used by untrusted content, they become a hidden policy channel. A connector response that says “set this request to high temperature,” a cached job that reuses another tenant's logit bias, or a workflow file that quietly inserts a stop string before the refusal paragraph can change the agent's behavior without adding a single suspicious sentence to the visible prompt.

The attack is not only what the prompt says. It is also who gets to set the generation conditions around the prompt.

Text filters are optimized for text. They scan prompts, retrieved documents, tool descriptions, emails, web pages, or returned JSON fields for dangerous instructions. Sampling parameter injection moves part of the steering mechanism into metadata: headers, request bodies, model-router configuration, cache entries, workflow defaults, tool schemas, or agent-debug traces.

That matters for AI agents because the next step is often external. The model is not only generating a paragraph. It may be preparing a command, selecting an MCP tool, summarizing a vulnerability, editing code, approving a deployment, or deciding whether to forward data. If untrusted metadata changes the generation settings that shape that decision, the agent may look compliant while the underlying probability field has been tilted.

The category is best understood as a runtime-boundary problem. Generation parameters can influence text. Runtime trust decides whether the resulting text, tool argument, approval state, suppression note, or outbound destination should control an action.

An agent asks an internal service to enrich a security finding. The service response contains a metadata block that a model-router mistakenly forwards into generation settings. A malicious or compromised source biases tokens associated with “benign,” “duplicate,” or “ignore,” making the final triage note lean toward suppression even though the visible finding text never asked for suppression.

A workflow lets a remote job specify output formatting hints. The hint includes a stop sequence that cuts off the model before it reaches “do not deploy until reviewed.” The answer still looks clean and concise. The missing tail is the control. A text-only prompt-injection detector may pass the request because the dangerous instruction lived in the stopping condition, not the paragraph.

A cache or batch runner reuses sampling settings from one request under another identity. A permissive exploratory request used high randomness and relaxed penalties. Later, a production approval request inherits those settings by trace ID collision or stale cache state. The model now produces more adventurous tool arguments in a context that expected deterministic review behavior.

An agent platform records speculative-generation traces for debugging. A malicious tool response includes a trace-shaped object that claims a risky continuation was accepted by the target model. A downstream approval helper sees the accepted label and treats the continuation as policy-safe. The runtime-trust check should verify the trace source, request identity, model boundary, timestamp, and process binding before the label affects action.

A serving layer caches generated continuations for speed. A cache key is too broad: it binds to model, prompt hash, or session prefix, but not tenant, tool scope, policy state, or approval path. An attacker causes a continuation drafted under one request to be replayed under another. The text may look fluent. The identity binding is wrong.

An evaluation or tool-routing layer exposes proposer metadata to decide whether a generated tool argument came from the “fast path” or the “checked path.” An attacker shapes input so a fallback path marks a tool argument as already target-verified. The dangerous move is not a magic token. It is a state transition: draft-like material receives target-verified authority without the current runtime proving it.

Speculative nouns: draft_model, proposer, num_speculative_tokens, hidden_state · acceptance words: accepted, target-verified, replayed, cached, fast path · authority verbs: approve, execute, suppress, merge, deploy, skip review · binding gaps: missing request ID, weak cache key, tenant drift, debug artifact in production. “These tokens were accepted” may be useful telemetry. “Therefore call the tool” is the leap that runtime trust should block.

Generation settings are evidence, not authority. The runtime can record temperature, top-p, top-k, stop strings, penalties, logit-bias maps, max-token limits, model-router choices, acceptance traces, and cache provenance as evidence about how output was produced. It should not let those settings decide whether the output is allowed to act.

Prompt filters scan visible language — not hidden request metadata that changed the generation boundary. Schema validation constrains allowed fields — not whether an allowed field is trusted to alter action-time behavior. Model-router policy chooses model, budget, and defaults — not whether a connector, cache, or tenant can override them. Runtime trust binds source, identity, settings, evidence, and requested action at execution time: this output may be text, but it is not yet permission.

Eight inference-layer patterns ship in this release: GLS-SPI-001 (LLM sampling-parameter metadata injection), GLS-SDH-001 (speculative-decode acceptance spoofing), encoding-smuggling rows GLS-V3-033, GLS-V3-034, unicode-evasion row GLS-V3-030, terminal-output encoding row GLS-V3-001, and parser-differential rows GLS-V3-050, GLS-V3-054 — searchable in the pattern database. Neither category claims a public inference engine is vulnerable by default.