Isolate document parsing before RAG ingestion

Separate three boundaries before retrieval

Put untrusted documents into quarantine, parse them in a worker with narrowly limited authority, and admit the extracted result through a separate service before embedding or indexing it. The parser should not inherit the credentials and network access of the indexer merely because both belong to the same ingestion pipeline. A file that produces readable text has completed a transformation; it has not earned trust.

Three problems need separate controls. A file can exploit a parser or one of its dependencies. It can consume excessive resources without exploiting a vulnerability. It can also contain instructions that later influence a retrieval-augmented model. Upload validation, execution containment and content-admission policy address different parts of this problem. None should be used as a blanket substitute for the others.

OWASP's upload guidance treats malicious files, resource limits and storage controls as a defense-in-depth concern. Its RAG guidance extends the problem into provenance, access control and the downstream use of retrieved content. ^{[1] [7]} The architectural implication is to keep the authority to interpret bytes separate from the authority to publish knowledge into the retrieval system.

Consider a hypothetical invoice assistant. An upload service accepts a document, a parser extracts text, and an indexer stores chunks for later questions. If all three steps run with one service identity, a parser failure may gain access to the index, object store or embedding endpoint. Even without compromise, a parser that follows document references could reach network destinations the upload workflow never intended to authorize.

The proposed boundary gives the parser one input, a bounded workspace and a constrained output channel. Another component owns the credentials needed to call the embedder and update the index. That component checks source identity, output limits and completion status before admitting a result. The separation reduces unnecessary authority; it is not a claim that the remaining sandbox can never be escaped.

Retrieval permissions remain a later requirement. An isolated parser can extract a confidential document correctly, and an indexer can still attach the wrong audience or expose its chunks to another tenant. Source identity and access metadata must travel through a trusted control path. Do not ask the document's own text to declare who is allowed to read it.

Begin the review by asking what the parser could do if every byte it emitted or every operation it attempted were hostile. Which files could it read, which credentials could it obtain, which services could it reach, and which records could it change? This counterfactual reveals unnecessary authority more quickly than a list of enabled file extensions.

Reduce the input contract

Support only the formats the application actually needs. Every additional decoder, archive handler or OCR path expands the set of code that interprets untrusted material. The goal is not to claim that one approved format is safe; it is to make the supported input contract small enough to maintain, constrain and test.

Use extension, declared content type and file-signature checks as complementary signals rather than trusting any one of them. OWASP cautions that upload handling requires layered validation and appropriate limits. ^[1] A renamed file or a plausible content type should not select an unexpected parser path. If the signals disagree, apply an explicit rejection or quarantine policy rather than guessing silently.

Define limits at more than the upload boundary. Compressed bytes, expanded bytes, nested objects, pages, extracted characters, processing time and temporary storage can impose different costs. A small compressed input may trigger much larger expansion. The exact thresholds should come from the accepted workload and capacity, not from a universal number copied into a guide. Document what happens when each limit is reached.

Keep the failure semantics consistent with the document's purpose. Truncating a public manual may be tolerable if the application clearly labels the partial result. Truncating a contract while presenting its answer as complete may not be. A parser limit should produce a machine-readable completion state so the admission service can decide whether partial output is permitted for that workflow.

External scanners and conversion services are separate data destinations. Do not upload sensitive documents to a public service simply because it offers a convenient safety check. Establish authorization, retention and recipient controls for that path. A security inspection can itself create an unintended disclosure if the input leaves its approved boundary.

Track the actual parser dependencies and enabled features. Apache Tika maintains a security advisory index for its own releases and affected functionality. ^[3] Use it as part of an update process, alongside the dependencies and optional tools present in the deployed image. This article does not name a universal fixed version because the appropriate action depends on the installed components and current advisories.

A useful acceptance record states which input families are supported, which are rejected, which require a separate path, and which limits are enforced by which component. It should distinguish a front-door check from a runtime limit. If the upload service rejects large files but the parser can create unlimited output, the input contract is still incomplete.

Remove the parser's unnecessary authority

Process separation is a necessary distinction, but it is not the entire security boundary. Apache Tika's robustness guidance warns about infinite loops and unexpected memory consumption and advises against parsing untrusted files in the same JVM as critical indexing code. It notes that Tika 2.x server parsing uses a forked process by default and that clients must handle restarts. ^[2]

A fork can help the parent survive certain failures while leaving the child's filesystem, credentials and network authority largely unchanged. Therefore review the child process's effective permissions, not merely the fact that it is separate. A parser running in another container with the same broad service identity may still be able to modify the index or read unrelated documents.

The recommended worker receives a single authorized input reference or read-only input artifact, a job-specific temporary workspace and a narrow result channel. Avoid mounting the whole ingestion bucket, repository or shared working directory when one document is enough. Do not provide index-write, embedding-service or broad cloud credentials to a component whose job is only to extract content.

