← Back to all posts

How to Review AI App Access in Microsoft 365

To review AI app access in Microsoft 365, identify the connected application, examine its granted permissions in Microsoft Entra, and decide whether its reach matches its business purpose. Blue Lantern Security's daily AI exposure scan helps surface AI connections and unverified apps with data access so your administrator can investigate and act.

An AI assistant connected for one task may retain permission to read mail, search files, or use calendars after that task ends. The review needs to answer what it can access today, who is responsible for it, and whether that access is still needed.

Start with your Blue Lantern Security AI exposure findings

Enable Daily AI exposure scan in your Outlook organization integration settings. Follow the Outlook integration instructions for the required Microsoft permissions and connection steps. The integration is named for Outlook, but its AI exposure checks cover application access across Microsoft Entra, including permissions for files and calendars as well as mail.

The scan runs once daily, with per-app findings in Monitoring Hub → AI Exposure. It reviews application identities, delegated grants, and application-permission assignments. It identifies known AI tools, assesses permission reach, and flags unverified publishers with data permissions, including apps that are not classified as AI.

Use a finding as the start of an access decision. The scan reads app identities and permission metadata, never message or file contents.

1. Match the finding to the enterprise application

Start in Enterprise apps, not App registrations. Enterprise apps is where a third-party application's instance and grants in your organization live. App registrations lists applications registered in your own directory, so a vendor's app registered elsewhere will not appear there.

In the Microsoft Entra admin center, open Entra ID → Enterprise apps → All applications, select the app, then open Permissions. Microsoft names the Cloud Application Administrator and Application Administrator roles for this workflow.

Check both Admin consent and User consent, then open each permission's details. The Microsoft permission-review guide covers this screen and the removal methods.

Record the application ID and the enterprise application's object ID alongside the name, because similarly named connectors are hard to tell apart otherwise. Identify the provider, the employee or team using it, and the work it supports.

2. Check the permission type as well as its name

Delegated permissions let an app act on behalf of a user, within both the granted permissions and that user's access. Application permissions let it act as its own identity without a signed-in user. These can have substantially different reach even when the permission name is identical.

Administrator consent is a separate question. An administrator can approve delegated permissions for the organization; that does not turn them into application permissions. Record both the permission type and who the consent covers.

Permission and type What to review
Files.Read.All
Delegated
The app can read files the user can access, potentially including shared OneDrive and SharePoint content
Files.Read.All
Application
The app can read files across site collections without a signed-in user
Mail.Read
Delegated
The app can read the signed-in user's mailbox
Mail.Read
Application
The app can read mail across mailboxes; check whether an applicable mailbox restriction limits its reach

Use the Microsoft Graph permissions reference to interpret the exact permissions you find. Review the full combination, including any ability to write files, send mail, or change calendars. Resource-specific controls can matter, so confirm the effective access with the administrator responsible for that service.

The useful business question is whether the assistant needs those resources and actions for its approved task. A familiar app with excessive permissions still deserves attention.

3. Investigate an unverified publisher in context

An unverified-app finding should prompt you to find out who operates the app and why it has access. On its own, it says nothing about whether the app is malicious, or even whether it is an AI tool.

For an internal application, identify its maintainer. For a vendor application, confirm the application's identity through the provider's documentation and review its data-handling terms. Check those details against the connection in your environment.

Microsoft's publisher verification confirms the publisher's organizational identity. It says nothing about whether the permissions are appropriate or the app is secure. Microsoft explains what publisher verification covers.

A verified app used for an abandoned experiment can still have unnecessary access. An internal app without a verified publisher may have a legitimate owner and purpose. Make the decision using the identity, permissions, and business context together.

4. Turn the finding into an access decision

Suppose your team tried an AI search assistant to summarize one SharePoint project. The trial ended, but the application still holds the application version of Files.Read.All.

That permission is broader than the single project the team had in mind. You do not need proof that the assistant read unrelated files to decide the access is unnecessary.

Record the decision in practical terms:

  • Purpose and owner: the completed project trial and the team responsible for it.
  • Access found: broad file-reading permission without a signed-in user.
  • Access needed now: none, because the trial has ended.
  • Action: have the authorized administrator remove the relevant grant and check for other grants that still authorize access.
  • Verification: confirm the change in Entra and compare the next successful scan with the expected result.

For an app you want to keep, ask whether the provider supports a narrower access arrangement. A smaller project scope in the product interface is not necessarily a smaller Microsoft permission grant. Confirm how any restriction is enforced before relying on it.

5. Remove the correct grant and address reconnection

For an unwanted permission on the Admin consent tab, select its … menu and choose Revoke permission. Review the affected workflow with its owner before routine changes.

The User consent tab has no portal removal action. Your administrator must use the Microsoft Graph or PowerShell methods in the permission-review guide. Match the application, affected user, and grant being removed; a script that removes every grant for an app can affect other users too.

Check both consent tabs after the change. A user-specific grant and an organization-wide delegated grant can coexist. Removing one may leave another route to the same access.

Revocation also does not prevent new consent where your policies permit it. If the business has decided the app should no longer be used, have the administrator review the applicable consent settings and approval process. Give employees an approved way to complete legitimate work.

6. Verify the change and review the next scan

Confirm the relevant grant is removed in Entra, inspect any remaining permissions, and record the time and administrator responsible. If the app is being reconnected with narrower access, review the replacement grant before declaring the issue resolved.

Permission removal is not always an immediate end to every active session. For delegated grants, Microsoft states that existing access tokens remain valid for their lifetime after grant deletion. Suspected active misuse needs your incident-response process and containment, as well as permission cleanup.

After the next successful daily scan, compare the findings with your decision. If unexpected access remains, investigate other grants, a second app identity, or renewed consent. An unsuccessful scan or missing report is not evidence that access has been removed.

Access findings will not tell you which documents were downloaded or what an employee pasted into a chat; that takes activity and content evidence. Revoking a grant also does not delete information the provider already holds.

Keep the access review connected to the business

The scan uses a maintained catalog and name-based checks to identify AI applications. Human review remains necessary for unfamiliar tools, ownership, and business approval. Local agents and personal AI activity without a grant in the connected environment fall outside this review. API keys and other authorization systems need separate review.

For each reviewed app, keep its identity, owner, purpose, permissions, decision, and verification date. Blue Lantern Security's AI exposure monitoring helps make that review repeatable as connections change.

If your business also uses Google Workspace, follow the Google Workspace access walkthrough. For protection against sensitive information being pasted or uploaded to AI tools, read AI access monitoring vs. DLP. Both support a broader approach to finding and managing shadow AI.