What an AI tool can actually read once you click Accept

01 / 10

A meeting-notes app asks for calendar and mail

Consider a fictional 12-person marketing agency. Someone on the account team finds an AI tool that joins her Teams calls, writes up notes, and emails a recap afterward. She signs up with her work account, a screen lists a set of permissions, and she clicks Accept. As soon as she does, the app can read her calendar and her mailbox — not because anyone in IT reviewed it, but because that one click was the entire approval process.

That screen is the only contract most small businesses will ever sign with an AI vendor, and almost nobody reads it end to end. The words on it are not written for a first-time reader either. This post explains what those words mean, using nothing but Microsoft's own documentation of how consent works in Microsoft 365.

02 / 10

Who is actually granting access: one person, or everyone

Two different people can grant the exact same permission, and Microsoft draws a hard line between them. A user can authorize an application to access some data at the protected resource, while acting as that user — that is user consent, and the resulting access is scoped to whatever that one person can already see.

Admin consent is a different transaction. During admin consent, a Privileged Administrator might grant an application access on behalf of other users (usually, on behalf of the entire organization). An administrator can also do this once, for everyone: to avoid the need for user consent, an administrator can grant consent for the application on behalf of all users in the organization. After that, users aren't prompted for consent for that application — the approval already covers them, until someone changes it.

Microsoft is direct about what that can mean. Tenant-wide consent is a sensitive operation, potentially allowing the application's publisher access to significant portions of the organization's data, or the permission to do highly privileged operations — its own examples are role management, full access to all mailboxes or all sites, and full user impersonation. In the agency's case, nobody granted tenant-wide anything; one employee approved access to her own calendar and mailbox. Knowing which of the two just happened is the first thing worth checking on any screen like this.

03 / 10

The switch that decides whether staff can grant anything at all

Whether an employee can click Accept on her own is itself a setting an administrator controls, and Microsoft's admin center offers three built-in choices for the whole organization.

• Disable user consent. Users cannot grant permissions to applications on their own; they can still sign in to apps already consented to, or to ones an administrator consented to on their behalf.
• Allow consent only for applications from verified publishers or the organization, and only for permissions classified as low impact.
• Allow consent for all applications — any user can consent to any permission that does not require admin approval, for any app.

04 / 10

The same permission name, two very different reaches

Here is the fact that changes how dangerous a permission actually is, and it is easy to miss because the name on the consent screen does not change to warn you.

Microsoft Graph offers two kinds of permission for nearly every scope: delegated and application. Delegated permissions... are permissions that allow the application to act on a user's behalf. The application isn't able to access anything the signed in user couldn't access. Application permissions... are used in the app-only access scenario, without a signed-in user present. The application is able to access any data that the permission is associated with.

Microsoft's own example for this uses the exact permission a meeting-notes app would ask for. Granted as delegated, Files.Read.All means the application is only able to read files that the user can personally access — one employee's OneDrive and the sites she already belongs to. Granted as application, the identical scope name means the app is able to read any file in the tenant using Microsoft Graph — every site, every OneDrive, every file, whether that employee has ever opened it or not.

Same four words on the screen. A completely different reach. Delegated grants are usually the user's own call; application grants generally are not, because only an administrator or owner of an API's service principal can consent to application permissions exposed by that API. Our advice, not Microsoft's: if a screen does not say which kind you are looking at, ask the vendor before you approve anything.

05 / 10

Reading the scope words on the actual screen

Once you know whether you are looking at a delegated or an application grant, the individual scope names get easier to translate. Here are the ones a typical meeting or productivity assistant asks for, in Microsoft's own wording.

06 / 10

The checkbox nobody reads: offline_access

One entry in that table rarely gets a second look, and it decides how long the access actually lasts.

Most consent screens also request a scope with no friendly icon: offline_access. It is an OpenID Connect scope, not a Graph permission, and Microsoft's description of what it does is worth reading twice: Allows the app to see and update the data you gave it access to, even when users are not currently using the app. This does not give the app any additional permissions.

