A corporate RAG system is often treated as a safer alternative to a public chatbot: the model runs locally, documents are not sent to an external API, and access is limited to employees. That does reduce part of the confidentiality risk. It does not answer a different question: can the content of the knowledge base itself be trusted?

If the index contains an altered policy, forged instruction, or deliberately crafted text, the model may retrieve it and produce a persuasive answer. Compromising model weights is not necessary; influencing the channel through which documents become “knowledge” can be enough.

What research has established

PoisonedRAG, published at USENIX Security 2025, studies targeted knowledge-base poisoning. The attacker creates text that is both highly retrievable for a selected question and capable of steering the model toward a chosen wrong answer. In the authors’ experiments, five malicious texts per target question produced an attack success rate of about 90%, even in a database containing millions of documents.

This is a laboratory result, not an estimate of incident probability for a particular company. It does demonstrate an important engineering point: a large corpus does not automatically dilute poisoning. Retrieval is not random; it selects the most relevant items, so a small purpose-built fragment can reach the top of the result set.

In July 2026, the authors of the TriShieldRAG preprint proposed three layers: an ingest check, trust-aware retrieval scoring, and a generation-time consensus stage. In a test using 5,000 documents, ten target questions, and a non-adaptive attacker, the full pipeline reduced attack success from roughly 91% to roughly 13%.

That number is not a production guarantee. The authors explicitly state that they did not evaluate an attacker who knows the defense and adapts to it; the question set is small, and the ingest filter performed most of the work by detecting an aggressive text pattern. The useful lesson is not the exact percentage but the architecture: one filter is insufficient, and controls must cover the entire document path.

How poisoning enters an ordinary business workflow

The source does not have to be an external attacker. Incorrect knowledge can originate in a routine process without clear ownership:

  • a shared network folder writable by dozens of employees;
  • automatic ingestion of email or ticket attachments;
  • synchronization with CRM, wiki, cloud storage, or a supplier website;
  • OCR that misreads a table or drops a negation;
  • an obsolete instruction stored beside the current version;
  • a service account with excessive privileges;
  • a contractor or employee able to publish without a second control.

Accidental contamination comes from errors, duplicates, and expired versions. Targeted poisoning is designed to rank for a specific question. The architecture should detect both without trying to infer the author’s intent.

Protection starts before the vector database

A dependable pipeline does not index a file immediately after upload. It places an intake gateway and quarantine between the source and the production collection.

For every object, retain an immutable original and a manifest containing:

  • a stable `document_id` and version number;
  • a cryptographic file hash;
  • source and acquisition method;
  • data owner and change author;
  • upload, review, and publication times;
  • access class, validity period, and review date;
  • linkage to the superseded or revoked version;
  • parser, OCR, chunking, and embedding-model versions.

A hash does not prove that a document is true. It proves that the reviewed version was not silently replaced. Provenance should not be a free-text field controlled by the same importer. A trusted gateway derives it from the authenticated identity, delivery channel, and source policy.

Separate the right to upload from the right to publish into the production index. Critical policies, prices, bank details, legal language, and safety instructions need a second participant or a formal approval rule. Low-risk sources may be automated, but only through an explicit allowlist and with an audit trail.

Three boundaries instead of one filter

1. Ingest-time control

The quarantine stage checks file format, malware rules, structure, language, unusual repetition, hidden elements, abrupt size changes, and similarity to known documents. Extracted text is then compared with the previous version: what was added, removed, and which facts changed?

Automated analysis can assign risk, but it should not declare a document truthful. Targeted content can be rewritten as natural prose, so high-risk objects need human review while low-risk objects go to staging.

2. Retrieval-time control

Relevance and trust are separate signals. Ranking should consider not only vector similarity but also approved source, current version, access class, and source independence.

Practical rules include:

  • do not let five chunks from one version look like five independent confirmations;
  • cap the share of results from one document or source;
  • rank an approved current policy above a draft;
  • exclude revoked versions before vector search, not after generation;
  • return `document_id`, version, and provenance with each chunk;
  • use a separate trusted corpus to confirm high-impact queries.

If every supposedly independent check reads the same poisoned index, it is not independent. A second search with a paraphrased query may improve recall, but it is not a separate trust channel.

3. Generation-time control

The model should treat retrieved documents as data, not instructions. The system policy should require citations to specific source versions, expose contradictions, and avoid categorical answers when evidence is insufficient.

For consequential actions—changing bank details, a payment, a price, an order status, or access—RAG output should not be an executable command. It produces a proposed decision; deterministic business rules validate it, and a person approves the action. This limits damage from both poisoning and ordinary model error.

Publishing and rollback

Release the working knowledge base in versions. New documents first enter a staging collection. Run control questions, citation checks, contradiction tests, and access tests there. After approval, switch an alias to the new corpus version. Keep the previous version available for rapid rollback.

A vector-index snapshot is useful but insufficient. Recovery also needs the originals, manifests, access rules, chunking configuration, and embedding-model version. Otherwise, a rollback may produce a different set of chunks under the same release name.

A minimum incident procedure is:

1. Stop automatic publication without deleting evidence.
2. Record the suspicious `document_id` values, versions, hashes, and queries where they appeared.
3. Point the production alias to the last approved release.
4. Rebuild from trusted originals instead of manually deleting a few vectors.
5. Change `corpus_version` and invalidate associated semantic and answer caches.
6. Re-run the control set and verify access rules.
7. Identify answers and business actions that may have relied on revoked documents.

Metrics for management

A small deployment can start with a weekly report:

  • number of identities allowed to publish documents;
  • share of objects without an owner, validity date, or verified source;
  • time to detect and roll back a deliberately bad test release;
  • share of answers without a verifiable citation;
  • rate of conflicts between sources;
  • concentration of top-k results in one document;
  • quarantine false positives;
  • control-set results after each release.

The main business variable is the cost of an accepted wrong answer. Informational search can use warnings; bank details, contracts, workplace safety, and payments need independent verification and human approval.

Economics of a minimum control plane

Most baseline controls do not require a second LLM. The low-cost first layer is organizational and deterministic: separate roles, prohibit direct production writes, keep versions and hashes, add staging, and run an automated regression set. The principal expense is data-owner time—who approves changes and within what service level.

Model cost from the change stream. If `D` documents arrive per day, fraction `q` requires review, and review takes `t` minutes, monthly manual load is approximately `D × q × t × working days / 60`. Reduce it with trusted-source policies and good diffs, not by removing control.

A multi-model panel increases cost and latency. A small business should first secure writes and establish rollback; use model consensus only for critical queries after testing on its Russian-language corpus.

A practical 30-day pilot

In week one, inventory sources, owners, write identities, and automatic ingestion paths. Then choose one process and build a versioned staging pipeline. During week three, collect 30–50 control questions with obsolete versions, contradictions, ownerless documents, and safe poisoning simulations. In week four, conduct a rollback drill with cache invalidation and an audit of affected answers.

The pilot should produce explicit roles as well as model metrics: who approves a source, publishes a corpus release, owns an incident, and confirms recovery.

Conclusion

A local model protects the perimeter; it does not make knowledge true. Operate a corporate RAG base as a production data system, with an owner for every source, change quarantine, verifiable provenance, separated privileges, versioned releases, auditable citations, and a rehearsed rollback.

The first step does not require an expensive platform. Block direct writes to the index, select one critical corpus, and test whether a bad release can be detected and fully reversed within a defined time. If that scenario fails, adding more models and agents is premature.