Before an AI Reads Your SharePoint: Which Permissions Its Indexer Really Needs

SharePoint AI indexer permissions: a monk with a sealed list may enter only the three library alcoves that carry the same seal

An AI assistant needs two identities: one reads documents to build its index, the other answers people. The indexer can be limited to named sites with the Microsoft Graph permission Sites.Selected, read only, and it cannot read more than you grant. The answering part should never hold the indexer’s key. Tenant-wide Sites.Read.All makes the vendor’s setup easier; the technology does not require it.

Why would an AI tool ask for all of SharePoint?

Because one consent makes the setup finish. Microsoft describes the Microsoft Graph application permission Sites.Read.All in one line: “Allows the app to read documents and list items in all site collections without a signed in user.”[1] After that consent, the vendor’s crawler never meets a closed site, and nobody has to keep a list of sites.

Microsoft’s own guidance treats that consent as sensitive. Granting tenant-wide admin consent “is a sensitive operation, potentially allowing the application’s publisher access to significant portions of your organization’s data”, and Microsoft names “full access to all mailboxes or all sites” as an example.[2]

For Microsoft Copilot, Microsoft states that it “only surfaces organizational data to which individual users have at least view permissions.”[3] There the boundary is each user’s own access, which is why overshared files still matter; we covered that side in what changes the day you turn on Copilot.

An indexer that runs alongside Copilot under its own application identity has no user whose access could limit it. It reads with exactly the application permission you consented to.[4]

What does Sites.Selected actually allow?

Sites.Selected is a Microsoft Graph permission that “manages application access at the site collection level, providing access to a specific site collection.”[4] The difference from Sites.Read.All or Files.Read.All is the starting point.

With the broad scopes, “as soon as the scope is consented, the application can access the resources it represents.” Selected scopes “require an explicit assignment action”, so an application that has only been consented “would initially have no access.”[4]

Three things must be true before the indexer can read a site. The app is consented for Sites.Selected in Entra ID. The site has been granted to that app with a role, through POST /sites/{siteId}/permissions.[5] And the token the app presents carries the scope.

Microsoft says these steps apply to all Selected scopes: if any of the three is missed, “the application doesn’t have access.”[4]

Of the four roles (read, write, owner, fullcontrol), read means “Read the metadata and contents of the resource.”[4] An indexer needs nothing beyond read.

Creating the site grant itself requires Sites.FullControl.All.[5] Microsoft explains: “Because you can grant full control permissions to a site collection by using Sites.Selected, this requirement is necessarily high.”[4] So for a moment somebody holds a very large key. The design question is what happens to that key afterwards.

Who should hold the indexer’s key?

Two separate identities, with one rule: the part that answers people never holds the indexer’s credential. The indexer runs on a schedule with nobody signed in.

Microsoft notes that application-only scenarios “have no user present and are considered higher risk”, while with delegated access “the application can never exceed the current user’s existing permissions.”[4]

The indexer should sign in with a certificate, not a client secret. The Microsoft identity platform accepts “a JSON Web Token (JWT) assertion signed with a certificate that the application owns” anywhere a client secret could be used; the request carries client_assertion instead of client_secret.[6]

The private key belongs in Azure Key Vault. A vault owner “can also set up auditing to log who accesses secrets and keys”, “key usage is logged in near real time”, and the vault “is designed so that Microsoft does not see or extract your keys.”[7]

An indexing job that fetches the key at run time leaves an access record each time. A key file on a server does not.

Answers to users are a separate topic. They are produced on behalf of the signed-in person, so that person’s own permissions are checked at the moment of the question.

What gets read, and what is kept from each file?

In our own indexer, files are cut into chunks of about 1,000 characters with 200 characters of overlap. Every chunk keeps where it came from (the page range in a PDF, the slides in PowerPoint, the sheet and rows in Excel), its SharePoint version when one is returned, and its link.

It reads PDF, Word, Excel, PowerPoint, Markdown and plain text files. A scanned PDF without a text layer gives no text, because there is no OCR step.

Version numbers are worth keeping but cannot be promised. Microsoft’s versions API says a new version “can be created for each edit, each time the file is saved, manually, or never”, depending on configuration.[8] An honest index records the version when SharePoint returns one and stays silent when it does not.

Which version an answer should use is a separate question, covered in four checks before you trust an AI answer.

The index also has to follow later changes without losing files; see what the Graph delta link taught us.

Each chunk becomes a vector with text-embedding-3-large. Microsoft’s data commitments say embeddings “are NOT available to other customers” and “are NOT used to train any generative AI foundation models without your permission or instruction.”[9]

