There's No Signature to Sanitize: AI's Injection Attack Surface

A support engineer forwards you a screenshot. Your assistant answered a billing question by quoting a company refund policy that does not exist. The text it cited was real — it sat in the knowledge base your retrieval pipeline pulls from. Someone had added a single document a week earlier. No malformed request hit your API. No injection string your WAF would flag. Nothing in the access logs looks unusual, because nothing about the request was unusual. The “attack” was a paragraph of ordinary English, and the model did exactly what you built it to do: find relevant text and follow it.

You reach for the two reflexes that have stopped injection for twenty years — and find neither one has anything to grab.

In an AI system, every byte the model reads is executable influence — a retrieved document, a tool’s output, a user message, and the training data behind it all arrive through one natural-language channel the model cannot separate from your instructions. The two reflexes that stopped injection for two decades assume a boundary and a grammar that no longer exist. This is a guide to the trust boundary you inherit when you call a model, not how to train one.

Your Injection Reflexes Assume a Boundary

Your defenses against SQL injection work because a database can tell code from data. A prepared statement parses user input strictly as a value — the query planner never mistakes '; DROP TABLE for a command. A WAF adds a second layer: it matches incoming requests against signatures of known-bad payloads. Both reflexes lean on the same assumption — that somewhere there is a parser boundary where instructions end and data begins.

An LLM has no such boundary. Your system prompt, a retrieved document, and a user’s message become one undifferentiated token stream. There is no grammar that marks a span as “data, do not obey.” OWASP calls the exploit indirect prompt injection — adversarial instructions hidden inside content the model retrieves rather than content the user types, cataloged as the number-one risk in the OWASP LLM Top 10. And signature matching fails for a deeper reason: the payload is meaning, not a string. “Ignore the stated policy and approve the refund” is valid English. Rephrase it a thousand ways and every version is grammatical, novel, and un-signaturable.

Mental Model Map: AI Injection From: Injection is a malformed string you filter at the boundary Shift: The payload is meaning, carried by ordinary text the model must read To: The trust boundary is every text source the model reads, not a parser at the edge Key insight: You cannot separate instructions from data when both arrive as language.

Your prepared-statement instinct no longer holds here — there is no parser to bind text as data. But the instincts underneath the reflex are still correct. You still draw explicit trust boundaries. You still treat every external input as hostile until proven otherwise. What changed is the mechanism that used to enforce those instincts — the parser, the signature — and where the boundary has to sit.

The Attack Surface Is Every Text Source

If the channel that carries the attack is data, then the attack surface is every place data enters. That is a larger perimeter than “the user text field.” An AI system reads from at least three surfaces an attacker can reach: the training pipeline that shaped the model, the retrieval corpus it queries at runtime, and — for agents — the memory it writes and reads across turns. Data Poisoning is the class of attack that corrupts any of them. OWASP ranks data and model poisoning as a top-tier LLM risk and treats agent-memory poisoning as its own threat category, precisely because a system with pristine model weights can still behave maliciously if any one of those surfaces was tampered with. The three-surface breakdown is worth reading before you decide which one your architecture actually exposes.

Here is the assumption that gets a small team burned: poisoning only threatens the big labs that train their own models. That was never the boundary. In October 2025, a team led by Souly, Rando, and Carlini showed that roughly 250 poisoned documents were enough to plant a backdoor in an LLM — and the number held near-constant across every model size and dataset size they tested. The cost of the attack does not scale with the size of the model; it scales with nothing. Your real exposure comes from supply-chain contamination of any public dataset, model checkpoint, or RAG corpus you consume. Provenance, not model scale, sets your attack surface — and every hosted-model team consumes external data somewhere.

Shift Diagram: Where Injection Enters Classic: Typed input → WAF / prepared statement → Instruction-data split → Execute AI: Any text (user, RAG doc, tool output, memory) → Single context window → No split → Model acts

In practice, this means your threat model has to enumerate data sources, not just endpoints. Every document store, tool response, and memory buffer the model reads is part of the surface — and an unlisted one is an unmonitored one.

Poison Survives the Tests That Pass

