Prompt Injection Prevention: A Security Checklist for Teams Building AI Features

OWASP defines a prompt injection vulnerability as one where prompts alter a model's behaviour or output in unintended ways. In a direct injection, the person typing into your chatbot tries to override its instructions. In an indirect injection, the model reads outside content, such as a web page, an email, a PDF or a support ticket, and hidden text in that content changes what it does. OWASP notes the injected text does not even need to be visible to a human, as long as the model parses it.

Indirect injection is the one product teams underestimate. The NCSC gives the example of a recruiter using an AI tool to screen CVs: a candidate can hide instructions in their own CV, and the system processes them as if they came from the recruiter. Any feature that summarises, classifies or acts on content written by someone other than your user has this exposure.

SQL injection was solved at the root by parameterised queries, which keep code and data in separate channels. The UK National Cyber Security Centre argued in December 2025 that this comparison is dangerous: current large language models simply do not enforce a security boundary between instructions and data inside a prompt, so prompt injection may never be totally mitigated in the same way. It describes the model as an inherently confusable deputy and concludes that the goal is to reduce the likelihood and the impact of an attack. If a system cannot tolerate the remaining risk, the NCSC says, it may not be a good use case for an LLM.

OWASP reaches the same conclusion from a different angle: because model outputs are probabilistic, it is unclear whether fool-proof prevention exists. Published test results show what that means in practice. When Anthropic red-teamed its Claude in Chrome browser agent in August 2025 with 123 test cases across 29 attack scenarios, attacks succeeded 23.6% of the time without its new defences. With site permissions, action confirmations, improved system prompts and classifiers, the rate fell to 11.2%. That is a large improvement and still far from a guarantee, which is why the controls that matter most sit outside the model.

Developer Simon Willison's lethal trifecta, published in June 2025, is the fastest way to triage a feature. An AI agent is exposed to data theft when it has all three of: access to private data, exposure to untrusted content, and the ability to communicate externally. An attacker plants instructions in the untrusted content, the model reads private data, and the external channel carries it out. The NCSC blog endorses a related rule: when a model processes input from a party, its privileges should drop to that party's level.

In a feature review, we list each AI feature with three yes-or-no columns. Any row with three yeses gets redesigned before launch, usually by removing the outbound channel (no arbitrary URLs, no email sending, no rendering of external images in output) or by splitting the feature so that the part reading untrusted content never touches private data.

A June 2025 paper by researchers from IBM, Invariant Labs, ETH Zurich, Google, Microsoft and others, Design Patterns for Securing LLM Agents against Prompt Injections, states the core principle plainly: once an agent has ingested untrusted input, it must be constrained so that it is impossible for that input to trigger any consequential actions. It proposes six patterns, each trading some flexibility for that guarantee.

This is the checklist we apply when we design an AI feature. It combines OWASP's seven mitigations with the NCSC's advice and the lethal trifecta test, ordered so that the controls that do not depend on the model come first.

OWASP recommends regular adversarial testing that treats the model as an untrusted user, checking whether trust boundaries and access controls hold. Build a small attack suite from your own data types: a support ticket with hidden instructions, a PDF with white-on-white text, a product review that asks the assistant to reveal its system prompt. Run it in CI whenever prompts, models or tools change, and track the success rate over time rather than aiming for a single pass.

For Japanese teams, the AI Safety Institute's Guide to Red Teaming Methodology on AI Safety, revised by IPA in April 2025, walks through an actual red-teaming exercise on a RAG system and includes example deliverables, which makes it a practical template for planning these tests. For monitoring, the NCSC suggests logging enough to spot suspicious activity, potentially including the full input and output of the model along with tool use and API calls. Failed tool calls deserve alerts, because they can be the first sign of an attacker probing.

The NCSC's advice to buyers is blunt: beware any vendor that claims it can stop prompt injection, and prefer those that explain how they reduce the risk. Willison makes a similar point about guardrail products that advertise detection rates: in web application security, 95% is very much a failing grade.