Enhancements to Device Status API & Logged-In User Email in Endpoint DLP
1. The Real‑World Problem Endpoint DLP analyst Faced (What Was Missing Earlier) Before the introduction of the Device Status API enhancements and logged‑in user visibility, Endpoint DLP teams consistently struggled in below discussed areas: Device Visibility Was Fragmented and Manual - Customers repeatedly told us: We know some devices are unhealthy, but we don’t know who owns them. We export the onboarding table to Excel every week just to understand drift. By the time we detect a policy issue, the user is already blocked or impacted. In practice, this meant: Device onboarding views were static snapshots, not operationally actionable. Admins relied on manual Excel exports to track onboarding, drift, and health. Reporting pipelines were brittle and always out of date. 2. Device Status API: Why Customers Asked for This (Beyond “Reporting”) The Hidden Cost of Excel‑Driven Operations as earlier, customers had to: Export device onboarding data manually. Rebuild dashboards every time they needed updated insight. Repeat this process weekly or even daily for compliance and SOC reviews. This approach failed at scale and created blind spots during incidents. When a device policy sync failed or appeared unhealthy, admins had no real‑time, view to answer basic questions like: Is this device configured correctly? Is the OS or Defender version lagging? Is the issue widespread or isolated? 3. What the Improvement Unlocks (New Operational Reality) From Static Views to Continuous Monitoring with the Device Status API: Device health, configuration status, policy sync state, OS version, and Defender version become query able signals Customers can power custom reporting and Advanced Hunting queries that are always current SOC and Endpoint teams finally share a single source of device truth This fundamentally changes how customers monitor Endpoint DLP not as a setup task, but as a living control plane. The Device Status API directly addresses this gap by making device‑level status continuously available through Advanced Hunting, allowing customers to build living dashboards instead of static reports. 4. The Old Workflow (Customer Pain) Historically, when a device showed: Policy Sync Failed Unhealthy Configuration mismatch Admins had to: Leave the Purview console Open Microsoft Defender for Endpoint or Intune Correlate device IDs or names Identify the user Start remediation This context‑switching cost time, accuracy, and confidence. 5. The New Reality: User Context Where It Matters Admins can now see who is logged in directly on the device onboarding page, aligning Windows with the macOS experience like: Immediate user context during device issues. Faster outreach and remediation. One unified investigative surface. What used to require three portals and multiple teams now happens in One Place. 6. When Customers Actually Needed This Data (But Didn’t Have It) This improvement wasn’t driven by curiosity it was driven by failure points in production. Some of the common customer scenarios listed below: Scenario Before Now / After Improvement Scenario 1: Quarterly Compliance Reviews Teams exported Excel files days before audits, resulting in stale data. Auditors questioned the reliability of reports. Advanced Hunting queries power live compliance dashboards. Reports are defensible because the data is always current. Scenario 2: Incident Post‑Mortems Teams struggled to answer whether devices were healthy at the time of the incident or if policies were enforced versus just configured. Reviews relied on assumptions. Device status, policy sync state, and OS/Defender versions are query able facts. Incident reviews shift from guesswork to evidence‑based analysis. Scenario 3: Silent Policy Drift Devices drifted due to OS updates, sensor lag, or configuration changes. Issues surfaced only after a DLP violation occurred. Policy drift becomes detectable before enforcement failures. Endpoint DLP acts as a reliability signal rather than a last‑line alarm. 7. New enhancement on Device Status API Device status API provides admins with access to device level information to integrate onboarded device information to custom reporting or use in advanced hunting queries. It has helped admins track down users associated with devices instead reaching out to Entra, on-premises Active Directory, or Intune team. During troubleshooting, if a device is not receiving policies on time, the device API allows quick identification of the device owner and assists in enabling always-on diagnostics or collecting logs directly from the device via Purview console. 8. Steps to capture User UPN Admin can find the device status by login to Security.microsoft.com as security admin. Click on Investigation and responses > Hunting > Advanced hunting. Device data can be found under DLPInfo JSON Column in the Deviceinfo table 3. Once we run above or any custom query as per requirement, you would see below as response. 4. Click on the loggedonuser field and expand the right-side information and look for DLPUPN under inspect record. 9. User login details on the Purview onboarding page Admins now can see who is currently logged in on the device onboarding page. This update aligns the Windows experience with macOS, allowing admins to respond quickly if necessary. In the past, when a device displayed a "Policy Sync Failed" or "Unhealthy" status, it was necessary to switch to Microsoft Defender for Endpoint (MDE) or Intune to identify the affected user. With this update, all relevant information is now accessible in a single view, streamlining the process. Benefits - Admins gain faster confirmation of device ownership and user context without extra investigation. It simplifies troubleshooting onboarding or policy issues by surfacing the user alongside other device insights like status and IP. No impact on users or DLP policies occurs, and it's enabled by default with no action required. 10.Steps to find User UPN on Purview admin console Login to Purview.microsoft.com with compliance admin > Select settings > Device onboarding > Select device Final Takeaway: Why This Matters More Than It First Appears "These enhancements evolve Endpoint DLP from a static, deployment‑centric control into a continuously observable, user‑context aware security signal, significantly reducing investigation time, operational overhead, and trust gaps at scale"Extend Microsoft Purview data protection to AWS Bedrock agents for cross-cloud AI governance
Organizations are moving fast with AI, and many of those AI workloads are not staying in one cloud. A team might use Microsoft 365 and Microsoft Purview for governance and in addition to Microsoft Foundry they may still choose to run an AI agent on AWS Bedrock or on the Google Cloud Platform. The technical challenge is straightforward: how do you keep one consistent set of data security, governance, and compliance controls when the agent itself runs outside Microsoft Azure? This is where Microsoft Purview becomes the central policy engine for your data estate. In this post, we show why that matters and then walk through a practical example: an expense approval agent running on Amazon Bedrock, protected by Microsoft Purview Data Loss Prevention (DLP) policies. Why Purview should be the central policy engine Most organizations do not want separate policy stacks for every cloud, every model endpoint, and every app team. That leads to duplicated controls, inconsistent enforcement, and audit gaps. The better model is to separate where workloads run from where policy decisions are made. That is the value proposition for Microsoft Purview in cross-cloud AI scenarios. Purview gives you: A consistent policy layer for sensitive information types such as credit card numbers, Social Security numbers, financial data, and other regulated content. A governance plane that can extend beyond Microsoft-hosted workloads into multi-cloud environments. A compliance framework with auditability, policy traceability, and a familiar operational model for security and compliance teams. A way to apply data-aware controls to AI interactions, not just to storage locations. In practical terms, that means the same organization that already trusts Purview to govern Exchange, SharePoint, Teams, and Copilot can use Purview to govern prompts and responses in a Bedrock-based agent as well. The key architectural shift is this: your app does not need to invent its own data policy engine. It can call Purview at the points where risk exists. What this Bedrock agent demonstrates The sample solution in this blog is a cross-cloud AI pattern: The frontend is a single-page browser-based chat app. Users authenticate with Microsoft Entra ID via MSAL. The backend runs in AWS Lambda. The model is Amazon Bedrock using Nova 2 Lite. Microsoft Purview evaluates prompts and model responses for DLP policy violations. This matters because it proves a broader point: Microsoft Purview can govern AI interactions even when the model and compute are not running in Azure. The core architecture As shown above the end-to-end flow follows this pattern: A user signs in through Microsoft Entra ID from the frontend. The frontend sends the user's access token and prompt to an API endpoint in AWS. The Lambda function exchanges that token using the On-Behalf-Of flow so Purview can evaluate under the signed-in user's identity. Purview scans the full prompt for sensitive information before the model is called. If the prompt is allowed, the Lambda function sends the request to Amazon Bedrock. Purview scans the model response before it is returned to the user. The frontend shows the result along with a Purview evaluation badge. That gives you two strong governance controls: In-line data loss prevention enforcement, which can block risky requests before they ever reach the model. Response-time enforcement, which can stop sensitive data from being returned even if a model generates it. The implementation also uses the user's identity for policy evaluation. That is important because governance decisions should reflect who is asking, not just what application is running. Why this pattern is useful for security, governance, and compliance teams There are three reasons this pattern is worth paying attention to. First, it aligns policy with risk rather than with hosting location. The compute might run in Lambda and the model might be in Bedrock, but Purview still remains the policy decision point. Second, it improves operational clarity. Security teams do not have to learn a different governance toolchain for each AI stack. They can keep using Purview concepts, policy models, and audit workflows. Third, it supports real-world adoption. Most large enterprises are hybrid and multi-cloud already. A governance pattern that only works for one vendor's runtime is not enough. Policy definition in Purview Two polices are needed to enforce DLP-a collection policy for Enterprise AI Apps and a DLP policy Collection policy 2. DLP policy Follow the steps outlined here to create the DLP policy for Enterprise AI Apps. Sample provided: purview-api-samples/DLPforCustomAIApps at main · microsoft/purview-api-samples To replicate this scenario, follow this link to the official GitHub repo: purview-api-samples/AWSBedrock at main · microsoft/purview-api-samples Once deployed, you will have: An AWS Lambda function that calls Amazon Bedrock. A browser frontend that authenticates with Microsoft Entra ID. Microsoft Purview evaluating both prompts and responses. A demo flow where safe prompts succeed and sensitive prompts are blocked. With the App and agent deployed, now comes the moment when the architectural value becomes clear. The model runtime is AWS Bedrock, but the policy decision is still coming from Microsoft Purview. Below screenshot shows the prompt containing sensitive information being blocked based on the policy evaluation by Purview. Minimal code integration requirements using the SDK Below is the code needed to perform the integration between Purview and Bedrock to perform the in and outbound inspection of content destined to and from the Bedrock model. Results of Purview’s verdict presented to user in the App UI Review governance evidence in Purview Data Security Posture Management Summary The bigger story here is not just that Microsoft Purview can protect an Amazon Bedrock agent. It is that organizations can centralize data security, governance, and compliance policy even while their AI architecture becomes more distributed across multiple clouds. That is the operational win. Developers keep the freedom to choose the best runtime and model platform. Security and compliance teams keep a central policy engine they already understand and trust. AI applications can be multi-cloud, but your data protection model does not have to be fragmented. Additional resources Configure Microsoft Purview - purview-sdk | Microsoft Learn Microsoft Purview Developer Platform Documentation - purview-sdk | Microsoft LearnMicrosoft Purview Referential Architecture Diagrams
Microsoft Purview architecture diagrams provide a reference view of how classification, sensitivity labelling, Data Loss Prevention (DLP), Insider Risk Management, and Microsoft 365 Copilot protections work together across Microsoft 365 workloads. They illustrate how organisations can consistently identify, label, and protect sensitive data across endpoints, email, collaboration services, browsers, and AI‑assisted workflows—without prescribing a single deployment model. Classification generates sensitivity signals, labels express organizational protection intent, and DLP enforces that intent in real time across devices, apps, and services. Together, these patterns show how Copilot inherits existing security controls so AI‑generated content remains governed within the same compliance boundaries as organizational data.Endpoint DLP Collection Evidence on Devices
Hello team, I am trying to setup the feature collect evidence when endpoint DLP match. Official feature documentation: https://learn.microsoft.com/en-us/purview/dlp-copy-matched-items-learn https://learn.microsoft.com/en-us/purview/dlp-copy-matched-items-get-started unfortunately, it is not working as described in the official documentation, I opened ticket with Microsoft support and MIcrosoft Service Hub, Unfortunatetly, they don't know how to setup it, or they are unable to solve the issue. Support ticket: TrackingID#26040XXXXXXX9201 Service Hub ticket: https://support.serviceshub.microsoft.com/supportforbusiness/onboarding?origin=/supportforbusiness/create TrackingID#26040XXXXXXXX924 I follow the steps to configure: based on the Microsoft documentation, I should be able to see the evidence in Activity explorer or Purview DLP alert or Defender Alerts/Incidents.
Set Up Endpoint DLP Evidence Collection on your Azure Blob Storage
Endpoint Data Loss Prevention (Endpoint DLP) is part of the Microsoft Purview Data Loss Prevention (DLP) suite of features you can use to discover and protect sensitive items across Microsoft 365 services. Microsoft Endpoint DLP allows you to detect and protect sensitive content across onboarded Windows 10, Windows 11 and macOS devices. Learn more about all of Microsoft's DLP offerings. Before you start setting up the storage, you should review Get started with collecting files that match data loss prevention policies from devices | Microsoft Learn to understand the licensing, permissions, device onboarding and your requirements. Prerequisites Before you begin, ensure the following prerequisites are met: You have an active Azure subscription. You have the necessary permissions to create and configure resources in Azure. You have setup endpoint Data Loss Prevention policy on your devices Configure the Azure Blob Storage You can follow these steps to create an Azure Blob Storage using the Azure portal. For other methods refer to Create a storage account - Azure Storage | Microsoft Learn Sign in to the Azure Storage Accounts with your account credentials. Click on + Create On the Basics tab, provide the essential information for your storage account. After you complete the Basics tab, you can choose to further customize your new storage account, or you accept the default options and proceed. Learn more about azure storage account properties Once you have provided all the information click on the Networking tab. In network access, select Enable public access from all networks while creating the storage account. Click on Review + create to validate the settings. Once the validation passes, click on Create to create the storage Wait for deployment of the resource to be completed and then click on Go to resource. Once the newly created Blob Storage is opened, on the left panel click on Data Storage -> Containers Click on + Containers. Provide the name and other details and then click on Create Once your container is successfully created, click on it. Assign relevant permissions to the Azure Blob Storage Once the container is created, using Microsoft Entra authorization, you must configure two sets of permissions (role groups) on it: One for the administrators and investigators so they can view and manage evidence One for users who need to upload items to Azure from their devices Best practice is to enforce least privilege for all users, regardless of role. By enforcing least privilege, you ensure that user permissions are limited to only those permissions necessary for their role. We will use portal to create these custom roles. Learn more about custom roles in Azure RBAC Open the container and in the left panel click on Access Control (IAM) Click on the Roles tab. It will open a list of all available roles. Open context menu of Owner role using ellipsis button (…) and click on Clone. Now you can create a custom role. Click on Start from scratch. We have to create two new custom roles. Based on the role you are creating enter basic details like name and description and then click on JSON tab. JSON tab gives you the details of the custom role including the permissions added to that role. For owner role JSON looks like this: Now edit these permissions and replace them with permissions required based on the role: Investigator Role: Copy the permissions available at Permissions on Azure blob for administrators and investigators and paste it in the JSON section. User Role: Copy the permissions available at Permissions on Azure blob for usersand paste it in the JSON section. Once you have created these two new roles, we will assign these roles to relevant users. Click on Role Assignments tab, then on Add + and on Add role assignment. Search for the role and click on it. Then click on Members tab Click on + Select Members. Add the users or user groups you want to add for that role and click on Select Investigator role – Assign this role to users who are administrators and investigators so they can view and manage evidence User role – Assign this role to users who will be under the scope of the DLP policy and from whose devices items will be uploaded to the storage Once you have added the users click on Review+Assign to save the changes. Now we can add this storage to DLP policy. For more information on configuring the Azure Blob Storage access, refer to these articles: How to authorize access to blob data in the Azure portal Assign share-level permissions. Configure storage in your DLP policy Once you have configured the required permissions on the Azure Blob Storage, we will add the storage to DLP endpoint settings. Learn more about configuring DLP policy Open the storage you want to use. In left panel click on Data Storage -> Containers. Then select the container you want to add to DLP settings. Click on the Context Menu (… button) and then Container Properties. Copy the URL Open the Data Loss Prevention Settings. Click on Endpoint Settings and then on Setup evidence collection for file activities on devices. Select Customer Managed Storage option and then click on Add Storage Give the storage name and copy the container URL we copied. Then click on Save. Storage will be added to the list. Storage will be added to the list for use in the policy configuration. You can add up to 10 URLs Now open the DLP endpoint policy configuration for which you want to collect the evidence. Configure your policy using these settings: Make sure that Devices is selected in the location. In Incident reports, toggle Send an alert to admins when a rule match occurs to On. In Incident reports, select Collect original file as evidence for all selected file activities on Endpoint. Select the storage account you want to collect the evidence in for that rule using the dropdown menu. The dropdown menu shows the list of storages configured in the endpoint DLP settings. Select the activities for which you want to copy matched items to Azure storage Save the changes Please reach out to the support team if you face any issues. We hope this guide is helpful and we look forward to your feedback. Thank you, Microsoft Purview Data Loss Prevention Team
DLP Policy - DSPM Block sensitive info from AI sites
Having issues with this DLP policy not being triggered to block specific SITs from being pasted into ChatGPT, Google Gemine, etc. Spent several hours troubleshooting this issue on Windows 11 VM running in Parallels Desktop. Testing was done in Edge. Troubleshooting\testing done: Built Endpoint DLP policy scoped to Devices and confirmed device is onboarded/visible in Activity Explorer. Created/edited DLP rule to remove sensitivity label dependency and use SIT-based conditions (Credit Card, ABA, SSN, etc.). Set Paste to supported browsers = Block and Upload to restricted cloud service domains = Block in the same rule. Configured Sensitive service domain restrictions and tested priority/order (moved policy/rule to top). Created Sensitive service domain group for AI sites; corrected entries to hostname + prefix wildcard a format (e.g., chatgpt.com + *.chatgpt.com) after wildcard/URL-format constraints were discovered. Validated Target domain = chatgpt.com in Activity Explorer for paste events. Tested multiple SIT payloads (credit card numbers with/without context) and confirmed detection occurs. Confirmed paste events consistently show: Policy = Default Policy, Rule = JIT Fallback Allow Rule, Other matches = 0, Enforcement = Allow (meaning configured rules are not matching the PastedToBrowser activity). Verified Upload enforcement works: “DLP rule matched” events show Block for file upload to ChatGPT/LLM site group—proves domain scoping and endpoint enforcement works for upload. Disabled JIT and retested; paste events still fall back to JIT Fallback Allow Rule with JIT triggered = false. Verified Defender platform prerequisites: AMServiceVersion (Antimalware Client) = 4.18.26020.6 (meets/exceeds requirements).Deploy scalable ring‑fenced Purview operations with Administrative Units
As Microsoft Purview deployments mature, many organisations encounter the same scaling challenge: how do you decentralize operations without fragmenting governance or losing visibility? Administrative Units (AUs) provide a native way to solve this by enabling ring‑fenced operations—allowing teams to operate independently within clearly defined boundaries, while preserving central oversight. This post focuses on the why behind using Administrative Units in Microsoft Purview, with a particular emphasis on scalable, ring‑fenced operations. We’ll walk through three reference architectures that illustrate how Administrative Units support real‑world operating models—without requiring multiple tenants or separate DLP platforms. note: this article and visuals will focus on Administrative Units support in Purview Data Loss Prevention. However, Administrative Units are supported in additional solutions of Microsoft Purview. Refer to Administrative units in Microsoft Purview | Microsoft Learn for more details and support. Why Administrative Units matter for scalable operations Many large organisations operate with decentralized compliance and DLP teams, often aligned to regions, business units, or regulated functions. Historically, this led to one of two sub‑optimal patterns: Multiple, disconnected DLP solutions or tenants Centralized teams managing policies and alerts for parts of the business they don’t own Administrative Units change this model by allowing organisations to: Partition users (and supported resources) into logical units Assign restricted administrators who can only see and act within their unit Apply both global and AU‑scoped policies together, with predictable behavior From a Purview perspective, this enables true business function autonomy, enforced through RBAC and data visibility boundaries, while keeping global services—such as classification—centralized. Reference architecture 1: Layered governance with ring‑fenced operations Scenario An organisation wants to migrate from multiple legacy DLP solutions into Microsoft Purview while preserving independent operations for each business function or region. Architecture highlights This model introduces three distinct layers: Central governance (Global) Global administrators define baseline policies applicable across the tenant Shared services such as classifiers and reusable components remain central Central teams retain cross‑tenant monitoring and reporting capabilities Administrative Units (per business function) Each business function or region is mapped to an Administrative Unit RBAC, policy visibility, and alert management are strictly scoped to the AU Policies created here only affect users within that unit Business function‑level operations Scoped DLP admins manage local policies Alerts and incidents are handled by the owning team Controls can be tuned to meet specific regulatory or operational needs Why this matters This architecture enables a phased migration: Start with a single entity Gradually scale across additional business functions Avoid policy sprawl by consolidating and retiring legacy configurations Crucially, tenant‑wide limits and global services remain unchanged, ensuring consistent performance as scale increases. Reference architecture 2: Ring‑fencing user activity visibility to sub‑business functions Scenario “We have dedicated DLP analysts for executives. DLP alerts and activities for these users must only be visible to that team.” Architecture highlights This model refines the first architecture and allowing to have DLP analysts for a subset of users only. Executive users are placed into a dedicated Administrative Unit representing a subset of users of a business unit. Policies can be published to multiple Administrative Units (ex: Americas + Americas - Execs) In this model: Some DLP administrators may be assigned to multiple AUs so they can publish policies across them Users must belong to a single AU to ensure clean visibility boundaries Why this matters This pattern is particularly effective for: Executive monitoring HR or Legal teams Highly sensitive populations It delivers strict separation of duties without duplicating policies or creating isolated tenants, and aligns with how Purview scopes alerts, activity explorer, and audit data when Administrative Units are used. Reference architecture 3: User activity visibility for multi‑AU users Scenario Some users operate across multiple business functions—for example, executives or shared service leaders—while still requiring controlled visibility for analysts. Architecture highlights User activities are stamped with the sum of all Administrative Units the user belonged to at the time of the activity Scoped DLP administrators: Can only create policies affecting users within their assigned AU. However the sum of their policies will be applicable. Scoped DLP analysts: See all activities for users in their AU, even if those activities were generated by policies scoped to a different AU. Why this matters This model ensures: No loss of investigative context for analysts Predictable visibility when users span multiple organizational boundaries Continued enforcement of AU‑based separation of duties It also reinforces a key principle: Administrative Units control visibility and management scope — not the existence of the underlying activity data. Once a user's in scope of a policy, its related activities/alerts are visible to DLP analysts allowed to review this user's activities. When not to use Administrative Units Administrative Units are a powerful enabler for decentralized, ring‑fenced operations—but they are not required in every Purview deployment. You may choose not to introduce Administrative Units in the following situations: Single, centralized compliance team. If one team owns all policy creation, alert triage, and investigations across the organisation—and there is no requirement to restrict visibility—Administrative Units add limited value. In this model, global role groups already provide sufficient control. No need for visibility or management separation. Administrative Units are primarily about scoping visibility and permissions. If all administrators are expected to see all users, alerts, and activities, AU‑based scoping may introduce unnecessary complexity without operational benefit. Early or small‑scale Purview deployments. Organisations at an early stage of Purview adoption—running a small number of global policies—may find it simpler to start without AUs and introduce them later as operating models mature. Administrative Units do not change tenant limits or global services, so adoption can be phased over time. Requirements driven purely by policy targeting. If the primary requirement is targeting users dynamically for policy application (rather than restricting administrator access or visibility), adaptive scopes alone may be sufficient. Administrative Units become relevant when who can see and manage data is as important as which users are in scope. In short, Administrative Units are best introduced when organisations need to scale operations with clear ownership boundaries, not simply to organise users. Centralized vs. Decentralized Functions in a Ring‑Fenced Operating Model A scalable Microsoft Purview operating model relies on a deliberate split between functions that remain centralized at the tenant level and those that are decentralized to business functions or regions via Administrative Units (AUs). This balance enables autonomy without fragmentation, preserving global consistency while allowing teams to operate independently within defined boundaries. Functions that Remain Centralized Certain capabilities are intentionally retained at the global (tenant) level to ensure consistency, performance, and governance across the organisation. These functions are not delegated to Administrative Units: Global governance and baseline policy definition Central teams define tenant‑wide baseline policies that apply consistently across all users, regardless of AU membership. This ensures minimum protection standards and avoids divergent interpretations of risk. Shared services and reusable components Core services such as classifiers and other reusable components remain centralized to prevent duplication, reduce administrative overhead, and maintain consistent detection behavior across the tenant. Cross‑tenant monitoring and reporting Central teams retain visibility across Administrative Units for monitoring, reporting, and oversight purposes, ensuring that decentralization does not result in blind spots at the organizational level. Tenant‑wide limits and platform behavior Administrative Units do not alter tenant‑wide service limits or global platform characteristics. Keeping these aspects centralized ensures predictable performance and scalability as additional business functions are onboarded. Functions that Are Decentralized via Administrative Units Operational responsibility is decentralized to business functions or regions by mapping them to Administrative Units, with strict scoping enforced through RBAC and data visibility boundaries: Policy creation and management scoped to the AU Business function teams can create and manage policies that only affect users within their Administrative Unit, allowing controls to be tailored to local regulatory or operational requirements without impacting other parts of the organisation. Scoped visibility of alerts, activities, and incidents Administrators and analysts assigned to an AU can only see alerts, activities, and incidents for users in that unit. This enforces separation of duties and prevents unintended access to sensitive data belonging to other functions. Local alert handling and incident response Decentralized teams own the investigation and remediation of alerts generated within their AU, enabling faster response times and clearer accountability. Operational tuning per business function Controls can be adjusted within an AU to reflect specific risk tolerances, regulatory obligations, or operational realities, without creating policy sprawl or requiring separate tenants. Why This Split Matters By clearly separating centralized governance and shared services from decentralized, AU‑scoped operations, organisations can scale Purview deployments in a phased and controlled manner—starting with a single business function and expanding over time—while maintaining consistent governance, visibility, and performance across the tenant. Key takeaways Administrative Units in Microsoft Purview are not just a permissions feature—they are an operating model enabler. Used correctly, they allow organisations to: Scale decentralized operations with confidence Enforce ring‑fenced visibility and management boundaries Combine global consistency with local autonomy For organisations planning large‑scale Purview deployments or consolidating legacy compliance tooling, Administrative Units provide a foundational architecture for sustainable growth. Learn more Administrative units in Microsoft Purview (presentation) Administrative units in Microsoft Purview | Microsoft LearnFrom Oversharing to Enforcement: A Practical Guide to AI Data Security with Microsoft Purview
Why AI Changed the Data Security Problem AI does not create entirely new categories of risk—it supercharges existing ones. Traditional data leakage stems from ordinary behavior: sharing a document too broadly, sending an email to the wrong person, copying regulated data to an uncontrolled device. Generative AI amplifies all of these because of the power and speed with which it can proactively surface content that may be obsolete, over-permissioned, or ungoverned. DSPM exists to help with exactly this challenge: it continuously scans your environment to identify sensitive data, assess risk, and recommend actions to reduce exposure. Oversharing at Scale Before AI, an overshared SharePoint file might sit unnoticed. Now, Copilot can summarize it in response to a casual prompt, distributing its contents far beyond the original audience. Prompt Leakage Users can inadvertently expose sensitive information—financial account numbers, health records, project code names—simply by typing them into a Copilot prompt. Because AI interactions feel conversational, users tend to drop their guard. Shadow AI Beyond sanctioned tools, employees experiment with unapproved AI services. Autonomous Agents Autonomous agents expand the data security threat surface by acting independently on sensitive information across systems and boundaries. Their ability to access and share data without direct user interaction increases the risk of oversharing, exfiltration, and unauthorized access, while also introducing complex behavior patterns that are harder to monitor, govern, and control using traditional security models. What Microsoft Purview Now Brings Together Data Security Posture Management (DSPM) DSPM consolidates insights from Data Loss Prevention (DLP), Insider Risk Management, Information Protection, and Data Security Investigations into a single view for monitoring data risks, policy coverage, and posture trends. Now also in Public Preview, DSPM extends coverage to third-party SaaS and IaaS platforms such as Google Cloud Platform, Snowflake, and Databricks, and integrates with partner solutions including Cyera, BigID, and OneTrust for comprehensive risk insights. A central innovation in this version is data security objectives—prominent, selectable cards that each represent a specific security goal. Selecting an objective guides administrators through an end-to-end workflow that groups together the most relevant Purview solutions—information protection, DLP, Insider Risk Management, and eDiscovery—so teams can focus on achieving a specific data security outcome rather than navigating separate solutions. Each Outcome card displays key metrics such as the percentage of data covered by policies, the number of risky sharing incidents, and improvements over time. Within each outcome, DSPM surfaces suggested prioritized actions—applying sensitivity labels, configuring DLP policies, or investigating alerts—all tailored to the organization's data. Administrators can take action directly from the workflow, including remediating oversharing, configuring one-click policies, or launching investigations into suspicious activity. DLP Integration for AI Interactions DLP is one of the core solutions integrated into DSPM's unified approach. The Activity Explorer's AI activities tab captures events where DLP rules were matched during AI interactions—including prompts, responses, and browsing to generative AI sites. DSPM can automate remediation steps such as removing public sharing links or applying data loss prevention policies to help prevent incidents before they happen. AI Observability and Agent Governance Dedicated dashboards and metrics monitor risks associated with AI apps and agents. AI observability enables tracking of agent-specific activities—oversharing, exfiltration, and unusual access patterns—across both Microsoft and third-party environments. Enhanced reporting provides advanced filtering and customizable views, supporting granular analysis of sensitive data usage, DLP activity, and posture trends. Audit logs and activity explorer features help track interactions with AI apps and agents, supporting compliance investigations and incident response. AI-Powered Security Operations DSPM not only secures and governs AI apps and agents but also uses Microsoft Security Copilot and AI agents to help secure and govern data. AI analyzes access patterns, sharing behaviors, and policy gaps to surface actionable risks and can detect unusual activity such as excessive sharing or suspicious downloads. Under administrator guidance, AI agents can take direct action on detected risks—removing public sharing links, applying DLP policies, or revoking permissions. These actions are always audited. To streamline investigations, AI-driven triage agents review alerts from DLP and Insider Risk Management solutions, filtering out noise and highlighting the most critical threats. Three Practical Starting Points For many organizations adopting generative AI, the biggest hurdle isn't recognizing new risks—it's figuring out where to begin. A "boil the ocean" approach can stall progress, while tackling a few targeted areas delivers quicker wins. The best early moves are those that reduce exposure quickly, improve visibility, and build a foundation for stronger governance over time. Starting Point 1: Enable prompt-level protection for Microsoft 365 Copilot An effective first step is to put guardrails on the prompts users enter into AI. Microsoft Purview DLP allows administrators to restrict Microsoft 365 Copilot and Copilot Chat from processing prompts that contain sensitive information. In practice, users are often more comfortable pasting data into a chat prompt than attaching it to an email, which means a well-meaning employee could inadvertently feed a confidential file or personal data into Copilot. Enabling prompt-level DLP creates an immediate safety net: if a user's prompt includes, say, a credit card number or a customer's national ID, Copilot will detect it and refuse to process or share that content. DSPM provides suggested prioritized actions—including configuring DLP policies—that can be activated directly from the workflow, and recommended policies can start in simulation mode. Simulation mode lets you see what would have been blocked or flagged, without actually interrupting users, so you can fine-tune the policy and prepare your helpdesk for any questions. Once you're comfortable with the results, switching to enforcement mode will actively block disallowed prompts and log those events for review. By activating this one control, you've significantly reduced the most immediate oversharing risk—the "oops, I pasted the wrong data" scenario—within hours of starting your AI governance program. Tradeoff: Simulation mode provides safety but delays enforcement. For organizations with imminent regulatory exposure, consider shortening the simulation window and monitoring alert volumes closely. Starting Point 2: Gain visibility into shadow AI usage before broad enforcement The second step is to illuminate what's happening in the shadows. Before rushing into blocking every unsanctioned AI tool, it's crucial to understand how and where AI is being used across the organization. In most enterprises, there's an official layer of AI usage and an often larger, unofficial layer—employees experimenting with free online AI chatbots, writing assistants, or code generators. DSPM provides this visibility. The Discover > Apps and agents dashboard shows AI apps used across the organization, including the top 20 most recently used agents, with details about sensitive data they accessed and how they are protected by Purview policies. The AI observability page provides a broader inventory of all AI apps and agents with activity in the last 30 days, including how many are high risk and the total with sensitive interactions. The Activity Explorer's AI activities tab shows when users browsed to generative AI sites, the prompts and responses involved, whether sensitive information was present, and whether DLP rules were matched. Armed with this insight, you can make informed decisions. If you discover that the majority of "AI consumption" comes from just two external apps, you might focus your immediate controls on those two. Conversely, if the data shows most unsanctioned usage is low-risk, you might decide to monitor rather than block it. The key is visibility first, enforcement second—letting real data guide where to tighten controls versus where to offer secure alternatives. Tradeoff: Visibility without timely follow-through can create a false sense of security. Set a defined window (e.g., 30 days) after which findings must translate into at least one concrete policy action. Starting Point 3: Operationalize DSPM objectives for Copilot A stronger third starting point is to use DSPM as your operational guide, not just a dashboard of charts. DPSM introduces data security objectives—each one a focused end-to-end workflow for a specific outcome. Rather than configuring individual features in isolation, you select an objective and let Purview navigate you through achieving that outcome with the relevant tools. For generative AI, the key objective to leverage early is "Prevent data exposure in Microsoft 365 Copilot and Microsoft Copilot interactions". By selecting this objective in the Purview portal, you're effectively telling Purview, "help me implement whatever is needed to make Copilot safe with our data." The DSPM interface then groups together the critical pieces: it may prompt you to enable a DLP policy, suggest applying or refining sensitivity labels on content, or surface an Insider Risk Management policy template for detecting AI-related risky behavior. It also surfaces metrics so you can track progress—for example, the percentage of data covered by policies, or the number of risky sharing incidents that have been remediated. Using DSPM objectives keeps your team aligned on a clear goal from day one. It shifts the conversation from "what knobs do we turn on?" to "how do we achieve this outcome?" You follow a guided plan curated by the platform's intelligence rather than navigating five different admin pages and hoping it adds up to protection. Tradeoff: Objectives streamline the path but can obscure the underlying complexity. Teams should periodically step outside the guided workflow to review the full policy landscape and ensure no coverage gaps exist between objectives. From Visibility to Remediation: Turning Insights into Action Automated Remediation at Scale DSPM can automate remediation steps such as removing public sharing links or applying data loss prevention policies to prevent incidents before they happen. Under administrator guidance, AI agents within DSPM can take direct action on detected risks—removing sharing links, applying DLP policies, or revoking permissions—and these actions are always audited. This moves the operating model from manual, one-at-a-time fixes to systematic, policy-driven remediation. Closing the Loop: From Risk to Standing Policy DSPM's data security objectives surface suggested prioritized actions such as applying sensitivity labels, configuring DLP policies, or investigating alerts, all tailored to the organization's data. Reporting and analytics are organized by outcome, making it easier to identify and report improvements, compliance, and risk reduction. This turns recurring findings into standing preventive controls. Instead of re-running assessments and manually fixing the same patterns, administrators create durable policies that enforce the desired state going forward. Alert-Driven Investigation and Tuning Audit logs and activity explorer features help track interactions with AI apps and agents, supporting compliance investigations and incident response. Integrated investigation and forensics tools support rapid incident response and root cause analysis for data security events. Impact prediction visuals and progress tracking for remediation steps are surfaced throughout DSPM, enabling administrators to quantify the effect of their actions and adjust course. The closed-loop process is: Discover (DSPM scans and risk assessments) → Remediate (automated actions and bulk fixes) → Prevent (create or tighten DLP and auto-labeling policies) → Monitor (alert review, investigation, and policy tuning). What "Good" Looks Like in a Regulated or Risk-Aware Organization A mature AI governance posture is defined by measurable outcomes and sustainable operating rhythms—not feature count: Clear, communicated AI usage policies. Users know what is and is not acceptable in AI interactions because the tools reinforce the rules. DLP policy tips delivered at the moment of a violation are a primary training mechanism—they remind users in context why their prompt was blocked and what to do instead. Measured enablement over blanket bans. Leading organizations allow Copilot with appropriate controls and restrict only truly unacceptable scenarios. Policies deployed initially in simulation mode provide data to calibrate enforcement thresholds before blocking. This avoids productivity backlash while preserving security posture. High data hygiene and classification rates. Purview's AI protections depend heavily on sensitivity labels. If everything is unlabeled or "General," label-based controls have nothing to act on. Mature organizations invest in auto-labeling and mandatory labeling to close this gap before deploying AI at scale. DSPM's data security objectives include suggested actions such as applying sensitivity labels, directly tying classification to governance outcomes. Quantifiable risk reduction. Security leadership can produce metrics from Purview that show trend lines: DSPM Outcome cards display the percentage of data covered by policies, the number of risky sharing incidents, and improvements over time. These figures feed directly into compliance reporting and audit evidence. Key metrics are tracked over time, supporting continuous improvement of the organization's data security posture. Cross-functional governance. AI governance is not a solo IT Security effort. Stakeholders from security, compliance, legal, and business units review AI usage patterns, discuss policy tuning, and evaluate new Purview capabilities as they release. Role-based access controls within DSPM provide granular access to features and AI content for delegated administration and compliance, enabling this cross-functional model without overexposing sensitive data to every participant. Tradeoff: Strict enforcement can frustrate power users and slow AI adoption. Organizations should explicitly define escalation paths—if a legitimate use case is blocked by DLP, there must be a fast process to review and adjust, rather than a permanent "no." A Phased Adoption Model Phase Focus Key Activities Phase 1 — Quick Wins (weeks) Visibility and baseline safeguards Enable prompt-level DLP for Copilot in simulation mode. Run first DSPM data risk assessment for oversharing. Enable shadow AI discovery via DSPM's Apps and agents dashboard and AI observability page. Start from the DSPM objective "Prevent data exposure in Microsoft 365 Copilot and Microsoft Copilot interactions." Phase 2 — Broad Enforcement (months) Acting on findings Switch DLP policies from simulation to enforcement. Use automated remediation actions (removing sharing links, applying DLP policies, revoking permissions). Expand sensitive information type definitions and add custom types. Rollout user communications explaining new controls and escalation paths. Phase 3 — Mature Governance (ongoing) Continuous improvement and AI-powered operations Leverage AI-driven triage agents to filter alert noise and highlight critical threats. Conduct periodic DSPM posture reviews using Outcome card metrics. Tune policies based on impact prediction visuals and progress tracking. Extend protections to new AI apps and agents as they are adopted—DSPM's AI observability tracks agent-specific activities across Microsoft and third-party environments. Formalize cross-functional AI governance cadence. *Phase 1 should take weeks, not months—the objective is to establish a baseline before risk accumulates. *Phase 2 is where enforcement generates measurable risk reduction. *Phase 3 is ongoing: as Microsoft continues extending Purview to additional AI apps and agent types, the governance framework must evolve in tandem. The DSPM preview's integration with third-party SaaS and IaaS platforms (Google Cloud Platform, Snowflake, Databricks) and partner solutions (Cyera, BigID, OneTrust) means the governance perimeter can expand alongside the organization's AI footprint. Conclusion AI adoption and data protection are not opposing forces. Microsoft Purview now provides the visibility, policy controls, and remediation workflows to move from discovering AI risk to actively governing Copilot, third-party AI apps, and agents at scale. DSPM surfaces oversharing and AI usage patterns through unified dashboards, data risk assessments, and AI observability. DLP blocks sensitive data in prompts and restricts AI access to labeled content. Insider Risk Management detects adversarial AI behavior. AI-driven triage and remediation agents close the gap between identifying a problem and fixing it—with every automated action audited. The path forward starts with practical actions: enable prompt-level DLP, illuminate shadow AI usage, and operationalize DSPM's "Prevent data exposure in Microsoft 365 Copilot and Microsoft Copilot interactions" objective. From there, enforce what you find, measure the results using DSPM's outcome-based metrics, and progressively mature your governance posture. Organizations that operationalize this loop will be in a strong position: able to say, "We use AI to work smarter—and we have the safeguards in place to do it safely."
Microsoft 365 Copilot not showing up as location in DLP
Hi, I am working on implementing security measures for Microsoft Copilot in a client environment. I want to create a DLP policy to not process data with certain sensitivity labels but when I go into DLP to create the policy, the location for Microsoft 365 Copilot is not an option. I also noticed that the "Fabric and Power BI workspaces: location is also not available. I have checked other similar client M365 tenants, and both of these locations are available by default. Any insight would be appreciated.
Adaptive Scopes
I'm setting up adaptive scopes in MS Purview for data retention testing, focusing on Entra groups. However, when I create a test adaptive scope using the 365 groups scope and add a query with the group's display name, it doesn't populate. Some scopes are over 7 days old, despite MS stating it can take up to 3 days for queries to sync. Does anyone have a better method for creating adaptive scopes for Entra groups?
