Prompt Injection vs Jailbreak: A Defense Checklist for Local RAG and Agents
Prompt injection vs jailbreak is a distinction many people miss: they treat the two as the same thing, and assume that a model running locally with no internet is safe. They are aimed at different things. A jailbreak mostly targets the model’s own safety training; prompt injection targets the application you built, by getting the model to treat text inside untrusted content as instructions. Local RAG (a model reading your documents, often through a chat front end) and agents (a model calling tools) are exactly where the second kind bites. This article gives a comparison table, a “lethal trifecta” risk check and a layered checklist. It covers defense and concepts only: no working attack prompts and no bypass steps, and every example is abstract. Sources were read on 2026-11-04, and nothing here depends on a particular product or version.
Key points (updated 2026-11-04)
- Jailbreak: a user tries to make the model ignore its safety rules. Prompt injection: text in untrusted content (a web page, a document, an email) is treated as instructions and changes what the application does.
Terminology is not settled: OWASP treats jailbreaking as a form of prompt injection, while Simon Willison, who coined “prompt injection,” treats them as different problems. We separate them by attack target.
Running locally does not make you immune: if the model reads untrusted content it can be influenced, and OWASP notes that RAG and fine-tuning do not fully mitigate prompt injection.
The framework for agent risk is the “lethal trifecta”: access to private data, exposure to untrusted content, and the ability to communicate externally. With all three, an attacker may get the agent to send your data out.
No single defense is 100% reliable: even a 95% block rate leaves about a 64% chance that at least one of 20 attacks succeeds (a hypothetical calculation).
Prompt injection vs jailbreak: what is different
| Dimension | Jailbreak | Prompt injection (including indirect) |
|---|---|---|
| Who attacks | Usually the user chatting with the model | A third party who can influence web pages, files, email or knowledge-base content |
| Main target | Make the model ignore its safety rules | Hijack the application: leak data, take actions, output misleading content |
| Entry point | The user’s input box | Anything the model reads |
| Who bears the impact | Mainly the model provider’s safety and reputation | The application’s developers and users |
| Defense focus | Model training, guard models, refusal tests | Trust boundaries, least privilege, output checks, human approval |
| Meaning for local users | Depends on the model and whether guardrails were removed | Needed whenever untrusted content is read |
OWASP’s LLM01:2025 defines prompt injection as user prompts altering the model’s behavior or output in unintended ways, and says jailbreaking is a form of it, where inputs cause the model to disregard its safety protocols entirely. Simon Willison says that when he coined “prompt injection” he meant the problem of mixing trusted and untrusted content in one context (by analogy with SQL injection), and that directly tricking a model into embarrassing output should be called jailbreaking, a different issue. Both views are defensible. The most useful practical question is the attack target: are you defending against a model that says the wrong thing, or an application that does the wrong thing? For the technique behind removing refusals see refusal-direction ablation explained, and for evaluation see refusal rate benchmarks.
Why local RAG and agents are exposed too
The root cause is that LLMs follow instructions found in content and cannot reliably tell whether an instruction came from the operator or from material they were asked to read; everything is flattened into one sequence of tokens. OWASP’s indirect-injection scenarios include summarizing a web page with hidden instructions, and an attacker modifying a document in the repository used by a RAG application so that, when a user’s query retrieves it, the content changes the model’s output. OWASP also states that RAG and fine-tuning improve relevance and accuracy, but research shows they do not fully mitigate prompt injection.
An abstract example: your local knowledge base includes a document from an outside source, and that document contains a passage addressed to the model rather than to a human, telling it to drop its task and do something else. If the same application can read your private files and make network requests, the outcome is more than a wrong answer. We do not give concrete wording, because defense does not need it.
Score your system with the lethal trifecta
Willison’s “lethal trifecta” is: access to your private data, exposure to untrusted content, and the ability to communicate externally. With all three, an attacker may trick the agent into reading private data and sending it to them. Tick each box for your local setup:
| Private data | Untrusted content | External comms | Our risk judgement (reasoning, not tested) |
|---|---|---|---|
| Yes | Yes | Yes | Highest: full exfiltration chain |
| Yes | Yes | No | High: hard to send out directly, but output or local actions may be tampered with |
| Yes | No | Yes | Medium: low while content is trusted, escalates if sources change |
| No | Yes | Yes | Medium: nothing private to steal, but messages or requests could be abused |
| Yes | No | No | Low |
| No | Yes | No | Low: mainly misleading output |
| No | No | Yes | Low |
| No | No | No | Lowest |
Willison’s conclusion is that end users should avoid combining all three, and developers should constrain an agent that has ingested untrusted input so that the input cannot trigger consequential actions. Running locally removes the external provider from the picture, but it removes none of the three: your local agent can still hold private files, read web pages and email, and make HTTP requests.
Why a 95% block rate is not enough: a worked example
Security products often claim to stop most attacks. Attacks are not one-off, though. Suppose each attack is blocked with probability 95% (a hypothetical number, not a measurement of any product). If an attacker tries 20 times, the chance at least one succeeds is 1 − 0.95^20 ≈ 64.2%. Now suppose your RAG processes 300 untrusted documents a day, and each has only a 1% chance of leading the model astray: the chance of at least one incident in a day is 1 − 0.99^300 ≈ 95.1%. The lesson is that probabilistic filters need structural limits on consequences—least privilege, read-only access, human approval—rather than the goal of catching every attempt. Willison makes the same point: in web application security, 95% is a failing grade.
Three misconceptions worth correcting
“My model is offline, so injection cannot happen.” Being offline removes the network path, not the cause. A local agent that reads a folder of downloaded files or a mailbox is still reading content written by other people. What offline mode does give you is one fewer exfiltration channel, which is why the third element of the trifecta (external communication) is the one you can most easily cut at the network level.
“A stronger system prompt solves it.” A system prompt is itself just text in the same context. It can reduce how often a model follows stray instructions, and it is worth writing carefully, but nothing in the model enforces it. Treat it as one layer, never as the boundary.
“Uncensored models are the only risky ones.” A model with its refusals removed is a jailbreak-and-compliance topic, covered in our legal and compliance article. A carefully aligned model embedded in an agent with broad permissions can still be steered by injected content. The two risks overlap but are not the same, so check both: the model’s behavior, and the application’s permissions.
A layered defense checklist for local RAG and agents
This list combines OWASP’s mitigation advice with Willison’s framework, by layer.
1. Ingest
– Index only trusted sources; label external documents with source and trust level and keep them in a separate store.
– Handle hidden text, invisible characters and odd formatting before ingestion, and spot-check documents of unknown origin by hand.
2. Retrieval and prompt
– Use clear delimiters between system instructions, the user’s question and retrieved material, and state in the system prompt that retrieved material is data, not instructions (this lowers the risk but does not remove it).
– Limit how many retrieved chunks, and how long, the model reads at once.
3. Model and tools
– Least privilege: tools read-only by default, file access confined to specific folders, API tokens held by application code rather than handed to the model.
– Tool allow-lists; disable unneeded network access; restrict external links, image URLs and other channels in model output that could carry data out.
– Require human approval for high-risk actions (sending, deleting, paying, running commands).
4. Output
– Validate output formats, require citations and check with deterministic code rather than trusting the model.
– Scan output for sensitive data and anomalies.
5. Operations
– Log tool calls and retrievals so incidents can be traced.
– Run adversarial tests regularly, treating the model as an untrusted user to test trust boundaries and access controls; retest after changing the model, prompt or knowledge base.
When choosing software, check whether it supports these controls; see the local AI app roundup. For building the knowledge base see local RAG, the AnythingLLM tutorial and Dify and RAGFlow; if you expose an endpoint to your LAN, see the local API server and Open WebUI. For company-level controls see the enterprise content-safety checklist.
How we checked this, and what we did not do
Definitions and mitigation advice come from the OWASP LLM01:2025 page; the lethal trifecta and the terminology distinction come from Simon Willison’s article of 2025-06-16; the probability examples are our hypothetical calculations. We did not attack any software, did not measure the block rate of any defensive product and provide no attack prompts or bypass methods; the risk table is our reasoning and should be checked against your actual architecture.
FAQ
Are prompt injection and jailbreak the same thing?
Opinions differ: OWASP treats jailbreaking as a form of prompt injection, while others consider them separate problems. A practical split is by target: jailbreaks target the model’s safety rules, prompt injection targets the application’s behavior.
Can a locally hosted model still suffer prompt injection?
Yes. If the model reads untrusted documents, web pages or email, text inside them can influence it, whether or not the model runs locally.
What is indirect prompt injection?
The attacking text is not typed by the user but hidden in external material the model reads, such as a web page, a file or a knowledge-base document.
Which agents are most dangerous?
Those that combine access to private data, exposure to untrusted content and external communication. Removing any one of the three greatly reduces the risk of data leaking.
Does telling the system prompt to ignore instructions in content help?
Somewhat, but unreliably; OWASP itself says it is unclear whether fool-proof prevention exists. Combine it with least privilege, output checks and human approval.
Do I need all this for a personal local RAG at home?
At minimum: index only trusted documents, keep tools read-only, do not let the model send anything out automatically, and keep a confirmation step for risky actions.
Want a second pair of eyes on your RAG or agent design?
Join the community or email admin@microaione.com with your software, tools and data scope; companies can reach us through the solutions inquiry page.
More in this series: Jailbreak, “po jia” and cracking compared; How jailbreak defenses work in layers; Red-teaming a local LLM. All articles are collected in the LLM Jailbreak and Safety hub.
References: OWASP LLM01:2025 Prompt Injection, Simon Willison: The lethal trifecta for AI agents, Greshake et al.: indirect prompt injection (arXiv), NIST AI 100-2: adversarial machine learning taxonomy. Read on 2026-11-04.
