Shadow AI is two problems: the apps you approved and the sites they visit

01 / 11

A CFO asks a question with two right answers

Consider a fictional 150-person engineering consultancy. The CFO reads about a competitor's data leak and calls a meeting with one question: which AI tools are our staff using with client data?

IT pulls a report that afternoon. It lists nine AI tools with an active connection to the company's Microsoft 365 tenant, each one showing exactly what it can access and who approved it. The CFO is satisfied for about a day, until someone mentions that half the engineering team has ChatGPT open in a browser right now, signed in with a personal account — and none of the nine connected apps is the one people actually use most.

Both reports are accurate. Neither is complete. That isn't a failure of the tool IT used. It's a property of the question: shadow AI isn't one thing you look up in one place. It's two questions, answered by two different sensors, and almost nobody realizes they're asking both.

02 / 11

Two sensors, not one blind spot

Every way of finding AI tools in a Microsoft 365 environment falls into one of two families, and what separates them is what triggers a record.

The first family is identity-based. Something happened inside the tenant: an employee or an administrator signed in to an app with a work account, or approved a set of Microsoft Graph permissions for it. Microsoft Entra ID logged the event because the tenant itself was the door the app walked through.

The second family is network- or endpoint-based. Nobody signed in to anything with a work account. Somebody on a managed device visited a website, and a sensor on the network path or the device itself noticed. Microsoft Defender for Cloud Apps is built for exactly that signal.

Ask do we have shadow AI without saying which family you mean, and you'll get a real answer to a question you didn't ask.

03 / 11

Lens one: what shows up because someone signed in

Open Microsoft Entra ID's Enterprise applications list and every app with a foothold in your tenant is there, because getting a foothold is what put it on the list. Select one and Microsoft's own guidance walks through the same two questions each time: who consented, and to what.

The Permissions tab splits by consent type. The Admin consent tab shows what an administrator approved for the whole organization; the User consent tab shows what one person approved for themselves. The same app's entry also links into Monitoring & health, Sign-in logs — pre-filtered to that one application — and a Usage & insights report summarizing how often it's actually used.

None of that tells you whether a given permission is dangerous; that's a different post's job. What it tells you, reliably, is that this app exists in your tenant, who let it in, and roughly how much it gets used. For an AI tool that connected through OAuth — a meeting-notes bot, a Copilot add-in, a plugin inside a line-of-business app — that's a complete, queryable record.

04 / 11

What lens one cannot see, at all

That record exists only because a consent or a sign-in event happened against this specific tenant. Nothing else gets an entry — not because Microsoft hid it, but because there's nothing to log.

A personal ChatGPT, Gemini, or Claude account, opened in a browser and signed in with a Gmail or personal Microsoft address, has no relationship to your tenant. No OAuth grant was requested. No sign-in touched your Entra ID. Our reading, not something Microsoft states directly: this follows from how the Enterprise applications list gets populated, not from a gap Microsoft left in the feature. It will never show that account, at any licence tier, because the mechanism this lens depends on never fired.

That's what makes we checked our connected apps and found nothing risky a dangerous sentence. It can be completely true and still miss most of what a CFO means by the question.

05 / 11

Two lenses, side by side

Put the two lenses next to each other and the shape of the problem is easier to see than to describe. Lens one's blind spot is exactly lens two's territory, and lens two's blind spot is exactly lens one's. A third, smaller zone sits outside both, no matter how well either one is configured.

06 / 11

Lens two: what shows up because a network or a device saw it

Microsoft Defender for Cloud Apps runs cloud discovery by comparing traffic logs against its own catalog — over 31,000 cloud apps, each scored against more than 90 risk factors, a figure that's held steady across Microsoft's pages from January 2023 through July 2026. Since at least April 2025 that catalog has carried a dedicated Generative AI category; Microsoft says it has added more than a thousand generative-AI-related apps to it, naming Bing Chat, Google Bard, ChatGPT, and more as examples — branding that has likely moved on since that page was written, even if the category hasn't.

None of it works without a data source feeding it:

