Prompt injection defences for developers: what actually holds

Start from the admission

The UK National Cyber Security Centre’s December 2025 guidance argues that prompt injection may never be mitigated the way SQL injection was, because a language model has no interface at which instructions and data are separated. Its conclusion is the frame for everything below: design protections around deterministic, non-model safeguards that constrain what the system can do, reduce the impact of an attack rather than promising to prevent it, and, where the remaining risk cannot be tolerated, accept that the use case may not be a good fit for a language model. OpenAI said much the same in its December 2025 note on the Atlas browser.

OWASP’s LLM01:2025 entry lists seven mitigations: constrain model behaviour with specific system prompts, define and validate output formats, filter inputs and outputs, enforce privilege control and least privilege, require human approval for high-risk actions, segregate and clearly identify external content, and test adversarially. They are all worth doing. They are not all the same kind of thing, which is what the tiers below are for.

Tier one: controls that hold whatever the text says

Least privilege is the foundation. Give the model, and every tool it can call, the narrowest access the task needs, and scope credentials per task rather than per assistant. The NCSC’s sharper form of the rule is that when the model processes content from a party, its privileges should drop to that party’s, so a system reading strangers’ email holds no privileged tools while it reads. Human approval for consequential actions is the second control: a person confirms anything that sends, pays, publishes or deletes, which is the step Google, OpenAI and Brave have each built into their products.

Egress control is the third. Restrict where rendered content can load from, strip or redact URLs from model output, and refuse tool calls that would move private data to an untrusted destination; Microsoft’s 2023 image-domain allowlist and Google’s 2025 Markdown sanitisation are the same idea applied at different layers. Output validation, requiring the model to answer in a constrained format that downstream code checks, and logging of every tool call complete the tier. None of these depends on recognising hostile text, which is why they hold when recognition fails.

Tier two: architecture that removes the trifecta

Simon Willison’s Dual LLM pattern, described in April 2023, separates a privileged model that can use tools and never sees untrusted text from a quarantined model that reads untrusted text and can do nothing else, with ordinary software passing opaque variable tokens between them. Willison is candid that it is awkward to build and to use, and that it can be defeated by social engineering that gets a person to copy tainted content across the boundary, but the isolation it provides is real rather than statistical.

CaMeL, published by researchers at Google DeepMind and ETH Zürich in March 2025, is the most developed version of the idea. It extracts the control flow and data flow of a task from the user’s trusted request, so that untrusted data encountered along the way cannot change what the program does, and it attaches capabilities to data so that a security policy can refuse a tool call that would send private data somewhere it may not go. On the AgentDojo benchmark it completed 77 per cent of tasks with provable security, against 84 per cent for an undefended agent. The cost is real and the guarantee is real; that trade is what an architectural defence looks like.

Tier three: measures that narrow the attack without bounding it

Spotlighting, published by Microsoft researchers in March 2024, is a family of prompt-engineering techniques that mark where untrusted content begins and ends: delimiting it, interleaving a marker through it, or encoding it so the model can tell provenance from position. In their evaluation it reduced the success rate of indirect injection on GPT-family models from above 50 per cent to below 2 per cent with little loss of task quality. Those are excellent numbers, and they are still numbers: a measure that fails one time in fifty is a strong filter and not a boundary.

Classifiers that detect injected instructions, the “security thought reinforcement” that reminds a model of its real task, and adversarial training against an automated attacker, as OpenAI describes for Atlas, belong in the same tier. Google deploys all of them in Gemini and is explicit that they are layers. EchoLeak is the reminder of the limit: its email passed the classifier by being phrased as advice to a human. Willison’s formulation is the one to remember: guardrails that offer 95 per cent protection are not a security boundary.

What only looks like a defence

A line in the system prompt telling the model to ignore instructions in the data is a request, not a control; the model has no way to enforce it. Keyword blocklists are trivially rephrased around and generate false alarms on every document that discusses security. Keeping the system prompt secret protects nothing once the attacker can observe the system’s behaviour. Relying on the model to refuse addresses jailbreaks, not injection, since an injected instruction usually asks for something permitted.

Detection tools belong on this list too, including the scanner on this site. An input scanner is a review aid at the point where content enters a system: it separates hidden channels from visible text, reveals invisible characters and reports instruction-shaped passages so a person can decide what to ingest. It knows nothing about the receiving system’s privileges and it can be evaded by anyone who studies its public rules. Used in front of tier-one controls it earns its place; used instead of them it is the illusion the NCSC warns against.

A checklist

For each assistant or agent you run, work through the following and write down the answers.

• List every source of text the model reads, including tool results, retrieved documents and the pages it browses; each is untrusted.
• For each combination of tools, check for private data, untrusted content and an outbound channel together, and remove one.
• Scope credentials per task and drop privileges while the model reads content from a less trusted party.
• Put a human confirmation in front of every action that sends, pays, publishes, deletes or changes a record.
• Constrain output to a format that code validates, and never render model output as live Markdown or HTML without sanitising it.
• Redact or strip URLs and external images from output; treat trusted domains with redirects as untrusted.
• Segregate external content from the user’s own instructions and label its provenance all the way to the model.
• Log every tool call with what the model read immediately before it, so an incident can be traced.
• Review content at ingestion for hidden channels, invisible characters and instruction patterns, and keep hard negatives so the review stays usable.
• Red-team continuously, including with automated attackers, and treat any measured success rate above zero as a reason to keep the tier-one controls.