Input Sanitization Pipelines for LLM Security

Prompt injection is a structural property of how large language models work, not a bug that a patch fixes. It is a structural property of how large language models work, which means every input sanitization pipeline built to stop it is a risk-reduction layer, not a cure. That distinction determines which defenses can work as a cure and which only reduce risk, and the rest of this piece explains why.

The threat taxonomy the pipeline must address

Start with the split that matters most: direct versus indirect injection.

Direct injection is the easy case to picture. A user types something malicious straight into the chat box, trying to override the system prompt or coax the model into ignoring its own rules. The attacker owns the input channel, so at least you know where to look.

Indirect injection is worse, and it's worse precisely because the user did nothing wrong. The malicious instructions sit inside a web page, an email, a PDF, a database record, anything the model retrieves on its own. The user just asked a normal question. The poison came in through the side door, riding along with content the system was supposed to trust.

Prompt injection has sat at LLM01, the top spot on OWASP's Top 10 for LLM Applications, across every edition published from 2023 through the 2025 update. No other LLM vulnerability has held that position for that long, and that consistency alone should tell you something about how hard the underlying problem is.

The 2025 OWASP list also makes clear that injection is a gateway risk. It's a gateway. A single crafted input can cascade into LLM02 (sensitive information disclosure), LLM06 (excessive agency), LLM07 (system prompt leakage), and LLM08 (vector and embedding weaknesses, added specifically to cover RAG pipelines and vector databases). One bad prompt, four categories lit up at once.

And the attack surface keeps widening. The NVIDIA AI Red Team has documented injection attempts using symbolic visual inputs, emoji strings and rebus-style puzzles. As models increasingly handle both text and images, that cross-modal gap becomes a real problem, one that text-only filters are not built to address. Microsoft, for its part, reports indirect prompt injection as the most widely used AI attack technique in the wild. So the pipeline has to cover direct text, retrieval-borne content, and now images too. That's a wide net to build.

What production incidents confirm about the real stakes

Theory is one thing. Production incidents are what make the threat concrete, and 2025 supplied several.

The clearest example is EchoLeak, tracked as CVE-2025-32711 and disclosed in June 2025 by Aim Security. It hit Microsoft 365 Copilot, and it was zero-click: a remote attacker could send a single email, and Copilot would be coerced into pulling internal files and shipping their contents to an attacker-controlled server. No user click, no attachment opened, nothing for a human to get wrong. Microsoft patched it server-side as part of that month's Patch Tuesday, so customers didn't need to do anything, but the case stands as the first confirmed instance of prompt injection weaponized for actual data exfiltration in a live production system. That's a meaningful line to cross.

Slack AI had its own moment in August 2024. Researchers at PromptArmor showed that injected messages inside a Slack workspace could get summarized by Slack AI in a way that leaked private channel content to someone who was never supposed to see it. The summarization feature, the exact thing meant to save people time, became the exfiltration path.

According to a production security guide published by introl.com, a cluster of incidents in July and August 2025 exposed user chat records, credentials, and third-party application data across multiple systems. And in February 2026, OpenAI shipped Lockdown Mode for ChatGPT and said that prompt injection in AI browsers is "unlikely to ever be fully solved."" That's a major AI lab telling its own users the problem doesn't have a finish line, not hedging. That's a major AI lab telling its own users the problem doesn't have a finish line.

Slack AI, Microsoft 365 Copilot, Cursor, GitHub MCP: these aren't lab demos run by academics trying to make a point. These are production systems serving real enterprises, and in each case the exfiltration ran straight through the retrieval and summarization features that companies are deploying by the thousand right now.

How a layered input sanitization pipeline is constructed

Production LLM safety is a stack. It's a stack, and each layer in that stack is built to catch a different failure mode: prompt injection, PII leakage, jailbreaks, tool-calling agents doing too much, and poisoned retrieval data. Treat any one of these as a stand-in for the whole stack and something will slip through.

