What is Indirect Prompt Injection?
Also called Second-Order Prompt Injection, Cross-Domain Prompt Injection.
Indirect prompt injection is a variant in which the malicious text is planted in content the model later retrieves, such as a web page, document, email, calendar invite, or code comment, rather than typed by the user. The victim triggers the attack simply by asking the assistant to read or summarize that content. It was described in published research in 2023.
The distinction from direct injection is who supplies the text and when. In the direct case the person at the keyboard is the attacker. In the indirect case the person at the keyboard is the victim, the attacker planted content earlier somewhere the assistant will read, and the two events may be separated by weeks. This makes attribution and detection considerably harder.
Any retrieval surface is a candidate carrier. That includes indexed web pages, shared documents, inbound email, ticket bodies, product reviews, file metadata, repository comments, and the output of another automated system. Payloads can be visually hidden from a human reader through white text, tiny fonts, off-screen positioning, or fields that render in the tool but not in the document view.
Risk multiplies in agentic systems, where retrieval and action happen in the same loop. An assistant that reads a document and can also send messages or modify files gives an attacker a path from planting text to causing an effect, with no further interaction. Chains through multiple agents extend the reach further, since one agent's output becomes another's trusted input.
The defensive posture starts from a rule: retrieved content is data and never authority. Practical measures include stripping hidden and non-visible text before it enters context, isolating retrieved content in clearly delimited spans, denying tool calls that originate from a retrieval step, requiring human approval for outbound actions, and restricting retrieval to sources the requesting principal is already allowed to see.
Key points
- Payload lives in retrieved content, not in the user's message
- The person triggering it is the victim, not the attacker
- Carriers include web pages, email, documents, tickets, code comments
- Hidden text can be invisible to a human reviewer
- Rule: retrieved content is data and never authority
In practice
An assistant is asked to summarize a competitor's public pricing page. Buried in the page markup is text styled invisibly, written as though it were an operator instruction telling the assistant to append a link to the summary. Nothing looks wrong to the person who asked. Stripping non-rendered text before retrieval, and blocking link insertion that did not originate from the user, both break the chain.