A retrieval system is a search engine that answers in sentences, and that changes its security properties in one specific way: search returns links a user can be denied, while generation returns prose that has already been assembled. By the time an answer exists, any disclosure has happened.
This page walks the pipeline and sets out what has to be true at each stage. It assumes the case for permission aware retrieval is already made. If it is not, security and privacy for AI-powered CMS platforms makes it at length, including why filtering after retrieval fails in ways that are hard to detect. The short version is that filtering belongs inside the query, evaluated against the identity of the person asking, and everything below assumes that.
Ingestion is a trust boundary
The index is assembled from sources of varying trustworthiness, and that is where the first decisions belong.
Decide what is in scope, explicitly. The default of indexing everything reachable is a decision made by omission. Some content should never be retrievable by a general assistant: material under legal hold, personnel investigations, security documentation describing your own controls, credentials that ended up in documents. An exclusion list maintained deliberately is worth more than a classification scheme nobody applies.
Carry the source permissions with the content. Each passage needs to retain who may see it, in a form the query layer can filter on. Reconstructing that later is guesswork, and the moment content is copied out of a system that knew its permissions into an index that does not, the authorization model has been discarded.
Treat content from outside your control as hostile input. Uploaded files, syndicated feeds, supplier documents and anything user submitted can carry instructions aimed at the model. The OWASP GenAI Security Project tracks this as LLM01:2025 Prompt Injection, and the version that matters here is the indirect one, where the instruction arrives inside a document rather than from the person asking.
Re-ingest on a schedule, and handle deletion. An index is a copy. When a document is deleted or its permissions are tightened at source, the index must follow, or the system is serving material the source system believes is gone. This is the most commonly missing piece in systems that have been running for a year.
The index is a copy of your content and needs treating as one
Embeddings feel abstract, which leads people to treat the store holding them as less sensitive than the documents it was built from. It is not. OWASP added LLM08:2025 Vector and Embedding Weaknesses to its list for this reason.
Three properties matter.
Most systems store the text too. To supply passages to the model, the passage itself is usually kept alongside the vector. An index over confidential material therefore contains confidential material in readable form, and it inherits the classification of its most sensitive source.
Vectors alone are not anonymous. Embeddings are derived from the text and retain a great deal about it. Treating a vector store as safe because it holds numbers is the same error as treating a hash as safe without considering what can be recovered from it.
Metadata is the enforcement surface. The permission attributes attached to each passage are what makes filtered retrieval possible, which means write access to that metadata is equivalent to write access to your permission model. It belongs under the same controls as any other authorization data, with the encryption, access control and logging NIST's SP 800-53 catalog specifies for data of that sensitivity.
Poisoning belongs here too. If an attacker can write into an indexed source, they can place content designed to be retrieved for particular questions. OWASP tracks that as LLM04:2025 Data and Model Poisoning, and the defense is unglamorous: control write access to indexed sources, and know which sources accept input from outside the organization.
Identity has to travel the whole way
The pipeline crosses several components, and the user's identity has to survive every hop. Where it does not, the system reverts to whatever the service account can reach.
The architectural requirement is that the retrieval query executes with the asker's effective permissions, not the service's. That is straightforward to state and is where most implementations quietly compromise, because propagating identity across an application, a retrieval service and an index is more work than granting the service broad access and filtering afterward.
NIST's SP 800-207 is the general principle: no implicit trust is granted based on network location, so a retrieval service inside your perimeter has earned nothing by being there. The specific consequences are worth stating.
- Permissions are evaluated at query time, not at ingestion time only. A user who lost access this morning must stop seeing that content this morning.
- Cached and precomputed results carry permissions too. A cache keyed only on the question text will serve one user's permitted answer to another user.
- Conversation history is retrieved content. A thread that quoted a restricted passage still contains it, and a summarization step over that history can reintroduce it later.
- Error paths must fail closed. If the permission service is unavailable, retrieval returns nothing. Returning unfiltered results on failure is the worst possible default and looks entirely normal in testing.
Output is not trusted either
What comes back from the model is generated text, and where it is used for anything beyond display it needs the treatment any untrusted input gets. OWASP calls this LLM05:2025 Improper Output Handling, and the failure is familiar to anyone who has handled user input: text that reaches a browser, a shell, a query or an API call without validation is an injection vector regardless of which component produced it.
Two further checks belong at this stage. Answers should be constrained to the retrieved material, so that a passage the user was not permitted to see cannot be paraphrased into an answer they were. And where the system can act rather than only answer, the action boundary belongs here: a compromised instruction that cannot trigger anything is a much smaller problem than one that can.
Provenance, and why it is a control
Attribution is usually built as a usability feature. It is also the cheapest security control in the system, because it makes two classes of failure visible to the person best placed to notice them.
A citation lets a reader see that an answer came from a document they recognize as superseded, or from a source that should not have been reachable at all. Users report the second immediately, and that report is frequently the first indication that a permission filter is wrong. A system that answers without showing where the answer came from has no such feedback path.
What to log, and the cost of logging it
Reconstructing an incident requires knowing who asked, what was retrieved, what was answered, and what ran as a result. Without the retrieval record specifically, it is impossible to answer the question that actually gets asked after an incident, which is what the system disclosed rather than what it was asked.
That record is itself a store of sensitive material, frequently more concentrated than the sources, because it collects the passages people actually asked about. It needs its own retention period, its own access controls and its own place in the data classification. Logging everything forever is not the cautious choice; it is a second disclosure risk created in the name of the first.
What to verify before it carries anything sensitive
- A user with restricted access asks a question whose best answer is in restricted material, and does not receive it.
- Access removed at source stops affecting retrieval within a stated interval, and the interval is written down.
- A document containing an obvious injected instruction is indexed, retrieved, and does not change the system's behavior.
- The permission service is made unavailable in a test, and retrieval returns nothing rather than everything.
- Every answer carries a citation, and the citations resolve to passages the asker may read.
- The retrieval log exists, is queryable, and has a retention period somebody has agreed to.
Each of those is a test that can fail. A design review that produces no failing test has not been performed.
Where to go next
The mechanism itself is covered in what enterprise RAG is, and the storage layer in vector databases and enterprise AI. The wider environment this sits inside is how to build a private AI environment.
LABUSA provides secure retrieval design as a scoped engagement, usually starting from the sources you already intend to index. Get in touch to discuss it.
Sources and further reading
- OWASP GenAI Security Project, OWASP Top 10 for LLM Applications, 2025. Includes LLM01 Prompt Injection, LLM04 Data and Model Poisoning, LLM05 Improper Output Handling and LLM08 Vector and Embedding Weaknesses. Community security guidance, authoritative on threats rather than on regulatory obligation.
- National Institute of Standards and Technology, Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Revision 5.
- National Institute of Standards and Technology, Zero Trust Architecture, SP 800-207, August 2020.
- MITRE, ATLAS, a knowledge base of adversary techniques against AI systems.
Every source above was opened and read on 20 August 2026.