PDF Prompt Injection

What Is PDF Prompt Injection?

PDF prompt injection is indirect prompt injection delivered through a PDF file that an AI system reads, extracts, renders, summarizes, classifies, indexes or otherwise turns into model-visible content. The attacker may author the whole file, supply one attachment, fill a form field, add an annotation, or influence a document that is later exported to PDF. Direct access to the assistant is not required: a legitimate user, connector or batch job triggers processing later.

What makes PDF distinctive is not a special kind of instruction. It is that one PDF can yield several different representations of "its content", and those representations do not have to agree with each other. A person sees rendered pages in one viewer. A text extractor emits a stream whose order and completeness depend on the implementation. A rendering-plus-OCR path produces a third result. Annotations, form field values, attachments and metadata may or may not be included at all.

Model influence and security impact stay separate. A changed summary or classification shows influence. A security consequence additionally requires a sensitive data or capability path and a missing, overbroad or failed application control.

PDF vs. Generic Document Prompt Injection

The Document Prompt Injection article covers the general container problem: office and open formats, markup and plain text, collaborative editing, conversion pipelines and the parts a parser may or may not traverse. Everything there applies to PDF as well. This page adds only what is specific to a fixed-layout, object-graph format that is usually consumed through extraction or rendering rather than through a structured editing model.

Where both pages would say the same thing, this one links instead of repeating. The shared conclusion remains: representation determines exposure, and exposure is not authority.

Not Malware, Not a File-Format Exploit

PDF has a long security history that has nothing to do with prompt injection: embedded JavaScript actions, launch and URI actions, malicious embedded files, and memory-safety bugs in parsers and renderers. Those are code-execution and traditional-exploit problems. They are addressed by sandboxing, disabling active features, patching and malware scanning.

Prompt injection is a different failure class. No code executes. Ordinary language that a processing pipeline turns into model-visible text influences an interpretation or a plan. A file can be perfectly benign by every malware and format-conformance measure and still carry content that changes an assistant's proposal.

How PDFs Are Processed End to End

Products combine these stages differently. Some extract the text layer and stop. Some rasterize pages and run OCR or a vision model. Some do both and merge the results. Some route scanned files down a different path than digitally generated ones. The security task is to document the runtime path that actually runs for each supported case, and the trust decision at every transition.

Trusted infrastructure faithfully returns untrusted content. A successful upload, a correct type check and a well-behaved parser establish properties of the pipeline, not authority for the text the pipeline emitted.

The Multi-Representation Problem

A single PDF can produce many different content views. Which of them exists in a given product depends entirely on its processing configuration.

None of this is inherently malicious. It is a visibility and provenance condition: the content that influenced a model may not be the content a reviewer saw, and vice versa.

What Actually Becomes Model-Visible

A screenshot cannot establish what the model received, and raw extractor output cannot establish what a person saw. Investigations and tests need both, plus the transformation between them. Teams should capture the exact model-visible representation per supported PDF class - digitally generated, scanned, form-bearing, annotated, mixed - rather than assuming one behaviour.

Parser, Renderer and Extractor Variance

Two conformant tools can return different text for the same page. Reading order is reconstructed rather than declared, so multi-column layouts, tables, footnotes, headers and floating elements can be ordered differently. Character mapping, ligatures, spacing heuristics and font encoding affect what the emitted string looks like. Rendering fidelity differs. OCR adds its own error and ordering profile.

This variance matters for three reasons. It means a security test result is tied to the exact library and version tested. It means a content span invisible in one pipeline can be prominent in another. And it means an incident reconstruction must record which component and version produced the representation that reached the model - otherwise the evidence cannot be reproduced.

Version pinning, a documented extraction configuration and re-testing after library upgrades are therefore part of the control set, not housekeeping.

Attacker Prerequisites and Delivery Surfaces

A PDF only matters to an AI system once it reaches a processing workflow. The realistic delivery surfaces are ordinary business channels.

Each surface has a different prerequisite: an account, an email address, a customer relationship, edit rights in a space, or merely a public URL. Enumerating who can place a file into which pipeline is the first step of both threat modelling and an authorized assessment.

Offensive Perspective on PDF Ingestion

In an authorized assessment the starting question is not how to write a clever file. It is which PDF surface the tester can legitimately control, under which identity, and which realistic task would cause that file to be processed at all. Control without reachability produces no finding.

The following constraints are technical rather than linguistic. The file must be accepted by size, type and policy checks. It must be routed to the extraction path the product truly uses, which may be a text layer, a rendering plus OCR path, or a vendor conversion service. The relevant object class - page content, annotation, form field, attachment, metadata - must be one the implementation returns. What survives normalization, truncation and chunking then decides what the model sees, and in which order relative to the legitimate task material.

Because this page is written for defenders and authorized testers alike, it explains the barrier structure and how to measure each stage. It deliberately omits concealment techniques, reusable instruction strings, object-placement recipes and any procedure for increasing extraction or influence probability. Those implementation details stay in the cited research.

PDF Attack Success Chain

Every gate is necessary for a complete end-to-end security impact, and every gate is separately testable. Reporting should keep them apart: a file that is accepted is an intake finding, an extracted controlled span is an extraction finding, a changed summary is an influence finding, and only a failed authorization decision with a real side effect is an authorization finding.

