Indirect Prompt Injection Is a Trust Boundary Problem

Engineers building RAG systems or tool-using agents often treat prompt injection as a prompting issue. The real failure is at the trust boundary. External content must be treated as untrusted data, and that data must stay separate from instructions. Indirect prompt injection does not require direct access to a model. An attacker only needs your application to ingest a malicious artifact: an email, a PDF, a wiki page, or a repository file. Once that happens, untrusted data enters the workflow and tries to override developer instructions. The mistake usually is not retrieval itself. It is letting untrusted data shape high-trust behavior. TL;DR Indirect prompt injection is not mainly a prompting issue. It is a trust-boundary failure. Retrieved content must stay in the role of data, never instructions. Sensitive actions need schema validation, policy checks, and approval gates. The Conflict: Data vs. Instruction You often see architectures where an application fetches external content, put