Read access to one SharePoint site needs FullControl first: how our AI indexer handles it
The easy way to let an AI assistant read SharePoint is one consent: the Microsoft Graph application permission Sites.Read.All. Microsoft describes it in one line: "Allows the app to read documents and list items in all site collections without a signed in user." The setup finishes, the crawler neve
The narrow way is Sites.Selected. It has one awkward step, and this post is about that step.
Miss one and "the application doesn't have access." An indexer needs the read role and nothing more: "Read the metadata and contents of the resource."
Creating the site grant needs a very large key. The call requires Sites.FullControl.All, and Microsoft explains why: "Because you can grant full control permissions to a site collection by using Sites.Selected, this requirement is necessarily high."
So to give one app read access to a few sites, something must hold full control for a moment. This is what our installation script does with that moment:
POST /sites/ { siteId } /permissions { "roles": [ "read" ], "grantedToIdentities": [ { "application": { "id": "<indexer app id>", "displayName": "Answergrove Indexer" } } ] } Enter fullscreen mode Exit fullscreen mode It removes the temporary app's permission and secret, so that even a restored copy could do nothing. It deletes the app and then removes it from the deleted items. Microsoft keeps a deleted application restorable "for up to 30 days", and after a permanent delete it "cannot be restored." If any cleanup step fails, it stops with an error, names what is left and does not count the installation as finished. The order matters. Take the permission away first and delete second, so that a failed permanent delete leaves only an empty shell in the recycle bin.
The indexer runs on a schedule with nobody signed in. The part that answers people never holds the indexer's credential. 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."
For the indexer that means three things:
A grant that works proves little. The useful test is the opposite one: with the indexer's own credential, request the drive of a site you never granted. The expected result is an access error, not a file listing.
Our script ends with that test and records the result before anything is indexed. The test proves the state of the tenant at the minute it ran, so it has to be repeated after every change to the site list or the app registrations.
One thing we have not measured: Microsoft states "Application access is lost as soon as a scope is revoked," but we do not know how quickly that holds for a token issued just before the revocation.
The full article covers the Entra admin center checks and lists every Microsoft source: Before an AI Reads Your SharePoint: Which Permissions Its Indexer Really Needs. The product this script installs is Answergrove.