What matters first
- Carry trusted ownership and permission context into retrieval.
- Review indexes and caches as stores of sensitive information.
- Test permission removal and document deletion across the full pipeline.
Map the document lifecycle and ownership
Identify document sources, ingestion identities, metadata, chunking, embeddings, indexes, and the application that assembles context. Record how a document’s organization, owner, and access policy are established. A shared index needs an explicit isolation model.
OWASP identifies unauthorized access and cross-context leakage among vector and embedding risks. For your product, define which documents may be shared, which are tenant-specific, and how permission changes should propagate. A retrieval feature cannot be reviewed accurately without those rules.
Enforce access before context is assembled
Use the verified user and organization context to constrain retrieval through an appropriate trusted boundary. Do not rely solely on a model instruction asking it to ignore information the user should not see. Review alternate retrieval APIs, administrative tools, and direct document previews too.
Check the behavior of queries, filters, reranking, and fallback retrieval paths. If a strict retrieval result is empty, a broad fallback should not silently expand access beyond the user’s policy. Record intentional sharing separately from exceptional debugging access.
Review caches, citations, and connected tools
A cached answer or retrieved chunk can contain sensitive material even if the original document remains protected. Review cache keys, ownership, expiry, and reuse across users and tenants. The same applies to citations, download links, conversation history, and debugging traces.
If the AI application can act on retrieved instructions through tools, review that action boundary separately. An internal document can be untrusted as an instruction source even when the user is allowed to read it. Narrow tool permissions and ensure downstream services authorize sensitive operations.
Verify changes and offboarding
Use synthetic documents with distinct ownership to test allowed and denied retrieval, role changes, membership removal, and deletion. Follow the content through indexes, caches, and retained conversations according to your product’s stated lifecycle. Do not test isolation using real confidential customer records.
Record which component enforces access and how the team verifies propagation. Revisit the review when adding knowledge sources, index providers, sharing features, or new retrieval fallbacks. A RAG security review is about controlled access to information, not only the quality of generated answers.
Your next steps
- Document sources, ownership, index metadata, and the trusted retrieval boundary.
- Review filters, fallbacks, caches, citations, and tool access.
- Test role removal and deletion using separate synthetic tenants.
- Discuss a scoped review of your AI application’s data paths.
Questions teams ask
Can a prompt keep a model from revealing forbidden retrieved data?
It should not be the primary authorization boundary. Prevent unauthorized retrieval and context assembly using trusted application controls.
Are embeddings automatically non-sensitive?
Do not assume that. Review the information they represent, access to the index, and the surrounding retrieval and storage controls.
Sources and editorial notes
Public-source facts are cited above. The review questions and action plans are Cyphen’s guidance for applying those lessons to your own systems. Sources checked on .