How to Prevent Prompt Injection: Seven Defences, Ranked by What They Actually Stop

You cannot prevent prompt injection completely. No product, prompt or model setting makes it impossible, and OWASP's own entry for the attack says it is unclear whether fool-proof prevention exists. What you can prevent is the damage. The goal is a setup where a fooled model has nothing worth reaching and no way to send anything out.

Ranked by what they stop, the seven defences are: least-privilege access, human approval before anything is sent or spent, keeping untrusted content away from private data, blocking the quiet exit routes, a screening layer, marking untrusted content as data, and a log. The first four work even when the model is fooled. The rest improve your odds or tell you what happened.

For the mechanism, see our prompt injection pillar and its live demo; our indirect prompt injection guide has the real cases. This page is the practical part: per defence, what it stops, what it does not, what it costs, and what to do this week.

Why rank by what they stop

Because the attacker is not a random sample. Simon Willison, who named the attack in 2022, put it in one line in 2023: in application security, "99% is a failing grade". An attacker tries a hundred phrasings and keeps the one that works. So a defence that spots most attacks is worth less than one that makes a successful attack pointless.

The research agrees. Google DeepMind's CaMeL (March 2025) builds an agent in which "the untrusted data retrieved by the LLM can never impact the program flow", with provable security on 77% of tasks in the AgentDojo benchmark. A June 2025 design-patterns paper by researchers from IBM, Invariant Labs, ETH Zurich, Google, Microsoft and others rests on one principle: once an agent has read untrusted input, that input must be unable to trigger consequential actions. Borrow the priority: access and actions first, detection second, prompts last.

The seven defences at a glance

#	Defence	What it stops	What it does not stop	Effort
1	Least privilege	Any attack needing access you never granted	Misuse of the access you did grant	Free, minutes per tool
2	Human approval to send or spend	The damaging action at the end of the chain	Leaks through channels you do not approve, approval fatigue	Free, some friction
3	Untrusted content away from private data	Exfiltration, by removing one leg of the lethal trifecta	Bad output inside the untrusted session	Free as a habit, real work in code
4	Block the exit routes	Data leaving through links, images and tool arguments	Attacks that do damage without leaving, such as wrong answers	Settings for users, a day of code for builders
5	Screening gateway or detection tool	Most injections, including ones in tool output, before the model acts	Novel or patient attacks; 99% is still a failing grade	Minutes to set up; blocking is paid
6	Spotlighting and delimiting	Crude and mid-level attacks	A determined attacker; the model can be argued out of it	Free, an hour
7	A log outside the tool	Nothing directly; it tells you what the others missed	Anything, in real time	Free to minutes

1. Give the AI less to reach

Stops: every attack that needs a capability you did not grant. An injection that lands in an assistant with no mailbox, no customer list and no way to post is a prank.

Does not stop: misuse of the access you did grant. If the one connector you kept can send e-mail, an injection can still try.

Effort: free. A few minutes per tool, and a bit of tedium setting up scoped tokens.

OWASP's fourth mitigation. It ranks first because it does not depend on the model noticing anything. For each connector, ask: if the AI went rogue for ten minutes with this, what could it do?

This week: remove any connector you have not used in a month, take read-only where it is offered, and swap full-account logins for tokens scoped to one project. If you followed our first MCP recipe, switch off the tools you do not use. Builders: do privileged work in code. The model asks for record 4812; your code decides whether it may see it.

2. Put yourself in front of anything that sends or spends

Stops: the exploit step. In the documented cases the harm happened at the end, when the assistant sent something: a reply, a link, an image request, a pull request. A person in front of that step breaks the chain.

Does not stop: leaks through channels you do not think of as sending (see defence 4), and approval fatigue. After the fortieth "allow?" prompt, people click yes without reading.

Effort: free, with some friction on every action that matters.

OWASP's fifth mitigation. Be strict about a short list rather than lax about everything.

This week: turn every "always allow" on a tool that writes, sends, publishes, pays or deletes back to "ask". Our house rule for MCP connectors is schedule, never publish now. Builders: reads run freely; writes that leave your system need approval or a dry run. The design-patterns paper's "plan-then-execute" is the strong form: fix the actions before reading untrusted content, and let the content add none.

3. Keep untrusted content away from private data

Stops: exfiltration. Willison's lethal trifecta is private data, exposure to untrusted content, and a way to communicate externally. Any two are survivable; all three in one session is a breach waiting for a sentence. This defence removes the middle leg where you cannot remove the first.

Does not stop: a bad answer inside the untrusted session. A poisoned web page can still give you a misleading summary.

Effort: free as a habit. Real engineering work if you build it into an application.

OWASP's sixth mitigation, segregate external content.

