SharePoint permissions and AI answers after indexing: a guard asleep with an old sealed list while a new notice goes up at the gate

Sometimes, yes. If the AI tool’s index stores its own copy of each document’s permission list, a removal on a library or folder can stay invisible to it until that copy is refreshed; Microsoft documents this for a preview feature of Azure AI Search. If the tool asks Microsoft 365 at question time, as the person asking, the answer follows current permissions, at the price of extra calls on every question.

Does an AI index keep its own copy of SharePoint permissions?

Every assistant that answers from SharePoint works from an index: a copy of your documents, split into passages. The question is whether that copy also holds the answer to “who may see this”.

Some designs store exactly that. Azure AI Search offers a SharePoint indexer with permission metadata ingestion, a preview feature of Azure AI Search, not of Microsoft Copilot.^[1] Its documentation says the indexer “stores the permissions as metadata on each indexed document” and that “at query time, users receive only documents they have permission to access”.^[1]

During ingestion the indexer “computes the effective ACL for each file” and stores the allowed user and group identifiers next to its text.^[1] At question time the search engine matches the asking person’s identity and groups against that stored list.^[2]

It is a legitimate design with one structural property: the stored list is a snapshot, and a snapshot has a date.

Which permission changes reach the index, and which do not?

Microsoft is precise: “Starting in the 2026-05-01-preview REST API, ACL changes for items with unique permissions are detected and refreshed on each successful indexer run.”^[1]

The person’s side is fresh too: Microsoft Entra group memberships are resolved through Microsoft Graph at query time, and the same preview API resolves SharePoint site groups at query time.^[2] Removing someone from a group does not wait for an indexer run.^[2]

The gap is narrower than “stale” suggests and has two named parts. The first is inheritance: “Parent-scope permission changes aren’t picked up automatically on subsequent indexer runs.”^[1] A change to what a site, library, list or folder grants, inherited by the files beneath it, waits for a resync, a document reset or an edit to the file itself.^[1]

Inheritance is the SharePoint default: sites, lists and libraries “inherit permissions settings from the site that is directly above them”.^[3] Removing a person or a group from a library is a parent-scope change.^[1]

The second is process. Microsoft’s warning is literal: “If you change SharePoint permissions without triggering an update mechanism, the index serves stale ACL data for previously ingested files.”^[1] The resync has to be triggered deliberately; changing a library’s permissions does not trigger it.^[1]

The preview also leaves out parts of the model: sharing links scoped to “Anyone” or “People in your organization”, and guest users, are not supported.^[1] For “the full SharePoint permissions model” the page points to a remote SharePoint knowledge source that “calls SharePoint directly via the Copilot retrieval API”.^[1]

What changes when permissions are checked at question time?

The other design keeps no permission list in the index. Permission trimming happens at question time: the tool takes the ranked candidate documents and asks Microsoft 365, for each one, whether this person may open it now.

The check runs as the person and sees only what they could open. In the OAuth 2.0 on-behalf-of flow “the intent is to pass a user’s identity and permissions through the request chain”, using delegated scopes only.^[4] Microsoft Graph documentation adds: in delegated access “the application can’t access anything the signed-in user couldn’t access”.^[5]

By contrast, ACL ingestion in Azure AI Search “requires application permissions. Delegated permissions aren’t supported.” An application permission such as Files.Read.All “can read any file in the organization”.^[5] The indexer reads as an application, not as the person asking. With a live check there is no copy to refresh.

Whatever its internal design, Microsoft Copilot states the outcome: it “only surfaces organizational data to which individual users have at least view permissions”.^[6] An assistant you run alongside it should state its rule as plainly.

What does a live check cost?

The first cost is time. Every question produces extra Microsoft Graph calls, so the check has to be limited to the documents that can reach the answer, and bounded.

The second cost is behaviour under failure. If Microsoft Graph is slow or returns an error for a document, a strict design leaves that document out: a thinner answer, possibly without the document that mattered most.

Azure AI Search also fails closed, for the whole query: “If ACL evaluation fails (for example, the Graph API is unavailable), the service returns 5xx and does not return a partially filtered result set.”^[2]

