How to Secure LLM Systems Against Prompt Injection Attacks

Large language models (LLMs) process every token in their context window as potential instruction—whether it comes from a system prompt, user input, or retrieved documents. This design creates a fundamental vulnerability: prompt injection attacks trick models into treating attacker-controlled data as directives. Relying solely on keyword filtering or output sanitization won't stop determined adversaries. Instead, security requires a layered approach where each defense addresses specific weaknesses while acknowledging its own limitations.

The Core Flaw: No Hard Boundary Between Data and Instructions

LLMs interpret all content within their context window uniformly. When an attacker crafts a prompt that embeds malicious instructions within seemingly benign text, the model has no innate mechanism to distinguish between the two. This ambiguity means traditional security measures like allowlists or blocklists—built on literal string matching—are fundamentally insufficient against semantic evasion.

Security experts emphasize that filtering alone cannot resolve this issue. Instead, organizations must adopt defense-in-depth, combining multiple security layers where each addresses a different attack vector while compensating for the weaknesses of others.

Evaluating Defense Layers: Strengths, Weaknesses, and Real-World Impact

Security frameworks for LLM systems often prioritize layered defenses, but understanding each layer's limitations is crucial for effective implementation.

1–2. Absent or Minimal Guardrails

The baseline scenario involves an LLM exposed without any restrictions. In this configuration, models may inadvertently disclose sensitive information stored in their context windows if prompted directly. While seemingly obvious, this scenario remains common in early-stage AI integrations where developers prioritize functionality over security.

3. Input Filtering Using Keyword Blocklists

• How it works: Systems scan incoming prompts for banned terms such as "secret," "password," or "reveal" and reject or sanitize matches.

• Where it fails: Attackers bypass blocklists using synonyms, misspellings, leetspeak (e.g., "s3cr3t"), or fragmented phrases. Filtering strings does not filter intent—only the literal characters.

• Better approach: Implement allowlists instead of blocklists. Use semantic classification to detect intent rather than matching specific terms. Treat all input as untrusted, and enforce rate limiting to detect probing attempts.

4. Output Filtering to Catch Sensitive Data Leaks

• How it works: Systems monitor model outputs for exact matches of known secrets and redact them before delivery.

• Where it fails: Techniques like splitting the secret into fragments, inserting separators, or encoding characters (e.g., base64) prevent literal string matching. The redacted content may still be reconstructed by recipients.

• Better approach: Minimize exposure of sensitive data within model context windows. Never rely solely on output filtering—treat it as a secondary check, not a primary control.

5. Combining Input and Output Filtering

• How it works: Stacking input and output filters raises the difficulty for attackers by forcing them to evade multiple systems.

• Where it fails: The combined weaknesses persist. Obfuscated input can bypass input filters, and fragmented output can evade output filters. Layering improves security but does not eliminate vulnerabilities.

• Key insight: More filters do not equate to stronger security. Each layer must be designed to address specific attack classes, not just add complexity.

6. Using a Second LLM as a Semantic Guardrail

• How it works: A separate LLM reviews outputs for sensitive content that might have evaded primary filters, catching obfuscated or semantically transformed secrets.

• Where it fails: Adversaries can manipulate the guardrail model through social engineering—reframing sensitive data as harmless or presenting it in unconventional formats the judge LLM does not recognize. Guardrail models inherit the same manipulability as the primary model.

• Better approach: Combine LLM-based guards with deterministic checks. Constrain the primary model's access to sensitive data and use traditional validation rules alongside AI-driven monitoring.

7. Human-in-the-Loop Review

• How it works: Human reviewers inspect model outputs for sensitive disclosures before final delivery.

• Where it fails: Humans review rendered text, not raw input streams. Techniques like ASCII smuggling embed invisible instructions or data within the raw payload that remain invisible to reviewers but are processed by the LLM. This flaw makes human oversight ineffective against certain attacks.

• Better approach: Sanitize and normalize raw input before it reaches either the model or human reviewers. Avoid relying solely on human review of displayed content.

The Hidden Threat: ASCII Smuggling and Its Real-World Consequences

ASCII smuggling represents a critical class of application-layer vulnerabilities that exploit discrepancies between rendered text and raw data streams. By embedding invisible or obfuscated characters, attackers hide instructions or sensitive data that LLMs process while remaining undetected by users or traditional filters.

How Attackers Exploit ASCII Smuggling

Attackers leverage several categories of invisible characters to smuggle malicious payloads:

• Unicode Tags Block (U+E0000–U+E007F): Deprecated control characters that appear as nothing in most interfaces but are fully processed by LLMs.

• Zero-width characters: Characters like Zero-Width Space (U+200B) or Zero-Width Non-Joiner (U+200C) insert invisible separators that affect tokenization but remain invisible to users.

• Bidirectional controls and format characters: Characters in the U+202A–U+202E range reorder text display while preserving logical structure, enabling attacks like Trojan Source-style manipulations.

Documented Real-World Exploits

Research from FireTail (September 2025) demonstrated practical impacts of ASCII smuggling across multiple LLM-powered systems:

• Identity spoofing: A tampered calendar invite embedded invisible text that altered the organizer's identity. The assistant processed the spoofed identity while the human reviewer saw only the visible text.

• Autonomous data exfiltration: A hidden instruction within an email told an assistant connected to an inbox to search for and leak specific sensitive documents. The model executed the instruction despite the visible text appearing benign.

• Content poisoning: A product review contained invisible text instructing a summarization model to include promotional links or fabricated customer consensus.

The study found vulnerabilities in models from Gemini, Grok, and DeepSeek, while ChatGPT, Copilot, and Claude demonstrated robust input sanitization against these techniques.

Securing Systems Against ASCII Smuggling

Defending against these attacks requires focusing on the application layer rather than the model itself:

• Sanitize raw input streams: Strip invisible characters, normalize Unicode using NFKC transformation, and validate input before tokenization.

• Use allowlists for Unicode: Define permitted character categories rather than chasing known bad ranges. This prevents attackers from leveraging unexpected Unicode blocks.

• Monitor input anomalies: Flag inputs where the visible character count diverges significantly from the raw code-point count—a strong indicator of obfuscation attempts.

• Extend protections to RAG systems: Treat retrieved documents with the same rigor as user prompts. Poisoned documents pose the same threat as malicious messages.

• Log and analyze suspicious inputs: Treat anomalies as security telemetry. AWS and other cloud providers have published guidance on Unicode sanitization techniques that can be adapted for LLM pipelines.

The Path Forward: Building Resilient LLM Systems

Prompt injection and ASCII smuggling represent evolving threats that demand proactive security measures. The key takeaway is that model-level defenses alone are insufficient—application logic, input sanitization, and layered monitoring are essential components of a secure LLM deployment. As organizations integrate LLMs into email clients, calendars, and document processing systems, they must prioritize raw input integrity over rendered output inspection. The future of LLM security lies in anticipating adversarial creativity while maintaining practical usability and performance.