Can a PDF contain prompt injection that a reader cannot see?
Yes. Content available to a PDF parser or extraction pipeline may not be obvious in the ordinary rendered view. A PDF page is not a simple image; it is a collection of drawing and text instructions that different software interprets in different ways. Text can remain extractable even when the current render settings do not paint it visibly, and structural elements can exist without a visible counterpart on the page.
When a model treats untrusted document content as instructions rather than data, the result is an instance of indirect prompt injection. The NIST glossary defines this as an attack executed through control of a resource rather than the user's direct input. A third-party PDF is one possible resource; not every document containing instruction-like text is malicious.
Plain visible text can also carry an instruction. Concealment is not required for prompt injection in documents. A sentence in a report's appendix that reads like a directive to a summarisation model is visible to a human reader, but a model processing the document as data may treat it differently. The OWASP guidance and OpenAI's explanation both make this clear.
The presence of instruction-like or non-visible content is a supported signal that warrants review. It does not, by itself, establish that the document is malicious or that an attack will succeed.
The visible page and the machine-readable PDF are different views
What a person normally sees
When you open a PDF in a reader, you see rendered pixels: text, images, shapes and layout as the viewer's rendering engine interprets the file's drawing instructions. This is the human-facing presentation. It is useful for reading and comprehension, but it is not a complete inventory of the file's content. A viewer's display settings, zoom level and layer visibility all affect what appears on screen.
What an AI workflow may receive
An AI workflow may receive extracted text, rendered page images or a mixture, depending on the tool and configuration. In an extraction-based workflow, a parser may supply text and supported document structures that differ from the rendered view. The exact surfaces extracted, and the order in which they appear, vary by tool and configuration. A parser may include text objects that the viewer does not paint, metadata fields, optional content layers or structural elements that have no visible counterpart on the rendered page.
This means the content a model processes can differ from what a person sees on screen. The PDF Mirage study documented differences between content as rendered and as processed by PDF systems, and the CrackedPDFs benchmark makes the prompt-injection implication explicit: document-aware features can retain evidence that a text-only representation discards.
Why a mismatch is not automatically an attack
Document production, accessibility and layout can produce non-obvious content for entirely benign reasons. White text, clipping, optional layers, metadata and other structural features can all have legitimate uses. The security relevance of a mismatch depends on the content itself, the document's provenance, the intended task and the downstream system's capability. A structural anomaly is evidence for review, not proof of malice.
How PDF-borne prompt injection can reach an AI workflow
Source → extraction → model context
Consider a restrained example. You receive a PDF report from an external contact and ask an AI assistant to summarise it. The assistant's pipeline extracts text from the PDF and places it in the model's context alongside your summarisation instruction. If the extracted text contains a passage that reads like an instruction to the model, the model may interpret it as a directive rather than as evidence to summarise. The Microsoft Security Response Center describes this source-to-model mechanism in the context of layered defence.
Whether the passage matters depends first on extraction and then on model behaviour. If the parser omits it, it never reaches the model; if the model disregards it, no influence follows. Even a changed response says nothing by itself about an external action or harm.
Risk changes with downstream capability
Impact is set by the receiving application's reach. The same PDF might only distort a stand-alone summary in one workflow but could steer a tool-enabled process in another. OpenAI's agent-design guidance therefore puts weight on limiting which private data and actions are reachable, not only on classifying the PDF.
Occurrence, effect and outcome
| Stage | Question | What would count as evidence? |
|---|---|---|
| Occurrence | Is relevant instruction-like or concealed content present? | Extracted excerpt, location, signal and coverage |
| Effect | Did it influence this model or pipeline? | Controlled comparison or reproducible output change |
| Outcome | Did that influence lead to harm or an external action? | Auditable decision, disclosure or tool action |
A finding may support the first statement. It does not, by itself, establish the second or third. Keeping these three claims separate prevents a single signal from being inflated into a verdict about intent or harm.
What the CrackedPDFs study found
Corpus and task
The CrackedPDFs preprint generated 29,322 one-page PDFs from 4,983 base documents, comprising 9,774 injected and 19,548 benign or matched-confounder files. The reported held-out test set contained 2,919 files. This is a generated, synthetic benchmark; it does not represent web prevalence or a sample of real-world PDFs.
Reported benchmark performance
On the 2,919-file held-out test set, the CrackedPDFs paper reports that its defined hybrid method achieved F1 0.960, ROC-AUC 0.998 and PR-AUC 0.997. On a balanced 1,946-file subset, it achieved 95.9% thresholded classification accuracy and 100% within-pair score ordering across 973 injected/confounder pairs. The ordering result means the injected member received a higher score within every matched pair; it does not mean every file was classified correctly. These figures are specific to the generated one-page benchmark, the named method and the stated test conditions. They are not .mdSiren results, do not cover every PDF construction, and do not justify a universal safety verdict.
What those figures do not establish
The limitation is as important as the scores. This was a generated, one-page benchmark. The authors do not establish broad real-world robustness or generalisation across PDF families, generators, languages or attack types. The figures do not measure .mdSiren's accuracy, do not represent field performance, and do not support a claim that any detector can certify a PDF as free of prompt injection. No benchmark on a synthetic corpus can substitute for evidence across the full diversity of documents encountered in practice.
The wider review of prompt-injection statistics compares these PDF results with other detector studies without treating their scores as interchangeable.
How to check a PDF before using it with AI
The following format-specific workflow is an operational synthesis of NIST guidance, OWASP, NCSC, Microsoft and OpenAI. It complements the general procedure to check a document before using it with AI; it is not a universal standard.
- Confirm the source, expected content and intended AI task.
- Examine relevant machine-readable and structural surfaces with a supported method, not visual review alone.
- Review excerpts, locations, coverage and limits rather than relying on a binary label.
- Hold ambiguous or high-consequence documents for human review.
- Restrict data access, tools and external actions when proceeding.
- Inspect the AI output and require approval before consequential action.
A supported scan can make selected checks repeatable and comparable across documents. Read the finding category, location and coverage. Do not reduce the result to a single label, and do not infer intent from a single finding. Incomplete coverage is itself a reason to hold: an absence of findings has meaning only within the checks that actually completed.
Does flattening or converting a PDF remove the risk?
Conversion can reduce some selectable, structural and active surfaces, depending on the method. Rasterising a PDF can remove selectable text and many active structures, but it preserves visible instructions as pixels and can reduce accessibility. A vision model or OCR-capable system can still read visible text in the resulting image. Changing a crop box or drawing over content is not the same as properly removing or redacting it: the underlying data may remain recoverable by a parser. Adobe's redaction guidance distinguishes visual covering from removal. Verify the saved output rather than judging by appearance alone.
Flattening or rasterisation is not a substitute for understanding the source, the task and the downstream permissions. It does not remove instructions that are already visible in the rendered page, and it is not a universal sanitiser.
Where .mdSiren fits
.mdSiren · Available now
.mdSiren is a document security checkpoint for AI systems. Standard Scan checks the exact document version for supported prompt-injection and document-borne risks before AI use, then routes it to Approved, Needs review or Quarantine.
The private Library makes only current eligible Approved versions available with their scan records, ready for retrieval into your AI workflow. Every result remains limited to the checks and coverage reported for that version; it does not establish that every document surface is clear.
See how it works · Checks and coverage · Coming soon
The practical decision
Treat the visible page as one view, not the only view. Inspect what the intended pipeline will actually process. Scale your review and permissions to the consequence of being wrong: a document summarised in isolation with no tools carries less risk than the same document processed by an agent with access to private data and external actions.
A signal is a reason to review, not a verdict. A mismatch between the rendered page and the extracted content is evidence to investigate, not proof of intent. The proportionate response is to understand the content, the source, the task and the downstream capability, then make a clear handling decision.
