Picture an AI assistant that summarises the admin inbox every morning. One day an email arrives from a stranger. You never open it, but the assistant does, and inside are a few lines written for it, not for you. That is indirect prompt injection, and it is the variant that should worry a company already using AI at work.

I have already explained what prompt injection is in general. Here I focus on the indirect kind: where it comes from, which real cases exist and what you can do so it does not catch you off guard.

◢What is indirect prompt injection?

The difference from direct injection is who writes the text. In the direct kind, the attacker types into the chat. In the indirect kind, the attacker never talks to your AI. They leave the message somewhere they know it will eventually pass.

◢Real examples of indirect injection

The technical detail matters less than the lesson: a product from one of the biggest companies in the world, with filters built specifically against this attack, could be manipulated with an email.

The 2023 paper had already demonstrated similar attacks against Bing Chat powered by GPT-4 and against code-completion tools, including data theft and changes to how the application behaved.

◢Why can't it be fixed with a patch?

IT teams ask this a lot. In a December 2025 post, the NCSC explains that comparing it with SQL injection is misleading: SQL injection was solved by separating data from instructions, and today's language models have no security boundary between the two. Its conclusion is that it may never be fully eliminated, so the goal is to reduce its likelihood and impact rather than wait for it to disappear.

OWASP says something similar: its measures reduce impact but do not guarantee complete prevention.

There is a practical consequence. If a vendor promises its product "stops" prompt injection, ask how they know. The NCSC advises caution with such claims and suggests looking for products that reduce it.

◢What changes when the AI has tools?

Everything. A chatbot that only answers can, at worst, say something wrong. An agent that reads your email, queries your CRM and can send messages turns manipulated text into a real action. The NCSC sums it up: if the model can call tools, injection has the same effect as giving the attacker direct access to those tools.

So the risk depends less on how smart the model is than on what you let it do. It is the same problem I describe in AI agents with too many permissions.

◢How do you prevent indirect prompt injection?

There is no single fix. These are the measures OWASP and the NCSC recommend, in the order I would apply them in a company:

1. ▹Least privilege. An assistant that processes external email should not have access to privileged tools. If it only has to summarise, it should not be able to send. The NCSC cites a simple idea that has been proposed in the industry: when the assistant reads someone's content, its privileges should drop to that person's level.
2. ▹Human approval for what matters. Sending, paying, deleting or changing permissions needs a person to confirm after seeing exactly what will happen.
3. ▹Mark and separate external content. Identifying which text comes from outside helps limit its influence, though it does not remove it.
4. ▹Validate what comes out. If the assistant has to return a specific format, check it with ordinary code, not with another model.
5. ▹Log everything. The NCSC advises keeping the full inputs and outputs of the model, tool use and API calls. A failed attempt to use a tool can be an attacker refining their approach.
6. ▹Test it first. OWASP recommends treating the model as an untrusted user in penetration tests and simulating attacks with prepared documents.

One measure the NCSC advises against: blocking known phrases. They can be reworded endlessly.

◢What staff can do

People who use AI every day are also a barrier. Before accepting what the assistant proposes, it is worth reading what it is about to send, share or delete, and to whom. A summary that insists on something odd, or an action nobody asked for, is a reason to stop and report it, just like a phishing email. If you want a refresher on spotting one, I covered it in how to spot a phishing email.

◢A design risk, not a careless-employee risk

Indirect injection is not caused by a careless employee. It happens even when everyone does their job well, because the trick travels inside the content the AI reads. So the defence is to design on the assumption that the assistant can be fooled, and to limit the damage it could do.

It is one of the topics I cover in my cybersecurity and AI training for companies, designed for non-technical teams.