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.Microsoft 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.
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 TeamData System Wide Lineage via API Request
I'm struggling with finding a solution. My goal is to identify all existing lineage relationships for any data objects within a specific data system they belong to. I've been using the Purview REST API (Datamap Dataplane) but I haven't found an endpoint returning data system side lineage/relationships. For my scenario I have a Databricks metastore and need to know the existing lineage relationships of those data objects within Purview so I can purge them out when we are doing our scheduled lineage refresh.
Microsoft 365 E7 & Agent365: From Where You Are to Enterprise AI at Scale
Introduction As organizations move beyond AI experimentation and begin operationalizing agent-based AI workloads, a new set of challenges is emerging governance, visibility, and control. Microsoft’s response to this shift is Microsoft 365 E7, introduced on May 1, 2026. It bundles: Microsoft 365 E5 Microsoft 365 Copilot Microsoft Entra Suite Microsoft Agent 365 This represents Microsoft’s strategic direction toward a human-led, agent-operated enterprise. However, a key pattern is emerging: Many organizations deploy Agent 365 and assume governance is complete. It isn’t. Understanding Agent 365: Control Plane, Not Control Source Agent 365 is not a standalone security solution, it is a control plane for AI agents. It provides: Agent registry and discovery Blueprint governance and lifecycle control Observability across agents Aggregation of signals from Entra, Defender and Purview Simple analogy Agent 365 is like a dashboard in a car It shows status It aggregates signals But it does not generate signals Without identity, data and threat signals → governance visibility is incomplete. The Key Gap: “Enabled” vs “Governed” Agent 365 can be enabled standalone but governance requires: Identity signals (Entra) Threat signals (Defender) Data risk signals (Purview) This gap between “enablement” and “full governance” is where most deployments fall short. Agent 365 Governance Maturity Heatmap The following heatmap summarizes how governance capabilities evolve as you layer the Microsoft stack: Capability Agent 365 on E3 + Defender Suite + Purview Suite + Entra Suite E7 (Full) Agent registry / inventory ✅ Full ✅ ✅ ✅ ✅ Shadow agent discovery ✅ Full ✅ ✅ ✅ ✅ Blueprint governance / kill-switch ✅ Full ✅ ✅ ✅ ✅ First-party agent observability ✅ Full ✅ ✅ ✅ ✅ Conditional Access for agents (P1) ✅ Already in BP/E3 ✅ ✅ ✅ ✅ ID Governance for agents (P1) ✅ Already in BP/E3 ✅ ✅ ✅ ✅ Risk-based CA / ID Protection (P2) ❌ ✅ ❌ ✅ ✅ MDA behavioral risk detection ❌ ✅ ❌ ❌ ✅ Risks column fully populated ⚠️ Entra only ⚠️ Entra + Defender ⚠️ Entra + Purview ⚠️ Entra + Network ✅ All signals Purview DLP for agent interactions ⚠️ Basic only ⚠️ Basic only ✅ Full ⚠️ Basic only ✅ Full DSPM for AI ❌ ❌ ✅ ❌ ✅ Shadow AI discovery (external tools) ❌ ❌ ❌ ✅ ✅ Security Copilot SCUs ❌ ❌ ❌ ❌ ✅ (via E5) 🔍 Interpretation of the Heatmap Key insight: Agent 365 on its own provides visibility and governance scaffolding, but true governance maturity emerges only when identity (Entra) threat (Defender), and data (Purview) signals are combined. Microsoft 365 E7 is the only SKU that delivers all signals, identity, security, compliance and AI governance in a single integrated model. What Works with Agent 365 Alone On Business Premium or E3 + Agent 365, you still get meaningful capabilities: Agent registry (full visibility) Shadow agent discovery Blueprint governance and kill-switch Entra Agent ID (identity registration) Conditional Access for agents (via Entra P1) ID Governance (via Entra P1) First-party agent observability This provides a strong governance foundation, especially for early-stage adoption. What’s Missing Without the Full Stack Without Defender, Purview, and Entra Suite key capabilities are limited: Risk-based Conditional Access (requires Entra P2) Behavioral threat detection (Defender) Data interaction governance (Purview DLP) AI data security posture (DSPM for AI) External shadow AI discovery (Entra Internet Access) Result: You can see agents exist but you cannot fully assess risk, behavior or data exposure. What changes across layers: Layer Added What Improves Defender Threat detection, behavioral risk Purview Data protection, AI data governance Entra Suite Network + identity-level AI control E7 Full integration across all layers Licensing Model: Clarifying Agent 365 Agent 365 licensing is simple but often misunderstood: Licensed per user (not per agent) Covers all agents owned or managed by that user Agents do not need individual licenses This eliminates agent sprawl licensing concerns and anchors governance to the user identity. Upgrade Math by Starting Point This is where architecture meets commercial reality. 📍 Business Premium Starting point: $22/user Step Add-on Total Step 1 Agent 365 ($15) $37 Step 2 Defender + Purview Combo ($15) $52 Step 3 Entra Suite ($12) $64 Step 4 Copilot + Intune Suite ~$95 👉 Full E7 Parity: ~$95/user 👉 E7: $99/user At this stage: Minimal price difference E7 adds Security Copilot + removes 300-user limit ✅ This is where consolidation becomes compelling. 📍 E3 Starting point: $39/user Component Cost E3 Base $39 Agent 365 $15 Defender Suite $12 Purview Suite $12 Entra Suite $12 Intune Suite $10 Copilot $30 Total $130/user 👉 E7: $99/user 💥 Delta: $31/user 💥 ~$74K/year extra for 200 users ✅Use Agent 365 for visibility if needed ✅Avoid building full add-on stack ✅Move to E5 or E7 early 📍 E5 Starting point: $60/user Remaining gaps: Copilot ($30) Entra Suite ($12) Agent 365 ($15) 👉 Total: $117/user 👉 E7: $99/user 💥 Savings: $18/user 💥 ~$108K/year for 500 users ✅ ~15% savings ✅ Simplified licensing ✅ This becomes a strong renewal conversation driver. Architectural Perspective AI governance requires layered architecture: Layer Function Agent 365 Control plane Entra Identity + access Defender Threat detection Purview Data protection Governance is not a feature, it is a system built on continuous signals across identity, security and data. How to Position This in Customer Conversations For Business Premium Start with Agent 365 Add Defender + Purview for maximum value For E3 Avoid incremental add-ons Move to E5/E7 For E5 Position E7 as cost optimization + simplification Final Thought Agent 365 is a foundational capability but it is not a complete solution. On its own, it gives you visibility and a governance layer. But enterprise AI governance is not just about seeing and managing agents it’s about understanding what they’re doing, what they’re accessing and whether they should be doing it at all. A simple way to think about it: Deploying Agent 365 alone is like setting up a badge system in your building you can track who is inside and control access. But without the broader security stack, you still can’t: Detect risky or unusual behavior Protect sensitive data from overexposure Enforce governance consistently across the environment Bottom Line Agent 365 provides the control plane Security and compliance services provide the signals Microsoft 365 E7 brings these together into a unified governance model The Strategic Shift Organizations are moving from: AI as tools → isolated productivity gains AI as systems → integrated workflows and automation AI as governed ecosystems → secure, compliant, and scalable operations Sustainable AI adoption is not defined by capability alone it is defined by how effectively that capability is governed at scale. E7 is not just a licensing evolution it represents a shift to an integrated AI operating model, where governance is embedded by design, not added as an afterthought.
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).
Get-AdaptiveScopeMembers doesn't show the SiteURL for OneDrive
I am working through reporting for Adaptive Scopes and Adaptive Retention policies. I'm so close. But I discovered a problem with my script in that when people return to the company after their account has been deleted, they get a new OneDrive URL. This is expected. While they can have the same email address as an inactive mailbox, they cannot have the same OneDrive URL as an inactive URL. Since we keep all data for a minimum of 7 years, it is possible for a UPN to be the "owner" of 2 or more OneDrive URLs (one active and the others are from previous accounts). I have no easy way of seeing which OneDrive URL is active short of looking for digits at the end of the URL and taking the highest digit. But, what I want to know, is why isn't it here? Why doesn't "Get-AdaptiveScopeMember" return the SiteURL for the user? I thought maybe it was because my test user didn't have a OneDrive site when the account was added to the scope, so I added my actual user account to the scope and it shows the same thing. Is SiteURL only for SharePoint sites and not OneDrive sites? This makes no sense. Does it just take more time to show up? what's the time frame on that?Welcome, Purview Lightning Talks audience!
Please log in and then post any of your Data Security (and AI) spillover Purview Lightning Talks questions in the thread below. You can tag them using these hyperlinked handles: Session Title Speaker Tech Community Alias (tag) The Purview Label Engine: Automated Classification, Translation, and Co-Documentation for Enterprise Tenants Michael Kirst Neshva MichaelKirst1970 Stop, Think, Protect: Data Security in Real Life with Purview Oliver Sahlmann Oliver Sahlmann Using Purview to Prevent Oversharing with AI Services Viktor Hedberg headburgh How I Helped My Customers Understand Their AI Usage (and Protect Their Sensitive Data) Bram de Jager Bram de Jager Four Labels Max for Daily Use: Which Ones & Why? Romain Dalle RomainDalle_MVP_MCT Data‑driven Endpoint DLP Solution with Advanced Hunting Tatu Seppälä tseppala The Purview Hack No One Talks About: Container Sensitivity Labels That Fix Oversharing Fast Nikki Chapple nikkichapple Why You Should Create Your Own Sensitive Information Types (SITs) Niels Jakobsen Niels_Jakobsen From Zero to First Signal: Insider Risk Management Prerequisites That Actually Matter Sathish Veerapandian Sathish Veerapandian Securing Data in the Age of AI Júlio César Gonçalves Vasconcelos jcvasconcelos Beyond eDiscovery – Purview DSI for Security Investigation Susantha Silva susanthasilva Elevating Purview DLP with a Real‑World Use Case Victor Wingsing vicwingsing Purview Lightning Talks takes place April 30th at 8am pacific: Webinar Details Full agenda here. Also, you can come here at any time and click "Start a Discussion" to post a topic or question to your Purview Community!Governing Entra‑Registered AI Apps with Microsoft Purview
As the enterprise adoption of AI agents and intelligent applications continues to accelerate, organizations are rapidly moving beyond simple productivity tools toward autonomous, Entra‑registered AI workloads that can access, reason over, and act on enterprise data. While these capabilities unlock significant business value, they also introduce new governance, security, and compliance risks—particularly around data oversharing, identity trust boundaries, and auditability. In this context, it becomes imperative to govern AI interactions at the data layer, not just the identity layer. This is where Microsoft Purview, working alongside Microsoft Entra ID, provides a critical foundation for securing AI adoption—ensuring that AI agents can operate safely, compliantly, and transparently without undermining existing data protection controls. Lets look at the role of each solution Entra ID vs Microsoft Purview A very common misconception is that Purview “manages AI apps.” In reality, Purview and Entra serve distinct but complementary roles: Microsoft Entra ID Registers the AI app Controls authentication and authorization Enforces Conditional Access and identity governance Microsoft Purview Governs data interactions once access is granted Applies classification, sensitivity labels, DLP, auditing, and compliance controls Monitors and mitigates oversharing risks in AI prompts and responses Microsoft formally documents this split in its guidance for Entra‑registered AI apps, where Purview operates as the data governance and compliance layer on top of Entra‑secured identities. Lets look at how purview governs the Entra registered AI apps. Below is the high level reference architecture which can be extended to low level details 1. Visibility and inventory of AI usage Once an AI app is registered in Entra ID and integrated with Microsoft Purview APIs or SDK, Purview can surface AI interaction telemetry through Data Security Posture Management (DSPM). DSPM for AI provides: Visibility into which AI apps are being used Which users are invoking them What data locations and labels are touched during interactions Early indicators of oversharing risk This observability layer becomes increasingly important as organizations adopt Copilot extensions, custom agents and third‑party AI apps. 2. Classification and sensitivity awareness Purview does not rely on the AI app to “understand” sensitivity. Instead the Data remains classified and labeled at rest. AI interactions inherit that metadata at runtime Prompts and responses are evaluated against existing sensitivity labels If an AI app accesses content labeled Confidential or Highly Confidential, that classification travels with the interaction and becomes enforceable through policy. This ensures AI does not silently bypass years of data classification work already in place. 3. DLP for AI prompts and responses One of the most powerful but yet misunderstood purview capabilities is the AI‑aware DLP. Using DSPM for AI and standard Purview DLP: Prompts sent to AI apps are inspected Responses generated by AI can be validated Sensitive data types (PII, PCI, credentials, etc.) can be blocked, warned, or audited Policies are enforced consistently across M365 and AI workloads Microsoft specifically highlights this capability to prevent sensitive data from leaving trust boundaries via AI interactions. 4. Auditing and investigation Every AI interaction governed by Purview can be recorded in the Unified Audit Log, enabling: Forensic investigation Compliance validation Insider risk analysis eDiscovery for legal or regulatory needs This becomes critical when AI output influences business decisions and regulatory scrutiny increases. Audit records treat AI interactions as first‑class compliance events, not opaque system actions 5. Oversharing risk management Rather than waiting for a breach, Purview proactively highlights oversharing patterns using DSPM: AI repeatedly accessing broadly shared SharePoint sites High volumes of sensitive data referenced in prompts Excessive AI access to business‑critical repositories These insights feed remediation workflows, enabling administrators to tighten permissions, re‑scope access, or restrict AI visibility into specific datasets. In a nutshell, With agentic AI accelerating rapidly, Microsoft has made it clear that organizations must move governance closer to data, not embed it into individual AI apps. Purview provides a scalable way to enforce governance without rewriting every AI workload, while Entra continues to enforce who is allowed to act in the first place. This journey makes every organizations adopt Zero Trust at scale as its no longer limited to users, devices, and applications; It must now extend to AI apps and autonomous agents that act on behalf of the business. If you find the article insightful and you appreciate my time, please do not forget to like it 🙂Sharing: PDF readers that support Purview labels
As I was researching on Adobe Acrobat reader and Sensitivity labels, I decided to check if the common alternative PDF readers out there are able to support Purview MIP Sensitivity labels. There is already a published documentation on this for SharePoint-Compatible PDF readers that supports Microsoft IRM: https://learn.microsoft.com/en-us/purview/sp-compatible-pdf-readers-for-irm (last updated Nov-2023) but I wanted to see if these same PDF readers supports the ability for end-users to use/ select labels similar to that of Adobe Acrobat As of 11-June-2025; atleast one of them clearly do: Nitro PDF: Yes. Documentation shows that users can see and use the sensitivity labels. PDF -X.change Editor: Yes. Documentation show that users can see and use the sensitivity labels. (check the official website, I can't hyperlink it because the site is blocked. FOX PDF editor: No. Documentation only states RMS and not clear if it show Purview labels. This is for F.O.X.I.T editor (spelled without the ".") but for some reason there is a community ban on that word and it won't allow me to post the full name PDFescape: No. Sumatra PDF: No Okular: No If there are other PDF readers that I've missed, I encourage you list it down in the comment below. Would love to grow this list.
