Indirect Prompt Injection

Indirect prompt injection is the variant of prompt injection in which the attacker is not the user of the AI system. Instead, the attacker plants the adversarial instructions inside external content the system ingests during normal operation — a README in a client repository, a reply on a public X thread, an MCP tool description, an RPC response, a Slack message, a calendar invite, an item in a vector database. The legitimate user never sees the payload. The agent reads it, treats it as instruction (because LLMs have no architectural boundary between data and instruction), and acts on it.

The term was popularised by Greshake et al. in the 2023 paper "Not What You've Signed Up For", which framed it as the consequence of LLM-integrated applications blurring the line between data and instructions. OWASP's LLM01:2025 entry lists indirect prompt injection as one of two primary variants of the top LLM threat, alongside direct prompt injection, and notes that fool-proof prevention may not be achievable given how the underlying models work.

Why Indirect Is the Harder Variant

Direct prompt injection requires the attacker to interact with the agent — visible, attributable, often blockable at the input layer. Indirect prompt injection requires only that the attacker control any source the agent reads. Three properties make it especially dangerous in Web3:

• Invisible trust boundary. The user issues a benign request ("summarize this Slack channel"). The agent fetches content. The content carries the payload. From the user's view, nothing went wrong.
• Cross-channel blast radius. An attacker can poison Channel A (Discord) and the action fires in Channel B (X), or in a different session entirely. The platform that received the original poison is not the platform that triggers the impact.
• Persistence via memory. When the poisoned content lands in an external memory store (RAG corpus, conversation history, vector DB), the attack remains active across sessions and across users. This is the memory injection subcase analyzed in the 2025 AI Agents in Cryptoland paper from Princeton and the Sentient Foundation.

Where It Shows Up in Production

Disclosed indirect-prompt-injection vulnerabilities in 2025–2026 cluster around three vectors. Agent wallets, where a payload routed through one AI agent triggers a transfer by another — the Bankrbot incident of May 4, 2026 cost roughly $150k–$200k in DRB tokens via a Morse code reply that Grok decoded and Bankrbot executed. AI-assisted coding and audit tools, where READMEs, GitHub issues, and inline comments deliver payloads to assistants with developer-level privileges (CVE-2025-54135 CurXecute, CVE-2025-11445 Kilo Code, the Rules File Backdoor disclosure). MCP server tool descriptions, where tool poisoning, rug-pull description swaps, and line-jumping payloads attack the agent at registration time, before any tool is invoked.

Defensive Posture

Indirect prompt injection cannot be patched out of the model — the mitigation has to live in the surrounding system. Treat every external content source as adversarial input. Strip Unicode and reject encoded payloads at ingestion. Separate read agents from execute agents architecturally. Cryptographically pin tool descriptions and detect changes between registration and invocation. Apply HMAC or digital signatures to persistent memory writes so the agent can distinguish authenticated history from impersonated history. Enforce human-in-the-loop approval on every state-changing action above a meaningful threshold, with caps and allowlists implemented in infrastructure rather than in the prompt.

Related Reading

• Indirect prompt injection in Web3: the attack chain against agent wallets, audit assistants, and MCP servers
• When AI controls DeFi vaults, prompt injection becomes remote code execution
• MCP security checklist
• MCP server hardening guide
• MCP breach index 2025–2026