A marketer asks an internal AI assistant to draft a landing page. It finds the brand guidelines, checks the product documentation and produces copy that follows the company’s tone of voice.
That is a useful application of retrieval-augmented generation, or RAG. Instead of relying only on what a large language model learnt during training, the application retrieves relevant material from a knowledge base and supplies it to the model as context.
For a company, the appeal is practical. Existing documents can support an assistant without retraining the model whenever a product changes. A focused prototype can be relatively quick to build, especially when the documents are already organised.
But the same convenience raises a question that should come before opening the assistant to everyone: whose documents is it allowed to search?
I am not a security expert, and this post should not be taken as security advice. I am sharing an access-control consideration from an applied AI perspective, not a complete security design. If you are building this for production, involve your security team or a qualified security professional.
Internal does not mean available to everyone
Imagine that the knowledge base contains approved brand guidelines, current product specifications and a confidential plan for a product that has not been announced.
The marketer needs the first two to write the landing page. That does not automatically mean they should see the third.
In the original document system, those files might have different permissions. Copying their contents into a shared search index does not automatically preserve those boundaries. Without permission-aware retrieval, an assistant could find restricted material and include it in an otherwise ordinary answer.
The user would not necessarily need to ask for the confidential document by name. “What product features should I highlight?” could be enough to retrieve relevant passages.
The problem is not that the answer is inaccurate. It might be entirely accurate, but based on information that person was never entitled to read.
A login is only the first step
This is why I would start with authentication, but would not stop there.
Authentication answers “Who are you?” Authorisation answers “What are you allowed to access?”
A company login can establish that someone is an employee. It does not establish that every employee can read every internal document.
The application needs to carry the user’s verified identity into the retrieval process and apply the relevant permissions. The assistant’s service account might be able to read the whole search index, but that should not become every user’s access level.
For the landing-page assistant, that means searching the approved material available to the marketer, rather than searching everything the assistant can read.
Different vector stores can help, but they are not the permission system
One approach is to separate information into different vector stores, indexes or namespaces. Approved marketing material could sit apart from confidential product planning.
That can make the boundaries clearer. However, separation only helps if the application enforces who can search each collection. If anyone can ask the assistant to switch to the restricted store, the boundary is only a label.
A shared store can also support access control when documents and their searchable chunks carry permission information and retrieval enforces it. Separate stores are one design option, not a universal requirement.
I would therefore discuss the access policy with the security team before deciding how many vector stores to create. The storage structure should support the permissions, rather than become a substitute for them.
Keep restricted information out of the model’s context
The principle I would take into that discussion is straightforward: check permissions before retrieved text reaches the model.
I would not retrieve every relevant document and then ask the LLM to avoid revealing the confidential parts. That gives the model information the user should not have, and makes the prompt responsible for protecting it.
The design approach I would discuss with a security team is to verify the user, establish their current permissions, retrieve only authorised material and then generate the answer. Those checks belong in the application and retrieval system, rather than being left to the model’s judgement.
That discussion should also cover supporting material. An answer that refuses to disclose a document but exposes its contents through a citation, preview or downloadable attachment has not respected the boundary.
Permissions need maintenance too
Access control is not finished when the first version launches.
People change teams. Contractors finish assignments. Documents become restricted or are withdrawn. The knowledge base needs to reflect those changes, not just the permissions that existed when the files were first imported.
If permissions are copied into an index, changes in the source system need to be synchronised. Otherwise, the assistant may continue using an outdated view of who can read what.
I would want the security and engineering teams to test different user accounts asking the same question. Can the authorised user retrieve the relevant information? Is the unauthorised user prevented from receiving it? What happens after access is revoked? Does a follow-up question or cached answer reveal something the first response correctly withheld?
Those are questions to include in a production review, not a complete security checklist.
A useful answer still needs an access boundary
RAG can make company knowledge easier to use. The landing-page example is valuable precisely because it brings brand guidance and product information into a workflow where someone needs them.
But easier access should not mean broader permission.
Before asking how well an internal assistant answers questions, I would ask whether it knows who is asking and whether its retrieval respects what that person is allowed to read.
The assistant should make authorised knowledge easier to use, without making restricted knowledge easier to obtain.