• Microsoft Defender for Endpoint, integrated natively, extending discovery to devices off the corporate network
• A log collector you run on your own network, reading Syslog or FTP
• A Secure Web Gateway integration — Microsoft names Zscaler, iboss, Corrata, and Menlo Security
• Firewall or proxy logs, from the 35 firewalls and proxies on Microsoft's supported list

07 / 11

What lens two cannot see, at all

Cloud discovery answers what did the network see, and its blind spot mirrors lens one's exactly. An app that came in cleanly through OAuth — approved by an admin, sitting in Enterprise applications with a full permissions record — still generates ordinary network traffic, and nothing about that traffic tells this lens it was ever approved. Our reading, not a documented Microsoft behavior: the two systems don't compare notes. Cloud discovery doesn't check your consent records, and Enterprise applications doesn't read your firewall logs. They're separate products, built from separate signals, with no shared conclusion between them.

There's a harder floor underneath both, too: if no data source is configured — no Defender for Endpoint rollout, no log collector, no proxy integration — lens two sees nothing at all, licence or no licence. A subscription is not a sensor.

There is one place these two lenses touch, though it runs through a third Microsoft product. Microsoft Purview DSPM for AI can monitor what gets typed into third-party generative AI sites, but only for devices onboarded to Microsoft Purview — and Microsoft says that onboarding is shared across Microsoft 365 and Microsoft Defender for Endpoint (MDE). If you already onboarded devices to MDE for lens two's cloud discovery, Microsoft's documentation says they appear in the managed devices list and no further steps are necessary for Purview to see them too — with a real limit attached: for unmanaged AI apps opened in Edge, the detail captured is text prompts only, not the responses.

08 / 11

The four questions, and which lens answers them

None of the last few sections argues for one tool over the other. Read the table by row, not by column — the interesting fact for most rows is in the fourth cell.

09 / 11

What each lens costs, in licence terms, not dollars

Lens one is close to free, in the sense that matters here — it rides on infrastructure every Microsoft 365 tenant already has. Microsoft's own tier-by-tier comparison lists sign-in logs, the record lens one leans on, as available under Microsoft Entra ID Free as well as every paid tier. You're not buying a new product for lens one; you're using one your directory already runs.

Lens two is a different kind of purchase. Microsoft's own licensing guidance lists Defender for Cloud Apps as a standalone product, and also as included in Enterprise Mobility + Security E5, Microsoft 365 E5 (and its A5/G5 equivalents), and a handful of named Defender and Purview suite bundles. If your tenant's plan isn't on that list, lens two isn't a setting to flip on — it's a licence you don't hold yet, on top of whichever data source you'd still need to connect.

Neither fact says which lens matters more for a 150-person firm. It says which one shows up on next month's invoice.

10 / 11

Back to the consultancy

Back to the CFO's question. The honest answer isn't the list of nine apps, and it isn't go ask the engineering team. It's both reports, read together, with their gaps named out loud: here's everything that received an OAuth grant, here's everything a sensor saw cross the network, and here's the part neither one covers — what's actually being typed into an unmanaged tab, and whether an old grant is still in use.

That's a less satisfying answer than a single number. It's also the only true one, and saying so out loud in the meeting costs nothing.

11 / 11

Where to start

Before buying anything, run the free half of this yourself. Open Microsoft Entra ID, go to Enterprise applications, and sort by sign-in activity — that's lens one, and it costs nothing but time. Then ask whoever runs your IT one direct question: do we actually have any of the data sources cloud discovery needs turned on — Defender for Endpoint, a log collector, a proxy integration? If the honest answer is no, that's also the answer for why lens two has never surfaced anything, licence or not.

Disclosure: this is a category we sell into. Avalon CloudSec classifies AI apps connected to a Microsoft 365 tenant against a curated catalog, showing the reasoning behind every match — that covers lens one. An optional add-on extends it to lens two: network-based shadow-AI discovery through Microsoft Defender for Cloud Apps, surfacing AI websites visited from managed devices even without a Microsoft sign-in, and it only works if your tenant already holds that Defender licence, since CloudSec reads that signal rather than generating it. The honest limitation: neither piece tells you what a person actually typed into an AI tool, approved or not. To ask about either lens, 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.