📚 RAG Security: Threats and Defenses for Retrieval-Augmented Generation

RAG security (Retrieval-Augmented Generation) is the protection of the entire "corpus → embeddings → vector store → generator" pipeline against data poisoning, indirect injection through documents, and information leakage during retrieval. RAG has become the standard for enterprise LLM assistants, but it also expands the attack surface: you can now compromise a system without touching the model itself — it is enough to "plant a mine" in the knowledge base. In the OWASP Top 10 for LLM 2025, several categories address these risks, including the new LLM08 (Vector and Embedding Weaknesses). Below is a breakdown of the threats and how the SYNTREX platform closes them.

Part of the series: OWASP LLM Top 10 · Prompt Injection · LLM Jailbreaks.

RAG Architecture and Its Attack Surfaces

A RAG system consists of four components, and each is a potential entry point:

Component	Function	Attack surface
Corpus / knowledge base	Stores the source documents	Data poisoning
Embedding model	Turns text into vectors	Inversion, source-text extraction
Vector store	Similarity search	Cross-tenant leakage, unauthorized access
Generator (LLM)	Builds the answer from context	Indirect injection via retrieved content

The central idea: in RAG, trust in the answer is no higher than trust in the corpus. If a poisoned document gets into the base or access control over the vectors is broken, the whole system suffers — no matter how "safe" the model itself is.

Knowledge Base Poisoning (Data Poisoning) — OWASP LLM04

An attacker plants malicious documents in the corpus that are highly likely to be retrieved and influence the answer. Unlike poisoning a model's training data, poisoning a RAG corpus requires far fewer resources: the PoisonedRAG study (Zou et al., USENIX Security 2025) demonstrated 90% attack success by injecting just 5 malicious texts per target question into a base of millions of documents. The attack works in both black-box and white-box scenarios, and the authors acknowledge that existing defenses are insufficient.

This category also includes re-ranker manipulation: poisoned "text + trigger query" pairs (PR-Attack) or universal corruption with a small set of adversarial texts (UniC-RAG) force the system to prefer the attacker's content.

Defense: ingest documents only from authenticated, whitelisted repositories; adversarial scanning for hidden instructions before indexing; provenance via OWASP CycloneDX / ML-BOM; a WORM store with versioning; regular re-validation of the index.

Indirect Injection via Documents — OWASP LLM01

This is indirect prompt injection delivered through a retrievable document. The attacker hides instructions in a PDF (white text on a white background), a web page, or an email that RAG will pull into the context; the model cannot tell "its own" instructions from those embedded in someone else's content. OWASP describes the "Hidden Text Injection" scenario, and the PoisonedRAG study confirms it: 5 specially crafted documents yield roughly 90% success.

Defense: scan the retrieved content for instructions before feeding it to the model; normalize Unicode (strip invisible characters and white-on-white text); separate system instructions from content in the prompt template; least privilege on the agent's tools (see also the lethal trifecta).

Vector and Embedding Weaknesses — OWASP LLM08

A new category for 2025, specific to RAG. It comprises several sub-risks:

Cross-Context Leakage

In a multi-tenant environment with a shared vector store, one user group's embeddings can be retrieved in response to another's query — and trade secrets leak. The typical root cause is the absence of tenant_id filtering before similarity ranking. According to industry post-mortems, with zero technical sophistication such leakage reproduced in the majority of test queries.

Embedding Inversion

Embeddings were long considered "irreversible" compression — that is a myth. The work by Morris et al., "Text Embeddings Reveal (Almost) As Much As Text" (EMNLP 2023), reconstructed 92% of tokens from 32-token inputs and extracted full names from clinical records. The few-shot ALGEN attack (2025) achieves results with only ~1,000 training samples and works cross-domain and cross-lingually. The conclusion: if the vector store is compromised, the stored vectors can be "decrypted" back into text.

Membership Inference

The "Is My Data in Your Retrieval Database?" attack (Anderson et al., 2025) determines whether a specific fragment is present in a RAG base from the characteristic responses to crafted queries — which is already a breach of the corpus's confidentiality of composition.

Unauthorized Access to Chunks

Insufficient access control allows the retrieval of chunks with PII, proprietary, or copyrighted information in circumvention of the user's permissions.

Defense: a permission-aware vector database with metadata filtering before the search; tagging content by access level; encryption of the store (AES-256 at rest, TLS 1.3 in transit); private network endpoints; an immutable log of retrieval operations.

Exfiltration via Retrieval — OWASP LLM02

The most painful situation for compliance: the RAG system returns one user's data in response to another user's query — which is already a reportable disclosure incident. This category also includes the extraction of PII, medical records (PHI), API keys, and secrets mistakenly indexed alongside the documents, as well as exfiltration via crafted queries. OWASP links these risks to MITRE ATLAS techniques AML.T0024 (Infer Training Data Membership / Invert ML Model).

Defense: scan every document for PII/PHI/secrets before creating embeddings; mask sensitive data on input and in the response; context-preserving tokenization instead of crude deletion; DLP scanning of the output; anomaly control over retrieval patterns.

How SYNTREX Protects

SYNTREX embeds into the RAG pipeline at two frontiers: at ingestion/indexing (what gets into the corpus) and at retrieval/output (what goes to the user). The consolidated map:

