Indirect prompt injection: instructions inside external content

I am studying PortSwigger’s Web LLM attacks with friends and will present on Saturday. I had trouble understanding the material from indirect prompt injection onward, so I asked AI to explain it. This first study note records that explanation. I have not done the labs yet.

Instructions arriving through another source

Indirect prompt injection places instructions in external material an AI reads, attempting to redirect it from the user’s task. The attacker controls content such as an email or web page. A legitimate user request can bring that content into the workflow. OWASP explanation

Type	Where the instruction appears	How it reaches the AI
Direct injection	Chat input	The attacker submits it directly
Indirect injection	Email, web pages, search results	The AI reads external material during a task

The source and role of a sentence matter. If someone asks me to translate “Close the door,” I do not close it. An imperative can be material to process. Instructions inside a document need the same distinction.

From summarizing an email to forwarding messages

Here is PortSwigger’s email example, paraphrased into separate steps. Original example

1. The user asks for a summary of the latest email.
2. The AI retrieves its body through a tool.
3. Alongside a greeting, the attacker’s email asks for future messages to be forwarded to Peter.
4. A vulnerable AI treats that sentence as an instruction and requests a forwarding tool call.
5. If the application permits and executes the request, it creates the rule.

The user requested a summary. The email’s author inserted the forwarding request. The boundary crossed is between email content and the user’s instructions.

A summary may describe the request inside the email. Describing it and changing a setting are separate actions.

A fake system message is still email content

The lesson also uses markers such as important system message and ---USER RESPONSE--- to disguise content as a system instruction or a later user message. These strings do not grant real system privileges. They try to make the AI mistake the content for an instruction with greater authority; success is not guaranteed. Disguised instructions

Saying that a special phrase creates permissions would confuse a disguise with actual authority. The question is whose instruction the AI thinks it is following, and where it read it.

A tool request is not its execution

Changing the forwarding rule requires a working tool and sufficient permissions. If the application rejects the request, that setting stays unchanged. Injection can also distort an answer without executing a tool. The available capabilities affect the impact. OWASP on impact and permissions

A prompt telling the model to ignore external instructions is therefore insufficient by itself. External content should be identified, tool access restricted by the application, and privileged operations subject to human approval where appropriate. In this example, reading email and changing forwarding rules can be treated as separate permissions. OWASP mitigations

When training data poisoning happens

The next section concerns interference with data used to train a model. The email example interferes with material read during a current task. It does not require retraining the model.

PortSwigger places training data poisoning under indirect prompt injection. The examples are easier to distinguish by separating data used during training from material read while handling the current request. Training data poisoning section

My next preparation step is to explain each stage: who can write the content, what the AI reads, whose instruction it follows, and where execution is permitted. I have not tested whether an attack succeeds. This post covers the concepts only.