Securing RAG Against Poisoned Documents: A Practical Architecture for Governed Knowledge Bases

Retrieval-augmented generation makes enterprise AI more useful by grounding answers in organizational documents. It also creates a new trust problem: the model receives instructions and facts from content that may be outdated, unauthorized, manipulated, or actively malicious.

A secure RAG design cannot assume that a document is safe because it came from an internal repository. The OWASP RAG Security Cheat Sheet identifies risks across ingestion, embeddings, vector storage, retrieval, generation, and agent tools. The useful lesson is architectural: security controls must follow the document through the entire pipeline.

The document is data, not an instruction

A human reader can usually distinguish policy text from an instruction directed at a language model. A model may not. A document can contain visible or hidden text such as “ignore the system prompt,” “reveal confidential context,” or “invoke this tool.” If that text is retrieved into the context window, it can influence the answer or an automated action.

That is indirect prompt injection. The attacker does not need to access the model interface. They need a path to place content in a source the model trusts.

Potential paths include a public upload form, a compromised integration, an email attachment, a collaboration folder, a vendor portal, an insider edit, or a migrated archive that has never been reviewed for AI use.

A six-stage control model

1. 01

   Govern the source

   Classify sources before ingestion. A board-policy library, public correspondence inbox, vendor upload portal, and employee collaboration folder should not have the same trust level. Record source system, uploader, ingestion time, approval state, document hash, and applicable classification.

   Use allowlists for high-trust corpora, quarantine unknown sources, and require approval before a new source can feed a production knowledge base. Source governance is stronger than trying to detect every malicious phrase after ingestion.

2. 02

   Inspect the document

   Malware scanning remains necessary, but RAG adds content-level inspection. Extracted text should be checked for invisible Unicode, suspicious instruction patterns, misleading metadata, embedded objects, and content that differs materially from the rendered document.

   A hash can establish that content has not changed since approval. It cannot establish that the content is safe. Approval and integrity are separate controls.

3. 03

   Preserve authorization during indexing

   Do not create a permission-blind vector index and attempt to filter sensitive results after retrieval. Each chunk needs enough authorization context to enforce the user's access before it enters the prompt. That context may include site, department, matter, case, sensitivity, role, and document-level policy inputs.

   The retrieval service should apply current authorization, not permissions copied months earlier. Revocation, deletion and classification changes must propagate to indexes and caches. A legal hold governs preservation; it does not itself grant retrieval access or require removal from search.

4. 04

   Treat retrieved text as untrusted

   Clearly delimit retrieved content, instruct the model to treat it as evidence rather than commands, cap the amount of retrieved text, and reinforce system instructions after the retrieved context where model testing supports that pattern. Prompt delimiters, instruction placement and content scanning reduce some risks but cannot guarantee that a model will ignore hostile instructions. Enforce permissions and tool authority outside the model; test the configured pipeline adversarially.

   Use provenance in the prompt and response. The application should know which document, version, and chunk supported each claim.

5. 05

   Validate the output

   A grounded answer can still be wrong. Require citations for factual claims, compare cited passages to the answer, validate structured outputs against schemas, and block unsupported instructions. High-impact results should route to human review.

   Avoid presenting model confidence as proof. The stronger signal is whether the response is supported by authorized, current, and identifiable sources.

6. 06

   Separate retrieval from action

   The risk increases sharply when the model can send email, update a case, approve a payment, publish a document, or invoke an API. A retrieved document should never grant authority. Tool permissions must derive from the authenticated user and application policy, and high-risk actions should require deterministic validation or explicit approval.

Authorization must exist at three boundaries

• Boundary

  Source document

  Required control

  Policy-governed access to the authoritative record.

  Failure if omitted

  Unauthorized content becomes eligible for indexing.

• Boundary

  Retrieval

  Required control

  Query-time filtering using current identity and policy.

  Failure if omitted

  Restricted chunks enter the model context.

• Boundary

  Output and tools

  Required control

  Response filtering, action authorization, and approval gates.

  Failure if omitted

  The model exposes data or performs an unauthorized action.

Design for quarantine and replay

Assume a poisoned document will eventually pass initial controls. The system should support quarantining a source, removing its chunks from retrieval, invalidating affected caches, identifying queries that retrieved it, and re-evaluating affected answers under controlled conditions. Do not automatically replay tool actions or repeat external side effects.

That requires durable identifiers and audit events connecting the source document to its extracted text, chunks, embeddings, queries, responses, and actions. Without those relationships, incident response becomes a broad index rebuild and a guess about who was affected.

Test the failure modes, not only answer quality

A RAG evaluation set should include adversarial cases:

• a document containing visible prompt-injection text;
• hidden text or zero-width characters;
• a restricted document that is semantically similar to an allowed one;
• a deleted or reclassified source that remains in the index;
• a poisoned document designed to rank for common queries;
• a response that attempts an unauthorized tool call;
• a cache created by one user and requested by another;
• a source whose content changes after approval.

Measure whether the system blocks, contains, records, and explains each case. A helpful answer is only one dimension of a production-ready knowledge base.

How FormKiQ supports a governed RAG foundation

FormKiQ's document model combines source files, metadata, schemas, entities, versioning, audit history, and policy-based access. KnowledgeBase and AI Processing and Analysis are separate add-on modules for Advanced and Enterprise. They use Amazon Bedrock, with inference geography determined by the selected model and inference profile. Source attribution, query-time policy enforcement, index/cache invalidation, injection screening and tool approval require explicit configuration, integration and testing; the public module description is not evidence that all six controls are enabled by default.

The key is not to treat the vector store as a second, less-governed repository. The authoritative document, current permissions, lifecycle state, and retrieval index must remain connected. That connection allows AI use to inherit the controls already required for records, cases, contracts, and regulated information.

Attack drill: a poisoned vendor policy

Illustrative design exercise, not a reported incident or measured FormKiQ result.

1. Step 1

   An attacker uploads a policy telling the model to email private contracts

   Expected control

   Treat instructions in the file as untrusted content; quarantine the source if detected

   Evidence

   Source/version ID, uploader, hash and approval state.

2. Step 2

   A procurement user asks about renewal terms

   Expected control

   Retrieve only sources currently authorized for that user; block restricted chunks before prompt assembly

   Evidence

   Retrieval IDs, policy decision and source versions.

3. Step 3

   The answer proposes sending a contract

   Expected control

   A separate action gateway rejects a tool request lacking user authority and required approval

   Evidence

   Denied action, requested tool, authenticated actor and decision reason.

4. Step 4

   The source is withdrawn

   Expected control

   Remove it from retrieval and invalidate affected caches; investigate earlier uses

   Evidence

   Index/cache invalidation, impacted query IDs and remediation record.