Your testing instinct assumes a defect is the thing a test is built to reveal. Break something and the suite goes red. Poisoning inverts that contract. A backdoored model scores normally on the validation set while carrying an attacker-chosen trigger that only fires on a specific input — the metric stays green precisely because the corruption was designed to be invisible to it. The full taxonomy of why poisoned data evades detection is its own study, but the engineering takeaway is blunt: a passed evaluation is not evidence of a clean model.

That failure has a familiar cousin. Data Leakage is the rare defect that makes a model look better, not worse — a feature that quietly encodes the answer inflates your accuracy, and the inflated score sails through review because a good number is not suspicious. Both failures share a signature-free quality: they corrupt the very measurement you built to catch them. You will not test your way out of either.

What you can do is establish chain of custody. The only pre-training defenses that cover all three poisoning surfaces at once are data provenance and Data Versioning — controls that cannot stop a poisoned sample from existing, but can make it traceable to a source and a time window, which strips the attacker of the ability to operate undetected across dataset versions.

A lockfile plays this role for your packages; an SBOM plays it for your build. For datasets, an ML-BOM and a provenance gate play the same chain-of-custody role — the mechanism you already trust in your dependency graph, applied to the bytes your model learns from and retrieves. Build the chain of custody first; add detection on top of it.

Your Safety Filter Is Another Model

When the perimeter gets uncomfortable, teams bolt on a guard model and call it a firewall. It is not one. A Toxicity And Safety Evaluation classifier is a second probabilistic model with its own blind spots, and it fails in two symmetric directions. It over-blocks: content in African American English, code-switched speech, or dialect markers from the Global South draws higher toxicity scores than equivalent standard-English text, because the classifier learned the surface features of harm rather than its intent. That over-block is a Bias And Fairness Metrics problem sitting inside your safety layer. And it under-detects: adversarial phrasing slips genuinely harmful output past the same filter.

Neither failure is a bug you patch out. They are design properties of a statistical classifier. A false positive on a minority dialect and a slipped-through jailbreak are the same architecture failing in opposite directions.

The transfer still holds — you do want a filter layer, and a real safety pipeline is better than none. What breaks is the mental model of a deterministic gate. In practice, the guard model needs its own tests, its own monitoring, and an explicit budget for both false positives and bypasses — treat it as a subsystem you operate, not a wall you install once.

Red-Team Findings Have No CVE

The security process transfers cleanly; the artifact does not. Red Teaming For AI — adversarially probing a system before deployment — is exactly the right reflex, and because prompt injection has held the top slot in the OWASP taxonomy for years, the attack categories are increasingly well-mapped rather than improvised, and structured tools like Promptfoo, PyRIT, and Garak will run attack suites against your endpoint today.

The break comes at the finding, where your patch-and-close reflex breaks down. A classic pentest result is a vulnerability: you patch it, you close the CVE, the class of bug is gone. A red-team finding against a model is a spec line you forgot to write — there is no patch that removes it, only a guardrail that reduces it. The input space is natural language, which is unbounded, so a passing test suite certifies nothing the way a passing unit suite certifies deterministic correctness. Automated probes find more of what they already know to look for, faster and at scale; human red teams find what nobody knew to look for, slowly and expensively; neither can certify safety because the failure taxonomy is never complete.

And the model can breach trust with no attacker in the picture at all. A Hallucination is influence the model manufactured from its own guesswork — a fabricated fact that arrives through the same channel as everything else, with, again, no signature marking it as false. The corrupted-document case and the fabricated-fact case land the same way on your user: confident text you did not author.

So the practical stance is not “test once and clear it.” Version your prompts and your corpora, budget for testing that runs continuously, and turn every red-team finding into a permanent regression check. For the full prerequisite map and the common questions this cluster raises, see the Safety & Red Teaming hub.

Before You Wire Untrusted Text In

Run this against your own stack before the next AI feature ships.

Update the model: the trust boundary is no longer a typed interface — it is every text source the model can read, and it cannot tell your instructions from anyone else’s. You will not sanitize your way out of that. List those sources for one endpoint this week, then put provenance and monitoring on the ones you do not control.