Inspiration
AI systems are increasingly asked to read contracts, invoices, onboarding packets, and reports. A PDF may look harmless to a person while its hidden text layer contains prompt injections, sensitive data, suspicious links, embedded files, or active actions. Sending that document directly into an agent creates a trust-boundary failure: the agent may treat attacker-controlled document text as instructions.
We built PaperShield to answer a practical question: what should happen before an untrusted document is allowed into an AI workflow?
What it does
PaperShield is a five-stage review and sanitization workflow:
- Upload: validates the PDF, records its SHA-256 hash, and keeps the original as evidence.
- Inspect: uses Nutrient DWS spatial extraction together with local rendering and static PDF inspection.
- Review: presents every finding with severity, location, and masked evidence. A reviewer must choose Redact, Keep, or Escalate and provide a reason.
- Sanitize: permanently removes approved regions. Sanitization remains locked while any finding is pending.
- Report: re-extracts and rescans the result, compares the original and sanitized files, and exports a JSON and Markdown audit record.
PaperShield detects more than visible PII. Its deterministic checks cover prompt-injection patterns, credential and personal-data formats, rendered-versus-text-layer discrepancies, suspicious links, JavaScript, launch actions, metadata, and embedded files.
The risk score is explainable rather than opaque:
$$ \text{Risk}=100(0.40I+0.25S+0.20H+0.15A) $$
where (I) is prompt-injection risk, (S) is sensitive-data risk, (H) is hidden-content risk, and (A) is active-content risk. A confirmed critical injection or active-content finding forces a minimum score of 80.
How we built it
The interface is built in Streamlit. Nutrient DWS is the document-understanding layer: PaperShield calls POST /extraction/parse in structure mode and normalizes the returned text, page data, confidence, reading order, and bounding boxes.
The security pipeline then combines:
- deterministic prompt-injection rules;
- sensitive-data detectors with validation such as Luhn checking for payment cards;
- PyMuPDF rendering and text extraction;
- visual-versus-digital text comparison for hidden content;
- pikepdf checks for active or suspicious PDF structures; and
- a weighted, severity-aware risk engine.
Approved findings become coordinate-based redaction regions. PaperShield attempts Nutrient Processor /build for permanent redaction. When the current development credential lacks that entitlement, the application clearly labels and uses a local PyMuPDF fallback rather than pretending the API call succeeded.
Finally, the verification stage re-extracts the sanitized file, checks that redacted evidence is absent, confirms the page count is preserved, and verifies that the output hash differs from the original. The audit record stores timestamps, hashes, detector versions, masked evidence, reviewer decisions, reasons, provider mode, and verification results.
Challenges we faced
PDF coordinates are surprisingly easy to get wrong. Nutrient extraction returns top-left render-space bounds, while PDF redaction uses a bottom-left coordinate system. We had to normalize page numbers and convert coordinates so that a finding and its permanent redaction refer to the same physical region.
The second challenge was proving removal rather than merely drawing black boxes. PaperShield therefore treats redaction as a transformation that must be followed by re-extraction, rescanning, hash comparison, and page-count validation.
The third challenge was incomplete API entitlement. Live DWS extraction succeeds, while the current key cannot access Processor /build. We added a clearly named local fallback so the workflow remains demonstrable without obscuring which provider performed each operation.
What we learned
Document safety is not one classifier call. It is a pipeline with provenance, deterministic checks, a human decision at the irreversible step, and evidence that the output changed as intended. We also learned that the human review experience matters as much as detection accuracy: a trustworthy system must explain what it found, where it found it, and why an operator chose to keep, redact, or escalate it.
Accomplishments we are proud of
- A complete upload-to-audit workflow rather than a static risk dashboard.
- Live Nutrient spatial extraction as a core dependency.
- Detection of content that is invisible to the human reader but present in the PDF text layer.
- A mandatory, reasoned human review gate before sanitization.
- Permanent redaction followed by an independent verification pass.
- Reproducible JSON and Markdown audit records with masked evidence and cryptographic hashes.
- A deterministic pipeline that does not require an LLM to make irreversible security decisions.
What's next
Next, we would enable full Nutrient Processor API access for live DWS redaction, embed the DWS Viewer for in-document human approval, add organization-level policy packs, sign cleared documents, and expose PaperShield as a pre-ingestion API for RAG pipelines and autonomous agents.
PaperShield does not certify that a document is legally compliant or universally safe. It creates a reviewable, reproducible control point before a document enters a higher-risk AI system.
Log in or sign up for Devpost to join the conversation.