Modern applications increasingly rely on AI-powered systems to read documents, summarize web pages, analyze emails, and retrieve information from internal knowledge bases. While these capabilities improve productivity, they also introduce a security risk known as indirect prompt injection.
Unlike direct prompt injection, where an attacker submits malicious instructions directly through a user prompt, indirect prompt injection hides instructions inside external content. This content may include PDF documents, Word files, web pages, emails, database records, or information retrieved through a Retrieval-Augmented Generation (RAG) pipeline.
The problem occurs when an application processes this content and treats malicious instructions as legitimate guidance rather than untrusted data.
For example, an employee may ask an internal assistant to summarize a business document. The document appears harmless, but it contains hidden instructions designed to manipulate the application’s behavior or influence its access to confidential information.
As organizations adopt document-processing systems, web browsing capabilities, and autonomous workflows, indirect prompt injection has become an important area of AI application security testing.
This guide explains how indirect prompt injection works, common attack techniques, practical penetration-testing scenarios, and security controls that help protect applications against malicious external content.
What Is Indirect Prompt Injection?
Indirect prompt injection is a security attack in which an attacker places malicious instructions inside external content that an application later processes.
The attacker does not need to interact directly with the target application. Instead, the attacker manipulates a document, web page, email, or another information source that the application trusts or retrieves.
When the application processes the content, the embedded instructions may influence the model’s response or trigger unintended actions.
For example:
- An attacker creates a document containing hidden instructions.
- The document is uploaded to a shared knowledge base.
- An employee asks an internal assistant to summarize the document.
- The application retrieves and processes its content.
- The embedded instructions influence the generated response.
- Depending on the application’s permissions and integrations, sensitive information may be exposed or an unauthorized action may be attempted.
The attack becomes more dangerous when the application has access to external tools, internal databases, email services, or confidential business information.
According to OWASP’s Prompt Injection guidance, indirect prompt injection occurs when malicious instructions enter an application’s context through external sources rather than directly through the user’s message.
Direct Prompt Injection vs Indirect Prompt Injection
Both techniques attempt to influence an application’s behavior, but they differ in how the malicious instructions reach the system.
| Feature | Direct Prompt Injection | Indirect Prompt Injection |
|---|---|---|
| Attack source | User input | External content |
| Delivery method | Chat or application input | Documents, websites, emails, databases |
| Attacker interaction | Direct | Often indirect |
| Common target | User-facing prompt interface | Retrieval and content-processing workflows |
| Example | Malicious chat instruction | Hidden instruction inside a PDF |
| Main security concern | Instruction manipulation | Untrusted content influencing application behavior |
Direct Prompt Injection Example
An attacker directly enters a malicious instruction into a chat interface, attempting to override the application’s intended behavior.
The attack originates from the user’s input.
Indirect Prompt Injection Example
An attacker uploads a document containing malicious instructions to a shared repository.
Later, an employee asks an assistant to summarize that document. The application retrieves the malicious content and processes it as part of its context.
The employee may have submitted a completely legitimate request, but the application encounters attacker-controlled instructions during processing.
How Does Indirect Prompt Injection Work?
Indirect prompt injection generally follows a sequence involving content manipulation, retrieval, context processing, and unintended behavior.
1. Content Preparation
The attacker creates or modifies external content.
Possible locations include:
- PDF documents.
- Word documents.
- HTML pages.
- Public websites.
- Email messages.
- Shared knowledge bases.
- Source code repositories.
- Database records.
The attacker embeds instructions designed to influence how the application processes the content.
2. Content Ingestion
The target application collects information from an external source.
For example, an enterprise application may automatically index documents stored in SharePoint, Google Drive, or an internal document management system.
During ingestion, the system extracts text and other relevant information.
3. Retrieval and Context Injection
When a user submits a request, the application searches its data sources and retrieves relevant content.
The retrieved information is added to the model’s context.
If the retrieved content contains malicious instructions, those instructions may influence subsequent processing.
4. Instruction Manipulation
The application may interpret attacker-controlled content as instructions instead of treating it as untrusted information.
This can affect the generated response or influence decisions about connected tools.
5. Unintended Action or Output
Depending on the application’s design, the result may include:
- Misleading summaries.
- Unauthorized information disclosure.
- Manipulated recommendations.
- Incorrect business decisions.
- Unintended tool execution.
- Unauthorized external communications.
The actual impact depends on the application’s permissions, architecture, and security controls.
Common Types of Indirect Prompt Injection Attacks
Attackers can introduce malicious instructions through different content sources. Security testers should understand each attack surface because the security controls may differ between ingestion, retrieval, and application processing.
1. Document-Based Prompt Injection
Document-based prompt injection occurs when malicious instructions are embedded inside files processed by an application.
Common file formats include:
- PDF.
- DOCX.
- TXT.
- Markdown.
- HTML.
- CSV.
An attacker may upload a document containing visible or hidden instructions that influence the application when it reads or summarizes the file.
Example:
An organization uses an internal assistant to summarize uploaded financial reports.
An attacker submits a modified report containing instructions intended to make the application retrieve additional confidential information.
When an employee requests a summary, the application processes both the legitimate report content and the malicious instructions.
Security impact:
- Sensitive information disclosure.
- Manipulated summaries.
- Unauthorized tool requests.
- Incorrect business recommendations.
Testing considerations:
- Review document extraction behavior.
- Inspect hidden text and metadata.
- Compare visible document content with extracted text.
- Check how the application handles suspicious instructions.
- Verify that document content cannot authorize sensitive actions.
2. Web Page-Based Prompt Injection
Web-based prompt injection occurs when an application retrieves content from websites that contain malicious instructions.
Applications with browsing or web-search capabilities may process content from both trusted and untrusted websites.
Attackers may manipulate:
- HTML content.
- Hidden page elements.
- Metadata.
- Comments.
- Page fragments.
- Embedded external resources.
Example:
A research assistant is asked to summarize a public article.
The article contains hidden instructions attempting to influence the generated summary or request additional information from connected services.
If the application fails to maintain a boundary between website content and trusted instructions, the result may be manipulated.
Security impact:
- Biased or misleading summaries.
- Unintended data disclosure.
- Manipulated research results.
- Unwanted external requests.
Microsoft documents historical indirect prompt injection scenarios involving malicious instructions embedded in web pages and documents.
Reference: Microsoft – Prompt Injection: Direct and Indirect.
3. Email-Based Prompt Injection
Email is another potential source of indirect prompt injection.
An organization may use an application to summarize incoming messages, extract meeting details, classify support requests, or prepare responses.
An attacker can send an email containing malicious instructions that may influence the processing workflow.
Example:
An employee asks an email assistant to summarize recent messages.
One message contains instructions attempting to make the application disclose information from other conversations.
If the application has broad mailbox access and insufficient authorization controls, this could create a privacy risk.
Security impact:
- Exposure of confidential email content.
- Manipulated email summaries.
- Unauthorized external communication.
- Unintended workflow execution.
4. Retrieval-Augmented Generation (RAG) Prompt Injection
Retrieval-Augmented Generation, commonly called RAG, allows an application to retrieve relevant information from external or internal knowledge sources before generating a response.
RAG systems often use:
- Document ingestion pipelines.
- Embedding models.
- Vector databases.
- Similarity search.
- Retrieval filters.
- Context construction.
Indirect prompt injection can occur when malicious content enters the retrieval pipeline and is later included in the model’s context.
Example:
A company maintains an internal knowledge base containing employee policies and technical documentation.
An attacker manages to upload a malicious document to a shared collection.
The document is processed, converted into embeddings, and stored in the vector database.
Later, an employee submits a query that causes the malicious document to appear in the retrieved results.
The application processes the retrieved content, potentially allowing the embedded instructions to influence its response.
Security impact:
- Knowledge base poisoning.
- Unauthorized data retrieval.
- Manipulated responses.
- Cross-user information exposure.
- Unintended downstream tool calls.
For further technical guidance, review the OWASP RAG Security Cheat Sheet.
Common Indirect Prompt Injection Attack Techniques
Understanding common attack techniques helps security professionals identify weaknesses during application assessments.
1. Hidden Instructions
Attackers may hide malicious instructions in content that appears harmless to human readers.
Possible locations include:
- White text on a white background.
- Small or visually obscured text.
- HTML comments.
- Document metadata.
- Hidden webpage elements.
- Text extracted from embedded content.
A document may look normal when opened manually but produce additional instructions during automated text extraction.
2. Unicode and Text Manipulation
Some documents contain unusual Unicode characters, zero-width characters, or visually confusing text.
These techniques may make suspicious instructions harder to identify during manual inspection.
Security testers should compare the original document with its extracted text representation.
3. Context Manipulation
An attacker may place instructions near legitimate information to make them appear relevant to the user’s request.
For example, a malicious instruction may be included in a technical report under a heading such as “Additional Processing Requirements.”
The application may give the content more attention because it appears related to the requested task.
4. Document Poisoning
Document poisoning occurs when malicious content is added to a knowledge base or retrieval corpus.
The poisoned content may be retrieved repeatedly and influence multiple user sessions.
This is especially important in enterprise environments where many users share the same document repository.
5. Multi-Stage Prompt Injection
Some attacks involve multiple content sources or processing stages.
For example:
- A malicious webpage contains an instruction.
- A research application extracts the content.
- The extracted information is stored in an internal knowledge base.
- Another application retrieves the stored information.
- The second application processes the malicious instruction.
This creates a persistent content-based attack path across multiple systems.
How to Test Indirect Prompt Injection: Practical Security Assessment
Penetration testers should evaluate indirect prompt injection through a controlled methodology.
Testing must be performed in an authorized environment using test documents, controlled web pages, and non-sensitive information.
1. Identify External Content Sources
Start by identifying every external source processed by the application.
Assessment checklist:
- Identify supported document formats.
- Identify web browsing capabilities.
- Review email integrations.
- Identify connected knowledge bases.
- Identify database retrieval sources.
- Review file upload functionality.
- Identify external API integrations.
- Understand how retrieved content reaches the model.
- Identify shared and user-specific data sources.
Objective: Build a clear understanding of where untrusted content can enter the application.
2. Inspect Document Processing
Review how the application extracts information from uploaded documents.
Assessment checklist:
- Upload a controlled test document.
- Compare visible content with extracted text.
- Inspect document metadata.
- Check for hidden text.
- Review HTML and embedded content extraction.
- Test unusual Unicode characters.
- Check whether unsupported content is rejected.
- Verify that file processing does not execute embedded active content.
Objective: Determine whether hidden or manipulated content can enter the application’s processing pipeline.
3. Test Web Page Retrieval
If the application supports web browsing, create a controlled test page containing ordinary content and a clearly identifiable test instruction.
Assessment checklist:
- Identify how URLs are processed.
- Test trusted and untrusted domains.
- Review webpage content extraction.
- Check handling of HTML comments.
- Inspect metadata and hidden elements.
- Verify whether page instructions influence application behavior.
- Check whether external links are accessed automatically.
- Review outbound network restrictions.
Objective: Verify that webpage content is treated as untrusted information rather than authoritative instructions.
4. Test RAG Retrieval Security
RAG testing should cover the complete lifecycle of a document, from ingestion to retrieval and response generation.
Assessment checklist:
- Identify document ingestion sources.
- Review document approval workflows.
- Inspect embedding and indexing processes.
- Test retrieval of controlled poisoned documents.
- Verify document-level access controls.
- Test cross-user retrieval.
- Test cross-tenant retrieval.
- Check whether revoked permissions are enforced.
- Review source attribution.
- Verify document deletion and index cleanup.
Objective: Determine whether malicious or unauthorized content can influence responses through retrieval.
5. Test Instruction and Data Separation
The application should maintain a clear distinction between trusted application instructions and untrusted external content.
Assessment checklist:
- Review how retrieved content is added to context.
- Check whether external content is clearly identified.
- Test whether malicious instructions override expected behavior.
- Verify that retrieved content cannot modify application permissions.
- Check whether tool calls require independent authorization.
- Verify output validation.
- Test whether the application follows the original user request.
Objective: Identify whether external content can influence security-sensitive application behavior.
6. Test Downstream Tool Execution
The highest-risk scenarios often occur when an application can perform actions using connected services.
Assessment checklist:
- Identify tools accessible during content processing.
- Test unauthorized file access.
- Review database operation permissions.
- Check email-sending capabilities.
- Verify external API authorization.
- Test approval requirements.
- Check whether tool arguments are validated.
- Verify that untrusted content cannot authorize sensitive operations.
Objective: Confirm that malicious content cannot trigger unauthorized actions.
Practical Indirect Prompt Injection Testing Scenario
Consider an enterprise application that allows employees to upload documents and generate summaries.
The application has access to an internal knowledge base containing confidential business information.
A penetration tester creates a controlled document containing:
- Normal business information.
- A harmless embedded instruction asking the application to ignore its original summarization task.
- A unique test marker that can be identified in the output.
The tester uploads the document and requests a summary.
The tester then evaluates the response.
Expected secure behavior:
- The application summarizes the document’s legitimate content.
- The embedded instruction is treated as untrusted text.
- No additional confidential resources are accessed.
- No unauthorized tools are invoked.
- The application records relevant security events.
Potential vulnerability:
If the application follows the embedded instruction and performs an action outside the original request, the tester should investigate the context-handling and authorization controls.
Evidence to collect:
- Original test document.
- Extracted document text.
- Retrieval results.
- Relevant application logs.
- Tool invocation records.
- Final response.
- Authorization decisions.
Do not use real credentials, production customer information, or uncontrolled external destinations during this test.
Tools Used for Indirect Prompt Injection Testing
Several established security tools can help assess the application components involved in indirect prompt injection.
1. Burp Suite
Burp Suite is useful for analyzing web-based applications and API integrations.
Common testing activities include:
- Inspecting document upload requests.
- Reviewing API responses.
- Testing session authorization.
- Modifying request parameters.
- Examining retrieval endpoints.
2. OWASP ZAP
OWASP ZAP helps identify common web application weaknesses that may affect document-processing and retrieval interfaces.
It can support:
- Web application scanning.
- Request and response inspection.
- Passive security analysis.
- API security testing.
3. Python
Python can help automate document inspection and test-content generation.
For example, the following script extracts text from a PDF so that testers can compare the extracted content with what is visually displayed.
import fitz
document = fitz.open("test-document.pdf")
for page_number, page in enumerate(document):
print(f"Page {page_number + 1}")
print(page.get_text())This is useful when investigating hidden or unexpected text in PDF files.
4. Semgrep
Semgrep can help identify insecure application code patterns involving document processing, input handling, and unsafe execution.
5. AI Security Testing Frameworks
Specialized testing frameworks can help evaluate prompt injection resistance and application behavior.
Examples include:
- Microsoft’s PyRIT.
- garak.
- NVIDIA NeMo Guardrails.
These tools support different testing objectives and should be selected according to the application’s architecture.
No single scanner can establish that an application is protected against all indirect prompt injection attacks. Manual validation remains important.
How to Prevent Indirect Prompt Injection
Preventing indirect prompt injection requires multiple security controls across the entire content-processing pipeline.
1. Treat External Content as Untrusted
Documents, web pages, emails, and retrieved information should never automatically receive the same trust level as application instructions.
Maintain explicit trust boundaries between instructions and external data.
2. Validate Documents Before Ingestion
Review documents before adding them to shared knowledge bases.
Recommended controls include:
- File type validation.
- Content inspection.
- Metadata analysis.
- Hidden text detection.
- Source verification.
- Document integrity checks.
- Approval workflows.
3. Implement Retrieval Access Controls
A user should only retrieve information they are authorized to access.
Apply permissions during retrieval rather than relying exclusively on permissions checked during document ingestion.
4. Use Context Separation
Clearly identify external content as data.
Use structured message roles, content delimiters, and application-level controls to reduce the risk of external instructions being interpreted as trusted commands.
However, delimiters and prompt wording alone are not sufficient security controls.
5. Apply Least Privilege
Limit access to connected databases, email accounts, APIs, and file systems.
An application that only summarizes documents should not automatically have permission to delete files or send external emails.
6. Validate Tool Calls
Every sensitive operation should pass independent authorization checks.
Never assume that a tool call is safe simply because it originated from an application that received a legitimate user request.
7. Require Human Approval
Require explicit approval for high-impact actions, such as:
- Sending confidential information.
- Deleting business records.
- Modifying financial information.
- Changing access permissions.
- Executing administrative operations.
8. Monitor Retrieval and Application Activity
Monitor unusual document retrieval patterns, repeated injection attempts, suspicious external requests, and unexpected tool execution.
9. Maintain Document Provenance
Track:
- Document source.
- Uploading user.
- Upload timestamp.
- Approval status.
- Integrity information.
- Modification history.
This helps security teams investigate suspicious documents and identify their origin.
10. Perform Regular Security Assessments
Test document processing, web retrieval, RAG pipelines, and connected tools whenever the application architecture changes.
For additional recommendations, refer to the OWASP LLM Prompt Injection Prevention Cheat Sheet.
Real-World Business Impact
Indirect prompt injection can affect organizations across different industries.
Financial Services
An internal financial assistant retrieves reports and transaction information.
A malicious document may influence the application to produce misleading financial summaries or request unauthorized access to sensitive records.
Healthcare
A healthcare application processes patient documents and medical records.
Malicious content may influence summaries or cause sensitive information to be included in an inappropriate response.
Software Development
Development assistants read source code, issue descriptions, pull requests, and repository documentation.
A malicious issue or README file may contain instructions attempting to influence code modifications or expose confidential repository information.
Enterprise Knowledge Management
A company maintains a shared document repository.
If employees can upload content without approval or integrity checks, an attacker may introduce poisoned documents that influence multiple users’ retrieval results.
These examples demonstrate that indirect prompt injection is not limited to chatbot interfaces. It can affect any application that processes untrusted content.
Career Opportunities in AI Application Security
As organizations adopt more advanced document-processing and retrieval systems, professionals with knowledge of AI application security will have opportunities across several cybersecurity roles.
Relevant positions include:
- AI Security Engineer.
- Application Security Engineer.
- Penetration Tester.
- AI Red Team Specialist.
- API Security Engineer.
- Security Researcher.
- Product Security Engineer.
Professionals interested in this field should understand:
- Web application security.
- API penetration testing.
- Prompt injection.
- RAG architecture.
- Document processing.
- Access control.
- Secure coding.
- Data protection.
Building practical experience through “https://vuln.pentesthint.com/” hands-on labs and structured “https://academy.pentesthint.com/” cyber security training can help develop the skills required to assess modern applications.
Future of Indirect Prompt Injection Security
Indirect prompt injection will remain an important security concern as applications process more external content and connect to additional business services.
Future assessments will increasingly focus on the complete information lifecycle.
This includes document ingestion, content extraction, retrieval, context construction, output validation, memory management, and downstream action execution.
Organizations will also need stronger controls around document provenance, permission-aware retrieval, automated security testing, and agent activity monitoring.
The objective should not be to rely on a single prompt filter or detection mechanism. Security must be enforced throughout the application architecture.
Frequently Asked Questions (FAQs)
1. What is indirect prompt injection?
Indirect prompt injection is an attack in which malicious instructions are embedded in external content, such as documents, websites, emails, or database records. An application processes this content and may unintentionally follow the embedded instructions.
2. What is the difference between direct and indirect prompt injection?
Direct prompt injection originates from user-submitted instructions. Indirect prompt injection originates from external content that an application retrieves or processes.
3. Can PDF documents contain indirect prompt injection attacks?
Yes. PDF files can contain visible or hidden text, metadata, and other content that may influence an application’s processing behavior. Testers should inspect both the rendered document and its extracted text.
4. How does indirect prompt injection affect RAG systems?
A malicious document can enter a retrieval corpus and later appear in search results. When the application includes that content in its context, the embedded instructions may influence its responses or downstream actions.
5. How can penetration testers identify indirect prompt injection?
Testers can use controlled documents and webpages containing harmless test instructions, inspect extracted content, review retrieval results, monitor tool calls, and verify that external instructions cannot bypass application authorization.
6. Can indirect prompt injection be completely prevented?
There is no reliable single control that eliminates all prompt injection risks. Organizations should combine content validation, trusted-source management, permission-aware retrieval, least privilege, output validation, and human approval.
7. What tools are useful for indirect prompt injection testing?
Burp Suite, OWASP ZAP, Python, Semgrep, PyRIT, and garak can support different aspects of security assessment. Manual testing is necessary to validate application-specific behavior.
8. What is document poisoning in cybersecurity?
Document poisoning occurs when an attacker introduces malicious or manipulated content into a document repository or retrieval system. If the application later processes that content, it may influence generated responses or application behavior.
Conclusion
Indirect prompt injection introduces a significant security challenge for applications that process documents, websites, emails, and retrieved information.
Unlike traditional attacks that directly target an application interface, these attacks exploit the trust placed in external content. A harmless-looking document or webpage can become an entry point for manipulating application behavior.
A comprehensive security assessment should examine document ingestion, hidden content, web retrieval, RAG pipelines, context separation, tool execution, and access-control enforcement.
Organizations should treat all external content as untrusted, apply permission-aware retrieval, restrict connected tools, and require independent authorization for sensitive actions.
For more practical cybersecurity tutorials, penetration-testing methodologies, and application security resources, visit “https://pentesthint.com/” PentestHint.
Never trust external content blindly. Validate every source. Protect every processing boundary.
