Prompt injection is an attack where text fed to a large language model overrides the instructions its builders gave it. It can come directly from a user or indirectly from emails, web pages and documents the model reads. OWASP ranks it first in its Top 10 for LLM Applications, and no single control fully prevents it.
What prompt injection is, in plain terms
Prompt injection is when someone smuggles instructions into the text a model processes, and the model follows them instead of yours. The model reads your system prompt, the user’s message and any retrieved content as one stream of text, and it cannot reliably tell instructions from data.
The term was coined in 2022 by analogy to SQL injection. The key difference is that SQL injection has a structural fix, parameterised queries, while prompt injection has no equivalent today. That is why it is treated as an open problem you manage, not a bug you patch once.
For a business leader, the practical meaning is this: any text your AI system reads should be treated as potentially hostile input, just as your web team treats form fields. That includes content from inside your company, such as shared documents and tickets, not only the open internet.
Direct vs indirect prompt injection
Direct prompt injection comes from the person typing into the system; indirect prompt injection hides in content the model reads on someone’s behalf. Both matter, but indirect injection is the bigger concern once you give models tools and access to outside content.
Indirect injection can be invisible to people. Instructions can sit in white text on a white background, in image alt text, in document metadata or in a long email thread nobody reads in full, and the model will still process them.
Direct injection
A user types something like “ignore your previous instructions” to make a chatbot reveal its system prompt, bypass content rules or produce output it should refuse. The attacker is the user.
Indirect injection
Instructions are planted in a web page, email, PDF, support ticket or calendar invite. When an agent reads that content to complete a task, it may follow the hidden instructions, such as forwarding data or calling a tool. The attacker never talks to your system directly.
Why OWASP ranks it first for LLM applications
Prompt injection sits at LLM01 in the OWASP Top 10 for LLM Applications 2025 because it is common, hard to prevent and opens the door to other risks. OWASP’s own guidance also notes that RAG and fine-tuning do not fully mitigate it.
It connects to other entries on the list. Combined with excessive agency, where an agent has more permissions than it needs, an injected instruction can turn into a real action against your systems rather than a strange reply.
For security teams, the OWASP list is a helpful shared vocabulary. Mapping each LLM system against it gives you a checklist for design reviews and a way to explain risk to auditors without inventing a new framework.
What the business risk looks like
The risk scales with what the model can reach and do. A public FAQ bot with no tools can be embarrassed; an agent with access to email, files and payment systems can be steered into causing real harm.
The useful question for leaders is not whether a model can be tricked, because it can. It is what the worst outcome would be if it were tricked today, and whether you would know. That framing points straight to permissions, approvals and logging.
- Data leakage: the model reveals customer records, internal documents or its own system prompt.
- Unauthorised actions: an agent sends emails, changes records or calls APIs on an attacker’s behalf.
- Manipulated output: summaries, recommendations or reviews quietly skewed by planted text.
- Reputational harm: screenshots of your assistant saying things it never should.
How an indirect attack plays out
A simple scenario shows why agents raise the stakes. Picture an assistant that reads incoming supplier emails, summarises them and can draft replies and look up purchase orders.
An attacker sends an email with a hidden line telling the assistant to search for recent invoices and include the bank details in its reply. If the assistant has broad search access and can send mail without review, the instruction may be followed and nobody notices until later.
Now apply the controls: the assistant can only read the sender’s own orders, outbound mail needs approval, and replies are checked for account numbers. The same email produces a blocked action and an alert instead of a leak.
Mitigations that reduce the risk
Defending against prompt injection takes layers, because each control catches some attacks and misses others. The most reliable controls sit outside the model, where an attacker’s text cannot argue with them.
Start with the first three layers, because they limit damage regardless of how clever the attack is. Filters and monitoring then reduce how often attacks succeed and how quickly you spot them.
| Layer | What it does | What it will not do |
|---|---|---|
| Least privilege | Gives the agent only the tools and data the task needs | Stop the model from saying odd things |
| Authorisation outside the model | Checks every tool call against policy in code | Catch harmful text with no action attached |
| Human approval | Requires sign-off for high-risk actions | Scale to every low-risk step |
| Separate untrusted content | Delimits and labels retrieved text as data | Guarantee the model ignores it |
| Input and output filtering | Flags known attack patterns and data leaks | Catch novel or obfuscated attacks |
| Monitoring and red teaming | Finds attacks and drift over time | Prevent the first incident |
Questions to ask your team or vendor
You do not need to read model internals to judge exposure. Ask these questions about any LLM system before it reaches production, and expect specific answers.
Vague answers such as “the model is trained to resist that” are a warning sign. You want to hear about specific permissions, code-level checks, named approvers and a testing schedule you can verify.
- What untrusted content can this system read: web pages, emails, uploads, tickets?
- Which tools can it call, and with whose credentials?
- Which actions require human approval, and who approves them?
- Are permissions enforced in code, or only described in the prompt?
- How is it tested for prompt injection, and how often?
- What gets logged, and who reviews it?
The honest limitation
No current technique makes an LLM immune to prompt injection. Filters can be bypassed with rephrasing, and instructions in the system prompt are only as strong as the model’s willingness to follow them.
That is why our pods design for containment: assume some injection will get through, and make sure the agent cannot do much damage when it does. Narrow permissions, policy checks in code and approval gates on high-risk actions turn a potential breach into a logged, blocked attempt.
Budget for this work as part of delivery rather than as an afterthought. Red teaming before launch and after each significant change costs far less than an incident review, and it gives your security team evidence they can sign off on.