Delegated Microsoft Graph permissions, explained for security reviewers
“Delegated” and “application” permissions look alike on an approval screen but behave very differently. A plain-language guide to what you are approving.
Brillienta team·Published ·5 min readWhen you deploy a SharePoint Framework solution, your tenant administrator may be asked to approve Microsoft Graph permissions. The approval screen lists names like User.Read.All, and it is easy to approve them without knowing what they allow. This post explains the one distinction that matters most.
Delegated vs. application permissions
| Delegated | Application | |
|---|---|---|
| Acts as | The signed-in person | The app itself, with no user |
| Can access | Only what that person can already access | Everything the permission covers, tenant-wide |
| Typical use | Apps people use in the browser | Background services and daemons |
With a delegated permission, the effective access is the overlap of what the app was granted and what the user is allowed to do. An employee using the app cannot read a mailbox or a file they could not already open themselves.
How Brillienta products use Graph
- Permissions are delegated: the products act as the person using them.
- They are requested per feature and documented, so you can see which feature needs which permission — for example, the Employee Directory reads profiles from Entra ID to keep the directory in sync.
- Some products request none at all. The Helpdesk package asks for no Microsoft Graph permissions: every email is a row in an Outbox list that your own Power Automate flow sends from your support mailbox.
Questions worth asking any vendor
- Is each permission delegated or application?
- Which feature needs it — and can we turn that feature off?
- Does any data leave our tenant as a result?
See every permission for every product on our Security & your data page.