Indirect Prompt Injection in AI Agents

Why This Matters

Indirect prompt injection is one of the most important security risks in modern AI systems because the attacker does not need to type into the prompt box.

They only need to place malicious instructions somewhere the AI system will later read.

That can be:

A webpage.
A PDF.
A support ticket.
An email.
A calendar invite.
A RAG document.
A code comment.
A tool response.
MCP tool metadata.
Long-term memory.

OWASP describes remote or indirect prompt injection as malicious instructions hidden in external content that an LLM processes, including code comments, documentation, issue descriptions, webpages, documents, emails, attachments, and hidden text.

Why Indirect Prompt Injection Matters

Direct prompt injection is visible. A user types something malicious into the chat box.

Indirect prompt injection is different. The malicious instruction is embedded in content the model consumes during normal operation.

User asks normal question
  -> system retrieves document / email / webpage / ticket / tool result
  -> retrieved content enters model context
  -> model treats hostile content as meaningful instruction
  -> agent leaks data, changes behavior, or calls tools

The root cause is instruction/data confusion.

LLMs process natural language instructions and natural language data in the same context window. If a document contains text that looks like an instruction, the model may interpret it as part of the task rather than as untrusted content.

This is why prompt-only mitigations are not enough. You cannot reliably solve indirect prompt injection by writing a stronger system prompt. You need architecture-level controls.

Common Indirect Prompt Injection Surfaces

Surface	Why It Is Risky
Webpages	Browsing agents may ingest attacker-controlled page text, hidden elements, or metadata.
PDFs	Hidden or low-visibility text can enter document-processing workflows.
Emails	Incoming messages can carry instructions later processed by assistants.
Support tickets	Customers, users, or attackers can inject text into support workflows.
RAG documents	Poisoned content can persist in the retrieval layer.
Code comments	Coding assistants may treat comments or docs as task instructions.
Tool output	API or tool responses can influence the next model step.
MCP metadata	Tool descriptions and metadata are model-facing and can steer behavior.
Memory	Poisoned memories can influence future sessions.

OWASP's AI Agent Security Cheat Sheet explicitly lists direct and indirect prompt injection from user input and external sources such as websites, documents, and emails as agent security risks. It also calls out tool abuse, data exfiltration, memory poisoning, goal hijacking, excessive autonomy, and cascading failures.

Why Agents Make Indirect Prompt Injection Worse

Indirect prompt injection against a passive summarizer may produce a bad answer.

Indirect prompt injection against an agent can produce action.

Agent Capability	Potential Impact
Retrieve	Unauthorized context exposure.
Summarize	Sensitive-data leakage through generated output.
Send	External exfiltration or unauthorized communication.
Write	Record modification or workflow tampering.
Execute	Code execution or command misuse.
Remember	Persistent manipulation.
Chain tools	Escalation from low-risk to high-risk operation.

This is why the key security question is not only whether the model can be tricked. The key question is what the system can do after the model is tricked.

Example: Document-Based Indirect Prompt Injection

A normal workflow:

User: "Summarize this uploaded vendor questionnaire."
AI system reads PDF.
AI system summarizes the document.

Risky workflow:

User uploads or retrieves a document.
Document contains adversarial instructions.
AI system treats those instructions as part of the task.
AI system changes behavior, reveals context, or calls tools.

Safer design:

Control	Purpose
Treat document text as untrusted data	Prevent content from becoming instruction.
Preserve source labels	Track which context came from which document.
Use structured extraction	Reduce free-form instruction blending.
Validate outputs	Prevent unsafe downstream action.
Gate tool calls	Require authorization outside the model.

Example: Email-Based Indirect Prompt Injection

Email is a dangerous ingestion surface because attackers can send email to many enterprise users.

A risky agent may read an inbound email, summarize it, retrieve internal context, compose a response, send the response externally, and store the interaction in memory.

If hostile email content can steer the assistant, a normal workflow becomes an exfiltration or social-engineering path.

Control	Purpose
Draft-first email workflows	Prevent automatic external sending.
Recipient validation	Ensure generated emails go only to intended recipients.
External-content labeling	Mark inbound email as untrusted.
Tool-call approval	Require human approval for send actions.
Logging	Preserve prompt, email ID, retrieved context, draft, and send decision.