Treat network access as opt-in. If parsing does not require external retrieval, remove direct egress. If a legitimate feature needs referenced content, use a controlled fetch path that validates destinations and returns bounded data. OWASP's SSRF guidance distinguishes application and network controls, including destination validation and redirect handling. ^[6] The parser should not independently turn arbitrary document links into requests to internal services or metadata endpoints.

A fetch broker also needs a narrow contract. It should know which job requested the object, which destinations and schemes are allowed, and which size and redirect limits apply. It must not become a generic proxy that accepts whatever URL the parser supplies. This is an original architecture recommendation, not a claim that naming a service broker automatically prevents SSRF.

Constrain output paths as carefully as input paths. The worker can emit data into a designated result location, but it should not choose an arbitrary index name, source identifier or destination bucket. A trusted controller should associate the output with the job and original source. Otherwise a compromised parser can attempt to overwrite another document's result or introduce records under another tenant's identity.

gVisor's security model explains that a sandbox limits particular host-facing attack surfaces but is not a substitute for secure architecture. Applications can still use files and network access deliberately granted to them. ^[4] That makes permission reduction valuable even when a stronger runtime boundary is available. Do not assume the sandbox will reinterpret an allowed data transfer as inappropriate for the business workflow.

The before-and-after comparison is conceptual. It contrasts a parser sharing index authority with a worker whose extracted content must pass admission before a separate service reaches the embedder or index. No throughput or incident reduction is asserted. The reader should be able to name the precise removed permissions and the remaining trusted components before considering the design complete.

Source. Original architecture informed by Apache Tika robustness guidance, gVisor's security model and OWASP SSRF guidance. ^{[2] [4] [6]}

Method. Conceptual comparison, not an executed deployment or measured security improvement. Process separation alone does not establish a sandbox or remove credentials.

Accessible table and figure data

Figure 1 accessible table

Boundary	Combined design	Proposed separated design
Credentials	Parser inherits index and embedding access	Parser has only bounded input and result access
Workspace	Shared ingestion files	Job-specific constrained workspace
Network	Direct broad egress	No direct egress or a restricted fetch broker
Output	Parser writes to index	Admission service validates before publishing
Failure	Crash or partial text can affect index path	Explicit attempt status and quarantine

Figure 1 accessible table

Boundary	Combined design	Proposed separated design
Credentials	Parser inherits index and embedding access	Parser has only bounded input and result access
Workspace	Shared ingestion files	Job-specific constrained workspace
Network	Direct broad egress	No direct egress or a restricted fetch broker
Output	Parser writes to index	Admission service validates before publishing
Failure	Crash or partial text can affect index path	Explicit attempt status and quarantine

Download imageDownload table CSV

Choose and test containment

Choose containment according to the threat and the operational requirements. A restricted container, a sandboxed runtime and a virtual-machine boundary expose different host interfaces and have different compatibility and management costs. There is no defensible universal risk score that ranks them without the deployment context. The relevant question is which attack surfaces and permissions remain in the selected configuration.

Kubernetes' Restricted Pod Security profile constrains privileges through requirements such as non-root execution, prevention of privilege escalation, restricted capabilities and seccomp settings, with documented operating-system and version conditions. ^[5] It is a useful control set, not a complete tenant-isolation or egress policy. Verify the policy version and effective workload settings instead of assuming that a namespace label supplies every needed restriction.

A sandbox also needs resource enforcement around it. gVisor's documentation describes reliance on host mechanisms for resource-exhaustion controls and separate network-policy enforcement. ^[4] Review memory, CPU, process count, temporary storage and concurrency budgets at the layer that actually enforces them. A parser that cannot escape can still consume enough permitted resources to disrupt neighboring work.

The following tests are proposed, not executed for this article. Use harmless fixtures and a non-production authorized environment to exercise timeouts, bounded output and denied access. A synthetic worker that sleeps beyond its deadline can verify termination behavior without needing a malicious document. A fixture that emits excessive text can check the output limit and admission rejection path.

Test permission denial directly. Confirm that the worker cannot read an unrelated job's input, write outside its designated result location, obtain the index credential or reach a controlled destination that should be blocked. Use safe test endpoints and fabricated data. Record the observed control and configuration rather than making a broad claim that all possible filesystem or network paths were tested.

Exercise the controller as well as the worker. When parsing times out, does the controller stop accepting output from that attempt? When a replacement worker starts, can an older attempt overwrite its result? When the sandbox exits, is the workspace cleaned according to the retention policy? These lifecycle questions can defeat the intended boundary even when the container configuration looks restrictive.

Keep availability evidence separate from security evidence. A parent process surviving a parser crash demonstrates a useful robustness property. It does not demonstrate that the child lacked access to sensitive mounts before crashing. A rejected network request demonstrates the tested egress restriction, not immunity to every kernel vulnerability. Scope the acceptance report to what each observation actually establishes.

Admit extracted content separately

The admission service should receive a result tied to a known input and parsing attempt. Its receipt can identify the source version, input digest, parser build, enabled feature profile, completion state and output location. These are recommended control fields, not a product-specific API. Their purpose is to keep the transformation traceable without trusting the parser to redefine the document's owner or audience.

