A dashboard reports that a small percentage of staff are sharing sensitive data with AI applications. There is a trend line, it is flat, and there is a list of recommendations underneath. Read at face value, it is reassuring: a manageable problem, under observation, with next steps.
Six chapters of Part Four have equipped a reader to ask the question that matters, and it is not about the percentage. On which devices was that measured? If the answer is the onboarded fleet, and if the AI activity of most concern is happening on machines that are not in it, then the trend line is a measurement of the population that was already the most governed, and it is flat for the same reason.
This is the category a defender will be asked to buy, justify or report from, and the marketing around it is at its thickest. The method for cutting through it is the one the whole of Part Four has been building: work out what kind of thing the surface is, then work out what it is standing on.
Posture is not detection
Two security activities are conflated constantly and are quite different.
Detection asks what is happening now. It consumes events, applies logic and produces alerts. Chapter 26 is about detection.
Posture management asks whether the configuration matches what was intended. It consumes configuration, compares it against a template of good practice, and produces findings and recommendations. Its output is a list of things to change, not a list of things that happened.
Both are useful and they answer different questions. A posture finding of the form 'this control exists in your licence and is not switched on' is often more valuable than an alert, because most organisations are not attacked through a novel technique; they are exposed through a capability they own and never enabled.
The lineage
The category arrived in three steps and the sequence explains its shape.
Cloud security posture management came first, to answer 'is our cloud infrastructure configured the way we think it is', because misconfiguration rather than intrusion had become the dominant cause of cloud data exposure. It works by reading configuration continuously and comparing it to a baseline.
Data security posture management moved the same idea from infrastructure to data. Where is sensitive data, who can reach it, is it labelled, is it protected. The questions are older than the category; the contribution was continuous automated assessment rather than a periodic audit.
The AI variant applies that method to a new object. Which AI applications are in use, what data is reaching them, and are the controls that ought to be in place actually in place.
Naming in this area is unstable, and a reader should expect that rather than be surprised by it. Microsoft's own instance was introduced under one name, renamed, and has since been superseded by a broader posture management solution, with the AI-specific surface now documented as the classic version and the newer one covering AI applications and agents with wider reach (high, checked 9 August 2026). The concept is stable; the product names are not.
An aggregation and orchestration surface
Here is the structural claim of the chapter, and it should be stated carefully because everything else follows from it.
A surface of this kind does three things. It reads from the controls beneath it. It presents the result in one place. And it offers one-click deployment of policies that those underlying controls will enforce.
It observes nothing directly. It has no sensor of its own. Therefore its coverage is exactly the union of the coverage of its inputs, and its blind spots are their blind spots, unchanged and inherited.
That is not a criticism. It is the definition of the category, and it is what makes the category evaluable. It also gives a defender a single question to put to any product in this space, including ones that do not exist yet: which sensor produces this number, and on which devices does that sensor run?
The recommendation engine
The other half of the product is a set of recommendations, each a comparison between an observed configuration and a template of good practice.
This is genuinely valuable, and the reason is unflattering to all of us: most organisations do not have an accurate inventory of what they have not switched on. Entitlements are broad, feature releases are frequent, and nobody reads every release note. A surface that says 'this exists, you own it, it is off' does real work.
It should also be read for what it is. The template was written by a vendor, and it reflects that vendor's product set. A recommendation is, in effect, 'here is a control we sell that you have not enabled'. That is frequently exactly the right advice. It is still worth recognising, because the template will not recommend a competitor's control, and it will not recommend the non-technical interventions that Part Five argues are among the most effective options available.
The shadow AI lens: the policy-to-prerequisite map
The most useful thing this category offers a student of the subject is that its policy list is a directory of the mechanisms in Chapters 22 to 26. Read the map and Part Four reappears in condensed form.
Detecting visits to AI sites uses insider risk browser signals, and requires the device to be onboarded and the compliance browser extension deployed, which is Windows only. Detecting sensitive information pasted or uploaded to AI sites uses endpoint data loss prevention, and requires an onboarded device plus either native integration in Microsoft's browser or the extension in Chrome and Firefox. Blocking elevated-risk users from pasting or uploading uses endpoint data loss prevention with adaptive protection, and requires an onboarded device. Blocking sensitive information from being sent to AI applications in Edge is inline browser protection, and requires no device onboarding at all, because the control lives in the browser. Detecting sensitive information shared with AI over the network requires a secure access service edge or security service edge integration, which is neither a device nor a browser dependency but a network one. Capturing interactions for Copilot experiences requires nothing device-side, because it is service-side capture. And the enterprise AI application integrations are server to server and independent of device state entirely (high).
Every one of those is a mechanism the reader has already met. The surface has not added a capability; it has arranged existing capabilities so that they can be seen together, which is a real service and a different one.
What the dashboard therefore measures. Work it through for a realistic Australian institution. Coverage of Microsoft's own AI is strong, because it is service-side and needs no device. Coverage of consumer AI in Microsoft's browser under a work profile is good, and reaches unmanaged devices, which is the one capability in the set that escapes the enrolment ladder. Coverage on the onboarded fleet is comprehensive. Coverage of the unmanaged device with a personal account is nil.
So the percentage on the screen is a measurement of the governed population. Presenting it without that qualifier presents a selection effect as a finding, and it is the specific error this chapter exists to prevent. The correct sentence for a governance paper names the denominator: of activity we can observe, this proportion involved sensitive information, and here is what proportion of the estate we can observe.
Prompt content, one final time, because this is where the question gets asked. Retention of prompts and responses through this surface is supported for enterprise AI applications connected through the identity layer or through the named enterprise integrations, and for a restricted set of consumer services in Microsoft's browser where a collection policy has been configured to capture content (high). Sensitivity labels and encryption are not supported for those third-party AI interactions at all (high). If the executive question is 'can we see what staff typed into free consumer ChatGPT on an unmanaged laptop', the answer is no, and no dashboard changes it.
What the category is actually good for. Stated positively, because this chapter should not read as dismissal. It collapses a scattered configuration question into one place. It surfaces controls the organisation already owns and has not enabled, which is usually the largest available improvement and the cheapest. It produces reporting a governance committee can read without a translator. It turns an unreviewable set of individual policies into a reviewable posture, with a history.
Those are real benefits. None of them is a sensor.
Dashboards inherit blind spots and present them as completeness. The most dangerous number in a shadow AI programme is a reassuring one drawn from the governed subset, because it is both true and misleading, and it is very hard to argue with in a meeting.
The category is young and its names are unstable. Microsoft's instance has been renamed at least twice and the AI-specific surface is now documented as the classic version alongside a newer, broader one (high). Documentation, screenshots and internal runbooks written a year ago will not match the product.
Several capabilities in and around the category are billed as pay-as-you-go rather than included in an enterprise or academic entitlement, and the guidance shifted more than once during 2025. Do not quote a cost without checking the tenant's own billing position (low).
Buying the surface does not add coverage. When the recommendation reads 'onboard more devices', the work is the onboarding, and the dashboard is the invoice for noticing. That is worth saying to a budget holder before rather than after procurement.
Recommendation templates are vendor-shaped. They will not recommend a competitor's control, and they will not recommend consulting the union, publishing a surveillance notice, or making the sanctioned alternative easier to find than the unsanctioned one.
The supported application list is maintained by the vendor and changes, so the posture is measured against a moving definition of what counts as an AI application. A percentage that improves between quarters may reflect a change in the denominator.
- Define posture management against detection in two sentences, and give one example of a finding that only posture management would produce.
- Take any named AI policy from this chapter and state the sensor it depends on and the device state it requires.
- An executive reads a dashboard percentage aloud in a meeting. Write the one sentence you add.
- Look at a typical recommendation list and identify which item represents real work rather than a configuration change, and say who would have to do it.
- State what would need to be true before a number on this dashboard could honestly be described as an estate-wide measurement.
Glossary terms used in this chapter
activity explorer · adaptive protection · browser data security · collection policy · CSPM · Defined from earlier chapters and reused here · device onboarding · DSPM · DSPM for AI · endpoint DLP · inline DLP · Insider Risk Management · Microsoft Compliance Extension · one-click policy · posture management · Purview · recommendation · SASE · SSE
Sources
Every Microsoft Learn page below was verified against the Microsoft Learn documentation service on 9 August 2026.
- Microsoft Learn, 'Microsoft Purview data security and compliance protections for generative AI apps'. learn.microsoft.com The reference for the category structure used in this chapter: Copilot experiences and agents, enterprise AI applications, and other AI applications detected through browser activity and categorised as generative AI in the cloud application catalogue. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Considerations for DSPM for AI to manage data security and compliance protections for AI interactions'. learn.microsoft.com The source of the policy-to-prerequisite map in this chapter, including that device onboarding and the browser extension are required for third-party AI site monitoring, that an Edge configuration policy activates browser integration, and the full list of one-click policies with their sources. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Learn about Data Security Posture Management for AI (classic)'. learn.microsoft.com Supports the description of the surface as a central management location offering insights, ready-to-use policies, data risk assessments and compliance controls, and carries the notice that this version is now the classic one, superseded by a broader posture management solution. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Use Microsoft Purview to manage data security and compliance for other AI apps'. learn.microsoft.com Supports the capability table used here, including that sensitivity labels and encryption are not supported for third-party AI interactions, that most capabilities require the browser extension and onboarded devices, and that retention and eDiscovery are restricted to the Edge browser and a named set of services. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Use Microsoft Purview to manage data security and compliance for ChatGPT Enterprise'. learn.microsoft.com Supports the claim that enterprise AI application integration is server to server and independent of device state. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Use Microsoft Purview to manage data security and compliance for Entra-registered AI apps'. learn.microsoft.com Supports the treatment of identity-registered AI applications as a distinct category with their own integration path. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Collection policies solution overview'. learn.microsoft.com Supports the dependency of prompt and response content on a collection policy configured to capture content. Last checked 9 August 2026; (high).
- Shadow AI Controls in Microsoft 365 E5, Behaviour by Windows Device State (this project's internal source report), section 8 and the concluding list of uncertain and evolving points. The source of the policy-to-device-state mapping this chapter renders as prose, and of the pay-as-you-go and renaming caveats.
Open questions
Microsoft's posture management surface for AI is documented as a classic version alongside a newer, broader posture management solution, and capability differences between them are still being described. Verify which version a tenant is using before mapping policies to prerequisites (medium).
The pay-as-you-go position for several capabilities in and around this category shifted more than once during 2025, and Australian education pricing is not published on Microsoft Learn. Check the tenant billing portal before quoting any figure (low).
The list of AI applications supported for each capability differs by capability, and several entries carry footnotes and preview status. Read the supported-sites page rather than assuming uniform coverage (medium).
Closing Part Four
Part Four set out to demystify the systems defenders actually work with, and the seven chapters have travelled outward from the device to the contract. The cloud service model decides which layers an organisation can instrument. The tenant decides where an audit trail can exist. The endpoint agent sees the connection and not the conversation. Discovery infers use from traffic and errs low in a knowable direction. Data loss prevention is a classification problem wearing an enforcement problem's clothes. The platform reflects the blind spots of its connectors. And the posture surface arranges all of it in one place without adding a sensor.
Where Part Three's constraint was the privilege boundary, Part Four's is the contract boundary. Every instrument in this part is either an inference drawn from traffic the organisation can still see, or a report from a service it has an agreement with. Where there is neither, there is nothing, and no product in the category alters that.
Which leaves the residue the manual has now approached from four directions. The staff member on their own device, with their own account, on their own network, typing into a service the organisation has no relationship with. Part One could not see it because of TLS. Part Two could not see it because the tenant never brokered the authentication. Part Three could not see it because nobody was permitted to install anything. Part Four cannot see it because there is no contract. Four layers, one answer, and it is not going to change.
At that point the interesting question stops being what can be built and becomes what should be. Under which Australian law, with what notice, at what level of invasiveness, after what consultation, and with what sanctioned alternative on offer. That is Part Five.
Last updated 9 August 2026