A company document assistant might answer a routine question correctly while showing information the person asking should never have received. Accuracy and access are separate requirements.
Consider a hypothetical design firm with shared project instructions, client-specific briefs, and internal staffing notes. Everyone needs the instructions. Only the assigned project team should read a particular client brief. The staffing notes have a smaller audience still. These are invented records, not a JTPCK client example.
Putting those files into one searchable collection should not flatten those distinctions. Before opening a RAG assistant to staff, we recommend walking through who can see each kind of information and how the product enforces that decision.
Start with an access list the business understands
Write down the audiences and document groups before choosing a model. For our design-firm example, a useful first list would be general staff, each project team, and the people responsible for staffing.
Then record a few concrete decisions. Can a contractor read the project brief? Can that person open the original attachment? What happens when the assignment ends? Ask the document owner to settle ambiguous cases before importing those files.
Signing in establishes identity; it does not establish permission to read everything. OWASP’s authorization guidance recommends denying access unless it is allowed and checking permissions on every request. Apply that principle to document previews and downloads as well as the chat screen.
For a first pilot, we would use only a clearly approved collection. Resolving a complicated permission model can take more work than answering questions from the documents.
Filter the evidence before the model sees it
The application needs to establish the signed-in user’s access before supplying document passages to the answer model. Asking the model to keep restricted text secret after giving it that text is an unreliable boundary.
Microsoft documents a search-filter pattern that matches user or group identifiers against identifiers stored with documents. It also makes an important distinction: those identifiers are strings in a filter, not proof of identity. The application must obtain the caller’s identity and permitted groups through a trusted path.
For our hypothetical firm, typing “I am on the project team” into a question should have no effect on access. Changing a project identifier in a request should not open another client’s brief either.
We recommend asking for a demonstration with two ordinary accounts. Run the same question under each account and inspect the actual passages supplied to the model, not only the final answer. A restricted passage that reaches the model but happens to be omitted from the answer is still a failed boundary.
Keep permissions attached when documents are split
A retrieval system often divides a document into smaller passages. Those passages still belong to the original document and need its access rules.
OWASP’s RAG guidance calls for access metadata on each chunk and checks at retrieval time. A successful permission check during the initial import is insufficient when access can change afterward.
In our example, a client brief might become ten searchable passages. We would expect all ten to remain associated with the same source and appropriate audience. A heading, extracted table, or short summary should not become generally available merely because it is stored separately.
Ask the implementer to trace one test file through the index. The useful evidence is a consistent connection among the original, its derived records, and the rules governing their use.
Check answers that were saved earlier
An assistant may save an answer so it can return it quickly later. That saved copy can contain restricted information even when the new request never searches the original document.
OWASP’s multi-tenant guidance describes cache isolation and authorization before reading protected cached values. Which user, organization, or permission context affects a result needs to be part of that design.
For our firm, a response prepared for the staffing manager must not become the answer to an identical question from a contractor. We would test this by asking the permitted account first, then asking the other account while the saved result is still available.
Include conversation links, exports, and source previews in the same walkthrough. A protected answer is not useful protection if its accompanying download opens for anyone with the URL. Decide whether shared answers may include restricted evidence before adding a convenient share button.
Test the moment access changes
Use synthetic documents and test accounts to rehearse a project reassignment. First confirm that an assigned person can retrieve the brief. Remove that access, then repeat the search and try the previously available preview and saved answer.
Check new requests and follow-up questions in an existing conversation. Record when the change becomes effective across each path. We recommend defining the acceptable delay and a way to block affected content if permission updates fail.
The test should also distinguish future access from information already delivered. Revoking access cannot recall a screenshot or an exported copy someone legitimately received earlier. Set expectations accordingly.
Our RAG maintenance guide covers the broader operational responsibilities. For permissions, the immediate deliverable is a repeatable check showing both allowed and denied behavior after a change.
Make the first rollout easy to inspect
A small review can use a shared instruction file, two project briefs with different audiences, and one restricted internal note. Give each synthetic file a distinctive phrase. Test ordinary questions, exact-title lookups, direct previews, repeated questions, and a removed team member.
Record the expected outcome before running each case. A denial should avoid revealing the restricted text or unnecessarily confirming a confidential document’s existence. An allowed request should still work, so security testing does not quietly become a test that everything is blocked.
Running the model locally does not decide which employee may read which record. That remains an application and business-policy decision.
We build retrieval, evaluation, and interfaces together. If you are planning a company assistant, tell us which groups need which documents. Start with the access boundaries and the work people need to do. If an existing document system already meets those needs, improving its search may be enough.