Indirect Prompt Injection: The Supply Chain Attack Hiding in Your AI’s Data

Your AI agent doesn’t just listen to you — it reads webpages, PDFs, emails, and documents on your behalf, and it trusts what it reads. That trust is exactly what attackers exploit: hide an instruction inside a document, a webpage, or even a support ticket, and the AI may follow it as if you’d typed it yourself. This is indirect prompt injection, and it’s currently ranked as the top risk facing large language model applications.

What It Is

Prompt injection comes in two flavors. Direct injection is when a user types something in a chat box trying to manipulate the AI’s behavior — the classic “ignore your previous instructions” attempt. Indirect prompt injection (IDPI) is subtler and more dangerous: the malicious instruction doesn’t come from the user at all. It’s embedded in external content the AI is asked to process — a webpage it’s summarizing, a PDF it’s reading, an email it’s triaging, or a document it retrieved from a knowledge base.

The OWASP Gen AI Security Project’s LLM Top 10 for 2025 lists prompt injection as the #1 risk to LLM applications, and it explicitly separates indirect injection as its own attack pattern because the trust boundary that fails is different: the model can’t distinguish between “text I should follow as an instruction” and “text I should merely read, quote, or summarize.” Anything that reaches the model’s context window has a chance of being treated as authoritative.

How It Works

A payload doesn’t need to be visible to a human to be effective — it only needs to be machine-parseable. Documented concealment techniques include:

• Zero-sized fonts or off-screen CSS positioning
• Opacity/visibility suppression (text that renders but is invisible)
• Invisible Unicode characters
• Homoglyph substitution (characters that look identical but aren’t)
• XML/SVG attribute cloaking
• Base64-encoded payloads assembled at runtime

A concrete example from security testing: a single PDF containing white-on-white (invisible) text was enough to make a RAG-connected agent execute the attacker’s embedded instructions instead of following its own system prompt. Because retrieval-augmented generation pipelines pull from potentially large document corpora, every document in the index is a potential injection vector — and there’s no practical way to manually review them all.

The ingestion surface for this kind of attack is broad. Demonstrated carriers include web pages and HTML, PDFs and other documents, emails and their metadata, MCP (Model Context Protocol) tool descriptions, RAG corpora, persistent memory stores, code repositories and config files, and internal wikis or CRM notes. If an AI agent reads it, it can carry a payload.

Who and What Is Affected

Any system where an LLM ingests external content and can also take action is at risk — this spans RAG chatbots, AI browsing agents, email-triage assistants, document-review pipelines, and coding agents that read repos or tool configurations. The risk scales with the agent’s autonomy: a model that only answers questions is lower-risk than one that can send emails, make payments, delete records, or execute code based on what it just read.

Real-World Impact

This isn’t a theoretical concern. Unit 42 (Palo Alto Networks) documented 12 distinct real-world IDPI attack cases against web-browsing AI agents, using 22 different delivery and jailbreak techniques. Notably, 37.8% of these payloads were delivered as plain, visible text — no exotic concealment required — and 85.2% of jailbreak attempts relied on social engineering rather than technical tricks, meaning that sophistication is often less important than persuasion.

Attacker goals in the wild broke down roughly as: causing irrelevant or degraded output (28.6% of cases), issuing data-destruction commands (14.2%), and bypassing content moderation (9.5%). Other observed attempts included triggering unauthorized payments through Stripe/PayPal-integrated agents, deleting databases, and exfiltrating system prompts or contact data. Interestingly, 73.2% of the malicious pages used ordinary .com domains — attackers aren’t relying on obscure infrastructure.

In December 2025, researchers identified what’s described as the first real-world case of IDPI targeting an AI ad-review pipeline: a site (reviewerpress.com) used hidden prompts attempting to trick an AI-based ad-moderation system into approving fraudulent scam ads. This is characterized as a plausible, identified attack attempt rather than a confirmed successful bypass in production.

A more consumer-facing example: Perplexity’s “Comet” AI browser was shown to leak a user’s one-time password after invisible text hidden in a Reddit post was ingested by its page-summarization agent — a direct chain from indirect injection to data exfiltration in a shipped product.

On the software supply-chain side, CVE-2025-59944 is cited as a concrete vulnerability in this class — a case-sensitivity bug enabling configuration-file hijacking — alongside reports of zero-click remote code execution in MCP-based IDEs achieved by manipulating Google Docs content that later reached an agent’s tool calls.

Detection

Because this vulnerability class is architectural rather than a single bug, detection has to happen at multiple layers:

• Scan for concealment techniques specifically — hidden or zero-size text, off-screen/opacity-suppressed HTML, invisible Unicode, homoglyphs, and encoded payloads — since these accounted for the bulk of real-world delivery methods.
• Add output and behavioral verification layers: a secondary LLM or rule-based reviewer checking outputs, groundedness and citation checks (OWASP’s “RAG Triad”: context relevance, groundedness, answer relevance), and anomaly logging to catch agent behavior that deviates from expectations.
• Adversarially test continuously: red-team RAG and agentic pipelines with intentionally injected documents and pages as a routine part of security testing, not a one-time audit.

Defense and Mitigation

The consistent theme across guidance from OWASP, Unit 42, and other researchers is: stop trusting retrieved content by default.

• Treat all external or retrieved content as untrusted — RAG documents, emails, webpages, tool descriptions, and memory entries should never carry the same authority as system or developer instructions.
• Segregate trusted instructions from untrusted data using explicit delimiters, source labels, or “spotlighting” techniques so the model can tell the difference between text to act on and text to merely summarize or quote.
• Enforce least privilege on agent tooling — restrict API and database scopes, require human approval for high-risk actions like payments or deletions, and keep business logic in deterministic code rather than letting prompts control branching decisions.
• Validate tool calls before execution against strict schemas and allow-lists rather than trusting model-generated parameters. This is the step that most real incidents — unauthorized payments, deletions, exfiltration — blow straight past.
• Reduce agent autonomy where possible. The fewer autonomous, unsupervised actions an agent can take — sending money, deleting data, executing shell commands — the smaller the blast radius when an injection succeeds.

Takeaway

Indirect prompt injection turns any external content your AI reads — a webpage, a PDF, an email, a retrieved document — into a potential attack vector, and real-world incidents already show this leading to leaked credentials, attempted fraud, and destructive actions. There’s no single patch for this; the fix is architectural: assume ingested content is hostile, keep humans in the loop for consequential actions, and validate everything before it becomes a tool call.

Sources

1. LLM01:2025 Prompt Injection — OWASP Gen AI Security Project
2. Fooling AI Agents: Web-Based Indirect Prompt Injection Observed in the Wild — Unit 42, Palo Alto Networks
3. Indirect Prompt Injection: The Hidden Threat Breaking Modern AI Systems — Lakera