Sign in with Microsoft / Google: when a third party AI tool becomes a tenant problem

What an enterprise application is

An enterprise application in Entra is an object representing a third-party application granted some access to the tenant. It carries the consents granted, the assigned permissions, the assigned users, and the sign-in audit history. The same construct exists in Google Workspace and Okta, with minor interface differences. Two related objects matter. The 'application' object is the global registration owned by whoever published the application, shared across every tenant it has been used in. The service principal is the per-tenant instance, created when a user in this tenant first signs in or when an admin registers it, and it carries the per-tenant consents and audit data. A defender doing a tenant audit is looking at service principals.

A service principal is created automatically when a user first signs in and grants user consent, or by an administrator when admin consent is granted. Once it exists, it persists until something deletes it. Disabling the consenting user does not remove it; removing the user from the tenant does not remove it. A service principal is tenant-level state on a tenant-level lifecycle, not a user lifecycle, which is one of the central points of this chapter.

The two consent paths

User consent is the path most consumer AI tools use: an individual signs in, sees the consent screen of Chapter 10, and clicks 'Allow' to grant the requested scopes for themselves only. Admin consent is required for applications that need to act for many users without each consenting, or that request scopes classified as too sensitive for user consent; an administrator grants it on behalf of the tenant, and for delegated permissions every user can then use the application without a consent screen. Tenants created since around 2020 restrict user consent to low-risk scopes, with an admin-consent request workflow for higher-risk ones; without that workflow configured, the user gets a hard block. Tenants created earlier can have more permissive settings, so the first step of any OAuth audit is to check the current consent settings, because the past behaviour the audit uncovers depends on what the settings have been. (medium; defaults have changed across Microsoft updates, and a tenant's posture depends on when it was created and what has changed since)

Delegated and application permissions

Delegated permissions let the application act as the signed-in user: the token carries the user's identity, and the resource server enforces what that user may do. 'Mail.Read' as a delegated permission reads the signed-in user's mail only, and stops working when the user is offboarded. Application permissions let the application act as itself, with no user: 'Mail.Read' as an application permission reads every user's mail in the tenant. Application permissions always require admin consent, because the impact is tenant-wide, and they are common for back-end automations. For shadow AI the dominant pattern is delegated permissions, where a staff member clicks 'Continue with Microsoft' and the AI vendor calls Microsoft Graph as that user, with a blast radius limited to one user's data. Application-permission AI tools are the less common but more dangerous case: an admin has approved a tool with tenant-wide read access, the integration acts independently of any user, and offboarding an individual does not affect it. Only revoking the admin consent or deleting the service principal stops it, so a tenant audit needs to flag application-permission grants specifically.

What AI tools commonly ask for

The minimum for federated sign-in is the OIDC set: 'openid', 'profile', 'email' and 'offline_access', the last triggering the refresh token. These are benign on their own. The escalation begins with Microsoft Graph scopes on top: 'User.Read', 'Mail.Read', 'Calendars.Read', 'Files.Read.All', 'Sites.Read.All', 'Chat.Read.All', each expanding the vendor's reach into corporate data. (medium; the exact scope set drifts as products evolve, and any list should be re-validated against the live consent screen at deployment) Google Workspace works the same way with different names, such as 'gmail.readonly' and 'drive.readonly'.

What the enterprise-applications view shows

The Entra portal exposes the audit surface Part Two has been pointing at since Chapter 8, at Identity, Applications, Enterprise applications, with 'application type: enterprise applications' applied to filter out Microsoft's own internal service principals. Per application it shows the name and application ID, the sign-in events, the assigned users, the permissions consented to (split into admin-consented and user-consented), and the owners, which is often empty for user-consented apps. The Permissions tab is the most important page for audit work, because it shows exactly what was granted and by whom. The sign-in logs filtered for the application are the operational telemetry, with timestamp, user, device, IP, Conditional Access decision and result; an application with a service principal but no recent sign-ins is dormant and a candidate for revocation.

Microsoft Defender for Cloud Apps has an app governance capability, sold as an add-on, that scores OAuth applications for risk using scope sensitivity, publisher verification, application age, anomalous usage and cross-customer reputation. It is the closest thing to a purpose-built tool for OAuth-app risk in a Microsoft tenant. (medium; licensing has shifted, verify before quoting) The Google Workspace equivalent is under Security, API controls, App access control, where admins can block app access to Workspace data by default and allow only approved apps, with scope-based restrictions.

The shadow AI lens: the tenant audit

The activity that should happen at least annually, ideally quarterly, is a tenant audit. For each enterprise application the questions are: what is this application; who consented and when; what scopes are granted; when was it last used and by whom; is the publisher verified; does it appear in any threat-intelligence feed for risky OAuth apps. The disposition is one of three: keep (legitimate, in scope), restrict (legitimate but over-scoped, narrow the consent), or revoke (no longer needed, or never should have been there). The audit routinely surfaces AI tools no one centrally approved, apps from vendors no longer trading with the organisation whose refresh tokens are still alive, one-time test integrations never cleaned up, browser extensions that registered themselves as enterprise apps, and personal-account sign-ins that authenticated against the corporate tenant by accident.

Revoking a consent is a specific act: in the Entra portal, open the application, open the Permissions tab, remove the consent, and the OAuth grant is deleted. Existing access tokens may keep working until they expire, typically within the hour; the next refresh-token use returns an error and the vendor stops calling Graph, faster where CAE is supported. The user sees a re-consent prompt the next time they sign in, which is usually when they discover the revocation, so communicating revocations in advance avoids help-desk tickets. Tenant-side preventive controls are the other half: restrict user consent to verified publishers and low-risk scopes; configure the admin-consent request workflow so users have a path to ask; block specific high-risk scopes from user consent at the tenant level; and create app-specific Conditional Access policies for the highest-risk applications. The category-based approach from Chapter 12 closes the loop: Conditional Access against the generative AI category catches sign-ins, and app governance against the same category catches grants and scope changes, both governable when the user authenticates against the corporate tenant and invisible when they do not.

Offboarding and the residual grant is the failure that keeps surfacing across Part Two. Disabling the account prevents new sign-ins from that user but does not delete enterprise-application entries or invalidate a refresh token already held by a vendor. The missing step in many playbooks is the explicit sweep: identify the user's OAuth grants, revoke their sessions across vendors, and audit for tokens that survived. Entra's 'revoke sessions' action revokes refresh tokens for a user, with propagation at the relying party depending on whether the vendor supports CAE-like semantics, which most consumer-grade vendors do not. When the AI vendor acts for nobody, the failure is more serious: a delegated-permission tool stops on the next refresh once the user is gone, but an application-permission tool keeps working on the original admin consent until that consent is revoked, so application-permission AI tools need explicit governance, owners, and periodic reconfirmation of business need.

Closing Part Two

A reader who has worked through chapters 8 to 13 has the identity-layer apparatus a defender needs: the authentication and authorisation split, the federation pattern, the OAuth and OIDC mechanics, SAML in the enterprise long tail, the Conditional Access engine that bites at the IdP, and the residual third-party app registration that consented users leave behind. They also understand the boundary the identity layer cannot cross: the personal account, the local SaaS account, the device the corporate IdP cannot see. Part Three begins there. The device is not a black box; it is an operating system with processes, identities, certificate stores and management agents, and the browser sits inside it. Several of the gaps named in Part Two can be closed, or named more precisely, at the device layer.

Last updated 9 August 2026