Validate the result before giving it downstream authority. Check the expected format, output bounds, source association and whether the attempt completed under the workflow's policy. A timeout followed by a partial text file should not look identical to successful extraction. If partial results are accepted, preserve that status through indexing and presentation so that later consumers do not infer completeness.

Extracted URLs and instructions remain untrusted content. Parsing a document into plain text does not authorize a downstream agent to follow its links, execute its commands or treat its assertions as system policy. OWASP's RAG guidance addresses the continuing risk of untrusted retrieved material. ^[7] Preserve the distinction between document content and the application's control instructions after the format conversion.

Pass access metadata through trusted application state. A source's tenant, permitted readers and document version should come from the authorized ingestion request or authoritative source system, not from a sentence or embedded property inside the upload. If the document includes a field that resembles an access tag, it is still document content until a defined policy says otherwise.

The sequence figure shows an uploader creating a quarantined input, an isolated worker extracting a bounded result, and an admission service either rejecting the result or passing approved content to the embedder and indexer. The embedder's credentials appear only after admission. This ordering is intentional: a parser should not be able to publish arbitrary extracted data simply by completing its own process.

Use a hypothetical duplicate-upload case to test identity handling. Two users submit identical bytes under different authorized scopes. Content deduplication may recognize the same input digest, but that does not justify merging their access policies. Reusing a parse artifact can be a legitimate optimization only if the trusted admission path still associates each resulting record with its correct source and audience.

Keep extraction quality and security state separate. A parser can complete within limits while producing garbled text, and a semantically accurate extraction can still contain hostile instructions. Quality checks can flag unusable content without claiming semantic safety. The result record should let later systems distinguish incomplete, low-quality, quarantined and admitted content according to the application's needs.

Finally, preserve the link from indexed chunk to source version and parse receipt. That enables a later parser advisory, source withdrawal or access-policy change to identify affected records. Without this lineage, the organization may know that a parser was vulnerable but not which derived knowledge needs to be rebuilt or removed.

Source. Original process synthesis informed by OWASP file-upload and RAG-security guidance. ^{[1] [7]}

Method. Conceptual sequence. The parser cannot assign its own access audience. A successful extraction is not proof that its instructions or claims are trustworthy.

Accessible table and figure data

Figure 2 accessible table

Stage	Trusted record	Decision
Upload	Authenticated source and scope	Accept supported bounded input
Quarantine	Input identity and source version	Dispatch constrained parse job
Parse	Attempt identity and completion state	Emit bounded result without index credentials
Admission	Output checks and trusted access metadata	Reject, quarantine or admit
Publish	Chunk lineage and parse receipt	Embed and index only admitted content

Figure 2 accessible table

Stage	Trusted record	Decision
Upload	Authenticated source and scope	Accept supported bounded input
Quarantine	Input identity and source version	Dispatch constrained parse job
Parse	Attempt identity and completion state	Emit bounded result without index credentials
Admission	Output checks and trusted access metadata	Reject, quarantine or admit
Publish	Chunk lineage and parse receipt	Embed and index only admitted content

Download imageDownload table CSV

Operate failures and updates

Repeatedly retrying a poison file can turn an isolated failure into a sustained queue problem. Classify outcomes such as unsupported format, exceeded limit, worker crash, temporary dependency failure and rejected output. Give each a bounded retry or quarantine policy. A parser restart may restore service health without making the same input suitable for another unlimited attempt.

Tika's guidance explicitly expects clients to handle server unavailability when forked parsing processes restart. ^[2] Apply that operational lesson to the surrounding queue: preserve the job identity, record the failed attempt and prevent stale output from being admitted later. A retry should not silently change the parser's permissions or disable limits to get the document through.

Maintain an inventory that connects parser builds and optional dependencies to admitted outputs. Review Apache Tika's advisories and the corresponding sources for OCR, archive and format-specific components in use. ^[3] When an update changes extraction behavior, evaluate both security fixes and downstream quality. A safer decoder that produces different chunk boundaries can require reindexing or adjusted retrieval tests.

Reassess the boundary when adding a new input format, enabling OCR, allowing external references or changing the sandbox runtime. Each can introduce new work, files or network paths. A previously valid policy should not automatically cover the expanded feature. Keep unsupported features disabled until their required authority and limits are understood.

Protect quarantine and diagnostic artifacts themselves. A rejected document may still be sensitive, and a crash report can include extracted fragments or paths. Define who can inspect them and how long they are retained. Sharing a triggering file with a maintainer or external service needs the same data-owner authorization as another export.

The parser owner should be able to produce one coherent receipt: what input was accepted, which constrained worker handled it, what output was produced, which admission checks passed and where the derived records went. The security claim remains bounded. Isolation limits what parsing can reach; admission controls what its output may become; retrieval authorization controls who may later use it. All three are needed for a defensible ingestion path.