Official documentation checked October 14, 2026.
If Microsoft 365 Copilot still shows a SharePoint item after a permission change, do not assume that a full search crawl is the solution. An old conversation, a stale result, another access grant, and a newly generated disclosure are different situations. First establish what the affected user can access now.
If a fresh response reveals information the user should no longer receive, involve your security team promptly. Do not treat a guessed 15-minute or 24-hour propagation window as permission to leave a suspected exposure uninvestigated.
1. Separate historical output from current access and retrieval
Record when permissions changed, which file or site was involved, which access path was removed, and the affected user’s account. Preserve relevant evidence through the approved incident process; do not delete the conversation or repeatedly paste sensitive text into new prompts.
- Existing conversation: determine whether the visible answer was generated before the change. Removing access to a source is not a request to erase earlier conversation content or exported copies. Copilot interaction data has its own storage and retention behavior.
- Current document access: have the affected user test the exact source URL using the intended work account. Record whether the document opens or denies access. Do not use an administrator’s session or share the user’s credentials.
- New retrieval: under the security team’s direction, compare a fresh conversation and current search results. Identify whether the result is only a title or link, or whether new restricted content is returned. Even a title may itself be sensitive.
For a controlled reproduction, use an approved test file containing a harmless unique phrase. Establish the allowed-user result, make the authorized test permission change, then repeat with the same test user. Avoid using payroll, credentials, or customer records to prove the point.
Keep timestamps and screenshots or sanitized response excerpts. If current direct access is denied but a new answer appears to disclose restricted source content, report the contradiction with evidence rather than explaining it away as normal cache behavior.
2. Verify every effective access path and the control actually changed
Removing someone from one site group may leave access through a different group, a direct file grant, a sharing link, or an inherited folder permission. Ask the owner to examine the exact item, not just the site’s main membership list.
In the library, select the item and review Manage access. Trace both people/groups and links, including inheritance. Microsoft’s permission-management guidance explains why direct access and link-based access must be reviewed separately. Remove only the unintended access path with owner approval, then verify that authorized colleagues retain their required access.
Check the real identity and group membership with the relevant administrator. A similarly named account, a second signed-in organization, or a remaining group grant can invalidate a test. Record the actual change and its time; do not remove and re-add memberships repeatedly to “refresh” the index.
Also distinguish permission changes from discovery settings. Restricted Content Discovery limits discovery but does not revoke access or remove indexed content. Its processing time varies with the site and workload. A user who remains authorized may still open a direct link; this is not proof that the file’s permissions were ignored.
Do not use a discovery restriction as the sole containment measure for an unauthorized access problem. The security and content owners must determine the appropriate access correction and incident response. Removing labels, restoring broad inheritance, or deleting content is not a diagnostic shortcut.
3. Use reindexing only for an established search-index requirement
Microsoft documents manual reindexing primarily for changes such as search-schema or managed-property updates. It is not a documented guarantee that forcing a crawl will revoke access, clear chat history, or repair a fresh unauthorized response.
If the investigation establishes a relevant search-schema issue, an authorized owner can follow the official reindexing procedure. For an affected library, open its settings, then Advanced settings, and request Reindex Document Library. For a justified site-wide request, use the site’s Site settings > Search and offline availability > Reindex site. Some modern sites expose Site settings through Site information > View all site settings.
The request marks content for the next scheduled crawl; it does not supply an immediate completion time. Prefer the smallest justified scope and avoid repeated requests, which can burden search processing. There is no general-purpose Request-SPOPersonalSiteReindex or Get-SPOSiteSearchIndexState procedure in that Microsoft guidance.
If permissions appear correct but the unexpected result persists, open a support case through your administrator. Supply the affected experience, exact resource, current access result, change timestamp, fresh-response timestamp, and the steps already taken. Share sensitive evidence only through the approved secure channel.
Close the investigation only after the intended access boundary is verified with the affected user and an authorized control user. A disappearing search result alone is not proof of revoked access, and a past answer remaining visible is not proof of a new unauthorized read.