Two Permissions That Were Never in the List ​

September 8, 2026 · InfraScout Team

Two read-only permissions have been added to the InfraScout permission catalog. If mail questions or distribution-list membership have been failing or coming back blank in your tenant, this is why — and topping up an app registration you already have just got easier.

Why the mail tools were failing everywhere ​

Three tools read mailbox message metadata, and the permission they need was missing from the catalog. Because the consent flow only ever asks for what the catalog lists, it was never requested at onboarding and so never granted — those three tools returned an authorization error in every tenant. The capability panel, which grades tool families against the permissions your app actually holds, reported no gap, because it did not know to look for one.

It is in the catalog now as Mail.ReadBasic.All. Deliberately the basic variant rather than Mail.Read: it covers subject, sender, recipients and timestamps, which is what these tools exist to read, and it keeps a tenant-wide grant over message bodies and attachments off your consent screen entirely. The tool descriptions say so, so the AI stops asking for a body preview it cannot have.

A distribution list that looked empty ​

The second one is the more interesting failure, because nothing errored.

Ask who is on a mail-enabled distribution list and Microsoft Graph returns the external contact members with an ID and a type and every other property null — display name included. No error, no warning. That is indistinguishable from a set of records that genuinely hold no data.

So "who is on this distribution list?" answered wrong, with nothing to prompt a retry. The AI did the right thing and refused to guess at the blank records, but still concluded there were external contacts with empty fields, when the truth was that it lacked permission to see them.

OrgContact.Read.All is now in the catalog, and two tools come with it for reading organizational contacts directly. InfraScout also recognizes the all-null shape when it appears and names the missing permission in the result, so a tenant that has not consented it yet gets an explanation rather than blanks.

Both permissions are read-only and both are non-core, which means adding them does not re-grade anything that already works or block saving a connection that lacks them.

Which is a good moment to make re-running easier ​

Two additions to the catalog means every app registration provisioned before this week is missing something. That is a recurring situation — the catalog grows as the tool surface grows — and the script's answer to it used to be re-run it with the same display name.

There is now an Extend mode that takes the app's client ID instead:

powershell
.\create-infrascout-customer-app.ps1 -ClientId <application (client) id> -TenantId <tenant id>

It never creates an app. It looks up the one you point it at, shows you what it found, and asks you to confirm before writing anything — with no as the default answer, because consenting tenant-wide application permissions to the wrong app is not something you can quietly undo.

From there it is strictly additive. Previously a run replaced the app's permission manifest wholesale; now it reads what is already there, keeps all of it — including permissions you added by hand for your own reasons — and appends only what is missing. If nothing is missing, it says so and makes no change. Consent works the same way: already-granted permissions are left alone.

Your secret is not rotated. -GenerateSecret defaults to off in Extend mode, the opposite of a fresh provisioning run, so an existing connection keeps working while you top up its permissions.

What to do ​

If your capability panel names a gap, run Extend mode. The default grant is now 50 permissions — 43 Microsoft Graph and 7 Defender for Endpoint — or 52 if you opt into the two device-secret permissions.

Full detail: Connecting Entra ID.

Questions or feedback? Reach us at info@infrascout.cloud.