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.
| Harmless fixture condition | Gate decision | Evidence expected |
|---|---|---|
| Small permitted note, correct owner | Admit to constrained preprocessing | Object reference, tenant scope, format decision |
| Filename says PDF; fixture metadata disagrees | Hold or reject before release | Stable type-mismatch reason |
| Declared extracted output exceeds the example limit | Stop processing; no index write | Resource-limit outcome and cleanup status |
| Document contains an external image link | Do not fetch it in the parser | No outbound request in the recording adapter |
| Required scanner reports unavailable | Keep object held | Pending check, no released chunks |
| Uploader loses access while the job waits | Reauthorize before release | Current 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.