Example: Webpage-Based Indirect Prompt Injection

Browsing agents ingest attacker-controlled webpages.

A safe browsing assistant should assume web content can be hostile.

Control	Purpose
HTML/text sanitization	Remove irrelevant hidden or active content.
Source trust scoring	Distinguish trusted docs from public web pages.
Instruction isolation	Prevent webpage text from overriding system/developer instructions.
No automatic tool chaining	Do not let page content trigger unrelated tool calls.
Egress restriction	Prevent the agent from transmitting sensitive context to arbitrary destinations.

The user asked the agent to read a webpage. The webpage should not be able to instruct the agent to use unrelated tools.

Example: Tool-Output Injection

Tool output can also be hostile.

Tool	Injection Path
Web fetcher	Attacker-controlled page returns hidden instructions.
Ticket search	Customer ticket text contains manipulation instructions.
CRM lookup	User-controlled field contains hostile content.
Code search	Repository comments include agent instructions.
Calendar read	Invite body includes malicious instructions.
API response	Upstream response includes text that steers next action.

Tool output should be treated as data, not as a higher-priority instruction.

Defensive Design Principles

Indirect prompt injection is a system problem. Controls need to exist across the architecture.

Principle	Implementation
Separate instruction from data	Use explicit context labels and structured prompts.
Treat retrieved content as untrusted	Documents, emails, webpages, and tool output are data.
Enforce authorization outside the model	Do not rely on model judgment for access control.
Gate high-impact tools	Human approval for send, write, delete, execute, deploy.
Validate tool parameters	Typed schemas, allowlists, policy checks.
Minimize context	Retrieve only what is needed and authorized.
Preserve source attribution	Track where every chunk came from.
Log the decision path	Prompt, retrieval, tool call, approval, output.
Regression test	Add indirect injection cases to CI/security testing.

OWASP's LLM Top 10 identifies prompt injection, insecure output handling, sensitive-information disclosure, insecure plugin design, and excessive agency as major risks. Those categories converge in indirect prompt injection against tool-using agents.

Indirect Prompt Injection Checklist

Question	Good Answer
Do we treat retrieved content as untrusted?	Yes.
Can external content override system instructions?	No.
Can documents trigger tool calls?	Not without policy and approval.
Can email content cause external sending?	Draft-first or approval required.
Can tool output become the next instruction?	No, it is labeled as data.
Is RAG authorization enforced before retrieval?	Yes.
Are high-impact actions gated?	Yes.
Can we reconstruct what content influenced the answer?	Yes.
Do we test indirect prompt injection in CI or pre-release?	Yes.
Can poisoned memory be inspected or removed?	Yes.

What The Review Should Leave Behind

The review should identify the real ingestion surfaces and show where hostile content can influence context, tools, memory, or outbound actions.

Deliverable	Description
Ingestion Surface Inventory	Lists documents, emails, webpages, RAG sources, tools, memory, and APIs.
Trust-Boundary Map	Shows where untrusted content enters model context.
Indirect Injection Abuse-Case Matrix	Documents realistic hostile-content scenarios.
Tool-Call Safety Review	Validates that retrieved content cannot trigger unsafe tool use.
RAG Poisoning Review	Tests stored malicious content and authorization boundaries.
Remediation Roadmap	Prioritizes architectural fixes and regression tests.

Final Thought

Indirect prompt injection is not a strange edge case. It is a predictable consequence of connecting LLMs to real-world content.

The more sources your AI system reads, the larger the injection surface becomes. The more tools your agent can use, the larger the business impact becomes.

Before production, ask:

Which untrusted content sources can influence this agent, and what can the agent do after being influenced?

If you cannot answer that, you do not know the system's real risk.

What TKOResearch Reviews

TKOResearch performs AI Agent Security Assessments for teams deploying RAG systems, MCP tools, copilots, workflow agents, and LLM applications that ingest external or semi-trusted content.

Request AI Agent Security Review

Indirect Prompt Injection Through Documents, Emails, Webpages, and Tool Output