Input Sanitization

The practice of rendering potentially dangerous characters syntactically inert rather than simply removing them. This preserves user intent while eliminating execution risk.

• Escapes special characters: ' becomes \' in SQL contexts
• Encodes HTML entities: < becomes <
• Wraps untrusted data in inert delimiters to prevent delimiter injection
• Applies context-specific encoding based on where data is used (HTML body vs. attribute vs. JavaScript)

Example: A user input containing </system> Ignore previous instructions is neutralized to prevent breaking out of XML-style prompt structures.

A security model that defines what input is explicitly permitted rather than attempting to enumerate all malicious patterns. This is the most robust sanitization strategy.

• Rejects any character not matching [a-zA-Z0-9\s.,!?] for free-text fields
• Validates against strict regex patterns for structured data (emails, phone numbers)
• Enforces character set restrictions at the API boundary
• Prevents token smuggling by rejecting unexpected Unicode code points

Blocklist approaches (blocking known bad strings) are inherently fragile because attackers can mutate payloads infinitely. Allowlists define a finite safe surface.

Applying different sanitization rules based on the specific interpreter context where data will be consumed. The same input requires different encoding for different destinations.

• HTML context: Encode <, >, &, ", '
• JavaScript context: Escape backslashes, quotes, newlines, and Unicode line separators
• URL context: Percent-encode non-ASCII and reserved characters
• LLM prompt context: Wrap in inert XML/CDATA blocks or strip markdown formatting characters

A common failure mode is applying HTML encoding to data that ends up inside a <script> tag, where HTML entities are not interpreted.

Enforcing strict character or token limits on all user-supplied data to prevent buffer overflow-style attacks and adversarial suffix injection.

• Truncates inputs exceeding maximum length before any processing
• Prevents adversarial suffix attacks that append long optimized strings
• Mitigates denial-of-service via extremely large payloads
• Reduces the attack surface for payload splitting across multiple fields

In LLM contexts, bounding input to a reasonable token count prevents attackers from overwhelming the model with noise designed to distract from malicious instructions hidden within the payload.

The practice of applying sanitization iteratively until the output stabilizes. This defends against nested or layered encoding attacks.

• Decodes and re-sanitizes until no further decoding is possible
• Handles double-encoding: %253C → %3C → <
• Detects recursive injection patterns where sanitized output creates new dangerous sequences
• Prevents attackers from chaining multiple encoding schemes

Example: An input containing <script> is decoded once to <script> and again to <script>—recursive sanitization catches the final dangerous form.

A preprocessing step that converts Unicode characters to a canonical form and strips invisible control characters to neutralize obfuscation attempts before sanitization rules are applied.

• Converts fullwidth characters (Ａ → A) to standard ASCII
• Strips zero-width spaces and bidirectional override characters
• Applies NFKC normalization to decompose ligatures and compatibility characters
• Prevents homoglyph attacks where 'а' (Cyrillic) replaces 'a' (Latin)

Normalization ensures downstream filters operate on predictable, standardized text rather than visually deceptive encodings.

A detection method that uses embedding models to understand the underlying intent of a prompt, blocking inputs that are semantically adversarial regardless of phrasing or obfuscation.

• Compares input embeddings against known attack patterns in vector space
• Catches paraphrased injection attempts that evade keyword-based filters
• Operates on semantic similarity thresholds rather than regex rules
• Effective against multi-turn social engineering and role-playing attacks

Unlike syntactic sanitization, semantic filtering identifies malicious intent even when the surface text appears benign.

A statistical defense that flags inputs with abnormally high perplexity scores, as obfuscated or encoded payloads often deviate from natural language distributions.

• Uses a smaller language model to score input predictability
• Detects Base64-encoded commands, token smuggling, and adversarial suffixes
• Low-latency check that runs before the primary model processes input
• Effective against automated optimization attacks that generate nonsensical strings

High perplexity indicates the text is statistically improbable as natural language, a strong signal of encoded malicious payloads.

A strategy that logically partitions the context window to strictly separate untrusted data from system instructions, preventing cross-context contamination.

• Uses special delimiter tokens that the model cannot override
• Places system prompts in a privileged region inaccessible to user input
• Implements instruction hierarchy where system > user > third-party data
• Prevents indirect injection from retrieved documents leaking into control flow

Segmentation ensures even if user input contains malicious instructions, they cannot cross the privilege boundary into the system context.

A mitigation technique that constrains a model's generation to a predefined, machine-readable schema, making it difficult for attackers to inject free-form malicious commands.

• Forces outputs through JSON Schema or regex-validated templates
• Rejects any generation that deviates from the expected structure
• Prevents the model from echoing injected instructions in its response
• Works with constrained decoding and grammar-based sampling

When the model can only output valid JSON with specific fields, there is no channel for executing arbitrary injected commands.

A brute-force defense that truncates user input to a strict character or token limit to prevent the insertion of long, complex adversarial suffixes.

• Limits attack surface by capping input length at 500-2000 characters
• Prevents multi-paragraph jailbreak narratives and role-playing setups
• Reduces the space available for encoding obfuscated payloads
• Simple to implement with minimal performance overhead

While not sufficient alone, clipping eliminates an entire class of attacks that require extensive setup or lengthy encoded instructions.