Status-first: how to read Microsoft's AI security stack without overstating your coverage
At any moment a single Microsoft product surface holds some controls that are Generally Available, some in Public Preview, and some still on the roadmap. A team that reads one launch blog and draws a coverage map from it ends up briefing leadership on protection it does not yet have.
The status is not hard to find. It is hard to trust. It sits across Microsoft Learn, the Microsoft 365 Roadmap, and the Message Center, and those three can disagree about the same capability on the same day.
I maintain a public capability-status matrix that records one row per Microsoft AI-security capability, with a status label, a primary-source URL, and the date the source was last read: microsoft-ai-security-control-plane. Everything below came out of keeping it current. Every Microsoft source named here was re-read on 15 August 2026, and the framework version pins in section 4 were verified on 9 and 10 August 2026.
1. "DLP for Copilot" is four behaviors on four schedules
Purview DLP for Microsoft 365 Copilot is usually discussed as one switch. The Learn page documents four separate protective behaviors, and they do not share a status.
Block sensitive information types in web search. Generally Available on the basis of Microsoft 365 Roadmap 548671, which reads status Launched with availability June CY2026. Learn's section for this behavior states no release stage at all, so of these two sources only the Roadmap record gives you one. The Roadmap record itself carries both General Availability and Preview release-phase tags.
Block sensitive information types in prompts. This one requires further validation, and it is the clearest example of why a coverage map needs more than one source. Learn states: "This feature is in preview and is rolling out to all tenants with access to Microsoft 365 Copilot and Copilot Chat." Roadmap 515945 reads status Launched, release phase General Availability, GA date March CY2026, on a record last modified 14 May 2026. The Learn page carries a content date of 10 June 2026 and a last-updated stamp of 17 July 2026, both later than that Roadmap record, and it still says preview. A page-level stamp does not prove anyone re-checked this particular sentence, which is why the row stays in validation rather than moving either way. Do not record this as GA.
Block files and emails with sensitivity labels from being processed. Generally Available on the basis of Roadmap 557255, which reads Launched with a GA date of April CY2026. Learn says "This feature is available in Microsoft 365 Copilot, Copilot Chat, and Copilot in Word, Excel, PowerPoint", which states availability without naming a release stage. The Roadmap record tags this one Current Channel alongside General Availability. Check what that means for your tenant's update channel before recording the date as yours. The page carries no instance of the phrase "generally available" anywhere in its visible text, for any of the four behaviors.
Block external email from being processed (preview). Public Preview per Learn, which tags the heading and repeats it in the body. Roadmap 561552 reads In development with a GA date of January CY2027. That record also carries both General Availability and Preview release-phase tags, so the phase field is multi-valued and proves little on its own. The sharper question is why a record whose status still reads In development carries a General Availability phase at all. Learn documents as shipping what the Roadmap describes as not yet shipped, which is the previous conflict running the other way. This behavior evaluates email metadata only, specifically the sender domain against your tenant's accepted domains. The body of the email is not inspected, so it is a sender-trust boundary rather than content inspection.
A note on where those field names come from. status, releasePhase and the record's modification date are fields of the Roadmap's machine-readable record, fetched by feature ID, rather than of the page a browser renders. Reading the record directly is what surfaced the dual release-phase tag on 548671, and it is what makes a status check repeatable by someone else instead of a screenshot you took once. The vocabulary differs by surface too: the Roadmap record calls this field releasePhase, Learn's Defender for Cloud availability table labels a row Release state, and the Purview page has no equivalent field at all, naming a stage for two of the four behaviors, once in body text and once in a heading, and none for the other two. Keep the three apart when you record them.
Five configuration facts belong in any design review of this policy location, all stated on the same Learn page. The Microsoft 365 Copilot and Copilot Chat policy location is available only in the Custom policy template. Selecting it disables all other locations in that policy. Those two together mean a Copilot DLP policy covers the Copilot location and nothing else, so you cannot extend an existing multi-location policy to reach Copilot; you have to stand up a separate one. A single rule cannot combine a sensitive-information-type condition with a sensitivity-label condition, so a policy covering both needs more than one rule. A policy change can take up to four hours to reflect in the Copilot experience, which sets the wait you have to plan into any test loop you build against these DLP settings.
The fifth is the one most likely to break a mental model. DLP cannot scan the contents of files uploaded directly into prompts. It only checks the text you type into the prompt itself.
Two of these four behaviors have Microsoft sources that contradict each other, and they contradict in opposite directions.
2. Defender for AI does not cover Microsoft 365 Copilot, and how you can tell matters
Defender for Cloud's AI threat protection is Generally Available. Its availability table on Learn gives the release state as "Generally available (GA)". Threat protection for AI agents built with Foundry ships inside the same Defender for AI Services plan but at a different release state, in preview, announced 2 February 2026.
What it produces is security alerts. Learn describes it working with Azure AI Content Safety Prompt Shields and Microsoft's threat intelligence to alert on threats such as data leakage, data poisoning, jailbreak and credential theft, and it integrates with Defender XDR so those AI workload alerts land in the same portal as the rest.
Its scope is the part people get wrong when drawing a diagram. Learn's availability table enumerates the supported AI services as Azure OpenAI supported models and Azure AI Model Inference service supported models. It scans text tokens only; image and audio tokens are not scanned. It runs in commercial clouds, with Azure Government, 21Vianet and connected AWS accounts all listed as No. That last entry is the one to carry into a multicloud design: AI workloads in a connected AWS account get nothing from AI threat protection.
Microsoft 365 Copilot and GitHub Copilot are not in that supported-services list. Drawing Defender for AI on a diagram as blanket "AI coverage" is a product-boundary error, and Microsoft 365 Copilot risk is addressed through different controls, principally Purview DLP for Microsoft 365 Copilot, DSPM for AI, and the permission and label posture on the underlying content, which Learn places first: a user must already have permission to access an item before it can appear in a prompt response.
There is a method point underneath that, and I learned it by getting it wrong in my own matrix. Absence from a list only means exclusion when the list is enumerating. Defender's availability table enumerates supported services, so an absence from it carries weight for services of the kind it lists. Not unlimited weight: that same table does not mention the AI-agent protection announced in February 2026, so even an enumerating list can lag the plan it describes. The table says less still about a product that is not an Azure AI service at all. That, rather than its silence, is the better reason the Microsoft 365 Copilot boundary holds. The CloudAppEvents advanced-hunting page introduces its covered applications with "such as", which makes that list illustrative, so an absence there is silence rather than denial. I had once read one of those lists as though it were the other. Before you treat a gap in documentation as a stated boundary, check which kind of list you are reading.
3. The Sentinel Copilot connector, and the hunting surface that does not exist
The Microsoft Copilot logs data connector for Microsoft Sentinel requires further validation, and the reason is a conflict inside one page. Learn's data-connectors reference carries a page-level notice that Microsoft Sentinel data connectors "are currently in Preview". The same page then suffixes only some individual entries "(Preview)", and the Microsoft Copilot entry carries none. Both signals cannot be authoritative at once.
Two further cautions on that connector. It is named "Microsoft Copilot" and its scope spans Security Copilot, so treating it as a Microsoft 365 Copilot control is a judgement rather than a quotation. And its destination table name is not confirmable on the Learn data-connectors reference, so treat the schema as provisional and confirm it in your own Sentinel workspace before you build on it.
The larger finding is about documentation that does not exist. The CloudAppEvents table reference documents no column or ActionType specific to Microsoft 365 Copilot chat prompts. By the test in the previous section that is silence rather than denial, so read it as what it is: not proof that no telemetry exists, but proof that there is nothing citable to build a detection on. A single documented ActionType would retire this finding, and no product change would be needed for that to happen. What exists instead is two adjacent surfaces at different release states. Prompt injection carried in email reaches advanced hunting through Defender for Office 365 as a detection-technology property, and carries no preview qualifier. AI-agent telemetry is explicitly public preview. Neither of those is Copilot chat.
This matters most for detection engineering. If a detection backlog assumes analysts can hunt Microsoft 365 Copilot chat prompts today, it rests on documentation that does not exist, so a query written against Copilot-specific field names is written against something you cannot cite. Confirm the table, the columns and the ActionType values in your own workspace before you write the logic. The way to do that is to survey what your own tenant actually emits for the application in question, rather than to start from a field name you read somewhere and hope it exists.
4. Map to framework items, and version the frameworks too
A cross-walk earns its keep when it maps a specific control to a specific framework item. Category-to-product mapping ("Purview covers data security") tells a reader nothing they can audit.
Frameworks move, and they move less visibly than products do. Four version pins that were current when I last read them:
OWASP Top 10 for LLM Applications, 2026 edition (v1.0), published by the OWASP GenAI Security Project, supersedes the 2025 edition (v2.0). The version numbers run backwards against the edition years, so pin a mapping to the edition year and treat the version string as secondary. Only LLM01 Prompt Injection and LLM02 Sensitive Information Disclosure kept their numbers. Supply Chain moved from LLM03:2025 to LLM04:2026. If a mapping still records Supply Chain as LLM03, it is pinned to the old edition. Worth knowing when you check: at the time I verified this, the OWASP landing page still presented the 2025 edition.
MITRE ATLAS, cited by technique and read from the distributed
atlas-datadataset (dist v5.6.0) rather than from memory. For this control set that means AML.T0051 LLM Prompt Injection (.000 Direct, .001 Indirect), AML.T0057 LLM Data Leakage, and AML.T0024 Exfiltration via AI Inference API.NIST AI 600-1 (Generative AI Profile, July 2024), cited by action ID in
<FUNCTION>-<subcat>-<seq3>form, for exampleGV-1.1-001, together with the relevant GAI risk such as 2.9 Information Security. The function name alone is not a mapping.CSA AI Controls Matrix (AICM) v1.1.1, cited by control-objective ID with the version label attached, for example UEM-11 Data Loss Prevention and DSP-17 Sensitive Data Protection. 247 control objectives across 18 domains.
Label the whole cross-walk as your own synthesis. It is not an official mapping by Microsoft, OWASP, MITRE, NIST or the CSA, and saying so is what keeps it usable.
Honest gaps belong in the same table as the controls, and they change too. Purview DSPM for AI audits by default and does not block by default: its discovery policies ship in audit mode only, and the one blocking policy ships in test mode. I still carry that row as requiring further validation. Enterprise governance of MCP servers is the one I had planned to record as a gap and reclassified before shipping: a non-overridable enterprise allowlist now exists, defined in an enterprise managed-settings file, evaluated deny-first and failing closed on a malformed or unretrievable policy. The residual limits are narrower than the original gap but still real, since client coverage reaches only the clients that support that settings file, third-party hosts are excluded, and built-in default servers are a permanent carve-out.
5. What to actually do
For every Microsoft AI-security capability in your coverage map, record five fields:
A status label: GA, Public Preview, Roadmap, or Requires further validation.
A primary-source URL.
The date you last read that source.
The date the source itself says it changed: the content date and last-updated stamp on a Learn page, the modification timestamp on a Roadmap record.
What the source actually said, quoted.
The last two fields are the ones people drop, and they are the ones that do the work. A quote lets you tell later whether the page changed or whether you read it wrong the first time, and those two failures need different fixes. The source's own change date tells you which rows to re-read first, and it is what exposed the conflict in section 1, where the Learn page carried a later date than the Roadmap record it disagreed with.
The rest comes down to three habits. Read a status from more than one Microsoft surface before recording it. Treat "Requires further validation" as a real status rather than a placeholder, and move a row out of it only on a specific documented finding. And date your framework versions the same way you date product statuses, because an edition change can silently invalidate a mapping that still looks correct.
Give all three a cadence. I re-verify every row monthly. Add a second trigger of your own: re-read whenever a source's own change date moves past the date you last read it. That is what fields 3 and 4 buy you together.
Then verify the contested items in your own tenant. A status you have not confirmed where it will actually run is a status you are quoting, not a control you have.
The matrix is public at microsoft-ai-security-control-plane, under MIT for the tooling and CC BY 4.0 for the content. If a row is wrong or has gone stale, the issue templates are there for exactly that.
