A dashboard reports that staff are using 63 generative AI applications, with a monthly data volume and a top ten by user count. The number is precise, it is rendered as a headline figure, and it is believed immediately, because it has the shape of a measurement.
Ask what kind of number it actually is. Nobody was surveyed. No application filed a return. Something inferred sixty-three from traffic that happened to pass a point where somebody was watching, and then matched what it saw against a catalogue of known destinations. Both halves of that sentence have limits, and knowing them is what turns the dashboard from a scoreboard into an instrument.
The useful question about a discovery figure is not whether it is right. It is which sixty-fourth application it cannot contain, and why. This chapter is about answering that from first principles, so that a defender presenting a number to a governance committee can say honestly what population it describes.
What a cloud access security broker is
The category predates generative AI by a decade, and it was created to answer a question that has not changed: staff are using cloud services the organisation did not procure, and the organisation would like to know which ones. The name that stuck, cloud access security broker, describes an intermediary sitting between users and cloud services. In practice the products in the category operate in four architecturally distinct ways, and this is the taxonomy worth teaching, because every capability difference in the market follows from which of the four a given deployment is using.
Log-based discovery reads the logs of network equipment the organisation already runs: firewalls, proxies, secure web gateways. It needs no agent and no change to the traffic. It sees whatever crossed a logged egress point.
Endpoint-based discovery takes the network connection telemetry from the endpoint agent of Chapter 23 and forwards it to the broker. It needs an onboarded device and no network position at all, and it therefore works on and off the corporate network.
Interface connectors integrate server to server with a sanctioned application, reading that application's own records. This yields real events rather than inferences, and works only for applications that expose an interface and that somebody has connected.
Inline interception routes traffic through the broker itself, forward or reverse proxied, which is the only mode that can act on content in flight. It carries the cost and contention Chapter 7 set out for anything that must break TLS to be useful.
Different products emphasise different modes, and one deployment often runs several. What each mode can attribute differs sharply, which is where the sixty-three comes from.
The catalogue and the risk score
Discovery produces destinations. An app catalogue turns those destinations into named applications with attributes, which is what makes a dashboard readable. Microsoft's catalogue runs to tens of thousands of applications with a dedicated generative AI category, and the count in that category has been in the low thousands (medium; the figures are published in product material and move).
Each catalogued application carries a risk score, typically a weighted judgement over security attributes, compliance certifications and legal and privacy terms. It is genuinely useful for triage, because it lets an analyst sort a long list into an order worth working through.
It should be read for what it is. A risk score is a vendor's opinion, rendered as a number, using weights that vendor chose. Scores are comparable to each other inside one catalogue and to nothing outside it. A governance paper that says 'this application scores 3 out of 10' has said something meaningful about ranking and nothing at all about acceptability, and the two get conflated constantly.
Sanction, unsanction, monitor
The broker offers a label. An application can be tagged sanctioned, monitored or unsanctioned, and the tag lives in the broker's own catalogue view.
The effect happens somewhere else. Where the broker is integrated with the endpoint agent, tagging an application unsanctioned automatically creates block indicators, and the domains associated with that application are propagated to onboarded devices, blocked by SmartScreen in Microsoft's browsers and by network protection elsewhere. Tagging an application as monitored creates warn indicators instead, which produce a bypassable block, and administrators can point the block page at an internal support URL so that staff are told why and how to request an exception (high).
The structural point is worth naming because it recurs in Chapter 27. The aggregation surface issues the verdict; a different system carries it out. This is why every enforcement caveat from Chapter 23 applies here unchanged, and why two more appear.
Latency compounds. Microsoft documents up to three hours from marking an application unsanctioned to the block taking effect on a device: up to one hour to synchronise the tag to the endpoint product, and up to two more to push the resulting indicator to devices (high). The label and the reality diverge for a working half-day.
And granularity is coarser here than for hand-written indicators. Full URLs are not supported for unsanctioned applications; the propagation works on domains, so a service reached at a subdomain can be blocked and a service reached at a path under a shared domain cannot (high). For AI tools that live at their own domain this is fine. For an AI feature reached under the domain of something the organisation wants to keep, it is the difference between a usable control and none.
The shadow AI lens: what the census is a census of
Assemble the sixty-three, feed by feed.
Endpoint-based discovery contributes user-attributed AI usage from onboarded devices, on or off campus. This is the highest-quality feed in the set: it names the user, the device and the application, and it keeps working when the laptop is at home (high).
Log-based discovery contributes usage from any device on the campus network, including personal ones, which is coverage the endpoint feed cannot reach. What it generally cannot contribute is identity. Unless the proxy authenticates users, the record is a source address and a destination, so the finding reads as 'a machine on the university network used this service on this date' with no name attached (medium; it depends entirely on local proxy configuration).
Interface connectors contribute nothing for consumer AI, because there is no tenant to connect. Chapter 21 explains why, and the emptiness is structural rather than an integration nobody got around to building.
So the census is attributed for managed devices, anonymous for personal devices on campus, and absent for the personal device off campus, which the internal source report identifies as the central blind spot of the whole problem (high). The number errs low, and it errs low in a direction that can be described precisely. That description is more valuable to a governance committee than the number.
The catalogue also reaches beyond the browser. Model provider interfaces and, more recently, servers offering tools to agents appear as catalogue categories in their own right, which is the only route by which the interface-mediated path of Chapter 22 shows up in a discovery view at all (medium; this is described in product material and third-party commentary rather than in a single authoritative page). It is partial, and it is better than nothing, and a defender should know it exists.
Discovery is the input to a decision, not the decision. The sequence the internal report recommends is worth compressing here because it is the sensible use of a lower-bound number. Establish a baseline first, with no enforcement attached. Classify what turns up: sanctioned, monitored, unsanctioned. Communicate and consult before anything changes, which in an Australian institution engages obligations that Part Five develops. Then soft-enforce, with warnings and audit-mode policies. Then block the narrow set where the risk is clearest and a sanctioned alternative exists. Then keep discovering, because the catalogue and the staff both keep moving.
The order matters more than any individual step. A programme that begins with blocking has taken its only accurate measurement of the problem after it has already changed the behaviour it was trying to measure.
Catalogue lag. New AI tools appear continuously, and an application the catalogue does not know is a destination without a name. The long tail is exactly where curious staff go, which means the coverage gap is correlated with the behaviour of most interest.
AI features inside sanctioned applications. The organisation approved a document tool; the tool shipped a summariser. Discovery sees a destination it has already sanctioned, and the feature is invisible as a distinct thing. This is the hardest structural gap in the category, it is growing rather than shrinking, and no amount of catalogue investment closes it, because the problem is that the unit of discovery is the destination and the unit of concern is the feature.
Identity attribution collapses on the log-collector feed, so on-campus personal-device usage is a count without a name. Useful for scale, useless for anything that requires knowing who.
Risk scores get quoted as facts. They are comparable within a catalogue and to nothing else.
Unsanctioning has real consequences for people mid-task, arrives up to three hours late, and cannot be scoped to a path. Each of those is manageable; all three together mean the label is a blunt instrument and should be used on a short list.
The deepest limit: discovery of an application is not discovery of what was sent to it. The broker knows the destination, the volume and, on a good feed, the user. It does not know the content, and treating a volume figure as a measure of exposure overstates what the programme knows. That is Chapter 25's problem, and Chapter 25 has its own limits.
- Name the four discovery feeds and state, for each, whether it can attribute activity to a named user.
- Explain to a committee why the count of AI applications in use is a lower bound, and describe the population it actually measures.
- Walk through what happens between an administrator tagging an application unsanctioned and a staff member seeing a block, and give the elapsed time.
- A sanctioned document product adds an AI summarising feature. Explain why discovery does not surface this, and say where you would look instead.
- You are writing a paper recommending that three AI services be blocked. State what the discovery data supports, and write the sentence that says what it does not.
Glossary terms used in this chapter
API connector · app catalogue · CASB · cloud discovery · Defined from earlier chapters and reused here · log collector · MDCA · MDE · network protection · reverse proxy · risk score · sanctioned application · shadow IT · SmartScreen · SWG · tenant · TLS inspection · unsanctioned application
Sources
Every Microsoft Learn page below was verified against the Microsoft Learn documentation service on 9 August 2026.
- Microsoft Learn, 'Cloud app discovery overview'. learn.microsoft.com The reference for the discovery feeds described in this chapter: endpoint integration, log collector, secure web gateway integrations and the discovery interface, and for the distinction between snapshot and continuous reports. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Integrate Microsoft Defender for Endpoint with Microsoft Defender for Cloud Apps'. learn.microsoft.com Supports the claim that endpoint logs sent to the broker provide user and device information for traffic activity, and that the integration extends discovery beyond the corporate network. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Govern discovered apps using Microsoft Defender for Endpoint'. learn.microsoft.com The source for the unsanctioning mechanism, the automatic synchronisation of unsanctioned domains to endpoint indicators, the warn-and-educate option with a custom support URL, and the stated latency of up to three hours composed of up to one hour of synchronisation and up to two hours of policy push. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Investigate apps discovered by Microsoft Defender for Endpoint'. learn.microsoft.com Supports the two-hour domain propagation figure, the default that unsanctioned applications are blocked for all endpoint devices in the organisation, and the limitation that full URLs are not supported for unsanctioned applications so that a path under a shared domain cannot be blocked this way. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Govern discovered apps in Microsoft Defender for Cloud Apps'. learn.microsoft.com Supports the sanctioned, unsanctioned and monitored tagging model and the alternative enforcement paths for organisations using third-party gateways. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Manage generative AI apps for your organization'. learn.microsoft.com Supports the described workflow of filtering discovered applications by the generative AI category and unsanctioning from that view, and the note that unsanctioned applications are blocked across onboarded devices unless the organisation chooses to warn instead. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Create cloud discovery policies in Defender for Cloud Apps'. learn.microsoft.com Supports continuous discovery through app discovery policies that alert on newly seen applications. Last checked 9 August 2026; (high).
- Telemetry and Control Options for Shadow AI in an Australian University (this project's internal source report). The source of the discover-then-decide sequence, the catalogue scale figures, and the identification of off-campus personal-device use as the central blind spot.
Open questions
The size of the Microsoft cloud application catalogue and of its generative AI category are published in product material rather than in a stable documentation page, and both figures move. Treat any specific number as approximate and dated (medium).
The presence of model provider and agent tooling categories in the catalogue is described in product material and third-party commentary rather than in one authoritative Microsoft Learn page. Verify in the tenant's own catalogue view before relying on it (medium).
Whether a given institution's proxy authenticates users, and therefore whether log-based discovery can attribute activity at all, is a local configuration question. It changes the value of that feed completely and cannot be answered from documentation (medium).
Last updated 9 August 2026