RAG Guard: Protect Your Retrieval Pipeline and Vector Database

RAG Guard protects the data surface at the point of retrieval. Where most guardrails inspect only the prompt, RAG Guard enforces policy at the vector-database boundary itself — on the retrieval traffic, not just the prompts that trigger it.

​

What RAG Guard protects

The retrieval pipeline: the RAG corpus, the embeddings, and the vector database your application queries for context. This is a distinct attack surface from the model — poisoned retrieval content corrupts responses downstream without ever touching the prompt.

​

Threats it stops

• RAG & data poisoning — documents submitted for embedding are scanned and quarantined before they reach the vector database; poisoned entries never reach the retrieval layer (BG-12).
• Vector & embedding weaknesses — source compliance, access rules, and data classification applied to retrieval traffic at the vector-database boundary (BG-09).
• Misinformation / hallucination — every factual span bound to a provenance-verified source; ungrounded output is rejected (BG-09).

​

How it works

RAG Guard binds each statement in a response to a verifiable reference (domain/URL, timestamp, content-hash) and rejects answers that are not grounded in an authorized source. On the ingestion side, each chunk submitted for embedding is evaluated for jailbreak instructions, policy-overriding directives, and obfuscated payloads, and is committed to the index only if it passes provenance, schema, and moderation checks.

​

Controls

RAG Guard runs BG-09 and BG-12. See the Controls Catalog for each control’s definition, scope, and benchmark.

​

OWASP coverage

Addresses LLM04 Data and Model Poisoning, LLM08 Vector and Embedding Weaknesses, and LLM09 Misinformation from the OWASP LLM Top 10.

​

Related