How to secure a Data & AI platform with Microsoft Defender
Where Defender ends and Purview begins, which plans to enable per data service, what AI threat protection does and does not see, and how the investigation path runs into Sentinel.
- 01
Split the roles before you enable anything
Four services all carry the word security and all four do something different. Defender is threat-centric, Purview is data-centric, Entra is identity-centric and Sentinel is centred on the investigation afterwards. A modern Data & AI platform needs all four, and if you do not write that split down first, you buy the same coverage three times and keep one gap.
Service What it watches What it does not do Microsoft Defender Threats, workload protection, cloud posture, attack paths Classify, label, retain Microsoft Purview Classification, labels, DLP, insider risk, audit, eDiscovery, lineage Attack paths and runtime threats Microsoft Entra Identity, Conditional Access, least privilege, agents included What happens to the data after access Microsoft Sentinel Cross-source correlation, long retention, hunting, automation Enforce policy on the workload itself The overlap sits in exactly one place, and it is worth naming. Defender for Cloud has data-aware security posture and a Data & AI security dashboard; Purview has DSPM. Both look at sensitive data, but with a different question: Defender asks how an attacker reaches it, Purview asks what it is, who may see it and how long you keep it.
Decisionwho owns which signal? Record per service who reads the alerts and who follows up the findings, before you enable the first plans. A service without an owner produces nothing but alerts. - 02
Enable Defender for Cloud everywhere, not only on production
Defender for Cloud is Microsoft's CNAPP and has three parts: CSPM for posture, DevSecOps for the pipeline and CWPP for the workloads. Start with Foundational CSPM on every subscription, including development and test. It costs you no plan and it closes the path attackers take most often: the environment everyone assumes is empty.
Defender CSPM on top is the second choice, and that one you do pay for. What you get back is the layer that turns a flat list of recommendations into priorities: attack path analysis, risk prioritization, the cloud security explorer, data security posture and AI posture.
# See what is enabled on this subscription today az security pricing list --query "value[].{plan:name,tier:pricingTier}" -o table # Defender CSPM for attack paths, data posture and AI posture az security pricing create --name CloudPosture --tier Standard # And the data services that matter in a Data & AI platform az security pricing create --name StorageAccounts --tier Standard az security pricing create --name CosmosDbs --tier StandardTreat secure score, recommendations and the compliance dashboard as a continuous loop rather than an annual audit activity. The regulatory compliance dashboard assesses your environment against standards, and that same result is what you see back in Purview Compliance Manager.
Pitfallenabling Defender on production only. Non-production then becomes the way in, and that is precisely where nobody looks. Apply CSPM and policy broadly, and only choose on risk when it comes to the paid workload plans. - 03
Choose workload plans on risk, not on completeness
CWPP is not one switch but a set of plans per service. For a Data & AI platform these are the plans that actually matter, and what each one adds.
Component Plan What it adds Data lake and object storage Defender for Storage Malware scanning, sensitive data threat detection, SAS misuse, Event Grid response Azure SQL and Synapse dedicated pools Defender for Azure SQL Vulnerability assessment, SQL injection, brute force, anomalous access Cosmos DB Defender for Azure Cosmos DB Injection variants, known bad actors, compromised identities, exfiltration AKS and containers Defender for Containers Runtime signals, Kubernetes posture, image assessment in ACR Compute and runtime nodes Defender for Servers Recommendations, Defender for Endpoint integration, agentless and secret scanning Key Vault Defender for Key Vault Unusual access attempts, with investigation and remediation guidance App Service Defender for App Service Attacks on web apps and APIs, plus dangling DNS risk Two things go wrong on this list more often than the rest. Defender for Storage is the plan you want on your landing zone the moment that zone also carries AI grounding data: a data lake without malware scanning is a fine staging area for whatever gets read out later. And Defender for App Service only produces usable investigation material when diagnostic logging is on; without those logs you get an alert without evidence.
ImportantAzure Databricks has no Defender plan of its own. Microsoft's Azure security baseline states in so many words that an offering-specific Defender solution for the service is not supported. So you cover Databricks with the surrounding controls: policy and compliance monitoring through Defender for Cloud, logging, Entra, private networking, Key Vault, Unity Catalog, Purview scanning and third-party vulnerability tooling where needed. - 04
Enable AI posture and AI threat protection, and know the boundary
AI security posture management is the discovery layer. It finds your Azure OpenAI, Microsoft Foundry and Azure Machine Learning workloads (as well as Amazon Bedrock and Google Vertex AI), assembles an AI bill of materials and shows which endpoints are externally reachable and which attack paths run through them. That is the question "what AI is actually running in my tenant", and at most customers it is unanswered.
AI threat protection is the runtime layer. It recognises generative AI attack patterns: data leakage, data poisoning, jailbreak, credential theft. The alerts land in the same stream as everything else, so your SOC needs no separate process for them.
If you want suspicious prompts included as evidence in the investigation, enable that only once you have worked through the privacy and compliance consequences and restricted the roles that may read it. A single prompt line can contain personal data that appears nowhere else in your logs.
NoteAI threat protection is GA and, according to Microsoft's availability table, supports text tokens only, for the supported Azure OpenAI and Azure AI Model Inference models. Image and audio tokens are not scanned. So do not assume full modality coverage for a multimodal application, and write that boundary down before you promise it to a customer.Decisionhow far do you go with agents? Agent-specific capabilities have moved toward Agent 365 licensing, while Defender CSPM continues to discover Foundry accounts and projects. Decide per agent scenario which of the two you need before you start on the architecture. - 05
Let Defender and Purview feed each other
The four integration points you actually use in practice:
- Compliance: regulatory compliance data from Defender for Cloud surfaces in Purview Compliance Manager, so cloud posture and organisation-wide compliance sit in one view.
- Sensitive data: sensitive data discovery in Defender for Storage leans on the sensitive information types and labels from Purview. A label that is right in Purview makes the storage alert immediately readable.
- Signals: DLP and insider risk alerts from Purview can flow into the Defender XDR and Sentinel investigation stream instead of landing in a mailbox of their own.
- AI interactions: with data security for AI interactions enabled, Purview can analyse prompts and responses, classify them and bring them under audit, retention and eDiscovery.
For the data platforms themselves, Purview is more often the route than Defender. For Microsoft Fabric, Microsoft's strongest public guidance is the Purview integration: the live view in the Unified Catalog, sensitivity labels through Information Protection, DLP for structured Fabric data, audit, insider risk indicators and governance for Fabric Copilots and agents. For Azure Data Factory and Azure Synapse you push lineage into Purview for the supported Copy, Data Flow, SSIS and pipeline activities; read the documented limitations around transformations and column level before you present that lineage as audit evidence.
Recommendationclassify, label and set up DLP before a broad Copilot or Fabric rollout, not after. Oversharing is not created by AI, but it is made visible by it, and then at AI speed. - 06
Build the investigation path with XDR and Sentinel
Defender XDR is the correlation layer: alerts from endpoints, identities, email, cloud apps and the other integrated services are grouped into incidents there. The investigation then follows a fixed route, and it is worth having your analysts walk it once: incident queue, summary, attack story, alerts, impacted assets, evidence and response, automated investigation, go hunt and the incident graph.
Sentinel joins the moment the investigation leaves Microsoft or has to outlive XDR retention. The integration takes over incidents and keeps them synchronised, can stream advanced hunting events, retains longer in Log Analytics and correlates with sources Defender does not see itself.
Decisionwhen Sentinel? As soon as an attack path runs through a non-Microsoft source, or as soon as your retention has to exceed what XDR offers by default. For a SOC working purely inside the Microsoft stack with short retention, XDR alone is a defensible choice.
Common mistakes
The eight you meet in almost every implementation:
| Mistake | Why it hurts | Better |
|---|---|---|
| Defender on production only | Non-production becomes the way in | CSPM and policy broadly, plans on risk |
| Secure score as the only priority | The score does not know your criticality | Add risk prioritization and attack paths |
| Everything on without choosing plans | Cost up, coverage still uneven | A plan per workload, chosen on risk |
| No diagnostic logs on App Service | An alert with no investigation material | Diagnostics on before the plan goes on |
| Treating Databricks as covered | A false assumption about coverage | Baseline, logging, Unity Catalog, Purview |
| Labels only after the Copilot rollout | Oversharing becomes visible at AI speed | Classify and label before the rollout |
| No Sentinel integration | Short retention, no view outside Microsoft | Integrate XDR and Sentinel |
| Selling preview as a commitment | Trust and delivery are both at risk | Record release state and licensing first |
What to do next
This guide covers the platform. The layer above it, where models, prompts and agents run, has its own choices; see How to secure AI workloads and agents. For the Purview side of step 5, How to set up Microsoft Purview data governance is the next guide, and if you run Databricks, How to set up Unity Catalog explains what belongs in the platform itself because Defender does not take it over there.
The process at a glance
Click a step for its key decision
Split the roles before you enable anything
who owns which signal? Record per service who reads the alerts and who follows up the findings, before you enable the first plans. A service without an owner produces nothing but alerts.
Read next
Related patterns
Related use cases
Related best practices