One filter is not enough: a layered defense for RAG chatbots

What is this?

On 17 June 2026, a paper titled A Layered Security Framework Against Prompt Injection in RAG-Based Chatbots appeared on arXiv. Its argument is simple and worth taking seriously: most prompt-injection defenses run at a single point in the pipeline, and a single point is never enough for a retrieval-augmented system. An input filter sees the user’s message but never the documents the retriever pulls in. An output monitor sees the model’s answer but only after a malicious payload has already reached the model. Each control has a blind spot, and indirect injection lives precisely in those blind spots.

Prompt injection remains the top entry — LLM01 — in the OWASP Top 10 for LLM Applications, and RAG makes it worse rather than better. In a plain chatbot the untrusted text is whatever the user types. In a RAG chatbot the knowledge base itself becomes an attack surface: one poisoned document, indexed once, can compromise every user whose query happens to retrieve it. The paper frames its contribution as closing that gap with defense in depth rather than a single smarter classifier.

How it works

This is a defensive design, not an attack, so there is nothing operational to redact. The framework places three independent checks along the inference path, each responsible for a different trust boundary.

Layer 1 — input screening. Before anything else, the user’s message is checked by a rule-based pattern library (known injection phrasings, suspicious control sequences) combined with a fine-tuned semantic anomaly classifier that flags inputs which look like instructions to the system rather than questions to be answered. This catches direct injection at the door but, by design, is not trusted to catch everything.

Layer 2 — provenance-based instruction hierarchy. This is the layer that matters most for RAG. When the prompt is assembled — system policy, retrieved documents, user query — the framework tags each span with its origin and enforces an ordering: operator policy outranks user input, and user input outranks retrieved content. Text that arrives from a retrieved document is never allowed to be read as an instruction that overrides the operator’s rules. A poisoned knowledge-base entry can still say “ignore your instructions,” but at assembly time it carries the lowest authority and is treated as data, not command. This directly addresses the indirect-injection path that input filters structurally cannot see.

Layer 3 — output auditing. After generation, the response passes a policy rule engine plus a semantic-drift check that compares the answer against the intended task. If the model has been steered off course — leaking system-prompt content, following an embedded instruction, drifting away from the user’s actual question — the divergence is caught before the answer is returned.

The layers are deliberately redundant. The point is not that any one of them is perfect, but that an attack has to defeat all three, and the three fail in different ways.

Why it matters

The reported numbers give a sense of the effect size: across the authors’ evaluation, layering the three controls reduced attack success rate from about 71% to roughly 11%, while keeping the false-positive rate near 5%. Those are the two figures that decide whether a defense is deployable — a filter that blocks injections but also blocks one in five legitimate queries never survives contact with real users.

More important than the exact percentages is the structural lesson, which generalizes beyond this one system. Teams routinely bolt a single guardrail onto a RAG deployment — usually an input classifier, because that is the easiest place to add one — and treat the problem as handled. It is not. The retrieval step quietly re-introduces untrusted text after the input filter has run, and no amount of tuning the input filter will inspect a document it never sees. Provenance-aware context assembly is the piece most deployments are missing, and it is the piece that specifically defends the RAG-only failure mode where one indexed document poisons many sessions. Recent industry case studies on securing RAG chatbots, such as the Hsinchu smart-tourism deployment, reach a similar conclusion from the applied side.

Defenses

Don’t rely on a single filtering stage. An input classifier alone cannot see retrieved content; an output monitor alone acts too late. Assume each control has a blind spot and place independent checks at input, context-assembly, and output so an attack must defeat all of them.

Tag provenance and enforce an instruction hierarchy. Label every span in the assembled prompt by origin — system, user, retrieved — and make authority follow origin: operator policy outranks the user, the user outranks retrieved documents. Retrieved text should be structurally incapable of overriding your rules, no matter what it says.

Treat the knowledge base as an attack surface. In RAG, a single poisoned document can affect every user who retrieves it. Vet and monitor ingested content, constrain who can write to the index, and log which documents contributed to a flagged response so poisoning can be traced.

Audit output for task drift, not just banned words. A semantic-drift check that compares the answer to the intended task catches steering that a keyword filter misses — system-prompt leakage, an answer that quietly follows an embedded instruction instead of the user’s question.

Measure the false-positive rate, not just the block rate. A defense that blocks attacks but rejects a large share of legitimate queries will be turned off. Report both numbers and tune for a usable operating point before shipping.

Status

Item	Reference	Date	Notes
Paper	arXiv:2606.19660	June 2026	Three-layer defense for RAG chatbots
Layer 1	Input screening: rule-based patterns + fine-tuned anomaly classifier	—	Catches direct injection at input
Layer 2	Provenance-based instruction hierarchy at context assembly	—	Retrieved content cannot override operator policy — the key RAG defense
Layer 3	Output audit: policy rule engine + semantic drift	—	Catches steering after generation
Reported effect	Attack success ~71% → ~11%; false-positive rate ~5%	—	Authors’ own evaluation
Context	OWASP LLM01; related RAG case study arXiv:2509.21367	2025–2026	Prompt injection ranked most critical LLM risk

The framework does not claim to solve prompt injection — no defense credibly does today — but it makes a concrete, testable case that RAG deployments need controls at more than one stage, and that provenance-aware context assembly is the stage most often left out. For anyone running a retrieval-augmented chatbot, that is a cheap architectural change to evaluate against a genuinely hard failure mode.