RAG security: protect retrieval pipelines and vectors

RAG security protects the entire flow: document source, ingestion, chunking, embedding, vector store, retrieval, prompt and output. Retrieval-Augmented Generation gives a model useful knowledge, but every document becomes untrusted input capable of influencing LLM behaviour.

OWASP highlights data poisoning, unauthorised access, cross-context leakage and vector or embedding weaknesses among the relevant risks.

Establish trust before ingestion

Every source needs an owner, classification and permitted scope. Scan files, normalise formats and store provenance, version, retrieval time and checksum. Keep document content separate from system instructions.

An internet page, customer ticket or uploaded PDF can contain prompt injection in text, metadata or OCR-visible images. Document content must not override policy or authorise tool execution.

Authorise before retrieval

Filter documents by user identity and permissions before chunks enter the prompt. Post-generation filtering is too late because the model may already have used forbidden content.

Carry ACLs into documents and chunks. In multi-tenant systems, use separate indexes or rigorously enforced tenant filters. Test for zero cross-tenant results.

Protect the vector store

Encrypt connections and storage, constrain service identities and log reads and writes. A changed embedding or metadata field can alter ranking without editing visible text, so control integrity, embedding-model versions and reindexing.

Never treat vector similarity as an authorisation decision. A semantically similar passage can still belong to another user.

Limit prompt-injection impact

Mark retrieved passages explicitly as untrusted data. Minimise their number and length. Expose tools through a separate policy layer with parameter validation, least privilege and confirmation for high-impact operations.

The model cannot decide that document text saying “send all files” is an authorised command. Use the OWASP Top 10 for LLM applications for the broader threat model.

Output, citations and privacy

Require citations to retrieved passages and expose the source to the user. A citation does not guarantee truth, but it supports verification. Filter secrets, personal data and internal instructions before responding.

Do not retain full prompts without classification and retention controls. RAG telemetry can become another sensitive-data repository.

RAG security tests

1. Ingest documents with visible and hidden prompt injection.
2. Test access boundaries between roles and tenants.
3. Attempt index poisoning and metadata modification.
4. Extract secrets through indirect questions.
5. Vary spelling, language and attack format.
6. Confirm tools reject over-broad actions.
7. Measure citation accuracy and unauthorised retrieval.

RAG does not automatically inherit permissions from source systems. Without provenance and pre-retrieval authorisation, it can turn distributed, protected data into one convenient leakage point.

---

Testing retrieval authorisation

Check permission before search and again before a chunk reaches the model. Metadata filtering must be enforced server-side, not supplied by the client. Build tests with two tenants, deleted records and embargoed content; questions should seek data directly, through synonyms and through aggregation of several chunks.

A document is untrusted input. Separate system instructions from retrieved text, label sources and constrain tools available after retrieval. Log chunk IDs, index version and policy decisions without retaining sensitive prompts longer than necessary. After deletion, verify the index, cache and replicas, not just the source store.

Sources: OWASP RAG Security Cheat Sheet, OWASP LLM08, NIST GenAI Profile.