Indirect prompt injection: sources, real cases and how to test for it

Indirect prompt injection is an attack in which instructions hide in content that an LLM application reads, instead of in the user's own message. The user may be an honest victim. The attacker only has to place text where the app will find it.

NIST's adversarial machine learning taxonomy gives it its own section (3.4, with the identifier NISTAML.015). Testers start from a list of untrusted content sources and test each one.

What is indirect prompt injection?#

It is prompt injection where the malicious text arrives through retrieved or received data. Greshake et al. described it in 2023: an attacker plants instructions in data that an app is likely to retrieve, without direct access to the app. Their paper, first posted on 23 February 2023, showed attacks on Bing's GPT-4-powered chat, code-completion tools and synthetic apps (arXiv:2302.12173).

The root cause is the same as in direct prompt injection: the app mixes untrusted data with instructions in one context. The difference is who controls the text. In the indirect case, a third party does.

Which sources of untrusted content should you list?#

List every path by which text that your own team did not write reaches the model. Each path is a place where an attacker may plant instructions. The table is a starting inventory.

Rank the sources by how easily an outsider can write to them. An open ticket form ranks above a locked internal wiki.

Which real cases show indirect prompt injection?#

Four public cases each have a primary source and a date.

Bing Chat, 2023: Greshake et al. showed indirect injection against Bing's chat with GPT-4 in their paper of February 2023. The authors wrote that effective mitigations were lacking at that time.

Slack AI, August 2024: PromptArmor published on 20 August 2024. Hidden instructions in a public channel made Slack AI show a link that carried a secret from a private channel. PromptArmor reported the issue to Slack on 14 August, and Slack replied on 19 August that public-channel content is visible to workspace members and that this is intended behavior. The failing controls were the lack of separation between channel text and the user's question, and clickable links in the answer.

GitHub MCP server, May 2025: Invariant Labs published on 26 May 2025. A malicious issue in a public repo hijacked a user's agent, which then leaked private repo data into a pull request on the public repo. The authors state it is "not a flaw in the GitHub MCP server code itself" and that security measures must be implemented at the system level. The demo needed access to both public and private repos and an "Always Allow" confirmation setting.

EchoLeak, CVE-2025-32711, 2025: NVD published the record on 11 June 2025, described as "Ai command injection in M365 Copilot allows an unauthorized attacker to disclose information over a network". The CNA (Microsoft) scored it 9.3 under CVSS 3.1; NVD scored it 7.5. A research paper by Reddy and Gujral describes a chain that bypassed an injection classifier and link redaction, then used auto-fetched images and an allowed Teams proxy (arXiv:2509.10540). The authors call it the first real-world zero-click prompt injection exploit in a production LLM system. That is their own claim. Simon Willison's summary dates the fix to June 2025 (Willison).

All the cases share untrusted text, access to private data, and an outbound channel such as a link or image. MITRE ATLAS lists several as case studies, for example AML.CS0035 (Slack AI) and AML.CS0059 (EchoLeak).

How do testers test indirect prompt injection?#

Testers plant a harmless marker instruction in each source and watch whether the system obeys it. A safe marker asks for something visible but harmless, such as adding a specific word to the answer. Only then, inside the agreed scope and with test data, does the tester raise the stakes.

1. Inventory sources. Use the table above.
2. Plant a marker. Place a benign instruction in the source, using a test account that the tester owns.
3. Trigger the read. Ask a normal question that makes the app fetch the source.
4. Check the behavior. Did the answer change? Did a tool run? Did a request leave the app?
5. Escalate within scope. If the marker works, test whether the model can reach test data, tools or the output channel.
6. Test the exits. Check links, images, tool arguments, email sends and file writes.
7. Repeat. Run each case several times, with different phrasing and positions in the source.

account B:  "Summarize my shared notes."
assistant:  "Two notes were shared with you. Note 'Trip plan' lists
             flights and a hotel. PINEAPPLE"

What controls reduce indirect prompt injection impact?#

Controls work best when they remove one of three legs: untrusted content, private reach or an outbound path.

• Cut the exit. Do not render model-written images or links to arbitrary hosts. See data exfiltration through Markdown images.
• Cut the reach. Run retrieval with the user's own access rights, and never with a broad service account. See RAG security.
• Mark the source. Tell the model which text is untrusted. This helps a little and sometimes fails.
• Ask for approval. Show the exact action before it runs.
• Use classifiers as one layer. EchoLeak shows a classifier can be bypassed.

NIST states that designers "may design systems with the assumption that prompt injection attacks are possible if a model is exposed to untrusted input sources" (AI 100-2 E2025, section 3.4.4). An LLM application security assessment tests each of these paths against your build.

What should a finding contain?#

State the source, who can write to it, what the model did, what it could reach, and the run rate. Name the exit path (link, image, tool call, email). Rate the impact by the data and tools that were reachable. Add the controls that held. A tool that refused a cross-user lookup is as useful to the reader as a failure, because it shows what to keep.

Retest after the fix with the same planted content and the same questions, and add new phrasings.