The same question can require different evidence
Two employees ask an internal AI assistant the same question: “What changed in the service process for this account?”
One belongs to the account team. The other can read the general service handbook but has no access to the account's private notes. A useful assistant may give them different answers. The second employee should receive the general process guidance without details drawn from the restricted record.
This hypothetical financial-services workflow exposes a product requirement that a polished demonstration can miss: a correct answer can still reach the wrong person.
Connecting an assistant to a document library does not, by itself, establish which parts each user may search. The application needs to preserve the source's access decisions through retrieval, generation, citations, and later reuse of the answer.
For teams expanding a pilot to more users, that boundary deserves as much attention as answer quality.
Establish access before assembling the answer
In a retrieval-based AI application, search finds relevant passages and supplies them to a model as context. Permission checks belong before ineligible passages enter that context. Hiding a citation after generation does not remove the information already used to write the response.
A practical request path is:
- Verify the user's identity on the server.
- Resolve the current organization, groups, and resource permissions relevant to the request.
- Apply those permissions to retrieval and validate eligible results before any model-based processing.
- Generate an answer from the permitted evidence.
- Apply the same boundary to citations, source previews, and downloads.
The browser can request an account or workspace, but the server must establish whether the user can access it. A group name supplied in a form field or prompt is not proof of membership.
Microsoft's Azure AI Search security-filter pattern illustrates filtering indexed documents by user or group identifiers. Its documentation also makes a critical distinction: those identifiers are strings used for matching; the filter itself does not authenticate the person supplying them. The surrounding application must provide trustworthy identity and permission context.
For a custom implementation, put that decision in a shared server-side path used by every retrieval entry point. Alternate search modes and follow-up questions need the same protection as the main search box.
Carry the source rules into the index
Indexing often splits one document into many passages. Each passage needs enough information to reconnect it to the source and its access policy.
For the account example, the general handbook and private service notes might share a search index. Their permissions should remain distinct even when their wording is similar. A relevant match is not an access grant.
Preserve stable source identifiers and the permission metadata required by the chosen authorization design. Handle missing or unresolvable permissions explicitly: hold the affected material out of retrieval until the system can establish who may use it. Do not quietly classify it as available to everyone.
The mapping deserves review with the source owner. A simple “employee” label may flatten distinctions between account teams, external partners, restricted folders, or individual records. If the source uses explicit denials or inherited permissions, an allow-list shortcut may not represent its actual rules.
Our guide to source-backed AI copilots explains why visible evidence matters to the user. That evidence is only useful when the application can also explain, internally, why this user was permitted to receive it.
Keep the scope manageable. One source with well-understood access rules is a stronger first release than several connectors whose permission behavior nobody owns.
Treat saved answers as another access surface
The retrieval check is only one part of the product.
Suppose an account-team member asks a question and receives a summary containing private notes. The application caches that answer under the question text. Later, someone outside the team asks the same question. Reusing the first answer would bypass an otherwise correct retrieval filter.
A cache therefore needs an authorization design, not just an expiration time. Its reuse rules must account for the requesting user or approved audience, the underlying sources, and relevant permission changes. A cache keyed by user alone can still serve stale access after that user's role changes.
The same issue applies to saved conversations, generated briefs, exports, and shared links. Record which sources contributed to an answer so the system can evaluate later access. If a summary combines several restricted sources, copying it into a broadly readable location can expose information from all of them.
Keep source previews inside the boundary
A citation title, snippet, or document thumbnail may itself disclose restricted information. Check these surfaces alongside the generated prose. Do not announce that a sensitive document exists to explain why it was excluded.
When accessible evidence is insufficient, say that the available sources do not support an answer. Offer an appropriate next step, such as contacting the workflow owner, without naming hidden records.
Make access changes part of normal operation
People change teams. Documents move. Account assignments end. Source permissions can change while the indexed text stays exactly the same.
Define how those changes reach retrieval, caches, and saved outputs. Depending on the platform, that may involve permission updates during indexing, live authorization checks, invalidation events, or a combination. Verify the mechanism instead of assuming a document-content sync also refreshes access.
OWASP's authorization guidance recommends denying access by default and validating permissions on every request. Applied to an AI product, that means an unavailable permission service should not silently turn a restricted search into an unrestricted one.
For the account-team example, test what happens when a user loses access after generating a summary. Decide how the application handles reopening that conversation, following its citations, and asking a follow-up that would reuse the old context. Define and measure the maximum propagation delay; a design with a delayed update should not be described as immediate revocation.
Access changes can govern future requests and displays. They cannot retract information someone already read or downloaded. That limit should inform which content the product allows people to export in the first place.
Release against a permission test set
A useful acceptance test checks both sides of the boundary: permitted users can complete their work, and other users cannot obtain restricted material.
Extend the AI evaluation layer with a small set of synthetic documents and named test identities. Include:
- The same question from two users with different source access.
- A request that substitutes another account or organization's identifier.
- A document whose text stays unchanged while its permissions change.
- An answer served from a cache created before access was revoked.
- A reopened conversation and follow-up using previously available evidence.
- A missing permission record or unavailable authorization service.
- A permitted user who should receive a useful answer with working citations.
Inspect the retrieved passages and model context as well as the visible response. A model declining to answer does not prove that retrieval respected the boundary. Use controlled fixtures for these checks, and protect diagnostic traces that may contain source content.
Treat an unauthorized disclosure as a release-blocking failure. Track retrieval usefulness separately so a system that refuses every request cannot appear successful.
For custom AI applications, permissions are part of the product's behavior from the first source connection through ongoing use. A dependable answer needs both relevant evidence and a justified audience.
If your team is moving an internal assistant beyond its pilot group, Start a Project to map the source permissions, saved-output behavior, and release checks before expanding access.
