Table of Contents
What Is Indirect Prompt Injection?
Indirect prompt injection occurs when an AI system reads external content that contains instructions intended to influence the model. The instructions are not typed directly by the current user. They may appear in a web page, email, document, retrieved knowledge entry, tool description, tool result, issue tracker, code repository, or stored memory.
The security problem becomes serious when the application allows the model to turn that content into an action. A model may summarize a page safely, but an agent with email, filesystem, payment, support, cloud, or administrative tools can create real operational impact.
Direct vs Indirect Prompt Injection
| Direct prompt injection | Indirect prompt injection |
|---|---|
| Submitted directly by a user | Embedded in external content |
| Model sees it as the current prompt | Model encounters it during normal work |
| Often visible to the user | May be hidden in a page, file or metadata |
| Mainly affects the current interaction | Can influence tools, memory or future actions |
Why AI Agents Increase the Impact
A chatbot can produce an incorrect answer. An agent may browse, retrieve, write, send, delete, approve, schedule, purchase, deploy, or modify permissions. This creates a chain of trust:
External content → model interpretation → plan → tool selection → arguments → external action.
Each step needs an independent control. Prompt filtering alone cannot verify user authorization, resource ownership, business rules, payment limits, destination safety, or whether an irreversible action requires approval.
Where Unsafe Instructions Can Hide
| Content source | Defensive concern |
|---|---|
| Web pages | Visible or hidden text may influence browsing agents |
| Emails | Message content may redirect a workflow or request a sensitive action |
| Documents and PDFs | Embedded text may be treated as instructions rather than data |
| Support tickets | Untrusted customer content may reach privileged support tools |
| RAG documents | Retrieved content may poison answers or decisions |
| Tool descriptions and results | Metadata or output may influence tool selection |
| MCP resources | External servers can supply context and capabilities |
| Long-term memory | Unsafe content may persist into future sessions |
| Code repositories | README files, issues and comments may influence coding agents |
Indirect Prompt-Injection Evidence Timeline
Framework and research milestones showing why untrusted external content is now a production agent-security boundary.
OWASP GenAI Security Project
OWASP Agentic Top 10 formalized agent risks
Goal hijacking, tool misuse, memory poisoning and human trust became distinct control areas.
OWASP frameworkUnit 42
In-the-wild web-based activity reported
Unit 42 documented observed techniques and malicious use targeting AI-based review and agent workflows.
Unit 42 reportOWASP GenAI Security Project
OWASP incident round-up expanded the evidence base
Recent cases connected tool misuse, identity abuse, memory, supply-chain and agent-control failures.
OWASP Q1 round-up
Observed In-the-Wild Activity
Unit 42 reported in March 2026 that web-based indirect prompt injection was being used in real activity. The research documented multiple observed techniques and attacker intents. The important defensive conclusion is that external web content is no longer only a theoretical model-safety concern; it is an active application-security boundary.
Organizations should not interpret one report as a complete measurement of global prevalence. Instead, use it as evidence that agent browsing, review, retrieval and tool workflows need production controls now.
Case Study: AI Ad-Review Evasion
One reported case involved malicious instructions hidden in a web page and an AI-based advertising review process as the target. The aim was to influence the review outcome by changing how the AI interpreted the page.
The lesson is broader than advertising: any agent or AI reviewer that consumes untrusted external content must separate data from instructions. The application should not allow page content to redefine policy, disable checks, select privileged tools, or approve the final action.
This article intentionally does not reproduce the hidden instructions, obfuscation patterns, or affected malicious URL.
Seven-Layer Defense Model
| Layer | Control |
|---|---|
| Content | Classify all external content as untrusted |
| Retrieval | Filter, scope and permission-check retrieved sources |
| Prompt | Separate trusted instructions from external data |
| Model output | Validate structured decisions and expected fields |
| Tool gateway | Enforce user, resource and action policy |
| Approval | Require confirmation for high-impact actions |
| Monitoring | Log, detect, stop and roll back unsafe behavior |
Use deterministic controls where possible. A model can help classify content or propose an action, but it should not be the final authority for identity, permission, payment, deletion, privilege or external communication.
RAG, MCP and Memory Considerations
- RAG: Track source and permissions for every retrieved document. Treat retrieved text as data, not policy.
- MCP: Review server ownership, tool definitions, schemas, scopes, results and updates. See the MCP Security Guide.
- Tool poisoning: Treat tool metadata and output as untrusted. See MCP Tool Poisoning.
- Memory: Isolate users and tenants, limit retention, preserve provenance, and allow review, deletion and quarantine.
- Approvals: Show the exact action, target, data and external impact before a person confirms.
Indirect Prompt Injection Incident-Response Checklist
- Disable or restrict affected tools.
- Preserve prompts, context, retrieved records, tool calls and approvals.
- Identify the malicious content source and every workflow that consumed it.
- Review stored summaries and long-term memory.
- Revoke exposed credentials or tokens.
- Check downstream systems for actions, messages, records or configuration changes.
- Remove or quarantine poisoned context.
- Retest policy, approval and rollback before reconnecting tools.
FAQs
What is indirect prompt injection?
How is indirect prompt injection different from direct prompt injection?
Can a web page attack an AI agent?
Can RAG systems be affected?
Can indirect prompt injection poison agent memory?
How should developers defend AI agents?
Summary
Indirect prompt injection turns external content into a security-relevant input. The risk grows when an AI system can use tools, retain memory or take actions. Treat every external source as untrusted, enforce policy outside the model, validate tool calls, require approval for high-impact operations, and design for monitoring, revocation and rollback.