Prompt injection: how a document or website can take over your AI agent

What is prompt injection?

OWASP describes it as a vulnerability in which input changes the behaviour or output of a language model in unintended ways. The cause lies in how a model works. It receives one long text in which your instruction, the maker's system instructions and all the content it has to read are mixed together. It then predicts what should come next. It has no built-in sense of who said what. A sentence in a document that looks like an instruction can therefore work as an instruction.

That is different from an ordinary security flaw. In a classic attack, someone abuses a mistake in the code; here, someone abuses the core of how the model works, and you cannot program that away. That is why it tops the list, and why the defence is not about making it impossible but about limiting what it can do.

The consequence can be harmless (an answer that deviates) or serious: data leaking out, an action nobody intended, a decision based on a hidden sentence. How serious depends on what the model is allowed to do. A model that only talks can at most say something wrong. A model that can send emails or delete files can do that at the request of a stranger.

• Input that unintentionally changes the behaviour of the model.
• The cause lies in how a model works: everything is text, nothing has a sender.
• The severity depends on what the model is allowed to do.

What is the difference between direct and indirect injection?

In direct injection, it is the user who changes the behaviour of the model with their own input, deliberately or by accident. Someone types something into a chat window that makes the model forget its rules. That is a risk for anyone who offers a chat feature, and it is the less dangerous of the two, because the attacker can only show something to themselves.

In indirect injection, the instruction comes from an external source that the model reads: a web page, a file, an email, a message in a database. The user asks something harmless (“summarise this page”) and the page contains a sentence that makes the model do something else. The user does not even see the sentence; it can be white on white, in a comment in the code, or in an image. This is the dangerous variant, because the attacker does not need access to your system. They only need to write a page that your agent reads one day.

OWASP also names variants that evade detection. Instructions spread over several pieces that only form an instruction together. Commands in other languages or in an encoding. Meaningless strings of characters that disrupt a model's safety rules. And instructions in images next to harmless text. The picture that emerges: the instruction can be anywhere in what the model reads.

• Direct: the user changes the behaviour themselves; limited damage.
• Indirect: the instruction is in what the model reads; the attacker does not need to be inside.
• Variants: spread out, translated, encoded, in an image.

What does it look like with an agent that reads email or web pages?

Suppose your project has an assistant that reads a user's emails and summarises them, and that can also reply to emails. Someone sends that user an email with, somewhere at the bottom, a sentence telling the assistant to forward the last ten messages to an address. The user asks for a summary. The assistant reads the email and sees an instruction, and if it is allowed to send emails, it does so. Nobody hacked anything; the assistant did what it said.

Or an agent that visits web pages to gather information for a report. One of the pages contains text that is invisible to people, asking the agent to put the conversation so far into a web address and visit that address. The agent does it, and the conversation ends up in the attacker's log. OWASP describes exactly these two scenarios. It adds an applicant who fills their CV with text for the AI system that assesses CVs, and a document in a knowledge base that was altered to produce misleading answers.

The common thread: there is an agent that reads and acts, and the text it reads comes from someone you do not know. That is the combination to watch for.

• An email assistant that can send, and an email with an instruction at the bottom.
• An agent that reads pages, and a page with invisible text.
• The combination: reading and acting, with text from a stranger.

Why can a filter not solve it?

Because an instruction in ordinary language can take unlimited forms, and the model is good at understanding exactly all those forms. A filter that looks for known sentences misses the sentence that is worded differently, is in another language, is spread over two paragraphs or sits in an image. A filter strict enough to catch everything also blocks the ordinary content the model needs to read. Filtering helps as one of the layers; it is not a solution.

On top of that, the boundary between content and instruction does not exist for the model itself. You can ask it to ignore instructions in documents, and that helps partly, but it is a request to the same system you are trying to protect. An attacker who knows you ask that words their sentence so that it does not sound like an instruction.

The conclusion of OWASP and of everyone who looks at it seriously: assume it will succeed at some point, and set up your system so that it can do little damage when it does. That is a different way of thinking than with most security, and it is the way that works.

• An instruction in ordinary language can take unlimited forms.
• Asking the model itself to pay attention is a request to the system you are protecting.
• Starting point: it will succeed at some point; limit what it can do then.

Which seven measures does OWASP name?

First: constrain the behaviour of the model in the system instructions, with a clear role and clear limits. Second: define what form the output must have and check that it complies, so that a deviating answer stands out. Third: filter the input and the output for what does not belong there. Fourth: do not give the model more rights than it needs for its task, and use separate, limited access for each action.

Fifth, and this is the most important one for a maker: have a person approve before the model carries out an action with consequences. Sending something, deleting something, paying something, sending something outside the system: that only happens after a click by a person who sees what is about to happen. Sixth: separate external content from the instruction and mark it as such, so that the model knows a document is a document and not an instruction. Seventh: test your system as if you were the attacker, regularly, and certainly after every change.

None of the seven is enough on its own. Together they make the difference between an agent that one day forwards an email to a stranger, and an agent that instead puts a request to you that you reject in surprise.

• Constrain behaviour, define and check output, filter input and output.
• Least rights, and a person for every action with consequences.
• Separate and mark external content, and test like an attacker.

What do you do as a maker with an AI in your project?

Start with the question of whether your AI reads and acts. If it only reads your own text and gives answers, the risk is small and the first three measures are enough. If it reads text from others (users, web pages, files, email), separation is added: that text goes into the model clearly marked as data, and the system instruction says that instructions in that data do not count. If it can then also act, the rights and human approval are added, without exception.

Translate that into your code. Every action the model can carry out is a function with its own access, as small as possible. A function that can only read. A function that can only save a draft. And not a single function that sends without a person in between. What the model cannot call, a hidden instruction cannot make happen either. That is the same rule as with the rights on your database: whoever may see only their own data cannot leak someone else's.

And test it. Put an instruction in a test document yourself, let your agent read it, and see what it does. If it ignores the instruction or puts it to you, that is a check most projects with an AI in them have not passed. The security checklist on this site has a point for it.

• If your AI reads and acts, all seven measures apply.
• Every action its own function with minimal access; never sending without a person.
• Test with your own test document, and again after every change.

And the agent you build with yourself?

The same rules apply to the agent that writes your code. A build agent reads documentation, web pages, files in your project and error messages, and it can write files, run commands and sometimes send things. That is exactly the combination of reading and acting. A web page with a hidden instruction can ask such an agent to put something in your code that does not belong there, or to read a file it should not read.

The defence is the same here too. Give the agent access only to the folder of your project, and not to your whole computer. Always have actions with consequences (sending something, deleting something, installing something from outside) put to you first; most build agents have a mode for that. Read what the agent wants to do before you approve, even if it looks boring. And be suspicious if the agent suddenly proposes something you did not ask for and that seems to come from a page or document.

The agent is a tool that reads whatever it comes across. Whoever knows that keeps the consequences in their own hands. That is the whole point of this article: not being afraid of the text, but making sure the text can do nothing without you.

• A build agent reads and acts; the same rules apply.
• Access only to the project folder; consequences put to you first.
• Suspicion towards a proposal you did not ask for and that seems to come from a text.

Sources

Checked on 5 September 2026. The definition, the scenarios and the seven measures come from the OWASP Top 10 for LLM Applications, version 2025; the translation for a maker is a working method. This article deliberately contains no example text of an attack.

• OWASP, LLM01:2025 Prompt Injection

Further reading

Three places that connect to this.