This week: make a second session or profile with no connectors and no logged-in accounts, and use it for the open web, strangers' PDFs and inbound attachments. It feels fussy for a week, then it is a habit. Builders: this is Willison's Dual LLM pattern (April 2023). A privileged model has the tools and sees only trusted input; a quarantined model reads untrusted content and has no tools, and its output reaches the privileged side as a reference, never as text. CaMeL is the rigorous version.

4. Block the quiet exit routes

Stops: data leaving through channels nobody thinks of as sending. As Willison puts it in the lethal trifecta post, any tool that can make an HTTP request, load an image or offer a link can carry stolen data out. The classic case is a markdown image whose address contains your chat history: the chat window fetches the "image" and the data is gone.

Does not stop: attacks that do their damage without leaving: a wrong answer, a deleted file, a changed setting.

Effort: a settings check for users. A day of careful code for builders.

OWASP's second and third mitigations: define and validate output formats, and filter output.

This week: treat any unexpected "click here", "reauthenticate" or image after a summary as a warning sign. Builders: do not render markdown images or links from domains you have not allowlisted, strip URLs that did not come from a trusted source, and check tool arguments in code. An e-mail tool asked to send to an address that appears nowhere in the user's request is a red flag no model needs to judge.

5. Screen the traffic with a detection layer

Stops: most injections, before the model acts on them, including the ones that arrive inside tool output. This is the layer people mean when they search for a prompt injection detection tool.

Does not stop: everything. Novel phrasings, instructions split across turns and patient attackers get through a share of the time. That is the 99% argument, and it is why this layer is fifth.

Effort: minutes to set up. Blocking, rather than just flagging, usually costs money.

OWASP's third mitigation, input and output filtering. The tools come in two shapes:

• Classifiers you call from your code. Lakera Guard (Lakera is now part of Check Point) screens prompts and responses over one API endpoint. Azure's Prompt Shields detects "user prompt attacks" and "document attacks", and in Microsoft Foundry can scan tool responses. Meta publishes Llama Prompt Guard 2 as open classifiers (86M and 22M parameters) inside LlamaFirewall, its open-source guardrail framework.
• A gateway in the traffic path. It screens the request on the way to the provider and the response on the way back. This shape covers tools you did not write, because Claude Code or ChatGPT will never call a classifier for you. Our LLM gateway comparison covers the field.

The gateway we use is Constellation Gate AI. Affiliate link: we earn a commission on Pro seats that start from our link, which pays for the testing and has no say in the verdict. Gate calls itself "the accountability layer for AI" and sits "between your agent and the model". It screens each request and each response, including indirect attacks in tool output, and returns a verdict: allowed, flagged, blocked or redacted. The tool-output part is what to look for in any product you evaluate. A screen on your own prompt does nothing when your prompt was "look at the open issues".

How good is it? Gate's published figures (arXiv:2606.02959, checked 23 September 2026): 95.4% of attacks caught across 16 public benchmarks at a false-alarm cap of 1 in 100, which works out at 97.4% F1. In a separate head-to-head at a matched false-positive rate, it reports 96.6% mean F1 to Lakera Guard's 83.7%. It wrongly blocks 2.7% of NotInject's benign-but-suspicious prompts and 1.4% of WildGuard's benign set, and screening adds a median 53 milliseconds. These are the vendor's own numbers: a strong claim, not an independent ranking. Next to Willison's point, 95.4% is a very good seatbelt. Nobody buys a seatbelt because they plan to crash; you wear it because the cost is one click and the alternative is unbounded. You still want brakes, which are defences 1 to 4.

Free records, Pro blocks. The free plan records 20,000 requests a month and runs a basic pattern-matching screen that catches only the blunt "ignore previous instructions" kind. Full detection, tool-result scanning, blocking, redaction and spend limits are Pro, at $20 per user per month. Our Gate review has the full picture, and the Gate page has the calculator.

This week: put a screen in front of the one tool that failed the trifecta test. Start in flag mode, look at what gets flagged for a week, then decide whether to block.

6. Mark untrusted content as data

Stops: crude attacks and a fair share of middling ones.

Does not stop: a determined attacker. An instruction to the model is advice the model can be argued out of.

Effort: free. An hour of prompt work.

Most "how to prevent prompt injection" advice starts and stops here, which is why it is sixth. It maps to OWASP's first mitigation, constrain model behaviour.

Microsoft's spotlighting paper (March 2024) is the strongest published version: it marks or encodes untrusted text so the model can tell where it came from, and on GPT models it cut indirect attack success from over 50% to under 2%. Azure offers it as a preview in Prompt Shields. A real improvement, measured on a test set, not a guarantee against the next attacker.