That second sentence matters as much as the first. offline_access does not widen what the app can touch — it removes the requirement that someone be signed in for the app to keep touching it. It is how the meeting-notes app in our scenario keeps summarizing calls on a Tuesday even though nobody has opened it since the day it was approved. Our reading, not something Microsoft states outright: for a small business, offline_access is the difference between a one-time look and a standing arrangement, and it deserves the same scrutiny as whatever permission it is riding along with.

07 / 10

What the blue verified badge proves, and what it does not

The consent screen often carries one more piece of reassurance: a blue verified badge next to the publisher's name. It is worth knowing exactly what that checks, because it is not what most people assume.

Publisher verification confirms identity, not intent or quality. When an app has a verified publisher, this means that the organization that publishes the app has been verified as authentic by Microsoft — the developer proved who they are through Microsoft's own partner program. Microsoft's own page is explicit about the limits: the blue verified badge doesn't imply or indicate quality criteria you might look for in an app. And: verified publisher status is only one of the several criteria to consider while evaluating the security and OAuth consent requests of an application.

A verified badge tells you the vendor is a real, identifiable company — genuinely useful, and worth checking for. It tells you nothing about whether that company writes secure code, stores data responsibly, or has ever been breached. Treat it as one input on the screen, not the whole decision.

08 / 10

Checking what has already been granted

None of this matters only at the moment someone clicks Accept. Apps approved months ago by an employee who has since left or forgotten about the tool are still sitting in the tenant with whatever access they were given.

Microsoft's documented path for checking this: browse to Entra ID, Enterprise apps, All applications, select the application, then select Permissions. Organization-wide grants show up under the Admin consent tab; permissions a single person approved for themselves show up under User consent. One limit worth knowing before you go looking: you can't revoke permissions in the User consent tab using the portal — that requires Microsoft Graph API calls or PowerShell.

Revoking is also less final than it sounds. Revoking the current granted permission doesn't stop users from re-consenting to the application's requested permissions. Take away an app's access on Monday, and an employee who still has it installed can hand back the same permissions on Tuesday, because the setting from the previous section, the one that decides whether she can consent at all, has not changed. Fixing that means changing that setting, not just clicking revoke once.

09 / 10

When a consent screen is not enough

A consent screen only ever shows one app, at the moment someone happens to be looking at it. For a business running more than a handful of connected tools, that is not really an inventory.

Microsoft's own answer to that gap lives inside Microsoft Defender for Cloud Apps, in a feature called app governance. Per Microsoft, it is a set of security and policy management capabilities designed for OAuth-enabled apps registered on Microsoft Entra ID, Google, and Salesforce, and it enables you to see which user-installed OAuth applications have access to data on Microsoft 365, Google Workspace, and Salesforce along with what permissions each one holds and who granted them. Getting it requires the right licence in place: Microsoft's FAQ states that Defender for Cloud Apps must be present in your account either as a standalone product or as part of a license package — the FAQ does not say which bundles include it, so check your own tenant rather than assume.

A standing inventory like that, reviewed on a schedule instead of reconstructed one app at a time, is also the kind of gap a managed monitoring service is built to close, ours included — more on that below.

10 / 10

Where to start

Before you evaluate any product, take one concrete look at your own tenant: open the Entra admin center, go to Enterprise apps > Consent and permissions > User consent settings, and read which of the three switches from earlier is actually turned on today. If you do not recognize the setting, that is useful information in itself about how the last connected app got approved.

Disclosure: this is a category we sell into. Avalon CloudSec keeps a standing inventory of enterprise applications and OAuth grants in a Microsoft 365 tenant, including which consents are tenant-wide, and flags permission drift — an app quietly asking for more than it did last time — with a diff of what changed. Connected AI tools are auto-classified against a curated catalog and moved through an approve, conditional, or not-approved review, so the decision gets made once and recorded rather than argued over per employee. One honest limit: CloudSec reads the tenant; it does not revoke a grant or block an app itself, so acting on what it shows still means the same admin-center screens described above. Questions go to email support@awservices.org.

Microsoft, Microsoft 365, Azure, Entra, Intune and Defender are trademarks of the Microsoft group of companies. Avalon CloudSec is an independent service and is not endorsed by Microsoft.