Metadata Stripping Prompt for File Uploads

This prompt is designed for document processing pipelines where files arrive from external users, third-party systems, or untrusted sources. Before any AI model reads the content, hidden metadata must be detected and stripped. EXIF geolocation data, author names from tracked changes, revision history, embedded thumbnails, and credential-like strings inside document properties all create data leakage risk. This prompt instructs the model to act as a metadata detection and stripping engine, producing a structured report of what was found and a sanitized version of the content ready for downstream AI processing.

Use this when your ingestion pipeline handles DOCX, PDF, XLSX, PPTX, or image files that may carry hidden data. It is best deployed as a secondary defense layer or when you must process files whose internal structure you cannot fully parse with code alone. The ideal user is a security engineer, platform architect, or document pipeline developer who needs a fast, auditable sanitization step before content reaches summarization, RAG indexing, or agentic workflows. The prompt expects a raw text extraction of the file content, not the binary file itself, and requires the model to reason about metadata patterns that deterministic parsers might miss.

Do not use this prompt as a substitute for deterministic file-parsing libraries when you control the file format. Libraries like python-docx, pdfplumber, or exiftool are faster, cheaper, and more reliable for known formats. This prompt is not a replacement for file-type validation, virus scanning, or content disarm and reconstruction (CDR) at the network boundary. It also cannot handle encrypted files, password-protected archives, or deeply nested OLE objects that require binary parsing. Use it when you need a human-readable audit trail of what was found and removed, or when you face unknown or inconsistent file structures that break your code-based parsers.

Before deploying this prompt, ensure your pipeline extracts text from files without stripping metadata first—otherwise the model has nothing to detect. Wire the prompt into a pre-processing stage that runs after file ingestion but before any content is stored, indexed, or passed to another model. Always log the structured detection report for audit purposes, and configure your harness to block files that contain high-severity findings such as geolocation coordinates, credential-like strings, or tracked changes with author names. For regulated environments, require human review of any file where the model flags potential PII or credentials before the sanitized content proceeds downstream.

This template is designed to be placed directly into your document processing pipeline, acting as a pre-flight check before any file content reaches a downstream model. Its job is to identify and neutralize hidden data—EXIF tags, author names, revision histories, embedded objects, and tracked changes—that could leak sensitive information or corrupt AI reasoning. Replace each square-bracket placeholder with your specific policy, file context, and output requirements before sending it to the model. The prompt is structured to produce a machine-readable JSON report, making it straightforward to integrate with automated validation and blocking logic in your application code.

textCopy
SYSTEM: You are a metadata security auditor. Your task is to analyze the provided file content and metadata for any hidden, sensitive, or non-public information. You must produce a structured report detailing all findings. Adhere strictly to the output schema. Do not output the file's primary content in your response.

USER:
Analyze the following file upload for hidden metadata and embedded objects.

[FILE_METADATA_AND_CONTEXT]

[FILE_CONTENT_EXCERPT]

Your analysis must follow this exact [OUTPUT_SCHEMA]:
{
  "file_identifier": "string",
  "findings": [
    {
      "type": "EXIF | AUTHOR_METADATA | REVISION_HISTORY | EMBEDDED_OBJECT | TRACKED_CHANGES | CREDENTIALS | GEOLOCATION | CUSTOM",
      "severity": "CRITICAL | HIGH | MEDIUM | LOW",
      "description": "string",
      "location_in_file": "string",
      "recommended_action": "REDACT | STRIP | QUARANTINE | REVIEW | ALLOW"
    }
  ],
  "safe_for_ai_ingestion": boolean,
  "summary": "string"
}

Apply these [CONSTRAINTS]:
- Flag any geolocation data (GPS coordinates, altitude) as CRITICAL.
- Flag any embedded credentials, API keys, or passwords as CRITICAL.
- Flag tracked changes and revision history that reveal author identities as HIGH.
- If no metadata is found, set safe_for_ai_ingestion to true and provide an empty findings array.
- Base your analysis only on the provided context; do not speculate about data not present.

To adapt this template, start by defining what your application considers a [FILE_METADATA_AND_CONTEXT] block. This should include the output of a metadata extraction tool like exiftool for images or python-docx for documents, rather than relying on the model to parse raw binary data. The [FILE_CONTENT_EXCERPT] should be a small, representative sample from the beginning and end of the file to catch embedded objects without sending the entire document. The [OUTPUT_SCHEMA] is your contract with downstream code; ensure your application validates that the model's response strictly conforms to this JSON structure before proceeding. For high-risk workflows involving legal or healthcare documents, always set a human review flag if safe_for_ai_ingestion is false or if any finding has a CRITICAL severity.

This prompt is designed to sit inside a file upload preprocessing stage, before any document content reaches the primary AI model or retrieval index. The harness should intercept uploaded files, extract text and metadata programmatically using libraries like exiftool, pdfinfo, or Apache Tika, and then pass the extracted metadata summary into the prompt alongside the raw text. The model never sees the original binary file; it only receives a structured representation of what was found. This architecture prevents the model from accidentally echoing hidden data that the extraction layer missed, and it keeps the stripping logic auditable.

Wire the prompt into a pipeline with three stages: extract, detect, and strip. In the extract stage, use deterministic tools to pull all metadata fields, embedded objects, revision history, and hidden text layers. In the detect stage, send the extracted metadata inventory to the LLM with this prompt to classify risky fields and generate a stripping plan. In the strip stage, apply the plan programmatically—redact EXIF GPS coordinates, remove author names, delete tracked changes, and scrub embedded credentials. Do not rely on the LLM to perform the actual redaction on raw file bytes; use it only for classification and instruction generation. Log every detection decision with the field name, risk classification, and action taken for audit trails.

For validation, build a test harness that uploads files with known risky metadata: a JPEG with GPS coordinates, a DOCX with tracked changes and author names, a PDF with embedded credentials in annotations. After the pipeline runs, verify that the output file contains none of these artifacts. Use exiftool -j on images to confirm GPS fields are stripped, python-docx to check that revision history is removed, and a regex scan for credential patterns in the final text. If the LLM fails to flag a known risky field, log the miss and route the file to a human review queue. Set a confidence threshold: if the model's risk score for any field is below 0.9, escalate. For high-sensitivity environments, require human approval on every file before it enters the AI ingestion path.

Choose a fast, cost-effective model for this task since it runs on every upload. GPT-4o-mini, Claude Haiku, or a fine-tuned small model works well because the classification task is narrow and the output schema is strict. Implement retries with exponential backoff if the model returns malformed JSON or misses required fields in the output schema. Cache stripping plans by file hash to avoid re-processing identical files. Monitor for drift: if the model starts missing known metadata types or over-flagging benign fields, re-evaluate against your golden test set and update the prompt's few-shot examples. Never let a file proceed to downstream AI processing until the stripping stage confirms zero risky fields remain.