Neither design repairs permissions that are too wide. Microsoft’s deployment guidance for Microsoft Copilot starts with “remediating oversharing”, and its semantic index page says that “indexing data doesn’t change access permissions to content”.^[7]^[8] A live check enforces today’s permissions, wide or narrow.

Check it in your tenant

An afternoon’s work, no vendor needed, plus indexing time:

In a library the assistant already indexes, create a test folder and grant a test person permission on it directly, by name: no group, no single-file share. Use a person with no other access to that site.
Then add one document that answers a specific question, for example a fictional payment term. After the next indexing run, ask the question as that person and confirm the document appears in the answer or its sources.
Remove that person’s permission on the folder itself, without editing the file. The file’s own permissions do not change, only what it inherits: the parent-scope case.
Wait for the next indexing run, or longer than the refresh interval your vendor states.
Ask again as the same person, in a new chat, after checking that SharePoint now refuses them the file. If the document still appears, the assistant is most likely serving a stored permission list that nobody refreshed. If it is gone, note how long that took and whether anyone had to run anything.

Removing the person from a group tests a different path: in the Azure AI Search design, group membership is resolved at query time.^[2] The folder test separates the two designs.

What we do not know

We read Microsoft’s pages on 4 November 2026. The Azure AI Search feature is a preview; such features “might change or be constrained before they become generally available”, so the gap described here may close.^[1]

We do not know how other tools handle these cases. A product page that claims to respect your permissions can mean a stored list, a live check, or both. The test above shows which you have.

For Microsoft Copilot, Microsoft documents the outcome, at least view permissions, and when content is indexed.^[6]^[8] We found no Microsoft documentation describing how a permission change moves through that index, and we do not speculate.

For our own design the limit is availability: when Microsoft Graph does not answer, fewer documents reach the answer.

How KSJ does it

Answergrove uses the second design. Our index stores no permission lists. When a person asks, each document that can reach the answer is checked live in Microsoft Graph with that person’s own token; the API acts on behalf of the signed-in user.

Only a clear yes from Microsoft Graph lets a document through. An error, a timeout or no answer means the document is left out.

Only the ranked results are checked, several in parallel, each with a time limit.

The order matters: before the check, the ranking step sees file names and the beginning of the text of candidate passages, and the answering model can see the names of indexed sites. The check happens before anything is shown to the person and before the answering model sees any document text.

In our demo environment (sample company Contoso, measured September 2026), two people asked the same question about the payment terms in a subcontractor framework agreement.

Anne, with access to the contracts library, got the agreement as the source, with pages and version 1.0. Maria, without access, got no answer from that document. This shows the check, not a change over time.

The cost is the one above: extra Microsoft Graph calls at question time, and a relevant document left out rather than shown when Graph is slow or fails. More on how Answergrove checks permissions.

Drafted with AI assistance, checked against the cited Microsoft sources and approved by Kaspars Jurjāns.

References

^ a b c d e f g h i j k l “Use a SharePoint Indexer to Ingest Permission Metadata – Azure AI Search”. Microsoft Learn. Retrieved 4 November 2026.
^ a b c d e “Query-Time ACL and RBAC Enforcement – Azure AI Search”. Microsoft Learn. Retrieved 4 November 2026.
^ a “Customize permissions for a SharePoint list or library”. Microsoft Support. Retrieved 4 November 2026.
^ a “Microsoft identity platform and OAuth2.0 On-Behalf-Of flow – Microsoft identity platform”. Microsoft Learn. Retrieved 4 November 2026.
^ a b “Overview of Microsoft Graph permissions – Microsoft Graph”. Microsoft Learn. Retrieved 4 November 2026.
^ a b “Data, Privacy, and Security for Microsoft Copilot”. Microsoft Learn. Retrieved 4 November 2026.
^ a “Secure & Governed Data Foundation for Microsoft Copilot – Foundational Deployment Guidance”. Microsoft Learn. Retrieved 4 November 2026.
^ a b “Semantic indexing for Microsoft Copilot”. Microsoft Learn. Retrieved 4 November 2026.

What Happens to AI Answers When SharePoint Permissions Change After Indexing?

Contents