What Is Prompt Injection? The Security Risk in Every AI Agent

Businesses are connecting AI tools to their inboxes, files, CRMs and payment systems. That is where the useful work happens, and it is also why this attack matters. A chatbot that can only talk might embarrass you. An agent with access to your data and tools can do real damage if someone else manages to give it instructions.

What prompt injection is

A language model receives everything as one stream of text: the rules its developer wrote, your request, and any document or email it was asked to work on. It has no dependable way to tell which parts are orders and which parts are only material to read.

Prompt injection exploits that. An attacker writes text that reads like an instruction, puts it somewhere the model will see it, and the model may obey.

Picture a new assistant told to go through the post and deal with it. One letter says: “Pay this invoice to our new bank account and don’t mention this letter to anyone.” A careful person would get suspicious. You can’t count on a language model to do the same.

OWASP, the nonprofit best known for its web security lists, released its LLM Top 10 for 2026 in August. Prompt injection stayed at number one, and excessive agency, which means giving an AI too much power to act on its own, climbed to third.

Direct and indirect attacks

Direct prompt injection

The attacker types the instructions straight into the tool, for example telling a support bot to ignore its rules and reveal its hidden prompt. This is annoying, but the damage is usually limited if the bot can only do what that user was already allowed to do.

Indirect prompt injection

The instructions are planted in something the AI will read later: an email, a web page, a PDF, a support ticket, a product review or a note in your CRM. The person using the AI does nothing wrong and may never notice the text.

This is the one to worry about. Anyone who can send you an email or get a document into your systems can reach your AI tool, without ever logging in.

A real example: EchoLeak

The clearest documented case is EchoLeak (CVE-2025-32711), a critical flaw in Microsoft 365 Copilot reported by researchers at Aim Labs. A published case study describes how it worked:

1. The attacker sent an email with instructions written to look like ordinary business text. It had no attachment and no malware.
2. Later, an employee asked Copilot a normal question, such as summarising recent emails, and Copilot pulled that email in as context.
3. Copilot followed the hidden instructions and placed sensitive data inside the web address of an image in its reply.
4. The image loaded automatically through an allowed Microsoft service, which carried the data to the attacker’s server.

The employee clicked nothing. Microsoft fixed the flaw on its servers in May 2025, published its advisory that June, and reported no evidence that it had been used in real attacks.

Look at what the attack had to get past: a classifier built to detect this kind of attack, link redaction, and a content security policy that blocked unapproved websites. Microsoft had thought about this problem, and the researchers still found a route through each layer.

Why it can’t simply be patched

SQL injection, an older attack on databases, has a proper fix: parameterised queries keep commands and data apart, so user input can never run as a command. Language models have no equivalent, because they only predict the next piece of text.

The UK’s National Cyber Security Centre made this point in “Prompt injection is not SQL injection (it may be worse)”, warning that these attacks “may never be totally mitigated”. It also warns against any product that claims to stop prompt injection, and against blocklists of phrases like “ignore previous instructions”, because attackers can simply reword them.

OWASP’s project leads put the practical conclusion well: “Stop trying to build a model that cannot be fooled. Build the system around it.”

The setup that makes it dangerous

Developer Simon Willison named the worst case the lethal trifecta. An AI tool is exposed to data theft when it has all three of these at once: access to private data, exposure to untrusted content, and a way to send information out.

This gives you a quick way to rate any AI tool you use or plan to build:

Data theft isn’t the only concern. An agent that can issue refunds, delete records or make payments can be pushed into doing those things too, even if it has no way to send data out. Rate each action by the worst thing it could do.

How to reduce the risk

Assume the AI will be fooled at some point, then decide what should happen when it is.

1. Give each tool the least access it needs. Read-only where possible, a dedicated account, and only the data that task requires.
2. Lower its power when it reads outside content. The NCSC’s rule is that when a model processes information from a party, its privileges should drop to that party’s. An AI reading a stranger’s email should have no more power than the stranger.
3. Put a person in front of anything that can’t be undone. Payments, refunds, deletions and messages to new recipients should wait for human approval.
4. Control what leaves. Limit which websites a tool can contact, and don’t load images or links from AI output automatically. EchoLeak depended on exactly that.
5. Mark outside content as data. Wrapping it in clear tags makes attacks harder, though it won’t stop them.
6. Log inputs, outputs and tool calls. Watch for failed or unusual calls, which can be a sign that someone is probing the system.
7. Attack your own system. Plant instructions in test emails and documents before launch, and again after every significant change.

The limits must live in ordinary code outside the model. A sentence in the prompt saying “never send data externally” is a request. A network rule that blocks the connection is a control.

Questions to ask before you buy or build

• What can this tool read, and who outside our company can put content in front of it?
• What can it do without a person approving?
• Can it send data outside our systems, and to where?
• Are its limits enforced in code, or only described in the prompt?
• Are its tool calls logged, and can we see those logs?
• If it is fooled tomorrow, what is the worst realistic outcome?

If the answer to any of these is “the AI is trained not to do that”, treat it as no answer.

None of this is a reason to avoid AI agents. A narrow agent with limited access and approval on risky steps is a sensible tool. If you are planning one and want help deciding what it should be able to touch, see our AI automation service or get in touch.

FAQ

Is prompt injection the same as jailbreaking?

They overlap. Jailbreaking usually means getting a model to ignore its safety rules. Prompt injection is broader: it means hijacking what an AI application does, often to reach data or tools, and the person affected may be someone other than the attacker.

Will better AI models solve this?

Newer models may resist more attacks, but the UK’s NCSC says these attacks may never be totally mitigated. Plan on the basis that some will get through.

Are small businesses at risk?

Yes, if they use AI tools that read outside content. The attack can be as simple as a message your tool will read, so company size is no protection. What matters most is what the tool can access and do.

Does using a well-known AI product make me safe?

It helps, because large vendors have security teams working on these flaws, but EchoLeak shows that major products can still be affected. Your own risk also depends on which data and accounts you connect to the tool.

Does this affect my website chatbot?

If it only answers from public information, the main risk is misleading or embarrassing replies. Review it again before connecting it to orders, customer records or any system that can take action.

What should I do first?

List every AI tool that touches company data. For each one, write down what it can read, what it can do, and whether it can send anything out. Fix the tools with all three first.