Copilot Cannot Read a SharePoint File: Check Access, Discovery, and Protection

Official documentation checked October 14, 2026.

Being able to open a SharePoint file does not guarantee that every Copilot feature can discover or process it. The failure can involve the account, the selected Copilot experience, search visibility, or a protection policy. Identify which layer fails before changing permissions.

This guide covers Microsoft 365 work or school accounts and SharePoint Online. A custom Copilot Studio agent or connector has its own configuration; do not apply app-registration instructions to the standard Microsoft 365 Copilot service.

Confirm the account, feature, and exact file

1. Open the original SharePoint file in the same browser profile used for Copilot. Check the signed-in work account and organization. Opening a downloaded copy, or opening the file as an administrator, does not verify the affected user’s current access.
2. Record the file URL, extension, modified date, Copilot app or agent, and exact error. Distinguish “cannot find the file,” “access denied,” and a response that cites the file but does not summarize it.
3. For work-data grounding in Copilot Chat, check the available controls and license. Microsoft’s current interface uses Work IQ, replacing the separate Work and Web tabs. Licensed users can check its button at the top left of Chat. Turning it on allows work context alongside attached content and permitted web information; it does not mean work-only answers.
4. In an approved work session, reference the existing file through the feature’s file picker or link support and request a summary of that specific document. Verify the citation points to the intended version. Do not download and re-upload protected material to get around a restriction.

Microsoft documents both the grounding controls and license-dependent availability. Work IQ being off does not prevent use of content explicitly attached to a prompt. If the control or file-reference option is absent, have IT confirm the supported experience for that account rather than assuming a permission grant is missing.

Separate search visibility from file permissions

With the affected account, search for the filename in the relevant site and in organization-wide search. Note which result is missing. Finding a document in one context does not prove another discovery experience must return it.

A site owner can inspect Site settings > Search and offline availability and the library’s Advanced settings search option. Site settings may be reached through Site information > View all site settings. These search-visibility controls govern indexing and results, not a user’s underlying permission to open a file. Record the existing values and intended policy before approving any change.

Separately, an authorized SharePoint administrator can inspect Active sites > select the site > Settings > Restrict content from Microsoft Copilot. Restricted Content Discovery limits organization-wide discovery and hides SharePoint AI entry points. It does not revoke existing access or prevent every experience, such as summarizing an already-open document. Do not disable it merely to make a test pass.

If recent changes explain missing search results, allow propagation and record the change time. Reindexing is a scheduled operation, not a guaranteed 30-minute repair. Microsoft warns against unnecessary whole-site reindexing. Request it only when the search administrator identifies an appropriate reason, such as a relevant search-schema change.

Check protection and escalate without broadening access

Ask the document owner or information-protection administrator to check the actual label and effective usage rights. Encryption does not automatically exclude every file: Microsoft’s protection architecture requires VIEW and EXTRACT rights for interaction with sensitivity-label-encrypted content. User-defined permissions and the particular agent experience can impose further limits. Do not downgrade the label or grant extraction rights without the data owner’s security decision.

A Copilot DLP policy can prevent processing of labeled content even when the user can open it. A blocked item can still appear as a citation; that is not proof its contents were used. Escalate the policy message instead of copying the contents into a prompt.

Compare with a small, non-sensitive file already approved for the same Copilot feature. Check that feature’s current format and size requirements; file support is not identical across Chat, Office apps, and custom agents. A successful comparison narrows the investigation but does not prove the original is corrupt or justify replacing it.

Do not create a “Copilot” app registration or grant Sites.Read.All or Files.Read.All as a generic repair. For a custom integration, its owner must review that integration’s documented authentication and least-privilege requirements separately.

Send IT the timestamp, affected account, sanitized error, file reference, and the direct-access/search/Copilot results. Authorized investigators can correlate Copilot audit records and available resource-policy details. An interaction record is not a guaranteed trace of every failed API call. A resolved case should establish that the intended user can use the intended feature while the original access and protection requirements remain intact.