External and guest access to apps

Two external routes

Sharing a canvas/model-driven app externally still runs everything through the same Dataverse security and connection model — a guest sees only what their role and the app's connections allow. Power Pages is different: it deliberately publishes selected Dataverse data to the internet, so its own permission layer (web roles, table permissions, page permissions) is the entire wall.

Failure modes

• Guest access to Dataverse. A guest granted a security role can read corporate rows; guests are external identities and easy to forget in access reviews. Guest access to Dataverse should be deliberate and scoped.
• Power Pages table permissions too broad. Grant a web role global read on a table and the site publishes every row publicly — the classic 'internal data on a public site' leak.
• Anonymous access left on. A page or table permission scoped to anonymous visitors exposes data with no authentication at all.
• Sharing with 'everyone'/broad groups — the app's connections (stored credentials) become usable far beyond intent.
• Guest lifecycle drift. Guests who left the partner org but remain in the tenant keep whatever they were granted.

What to watch (proofs)

• App sharing including guests: Get-AdminPowerAppRoleAssignment — apps shared to guest principals or broad groups are the finding.
• Guest identities with platform access: cross-reference guest users (Get-MgUser filtered to userType eq 'Guest') against environment role assignments — external access to Dataverse.
• Power Pages sites and their exposure: the admin center's Power Pages inventory, plus each site's table permissions/web roles — global-read or anonymous permissions are the leak.
• Tenant external-sharing posture for the platform (admin center tenant settings) — whether guest sharing is allowed at all is the baseline control.