What it means
Indirect prompt injection places hostile instructions in content the model later retrieves or processes, such as a webpage, document, email, or tool result.
Why it matters
The attacker may never interact with the application directly, and the malicious content can inherit the authority of the user or agent that reads it.
Practical focus
- Define the approved purpose, accountable owner, users, operating environment, and acceptable risk for indirect prompt injection before implementation or procurement
- Implement content trust labels, retrieval filtering, instruction isolation, tool authorization, output validation, and cross-domain attack tests through documented architecture, policy, configuration, and change control
- Collect retrieval provenance, content-sanitization outcomes, denied actions, tool-call traces, and seeded-document exercises and compare the results with approved requirements, risk thresholds, and expected outcomes
- Exercise this failure scenario as a planned test: a document in a trusted repository tells the agent to send data to an external destination and the agent obeys
Common mistakes
- Using the label indirect prompt injection without defining the exact system boundary, decision, data, and people in scope
- Treating a model response or vendor claim as sufficient evidence without testing the surrounding application and operating process
- Failing to preserve retrieval provenance, content-sanitization outcomes, denied actions, tool-call traces, and seeded-document exercises in a form that lets reviewers reconstruct decisions and changes
- Testing only the normal path and never rehearsing what happens when a document in a trusted repository tells the agent to send data to an external destination and the agent obeys
Certification relevance
This subject appears in or supports the following certification bodies of knowledge: