How to make an AI assistant respect who may see what.

Before launch, someone in security will ask the right question: could an employee type “what are the salary bands for managers?” and get an answer? If the salary-band document is in the assistant’s index and nothing checks who is asking, the answer is yes, and it comes with a helpful citation.

The rule is easy to state. An assistant must never become a way around your permissions: a person gets answers only from documents they could open themselves, in the source system, at the moment they ask. Making that true takes three things: enforce access at retrieval time using the source system’s own rules, keep those rules in sync, and test with real personas, including people who just lost access.

How can an AI assistant leak information between colleagues?

Through the front door and through side doors:

• One all-seeing index. Documents indexed with a service account that can read everything, and no filter at query time.
• Permissions copied once. Right on the day of indexing, wrong after the first reorganization.
• Filtering after the answer. The model already read the restricted passage; hiding the citation doesn’t remove what the answer says.
• Shared caches. An answer cached for a manager and served to an employee who asked something similar.
• Conversations and logs. Histories visible to colleagues, and logs of prompts and passages readable by more people than the documents were.
• Over-shared sources. Files open to “everyone” that nobody could find before; the assistant makes them findable in seconds.

The last one isn’t the assistant’s bug, but it becomes the assistant’s incident.

The assistant must never become a way around your permissions.

Where should permissions be enforced?

At retrieval, before the model sees any text. RAG, explained for business teams shows where that step sits.

1. Store access with every passage. At indexing, each passage carries its document’s access list from the source system: a SharePoint site, a Google Drive folder or a document management system, for example.
2. Resolve the user at question time. Identity and group memberships come from your identity provider when the question is asked, nested groups included.
3. Filter inside the search. Only passages whose access list includes the user or one of their groups are searched at all. A filter applied after ranking can still leak through result counts or suggestions.
4. Re-check sensitive sets at the source. For the most sensitive documents, check the final few passages against the source system’s live permissions before they reach the model. Slower, but always current.

Done when: a user without access gets “no source found”, with no hint that a restricted document exists. What goes wrong: nested groups left unresolved, “anyone with the link” sharing treated as access, and individual exceptions ignored.

How do you keep permissions in sync with source systems?

Sync lag is the gap between a change in the source and its effect on answers. Someone who lost access yesterday must not see the document today.

• Sync sharing changes, not just content changes. A pipeline that re-indexes only when a file’s content changes never notices that its sharing did.
• Use change events where the source offers them, plus a scheduled full reconciliation to catch what events missed.
• Handle leavers and movers. A group removal must reach the assistant as fast as it reaches the file system.
• Remove deleted documents from the index in the same run.
• Agree on a maximum lag per document set with its owner, shorter for sensitive sets, and alert when it is exceeded.

Done when: a removed permission stops affecting answers within the agreed window, and the lag is measured, not assumed. What goes wrong: sync jobs that fail silently and leave the index days behind.

What about summaries, caches and logs?

Every copy of content needs the same rule as the original.

• Caches are keyed by user or permission set, or switched off for restricted sets.
• Shared conversations re-check the recipient’s access, or drop restricted content.
• Summaries and extracted fields inherit the most restrictive permission of their sources. A digest of HR cases doesn’t belong in a folder the whole department can read.
• Logs keep the question, the passages and the answer, because diagnosis and audit need them (what an AI audit trail should record), but access is restricted, retention is agreed and personal data is masked where possible.
• The model provider’s side, meaning what it stores and for how long, belongs in the contract; where your data goes lists the questions.

Done when: every place content is copied is listed with its access rule. What goes wrong: a debug log switched on during the pilot and never switched off.

How do you test access control?

With persona tests: a test account for each role, and a list of what each should and shouldn’t retrieve.

Consider an illustrative case: an HR salary-band document that line managers can open and other employees can’t. The manager persona asks “what is the salary band for a senior analyst?” and gets an answer citing the document. The employee persona asks the same question, then variations: “what do senior analysts earn?”, “maaş bantları”, “summarize the HR policies folder”. Each gets “no source found”, with no mention that a relevant document exists, including when the employee asks straight after the manager, which proves the cache doesn’t carry the answer across. Finally, the manager persona is removed from the managers group and asks again after the agreed sync window: no answer.

These cases join the evaluation set and run after every change to the index, the sync or the prompts, in line with the access rules in our guardrails. Done when: every role has a persona with should-see and must-not-see lists, and the suite passes before launch.

What should you ask a vendor about it?

1. Where are permissions enforced: inside the search, before the model sees content?
2. Which access lists are read, including groups, nested groups and link sharing?
3. How quickly do permission changes and deletions take effect, and how is the lag monitored?
4. Are caches, shared conversations, summaries and logs permission-aware?
5. Who at the vendor can read prompts, passages and logs, and for how long are they kept?
6. Can we run our own persona tests and see the results?

A good answer comes with a number for the sync lag and a demonstration with your roles.

Start with the sensitive sets

List the three most sensitive document sets the assistant might reach and write down who may open each. That list is your first persona test. Permission-aware retrieval is a core part of our data and AI foundations work, and every knowledge and document intelligence system is built on it.

Sources

1. LLM08:2025 Vector and Embedding Weaknesses OWASP Gen AI Security Project genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses
2. LLM02:2025 Sensitive Information Disclosure OWASP Gen AI Security Project genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure