Graph Permissions Finder Beta

What this answers, and what it doesn't

Microsoft publishes, for every Graph request URL and HTTP method, which permissions can call it and which of those is the least-privileged. This tool inverts that mapping: you describe a task, it collects the operations that task makes, takes the least-privileged permission for each one, unions them, and collapses anything a broader permission in the set already covers. That is the entire algorithm — there is no scoring, no heuristic, and no model involved anywhere in the answer.

Two limits worth stating plainly. First, this is the answer to “what does this request need”, not “what does my task need”. If your integration only ever touches one SharePoint site, the per-operation answer is still Sites.Read.All, because Microsoft's mapping has no way to know your scope — the narrower answer is Sites.Selected with per-site grants. A handful of scenarios carry a note where that gap is sharp enough to matter, but a note is all it is: the resolved set stays Microsoft's answer.

Second, there is no permission-centric browser here — you cannot start from Mail.ReadWrite and page through everything it unlocks. That is a different tool with a different shape, and building half of it would be worse than not building it. Searching the operation picker by permission name is the closest thing, and it is deliberately just a search.

How permissions get collapsed

When a selection ends up needing both Mail.Read and Mail.ReadWrite, only Mail.ReadWrite appears — the broader grant already covers the narrower one. That collapse runs off a hand-curated list, never off pattern-matching the permission name, because the naming genuinely does not hold: Files.ReadWrite.Selected does not cover Files.Read.All despite the longer name, and Policy.ReadWrite.ConditionalAccess does not cover Policy.Read.All. Any pair the curated list does not cover stays uncollapsed and both permissions show — verbose is recoverable, a wrong collapse is not. Every collapse is listed under the results so you can audit it.

Deliberately not collapsed

These come up often enough that “we chose not to” is worth distinguishing from “we forgot”.

Delegated vs application

Delegated permissions let an app act as a signed-in user, and the effective access is the intersection of the permission and what that user could already do. Application permissions let an app act with no user at all, and the effective access is the whole tenant — which is why so many of them require admin consent and why an application answer is usually broader than the delegated one for the same task. Around 2,421 operations in Microsoft's mapping have no application permission at all; this tool lists those explicitly instead of quietly leaving them out.

Admin consent is shown as a fact, not a warning. Most useful application permissions require it, and colouring that red would make the entire results panel look like a problem.

Building the app registration afterwards? The manifest block copies as a requiredResourceAccess entry with real permission GUIDs and the right Scope/Role type. Microsoft has not published GUIDs for part of its own preview permission surface; anything in that group is named in the copy confirmation rather than emitted with a made-up id.