Layer 1 is pre-model input validation. The goal is simple to state and hard to execute: keep unsafe content from ever reaching the model, the same instinct behind sanitizing SQL inputs. In practice that means pattern matching or lightweight classifiers to flag suspicious text, regex filters for dangerous commands, and character whitelisting on constrained fields like names or account numbers. High-risk input can get rewritten, truncated, or rerouted through a moderation pipeline before it ever touches the main model. Keeping instructions and dynamic content in separate fields, rather than mashing them into one prompt string, cuts down on how much the model has to sort out on its own.

Layer 2 is prompt template hardening. Injection works in the first place because system instructions, developer instructions, and user input all share the same context window, the same stream of tokens. Separating those structurally, using delimiters or tags that the model has been trained to treat as literal text rather than commands, narrows the room an attacker has to work with.

Layer 3 covers RAG and retrieval. Retrieved documents are the riskiest input class there is, because they walk straight past every filter applied earlier in the pipeline. If nobody's watching who can write to the vector store, the store itself becomes an attack surface. That means locking down the ingestion pipeline, controlling who or what can add or edit records, and scanning external documents before they join the knowledge base. OWASP added LLM08:2025 Vector and Embedding Weaknesses specifically to address retrieval-layer risks like this.

Layer 4 is guardrail middleware, sitting between the user and the model, checking traffic in both directions. Input guardrails scrub prompts before the model sees them; output guardrails inspect what comes back before it reaches the user; system-level guardrails enforce policy across the whole exchange; things like instruction hierarchy (system prompts outrank user prompts), memory management so old context can't be quietly weaponized, tool-use limits, and logging.

Layer 5 is tool-use and agent permissions. Least privilege, applied to what an agent is allowed to call and with what arguments. Anything consequential, sending an email, moving money, touching a production database, pushing code, should require a human to sign off before it executes. OWASP classifies unchecked tool access as LLM06:2025, Excessive Agency, and it's easy to see why: an agent with too much reach turns a small injection into a large incident.

Layer 6 is output validation. Sanitizing the input doesn't guarantee a clean output. Structured checks on what comes back from the model catch malformed JSON, missing fields, schema mismatches, and things that shouldn't be there at all, credit card numbers, API keys, anything matching a pattern the response should never contain.

None of this works without logging, and logging shouldn't be treated as paperwork for an audit nobody reads. Rejected prompts, repeated abuse attempts, structured JSON events with timestamp, user, action, and status: that's the raw material for spotting a pattern before it becomes an incident.

Open-source tools and frameworks available to build each layer

Nobody's building all six layers from scratch, and there's a decent open-source ecosystem to draw from, though each piece only covers part of the stack.

Meta's LlamaFirewall, announced in April 2025, bundles three guardrails into one system: PromptGuard 2 for catching jailbreaks and injection attempts in real time, Agent Alignment Checks for spotting goal hijacking in an agent's own reasoning, and CodeShield, which does static analysis to stop the model from generating insecure code. On the AgentDojo benchmark it cut attack success rates by more than 90%, and Meta runs it in production. But researchers at Trendyol found a gap: Unicode-based invisible prompt injections, text that looks harmless to a human eye but hides instructions, slip past it, because the firewall judges them non-malicious.

NVIDIA's NeMo Guardrails splits the problem into five rail types, input, dialog, retrieval, execution, and output. Version 0.17.0 shipped in October 2025, and NVIDIA itself says the project isn't recommended for production use as-is in its current beta state, so anyone building a launch plan around it should account for that.

LLM Guard, an open-source project under the MIT license with over 4,200 GitHub stars, ships pre-built scanners for both input and output covering toxicity, PII, and prompt injection detection. Meta's Prompt Guard is a multilabel classifier fine-tuned from mDeBERTa-v3-base, an 86M-parameter model, built to catch both jailbreaks and indirect injection. Researchers have since demonstrated attacks that evade it entirely, 100% success rate, which is a useful reminder that no single classifier closes this out on its own.

Protect AI has released two open prompt injection models, v1 in November 2023 and v2 in April 2024, both fine-tuned from DeBERTa-v3-base at a parameter count in the hundreds of millions. Beyond that, the ecosystem includes Guardrails AI (focused on validation policies covering formatting and content filtering), IBM's Granite Guardian, WhyLabs LangKit for inspecting context windows, and Microsoft Presidio, which sits alongside NeMo Guardrails and Llama Guard as open tooling covering different slices of the same pipeline.

