A seven-step document-intake checklist
- Preserve the original and record its source and version.
- Define the intended AI task and what data or tools the system can access.
- Review visible content for unexpected instructions or changes in purpose.
- Inspect supported machine-readable, hidden, linked and active surfaces.
- Assess instruction-like text in context, not by keywords alone.
- Read findings together with coverage, failures and uninspected areas.
- Proceed within those boundaries or hold the document for human review.
This sequence reduces uncertainty; it does not certify trustworthiness. Each step narrows the question from "should this document enter the workflow?" to a specific, evidence-based answer. The steps are cumulative: a finding in step 5 is interpreted differently depending on what steps 1 and 2 established about provenance and destination risk.
What is a prompt-injection signal in a document?
Prompt injection exploits the combination of untrusted input with a prompt created by a higher-trust party. In an indirect prompt-injection attempt, instruction-like content reaches the system through an external resource rather than through the user's direct input; a third-party document is one possible resource. Its presence does not establish that a model followed it. The source material can be interpreted by an AI system as instructions rather than data.
Ordinary visible text can carry an injection; concealment is not required, as the OWASP guidance and OpenAI's explanation both make clear. Conversely, hidden or imperative text is not automatically malicious. Accessibility layers, document templates, quoted security research and legitimate workflow instructions can all create benign lookalikes that resemble suspicious patterns to a pattern-matching check.
For the broader trust-boundary explanation, see prompt injection in documents. For the detailed source-to-model mechanism, see indirect prompt injection in a document.
Before checking, record the source and destination
Preserve the original document unchanged. Note its source, receipt date and version using your normal file-management process. If provenance is unclear, consider whether a trusted alternate copy is available before proceeding.
Identify the intended AI task and the system's possible access to sensitive context, tools or consequential actions. OpenAI's source-to-sink framing helps explain why a text-only summariser with no external access has a different consequence boundary from an agent that can send messages, query databases or modify files. This distinction shapes how seriously a given signal should be treated.
Treat sensitive-information review as separate from prompt injection: either can exist without the other. A document may contain personal data without any instruction-like content, or it may contain an instruction without exposing sensitive information.
This is practical layered-defence guidance, not a universal compliance standard.
How to check a document for prompt-injection signals
The checklist above is the governing sequence. Its first two steps establish provenance and destination risk; the sections below expand the review, scanning, interpretation and decision work without creating a second numbered process.
Review what a person can see
Check headings, footnotes, appendices, tables, comments and any abrupt changes in voice or purpose. Look for text that appears addressed to an AI system rather than a human reader: requests to override the stated task, attempts to obtain information outside the document, or instructions to perform an unrelated action. A sentence in a supplier report's appendix that reads like a directive to a summarisation model is a signal worth noting, even if it is fully visible.
Visual review does not cover every machine-readable surface. A document can look ordinary on screen while its extractable content differs from the rendered view.
Compare visible and supported machine-readable content
An AI pipeline may receive extracted content that differs from what a person sees. Text layers, comments and document properties are categories of machine-readable content that a parser may expose. Copy-and-paste from a rendered view is not a complete extraction: it may omit content that a parser would include, or include content that a different parser would handle differently.
A comparison can reveal discrepancies between the rendered and extracted views. A match does not show that every possible document surface was inspected.
For format-specific detail on how visible and machine-readable content can diverge, see visible and machine-readable PDF content.
Review links, active features and unexpected structure
Where your chosen method supports it, inspect remote links, embedded or active features and structural inconsistencies. A remote link or an active feature is evidence to understand, not proof of injection. Legitimate documents contain links, form fields and interactive elements for ordinary purposes.
Keep malware detection outside the scope of a prompt-injection check. They are related but distinct security categories, and a prompt-injection signal does not establish the presence of malware or vice versa.
Interpret instruction-like content in context
Compare any instruction-like text with the document's purpose, its source and the user's intended task. Recognise benign categories: policy text, document templates, quoted attack patterns from security research, and legitimate workflow guidance. A security paper that quotes example prompts, a form template that says "complete the fields below," or a project brief with formatting rules can all resemble suspicious patterns without malicious intent.
Keyword lists can miss paraphrases and flag legitimate imperatives. Context, location, provenance and the presence of multiple signals all matter. For a recognition-first catalogue of patterns, see prompt-injection examples.
Use a supported scanner and inspect its evidence
A scanner can make selected checks repeatable and comparable across documents. It is bounded by format, parser, rules and configuration. Read the finding category, location and excerpt where available. Do not reduce the result to a red or green badge, and do not infer intent from a single finding. A scanner's output is a supported signal within its completed checks, not a verdict about the document's author or overall trustworthiness.
Check coverage and limits
Ask which pages, parts and surfaces completed. Parsing failures, unsupported content types, exhausted size limits and absent OCR are meaningful gaps. An incomplete check must not silently become a pass. If a required surface could not be inspected, the result reflects that limitation, and the handling decision should account for it.
Record the handling decision
If no supported reason to hold was found within the completed checks, proceed only for the stated use and retain downstream controls. If a signal or required-check failure exists, keep the document outside the intended workflow pending review, a trusted alternate version or rejection. Preserve the original and re-check any changed version. Use "proceed within stated limits" and "hold for review" rather than generic "safe" or "unsafe" labels.
Why prompt-injection detection has limits
Natural-language instructions are open-ended and contextual. Deterministic pattern and structure checks are reproducible triage controls, but they can miss paraphrases and flag benign imperative language, as the limitations in OWASP's guidance and Chen et al. illustrate. Detection results are conditional on the corpus, format, threshold and model used in evaluation. Strong results on one test set do not establish performance in another workflow.
The CrackedPDFs benchmark shows why a strong result still needs a scope label. Its hybrid method reported F1 0.960, ROC-AUC 0.998 and PR-AUC 0.997 on a held-out 2,919-file test set drawn from 29,322 generated one-page PDFs based on 4,983 documents: 9,774 injected and 19,548 benign or matched-confounder files. Those figures describe that synthetic PDF benchmark, not broad real-world robustness or .mdSiren accuracy.
Chen et al. evaluated two constructed 900-sample benchmarks derived respectively from SQuAD and TriviaQA. One tested out-of-domain detector configuration produced a 27.33% false-positive rate. That rate is specific to that corpus and configuration; it cannot be transferred to business PDFs, DOCX files or .mdSiren, and it is not a production prevalence estimate.
.mdSiren has no approved public false-positive or false-negative rate. Operationally, a flag means review, not maliciousness. No finding means only that no supported reason to hold was found within the checks that completed.
What should happen next?
| Situation | Interpretation | Next action |
|---|---|---|
| No supported signal; required checks completed | Nothing within completed supported checks required a hold | Proceed only for the stated use and retain normal controls |
| Suspicious signal found | Something needs contextual review; intent is unknown | Hold, inspect the cited evidence and source, then reject or obtain another version if necessary |
| Coverage incomplete | The check cannot support a complete handling decision | Hold, resolve the parser, format or limit issue, or use a trusted alternative process |
A signal and an incomplete check can lead to the same operational response—holding the document—for different reasons. In the first case, the concern is a possible instruction that needs contextual interpretation. In the second, the concern is that the check itself could not complete, so the absence of a finding is not meaningful. Both warrant a human decision before the document re-enters the workflow.
A document check is one defence layer
Treat external content as data, not as higher-priority instructions. Constrain the system's access to sensitive context, tools and external actions to what the specific task requires. Validate outputs and require human approval for consequential actions. Preserve provenance, monitor the workflow and re-check changed documents.
These layered controls are consistent with guidance from OWASP, Microsoft and the UK NCSC. No single layer, including a document check, is a complete guarantee.
The same intake sequence can be adapted to research papers before AI-assisted review and to CVs or resumes before AI-assisted screening, with the human decision process matched to each setting.
Where .mdSiren fits
For a repeatable intake check, .mdSiren follows Choose → Scan → Decide. Its current implementation supports PDF and DOCX up to 25 MiB and TXT and Markdown up to 5 MiB. Bounded deterministic checks cover supported instruction-like, hidden, sensitive, remote-link and active-feature patterns, and incomplete coverage.
It returns Ready or Held with findings, coverage, limits and a next action. Ready means required supported checks completed without a supported reason to hold. Held means a supported signal was found or a required check could not complete. Held is a review state, not quarantine or proof of malicious intent; neither state proves universal safety.
The original document remains unchanged. Scan-derived data is not sent to a cross-origin scanning service; the document is processed in your browser. The web host can still receive ordinary request metadata while serving the application. .mdSiren does not perform OCR, inspect image-only text, execute content or provide comprehensive malware detection.
.mdSiren is in development and coming soon.
See what .mdSiren scans · See how its Ready/Held results work
Frequently asked questions
Can a prompt-injection detector prove that a document is safe?
No. It can report supported signals and completed checks. It cannot establish universal safety, trusted intent or freedom from malware. A result is bounded by the formats, surfaces and limits it actually examined.
How can I detect prompt injection in a PDF or DOCX file?
Combine provenance review, visible content inspection, supported machine-readable and structural checks, contextual interpretation, coverage review and a documented handling decision. The format-specific anatomy of PDF surfaces is covered in visible and machine-readable PDF content.
Is hidden text always malicious?
No. Accessibility content, formatting, templates, quotations and research can produce non-obvious text for legitimate reasons. It is evidence to interpret in context, not a verdict.
What should I do if a document is flagged?
Hold it outside the intended AI workflow, review the cited evidence and source, then decide whether to reject it or obtain a trusted alternate version. A flag is a reason for review, not proof of wrongdoing.
Does a .mdSiren Ready result mean there is no prompt injection?
No. Ready means required supported checks completed without a supported reason to hold. It can include low-severity or informational observations and is not antivirus clearance or proof of universal safety.
