Prompt injection in AI agents: why filters are not enough and what actually protects

By Wladimir Neuberger · Updated 27 Oct 2026

What prompt injection is

Prompt injection ranks first in the OWASP list of the ten biggest risks for applications built on language models (2025 edition, LLM01:2025). It means that inputs change a model’s behaviour in a way nobody intended. The inputs do not have to be readable by humans; it is enough that the model processes them. Depending on the application this can lead to disclosure of sensitive information, distorted results, unauthorised access to functions or command execution in connected systems.

According to OWASP, how severe the damage is depends on the business context and on how much autonomy the model has. With a plain chatbot it usually stops at a wrong or inappropriate answer. With an agent that calls tools, the effect reaches as far as the agent’s permissions.

Direct and indirect

OWASP distinguishes two ways a model can be redirected. Both can arise deliberately or by accident.

• Direct injection: the user’s own input changes the model’s behaviour unexpectedly.
• Indirect injection: the model reads external content such as web pages or files, and that content contains instructions that alter its behaviour.

For agents the indirect variant is the awkward one. An agent is meant to read untrusted content: summarise emails, evaluate web pages, search documents. Imagine an agent that summarises incoming email and may also send messages. If one email contains hidden instructions, the agent might take them for a genuine task. The example is hypothetical, but it follows the scenario OWASP describes under “Excessive Agency”.

Why filters alone are not enough

The UK National Cyber Security Centre (NCSC) explains the core issue in a blog post of 8 December 2025: SQL injection can be fully fixed with parameterised queries because data and instructions stay separate at the database level. Language models make no such distinction. The NCSC therefore calls them “inherently confusable”. The risk can be reduced but probably not eliminated entirely. OWASP is similarly cautious: it says it is unclear whether any foolproof prevention method exists and that the listed measures aim to reduce impact. According to OWASP, retrieval techniques and fine-tuning do not fully mitigate the problem either.

The NCSC also advises against relying on deny-lists of known phrases, because attackers can rephrase endlessly, and recommends scepticism towards products that promise to “stop” prompt injection. Simon Willison, who coined the term, writes that vendors of protection products often promise high detection rates; in web security, a rate below 100 per cent is not a satisfying result, and nobody yet knows how to prevent these attacks reliably. According to Willison’s summary, a study of twelve published defences (“The Attacker Moves Second”, October 2025) found that the authors could bypass most of them with adaptive attacks, even though those defences had originally reported very good results.

Filters are a useful layer but not a guarantee. Plan as if an injection will succeed at some point, and limit what can happen then.

What works: limit the consequences

The following points come from the recommendations of OWASP (LLM01:2025) and the NCSC. The order and the selection for small projects are our own assessment.

• Separate content from instructions: mark external content clearly and keep it apart from user instructions so that it has less influence. The NCSC names marking or wrapping external content as a technique and stresses that this only makes attacks harder rather than preventing them.
• Limit permissions: the application gets its own credentials with minimal rights, and privileged functions run in application code rather than in the model. By the NCSC’s rule, a model’s privileges drop to the level of whoever supplied the input it processes: a model that reads external email should have no access to privileged tools.
• Build in approvals: for risky or privileged actions, a human decides before they are carried out.
• Check outputs: the model should return a fixed output format, and deterministic code verifies that the output conforms before anything else happens.
• Monitor: the NCSC recommends logging enough to spot anything unusual, such as inputs and outputs, tool calls and failed calls, which can indicate an attacker probing.
• Test regularly: OWASP recommends penetration tests and attack simulations that treat the model as an untrusted user in order to verify trust boundaries and access controls.

Avoid the dangerous combination

Simon Willison describes three properties that are especially dangerous together, the “lethal trifecta”. In October 2025 Meta derived the “Agents Rule of Two” from it, which also takes state changes into account. According to it, an agent should satisfy no more than two of these three properties in a session:

• It processes untrusted inputs, such as web pages or emails from strangers.
• It has access to sensitive systems or private data.
• It can change state or communicate externally, for example send messages or write data.

If a task needs all three, Meta says the agent should not operate autonomously but under supervision, for example with human approval. Willison considers the rule the best practical guidance for now, but notes that untrusted input combined with state changes alone can also cause harm.

Testing and red teaming

According to Willison’s summary, “The Attacker Moves Second” recommends adaptive, iterative attacks rather than fixed sets of static test strings, because the latter make defences look better than they are. For your practice that means, without presenting it as a claim from the source: a one-off test with a handful of example strings tells you little.

• Test your agent before go-live with deliberately prepared documents and emails in a test environment.
• Check not only whether the model resists but what would happen if it gave in: which tools, data and recipients would be reachable?
• Repeat the tests after every change to the model, tools or permissions.

Our recommendation: start with what you control immediately, namely permissions and approvals (see the guide on permissions and approvals for AI agents), and add filters and tests as further layers. If a use case cannot tolerate the remaining residual risk, the NCSC’s view is that a language model may not be suitable for it.

Frequently asked questions

Sources

• OWASP GenAI Security Project — LLM01:2025 Prompt Injection
• OWASP GenAI Security Project — Top 10 for LLM Applications (Ausgabe 2025)
• UK National Cyber Security Centre (NCSC) — Prompt injection is not SQL injection (it may be worse), 8. Dezember 2025
• Simon Willison — The lethal trifecta for AI agents, 16. Juni 2025
• Simon Willison — New prompt injection papers: Agents Rule of Two and The Attacker Moves Second, 2. November 2025

This assessment rests on the publications listed. Check the original source before making decisions.

Keep reading

• Permissions and approvals for AI agents: avoiding excessive agency
• Cyber security in the age of agents: what changes when AI acts on its own