The direct answer

Treat an uploaded document as untrusted bytes before treating its extracted text as model context. Admit only the formats and sizes your workflow needs, preprocess with a constrained identity and bounded resources, and release the result only after required checks and authorization succeed. Successful parsing does not make the document’s instructions trusted.

Separate receipt, processing, and release

A document can be received successfully while remaining unsuitable for a search index or model request. Give those states different meanings. A useful pipeline might mark an object received, quarantined, processing, checked, and released; a failure leaves it rejected or held. A browser upload success message must not imply that every later security check passed.

OWASP’s File Upload Cheat Sheet recommends layered checks, limited file types and sizes, generated storage names, and controlled storage and access. Client-supplied MIME types and signatures are useful signals, not standalone proof of safety. The worksheet below turns those principles into an original small-workflow design.

An original admission worksheet for a synthetic knowledge tool

Imagine a fictional team tool that accepts plain UTF-8 notes and PDFs for an internal question-answering feature. Its example limits are two MiB uploaded, fifty PDF pages, and one MiB of extracted text per document. These invented limits are discussion inputs, not tested defaults, capacity measurements, or protection guarantees. Choose real limits from your workload and infrastructure.

Proposed ingestion gates; no parser or attack test performed
Harmless fixture conditionGate decisionEvidence expected
Small permitted note, correct ownerAdmit to constrained preprocessingObject reference, tenant scope, format decision
Filename says PDF; fixture metadata disagreesHold or reject before releaseStable type-mismatch reason
Declared extracted output exceeds the example limitStop processing; no index writeResource-limit outcome and cleanup status
Document contains an external image linkDo not fetch it in the parserNo outbound request in the recording adapter
Required scanner reports unavailableKeep object heldPending check, no released chunks
Uploader loses access while the job waitsReauthorize before releaseCurrent permission decision, no model dispatch

The rows describe metadata and stub behavior. They do not require a malicious file, a decompression bomb, a live remote endpoint, or a production parser to explain the expected boundary.

Constrain the parser before asking it to inspect content

Use a dedicated processing identity without model-provider keys, application-admin credentials, or unnecessary access to other documents. Give each job its own temporary workspace and permit only the reads and writes it needs. Disable active document features and external resource loading where the selected processor supports that configuration. Do not run uploaded macros or scripts as part of extraction.

Bound elapsed processing time, memory, temporary storage, output bytes, page count, and any permitted archive expansion. Reject archives entirely when they are not needed. A small uploaded object can still cause much larger processing output; the upload-byte ceiling alone does not bound that work.

Keep the processor version and configuration in the job evidence. A conversion or content-disarm step introduces another component handling untrusted input. An antivirus result, format rewrite, or sandbox boundary reduces particular risks; none certifies that arbitrary content is safe. Review data-transfer permissions before sending a sensitive file to any external scanning service.

Make URL import a separate controlled operation

“Upload a document” and “fetch this document URL” grant different network capabilities. Prefer an approved connector or a server-side source identifier over an arbitrary user-supplied URL. The parser should not independently follow hyperlinks, load remote images, or resolve external references found inside a document.

OWASP’s SSRF guidance discusses destination allowlists, redirects, parser ambiguity, DNS behavior, and network restrictions. If remote importing is required, use a separate fetcher whose destination and network policy are explicit. Constrain scheme, host, port, and intended resource; do not rely on a raw string prefix. Disable automatic redirect following or evaluate every permitted hop under the same policy.

Validate the actual connection destination under your supported stack and keep private or infrastructure-only destinations outside the importer’s reach. This is an architectural requirement, not a ready-made URL validator or a report that this article tested a bypass.

Preserve ownership when bytes become chunks

Assign an application-generated object identifier and retain the upload owner, authorized tenant, source revision, and processing revision in protected metadata. A content digest can identify the processed bytes; it does not establish who supplied them, whether they are harmless, or who may read them. Do not deduplicate protected documents across tenants in a way that exposes another customer’s existence or contents.

OWASP’s RAG guidance calls for permissions to follow chunks and be checked at retrieval, and for ingestion dependencies to be tracked. Carry those restrictions into extracted text, embeddings, cached answers, and result artifacts. Do not publish a raw storage URL as an access-control substitute.

Authorize release and later retrieval using current application rules. Define how revocation, deletion, failed jobs, and retention affect each derived store. Avoid copying entire documents into routine logs; use minimized references and protected evidence only when necessary.

Keep extracted instructions on the data side

A perfectly readable PDF may contain instructions addressed to an assistant. Parsing, scanning, and indexing do not turn those sentences into authority to send messages, reveal credentials, or change policy. Preserve provenance when constructing context and enforce tool permissions separately. The retrieved-document injection guide covers that later boundary.

At admission time, verify that a held or rejected document cannot reach the embedding adapter, model adapter, or ordinary search results. If a required check is unavailable, report a held status rather than silently releasing an unchecked copy. Explain the permitted recovery path without exposing internal document data.

Review the gates without dangerous fixtures

Start with fabricated identities, short notes, fake result metadata, and recording adapters. Walk each worksheet row through the proposed state machine. Assert that rejected jobs produce no index or model dispatch and that accepted ordinary notes remain useful. Separately review real processor isolation and resource enforcement in an authorized environment; a stub cannot prove those controls.

This article has not processed malicious files, scanned a service, called a model, or measured parser resilience. Boundary is a prelaunch commercial model router with planned request-path checks; it is not an implemented document-upload scanner, parser sandbox, or ingestion authorization engine.

Primary sources

Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.

  1. OWASP File Upload Cheat Sheet
  2. OWASP Server-Side Request Forgery Prevention Cheat Sheet
  3. OWASP RAG Security Cheat Sheet