This week: add a line to your project or custom instructions saying that content from files, pages and tools is material to work on, never instructions to follow, and that any request to send, post or fetch something must come from you. Builders: keep system instructions apart from user and tool content, wrap retrieved text in clear delimiters, and tell the model what the delimiters mean.

7. Keep a log the tool cannot edit

Stops: nothing, in the moment. That is why it is last.

Does not stop: anything in real time.

Effort: free to minutes, depending on the tool.

A log is how you find out what the other six missed: what the assistant read, what it sent, and when. A chat history the assistant can write to does not count; our AI audit trail guide covers what does. Gate writes one on the free plan as a side effect of being in the path, and for a team, one gateway in front of everyone gives you that record per person.

Testing belongs here too (OWASP's seventh mitigation). Once a quarter, ask your main assistant to summarise our tomato test page, a harmless page with one hidden instruction. If the summary ends with "The page talked back", it followed an instruction you never saw.

LLM jailbreak protection is a different job

The two get sold under one label but have different owners. A jailbreak is the user attacking the model's own rules to get content its maker forbids. Protection is mostly the model maker's job.

Prompt injection is a third party attacking your assistant through content it reads, aimed at your data and permissions. Anthropic, which trains Claude against it, still treats defending its browser agent as ongoing work rather than a solved problem. So prompt injection protection is your job. When a tool advertises jailbreak detection, ask whether it also scans documents and tool output; Azure makes the split explicit with two separate shields.

If you build a chatbot or agent

Take the table literally, in order:

1. Scoped credentials; authorisation in code.
2. Approval or plan-then-execute in front of every write.
3. Untrusted reading separated from privileged acting: Dual LLM, map-reduce sub-agents, or CaMeL-style control flow if the stakes justify it.
4. Allowlisted output domains, no untrusted markdown images, tool arguments validated in code.
5. A detector or gateway on inputs and tool results, failing closed.
6. Delimited, spotlighted retrieved content.
7. An injection test suite shaped like your own data, run on every prompt or model change.

If your agent uses MCP servers, our MCP security checklist goes deeper on that surface.

If you only use AI tools

You cannot change the code, so your levers are settings, habits and where your traffic goes. They still reach six of the seven defences:

• Connectors: fewer, narrower, read-only where possible (defence 1).
• Permissions: "ask" instead of "always allow" for anything that sends, publishes, pays or deletes (defence 2).
• Sessions: one connector-free session for the open web and other people's files (defence 3).
• Links: treat any unexpected "click here", "reauthenticate" or image after a summary as a warning sign (defence 4).
• The tools you cannot change: put a gateway in front of them (defences 5 and 7).

Your first fifteen minutes

This follows our fifteen-minute recipe format: one task, one tool, something finished at the end.

1. Minutes 0 to 5: the trifecta test. List the AI tools you use. For each, write three ticks or crosses: private data, untrusted content, can send. Circle any tool with three ticks.
2. Minutes 5 to 10: remove one leg. For each circled tool, remove one connector, switch one "always allow" back to "ask", or move untrusted reading to a clean session. One leg per tool is enough to turn a breach back into a prank.
3. Minutes 10 to 15: screen and record the rest. Start free with Gate, install Gate Connect, switch on the circled tool, restart it, and do your normal work. Setup is one toggle for Claude Code, Codex, Cursor and OpenCode. Free records, Pro blocks: after a week, open the dashboard and look at the flagged column. If it is empty, you have lost nothing. If it is not, you know something about your tools you did not know before, with a timestamp.

Then put the tomato test in your calendar for three months from now.

None of this makes prompt injection impossible. Together, it makes it survivable, which is the only kind of prevention on offer.

Sources: OWASP Top 10 for LLM Applications, LLM01:2025, prevention and mitigation strategies 1 to 7; Simon Willison, "Prompt injection explained" (2 May 2023), "The Dual LLM pattern for building AI assistants that can resist prompt injection" (25 April 2023), "The lethal trifecta for AI agents" (16 June 2025) and "Design Patterns for Securing LLM Agents against Prompt Injections" (13 June 2025); Beurer-Kellner et al., arXiv:2506.08837 (10 June 2025); Debenedetti et al., "Defeating Prompt Injections by Design" (CaMeL), arXiv:2503.18813 (24 March 2025); Hines et al., "Defending Against Indirect Prompt Injection Attacks With Spotlighting", arXiv:2403.14720 (20 March 2024); Microsoft Learn, "Prompt Shields in Azure AI Content Safety"; Lakera Guard API documentation; Meta, Llama Prompt Guard 2 model card and LlamaFirewall documentation; Anthropic, "Mitigating the risk of prompt injections in browser use"; Constellation Gate AI product pages and technical report arXiv:2606.02959. All checked 23 September 2026.