Sites.Selected: how to give an app one SharePoint site and nothing else
Sites.Selected is the Microsoft Graph permission that lets an application reach exactly one SharePoint site — not your whole tenant. Here is what it is, why it matters, and how to grant it.
Most SharePoint integrations ask for far more access than they need. The classic application permission, Sites.ReadWrite.All, grants an app read and write to every site in your tenant — HR, finance, the board's site, all of it. For a tool that only needs one document library, that is wildly over-scoped, and your security team is right to refuse it.
Sites.Selected is the answer. It is the Microsoft Graph permission designed for exactly this: an app that should see one named site and nothing else.
What Sites.Selected actually does
Sites.Selected is unusual. On its own, it grants an application no access to any site at all. Consent to it does nothing until an administrator separately grants that specific app permission to a specific site.
So the model is two steps:
- The app is granted the
Sites.Selectedapplication permission (tenant-wide consent, but it unlocks nothing yet). - An administrator grants this app
readorwriteon this one site.
The result: the app can reach precisely the site you named, at the level you set, and no other. Add a second site later and you grant it again, explicitly. Remove the grant and the app goes dark for that site immediately.
Why this is the right default
- Least privilege. The app holds the minimum it needs to do its job. A compromise of the app's credentials exposes one site, not the tenant.
- Auditable. The per-site grant is an explicit, logged administrative action. You can answer "what can this app see?" with a precise list.
- Reversible. Revoking access is a single grant removal, not an app re-registration.
This is why Docplume uses Sites.Selected for the Microsoft 365 editing bridge. The connection is locked to the one site you choose, and it can neither discover nor touch any other.
How to grant it
The grant is made by a SharePoint or Global Administrator. The shape of the steps:
1. Register or identify the application
You need the application's client (app) ID. For Docplume this is shown on the integration setup screen.
2. Consent to the Sites.Selected permission
In Entra ID, grant the application the Sites.Selected application permission and provide admin consent. Remember: this unlocks nothing by itself.
3. Find the site you want to expose
Every SharePoint site has a Graph site ID. You can resolve it from the site's URL through the Graph API or the admin tooling.
4. Grant the app permission to that one site
Create a permission on the site that names the application and sets the role to read or write. This is the step that actually gives access — and it names a single site, so that is all the app gets.
5. Verify
Confirm the app can list the target site's document library, and confirm it cannot reach a different site. The second half of that check is the point of the exercise.
What it can and cannot see
With write on one site, the app can read and write the documents and document libraries on that site. It cannot:
- enumerate or open any other site in the tenant,
- read user mailboxes, Teams chats or OneDrive,
- change tenant settings or other apps' permissions.
If you need it narrower still, grant read instead of write, or scope to a specific document library rather than the whole site.
Taking it away
Because access is a single explicit grant, removing it is a single explicit action: delete the site permission for the app. Access stops at once, and your audit log shows exactly when and by whom. That reversibility — grant one site, revoke one site, prove it either way — is what makes Sites.Selected the permission to insist on.