Securing RAG systems in production: ingestion, indexing, multi-tenancy

RAG architectures have become the dominant pattern in 2026 for B2B SaaS integrating LLMs in production. The user query is converted to embedding, relevant documents are retrieved via vector similarity, then injected into the LLM context.

This architecture introduces three new attack families that don't appear in traditional pentests.

The 3 RAG-specific attack families

Family 1: Indirect prompt injection via retrieved documents

An attacker plants a document containing hidden instructions (in HTML metadata, in characters that look invisible, in obscure formatting). When the document is retrieved and injected into the LLM context, the instructions are executed.

This is the most dangerous family because it bypasses the user's awareness. The user thinks they are asking the LLM a benign question; the LLM is in fact executing instructions from a document they don't see.

Family 2: Cross-tenant leakage

If the vector index is shared across tenants without strict isolation, a tenant's query may retrieve documents from another tenant. Data leakage at scale.

Test: prompt crafting designed to force retrieval from another tenant's documents (queries semantically close to known documents of other tenants).

Family 3: Index poisoning

An attacker with authoring access to the index can plant deceptive content that becomes "ground truth" for the LLM. The model now confidently states fictional information sourced from the poisoned document.

The 5-step defensive pipeline

Step 1 — Audit ingestion sources

Inventory document ingestion sources: PDF uploads, web scraping, internal API feeds, user-submitted content. For each source:

• Who can ingest? (least privilege).
• From where? (allowed domains for scraping).
• What format? (whitelist of MIME types).
• What signature? (authoring trace, hash, timestamp).

Step 2 — Sanitize ingested content

Three sanitization layers:

1. Format normalization: HTML stripping, markdown stripping, conversion to plain text.
2. Hidden instruction detection: regex on patterns ("ignore previous instructions", base64 chunks, ROT13 patterns), classifier-based detection (Llama Guard, Prompt Guard).
3. Confidentiality labeling: tag each document with sensitivity (public, internal, restricted, secret).

Tools 2026: LangChain DocumentLoaders with custom validators, Unstructured.io for parsing, Lakera Guard for instruction detection.

Step 3 — Implement multi-tenant isolation

Three isolation patterns, in decreasing order of safety:

• Pattern A: Separate index per tenant. Strongest isolation. Higher cost (one index per tenant). Tools: Pinecone Namespaces, Weaviate Multi-tenancy, Qdrant Collections, pgvector with separate schemas.
• Pattern B: Shared index with strict metadata filter. Acceptable if filter is infallible (test with bypass attempts). Cheaper. Tools: pgvector with Row-Level Security, any vector DB with metadata filter + verified RBAC.
• Pattern C: Shared encrypted index per tenant (CVRF — Confidential Vector Retrieval). Emerging, not yet standardized. For very-high-isolation use cases.

Avoid: shared index without filtering — guaranteed cross-tenant leakage at the first non-trivial query.

Step 4 — Test in CI/CD

Automated test suite running at every release:

• Cross-tenant retrieval tests: queries explicitly designed to retrieve other tenants' content. Must return zero hits.
• Indirect injection tests: corpus of documents containing hidden instructions. Pass condition: LLM answers user query correctly, ignores injected instructions.
• Index poisoning tests: ingestion of crafted "honeypot" documents. Verify they do not become "ground truth" for normal queries.

Tools: Garak (NVIDIA) with custom RAG probes, Promptfoo for evaluation, Lakera Red for managed service.

Step 5 — Monitor in production

Production monitoring:

• Anomaly detection on queries: unusual length, atypical patterns, unusual retrieval patterns.
• Cross-tenant retrieval rate: should be zero. Alert at first occurrence.
• Source reliability scoring: track which documents are most cited, who authored them, when.
• Audit log: full retrieval history with user, query, retrieved documents, LLM output. Retention >= 12 months.

Compliance — regulatory layer

RAG security is required by:

• EU AI Act Article 15: robustness and cybersecurity for high-risk systems. Cross-tenant isolation is essential.
• EU AI Act Annex IV: technical documentation must describe RAG architecture, sources, isolation mechanisms.
• ISO 42001: AI risk management — RAG-specific risks documented and mitigated.
• OWASP LLM Top 10: LLM01 (prompt injection, especially indirect via retrieved data), LLM06 (sensitive information disclosure).

For SaaS handling regulated data (HDS healthcare, financial, defense), document the RAG architecture explicitly in the Annex IV technical documentation before placing high-risk AI systems on the European market.

The "AI engineer's blind spot"

A common pattern: AI engineers build sophisticated RAG architectures but treat security as a downstream concern. By the time security review happens, the architecture has been deployed. Retrofitting cross-tenant isolation in production is 5-10x more expensive than designing it in.

Recommendation: include security review at the architecture phase of any production RAG. WeeSec offers focused 1-week reviews specifically for this.

Frequently asked questions

What are the risks of a RAG in production?

Three families: (1) index poisoning (malicious injection via ingested documents), (2) cross-tenant leakage in multi-tenant, (3) indirect prompt injection via retrieved documents containing hidden instructions.

How to secure the RAG ingestion pipeline?

Trace authoring (who loaded what, when), validate sources (whitelist of domains), sanitize text (HTML stripping, hidden instruction detection), apply confidentiality labels, monitor anomalous queries.

What isolation patterns for a multi-tenant RAG?

Three options: (1) separate index per tenant — strongest, costliest; (2) shared index with strict metadata filter — acceptable if filter is infallible; (3) tenant-encrypted index (CVRF, emerging). Test in CI/CD with cross-tenant injections.

Which tools for multi-tenant isolation?

Pinecone Namespaces, Weaviate Multi-tenancy, Qdrant Collections, PostgreSQL pgvector with Row-Level Security. ISO 42001 + EU AI Act: cross-tenant isolation is an essential control to document explicitly in Annex IV technical documentation.

How to test indirect prompt injection in a RAG?

Corpus of documents containing hidden instructions in various formats (HTML metadata, comments, invisible characters, encoded text). Tools: Garak with custom RAG probes, Promptfoo for evaluation. Run in CI/CD at every release. Pass condition: LLM answers user query correctly, ignores injected instructions.