Your Entra Connector Now Reports What It Can Actually Do

September 2, 2026 · InfraScout Team

You onboard a tenant by running our script, which creates an app registration and consents around fifty read-only permissions. If one of them does not take, you have previously found out weeks later, when a tool returned an authorization error in the middle of an assessment.

That gap is now closed at the front. A connection reads back which application permissions your app registration actually holds, and grades every tool family against them.

It costs nothing to check

The answer is already in hand. An application access token carries a claim listing exactly the permissions Microsoft has admin-consented for that app — so reading it requires no Graph permission of its own. The sign-in the connection already performs answers the question.

Which is why it can run at setup time, before your app is known to hold anything. Creating, updating and testing a connection now all read that claim and keep the result, so Test connection doubles as the re-check after you consent something new.

The panel leads with the gaps

Thirty capability rows, and on a healthy connector the working ones outnumber the actionable ones by roughly ten to one. So anything unavailable is listed with the exact permission that would unlock it, and everything already working folds behind a count.

Three states are kept distinct, because two of them call for opposite actions:

• Granted — that family's permissions are consented.
• Not granted — they are not, and the panel names them. Consent them, then press Test connection.
• Not checked — that part of the catalog has not been read for this connection yet, typically because the connection was last tested before a capability existed. It is not a claim that anything is missing, and it clears on the next test.

Conflating the last two would tell you to go and grant permissions your tenant may already hold, which is the exact problem this feature exists to prevent.

Two deliberate absences

Azure is not part of this. Azure access is granted as role assignments on subscriptions and resource groups rather than as application permissions, so an Azure token carries nothing of this shape to read back. It is left out rather than shown as a zero that would read as a problem.

A tenant with no Defender deployment reports zero, not a failure. Microsoft Graph exists in every tenant; Defender for Endpoint does not, and Microsoft declines a token for a service that was never provisioned. An app cannot hold a permission on a service with no presence in your tenant, so zero is the factually correct reading — and reserving the failure warning for genuine failures is what keeps that warning meaningful.

Re-run the script: two permissions were missing from the list

Building the capability catalog meant reconciling the published permission list against what the tools actually call. Two permissions the shipped tools genuinely need had never been in the list, which means the affected tools return an authorization error on every tenant onboarded before this release:

Permission	Tools it unlocks
SharePointTenantSettings.Read.All	The tenant-wide SharePoint and OneDrive sharing policy
SensitivityLabels.Read.All	The Purview sensitivity-label taxonomy

Both are now in the script. Re-run it — it is idempotent, detects your existing app, and leaves your secret alone:

.\create-infrascout-customer-app.ps1 -GenerateSecret $false

Then press Test connection and read the capability panel.

BitLocker and LAPS are now an explicit choice

The permissions behind the BitLocker recovery-key and LAPS password tools are available and not requested by default, behind -IncludeDeviceSecrets.

Every other permission in the catalog describes configuration or inventory. These two disclose a credential — a recovery key, a local administrator password — and an InfraScout tool result is read by a language model and kept in the conversation store. Microsoft takes the same view: its own Entra Agent ID blocks the BitLocker permission for AI agents outright.

So it is a decision to take per tenant rather than a default. Without them the two tool families report an authorization error and the capability panel names the gap, which is a better default than quietly holding your recovery keys. Pass the switch if you want those tools, and expect the two permissions on the consent screen.

And two we stopped asking for

The script no longer requests the two Microsoft Threat Protection permissions it used to attach. Nothing in InfraScout calls that API — Advanced Hunting runs through Microsoft Graph, and so do incidents — so they were consent granted for no capability. If your app already holds them you can remove them; leaving them changes nothing.

Check your app for permissions we never asked for

This is why the panel calls out write-capable permissions in their own block rather than listing them among forty-odd read permissions.

InfraScout's entire permission specification is .Read.All. There is no code path in the platform that writes to your directory or to any of your Microsoft Cloud services, so a write-capable permission on your InfraScout app registration is one nothing will ever use. The onboarding script has never requested one.

If the panel shows you one, it was added outside the script — during a manual portal walkthrough, or by reusing an existing app registration for this. The PIM permissions are the ones to look for hardest: a write-capable PIM role can grant a directory role, including a privileged one, to any principal, which is a materially different grant from reading a policy. If one is on your app and you did not put it there deliberately for something else, remove it.

One note on what the gate does

Only one capability is a hard requirement: the directory sync. A connection missing the permissions sync depends on is refused at save, with the missing permissions named.

Every other gap is advisory. The tools stay in the catalog and report the missing permission when something calls them, rather than disappearing — which is usually the better trade, since a capability you are about to grant should not vanish from the documentation in the meantime. This is deliberately not wired to tool exposure.

See Connecting Entra ID.

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