Indirect Prompt Injection: Every Channel, One Payload

This is a lookup page, so I'll start with the thing it's arguing against and get out of the way: formatting is not a boundary. CSV columns, a code fence, a blank line, an HTML comment. They look like separation to you and the model gets one flat string with no marker anywhere in it saying which half is allowed to give orders.

Everything below is the short version of that problem. If you've got a bot summarising an inbox or chewing through an exported spreadsheet nobody audits, this is your page.

Direct injection goes attacker to model. Indirect goes attacker to resource to model, and the person who pulls the trigger is a legitimate user doing their job. That's the whole difference and it's the reason this one is nastier.

The channels

The CSV row is the underrated one. A weekly export of user reports goes to a model that returns a list of accounts to suspend. One attacker-written row asserting a breach by somebody else, repeated a few times for emphasis, steers a decision about other people's accounts. The attacker never touched the tool, they posted a comment weeks earlier.

The payload shapes

Work up in that order. A recipe request is harmless and settles whether you have any influence at all, which saves burning the interesting payloads on a target that was never going to fetch your page.

Where it hides

Here's the gap that makes the comment trick work, from my own run. Same page, two readers.

Nothing clever is happening. The pipeline hands over what the HTTP request returned, because fetching a page is one line and stripping it properly is a job nobody scoped.

Confirming the fetch

Before you accuse an app of retrieving your content, prove it does. Serve a page and read your own log.

python3 -m http.server 8000
# hand the app http://127.0.0.1:8000/index.html, then watch:
127.0.0.1 - - [16/Aug/2026 16:50:53] "GET /index.html HTTP/1.1" 200 -

A hit proves retrieval and rules out the model inventing a summary from the URL alone. No hit, and the interesting question is why not.

For the mail path swaks is the usual tool. I couldn't install it in this sandbox, so treat the line below as the shape rather than something I ran:

swaks --to admin@target.test --from alice@target.test \
      --header "Subject: Hello" --header "Content-Type: text/html" \
      --body @mail.txt --server 127.0.0.1 --port 2525

What I did run was the same message through Python into a local SMTP sink, and it turned up something I hadn't thought about. The transfer encoding wraps long lines, so the payload arrives cut in half.

I only found that because my sink crashed the connection before replying, so I went digging through the raw message to check anything had arrived at all. Useful from both chairs: the payload still works, because the mail parser rejoins it before the model sees it, and a filter reading raw MIME is searching a string that's been chopped up on it.

What I check

• Every source the app reads, and who is allowed to write to each one.
• Whether the raw fetch or the extracted text reaches the model. Ask for the code, not an assurance.
• Whether retrieved content is marked as data anywhere in the prompt, or just concatenated.
• Whether the model's answer triggers an action: a ban, an approval, a refund, a ticket, a tool call.
• Whether anybody would notice. A silenced payload produces a completely ordinary log line.

The three that matter most

If you only do three: a payload in an HTML comment, because review looks at rendered output. One in a CSV row, because nobody reads row 47. And a decision flip rather than a leak, because a wrong summary is a bug and a wrong approval is a breach. Greshake and colleagues made that last point in 2023 and it's still the part people skip: the attacker usually never sees the answer, so impact lives in what the system does next.

What I'd tell someone starting this today

Stop testing the chat box first. Draw the data flow, find every place text enters the prompt from somewhere a stranger can write, and start there. Less fun than arguing with a model, and it's where the findings are. I still don't know how much of this survives a properly built pipeline with retrieved text fenced off and labelled, because I've not had a well-defended one to test against.

Commands are in my AI and LLM pentest notes. If you run one of these bots and have never checked what the fetcher actually hands the model, that's tonight's twenty minutes, and tell me what you find.

FAQ

What is indirect prompt injection?

Indirect prompt injection is when the attacker's instruction reaches the model through something the application fetches, such as a web page, an email, a document or an exported spreadsheet, rather than through the chat box. The attacker never talks to the model, so input filters on the user's message never see the payload.

Does an HTML comment really work as a prompt injection payload?

It works whenever the pipeline sends raw HTML to the model, which is common because fetching a page is one line of code and stripping it properly is not. In my own run the comment was absent from the rendered text and present in full in the HTTP response, so the reviewer and the model saw different documents.

Why doesn't CSV or JSON formatting protect the data from being read as instructions?

Because the model receives one flat string. Columns, quotes, code fences and blank lines are visual conventions for people. Nothing in the prompt marks where data stops and orders begin, so a sentence sitting inside a cell competes with the system prompt on equal terms.

How do I confirm an application actually fetches a URL I supply?

Serve a page from a listener you control with python3 -m http.server, hand the application the URL, then read your access log. A GET arriving there proves the fetch happens, tells you the source address, and separates a real retrieval from the model inventing a summary.

Is indirect prompt injection worse than direct prompt injection?

Usually, for two reasons. The attacker needs no access to the application, and the person who triggers the payload is a legitimate user doing a legitimate task. That also means the attacker often never sees the response, so the impact lands on whatever the system does next rather than on what it prints.

References

• Greshake et al., "Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection" (2023)
• OWASP Top 10 for LLM Applications (LLM01)
• MITRE ATLAS, adversarial threat landscape for AI systems

Related reading

• Prompt Injection: Your Filter Blocks Words, Not Intent (the direct version, measured against two filters)
• Red Teaming Generative AI: The Model Is the Wrong Target (this payload followed all the way to a stolen cookie)
• Injection Attacks Explained (the same data-versus-instructions problem, without a model)
• The AI and LLM pentest notes playbook
• Browse the whole AI / LLMs track