Minimum permissions

What this page is

Nothing on this page is granted, requested or consented by reading it. It is what an owner reads before deciding whether a read may be pointed at a tenant. A permission appearing in a table is not a reason to ask for it, and holding one is not authorization to audit a service.

The two tables below are built from the Engine's own catalogue, one row for each collector, and the collector catalogue shows the same rows in full. The prose around them is taken from the Engine's permissions document for its Microsoft Entra reads.

Each read asks for its own scope, and no other

A Microsoft Graph read asks only for the scopes its collector declares. No wider set is asked for once and kept for convenience, so reading guests does not ask for what reading applications needs.

The scopes the catalogue records for the reads of Microsoft Graph:

• m365g entra app list asks for Application.Read.All.
• m365g entra ca list asks for Policy.Read.All.
• m365g entra group list asks for GroupMember.Read.All.
• m365g entra guest list asks for User.Read.All.
• m365g entra serviceprincipal list asks for Application.Read.All.
• m365g entra tenant governance get asks for Policy.Read.All, RoleManagement.Read.Directory, Policy.Read.AuthenticationMethod.

m365g teams team list is the groups read under a second command and asks for nothing further.

What the Engine's permissions document adds, for the reads it covers:

• Guests. User.Read.All. A narrower scope is listed first for the same call, and whether it returns the property that tells a guest from a member is not established, so it is not used.
• Applications. Application.Read.All.
• Groups, their owners and members. GroupMember.Read.All, the least for owners. A narrower scope reads members alone and does not read owners. The vendor's reference lists a write scope as the least for listing groups, and the Engine does not ask for it.
• Conditional Access policies. Policy.Read.All.
• Service principals. Application.Read.All.

Consent is the person's, and can be for oneself alone

A scope nobody has consented to is asked for at the sign-in, and the directory shows its own consent prompt there. The Engine grants nothing and consents to nothing: no read has a step that accepts a prompt. Whether a given person may accept a given scope is the directory's rule, not the Engine's.

The directory's prompt lets an administrator consent for their own account without consenting on behalf of the organisation, and the Engine asks for nothing more than that: no read on these pages needs a grant made for everybody.

The Engine's document states how a decision is asked for: one collector, one scope, one tenant, named in the request, immediately before the consent.

What the SharePoint reads use

The SharePoint reads sign in through the application registered for the command line by m365g engine setup. Authentication and sessions describes that sign-in. For some of them the catalogue records a permission, and for others it records not-established: the read works with what that application holds, and the least it would work with has not been proved. The two tables below say which is which. not-established is not a way of saying none is needed.

What is not decided

Planned, not implemented

• Delegated grants, which say what an application was consented to on behalf of people. The only read scope the vendor's reference offers for them is Directory.Read.All, which is broad, and no narrower one is documented. The Engine's document calls it the widest read in its table and the one to decide on deliberately. Nothing reads delegated grants today, which is why the application governance page says what an application asks for and never what it was granted.
• Role assignments. The Engine's document records the least scope for listing them as not yet established.

Neither is a command. Nothing here can be run, and no permission in this section has been requested or granted.