Priority Cleanup V2: Faster, Simpler Data Purging for Exchange Online
Enhancements Achieved with Exchange Priority Cleanup V2 Priority Cleanup (Use priority cleanup to expedite the permanent deletion of sensitive information from mailboxes | Microsoft Learn) was introduced to provide administrators with a powerful tool for permanently deleting mailbox content, even when under retention or eDiscovery hold, to address scenarios such as data spillage and urgent removals. Priority Cleanup addressed a key need in Exchange Online by allowing hold overrides. Through real-world use, we received valuable insights regarding the approval process, deletion speed, and reviewer experience. These learnings have guided our ongoing enhancements, ensuring that the solution evolves to better meet customer needs for efficiency and ease of use while maintaining robust security and compliance standards. What's New in Priority Cleanup V2 Priority Cleanup V2 is currently in the planning stage. We’re sharing the proposed updates early to gather feedback before we begin implementation. The goal is to address the core limitations of V1 with enhancements focused on speed and simplicity. Faster Data Deletion & Simplified Approval Workflow: We’re proposing to streamline the process to two key checkpoints: Policy enforcement approval when moving from simulation to active mode (requires approval from a different Priority Cleanup admin). We’re proposing to minimize approval overhead by removing unnecessary review stages. Disposition review by eDiscovery admins will be required only for mailboxes under eDiscovery hold. For other mailboxes, items will be permanently deleted soon after the Priority Cleanup policy is applied to speed up processing from days to hours. This would reduce the number of required users with admin privileges from four to two. Controlled Purge Limits: Administrators will be able to efficiently manage substantial purges by securely processing deletions in batches, with a configurable limit of up to 100 items per mailbox per ELC run. A default limit of 100 items is applied, with the ability to adjust this value through an organization‑level configuration. This configurable limit provides an additional safeguard for system operations while offering flexibility to meet varying organizational needs. Note: A default limit of 100 items will apply, with the ability to adjust this value via an organization-level configuration. V1 vs V2 Feature Comparison Feature V1 Behavior V2 Improvement Deletion Speed Multi-stage process taking 6+ days for small purges Significantly faster with immediate deletion for non-hold mailboxes Approval Workflow 3-stage approval (Priority Cleanup Admin, Retention Admin, eDiscovery Admin) 2-stage approval (policy enforcement + eDiscovery review only when needed) Proposed Improvements in Admin Experience and Control Streamlined Policy Management: We are considering making policies easier to enable or disable directly from the main list view, potentially through a simple toggle, so administrators would no longer need to use the setup wizard for this task. Enhanced Review Interface: Proposed updates include adding new, informative columns to the interface, such as a dedicated Mailbox/Site column to help identify the source location. We are also looking at providing clearly labeled date fields to indicate when items were received or created, which would replace the potentially confusing ExpiryDate label. Comprehensive Audit Trails: It is proposed that every action would be thoroughly documented with a unique Cleanup ID. This ID could then be used in Audit Search to locate all events related to a specific cleanup operation, helping to simplify verification and post-incident analysis. Note: Priority Cleanup V2 enhancements are specific to Exchange Online. These changes do not affect Priority Cleanup for OneDrive and SharePoint (PC ODSP), including its rollout timelines or behavior. Key Benefits for Administrators Priority Cleanup V2 delivers tangible improvements across the entire data purging workflow. Accelerated Deletion: Requests for data removal are fulfilled much faster, enabling urgent incidents to be resolved within hours rather than days, and minimizing risk exposure. Reduced Administrative Overhead: Coordination requirements are simplified, decreasing the number of users involved from four to two in most cases, which makes Priority Cleanup V2 more practical for smaller teams. Enhanced Transparency: Improved user interface labels and robust audit logs help administrators clearly understand what data is being deleted and who authorized the action. Maintained Security and Compliance: Segregation of duties is preserved so that no single individual can delete protected content alone, supporting security and compliance requirements. Availability and Rollout Priority Cleanup V2 is currently in development with rollout planned for the end of 2026. As with all Exchange Online features, we will publish a Microsoft 365 Roadmap item and send Message Center notifications to affected tenants before general availability We Want Your Feedback Priority Cleanup V2 represents a significant evolution based on customer feedback from V1 users who emphasized the need for faster, simpler data purging without compromising security. We've addressed the core pain points around speed, approval complexity, and admin experience, but we know there's always room for improvement. We'd love to hear your thoughts: Does the simplified approval workflow meet your security requirements? What visibility or reporting capabilities would make you more confident in using Priority Cleanup for urgent data removal scenarios? Your feedback directly shapes how we prioritize future enhancements. Please share your experiences and suggestions through your regular Microsoft support channels or customer success contacts. Together, we can continue refining Priority Cleanup to better serve your data governance needs. Aniket Gupta, Mehul Kaushik, Victor Legat & Purview Data Lifecycle Management TeamDeploy 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 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.Data Security Posture Reports
Proving Your Data Security Posture with Confidence Microsoft Purview Posture Reports help organizations prove (not just assume) that their data security controls are working. They provide a clear, outcome‑based view of how effectively sensitivity labels and Data Loss Prevention (DLP) policies are protecting sensitive data across Microsoft 365. Rather than focusing on individual events or alerts, Posture Reports answer a higher‑level question: Are our data protection controls consistently applied and enforced across the organization? We designed Posture Reports to give security, compliance, and business leaders a defensible, measurable view of data security posture, especially critical as organizations adopt Copilot and other AI tools. Purview reporting offers unified data security insights, helping teams identify and address top risks quickly. By consolidating intelligence, it highlights vulnerabilities so you can take prompt action. With contextual information and measurable results, Purview streamlines responses to threats, improves resilience, and supports a proactive security strategy. Microsoft Purview reporting dashboards drive security decisions because they convert massive, fragmented security telemetry into decision‑ready insights: what’s happening, where the risk is, whether controls are effective, and what to do next. For insights on customizing these reports, check out this article. Where can I access these reports? Three Locations: Purview.microsoft.com -> Information Protection -> Reports Purview.microsoft.com -> Data Loss Prevention -> Posture Reports Purview.microsoft.com -> DSPM -> Reports Posture Reports Basics The out-of-box (OOB) reports are built with a combination of Metric and Analytic cards. Note: these reports are refreshed hourly. What is a Metric Card? What is an Analytic Card? Metric cards are designed to highlight a single, high‑level value or KPI and are also the foundation for building custom cards that combine metrics with trend context. Analytics cards provide richer visualizations that help users explore patterns and trends in the data. What they do: A Metric card is used to create a card that pairs a primary metric with its historical trend This allows users to answer not just “What is the value?” but also “Is it improving or declining?” Metric cards are commonly used for adoption, growth, and compliance health indicators These cards focus on showing trends over time What they do: Show distributions, breakdowns, or trends over time Enable comparison across locations, labels, or workloads Support investigation and analysis rather than just reporting These are useful when you need a visual representation rather than a single metric. Display data using charts such as bars, lines, or other visual formats These cards are commonly used for trend analysis, distribution views, and comparative reporting. Both make patterns easier to understand. Report Insights The following table goes into each OOB report and breaks down different viewpoints to help understand how to use them. Report Where it shows Data Security Decision Intent Why What it shows Key Metrics Filter by Label distribution and adoption in Microsoft 365 DSPM Reports Information Protection Reports Expand auto labeling to high volume unlabeled areas Simplify or consolidate confusing labels Look for high label coverage areas as additional enforcement opportunities Prioritize training/auto-labeling in areas with low label adoption Label coverage is the foundational signal for downstream controls Label activities by workload Sensitivity labels by platform for endpoint devices Sensitivity label usage Label activities by application methods Total labeled items Auto-labeled items Manually labeled items Labeled by default How applied Activity Location Platform Sensitivity label Sensitive info type Policy Rule How applied detail Sensitive info type confidence User Auto-labeling coverage DSPM Reports Information Protection Reports Which auto-labeling polices to promote from audit to enforce Where false positives need tuning before enforcement Which sensitive data types are under-protected Whether auto-labeling can safely scale further Can we trust our classification signal enough to automate protection? Auto-labeling by enforcement (which are in sim mode vs. enforcement mode) Auto-labeled items by policies Top auto-labeling policies (most active auto-labeling policies by number of items they have labeled) Auto-labeling policies by platform for endpoint devices Total labeled items Auto-labeled items Auto-labeled emails Auto-labeled files How applied Activity Location Platform Sensitivity label Sensitive info type Policy Rule How applied detail Sensitive info type confidence User Sensitivity Label Changes DSPM Reports Information Protection Reports Whether to restrict or justify label downgrades Where insider risk controls may be needed (users downgrading heavily) Which labels need stronger default enforcement? Whether user behavior is increasing data exposure Label changes are often an early warning signal of oversharing or misuse Sensitivity label transition trends (timelines for label upgraded/downgraded/removed over time) Sensitivity label removed across workloads (where labels have been removed) Types of Sensitivity labels downgraded (to which sensitivity labels items were often downgraded) Sensitivity label downgrade methods (Analyze sensitivity label downgrades by application method/workload. Dual chart helps identify if this is happening manual or automatic) Sensitivity label downgrades by user (which users are most frequently downgrading) Labels upgraded Labels removed Labels downgraded Labels downgraded manually How applied Activity Location Platform Sensitivity label Sensitive info type Policy Rule How applied detail Sensitive info type confidence User Top users triggering DLP Policies DSPM Reports Data Loss Prevention Posture Reports Whether activity reflects risky behavior or broken workflows Which users or roles need targeted controls or guidance If DLP policies are too broad or too noisy If insider risk investigations should be warranted or considered Distinguish Real risk vs policy misalignment vs. normal business activity DLP Policies Triggered by Users (DLP rule match per rule) Unique users involved in triggers Total users with repeated triggers Policy Location (Workload) Endpoint Device Activity Most triggered DLP Rules or Activities DSPM Reports Data Loss Prevention Posture Reports Which policies need tuning or scoping Where enforcement can be strengthened safely Which risks are systemic vs. isolated Whether DLP is actually aligned to sensitive data High volume DLP rules should drive prioritization, not alert fatigue Top DLP Rules Triggered DLP Rules Triggered by Device Activity (most common endpoint activities triggered) Total rules triggered Unique users involved in triggers Total protective actions taken Policy Location (Workload) Endpoint Device Activity Most triggered DLP policies DSPM Reports Data Loss Prevention Posture Reports Are my highest‑priority policies aligned to real user behavior Shows whether your most critical policies are: Actively protecting data, or rarely triggered (possibly mis-scoped or irrelevant) Which DLP policies are most actively protecting sensitive data, is this the highest risk? DLP Policies Triggered by Workload Total policy trigger volume Unique users involved in triggers Total rules triggered Policy Location (Workload) Endpoint Device Activity Customer Use Cases What are some customer concerns Posture Reports address OOB? Use Case Situation Guidance Labeling & auto-labeling program rollout: “Are we increasing coverage and preventing drift?” Customer situation: A customer is rolling out sensitivity labels and auto-labeling. Leadership asks: “Are we labeling more content?” Security asks: “Are sensitive items still unprotected?” And compliance asks: “Are users downgrading labels?” In posture reports, Information Protection coverage includes label distribution/adoption, auto-labeling posture, and posture drift through label transitions (e.g., label downgrades). This maps directly to “coverage + drift + enforcement” conversations. The built-in IP posture set also calls out label distribution and adoption, auto-labeling policy coverage, and sensitivity label activity as core reports. For “active data” posture, the design intent explicitly includes questions like “What % of my active data estate is labeled vs not labeled?” and “What %/count of unlabeled data has sensitive info?” and “How is labeling protection trending over 30 days?”: perfect for proving program progress (or identifying gaps). DLP tuning & noise reduction: “Which policies/rules are actually firing, and who’s tripping them?” Customer situation: The DLP admin is overwhelmed: policies exist, but they don’t know which ones are actually driving volume (or pain), and which users are repeatedly triggering violations. They need to prioritize tuning based on real-world triggers. Surfaces most triggered DLP rules, most triggered DLP policies, and top users triggering DLP policies. This is directly aligned to the operational question “Are our policies effective?” The service-description blurb explicitly frames DLP posture reports as highlighting most triggered rules, highest-volume policies, and top policy violators. This is exactly what admins use to decide what to tune first. Helps teams move from anecdotal “DLP is noisy” to a ranked view of where to focus (policy/rule/user). CISO Reports, “Are we safer this quarter?” posture readout Customer situation: A CISO (or compliance leader) needs a repeatable, executive-ready snapshot of how the organization is protecting sensitive data, without stitching together audit logs, Activity Explorer screenshots, and spreadsheets. Posture Reports are explicitly positioned as “executive-ready visibility” across Information Protection + DLP. Provides OOB, executive-ready visibility into data protection posture across Information Protection and Data Loss Prevention, so the CISO can answer “Is Purview doing what we intend it to do?” and “Where are the gaps?” quickly. Enables a consistent monthly/quarterly narrative from built-in metrics and trends, with hourly refresh called out as a customer/partner value driver (great for “freshness” credibility in leadership reviews). Uses a rolling window approach; guidance is to save/export what you want to retain for future reference (great for recurring readouts). Frequently Asked Questions (FAQs) Question Guidance What is the least permission required to see Posture Report section for DLP? Information Protection Reader We can see Activity Explorer details inside the reports in a non-simplified view, where all confidential information is visible. If someone has the Security Reader role, will they be able to see these things? Security Reader can see Activity Explorer content surfaced inside Posture Reports, including user/activity-level details that may expose sensitive metadata. If you want a role that can view posture reports but not see confidential item-level signals, Security Reader is not the safe minimum; Information Protection Reader is. Why are our DLP "Device Posture" reports are not in the Posture Reports and only on the DLP Overview page? It will move. Right now, the traffic on home page is high, so we launched there. There will eventually be a deep clone into our "Posture Reports" section, however, it will take some time before it shows up. Can I get reports going back longer than 30 days? We're working on increasing this number but at this time, the reports go back a max of 30 days. Is there any impact on tenant performance when enabling new reporting features? How quickly will reports populate after enabling the feature? No significant impact is expected. If labeling, scanning, and/or DLP policies are already active, reports populate instantly when the feature is enabled (assuming E5 is in place). No additional intrusive operations are performed on the tenant. Can we customize these reports? We have a current public preview in place for posture report customization. Stay tuned for more updates as we continue to build out Microsoft Purview Reporting. Co-Authors: Kevin Kirkpatrick and Jane SwitzerData Security Posture Reports (Custom Workspace and Charts)
For more insights on OOB Reports, check out this article. Overview: NOW IN PUBLIC PREVIEW Microsoft Purview Posture Reports provide a clear, outcome‑based view of how effectively data protection controls, such as Sensitivity Labels and Data Loss Prevention (DLP) policies, are working across Microsoft 365. Rather than focusing on individual alerts or isolated events, Posture Reports help organizations answer a higher‑level, executive‑ready question: Are our data protection controls consistently applied and actually reducing risk at scale? Posture Reports transform complex telemetry from Audit logs, Activity Explorer, and policy enforcement into measurable, defensible insights that security, compliance, and business leaders can act on with confidence. Building on the out‑of‑the‑box experience, Custom Posture Reports enable teams to create scenario‑specific views tailored to their organization’s risk priorities. Key capabilities include: Custom dashboards with drag‑and‑drop sections and cards Built‑in and custom metric or chart cards powered by Activity Explorer data Flexible filtering to support focused investigations and reporting Tips: Start with clear questions, then choose cards that answer them Avoid overcrowding reports; fewer, well‑chosen cards are more effective Use metric cards for status, analytics cards for understanding Treat custom reports as living assets, iterate as needs evolve This allows security teams to move beyond one‑size‑fits‑all reporting and build views aligned to their unique data protection strategy. Preview note: As this feature is in Preview, capabilities, terminology, and UX may change, and not all scenarios are fully documented yet. Key Concepts Where can I access these reports? Three Locations: Purview.microsoft.com -> Information Protection -> Reports Purview.microsoft.com -> Data Loss Prevention -> Posture Reports Purview.microsoft.com -> DSPM -> Reports (CUSTOM COMING) What is a Custom Report? A Custom Report is a user‑created report container where you assemble one or more cards to visualize Information Protection–related data (for example, labeling, classification, or protection activity). Unlike the built‑in reports, custom reports are designed to be adaptable to different audiences and questions. Typical use cases include: Tracking adoption of sensitivity labels over time Monitoring where sensitive data is most concentrated Creating executive‑friendly, KPI‑style summaries Building analyst views for deeper investigation Core Actions in the Custom Reports Experience Add Report creates a new, empty report canvas. This is the starting point where you define: The report name and purpose Create custom reports with your preferred cards and analytics. Add section is used to create a logical grouping within a custom report. A section acts as a container that helps organize cards on the report canvas into meaningful groupings based on purpose, audience, or storyline. What a section does How sections are used Provides structure to a report by grouping related cards together Improves readability and navigation, especially in reports with multiple cards Helps separate different analytical themes within the same report A report can contain one or more sections Each section can include multiple cards (metric cards, chart cards, analytics cards, or custom cards) Sections are added before cards, serving as the layout framework for the report Add Card lets you place a visualization or metric onto the report canvas. Each card answers a specific question, such as “How much data is labeled Confidential?” or “Where is sensitive content growing fastest?” Cards are the building blocks of custom reports and can be mixed and matched within the same report. Permissions: in order to create these reports, you must have permissions to create labels and DLP policies. Built‑in (OOB – Out of the Box) cards: Custom reports include two built‑in card types that can be added to sections: Metric cards – predefined cards used to display key metrics and trends Analytics cards – predefined cards that provide deeper analytical insights Note: In addition to built‑in cards, you can add custom cards (such as metric‑based or chart‑based custom cards) to tailor the report to your scenario. What is a Metric Card? What is an Analytic Card? Metric cards are designed to highlight a single, high‑level value or KPI and are also the foundation for building custom cards that combine metrics with trend context. Analytics cards provide richer visualizations that help users explore patterns and trends in the data. What they do: A Metric card is used to create a card that pairs a primary metric with its historical trend This allows users to answer not just “What is the value?” but also “Is it improving or declining?” Metric cards are commonly used for adoption, growth, and compliance health indicators These cards focus on showing trends over time What they do: Show distributions, breakdowns, or trends over time Enable comparison across locations, labels, or workloads Support investigation and analysis rather than just reporting These are useful when you need a visual representation rather than a single metric. Display data using charts such as bars, lines, or other visual formats Custom cards allow you to define tailored views aligned to your organization’s unique questions. What they do: Focus on specific scenarios not covered by default cards Combine dimensions or filters relevant to your business context Adapt reporting to regulatory, regional, or operational needs When to use them: Organization‑specific KPIs Regulatory or audit‑driven reporting Advanced scenarios that go beyond standard dashboards Custom cards are especially useful for mature programs where built‑in reports are no longer sufficient on their own. Custom Card Configuration The following example illustrates how a metric‑based custom card can be configured to track adoption trends. Scenario: Track adoption of the Confidential sensitivity label over the last 30 days. Card type: Custom card (built from a Metric card) Metric configuration Filters applied What this card shows Metric: Number of items labeled Confidential Time range: Last 30 days (custom) Display format: Compound (shows total count with trend direction) Sensitivity label: Confidential Workload: SharePoint The current total number of items labeled Confidential Whether labeling activity is increasing or decreasing over the last 30 days A focused view of adoption for a specific label and workload This type of custom card is well‑suited for adoption tracking, executive summaries, and ongoing compliance health monitoring. Metric card configuration: Metric cards currently surface up to 7 days of data, providing recent context for the selected metric. Custom surfaces up to the last 30 days of data. You can choose different display formats, such as: Number – a raw count or value Percentage – a proportional view of the metric Compound – a combination of value and trend for quick interpretation You can apply filters to limit the data set to specific criteria (for example, a particular label, location, or workload), allowing the metric to reflect a targeted scenario rather than all data Chart cards are used to visualize data as a graphical chart and can be created as custom cards when you need a visual representation rather than a single metric. Click on Chart Card and under Chart card configuration, select the primary activities: Sensitivity Label Then define the Chart Type Based on the configuration options shown in the UI, the following chart types are available: Vertical bar – compares values across categories using vertical bars; commonly used for side‑by‑side comparisons Horizontal bar – compares values across categories using horizontal bars; useful when category labels are long Pie – shows proportional distribution of values across categories Donut – similar to a pie chart, with a central area that improves readability Line chart – visualizes trends or changes over time Selecting the appropriate chart type helps ensure the custom card clearly communicates the intended insight and improves overall report readability. These cards are commonly used for trend analysis, distribution views, and comparative reporting. Both make patterns easier to understand. Real World Example The business goal this report is addressing is to prove security value and risk reduction, especially to leadership and stakeholders, by tying data protection investments to measurable outcomes. Primary Business Goal: demonstrate that the organization’s data protection controls are effective in reducing financial data risk. The report shows that sensitive financial data is not only being found, but consistently labeled and enforced through DLP, validating that controls are working as intended. Supporting Business Objectives Executive assurance & trust Provide leadership with evidence that compliance and security controls are actively protecting financial data, not just configured. Risk reduction validation Show that financial SITs are being systematically identified and governed, reducing exposure and improper data handling. Value justification for security investments Correlate auto labeling and DLP outcomes to demonstrate ROI on Purview, labeling, and policy investments. Operational confidence Confirm that auto‑labeling policies are accurately detecting sensitive data at scale and triggering appropriate DLP enforcement. Audit and compliance readiness Establish defensible proof that sensitive financial data is discovered, classified, and protected consistently across the environment. Step 1: Create a report, add a name, and description Step 2: Add a section called Key Outcomes (title and description) and add metric cards to show the data at a glance. Step 3: Add another section. Include the following two out of the box charts available. Step 4: Add another section with the out of the box charts Step 5: Add the last section that ties everything together. One out of the box chart and another custom chart. Step 6: for the custom chart above, Do a vertical bar, pivot (the groupings at the bottom of the chart) to Activity. Then, add filters (Sensitive info type: the SITs and Activity: DLPRuleMatch. The report highlights key outcomes, label adoption, application areas, and auto labeling policies. It identifies the main SITs used in labeling and connects them to DLP, demonstrating that the admin's data security measures are effective, particularly with financial information. Using AI to simplify insights This AI integration builds on Microsoft Purview’s existing reporting stack (Posture Reports, Activity Explorer and Audit) and introduces AI-assisted interpretation, summarization, and report composition to reduce manual analysis and accelerate decision-making. To access the report AI Summary: Click on the report and open “View Details” AI will prepare and summarize the report. AI Report Components Executive Summary Delivers a high level, leadership friendly narrative of the most important insights. Highlights overall posture, major risks, and notable improvements or regressions. Summarizes overall activity (for example, total labeled items and dominant platforms) Calls out major observations and limitations (such as lack of trend comparison due to retention) Provides a concise interpretation of what the data means at a point in time This section answers: “What happened, and what should I know without reading the full report?” Key metrics This section provides the essential quantitative data that forms the foundation of the report. Establishes a baseline that can be tracked over time Quantitative measures such as: Number of policy triggers or Label adoption rates Lists the primary counts, categories, and time range used for analysis Clarifies what measurements are available and which are not (such as trends) This section answers: “What are the exact numbers this report is based on?” Distribution Breakdown This section shows how activity is distributed across categories or dimensions. Breaks total activity into meaningful segments (for example, Mac vs. Web Browser) Displays proportional impact using counts and percentages Helps identify concentration areas or imbalances across platforms This section answers: “Where is activity happening the most?” Trend Analysis Evaluates changes over time when historical data is available. Compares current activity to prior periods Highlights increases, decreases, or stability in behavior Clearly calls out when trend analysis is not possible due to data limitations This section answers: “is behavior improving, worsening, or staying the same over time?” Key Findings Synthesizes insights derived from metrics, distributions, and trends. Interprets the data rather than restating it Identifies notable patterns, gaps, or risks (for example, platform skew or low adoption) Connects observations to possible operational or policy implications. This section answers: “What stands out as important or concerning?” Assessment Provides an overall evaluation of the security or compliance posture Combines findings into a holistic judgment Assesses scope, coverage, and effectiveness of current practices Describes whether the posture is sufficient or limited This section answers: “How healthy is our current posture?” Status Summarizes the assessment into a simple outcome indicator. Recommendations Guides next steps based on observed gaps and risks. Suggests practical actions to improve coverage or effectiveness. Aligns recommendations to best practices and product capabilities. Prioritizes changes that reduce risk and improve consistency. This section answers: “What should we do nex References Provides traceability and supporting documentation. Links to authoritative Microsoft documentation used to inform recommendations Allows readers to validate guidance or explore implementation details This section answers: “Where can I verify or learn more?” Full AI Report Summary Summary Posture Reports represent a shift from security configuration to security outcomes. They empower organizations to confidently answer critical questions about risk, readiness, and return on security investment, especially in an AI‑driven world. As reporting continues to evolve, Posture Reports will play a foundational role in how customers prove, improve, and communicate their data security posture.AI‑Powered Troubleshooting for Microsoft Purview Data Lifecycle Management
Announcing the DLM Diagnostics MCP Server! Microsoft Purview Data Lifecycle Management (DLM) policies are critical for meeting compliance and governance requirements across Microsoft 365 workloads. However, when something goes wrong – such as retention policies not applying, archive mailboxes not expanding, or inactive mailboxes not getting purged – diagnosing the issue can be challenging and time‑consuming. To simplify and accelerate this process, we are excited to announce the open‑source release of the DLM Diagnostics Model Context Protocol (MCP) Server, an AI‑powered diagnostic server that allows AI assistants to safely investigate Microsoft Purview DLM issues using read‑only PowerShell diagnostics. GitHub repository: https://github.com/microsoft/purview-dlm-mcp The troubleshooting challenge When you notice issues such as: “Retention policy shows Success, but content isn’t being deleted” “Archiving is enabled, but items never move to the archive mailbox” The investigation typically involves: Connecting to Exchange Online and Security & Compliance PowerShell sessions Running 5–15 diagnostic cmdlets in a specific order Interpreting command output using multiple troubleshooting reference guides (TSGs) Correlating policy distribution, holds, archive configuration, and workload behavior Producing a root‑cause summary and recommended remediation steps This workflow requires deep familiarity with DLM internals and is largely manual. Introducing the DLM Diagnostics MCP Server The DLM Diagnostics MCP Server automates this diagnostic workflow by allowing AI assistants – such as GitHub Copilot, Claude Desktop, and other MCP‑compatible clients – to investigate DLM issues step by step. An administrator simply describes the symptom in natural language. The AI assistant then: Executes read‑only PowerShell diagnostics Evaluates results against known troubleshooting patterns Identifies likely root causes Presents recommended remediation steps (never executed automatically) Produces a complete audit trail of the investigation All diagnostics are performed under a strict security model to ensure safety and auditability. What is the Model Context Protocol (MCP)? The Model Context Protocol (MCP) is an open standard that enables AI assistants to interact with external tools and data sources in a secure and structured way. You can think of MCP as a “USB port for AI”: Any MCP‑compatible client can connect to an MCP server The server exposes well‑defined tools The AI can use those tools safely and deterministically The DLM Diagnostics MCP Server exposes Purview DLM diagnostics as MCP tools, enabling AI assistants to run PowerShell diagnostics, retrieve execution logs, and surface Microsoft Learn documentation. More information: https://modelcontextprotocol.io Diagnostic tools exposed by the server The server exposes four MCP tools. 1. Run read‑only PowerShell diagnostics This tool executes PowerShell commands against Exchange Online and Security & Compliance sessions using a strict allow list. Only read‑only cmdlets are permitted: Allowed verbs: Get-*, Test-*, Export-* Blocked verbs: Set-*, New-*, Remove-*, Enable-*, Invoke-*, and others Every command is validated before execution. Example: Archive mailbox not working Admin: “Archiving is not working for john.doe@contoso.com” The AI follows the archive troubleshooting guide: 1 Step 1 – Check archive mailbox status 2 Get-Mailbox -Identity john.doe@contoso.com | 3 Format-List ArchiveStatus, ArchiveState 4 5 Step 2 – Check archive mailbox size 6 Get-MailboxStatistics -Identity john.doe@contoso.com -Archive | 7 Format-List TotalItemSize, ItemCount 8 9 Step 3 – Check auto-expanding archive 10 Get-Mailbox -Identity john.doe@contoso.com | 11 Format-List AutoExpandingArchiveEnabled Finding The archive mailbox is not enabled. Recommended action (not executed automatically): 1 Enable-Mailbox <user mailbox> –Archive All remediation steps are presented as text only for administrator review. 2. Retrieve the execution log Every diagnostic session is fully logged, including: Command executed Timestamp Duration Status Output Admins can retrieve the complete investigation as a Markdown‑formatted audit trail, making it easy to attach to incident records or compliance documentation. 3. Microsoft Learn documentation lookup If a question does not match a diagnostic scenario – such as “How do I create a retention policy?” – the server falls back to curated Microsoft Learn documentation. The documentation lookup covers 11 Purview areas, including: Retention policies and labels Archive and inactive mailboxes eDiscovery Audit Communication compliance Records management Adaptive scopes 4. Create a GitHub issue (create_issue) create_issue lets the assistant open a feature request in the project’s GitHub repo and attach key session details (such as the commands run and any failures) to help maintainers reproduce and prioritize the request. Example: File a feature request from a failed diagnostic ✅ Created GitHub issue #42 Title: Allowlist should allow Get-ComplianceTag cmdlet Category: feature request Labels: enhancement URL: https://github.com/microsoft/purview-dlm-mcp/issues/42 Session context included: 3 commands executed, 1 failure Security and safety model Security is enforced at multiple layers: Read‑only allow list: Only approved diagnostic cmdlets can run No stored credentials: Authentication uses MSAL interactive sign‑in Session isolation: Each server instance runs in its own PowerShell process Full audit trail: Every command and result is logged No automatic remediation: Fixes are never executed by the server This design ensures diagnostics are safe to run even in sensitive compliance environments. Supported diagnostic scenarios The server currently includes 12 troubleshooting reference guides, covering common DLM issues such as: Retention policy shows Success but content is not retained or deleted Policy status shows Error or PolicySyncTimeout Items do not move to archive mailbox Auto‑expanding archive not triggering Inactive mailbox creation failures SubstrateHolds and Recoverable Items growth Teams messages not deleting Conflicts between MRM and Purview retention Adaptive scope misconfiguration Auto‑apply label failures SharePoint site deletion blocked by retention Unified Audit Configuration validation Each guide maps symptoms to diagnostic checks and remediation guidance. Getting started Prerequisites Node.js 18 or later PowerShell 7 ExchangeOnlineManagement module (v3.4+) Exchange Online administrator permissions Required permissions Option Roles Notes Least-privilege Global Reader + Compliance Administrator Recommended, covers both EXO and S&C read access. Single role group Organization Management Covers both workloads but broader than necessary. Full admin Global Administrator Works but overly broad, not recommended. Exchange Online (Connect-ExchangeOnline): cmdlets like Get-Mailbox, Get-MailboxStatistics, Export-MailboxDiagnosticLogs, Get-OrganizationConfig Security & Compliance (Connect-IPPSSession): cmdlets like Get-RetentionCompliancePolicy, Get-RetentionComplianceRule, Get-AdaptiveScope, Get-ComplianceTag Exchange cmdlets require EXO roles; compliance cmdlets require S&C roles. Without both, some diagnostics will fail with permission errors. Why both workloads? The server connects to two PowerShell sessions: The authenticating user (DLM_UPN) needs read access to both Exchange Online and Security & Compliance PowerShell sessions. MCP client configuration The server can be connected to IDE like Claude Desktop or Visual Studio Code (GitHub Copilot) using MCP configuration. Include this configuration in your MCP config JSON file (for VS Code, use .vscode/mcp.json; for Claude Desktop, use claude_desktop_config.json) { "mcpServers": { "dlm-diagnostics": { "command": "npx", "args": [ "-y", "@microsoft/purview-dlm-mcp" ], "env": { "DLM_UPN": "admin@yourtenant.onmicrosoft.com", "DLM_ORGANIZATION": "yourtenant.onmicrosoft.com", "DLM_COMMAND_TIMEOUT_MS": "180000" } } } } Summary The DLM Diagnostics MCP Server brings AI‑assisted, auditable, and safe troubleshooting to Microsoft Purview Data Lifecycle Management. By combining structured troubleshooting guides with read‑only PowerShell diagnostics and MCP, it significantly reduces the time and expertise required to diagnose complex DLM issues. We invite you to try it out, provide feedback, and contribute to the project via GitHub. GitHub repository: https://github.com/microsoft/purview-dlm-mcp Rishabh Kumar, Victor Legat & Purview Data Lifecycle Management TeamData Security Posture Management for AI
A special thanks to Chris Jeffrey for his contributions as a peer reviewer to this blog post. Microsoft Purview Data Security Posture Management (DSPM) for AI provides a unified location to monitor how AI Applications (Microsoft Copilot, AI systems created in Azure AI Foundry, AI Agents, and AI applications using 3 rd party Large Language Models). This Blog Post aims to provide the reader with a holistic understanding of achieving Data Security and Governance using Purview Data Security and Governance for AI offering. Purview DSPM is not to be confused with Defender Cloud Security Posture Management (CSPM) which is covered in the Blog Post Demystifying Cloud Security Posture Management for AI. Benefits When an organization adopts Microsoft Purview Data Security Posture Management (DSPM), it unlocks a powerful suite of AI-focused security benefits that helps them have a more secure AI adoption journey. Unified Visibility into AI Activities & Agents DSPM centralizes visibility across both Microsoft Copilots and third-party AI tools—capturing prompt-level interactions, identifying AI agents in use, and detecting shadow AI deployments across the enterprise. One‑Click AI Security & Data Loss Prevention Policies Prebuilt policies simplify deployment with a single click, including: Automatic detection and blocking of sensitive data in AI prompts, Controls to prevent data leakage to third-party LLMs, and Endpoint-level DLP enforcement across browsers (Edge, Chrome, Firefox) for third-party AI site usage. Sensitive Data Risk Assessments & Risky Usage Alerts DSPM runs regular automated and on-demand scans of top-priority SharePoint/E3 sites, AI interactions, and agent behavior to identify high-risk data exposures. This helps in detecting oversharing of confidential content, highlight compliance gaps and misconfigurations, and provides actionable remediation guidance. Actionable Insights & Prioritized Remediation The DSPM for AI overview dashboard offers actionable insights, including: Real-time analytics, usage trends, and risk scoring for AI interactions, and Integration with Security Copilot to guide investigations and remediation during AI-driven incidents. Features and Coverage Data Security Posture Management for AI (DSPM-AI) helps you gain insights into AI usage within the organization, the starting point is activating the recommended preconfigured policies using single-click activations. The default behavior for DSPM-AI is to run weekly data risk assessments for the top 100 SharePoint sites (based on usage) and provide data security admins with relevant insights. Organizations get an overview of how data is being accessed and used by AI tools. Data Security administrators can use on-demand classifiers as well to ensure that all contents are properly classified or scan items that were not scanned to identify whether they contain any sensitive information or not. AI access to data in SharePoint site can be controlled by the Data Security administrator using DSPM-AI. The admin can specify restrictions based on data labels or can apply a blanket restriction to all data in a specific site. Organizations can further expand the risks assessments with their own custom data risk assessments, a feature that is currently in preview. Thanks to its recommendations section, DSPM-AI helps data security administrators achieve faster time to value. Below is a sample of the policy to “Capture interactions for enterprise AI apps” that can be created using recommendations. More details about the recommendations that a Data Security Administrator can expect can be found at the DSPM-AI Documentation, these recommendations might be different in the environment based on what is relevant to each organization. Following customers’ feedback, Microsoft have announced during Ignite 2025 (18-21 Nov 2025, San Francisco – California) the inclusion of these recommendations in the Data Security Posture Management (DSPM) recommendations section, this helps Data Security Administrators view all relevant data security recommendations in the same place whether they apply to human interactions, tools interactions, or AI interactions of the data. More details about the new Microsoft Purview Data Security Posture Management (DSPM) experience are published in the Purview Technical Blog site under the article Beyond Visibility: The new Microsoft Purview Data Security Posture Management (DSPM) experience. After creating/enabling the Data Security Policies, Data Security Administrators can view reports that show AI usage patterns in the organization, in these reports Data Security Administrators will have visibility into interaction activities. Including the ability to dig into details. In the same reports view, Data Security Administrators will also be able to view reports regarding AI interactions with data including sensitive interactions and unethical interactions. And similar to activities, the Data Security Administrator can dig into Data interactions. Under reports, Data Security Administrators will also have visibility regarding risky user interaction patterns with the ability to drill down into details. Adaption This section provides an overview of the requirements to enable Data Security Posture Management for AI in an organization’s tenant. License Requirements The license requirements for Data Security Posture Management for AI depends on what features the organization needs and what AI workloads they expect to cover. To cover Interaction, Prompts, and Response in DSPM for AI, the organization needs to have a Microsoft 365 E5 license, this will cover activities from: Microsoft 365 Copilot, Microsoft 365 Copilot Chat, Security Copilot, Copilot in Fabric for Power BI only, Custom Copilot Studio Agents, Entra-registered AI Applications, ChatGPT enterprise, Azure AI Services, Purview browser extension, Browser Data Security, and Network Data Security. Information regarding licensing in this article is provided for guidance purposes only and doesn’t provide any contractual commitment. This list and license requirements are subject to change without any prior notice and readers are encouraged to consult with their Account Executive to get up-to-date information regarding license requirements and coverage. User Access Rights requirements To be able to view, create, and edit in Data Security Posture Management for AI, the user should have a role or role group: Microsoft Entra Compliance Administrator role Microsoft Entra Global Administrator role Microsoft Purview Compliance Administrator role group To have a view-only access to Data Security Posture Management for AI, the user should have a role or role group: Microsoft Purview Security Reader role group Purview Data Security AI Viewer role AI Administrator role from Entra Purview Data Security AI Content Viewer role for AI interactions only Purview Data Security Content Explorer Content Viewer role for AI interactions and file details for data risk assessments only For more details, including permissions needed per activity, please refer to the Permissions for Data Security Posture Management for AI documentation page. Technical Requirements To start using Data Security Posture Management for AI, a set of technical requirements need to be met to achieve the desired visibility, these include: Activating Microsoft Purview Audit: Microsoft Purview Audit is an integrated solution that help organizations effectively respond to security events, forensic investigations, internal investigations, and compliance obligations. Enterprise version of Microsoft Purview data governance: Needed to support the required APIs to cover Copilot in Fabric and Security Copilot. Installing Microsoft Purview browser extension: The Microsoft Purview Compliance Extension for Edge, Chrome, and Firefox collects signals that help you detect sharing sensitive data with AI websites and risky user activity activities on AI websites. Onboard devices to Microsoft Purview: Onboarding user devices to Microsoft Purview allows activity monitoring and enforcement of data protection policies when users are interacting with AI apps. Entra-registered AI Applications: Should be integrated with the Microsoft Purview SDK. More details regarding consideration for deploying Data Security Posture Management for AI can be found in the Data Security Posture Management for AI considerations documentation page. Conclusion Data Security Posture Management for AI helps Data Security Administrators gain more visibility regarding how AI Applications (Systems, Agents, Copilot, etc.) are interacting with their data. Based on the license entitlements an organization has under its agreement with Microsoft, the organization might already have access to these capabilities and can immediately start leveraging them to reduce the potential impact of any data-associated risks originating from its AI systems.Share Your Experience with Microsoft Purview on Gartner Peer Insights!
When deciding which products to include in an RFP or to purchase, companies often look at reviews from real customers. At Microsoft, we are committed to delivering top-notch security solutions that meet your needs and exceed your expectations. Additionally, we’re always looking to get more online reviews from users of our products. You would have the chance to help your peers, who can benefit from your experiences and feedback so that they buy products they can trust. And as a token of our appreciation for taking 10 minutes to fill out a review, Gartner Peer Insights will prompt you to choose a $25 USD gift card option! How to Submit Your Review for Microsoft Purview Communication Compliance: Click this direct link: Purview Communication Compliance. You’ll be prompted to create an account first or log in. Once you have completed your review, GPI will prompt you to choose a gift card option. As soon as your review is approved, the card will be made available to you digitally. You can also click this link to review other Microsoft Security Products that you are familiar with. Privacy/Guidelines: Please Note: Only Microsoft customers are eligible to participate. Microsoft partners, MVPs and Microsoft employees are not eligible. Microsoft Privacy Statement Gartner’s Community Guidelines & Gartner Peer Insights Review Guide Please feel free to comment on this post or message RenWoods with any questions!Secure external attachments with Purview encryption
If you are using Microsoft Purview to secure email attachments, it’s important to understand how Conditional Access (CA) policies and Guest account settings influence the experience for external recipients. Scenario 1: Guest Accounts Enabled ✅ Smooth Experience Each recipient is provisioned with a guest account, allowing them to access the file seamlessly. 📝 Note This can result in a significant increase in guest users, potentially in hundreds or thousands, which may create additional administrative workload and management challenges. Scenario 2: No Guest Accounts 🚫 Limited Access External users can only view attachments via the web interface. Attempts to download then open the files in Office apps typically fail due to repeated credential prompts. 🔍 Why? Conditional Access policies may block access to Microsoft Rights Management Services because it is included under All resources. This typically occurs when access controls such as Multi-Factor Authentication (MFA) or device compliance are enforced, as these require users or guests to authenticate. To have a better experience without enabling guest accounts, consider adjusting your CA policy with one of the below approaches: Recommended Approach Exclude Microsoft Rights Management Services from CA policies targeting All resources. Alternative Approach Exclude Guest or External Users → Other external users from CA policies targeting All users. Things to consider These access blocks won’t appear in sign-in logs— as this type of external users leave no trace. Manual CA policy review is essential. Using What if feature with the following conditions can help to identify which policies need to be modified. These approaches only apply to email attachments. For SharePoint Online hosted files, guest accounts remain the only viable option. Always consult your Identity/Security team before making changes to ensure no unintended impact on other workloads. References For detailed guidance on how guest accounts interact with encrypted documents, refer to Microsoft’s official documentation: 🔗 Microsoft Entra configuration for content encrypted by Microsoft Purview Information Protection | Microsoft LearnAI Security Ideogram: Practical Controls and Accelerated Response with Microsoft
Overview As organizations scale generative AI, two motions must advance in lockstep: hardening the AI stack (“Security for AI”) and using AI to supercharge SecOps (“AI for Security”). This post is a practical map—covering assets, common attacks, scope, solutions, SKUs, and ownership—to help you ship AI safely and investigate faster. Why both motions matter, at the same time Security for AI (hereafter ‘ Secure AI’ ) guards prompts, models, apps, data, identities, keys, and networks; it adds governance and monitoring around GenAI workloads (including indirect prompt injection from retrieved documents and tools). Agents add complexity because one prompt can trigger multiple actions, increasing the blast radius if not constrained. AI for Security uses Security Copilot with Defender XDR, Microsoft Sentinel, Purview, Entra, and threat intelligence to summarize incidents, generate KQL, correlate signals, and recommend fixtures and betterments. Promptbooks make automations easier, while plugins provide the opportunity to use out of the box as well as custom integrations. SKU: Security Compute Units (SCU). Responsibility: Shared (customer uses; Microsoft operates). The intent of this blog is to cover Secure AI stack and approaches through matrices and mind map. This blog is not intended to cover AI for Security in detail. For AI for Security, refer Microsoft Security Copilot. The Secure AI stack at a glance At a high level, the controls align to the following three layers: AI Usage (SaaS Copilots & prompts) — Purview sensitivity labels/DLP for Copilot and Zero Trust access hardening prevent oversharing and inadvertent data leakage when users interact with GenAI. AI Application (GenAI apps, tools, connectors) — Azure AI Content Safety (Prompt Shields, cross prompt injection detection), policy mediation via API Management, and Defender for Cloud’s AI alerts reduce jailbreaks, XPIA/UPIA, and tool based exfiltration. This layer also includes GenAI agents. AI Platform & Model (foundation models, data, MLOps) — Private Link, Key Vault/Managed HSM, RBAC controlled workspaces and registries (Azure AI Foundry/AML), GitHub Advanced Security, and platform guardrails (Firewall/WAF/DDoS) harden data paths and the software supply chain end-to-end. Let’s understand the potential attacks, vulnerabilities and threats at each layer in more detail: 1) Prompt/Model protection (jailbreak, UPIA/system prompt override, leakage) Scope: GenAI applications (LLM, apps, data) → Azure AI Content Safety (Prompt Shields, content filters), grounded-ness detection, safety evaluations in Azure AI Foundry, and Defender for Cloud AI threat protection. Responsibility: Shared (Customer/Microsoft). SKU: Content Safety & Azure OpenAI consumption; Defender for Cloud – AI Threat Protection. 2) Cross-prompt Injection (XPIA) via documents & tools Strict allow-lists for tools/connectors, Content Safety XPIA detection, API Management policies, and Defender for Cloud contextual alerts reduce indirect prompt injection and data exfiltration. Responsibility: Customer (config) & Microsoft (platform signals). SKU: Content Safety, API Management, Defender for Cloud – AI Threat Protection. 3) Sensitive data loss prevention for Copilots (M365) Use Microsoft Purview (sensitivity labels, auto-labeling, DLP for Copilot) with enterprise data protection and Zero Trust access hardening to prevent PII/IP exfiltration via prompts or Graph grounding. Responsibility: Customer. SKU: M365 E5 Compliance (Purview), Copilot for Microsoft 365. 4) Identity & access for AI services Entra Conditional Access (MFA/device), ID Protection, PIM, managed identities, role based access to Azure AI Foundry/AML, and access reviews mitigate over privilege, token replay, and unauthorized finetuning. Responsibility: Customer. SKU: Entra ID P2. 5) Secrets & keys Protect against key leakage and secrets in code using Azure Key Vault/Managed HSM, rotation policies, Defender for DevOps and GitHub Advanced Security secret scanning. Responsibility: Customer. SKU: Key Vault (Std/Premium), Defender for Cloud – Defender for DevOps, GitHub Advanced Security. 6) Network isolation & egress control Use Private Link for Azure OpenAI and data stores, Azure Firewall Premium (TLS inspection, FQDN allow-lists), WAF, and DDoS Protection to prevent endpoint enumeration, SSRF via plugins, and exfiltration. Responsibility: Customer. SKU: Private Link, Firewall Premium, WAF, DDoS Protection. 7) Training data pipeline hardening Combine Purview classification/lineage, private storage endpoints & encryption, human-in-the-loop review, dataset validation, and safety evaluations pre/post finetuning. Responsibility: Customer. SKU: Purview (E5 Compliance / Purview), Azure Storage (consumption). 8) Model registry & artifacts Use Azure AI Foundry/AML workspaces with RBAC, approval gates, versioning, private registries, and signed inferencing images to prevent tampering and unauthorized promotion. Responsibility: Customer. SKU: AML; Azure AI Foundry (consumption). 9) Supply chain & CI/CD for AI apps GitHub Advanced Security (CodeQL, Dependabot, secret scanning), Defender for DevOps, branch protection, environment approvals, and policy-as-code guardrails protect pipelines and prompt flows. Responsibility: Customer. SKU: GitHub Advanced Security; Defender for Cloud – Defender for DevOps. 10) Governance & risk management Microsoft Purview AI Hub, Compliance Manager assessments, Purview DSPM for AI, usage discovery and policy enforcement govern “shadow AI” and ensure compliant data use. Responsibility: Customer. SKU: Purview (E5 Compliance/addons); Compliance Manager. 11) Monitoring, detection & incident Defender for Cloud ingests Content Safety signals for AI alerts; Defender XDR and Microsoft Sentinel consolidate incidents and enable KQL hunting and automation. Responsibility: Shared. SKU: Defender for Cloud; Sentinel (consumption); Defender XDR (E5/E5 Security). 12) Existing landing zone baseline Adopt Azure Landing Zones with AI-ready design, Microsoft Cloud Security Benchmark policies, Azure Policy guardrails, and platform automation. Responsibility: Customer (with Microsoft guidance). SKU: Guidance + Azure Policy (included); Defender for Cloud CSPM. Mapping attacks to controls This heatmap ties common attack themes (prompt injection, cross-prompt injection, sensitive data loss, identity & keys, network egress, training data, registries, supply chain, governance, monitoring, and landing zone) to the primary Microsoft controls you’ll deploy. Use it to drive backlog prioritization. Quick decision table (assets → attacks → scope → solution) Use this as a guide during design reviews and backlog planning. The rows below are a condensed extract of the broader map in your workbook. Asset Class Possible Attack Scope Solution Data Sensitive info disclosure / Risky AI usage Microsoft AI Purview DSPM for AI; Purview DSPM for AI + IRM Unknown interactions for enterprise AI apps Microsoft AI Purview DSPM for AI Unethical behavior in AI apps Microsoft AI Purview DSPM for AI + Comms Compliance Sensitive info disclosure / Risky AI usage Non-Microsoft AI Purview DSPM for AI + IRM Unknown interactions for enterprise AI apps Non-Microsoft AI Purview DSPM for AI Unethical behavior in AI apps Non-Microsoft AI Purview DSPM for AI + Comms Compliance Models (MaaS) Supply-chain attacks (ML registry / DevOps of AI) OpenAI LLM OOTB built-in; Azure AI Foundry – Content Safety / Prompt Shield; Defender for AI – Run-time Secure registries/workspaces compromise OpenAI LLM OOTB built-in Secure models running inside containers OpenAI LLM OOTB built-in Training data poisoning OpenAI LLM OOTB built-in Model theft OpenAI LLM OOTB built-in Prompt injection (XPIA) OpenAI LLM OOTB built-in; Azure AI Foundry – Content Safety / Prompt Shield Crescendo OpenAI LLM OOTB built-in Jailbreak OpenAI LLM OOTB built-in Supply-chain attacks (ML registry / DevOps of AI) Non-OpenAI LLM Azure AI Foundry – Content Safety / Prompt Shield; Defender for AI – Run-time Secure registries/workspaces compromise Non-OpenAI LLM Azure AI Foundry – Content Safety / Prompt Shield; Defender for AI – Run-time Secure models running inside containers Non-OpenAI LLM Azure AI Foundry – Content Safety / Prompt Shield; Defender for AI – Run-time Training data poisoning Non-OpenAI LLM Azure AI Foundry – Content Safety / Prompt Shield; Defender for AI – Run-time Model theft Non-OpenAI LLM Azure AI Foundry – Content Safety / Prompt Shield; Defender for AI – Run-time Prompt injection (XPIA) Non-OpenAI LLM Azure AI Foundry – Content Safety / Prompt Shield; Defender for AI – Run-time Crescendo Non-OpenAI LLM Azure AI Foundry – Content Safety / Prompt Shield; Defender for AI – Run-time Jailbreak Non-OpenAI LLM Azure AI Foundry – Content Safety / Prompt Shield; Defender for AI – Run-time GenAI Applications (SaaS) Jailbreak Microsoft Copilot SaaS OOTB built-in Prompt injection (XPIA) Microsoft Copilot SaaS OOTB built-in Wallet abuse Microsoft Copilot SaaS OOTB built-in Credential theft Microsoft Copilot SaaS OOTB built-in Data leak / exfiltration Microsoft Copilot SaaS OOTB built-in Insecure plugin design Microsoft Copilot SaaS Responsibility: Provider/Creator Example 1: Microsoft plugin: responsibility to secure lies with Microsoft Example 2: 3rd party custom plugin: responsibility to secure lies with the 3rd party provider. Example 3: customer-created plugin: responsibility to secure lies with the plugin creator. Shadow AI Microsoft Copilot SaaS or non-Microsoft SaaS gen AI APPS: Purview DSPM for AI (endpoints where browser extension is installed) + Defender for Cloud Apps AGENTS: Entra agent ID (preview) + Purview DSPM for AI Jailbreak Non-Microsoft GenAI SaaS SaaS provider Prompt injection (XPIA) Non-Microsoft GenAI SaaS SaaS provider Wallet abuse Non-Microsoft GenAI SaaS SaaS provider Credential theft Non-Microsoft GenAI SaaS SaaS provider Data leak / exfiltration Non-Microsoft GenAI SaaS Purview DSPM for AI Insecure plugin design Non-Microsoft GenAI SaaS SaaS provider Shadow AI Microsoft Copilot SaaS or non-Microsoft SaaS GenAI APPS: Purview DSPM for AI (endpoints where browser extension is installed) + Defender for Cloud Apps AGENTS: Entra agent ID (preview) + Purview DSPM for AI Agents (Memory) Memory injection Microsoft PaaS (Azure AI Foundry) agents Defender for AI – Run-time* Memory exfiltration Microsoft PaaS (Azure AI Foundry) agents Defender for AI – Run-time* Memory injection Microsoft Copilot Studio agents Defender for AI – Run-time* Memory exfiltration Microsoft Copilot Studio agents Defender for AI – Run-time* Memory injection Non-Microsoft PaaS agents Defender for AI – Run-time* Memory exfiltration Non-Microsoft PaaS agents Defender for AI – Run-time* Identity Tool misuse / Privilege escalation Enterprise Entra for AI / Entra Agent ID – GSA Gateway Token theft & replay attacks Enterprise Entra for AI / Entra Agent ID – GSA Gateway Agent sprawl & orphaned agents Enterprise Entra for AI / Entra Agent ID – GSA Gateway AI agent autonomy Enterprise Entra for AI / Entra Agent ID – GSA Gateway Credential exposure Enterprise Entra for AI / Entra Agent ID – GSA Gateway PaaS General AI platform attacks Azure AI Foundry (Private Preview) Defender for AI General AI platform attacks Amazon Bedrock Defender for AI* (AI-SPM GA, Workload protection is on roadmap) General AI platform attacks Google Vertex AI Defender for AI* (AI-SPM GA, Workload protection is on roadmap) Network / Protocols (MCP) Protocol-level exploits (unspecified) Custom / Enterprise Defender for AI * *roadmap OOTB = Out of the box (built-in) This table consolidates the mind map into a concise reference showing each asset class, the threats/attacks, whether they are scoped to Microsoft or non-Microsoft ecosystems, and the recommended solutions mentioned in the diagram. Here is a mind map corresponding to the table above, for easier visualization: Mind map as of 30 Sep 2025 (to be updated in case there are technology enhancements or changes by Microsoft) OWASP-style risks in SaaS & custom GenAI apps—what’s covered Your map calls out seven high frequency risks in LLM apps (e.g., jailbreaks, cross prompt injection, wallet abuse, credential theft, data exfiltration, insecure plugin design, and shadow LLM apps/plugins). For Security Copilot (SaaS), mitigations are built-in/OOTB; for non-Microsoft AI apps, pair Azure AI Foundry (Content Safety, Prompt Shields) with Defender for AI (runtime), AISPM via MDCSPM (build-time), and Defender for Cloud Apps to govern unsanctioned use. What to deploy first (a pragmatic order of operations) Land the platform: Existing landing zone with Private Link to models/data, Azure Policy guardrails, and Defender for Cloud CSPM. Lock down identity & secrets: Entra Conditional Access/PIM and Key Vault + secret scanning in code and pipelines. Protect usage: Purview labels/DLP for Copilot; Content Safety shields and XPIA detection for custom apps; APIM policy mediation. Govern & monitor: Purview AI Hub and Compliance Manager assessments; Defender for Cloud AI alerts into Defender XDR/Sentinel with KQL hunting & playbooks. Scale SecOps with AI: Light up Copilot for Security across XDR/Sentinel workflows and Threat Intelligence/EASM. The below table shows the different AI Apps and the respective pricing SKU. There exists a calculator to estimate costs for your different AI Apps, Pricing - Microsoft Purview | Microsoft Azure. Contact your respective Microsoft Account teams to understand the mapping of the above SKUs to dollar value. Conclusion: Microsoft’s two-pronged strategy—Security for AI and AI for Security—empowers organizations to safely scale generative AI while strengthening incident response and governance across the stack. By deploying layered controls and leveraging integrated solutions, enterprises can confidently innovate with AI while minimizing risk and ensuring compliance.
