What Is Document Prompt Injection?
Document prompt injection is indirect prompt injection delivered through a file or document that an AI system reads, parses, converts, summarizes, classifies, indexes or otherwise makes visible to a model. The attacker may control the whole document, an editable field, a comment, one section of a shared file, an uploaded attachment or content synchronized from an external source. Direct access to the target assistant is unnecessary: a legitimate user or automated workflow can trigger processing later.
The defining boundary is not a particular file extension. Office and productivity files, collaborative documents, text and markup files, presentation material and other document-like containers can all carry externally authored language into model context. PDF has its own article: PDF Prompt Injection. This page focuses on the generic document-processing path.
Model influence and security impact remain separate. A changed summary, classification or proposed plan demonstrates influence. A security consequence additionally needs a sensitive data or capability path and a missing, overbroad or failed application control.
The End-to-End Document Processing Chain
Real products combine or reorder these stages. Some render first and apply OCR, others traverse package parts, call a conversion service, or send selected text directly to a model. The security task is to document the actual runtime path and the trust decision at each transition.
Trusted processing infrastructure can faithfully return attacker-controlled text. Storage authentication, successful type detection and parser correctness establish properties of the pipeline, not instruction authority for the payload. The model output remains a proposal until deterministic application policy evaluates the initiating principal, data, action, parameters and destination.
Document Attack Success Chain
Every stage is needed for complete end-to-end impact. A document can be present but never processed, processed but not expose the relevant part, visible but not influential, or influential without reaching a protected capability. Report each stage separately rather than labelling mere file presence as compromise.
Controls can break the chain through writer restrictions, processing isolation, part allowlists, provenance, context minimization, detection, least privilege, policy and egress controls. This layered view avoids depending on perfect semantic detection while still treating observable influence as a signal worth investigating.
The chain also describes the constraints an attacker competes against. Processing may never be triggered, the relevant part may not be extracted, conversion may drop or reorder content, provenance labelling may mark the content as untrusted task data, context minimization may exclude it, and deterministic policy may deny the action even after influence is visible.
Offensive Perspective on Document Ingestion
For an authorized assessment, the starting point is not a file but a question of control: which document, field, section, comment, attachment or synchronized record can the tester legitimately author or edit, and under which identity? Content control alone proves nothing. The document must then reach a workflow that actually processes it, through upload, mailbox delivery, a shared drive, a collaboration space, a connector sync, a ticket attachment or an indexing job.
The next constraints are technical rather than linguistic. The file must pass file-type detection, be routed to the parser or converter the product really uses, and have its relevant part traversed by that implementation. Conversion to text, HTML or another intermediate form, OCR of rendered pages and normalization each decide whether controlled content survives at all, and in which order it appears next to the legitimate body.
Which document surface can be authored or edited, and which principal owns that change?
Which realistic task, share, sync or automation brings the document into a processing workflow?
Which parser, version and configuration processes it, and which parts does that implementation actually traverse?
What remains after conversion, OCR, normalization, truncation and chunking?
Which extracted spans enter the exact model context, with which provenance labelling and ordering?
Does document-derived language change the answer, classification, plan or proposed action?
Which data, tools, destinations and write paths would an influenced plan be able to touch?
Which application-side policy decision would have to be missing, overbroad or wrong for an actual side effect?
This page deliberately omits concealment methods, reusable instruction strings, part-placement recipes and any procedure for making content more likely to be extracted. The defensive and offensive value lies in the gate structure and its measurement, not in payload construction.
A Document Is More Than Its Visible Body
Many document formats are containers with multiple logical or physical parts. The body displayed in the default reading view is only one possible representation. WordprocessingML packages can include a main document and separate comments, headers, footers, footnotes and endnotes; related document stories can include text boxes and glossary material. Presentation packages can contain notes. Other formats define different structures.
This does not mean every extractor reads every part. Some process only the main body, some include comments or notes, and some produce different results depending on configuration or conversion path. The security question is therefore empirical and product-specific: which parts are accepted, extracted, retained, labelled and rendered into model context?
The paragraphs, sections or slides shown in the ordinary reading or presentation view.
Comments, annotations and revision-related content where the format and extractor support them.
Headers, footers and template-provided text that may be visually secondary but repeatedly extracted.
Footnotes, endnotes, speaker notes, text boxes and glossary or reusable content where applicable.
Metadata, linked resources and descriptions that only become relevant if a product deliberately surfaces them.
Human View vs. Parser View vs. Model View
| View | What it represents | Security question |
|---|---|---|
| Human rendered view | What a specific application, mode and viewport displays | Could a reviewer reasonably see the material that later affected the model? |
| File or package structure | Parts, relationships, properties and embedded resources in the container | Which parts exist, and who controlled each one? |
| Parser or extractor output | Selected and normalized text, tables, labels, OCR results or object descriptions | What did the processing component emit, omit or flatten? |
| Model-visible context | The exact extracted spans, wrappers, summaries and application instructions sent to the model | Which provenance and authority labels survived context assembly? |
Comments, headers, notes, tracked or revision content where supported, text boxes, metadata, table extraction, image-derived text, object descriptions and converter-generated text can create differences among these views. A difference is not malicious by itself. It is a visibility and provenance condition that becomes security-relevant when unreviewed content is granted influence over sensitive data or capabilities.
A screenshot of the ordinary document view cannot establish what the model saw. Conversely, raw extractor output does not establish what a person saw or intended. Investigation and testing need both representations and the transformation between them.
What Actually Becomes Model-Visible
Paragraphs, headings and structural labels selected by the extractor.
Review content only where the configured parser or connector includes it.
Repeated or section-specific regions that may be included, omitted or deduplicated.
Supporting text whose placement in a flattened stream may differ from the rendered page.
Speaker or presenter notes and analogous supporting parts where the format provides them.
Cell text, captions and row order reconstructed into text or structured context.
Metadata, alternative text or descriptions only when deliberately surfaced.
Derived text or representations from images and scans where the product supports them.
Content from related objects only when the workflow explicitly processes those objects.
Converter text, summaries and RAG chunks created from one or more source parts.
Implementations differ, and no inventory should be treated as universal. Teams should capture the exact model-visible representation for each supported file type and processing configuration. Extraction exposes content; it does not grant that content authority.
Container Validity Is Not Content Trust
| Evidence | What it can support | What it cannot establish |
|---|---|---|
| Valid file format | The container conforms sufficiently for a tool to process it | That natural-language content is safe or authorized |
| Malware-clean result | A scanner did not identify the code or artifact classes it checks | Absence of semantic prompt injection |
| Trusted parser | The organization accepts the component as processing infrastructure | Trustworthiness of parser output |
| Internal repository | The file resides in an organizational system | Who authored every part or whether it may instruct an AI |
| Valid digital signature or integrity evidence | Specified integrity or signer-related properties under that mechanism | Application authority for every statement in the document |
These controls remain useful. File validation and malware scanning address different failure classes, signatures can support integrity and origin decisions, and managed storage can improve access control. The mistake is promoting any of them into a semantic authorization decision they were not designed to make.
Parsing, Conversion and Provenance
Transformations can erase distinctions the next control needs. Comments, notes and body text can collapse into one stream; page, slide and section boundaries can disappear; style and visibility properties can be discarded; OCR can introduce text that was not ordinary selectable document text; and summarization can make externally authored content look like an internal system artifact.
A useful extraction manifest records source file ID, version and cryptographic hash; uploader, owner, tenant and workspace; detected and declared file type; parser, renderer, OCR and converter versions; extracted part type and stable part or element identifier; page, slide or section when meaningful; transformation chain; access label; and the model request or derived artifact that consumed the output.
Keep authoritative provenance outside document-authored fields. A sentence claiming that a section is approved, internal or public is content, not policy metadata. Derived summaries and chunks inherit labels from the control plane and retain links to every source span they summarize.
Office Open XML as a Multi-Part Document Example
ECMA-376 and ISO/IEC 29500 define Office Open XML vocabularies, packaging and document representation. Microsoft documentation describes a typical WordprocessingML package as a set of parts rather than one text stream, including the main document and optional comments, headers, footers, footnotes and endnotes. Presentation packages can likewise include notes.
The defensive conclusion is narrow: the phrase "document text" may refer to several package parts, and a processing product must state which it reads. The standards describe document structure, not AI-security trust. This article intentionally omits XML editing, content placement and concealment techniques.
Worked Example: Enterprise Document Summarizer
An employee asks an enterprise assistant to summarize a collaboratively edited supplier document and identify agreed next steps.
The approved parser returns the main body plus a supported review part. Telemetry preserves the file version, part identifiers and parser version.
One attacker-influenced segment changes the proposed summary and adds an unrelated suggestion to retrieve private account material and send an external update.
The application finds no task authorization for the private retrieval or destination. It rejects both operations while retaining the summary as a draft for review.
The event links source file and part, extracted span, model-visible context, proposal, policy version, denial and any user-visible draft.
Influence occurred because document-derived language changed the proposal. Security impact was contained because protected data never entered context and no unrelated external action executed. The parser did not fail; the architecture correctly treated its output as untrusted task data.
Offensive Review Questions
An authorized document assessment should evidence each gate independently, using synthetic documents, synthetic protected data, bounded permissions and reversible side effects. The questions below structure the review without prescribing an exploitation sequence.
Which document surfaces can be authored, edited or commented on, by which identity, and with which review step in between?
Which user task, automation, connector sync or indexing job causes the document to be processed, and how predictable is it?
Which parser and version runs, and which parts, metadata fields, annotations and notes does it return in this configuration?
Which controlled content survives conversion, OCR, normalization, truncation and chunking, and in which representation?
What exactly reaches the model context, is it labelled with source, part and principal, and how does it compete with the real task?
Which summaries, caches, index entries or embeddings persist after processing, and does deleting the source remove them?
Which tools, data, recipients and write paths become reachable once a plan is influenced?
Which deterministic policy denies the path, and can telemetry separate extraction, inclusion, influence, decision and effect?
Collaborative and Shared Documents
A shared document rarely has one durable author. Employees, guests, external collaborators, automation and synchronized third-party sources may edit different regions under changing permissions. Comments and review workflows add further principals, while ownership transfers and copied versions can detach content from its original access context.
An internal location therefore does not mean trusted content. Record the principal responsible for each source or version where the platform supports it, the connector that imported it, current effective permissions, sharing state and relevant version history. A later internal editor approving one change should not silently endorse every earlier segment as an AI instruction.
Authorization is evaluated at processing time. A service identity that can read the whole workspace must not replace the initiating user's narrower rights. Revocation and ownership changes must invalidate caches and derivatives that no longer match current policy.
Document-to-RAG Pipelines
When documents are parsed, chunked and indexed, a one-time file exposure can become persistent and reach users far from the original upload. Document-level provenance and access policy must survive chunking, embedding, indexing, retrieval and context assembly. Parent ACLs that disappear from child chunks create an authorization failure before prompt influence is considered.
The RAG Prompt Injection article covers retrieval reachability, security trimming, tenant isolation, index generations and derived-artifact cleanup in depth. At this boundary, the document article contributes precise source-part lineage; the RAG layer must preserve it rather than flattening every span into anonymous corpus text.
Document Prompt Injection in Agents
A read-only summarizer limits direct effects. A productivity, coding or workflow agent may also retrieve records, update systems, draft or send email, create tickets, write files or call external services. Document influence then reaches planning and tool selection, but it still creates no authority.
Use task-scoped, short-lived capabilities where practical. Separate read and summarize permissions from write and send permissions. Human approval can support selected high-impact actions, but only when it binds the exact immutable action and expires if the proposal changes.
Potential Impact
A summary, classification, extraction result or recommendation changes in a material way.
Document-derived signals redirect prioritization, routing, review or an operator's decision.
An influenced proposal requests data outside the document task or initiating user's need.
Sensitive model-visible data appears in an answer, draft, log or external destination.
Records, tickets, files or states change without valid application authorization.
Influenced content reaches email, messaging, web or another destination.
Summaries, caches, RAG chunks or memory carry influence into later sessions.
Shared processing or authorization failure carries content or effects across a boundary.
Each outcome is conditional on architecture. Severity is determined by the actual data exposed, action executed, destination reached and affected principal, not by how conspicuous the instruction-like document span appears.
Detection and Telemetry
- 01Source
File ID, version, hash, uploader or connector, owner, tenant, workspace and effective permissions.
- 02Processing
Detected type, parser or converter version, selected part classes, sandbox result and transformation manifest.
- 03Extracted spans
Stable part and element identifiers, page or section where meaningful, and model-visible representation.
- 04Probabilistic signals
Instruction-like language, unusual visibility differences, unexpected part classes, provenance changes and task drift.
- 05Proposal
Model output, proposed retrievals or actions, tool-chain changes and source attribution.
- 06Decision and effect
Policy version, authorization allow or deny, exact parameters, destination and executed side effect.
Unexpected follow-up tools, external destinations, low-provenance spans and divergence between the requested task and proposed plan are useful signals, not proof. Hard evidence comes from file history, authorization decisions and executed-action records. Correlation establishes sequence and context; it rarely proves internal model causality.
Extracted text and model context may contain confidential information. Apply purpose limitation, access controls, retention limits and redaction to telemetry while preserving enough evidence for reconstruction.
Prevention and Secure Architecture
- 01Establish source provenance
Record writer, uploader, connector, ownership, workspace and version without trusting document-authored claims.
- 02Validate and scan separately
Verify file and content type, scan for malware, and recognize that neither control detects semantic prompt injection reliably.
- 03Isolate processing
Sandbox or isolate parsers and converters where appropriate to contain traditional file-processing risks.
- 04Allowlist required parts
Decide which body, review, note, property and object classes the task needs instead of extracting everything by default.
- 05Preserve part-level lineage
Carry source, part, transformation and access labels into every model-visible span and derivative.
- 06Minimize context
Expose only task-required document content and sensitive application data.
- 07Enforce permissions before visibility
Apply repository and RAG authorization before protected content enters model context.
- 08Separate proposal and execution
Treat model output as untrusted proposals and authorize every sensitive action independently.
- 09Constrain capability and egress
Use least privilege, task scope, destination policy, selected bound approvals and observable execution.
- Document
- Extractor
- LLM Agent
- Privileged Action
Extracted content flows directly into a broadly capable agent.
- Document + Provenance
- Isolated Parsing / Extraction Policy
- Part-Level Labels
- Model Context
- LLM Proposal
- Policy / Authorization
- Restricted Action
Representation, authority and execution remain separate throughout the workflow.
The Defense Hub places these controls in the site's broader model for provenance, information flow, least privilege, action control, monitoring and recovery.
Incident Response
Document injection response checklist
- Preserve the original document, exact version and cryptographic hash.
- Preserve source, uploader, owner, tenant, workspace, sharing state, permissions and version history.
- Record the parser, renderer, OCR or converter versions and configuration used.
- Preserve the exact extracted and model-visible representations with part, element, page or section identifiers where meaningful.
- Identify the exact spans and derived chunks involved without publishing reusable payload text.
- Enumerate every user, workflow and tenant that processed the affected version.
- Locate summaries, caches, RAG chunks, index entries, tickets, drafts and memory derived from it.
- Separate observed model influence from data actually disclosed or actions actually executed.
- Quarantine source and derivatives while preserving evidence, then rebuild from known-good material where needed.
- Revoke or rotate credentials only when evidence supports exposure or misuse.
Controlled Defensive Testing
Use synthetic documents, identities, repositories and test tenants. Vary supported document type, parser and version, extracted part classes, collaborators, conversion path, permission state and available capabilities. Test ordinary and secondary parts without publishing concealment methods, reusable prompt strings or payload-generation procedures.
The Document / PDF Prompt Injection lab practices the underlying trust decisions with fictional documents: storage, extraction and document labels versus provenance and application records.
| Metric | Question answered |
|---|---|
| Processing Reachability Rate | How often does the controlled document reach the intended processing workflow? |
| Model-Visibility Rate by part type | How often does each tested part class enter the exact model context? |
| Injection Influence Rate | How often does visible synthetic content change answer, classification, plan or proposal? |
| Policy Bypass Rate | How often does a prohibited influenced path pass application policy? |
| Unauthorized Action Rate | How often does an impermissible side effect execute? |
| Data Disclosure Success Rate | How often does synthetic protected data reach a forbidden output or destination? |
| Detection Recall | How many known synthetic cases produce the expected alert or review signal? |
| False-Positive Rate | How many benign documents are incorrectly flagged? |
| Containment Rate | How often is influence prevented from becoming unauthorized impact? |
Do not combine the metrics. High visibility with low influence describes a different control outcome from high influence with zero policy bypass. The separation shows whether improvement is needed in extraction policy, detection, authorization or containment.
Common Implementation Mistakes
Frequent document-processing errors
- Assuming a malware-clean file is safe from semantic prompt injection.
- Extracting all text without knowing which document parts contribute it.
- Flattening body, comments, notes and derivatives while losing provenance.
- Treating internal storage, a trusted parser or a valid signature as instruction authority.
- Assuming parsing, conversion, OCR or summarization sanitizes semantic instructions.
- Allowing document text to select destinations, permissions or tool scope.
- Running retrieval with a service credential broader than the initiating user.
- Combining read and summarize privileges with write and send privileges by default.
- Deleting the original file while leaving chunks, caches, summaries or memory.
- Recording no linkage from source span and model proposal to policy decision and executed action.
Document Prompt Injection vs. Related Classes
| Class | Primary mechanism | Distinguishing question |
|---|---|---|
| Document prompt injection | Document-derived language influences model interpretation, planning or behavior | Which file part became model-visible and could influence cross a protected boundary? |
| RAG prompt injection | Retrieved corpus content enters context for a later query | Was the content reachable, authorized, retrieved and assembled for this principal? |
| PDF prompt injection | A document subtype with specific rendering and extraction behavior | Which PDF-specific representation did the human, parser and model receive? |
| Document malware or macros | Executable code or active content exploits a runtime | Did code execute rather than language influence a model? |
| Data or knowledge poisoning | Stored information is corrupted to produce false or biased outputs | Was knowledge integrity changed even without instruction-like content? |
| Direct prompt injection | Competing instructions arrive through the primary user-input channel | Did the user directly supply the content to the model-facing interface? |
Classes can coexist without becoming synonyms. A malicious file can contain malware, false claims and instruction-like language, while later RAG ingestion adds persistence. Each finding needs its own evidence and control response. The PDF Prompt Injection article covers that format's particular rendering and extraction surface.
Standards and Research Context
Reviewed classifications and document references
- OWASP GenAI Security Project
- LLM01:2026 Prompt Injection
- NIST
- NIST AI 100-2e2025 terminology, NIST Glossary: indirect prompt injection
- Document standards
- ECMA-376 Office Open XML, ISO/IEC 29500 context, Microsoft WordprocessingML structure documentation
- Research
- Greshake et al. 2023
OWASP LLM01:2026 describes indirect prompt injection through external sources such as files and treats retrieved documents and memory as a single token stream with no enforced trust boundary, so retrieval is not a mitigation boundary for prompt injection. NIST AI 100-2e2025 and the NIST glossary describe indirect prompt injection through control of a resource rather than the primary user input. These sources support the attack classification, not a claim that every processed document is malicious.
Microsoft guidance treats documents and other external content as untrusted input and recommends defense in depth around content marking, plan and tool-chain monitoring, information flow, least privilege, policy and selected human approval. Its Input, Context, and Retrieval Hygiene guidance states specifically that every prompt, document, retrieved chunk, tool result and memory write should be treated as untrusted input, and that secure retrieval requires source provenance, permission-aware indexing and validation at every read and write. That applies directly to extracted document parts and to the summaries, caches and index entries derived from them. ECMA-376 and Microsoft Open XML documentation are used only for factual package and part structure. They are not AI-security standards and do not assign trust.
Greshake et al. provides broader research context for indirect prompt injection against LLM-integrated applications. No CWE or CAPEC mapping is asserted, and no source is treated as a universal prevention guarantee.
Frequently Asked Questions
Is a malware-clean document safe for an AI assistant?
No. Malware scanning addresses known malicious code and file artifacts, not whether natural-language content can influence a model. Both controls are needed for different risks.
Can comments or notes become model-visible?
Yes, if the product's parser, connector or converter includes them. Many implementations omit them. Verify the exact supported formats, parts and configuration.
Does a digital signature make document content trusted instructions?
No. A signature can support specified integrity or signer properties. It does not grant the signed prose authority to direct an AI workflow.
Is hidden content required for document prompt injection?
No. Clearly visible ordinary text can remain untrusted and influence a model. The security problem is authority and application control, not concealment.
Why can a model see text a user did not notice?
The parser may include secondary parts, normalize tables, run OCR or flatten content differently from the user's viewing application. Capture all three views during testing.
Does converting a document to plain text remove prompt injection?
No. Conversion changes representation and may reduce active-file risks, but instruction-like semantic meaning can survive in the resulting text.
What changes when documents enter RAG?
Parsed spans become persistent chunks and index entries that later users may retrieve. Provenance, access labels and revocation must survive every derivative.
How should document-processing agents be authorized?
Use the initiating principal's current permissions, task-scoped capabilities, independent policy for every sensitive action and destination, and bound approval for selected high-impact effects.
References
- LLM01:2026 Prompt InjectionOWASP GenAI Security Project · GuidanceReviewed 2026-09-20
- Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, NIST AI 100-2e2025NIST · Standard · 2025-03Reviewed 2026-09-20
- indirect prompt injectionNIST Glossary · Technical documentationReviewed 2026-09-20
- Defend against indirect prompt injection attacksMicrosoft Learn · GuidanceReviewed 2026-09-20
- Input, Context, and Retrieval HygieneMicrosoft Learn · GuidanceReviewed 2026-09-20
- ECMA-376 Office Open XML File FormatsEcma International · StandardReviewed 2026-09-20
- Structure of a WordprocessingML documentMicrosoft Learn · Technical documentationReviewed 2026-09-20
- Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt InjectionKai Greshake et al. · Research publication · 2023Reviewed 2026-09-20