Controls can break the chain at several points: restricting who can submit files, restricting accepted object classes, isolating parsing, labelling provenance, minimizing context, detecting task drift, enforcing least privilege and applying deterministic policy before any consequential action. This layered view avoids depending on perfect semantic detection while still treating observed influence as a signal worth investigating.

Competing Constraints for an Attacker

The chain also describes what an attacker competes against, which is why real-world exploitation is far less certain than a laboratory demonstration suggests.

These constraints are the reason stage-wise measurement is more informative than a single success number: they tell a team which gate is actually carrying its defensive weight.

Offensive Review Questions

An authorized PDF assessment should evidence each gate independently, using synthetic files, synthetic protected data, bounded permissions and reversible side effects. These questions structure the review without prescribing an exploitation sequence.

Worked Scenario: Automated Invoice Intake

Influence occurred, because PDF-derived language changed the proposal. Impact was contained, because the synthetic protected ledger never entered context and no external action executed. The extractor did not fail; the architecture treated its output as untrusted task data. All data in such an exercise should be synthetic and every side effect reversible.

PDFs in RAG and Derived Artifacts

PDF is one of the most common formats in enterprise retrieval corpora. Once a file is parsed, chunked and indexed, a one-time exposure becomes persistent and can reach users far from the original upload. Source-level provenance and access policy must survive chunking, embedding, indexing, retrieval and context assembly; document ACLs that disappear from child chunks are an authorization failure before prompt influence is even considered.

Deleting the source PDF does not automatically remove its derivatives. Summaries, caches, index entries, embeddings and memory writes can outlive the file and must be enumerated and invalidated explicitly. The RAG Prompt Injection article covers retrieval reachability, security trimming, tenant isolation and index generations in depth; this page contributes the page- and object-level lineage that the retrieval layer must preserve rather than flatten.

Detection and Telemetry

These signals establish sequence and context; they rarely prove internal model causality. Hard evidence comes from file history, authorization decisions and executed-action records. Extracted text and model context can contain confidential material, so apply purpose limitation, access control, retention limits and redaction while preserving enough to reconstruct an incident.

Prevention and Secure Architecture

1. 01
   Process representation-aware

   Know and document which representations - text layer, render, OCR, annotations, form values, attachments, metadata - each pipeline produces.

2. 02
   Minimize accepted surfaces

   Accept only the object classes the task needs instead of extracting everything a library can return.

3. 03
   Isolate parsing

   Sandbox parsers, renderers and OCR to contain traditional file-processing risk, and keep components patched and pinned.

4. 04
   Establish provenance

   Record submitter, channel, ownership, file hash, page and object identity without trusting claims made inside the file.

5. 05
   Preserve lineage

   Carry source, page, object class and access labels into every model-visible span, chunk, summary and cache entry.

6. 06
   Ingest permission-aware

   Apply repository and tenant authorization before content enters an index or a model context.

7. 07
   Minimize context

   Send only task-required PDF content and only the application data the task needs.

8. 08
   Separate proposal and execution

   Treat model output as an untrusted proposal and authorize every sensitive action deterministically.

9. 09
   Constrain capability and egress

   Use least privilege, task-scoped and short-lived credentials, destination policy and observable execution.

10. 10
    Bind approval to the action

    Where human approval is used, bind it to the exact immutable action and expire it if the proposal changes.

The Defense Hub places these controls in the site's broader model for provenance, information flow, least privilege, action control, monitoring and recovery.

Controlled Defensive Testing

Use synthetic PDFs, synthetic identities, test repositories and test tenants. Vary the PDF class - digitally generated, scanned, form-bearing, annotated, mixed - the extraction path, the library version, the object classes returned, the permission state and the available capabilities. Measure each stage separately.

The Document / PDF Prompt Injection lab practices the underlying trust decisions with fictional documents: storage, extraction and document labels versus provenance and application records.

Do not combine these into one score. High visibility with low influence is a different control outcome from high influence with zero policy bypass, and only the separation shows whether to improve extraction policy, detection, authorization or containment.

Incident Response

Common Misconceptions

Standards and Research Context

OWASP LLM01:2026 states that indirect prompt injection can arrive through external sources such as files, that such content need not be visible to a human as long as it is parsed by the model, and that multimodal systems add cross-modality risk. NIST AI 100-2e2025 describes indirect prompt injection as attacker control over a resource that a generative AI system consumes, and keeps that mechanism distinct from downstream impact.

Microsoft guidance counts documents among untrusted external content and recommends layered probabilistic and deterministic controls. Its Input, Context, and Retrieval Hygiene guidance states 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 PDF pages and to the summaries, caches and index entries derived from them.

For research context, CrackedPDFs is a controlled benchmark for hidden prompt injection in PDFs; its results describe that benchmark setup and should not be read as universal robustness or success claims for arbitrary products. It is cited here for one defensive lesson: flattening and extraction can destroy the evidence that content was never human-visible, which is exactly why investigations need the rendered view, the extracted representation and their difference. Research on AI-assisted peer review similarly documents that PDF-borne hidden prompts can affect LLM reviewers. Neither concealment methods nor optimization procedures are reproduced here. The PDF specification is used only for factual structure; it is not an AI-security standard and assigns no trust.

Frequently Asked Questions