Prompt injection: how to defend production LLM applications

Every LLM feature that reads text it did not write is exposed to prompt injection. A support bot reads customer messages. A research agent reads web pages. A document assistant reads uploaded contracts. Any of that text can contain instructions, and a model has no built-in way to tell your instructions from someone else's. This article explains the risk and the layered defence we put on every production system we build.

What prompt injection is

Prompt injection happens when input changes a model's behaviour in ways its developer did not intend. There are two forms.

• Direct injection: the user types the instructions themselves, for example asking the assistant to ignore its rules or reveal its system prompt.
• Indirect injection: the instructions are hidden in content the model processes on someone's behalf, such as a web page it summarises, an email it triages or a PDF it reads. The person using the tool may not know the instructions are there.

Indirect injection is the bigger concern for agents, because they can act: send emails, query databases, call APIs. An injected instruction in a document can turn into a real action.

Where it sits in OWASP's list

The OWASP Top 10 for LLM Applications 2025 puts prompt injection first, as LLM01. Several other entries are closely linked to it:

• LLM02 Sensitive Information Disclosure, often the goal of an injection.
• LLM05 Improper Output Handling, when model output is passed to other systems without checks.
• LLM06 Excessive Agency, when a model can take actions it should not.
• LLM07 System Prompt Leakage, when hidden instructions are exposed.

The remaining entries cover supply chain, data and model poisoning, vector and embedding weaknesses, misinformation and unbounded consumption.

Six layers of defence

1. Give the model as little power as possible

OWASP's first mitigation is privilege control. A model that can only read a single knowledge base cannot be tricked into deleting records. Give each agent its own narrowly scoped credentials and tools.

2. Keep untrusted content separate

Put retrieved documents, user messages and tool results in clearly marked sections, and tell the model to treat them as data, never as instructions. XML-style tags work well. This does not make injection impossible, but it makes it much harder.

3. Validate outputs before they reach anything else

Require structured output, check it against a schema, and never execute or render model output directly. Check generated SQL, URLs and email recipients against allow-lists.

4. Keep a person in the loop for risky actions

Payments, deletions, external emails and changes to permissions should need a human approval step, at least until the system has a track record.

5. Keep secrets out of prompts

Assume the system prompt can leak. API keys, internal URLs and private business rules belong in code and configuration, not in prompt text.

6. Monitor and limit

Log inputs and outputs, alert on unusual patterns, and set rate and spend limits per user. That also covers OWASP's unbounded consumption risk.

Testing for it

Treat injection like any other regression. Keep a fixed set of attack cases for each prompt: requests to ignore instructions, to reveal the system prompt, to change format, and instructions hidden inside documents. Run them, with your normal quality examples, on every prompt or model change, and block the release if any of them succeed. Our Prompt Lab runs this kind of diagnosis on a failing prompt, and our prompt hardening service sets it up as a permanent check in your release pipeline.

A release checklist

1. Each agent and tool has the minimum permissions it needs.
2. Untrusted content is fenced and labelled as data.
3. Outputs are schema-checked; nothing is executed or rendered unchecked.
4. High-risk actions need human approval.
5. No secrets in prompts.
6. An injection test set runs on every change.
7. Logging, alerts and per-user limits are in place.