Indirect Prompt Injection Explained: Defenses That Hold

Indirect prompt injection is the attack class where malicious instructions reach a language model not from the user typing them, but hidden inside content the model was asked to process: a web page, an email, a PDF, a support ticket, a record returned by a retrieval pipeline. This post is indirect prompt injection explained from the defender’s side: what separates it from direct injection, why models keep falling for it, and which layered controls actually reduce the risk. The uncomfortable summary up front: any application that lets an LLM read attacker-reachable content and then act on what it read inherits this problem by design, and no single control eliminates it.

Direct vs. indirect: where the instructions come from

In a direct prompt injection, the attacker is the user. They type adversarial input straight into the chat box, trying to override the system prompt. In an indirect injection, the attacker never touches the application at all. They plant instructions in third-party content the application will later ingest on a victim’s behalf.

The OWASP Top 10 for LLM Applications covers both variants under LLM01, and its description of the indirect case is precise: the vulnerability arises when an LLM accepts input from external sources an attacker can control, such as websites or files, and the embedded payload hijacks the conversation context. OWASP also notes the payload does not need to be human-visible. White text on a white background and non-printing Unicode characters both parse fine as model input, so a document that looks clean to a reviewer can still carry live instructions.

The root cause is architectural. A transformer consumes one token stream. The operator’s system prompt, the user’s question, and the text of a retrieved web page all arrive in the same channel, with no cryptographic or structural marker of provenance. The model has no reliable way to distinguish “instructions from my operator” from “instructions someone wrote into a document I was told to summarize.” It is a confused-deputy problem sitting at the prompt layer, which is also how our earlier post on defense-in-depth for prompt injection frames it.

The attack class was formalized in 2023 by Greshake et al., who coined the term and demonstrated it against real systems, including Bing’s GPT-4-powered chat and code-completion engines. Their paper showed that remotely planted prompts could exfiltrate data, manipulate users, contaminate downstream information, and trigger arbitrary API calls, all without the attacker ever holding a session with the target application.

Anatomy of an attack

An indirect injection unfolds in four stages, each worth defending separately.

Plant. The attacker writes a payload somewhere the model will eventually read: a web page positioned to rank for queries a browsing agent might issue, an inbound email to an AI-triaged mailbox, a README or issue comment for a coding agent, a poisoned document in a shared drive that feeds a RAG index, a calendar invite body. Google’s GenAI security team calls out emails, documents, and calendar invites specifically as the carriers they defend Gemini against.

Retrieve. The application does exactly what it was built to do and fetches the content. Nothing anomalous appears in logs. Retrieval-augmented generation widens this stage considerably, because the corpus becomes part of the attack surface. The offensive mechanics of that variant are covered in detail at aisec.blog’s write-up on indirect injection in RAG pipelines.

Interpret. The model encounters the embedded instructions and, some fraction of the time, follows them. That fraction is the contested variable that every defense tries to push down, and it is rarely zero.

Act. Severity depends on capability. A chatbot with no tools produces a manipulated answer, which is bad but bounded. An agent that can call tools, send messages, or render markdown can do real damage: the classic exfiltration path renders an attacker-controlled image URL with sensitive data packed into the query string. Real-world incidents along these lines, from mail-assistant exfiltration chains to agent hijacks, are tracked at ai-alert.org.

Why models keep falling for it

It is tempting to treat this as a bug that the next model generation will patch. The evidence points the other way. Instruction-following is what these models are trained to do, and they generalize it to instructions wherever they appear in context. Alignment fine-tuning reduces compliance with obviously malicious embedded instructions but does not eliminate it, which is why prompt injection has held the LLM01 slot since the OWASP list first shipped, and why both Microsoft and Google describe their production posture as defense in depth rather than a fix. Microsoft’s MSRC reports indirect prompt injection as one of the most widely used techniques in the AI security issues reported to them.

The defense stack that exists today

Both vendors’ published architectures converge on four layers, a useful signal about what holds up in production.

Preventive prompt engineering. Microsoft’s “spotlighting” family (delimiting, datamarking, encoding untrusted content) gives the model a continuous signal about which tokens came from untrusted sources. In the original spotlighting paper, the authors report attack success dropping from above 50% to below 2% on GPT-family models in their experiments. Treat that as evidence the technique helps, not as a guarantee; the numbers come from their specific models and attack set. Google’s equivalent, “security thought reinforcement,” wraps retrieved content in targeted reminders to ignore embedded instructions.

Detection classifiers. Microsoft ships Prompt Shields, a multilingual injection classifier wired into Defender for Cloud; Google runs purpose-built content classifiers over emails and files before they reach the model. These are probabilistic controls with real false-positive and false-negative rates, and they sit in the same trade-off space we mapped in our survey of prompt injection detection methods.

Deterministic output controls. This is the quietly load-bearing layer. Google sanitizes markdown and redacts URLs flagged by Safe Browsing; Microsoft deterministically blocks known exfiltration channels such as external image tags and links. Unlike a classifier, a hard block on rendering external images cannot be talked out of its job.

Impact mitigation. Least-privilege tool access, data governance and sensitivity labels, and human-in-the-loop confirmation before sensitive actions. Both vendors require explicit user approval for risky operations, which converts a silent compromise into a visible prompt.

What risk remains

The residual risk is real and worth stating plainly. Classifiers can be bypassed by novel phrasings. Spotlighting figures were measured on particular models and may not transfer to yours. Human-in-the-loop degrades under approval fatigue. The durable design assumption, now standard across the industry: treat everything the model reads as potentially steering it, and constrain what the model can do rather than trusting what it reads. Scope tools narrowly, block exfiltration channels deterministically, log model inputs and outputs for investigation, and keep a human gate on irreversible actions. Layered controls do not make indirect prompt injection go away; they make it expensive, noisy, and recoverable.

Related across the network

• How Indirect Prompt Injection Works — aiattacks.dev
• How to Detect Prompt Injection: Four Approaches Ranked — aiattacks.dev
• LLM Jailbreak Defense Techniques: A Practitioner’s Guide — aisecweekly.com
• LLM Prompt Injection Defense: What Actually Works — aisecweekly.com
• Indirect Prompt Injection: How These Attacks Work — promptinjection.report