RAG threat (OWASP)	SYNTREX engines	Frontier
LLM04 Data Poisoning	`dormant_payload`, `injection`	Document ingestion
LLM01 Indirect injection via documents	`injection`, `output_scanner`	Retrieval → generation
LLM08 Vector/embedding weaknesses	`pii`, `exfiltration`, `output_scanner`	Ingestion + retrieval
LLM02 Exfiltration at retrieval	`pii`, `exfiltration`, `output_scanner`	Output

Specifically:

injection scans the retrieved content for hidden instructions (with Unicode normalization — white-on-white text and invisible characters are stripped before analysis), preventing an indirect injection via a document from reaching the model.
Redaction controls use pii, output_scanner, and exfiltration to catch API keys and tokens in the corpus before indexing and in responses — secrets do not enter the embeddings and do not leak to the user.
pii masks personal data on input and output (including 16-digit card numbers), reducing the risk of cross-tenant leakage and embedding inversion.
exfiltration detects and blocks data-exfiltration patterns in the content (including Markdown-image exfiltration).
dormant_payload detects dormant payloads in documents (Phantom/CorruptRAG patterns) that activate on a trigger.

An important honest boundary: the cross-tenant isolation of the vector store (filtering by tenant_id, RBAC/ABAC at the retrieval layer, encryption) is implemented on the side of the application and the RAG infrastructure. SYNTREX does not replace access control over the vector database — it complements it with content scanning, PII/secret masking, and an immutable audit of operations.

Example `syntrex.yaml` configuration for RAG

YAML

engines:
  injection:
    action: block
    confidence_threshold: 0.6
    normalize_unicode: true       # strip white-on-white and zero-width before analysis
    scan_retrieved_context: true  # inspect retrieved chunks, not just the query
  pii:
    action: redact
    mask_character: "*"
    scan_on_ingest: true
  exfiltration:
    action: block                 # keys/tokens and outbound leakage patterns stay out
  dormant_payload:
    action: alert                 # Phantom/CorruptRAG dormant payloads

SOC correlation rule: RAG poisoning → suspicious response

YAML

rules:
  - id: RAG_POISON_TO_LEAK
    name: "RAG Poisoning → Sensitive Leak"
    description: "A dormant payload from RAG content followed by PII/secret in the response"
    enabled: true
    conditions:
      - sequence:
          - category: dormant_payload
          - category: pii
        within: "5m"
        same_field: "session_id"
    action:
      create_incident: true
      severity: CRITICAL
      kill_chain_stage: "impact"
      playbook: "quarantine_rag_source"
    metadata:
      mitre_atlas: ["AML.T0051", "AML.T0024"]
      owasp_llm: ["LLM01", "LLM04", "LLM08"]

Every retrieval operation and every verdict is recorded in the Decision Logger (a SHA-256 + HMAC chain) — providing an immutable audit trail for investigations and regulators (important for GDPR/Russia's FZ-152, where RAG is explicitly flagged as a risk source when processing personal data).

Frequently Asked Questions (FAQ)

What is RAG security and why is it a separate topic?

A RAG system augments LLM answers with data from an external knowledge base, and that base becomes a new attack surface. You can compromise the system without touching the model: poison the corpus, hide instructions in a document, or extract data through broken access control over the vectors. That is why RAG security is treated separately from the security of the model itself.

What is RAG poisoning (data poisoning)?

It is the planting of malicious documents in the knowledge base that the system will retrieve and use in its answer. The PoisonedRAG study showed that just 5 specially prepared documents per target question are enough to achieve roughly 90% attack success, even in a base of millions of records — and the model is not modified in the process.

Can the source text be recovered from embeddings?

Yes. Contrary to common belief, embeddings are not irreversible compression. Inversion attacks (Morris et al., 2023) recover up to 92% of tokens and extract, for example, full names from medical records. That is why the vector store must be encrypted and protected just as strictly as the source data.

What is cross-tenant leakage in RAG?

It is when, in a shared vector store, one customer's (tenant's) data ends up in another's responses. The usual cause is that similarity search runs without prior filtering by tenant_id. The defense is a permission-aware vector database where permissions are checked before ranking, and logical separation of indexes.

How do you defend against indirect injection via documents in RAG?

You need to scan the retrieved content for hidden instructions before feeding it to the model, normalize Unicode (remove white-on-white text and invisible characters), separate system instructions from content in the prompt template, and give the agent least privilege. In SYNTREX, the injection (with scan_retrieved_context) and output_scanner engines handle this.

Does SYNTREX replace access control over the vector database?

No. Cross-tenant isolation, RBAC/ABAC, and encryption of the vector store remain on the side of the application and the RAG infrastructure. SYNTREX complements them: it scans content for injections, masks PII and secrets at ingestion and output, detects dormant payloads, and maintains an immutable audit of retrieval operations.

Which standards govern RAG security?

Primarily the OWASP LLM Top 10 2025 (categories LLM01, LLM02, LLM04, LLM08), MITRE ATLAS (injection and model-inversion techniques), and NIST AI 100-2e2025 on adversarial ML, which explicitly describes RAG-base poisoning and indirect injection. For personal data, GDPR and Russia's FZ-152 apply.

Sources

Related guides: OWASP LLM Top 10 · Prompt Injection · LLM Jailbreaks