Prompt injection turns from a nuisance into a fraud route once a model can act. OWASP ranks it first among risks for LLM applications and accepts it cannot be fully prevented. For an AI agent with tools, the answer is containment: untrusted text is labelled, can never authorise an action, and meets limits enforced outside the model.
What does OWASP say about prompt injection?
The OWASP Top 10 for LLM Applications places prompt injection at the head of its list. It describes the risk as input that alters the model's behaviour or output in ways the designer did not intend. OWASP distinguishes two forms:
- Direct injection: the user types instructions meant to override the system's rules.
- Indirect injection: instructions arrive inside content the model processes, such as a web page, an email, a document or a file, without the user necessarily knowing.
OWASP's mitigations, in substance: constrain the model's role and behaviour; define and check expected output formats; filter inputs and outputs; enforce least privilege on whatever the model can reach; require human approval for high-risk actions; separate and clearly identify external content; and test adversarially on a regular basis. It notes that because of how language models work, no method is guaranteed to stop injection. For the basics, see what prompt injection is.
Who does it apply to?
Anyone running an application where a language model reads input it did not write. For agents in regulated firms, that is nearly every agent: they read customer messages, emails, attachments, forms and records from other systems. The OWASP list is guidance, but security reviewers, auditors and customers use it as a benchmark.
Why is prompt injection worse when the system can act?
A chatbot that is successfully injected says something it should not. The harm is real but bounded by what words can do. An agent that is successfully injected can do something it should not, with whatever tools and permissions it holds.
Three features of agents widen the gap.
Agents read untrusted content as their job. An accounts payable agent must read supplier invoices. A complaints agent must read customer letters. Each is a channel through which an attacker can deliver instructions. Our piece on indirect injection through documents an agent reads works through examples, and our glossary entry on indirect prompt injection defines the term.
Agents hold tools and data together. An agent that can read customer records and also send emails can be told to send those records out. The combination is the danger, not either part alone.
Agents act in chains. An instruction planted early in a multi-step task can shape later steps, or pass to another agent, long after the injected text has left view.
How do you contain it when prevention fails?
Design on the assumption that some injection will succeed, and make sure that when it does, nothing important happens.
Separate instructions from data. The agent's brief and the firm's policies are instructions. Customer emails, attachments and web pages are data. Keep them in separate, labelled channels so neither the model nor the control layer confuses them.
Label where every fact came from. A bank detail from the firm's vendor master file and a bank detail typed into an emailed invoice may look identical to a model. Labelled by origin, they are not. We explain the principle in prompt injection and the provenance of facts.
Never let external text authorise an action. Rules enforced outside the model should refuse any action whose justification rests on untrusted content alone, such as changing payee details because an email asked.
Limit tools and permissions. Narrow tools, least-privilege access, and caps on what any single action can do.
Hold high-impact actions for a person. The reviewer sees the facts and their sources, so a request that rests on an external document is visible as such.
Take an illustrative case. A supplier invoice arrives with hidden text telling the agent to update the supplier's bank details and release payment. The agent may well draft the change. The control layer sees that the only source for the new details is an external document, refuses the update, and records the refusal with that reason. The invoice is routed to a person.
How do you meet OWASP's guidance for agents?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Constrain behaviour | Agent brief defines role, scope and prohibited actions | Versioned brief |
| Segregate external content | Untrusted inputs delivered in a separate, labelled channel | Input labels in action records |
| Least privilege | Tools scoped to the capability and the case | Access configuration |
| Human approval for high risk | Named person approves irreversible or high-value actions | Held-action records |
| Untrusted content cannot authorise | Control layer refuses actions resting only on external sources | Refused verdicts naming the source |
| Output checks | Outgoing messages and data checked before release | Output filter logs |
| Adversarial testing | Regular injection tests through every input channel | Test reports and fixes |
For a step-by-step method, see how to prevent prompt injection in AI agents.
What will a security reviewer or auditor ask?
- Which inputs can reach each agent, and which of them are untrusted?
- Could text in an email or attachment cause this agent to move money or change records?
- How does the control layer know where a fact came from?
- When did you last test injection through each channel, and what did you find?
- Show us an action that was refused because it rested on untrusted content.
What does OWASP's entry not cover?
It does not tell you which actions your business should hold for approval or what your limits should be. It is not law, though controls against injection support security duties under data protection law and resilience rules. For the full regulatory map, see our guide to AI agent regulation mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where Pryme fits
The Pryme Context Protocol labels every fact by provenance, from sealed to external, at the point it enters, so injected text cannot relabel itself. An external claim cannot authorise a payment. When an injected instruction pushes an agent towards an action its sources cannot support, the verdict is refused or held, and the record says why.
Questions people ask
Can input filters stop prompt injection on their own?
No. Filters catch known patterns, but attackers rephrase, hide text in formatting or use other languages. Filters reduce volume; containment limits damage.
Is prompt injection a risk for internal agents that never face customers?
Yes. Internal agents read emails, documents and data from outside the firm. Any of those can carry injected instructions, so the same controls apply.
Should agents be prevented from reading external content at all?
Usually not; reading it is often the job. The safer approach is to let the agent read external content while ensuring it can never be the sole basis for an action that matters.