An internal AI assistant should retrieve only documents the current user is allowed to access, with permission checks enforced by the application and source systems—not by a prompt. Before expanding access, identify which system owns each permission, how changes are reflected, and what the assistant does when those checks fail. The core decision is whether access can be verified for every document the assistant may use.
The assistant must enforce the source system’s permissions
An internal AI assistant should only retrieve and use documents the requesting person is authorized to see. The safest design treats access control as a requirement of every retrieval, not as a prompt asking the AI to avoid sensitive material. A model can generate an answer from content it has already received; it cannot reliably enforce permissions that the application never checked.
Start by identifying the authoritative source for identity and access: for example, a document repository, a business application, or a managed group directory. Decide how the assistant will establish who is asking and whether that person can access each document. If access rules cannot be checked consistently, limit the assistant to a deliberately approved document collection rather than indexing everything.
Map permissions before loading documents
Make an inventory of the sources, document types, and access rules in scope. Permission models often differ: one source may use groups, another individual sharing, and another inherited access from a folder. Record who owns each source and how quickly changes such as a staff departure or group removal are reflected.
Then choose a retrieval design. One option is to filter eligible documents for the signed-in user before searching. Another is to search broadly and check each candidate against the source system before using it. Either approach needs a dependable identity link and a defined response when permission information is missing or cannot be confirmed. Do not assume that copying files into an AI index carries their original permissions with them.
Protect the whole answer path, not just search
Access can leak at several stages: search results, document excerpts, citations, generated answers, conversation history, cached responses, and diagnostic logs. A citation that exposes a restricted file name or a preview containing a sensitive passage is still a disclosure, even if the final answer omits the details.
Keep authorization checks close to retrieval and apply them before content is sent to the model. Partition or filter caches by the user’s effective permissions, and avoid reusing an answer across users unless its source material is safe for both. Set retention and access rules for prompts and logs too; operational records can contain more than teams expect.
Plan for changing access and service failures
Permissions change. A person may lose access while an index, cached result, or group-membership record remains out of date. Define how updates are detected and propagated, and decide what “fresh enough” means for the sensitivity of the documents. For particularly sensitive material, checking current access against the source at retrieval time is generally safer than relying only on a periodically refreshed index.
Also define failure behavior. If the identity provider or permission service is unavailable, the assistant should not silently fall back to unrestricted search. It can pause retrieval, ask the user to try later, or use only a separate collection whose access can still be verified. Log the failure in a way that helps an operator investigate without storing unnecessary document contents.
Test with real permission boundaries
Testing only with an administrator proves little about ordinary users. Use test accounts representing different roles and access patterns. Include documents shared directly with one person, inherited from a group, removed from a group, and recently updated. Ask questions whose answers would reveal the protected content, then inspect not only the response but also citations, previews, conversation history, and logs.
Test negative cases explicitly: a user who should not see a document must not retrieve it indirectly through a summary, paraphrase, or cached answer. Test permission-service outages and changes made during an active session. Keep the test cases with the system’s operational documentation so that changes to connectors, indexing, or identity handling can be checked before release.
When a broad internal assistant is unnecessary
A general assistant may be unnecessary if staff only need search within one well-managed collection, or if existing business software already provides suitable permission-aware search. A narrower tool can be easier to govern: for example, an assistant limited to public procedures or a specific department’s approved reference material.
A practical next step is to select one document source and map its identity, permission, and update behavior before estimating a wider build. If the source cannot provide reliable access decisions, resolve that constraint first or keep it outside the assistant’s scope. The right boundary is the one the business can explain, test, and maintain.
Permission checks before launch
- List the document sources and the system that owns each user's access rights.
- Define how identity, group membership, and document permissions reach the assistant.
- Test allowed, denied, revoked, and newly granted access using separate test accounts.
- Verify that search results, citations, previews, cached content, and logs do not reveal restricted material.
- Choose a safe response for permission-service outages and stale access data.
- Assign owners for access changes, incident review, and recurring permission tests.
Questions about this approach
Can a system prompt prevent the assistant from revealing restricted files?
No. A model prompt can guide responses, but it is not an access-control mechanism. The application should check permissions before sending retrieved content to the model and should protect citations, caches, conversation history, and logs as well.
Is it enough to refresh document permissions on a schedule?
That depends on the sensitivity of the content and how quickly access changes must take effect. If a stale index could expose material after access is removed, verify current permissions during retrieval or use a tightly controlled refresh and revocation process that meets the business requirement.
What if a document source cannot report reliable permissions?
Use an intentionally limited collection with access rules you can reliably verify, or defer that source until its permission handling is understood. Do not treat missing identity or permission data as approval to search more broadly.
For help applying this approach, explore our custom AI projects services.
Discuss your project with Full Blown Studio
Tell us what needs to work better and what you have tried. Discuss your project, email bob@fullblown.com, or call (661) 429-0940.
