Retrieval & RAG Security
May this user and agent retrieve this content for the current task?
Reference notes by Min · Reviewed October 15, 2026
Definition
Retrieval security protects the ingestion, indexing, selection, and delivery of information supplied to an AI workflow. It includes source integrity, access control, tenant boundaries, and handling of untrusted retrieved content.
Retrieval changes what information a model can use, but relevance ranking is not an access decision. A highly relevant passage can still belong to a different customer or be out of scope. Keep the ranking and the permission decision conceptually separate.
What it covers
- Ingestion
- Verify sources, metadata, permissions, and update ownership.
- Selection
- Apply resource and tenant checks before protected context is returned.
- Context handling
- Distinguish retrieved claims from trusted system instructions.
- Lifecycle
- Propagate relevant access changes and removals to indexes and caches.
The security boundary includes indexes, raw documents, metadata, reranking, caches, and returned artifacts. Review where protected content first becomes available to the model and make sure the authorization is effective before that point.
In practice
Practical design patterns by Min.
- Carry the requester and task scope into retrieval authorization.
- Test access boundaries with similar documents from different tenants.
- Keep source identifiers and versions with retrieved evidence.
- Evaluate stale permissions, deleted documents, poisoned text, and cache leakage.
Build evaluation cases in which documents have similar text but different owners or permissions. Add tests for a revoked document and for a source containing misleading instructions. Examine the retrieved material and actual service access, not only the final answer.
Working example
A shared company knowledge index
An agent searches documents held by several client teams.
- Restrict retrieval to documents visible to the caller and relevant to the task.
- Return source references with the selected passages.
- Verify that a cached result for one client cannot be served to another caller without its own permission check.
Why the controls matter
A reference in an answer should identify the evidence used without exposing a document the reader cannot access. Source references need their own permission behavior; a copied title or URL can also reveal protected information.
Common pitfalls
- Assuming a vector database inherits every source system’s permission automatically.
- Filtering sensitive passages only after they enter model context.
- Confusing relevance with source trust or current authority.
Encryption protects certain storage and transport risks but does not decide which caller may retrieve a record. Likewise, a clean source at ingestion can change later, requiring update and review paths.
Questions for operational review
Use these questions to decide what evidence your team needs. They are editorial prompts, not a compliance checklist.
- Where are source permissions enforced?
- How do revocations reach caches and indexes?
- Can the same query expose another tenant’s information?
Articles linking here
References
Primary documents reviewed for this entry. Examples and implementation patterns are editorial synthesis.
- OWASP LLM08:2025: Vector and Embedding Weaknesses ↗Accessed October 15, 2026