Prompt injection detection techniques fall into a handful of families — static pattern filters, embedding-based classifiers, LLM-as-judge, known-answer probing, perplexity scoring, and canary tokens — and every one of them has a documented bypass. That’s not editorializing; it’s the conclusion of the growing SoK (systematization-of-knowledge) literature on guardrail evasion, and it’s why the OWASP Gen AI Security Project still lists prompt injection as its top LLM risk with no fool-proof prevention method attached. If you’re building detection into an LLM pipeline, the honest goal isn’t “block it” — it’s “raise the attacker’s cost and shrink the blast radius when detection inevitably misses.”
This piece walks through what each detection technique actually does, where it breaks, and what to pair it with. It assumes the attack classes are already familiar; if not, start with the working taxonomy of prompt injection attacks, because what a detector can see depends heavily on which class it is facing. The class that most often defeats a detector deployed on the user turn is the indirect one, where the payload arrives through retrieval or a tool response — the channel inventory for indirect prompt injection is the list of inputs a detector has to cover before its numbers mean anything.
Why detection is structurally hard
The root problem is architectural, not a tooling gap. Transformer-based LLMs concatenate system prompt, retrieved context, tool output, and user input into one token stream with no reliable provenance tag. NIST’s AI 100-2 taxonomy classifies prompt injection as an evasion attack against generative AI systems for exactly this reason — the model has no hard boundary between “instructions I should trust” and “data I should describe,” so any text the model ingests is a candidate command channel.
Simon Willison’s “lethal trifecta” framing makes the practical consequence concrete: once an agent has (1) access to private data, (2) exposure to untrusted content, and (3) a channel to communicate externally, detection is no longer the load-bearing control — it’s a speed bump. As he puts it, guardrail vendors “almost always carry confident claims that they capture ‘95% of attacks’… but in web application security 95% is very much a failing grade,” and the deeper issue is that LLMs “are unable to reliably distinguish the importance of instructions based on where they came from” — everything gets glued into one sequence of tokens regardless of source. Detection techniques are still worth deploying. They just aren’t a substitute for constraining what an agent can do after ingesting untrusted text.
Technique 1: Pattern and heuristic filters
The cheapest layer is regex and keyword matching against known injection phrasing — “ignore previous instructions,” “you are now DAN,” base64 blobs that decode to instruction-shaped text, zero-width Unicode padding used to break tokenizer-level string matches. OWASP’s guidance folds this under content filtering: apply semantic filters and string-checking to scan for disallowed content, and evaluate RAG output for context relevance and groundedness before it reaches the user.
Pattern filters are fast and cheap to run at the edge, but they only catch injections whose surface form was anticipated. Paraphrase the instruction, translate it, split it across two retrieved documents, or encode it as a data structure the model still parses as intent, and the filter passes it straight through. Treat this layer as a tripwire for lazy attackers, not a control.
Technique 2: Fine-tuned classifiers and embedding detectors
The next tier trains a dedicated model — a small BERT-class classifier or an embedding-distance detector — to flag injected text before it reaches the primary LLM. This is genuinely state-of-the-art among automated techniques: it generalizes past exact-string matches and catches semantic variants pattern filters miss.
It’s also the layer with the most published bypass research. A recurring finding across the 2025-2026 SoK literature is that published indirect-injection defenses get bypassed by adaptive adversaries at attack-success rates well above chance, because the classifier is itself a neural network with its own adversarial examples — an attacker who can craft text to fool the primary model can often craft text that fools the guard model with the same gradient-based or black-box search techniques. A classifier trained on last year’s attack corpus is a snapshot, not a moving target.
Technique 3: Known-answer and canary probing
This is a clever, low-overhead trick: embed a probe instruction with a predetermined expected output somewhere in the context, then check whether the model’s response still contains that expected output. If injected content has hijacked the model’s attention away from the legitimate instruction stream, the known answer goes missing or gets altered. It’s cheap because it doesn’t require a separate model — just one extra check against the primary model’s own output.
Rebuff builds a production implementation of exactly this idea, and the review of what its four layers catch and where they fail is the closest thing to a field test of the technique. The limitation is coverage: known-answer detection tells you the model’s instruction-following got disrupted, not what disrupted it or whether a more surgical injection left the canary untouched while still exfiltrating data through a side channel (a tool call, a footnote, a citation URL).
Technique 4: LLM-as-judge and dynamic red-teaming
Running a second LLM call to classify the first model’s input or output as “injected” or “clean” scales better than hand-written rules, and it’s the approach behind several commercial guardrail products. For proactive testing rather than runtime defense, NVIDIA’s garak automates this at scale — it’s an open-source scanner that fires structured adversarial probes at a target LLM across dozens of vulnerability classes, including prompt injection and jailbreaks, and evaluates the responses with purpose-built detectors.
The judge-model approach inherits the same weakness as the primary model: it’s also a token-predicting LLM, so injected text crafted to manipulate one LLM has a reasonable chance of manipulating the judge LLM too, especially if both are drawn from similar model families. Garak and tools like it are best used as a CI-style regression gate — run before every model or prompt-chain change, not as a live production filter. How its probe coverage compares with PyRIT and promptmap, and what each one structurally cannot reach, is broken down in the Garak vs. PyRIT vs. promptmap comparison.
Technique 5: Normalization and invisible-character screening
The layer most stacks skip entirely, and the cheapest one to add. Before any classifier sees a string, decode and normalize it: strip or flag Unicode Tag codepoints and zero-width characters, apply NFKC normalization, decode base64 and hex blobs that resolve to instruction-shaped text, and collapse homoglyph substitutions. Every technique above scores the literal string it is handed, so an invisible payload built from Unicode Tag characters passes a pattern filter, a classifier and a human reviewer at once while remaining fully legible to the tokenizer.
Normalization is not detection — it does not decide anything. It is the preprocessing step that makes the other four layers score what the model will actually read rather than what the page appears to say. Skipping it means your measured detection rate is optimistic by however many encoded variants your corpus never contained.
The detection layers compared
| Technique | What it sees | Cost | Latency | Primary bypass |
|---|---|---|---|---|
| Pattern and heuristic filters | Literal strings matching known injection phrasing | Negligible | Sub-millisecond | Paraphrase, translation, fragmentation across documents |
| Fine-tuned classifiers | Semantic variants of injected instructions | Training plus per-call inference | Low, one small model call | Adversarial examples crafted against the guard model itself |
| Known-answer / canary probing | Disruption of the legitimate instruction stream | One extra check on existing output | None beyond the primary call | Surgical injections that leave the canary intact |
| LLM-as-judge | Fuzzy, context-dependent violations | A second full model call per request | Highest of the five | Text that manipulates judge and primary model alike |
| Normalization screening | Encoded, invisible and homoglyph payloads | Negligible | Sub-millisecond | Nothing directly — it is preprocessing, not a verdict |
Read the table as a stack rather than a menu. Normalization runs first because everything downstream scores its output. Pattern filters run next because they are free. Classifiers and canaries run in the request path. Judge models run only where the cost is justified by the consequence of the action being authorized. No row closes the hole, and the last column is why.
Whichever combination you deploy, the number that matters is attack success rate measured against a fixed corpus over time, not a one-off clean run — the method for producing that number is in prompt injection testing: a repeatable method.
What actually reduces risk
Given that no single detector closes the gap, the OWASP guidance and the agent-security literature converge on layered, non-detection controls, sequenced by cost and impact in the layered mitigation guide:
- Privilege limitation. Give the model only the API scopes and data access it needs for the task at hand, not standing account-wide credentials.
- Content segregation. Tag untrusted external content (retrieved documents, tool output, email bodies) distinctly from system instructions in your prompt construction, even though the model can’t fully honor the boundary — it still raises the bar for naive injections.
- Human approval on consequential actions. Anything that writes data, spends money, or sends a message externally should require a checkpoint, not a model’s unsupervised judgment call.
- Break the lethal trifecta. Don’t let a single agent session simultaneously hold access to sensitive data, exposure to untrusted input, and an external communication channel — remove one leg and most exfiltration paths collapse regardless of whether detection caught the injection.
- Adversarial regression testing. Run garak or an equivalent probe suite against every prompt-chain or model change before it ships, and track attack-success rate over time rather than treating a single clean run as proof of safety.
Which of those controls your application actually needs depends on which attack classes its architecture makes reachable. The injection threat modeler resolves that from your building blocks — retrieval, browsing, tools, memory, file upload — and returns the reachable classes with the defenses that apply to each. For what happens when none of this is in place in a shipped commercial product, the Bing Chat / Sydney incident is the documented case.
For broader technique coverage — RAG-specific poisoning vectors, agent tool-call hijacking, and disclosed jailbreak incidents — see the tracking on aisec.blog and the guardrail tooling roundups at guardml.io.
Related across the network
- Tool-Call Hijacking in Agentic Systems — aiattacks.dev
- How Prompt Injection Detection Works: From Classifiers to Runtime Monitors — aisecreviews.com
- OWASP LLM Top 10 2026 Changes: What’s New, Gone, and Coming — aisecweekly.com
- How to Detect Prompt Injection Vulnerabilities in LLM Apps — bestllmscanners.com
