Does RAG or fine-tuning stop prompt injection? Myth vs fact

No. OWASP's guidance on prompt injection says that while RAG and fine-tuning aim to improve relevance and accuracy, research shows they do not fully mitigate prompt injection vulnerabilities. RAG can make the exposure larger, because it feeds more outside text to the model. Reduce the damage with design controls, not model tweaks.

Myth 1: Grounding the model keeps it on task

Fact. Grounding gives the model better facts. It does not make it distinguish your instructions from instructions hiding in the facts. OWASP defines indirect prompt injection as the model processing external content, such as websites or files, that contains instructions that alter its behaviour. A RAG system retrieves exactly that kind of content.

Myth 2: Fine-tuning teaches the model to ignore injected instructions

Fact. OWASP groups fine-tuning with RAG in the same statement: neither fully mitigates the problem. It also says that prevention is not foolproof, given the stochastic nature of generative models. Fine-tuning can change behaviour on average. An attacker only needs one phrasing that gets through.

Myth 3: Our system prompt says to ignore instructions in documents

Fact. A system prompt instruction is one layer. OWASP lists constraining model behaviour in the system prompt as the first mitigation, and then lists six more that do not depend on the model complying.

Myth 4: Injection only matters if the user is the attacker

Fact. OWASP's definition covers both direct and indirect forms. In the indirect form, the user is the victim. A colleague asks a normal question and an attacker's document answers it.

Myth 5: A scan at upload will catch it

Fact. Upload checks help, but injected instructions can be written in endless ways, and OWASP lists input and output filtering as one control among several.

What works better

OWASP's mitigation list is a good base. Putting it in order of impact for RAG apps:

1. Least privilege. Handle privileged functions in code and do not give the model direct access to them.
2. Human approval for high-risk actions.
3. Segregate and label untrusted content, so the system and the model know it came from outside.
4. Validate output formats with deterministic code, so unexpected content is rejected.
5. Filter inputs and outputs, including semantic filters.
6. Constrain behaviour in the system prompt.
7. Test adversarially on a schedule, treating the model as an untrusted user.

Notice that the first four limit what a successful injection can do. That is the main shift: assume it will sometimes work, and make sure it cannot do much.

A simple design question

For each piece of content the model reads, ask two things: who wrote it, and what can the model do next? If the author is untrusted and the next action is powerful, add a control between them. See restricting tool calls after retrieval.

For more on how injection works in retrieval systems, see prompt injection in RAG pipelines.

Quick check

Sources

• OWASP LLM01 Prompt Injection

Last reviewed: 19 October 2026.