A retrieval-augmented generation assistant should retrieve only material the current user is authorised to use. Agree that boundary before connecting documents. Relevant search results, convincing answers and a prompt asking the model to keep secrets do not establish that the underlying access decision is correct.
For a business buyer, the practical task is to define identities, document permissions, permission changes and acceptance evidence. The implementation team then needs to show how those decisions are enforced across retrieval, answers and supporting links.
Define whose documents the assistant may use
Identify the intended users and the knowledge sources. A public help assistant has a different boundary from an internal assistant searching project records. Within an internal system, staff may belong to different teams, customer accounts or temporary projects. “Employee” alone may be insufficient to decide access.
Place retrieval permissions within the wider AI integration strategy for existing business software.
Name the system that owns each permission. A document platform may control group membership, while a business application owns account assignments. If those policies overlap, decide how the assistant obtains the effective decision and what happens when policy information is unavailable.
Also distinguish access to the assistant from access to its sources. Being permitted to open a chat window does not grant permission to every indexed document. Likewise, permission to search a document does not necessarily authorise an unrelated tool action suggested by its contents.
OWASP's authorisation guidance provides a general basis for explicit access decisions. For this project, turn the organisation's real policy into requirements rather than relying on a role name or an instruction embedded in a prompt.
Carry access decisions into retrieval
Ask where unauthorised material is excluded. If the system retrieves restricted passages and sends them to the model before attempting to remove sensitive text from the final answer, the boundary has already been crossed within that processing path. Define which components may receive the material.
Relevance is not permission
A search score indicates a relationship to the question. It does not establish the user's entitlement to the source. The retrieval request needs an identity and a policy context that cannot simply be replaced by text supplied in the conversation.
Supabase's RAG permissions guide demonstrates retrieval constrained through document permissions using its row-level security approach. That is one implementation example. Other architectures need their own enforcement design and evidence; copying a filter label does not establish equivalent protection.
Metadata must reflect the real policy
Chunks, attachments and derived summaries need a traceable relationship to their source and permissions. Decide how a restricted section is represented when a larger document is broadly shared. A single “public” label copied from the wrong level can lose the distinction the source system intended.
Require a defined response to missing or conflicting policy data. Withholding affected material and routing the problem for investigation can be an explicit product decision. Silently treating unknown access as permission leaves the behaviour difficult to review.
Plan for permission changes and stale copies
Access changes after indexing. People leave teams, documents move and sharing settings are corrected. Record how the assistant learns about these changes, which copies it holds and how the team measures or investigates delays.
Assign ownership of identities and permission changes when integrating source systems with the assistant.
Include answer caches, saved conversations, generated summaries and search snippets. A fresh retrieval check does not by itself explain whether yesterday's answer remains visible after permission is revoked. Decide the intended behaviour for each retained surface and have the responsible owners review it.
Citations create another path to inspect. Their titles or previews can reveal information even when the destination refuses access. Check what a user sees in the answer and what happens when they follow the link using their own identity.
Record the consequences of a failed permission update. The operating team needs an owner, evidence and a way to restrict affected functionality while investigating. A periodic synchronisation schedule is useful context, but it does not answer every access-change case.
Write an access-change acceptance matrix
The following fictional cases are planning aids, not tests performed against a deployed assistant. Assume project documents and HR documents have distinct owners and permissions.
| Situation | Expected decision to define | Evidence to inspect |
|---|---|---|
| Two users ask the same project question | Each receives information only from their permitted sources | Identity, retrieval decisions and answer citations for each user |
| A user loses project access | New requests follow the changed policy; retained answers follow the agreed rule | Source change, index state and cache behaviour |
| A document moves into a restricted team | Derived copies acquire the intended restriction | Source identity, permission mapping and retrieved chunks |
| Permission metadata is missing | The defined withholding or review path is used | Decision reason and responsible owner |
Add negative cases deliberately. Ask for a restricted document by title, refer to it indirectly and repeat a question another user was allowed to answer. The expected result depends on the real policy, including whether acknowledging the document's existence is itself appropriate.
Keep test material fictional or appropriately controlled. The purpose is to inspect the enforcement path, not to expose real confidential passages in a shared test report. Record limitations when an environment cannot reproduce the actual identity or document structure.
Review answers, citations and operational access separately
An answer may be accurate yet unauthorised, or authorised yet inaccurate. Review these as separate dimensions. Good answer quality cannot compensate for retrieving a document the user should not receive.
Operational access also needs a decision. Administrators, support staff, logs and diagnostic tools can see different parts of the processing chain. Identify which roles may inspect prompts, retrieved text and stored answers, and how those powers are granted and removed.
Ask reviewers to preserve the reason for each failed case. Wrong group mapping, stale metadata, an over-broad retrieval request and an inappropriate citation preview lead to different corrections. A single “security failed” score gives the delivery team little direction.
This matrix contributes to acceptance planning. It does not replace a technical security assessment or demonstrate that every possible disclosure has been prevented. The evidence must match the architecture and actual deployment boundary.
Include an attachment case in the fictional matrix. A broadly shared project page links to a restricted staffing attachment. Ask whether the index stores them as distinct sources and how their policies are evaluated. The page's visibility should not silently become the attachment's policy. Inspect any generated summary that combines them as well. This makes the acceptance question concrete without assuming one chunking method or storage product is universally appropriate.
Agree the boundary before adding internal AI search
Bring document owners, identity administrators and the delivery team into the same review. They should be able to explain who may search each source, how a change propagates and who investigates an uncertain decision.
The resulting requirements should name the policy source, retrieval boundary, retained surfaces, access-change cases and acceptance owners. That gives a proposed assistant a reviewable scope before expanding its knowledge sources.
Discuss the document boundaries for internal generative AI search with ZakCodeX before connecting a knowledge source.