The honest read here: every one of these tools handles a slice. None covers the whole stack, and that 100% evasion result against both Azure Prompt Shield and Meta Prompt Guard is the clearest evidence that treating any single tool as a full solution is a mistake waiting to happen.

Model-level and architectural defenses that go beyond input filtering

Filtering input is one approach. Changing how the model itself behaves is another, and the research here has moved fast.

SecAlign, a fine-tuning method, brought the attack success rate of the strongest tested injection down to 8% on Llama3-8B-Instruct, without a measurable hit to the model's general usefulness. An improved version of SecAlign was later used to build what's described as the first open-source, commercial-grade 70B model with prompt injection defense built in, described as commercially viable for deployment.

ReasAlign, from January 2026, pushed the numbers further: 94.6% utility with only a 3.6% attack success rate on the CyberSecEval2 benchmark, a noticeably better trade-off than SecAlign posted on the same test. But that number comes with a catch: these benchmarks test against attackers who don't know they're being tested against a defense. These benchmarks test against attackers who don't know they're being tested against a defense, making them static. They're static. An adversary who knows what ReasAlign or SecAlign looks like, and optimizes specifically to beat it, is a different animal.

Research on adaptive attack methods demonstrates this pattern. Tools optimized to defeat specific defenses generalize readily to benchmarks they were never trained against. The lesson lands hard: a defense that scores well on a static benchmark can still fall apart against an attacker that adapts. Which raises the obvious question. If a defense trained on 100 examples can break every fixed benchmark it meets, how much should anyone trust a benchmark score as a measure of real-world safety?

A complementary architectural philosophy takes a different angle entirely, one built around containment rather than prevention. Rather than trying to stop the model from ever being fooled, such designs assume it might be, and contain the damage regardless, for example by strictly separating the components that handle trusted instructions from those that process untrusted external content, so a compromised retrieval step cannot act on what it reads.

Why agentic systems push sanitization pipelines to their limits

Independent researcher Simon Willison named the pattern in 2025 that ties much of this together: the lethal trifecta. Three conditions, present together, make an agent fully exploitable: access to private data, exposure to untrusted content, and a way to send information out to the world. Any agent with all three is a target. Take away even one, and the attack path collapses.

That framing explains why agentic systems are so much harder to secure than a single chatbot turn. A basic Q&A bot might have access to sensitive documents but no way to send that data anywhere. An agent wired into email, a code repository, and a browser has all three legs of the trifecta at once, often by design, because that's what makes it useful. Attack success rates in agentic settings have reportedly reached 84%, and production exploits have carried CVSS scores above 9.0. That's a different category of exposure entirely from a rounding error on last year's chatbot risk. That's a different category of exposure.

Indirect injection is where this gets hardest to reason about. An agent reading a webpage to complete a task cannot reliably distinguish between the page's actual content and a hidden instruction planted inside it, because both arrive as the same kind of token, processed through the same attention mechanism, with no privilege separation baked into the architecture. The actual issue this entire piece keeps circling back to is that there's no equivalent yet of the parameterized query that solved SQL injection, no clean line between code and data inside a transformer.

Enterprise security teams have started treating this as a vendor management problem as well as an engineering one. It's no longer enough to secure one internal chatbot. Organizations now run AI features across Slack, Microsoft 365 Copilot, coding assistants, and a rotating cast of third-party tools, and each one is a fresh injection surface with its own patch cycle and its own blind spots. Tracking which vendors introduce new exposure, and how fast they respond once something breaks, has become its own discipline. Promptarmor is one of the firms working in that space, watching how injection risk moves across vendor AI ecosystems as those systems keep expanding.

The pipeline described across this piece, six layers deep, backed by open-source tooling and model-level defenses, cuts risk substantially. It does not remove it. Given that even OpenAI has said publicly that this problem may never be fully solved, the honest posture for anyone building on these systems is one of ongoing vigilance rather than a finished checklist. The threat model shifts every time a new modality, a new tool, or a new agentic pattern gets bolted on, and the defense has to shift with it.