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

A user asks an assistant to summarize a vendor questionnaire. A paragraph in the questionnaire tells the assistant to send internal files to a different address. The paragraph is part of the material being reviewed; it has no authority to change the task.

Indirect prompt injection occurs when instructions embedded in retrieved or otherwise external content influence the model's behavior. The attacker may control a document, email, webpage, ticket field, tool description or tool result without controlling the user's request. OWASP's prompt-injection guidance describes these external-content paths.

Assess both the model's response and the application's enforcement. A refusal may stop this attempt. If the model follows the paragraph, the application still needs to reject an unauthorized read or send.

Follow the questionnaire through the normal path

The authorized task is simple:

User: "Summarize this uploaded vendor questionnaire."
Application extracts the document text.
Assistant produces a summary for the authorized user.

Now include a hostile paragraph in the source fixture and let it pass through the same parser, chunker and retrieval process used by ordinary documents. Keep the requested destination inert and use test records. A payload pasted directly into the model bypasses these steps and answers a different question.

Observe the transitions. Was the paragraph extracted? Did retrieval select it? Did the model change the summary, request another document or propose a tool call? Did policy allow that operation? Did the downstream system change?

A successful extraction test does not establish a model failure. A model that requests a send does not establish that the send occurred. Recording each step makes the result useful for remediation.

Choose surfaces an attacker can actually influence

Source reputation does not settle the trust question. An approved internal wiki may contain an external paste. A trusted API can return user-controlled text. Identify who controls the particular field, then test how the application handles it.

Tool access changes what the instruction can accomplish

A summarizer can disclose protected context through its answer even if it has no write tools. Adding email, record updates or command execution creates further paths.

For the questionnaire example, inspect both the data permission and the destination permission. The user might be allowed to read an internal file without being allowed to email it to the address in the document. Checking those permissions independently can miss the prohibited transfer.

A draft-first workflow gives a person a chance to review a message. Bind any approval to the actual recipients, content and attachments, and recheck authority before sending. Where a workflow permits automated sends, enforce its recipient and content rules outside the model. The source document cannot expand that policy.

The same rule applies to a tool chain. A successful search or API call does not authorize the next operation. Validate its parameters, target and current permissions again.

Separate useful mitigations from the final check

Label source content and preserve its origin. Structured extraction can reduce instruction blending and make a response easier to validate. Remove unnecessary hidden or active content from ingestion where appropriate.

None of those measures guarantees that the model will ignore hostile prose. A visible sentence can carry the attack, and stripping every imperative can destroy legitimate content. Test the model with the source representation your application actually uses.

At execution, require typed inputs and server-side authorization. Limit the tools and destinations available to the workflow. Keep credentials outside context. Use network and runtime restrictions where an agent can fetch URLs or execute code. A model-generated claim that the user approved an action must not satisfy the approval check.

Retrieval needs its own authorization checks before protected content reaches a model, an external reranker or the user. Output filtering cannot undo disclosure to an upstream processor.

Check persistence and recovery

If the assistant saves a summary or memory, inspect whether the injected instruction survives there. Removing the original document may leave a copied instruction in a cache, index, draft or later conversation.

Record source references and derived copies so an operator can correct the affected state. Test whether disabling a tool or revoking a credential stops queued and in-flight work. An “off” switch in the interface is incomplete if the worker continues to act.

Keep limits on retries, time and resource use. An attacker may seek repeated operations or cost rather than a single dramatic disclosure.

Record attempts and effects separately

For each test, retain the source fixture, authorized task, model and configuration, proposed tool arguments, policy result and downstream observation. Store safe parameter fields and protected references instead of unrestricted prompts, secrets or customer documents in ordinary logs.

Include a legitimate task beside the attack case. If the fix rejects every document or disables every tool, it may contain the attack while breaking the intended workflow. Acceptance should cover both the denied operation and the permitted one.

The report should identify the failed boundary and the smallest correction that addresses it. A redirected model stopped by a working policy gate calls for a different response from confirmed disclosure. Keep the test's limitations visible when the result is summarized for a release decision.

The two-tenant RAG walkthrough provides an inert hostile-document fixture and local access checks. Add a separately authorized model evaluation before making claims about your deployed assistant.

Sources

• OWASP LLM Prompt Injection Prevention Cheat Sheet
• OWASP AI Agent Security Cheat Sheet
• OWASP 2025 LLM Top 10