A RAG application can bring information from several environments together. That makes the distinction between permission to ingest, permission to search and permission to receive information essential. A connector with broad reading access does not establish that every employee may see every retrieved passage. Even a brief answer or document title may reveal information outside a particular user’s entitlement.
This guide prepares an access model for a bounded knowledge application. Its examples are illustrative, not completed security tests. The technical measures needed depend on users, sources, integrations and the consequences of an incorrect access decision.
Describe users and information boundaries
Start with roles that colleagues recognise in their work: an employee, team administrator or external customer user. Then describe the information each role needs for a particular task. A role list alone is insufficient when the same role exists within several customers or branches. Organisation and record boundaries must then be defined separately from the person’s job title.
An illustrative consultancy manages documents for multiple clients. Two project employees have the same title but may access different files. Searching with identical words should therefore not necessarily produce identical passages. Use these distinctions as concrete design examples. They reveal the trusted context the application needs before selecting information and make the required boundary understandable to the operational owner.
Distinguish connector access from user entitlement
A technical connection may be authorised to process a document collection. That permission serves a different purpose from an end user’s right to read a particular source. Record both independently. Otherwise a broad import may quietly become broad disclosure once the application starts producing answers from all the content available to its background connection.
For every connector, ask how original permissions are obtained and how changes propagate. Some sources may require additional registration or application-defined selection. Do not assume existing permissions transfer automatically without testing the chosen source and platform combination. The proposal should distinguish enforced behaviour, matters still under investigation and sources that remain excluded until an appropriate boundary is demonstrated.
Select permitted sources before answer generation
Design retrieval so it returns only passages permitted for the established user and task. Telling a model not to reveal confidential information is not a replacement for that selection. If forbidden content has already entered the answer context, an important part of the intended information boundary has already been crossed before the model produces its visible response.
The check must also be independent of how a question is phrased. Naming another person, organisation or document reference in a query does not grant additional access. The application should establish the relevant identity and context through a trusted route. Decide what happens when that information is missing, ambiguous or temporarily unavailable, rather than allowing the question text to fill the gap.
When access comes through a portal, organisation and record boundaries matter. This guide examines those limits: Customer portal roles and permissions: who may use which record?.
OWASP: Authorization Cheat Sheet ↗OWASP GenAI: Prompt Injection ↗
Apply the same boundary to citations
An answer may look appropriately limited while a citation, title or preview reveals another customer’s information. Assess the complete visible response: quoted passages, page references, labels, proposed follow-up questions and notices describing documents that were or were not found. Each may disclose more than a review focused exclusively on the main answer text would notice.
Test opening the source too. Linking a permitted passage to an unsecured document copy defeats the earlier control. If a link leads into the original source system, that destination needs to preserve suitable access checks. The interface should explain that a source cannot be opened when necessary without simultaneously revealing details from material the user was not entitled to receive.
Keep conversations and caches in context
Caching may improve response time, but reuse must respect the information boundary. Two users asking the same question may have different permitted sources. A cache keyed only by question text may return an answer prepared under somebody else’s permissions. Agree which user, organisation and source-version context reuse requires and when stored material must become invalid.
Conversation history also matters. An employee may switch client files or share a conversation with a colleague. Investigate which earlier passages remain available after that transition. The goal is not necessarily to discard every history, but to make a deliberate rule for reuse, sharing and expiry. Implement that rule in the application and test realistic transitions rather than only a fresh, isolated question.
Treat revocation as normal operation
Permissions change when employees move teams, external users leave a project or a source temporarily becomes restricted. Specify how quickly each change must affect retrieval, answers and stored material. Access that is correct during initial ingestion is not enough for an application employees depend on every day while the underlying organisation continues to change.
Prepare a test in which a user initially has access and later loses it. Check new questions, old citation links and any answer reuse. Distinguish immediate revocation from changes delayed by synchronisation. If the available mechanism cannot meet the required timing, the design needs another boundary or a temporary block instead of an unsupported promise that access disappears immediately everywhere.
Use a focused matrix with negative cases
Build a small pilot matrix covering user, source area and operation. Record not only what is allowed but also what must be refused. An external user might read a project handbook but not internal evaluation notes. Try the same question in both roles, using ordinary wording and a direct reference to the document the external user must not receive.
Add an unknown user and an unavailable permission source. A useful evaluation examines behaviour when context is missing as well as normal successful access. Keep expected boundaries and observed outcomes as repeatable cases. A later connector or index change can then be checked against the same agreement rather than judged only through a few convenient demonstrations of permitted information.
Limit diagnostic data and access to it
A source reference, task context and failure category may be more useful for investigation than a full copy of every conversation. Decide what information is necessary to diagnose an access problem and who may read those records. Otherwise an appropriately bounded user interface may still create an overly broad collection of sensitive information in its diagnostic environment.
Make investigation practical with recognisable references and a responsible person. A report that a source was wrongly available should lead to temporary containment, focused investigation and another check. Tell users how to report a problem. Technical controls without an accessible owner leave uncertainty about who can intervene when the observed behaviour differs from the intended boundary.
Deliver evidence of the access design
A useful handover includes the user matrix, identity context, selection rules, revocation arrangements and results from the agreed tests. Distinguish demonstrated behaviour from areas requiring further investigation. A successful set of pilot cases is not evidence that every possible attack, connector combination or future permission change has already been covered by a complete security assessment.
Reassess when adding source areas, external users or another way to share answers. These changes may alter the information boundary even if the chat interface looks unchanged. Treating permissions as a maintained part of the application makes expansion a deliberate project decision, supported by reviewable arrangements about which company information each participant may use.
Turn the explanation into a project decision
Record your assumptions, unknowns and acceptance checks in the matching tool. Use the service guides to discuss delivery and scope.
Open the preparation tool ↗Questions about this topic
Does RAG automatically inherit SharePoint or other source permissions?
Do not assume that without investigation. Capabilities depend on the connector, platform and configuration. Check which permissions are processed, how updates propagate and what additional controls the application must implement.
Is a system instruction enough to hide confidential passages?
No. The design must keep unauthorised source material outside the relevant retrieval and answer context. Instructions may provide additional behavioural guidance, but they do not replace technical authorisation or suitable limits on source connections.
How can we test the boundary?
Ask the same questions under different roles and organisations. Include forbidden documents, revoked access, unknown users, old links and caches. Keep expected outcomes and observed behaviour so later changes can be checked against the same cases.
Continue with a related question
Prepare company documents for RAG: build a managed source collection
Make documents useful for a RAG trial through ownership, validity, structure, removal rules and representative checks.
RAG & business knowledgeTest a RAG system: assess sources, answers and refusals separately
Build a useful RAG evaluation with representative questions, expected passages, permission cases, clear criteria and repeatable comparisons.
Custom software & portalsCustomer portal roles and permissions: who may use which record?
Define portal access by organisation, record, operation and field, including invitations, downloads, role changes and meaningful denial tests.
Sources and technical background
- OWASP: Authorization Cheat Sheet ↗
Authorisation principles; the worked evaluation cases are illustrative.
- OWASP GenAI: Prompt Injection ↗
Risk of misleading instructions in input and retrieved sources.