With a Standard deployment, prompts and responses “are processed within the customer-specified geography.”[9][10] Microsoft lists text-embedding-3-large as available for Standard deployment in Sweden Central,[11] and a Data Zone deployment created in a European Union member nation keeps processing within European Union member nations.[9]

How do you check that a site outside the list is really denied?

Do not take the vendor’s word for it, and do not take ours. Microsoft gives administrators two points of control: remove the grant on a specific site, or revoke the Selected consent in Entra ID, which blocks access to everything previously granted under that scope.[4]

What we do not know

Microsoft states: “Application access is lost as soon as a scope is revoked.”[4] We have not measured how quickly that holds in practice, for example for a token issued just before the revocation. Check it yourself after you revoke.

A denial test proves the state of the tenant at the minute it ran. A site added next month is a new fact, so the test has to be repeated after every change to the site list or the app registrations.

Whether a given AI product can run on Sites.Selected at all is something only its maker can say. Microsoft’s API reference for downloading file content lists Files.Read.All as the least privileged application permission,[13] so a vendor following that page alone will ask for more than a site-scoped indexer needs. We know only what our own indexer needs.

How KSJ does it

For a new installation, a Global Admin runs our script, which creates two app registrations. The indexer app holds one Microsoft Graph permission, Sites.Selected, read only, granted on the chosen sites.

Microsoft Graph lets an app grant site access to another app only if it holds Sites.FullControl.All.[5] So the script creates a temporary app with that permission and uses it once to make the grants. Then it removes the permission and the secret, so that even a restored copy could do nothing, deletes the app and removes it from the deleted items. Microsoft keeps a deleted application restorable “for up to 30 days”,[14] and after a permanent delete it “cannot be restored.”[15] If any cleanup step fails, the script stops with an error, names what is left and does not count the installation as finished.

The indexer signs in with a certificate. The key is generated on the admin’s machine, a copy goes to Azure Key Vault, and the indexing job reads it from there.

The answering API never receives the indexer identity. If indexer credential settings are present where it runs, it refuses to start, with exit code 78.

The script ends with a test against a site outside the list and records whether access was denied, so the admin sees the result before anything is indexed. More about the product is on the Answergrove page.

References

  1. ^ a b “Microsoft Graph permissions reference – Microsoft Graph”. Microsoft Learn. Retrieved 27 October 2026.
  2. ^ a “Grant tenant-wide admin consent to an application – Microsoft Entra ID”. Microsoft Learn. Retrieved 27 October 2026.
  3. ^ a “Data, Privacy, and Security for Microsoft Copilot”. Microsoft Learn. Retrieved 27 October 2026.
  4. ^ a b c d e f g h i j “Overview of Selected Permissions in OneDrive and SharePoint – Microsoft Graph”. Microsoft Learn. Retrieved 27 October 2026.
  5. ^ a b c “Create permission – Microsoft Graph v1.0”. Microsoft Learn. Retrieved 27 October 2026.
  6. ^ a “Microsoft identity platform certificate credentials – Microsoft identity platform”. Microsoft Learn. Retrieved 27 October 2026.
  7. ^ a “What is Azure Key Vault?”. Microsoft Learn. Retrieved 27 October 2026.
  8. ^ a “List versions – Microsoft Graph v1.0”. Microsoft Learn. Retrieved 27 October 2026.
  9. ^ a b c “Data, privacy, and security for Foundry Models sold by Azure in Microsoft Foundry – Microsoft Foundry”. Microsoft Learn. Retrieved 27 October 2026.
  10. ^ a “Understanding deployment types in Microsoft Foundry Models – Microsoft Foundry”. Microsoft Learn. Retrieved 27 October 2026.
  11. ^ a “Region availability for Foundry Models sold by Azure – Microsoft Foundry”. Microsoft Learn. Retrieved 27 October 2026.
  12. ^ a b “Review permissions granted to enterprise applications – Microsoft Entra ID”. Microsoft Learn. Retrieved 27 October 2026.
  13. ^ a “Download driveItem content – Microsoft Graph v1.0”. Microsoft Learn. Retrieved 27 October 2026.
  14. ^ a “Restore deleted item (directory object) – Microsoft Graph v1.0”. Microsoft Learn. Retrieved 27 October 2026.
  15. ^ a “Permanently delete item (directory object) – Microsoft Graph v1.0”. Microsoft Learn. Retrieved 27 October 2026.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top