Why “Data in Switzerland” Is Not Enough
Moving from Residency to Control in Microsoft 365 Every conversation about data sovereignty in regulated industries tends to start the same way: “We use Multi-Geo. The data stays in Switzerland.” It’s the right starting point. Microsoft 365 Multi-Geo allows organizations to place selected workloads - SharePoint sites, OneDrive accounts, Teams data, or Exchange mailboxes - into specific regions, including Switzerland, while maintaining a single global tenant. This makes it possible to align sensitive data with regulatory or customer requirements without fragmenting the overall environment. But it only answers one question: Where is the data stored? It does not answer who accessed the data, from where, under which conditions, or what happened after access. That is where the real problem begins. A scenario that happens every day A Swiss engineering firm stores sensitive project documentation in Switzerland using Multi-Geo. An external contractor - working from an unmanaged device outside Switzerland - is granted access to review a file. The document opens. The data is now on a screen in an unknown location, on a device with no compliance posture, in a session with no restrictions. From the platform’s perspective, residency was enforced. From a sovereignty perspective, control was lost the moment access was granted without conditions. The file never left Switzerland. But sovereignty did. Residency is static. Control is not. The moment a document is opened, storage location stops being the relevant boundary. The file is no longer just “in Switzerland.” It moves instantly across endpoints and browsers, collaboration tools like Teams, external users and partners, and increasingly AI-driven contexts. The infrastructure remains unchanged. The data does not. From the platform’s perspective, everything is working as designed - access was granted, residency was enforced - and control was lost. Most “data in Switzerland” strategies fail at exactly this moment: when the data is used. The shift: from location to conditions If data sovereignty is the goal, the question must change. Not “Where is the data stored?” but: Under which conditions can data be accessed and used? This shift fundamentally changes the architecture. Control must be applied across three distinct layers - and all three must be connected. Layer 1: Access is conditional, not static Conditional Access extends control beyond authentication and turns it into continuous evaluation. Access decisions can depend on: Device compliance Location (geo-restriction) Identity and risk signals Multi-Geo ensures data is placed correctly. Conditional Access ensures it is reachable only under defined conditions. The two must work together - residency without access governance is an incomplete control. Layer 2: The session is the real risk surface Even with strict access controls, risk remains. A session is an exposure surface by design. During an active session, data is viewed, copied, shared, processed by applications, and connected to AI prompts. The gap does not appear at storage or authentication. It appears during active usage - inside the session. This is the layer most architectures do not explicitly address. Controls must extend into the session itself: limiting data transfer and replication, restricting interaction patterns, and enforcing policies in real time. Access is no longer a one-time event. It becomes continuously governed. This becomes even more critical as AI assistants consume content across SharePoint, Teams, Exchange, and other Microsoft 365 services. The question is no longer only where the source document resides - but whether the AI interaction itself is governed by the same access and protection controls as direct access. Layer 3: The document becomes the control point The most durable control does not sit in the network or in the session. It sits in the data itself. In regulated industries, organizations often arrive at this architecture having first evaluated sovereign or national encryption solutions. The decision to rely on native Microsoft 365 Purview encryption rather than a separate layer comes down to integration: AES-256 protection operating natively at file, user, and SharePoint level - including geo-based access restrictions - without an additional system to maintain. When protection is applied directly to the document through Microsoft Purview: Sensitivity labels define classification - automatically assigned based on content Encryption enforces access - AES-256, bound to the file itself IRM controls usage - view, copy, print, share, and presentation rights DLP governs movement across services - preventing data from leaving defined boundaries Dynamic watermarking tracks exposure - applied on open, view, or print At that point, access is enforced by the file, usage restrictions travel with it, and control persists regardless of location. The document becomes the perimeter. Platform control: limiting provider access One dimension often overlooked in sovereignty discussions is platform access itself. Even a perfectly configured tenant is only as sovereign as the controls placed on the operator. Customer Lockbox ensures that even Microsoft support cannot access customer data without explicit, logged, time-bound approval. Every access request is visible, auditable, and subject to customer veto. Data control applies not only to users - but also to the platform operating the service. Enforcement requires an integrated architecture Most organizations already have the required capabilities: Multi-Geo, Conditional Access, session control, Purview (labels, encryption, DLP, IRM), and monitoring. The issue is not capability. It is fragmentation. In practice, fragmentation looks like this: residency is configured in one project, Conditional Access policies are managed by a different team, and Purview labels were applied during a compliance initiative that never connected to the access layer. The tools exist. The signals do not flow between them. When designed as a single architecture: Data is placed intentionally - residency aligned to regulatory requirements Access is governed by context - device, location, and identity evaluated continuously Usage is controlled dynamically - session-level restrictions enforced in real time Protection is embedded in the document - encryption and IRM travel with the file Signals are connected across the platform - monitoring feeds access policy, not just audit logs “Data in Switzerland” becomes not just a statement - but an enforceable system property. Closing thought Placing data in Switzerland is the right first step. Multi-Geo makes it possible, even in global environments. But residency alone is not control. Data residency answers where information is stored. Data sovereignty requires proving who can access it, under which conditions, and what controls remain in place after access is granted. In Microsoft 365, sovereignty is no longer defined by geography alone. It is defined by the ability to enforce control wherever the data travels.Securing AI Agents End‑to‑End: Connecting Purview DSPM, Agent 365, and the AI Security Dashboard
The Challenge: Organizations deploying Microsoft Copilot and custom AI agents face a critical gap: security visibility is fragmented across data protection, identity governance, and threat detection tools. While Microsoft provides powerful capabilities through Purview Data Security Posture Management (DSPM), Agent 365, and the AI Security Dashboard, practitioners often struggle to understand how these components work together to deliver unified AI security posture management. This blog provides an architectural and operational blueprint for connecting these three pillars into a cohesive security framework that security architects can implement today. The Three Pillars: Capabilities Overview Microsoft Purview DSPM for AI Purview DSPM extends data‑centric security controls to AI interactions. Its key capabilities include: Sensitivity labels with EXTRACT usage rights that govern whether AI agents can read and process sensitive content Data Loss Prevention (DLP) policies that block or audit AI interactions involving confidential data across Copilot, SharePoint, OneDrive, and Teams Comprehensive audit logging that captures AI‑to‑data interactions, including user identity, agent identity, data classification, and the action taken Insider Risk Management integration that detects anomalous agent behavior patterns, such as bulk or unusual data access DSPM operates at the data layer, answering a foundational question: What sensitive information can this agent access, and what is it doing with that data? Microsoft Agent 365 Agent 365 provides a unified control plane for governing AI agent identity, access, and lifecycle across the Microsoft 365 ecosystem. Core components include: Agent Registry, backed by Entra Agent IDs, providing a unique identity for every Copilot Studio agent, custom agent, and supported third‑party AI integration Conditional Access policies that enforce real‑time access controls based on agent identity, user context, device compliance, and risk signals Centralized observability, with dashboards showing agent‑to‑agent interactions, agent‑to‑human conversations, and near real‑time telemetry Governance workflows that support agent approval, lifecycle management, suspension, and decommissioning Agent 365 operates at the identity and control layer, answering: Which agents exist, who authorized them, and what access boundaries are enforced? AI Security Dashboard The AI Security Dashboard aggregates security signals from Entra, Purview, and Defender to provide a unified risk view across all AI assets. It delivers: AI asset inventory, cataloging Copilot instances, custom agents, and third‑party models with associated risk context Misconfiguration detection, identifying agents with excessive permissions, missing conditional access policies, or DLP coverage gaps Attack path visualization, showing how compromised agents could pivot to sensitive data or escalate privileges Integration with Microsoft Security Copilot, enabling natural‑language investigation of AI security risks and incidents The Dashboard operates at the aggregation and recommendation layer, answering: What is my overall AI security posture, and where should remediation be prioritized? The Unified Architecture: How Signals Flow End-to-End Understanding the technical integration requires mapping how identity, data, and security signals flow across these three systems. Identity Foundation (Microsoft Entra): Every AI agent is assigned a unique Entra Agent ID at creation. This identity becomes the anchor for all security controls—conditional access policies in Agent 365, audit attribution in Purview, and risk correlation in the AI Security Dashboard. When a Copilot Studio agent is deployed, Entra automatically registers it with Agent 365 and propagates identity metadata to connected security services. Data Interaction Telemetry (Microsoft Purview): When an agent accesses SharePoint files, reads emails, or queries structured data, Purview captures detailed audit events that include agent identity, user context, data classification labels, and enforcement outcomes. These events flow into Purview’s unified audit log and are accessible through the Compliance portal, Microsoft Graph, and SIEM integrations. Crucially, Purview enforces sensitivity labels with EXTRACT usage rights—if a document is labeled Confidential without EXTRACT permission, the agent’s request is blocked before content reaches the AI model. Control Plane Enforcement (Agent 365): Agent 365 applies identity‑based governance by evaluating Entra signals and surfaced risk indicators. During policy evaluation, the control plane verifies whether the agent is registered, whether the invoking user satisfies authentication requirements, and whether recent signals (such as DLP violations) warrant blocking execution. Agent 365 also provides observability views that correlate agent activity with security events, helping administrators identify unmanaged or unauthorized (“shadow”) agents. Aggregated Risk View (AI Security Dashboard): The AI Security Dashboard correlates telemetry from: Entra — conditional access decisions, authentication anomalies, and privileged identity usage Purview — DLP violations, sensitivity label mismatches, and Insider Risk Management signals Defender — threat detections, application posture assessments, and suspicious activity indicators These signals are correlated by agent identity and time, then surfaced as risk cards with contextual severity and recommended remediation actions. The Dashboard does not replace the underlying tools; instead, it provides a consolidated view that helps teams focus on the most impactful risks. The diagram below illustrates how identity, data, and threat signals flow across the three AI security pillars. Figure 1: End‑to‑end AI security architecture. Enforcement happens at the data layer (Purview) and identity layer (Agent 365 via Entra). The AI Security Dashboard aggregates—rather than replaces—underlying security controls. From Architecture to Action: Telemetry & Enforcement Flow Understanding architecture is essential—but practitioners need to know when and where enforcement occurs during a real agent invocation. The sequence below illustrates runtime interaction between a user, an AI agent, and the three security pillars. The Critical Distinction: Two Enforcement Layers Enforcement occurs at two distinct points in the request lifecycle. First, Microsoft Entra validates agent identity and evaluates conditional access policies before execution begins. If the agent is not registered, if the user fails authentication requirements, or if policy conditions require blocking, execution is denied immediately. Second, when execution is permitted, Purview DSPM enforces data access controls inline. Every attempt to access documents, emails, or structured data is evaluated in real time. If a document is labeled Confidential without EXTRACT rights, Purview blocks the request and returns no sensitive content to the agent. Telemetry Generation Across the Stack Each step produces structured telemetry. Entra logs authentication attempts and policy decisions. Purview records AI interaction audit events, including enforcement outcomes. Agent 365 correlates identity and behavior signals to maintain agent posture and observability. These combined signals are surfaced in the AI Security Dashboard, which correlates activity across time and identity to present prioritized risk insights. Make the “where enforcement happens” distinction explicit (data vs. identity). Figure 2: Purview enforces data controls inline, Agent 365 enforces identity and execution controls, and the AI Security Dashboard correlates signals for prioritization. Practitioner Scenario: Detecting and Blocking Agent Data Exposure Context: Your organization deploys a custom Copilot Studio agent to summarize sales proposals stored in SharePoint. Several documents contain customer PII labeled "Highly Confidential" with no EXTRACT usage rights granted. Incident Timeline: Agent Data Exposure Detection → Remediation Detection The agent attempts to access SharePoint files through Microsoft Graph. Purview DSPM evaluates sensitivity labels and identifies restricted documents. A DLP policy blocks access and logs a violation with full context. The audit event appears in the Purview unified audit log within minutes. Visibility Agent 365 flags the blocked interaction in its observability dashboard. The AI Security Dashboard surfaces a High‑severity risk card titled “Agent accessing restricted data.” Security teams investigate the agent using Security Copilot to determine scope and recurrence. Remediation An administrator applies an Entra conditional access policy to suspend the agent. Data permissions are adjusted to restrict access or explicitly grant EXTRACT rights where justified. The AI Security Dashboard reflects a reduced risk score once controls are validated. Outcome: The incident is contained quickly, audit evidence is preserved, and the agent is restored with least‑privilege access—without disrupting legitimate business workflows. Figure 3: A single DLP violation triggers coordinated detection, investigation, and remediation across Purview, Agent 365, and the AI Security Dashboard within 30 minutes. Division of Responsibility: What Each Tool Does Tool Primary Function Key Signals Enforcement Capability Purview DSPM Data-layer protection and audit Sensitivity labels, DLP violations, data access patterns Blocks API calls violating DLP or label policies Agent 365 Identity and lifecycle governance Agent registry, conditional access hits, observability telemetry Denies agent invocation based on Entra policies AI Security Dashboard Unified risk aggregation Cross-product signals from Entra, Purview, Defender No direct enforcement—provides recommendations and prioritization Critical Distinction: Enforcement happens at two layers—Purview blocks data access violations, while Agent 365 (via Entra) blocks agent invocation. The Dashboard does not enforce policies but accelerates investigation and remediation by correlating signals that would otherwise require manual analysis across three separate consoles. Key Takeaways for Practitioners Agent identity is the integration anchor. Every security control—DLP policies, conditional access, audit logs, risk scoring—relies on Entra Agent IDs. Ensure all agents are properly registered in Agent 365 before production deployment. Purview enforces at the data layer, Agent 365 at the identity layer. Use both—Purview prevents unauthorized data exfiltration, while Agent 365 prevents unauthorized agent execution. Neither is redundant. The AI Security Dashboard is for prioritization, not replacement. Continue using Purview Compliance Portal for detailed DLP investigations and Agent 365 registry for operational monitoring. Use the Dashboard to identify which risks warrant immediate attention. Audit logs are your ground truth. All three tools consume Purview audit events. Integrate these logs with Microsoft Sentinel or your SIEM for long-term retention and advanced threat hunting. Shadow agents are your blind spot. Regularly audit the Agent 365 registry against actual AI deployments (Copilot Studio, Azure OpenAI, third-party integrations) to identify unregistered instances. As AI agents become embedded in everyday work, security teams must move beyond feature‑level understanding and adopt an end‑to‑end enforcement mindset. The combination of Purview DSPM, Agent 365, and the AI Security Dashboard provides the building blocks—but value is realized only when they are implemented as a unified model. How are you governing AI agents in your environment today? Share your experiences and patterns in the comments—especially where identity, data, and security signals intersect.
Windows Hello passkeys dialog appearing and cannot remove or suppress it.
Hi everyone, I’m dealing with a persistent Windows Hello and passkey issue in Chrome and Brave and yes this is relevant as they're the only browsers having this issue whilst Edge for example is fine, and at this point I’m trying to understand whether this is expected behavior, a bug, or a design oversight. PS. Yes, I'm in contact with related browser support teams but since they seem utterly hopeless i'm asking here, since its at least partially Windows Hello issue. Problem description Even with: Password managers disabled in browser settings, Windows Hello disabled in Chrome/Brave settings, Windows Hello PIN enabled only for device login, Passkeys still stored under chrome://settings/passkeys (which I cannot delete since its used for logging on the device), The devices are connected to Entra ID but this is not required to reproduce the issue although a buisness account configuration creates a Passkey with Windows Hello afaik. Observed behavior When I attempt to sign in on office.com, Windows Hello automatically triggers a dialog offering authentication via passkeys, even though: I don’t want passkeys used for browser logins, passkeys are turned off everywhere they can be, Windows Hello is intended only for local device authentication. The dialog cannot be suppressed, disabled, or hidden(trust me, i tried for weeks). It effectively forces the Windows Hello prompt as a primary option, which causes problems both personally and in business contexts (wrong credential signaling, misleading users that are supposed to use a dedicated password manager solution insted of browser password managers, enforcing an unwanted authentication flow, etc.). What I already verified Many, many, (too many) Windows registry workarounds that never worked. Dug through almost all flags on those browsers. Chrome/Brave → Password Manager: disabled Chrome/Brave → Windows Hello toggle: off Looked through what feels like almost every related option in Windows Settings. Tried gpedit.msc local rules System up to date Windows Hello configured to use PIN, but stores "passkeys used to log on to this device" Why this is a problem Windows Hello automatically assumes that the device-level Windows Hello credentials should always be available as a WebAuthn authenticator. This feels like a big security and UX issue due to: unexpected authentication dialogs, Inability to controll where and how passkey credential are shared to applications, inability to turn the feature off, no administrative or local option to disable Hello for WebAuthn separately from device login. Buisness users either having issues with keeping passwords in order (our buissnes uses a dedicated Password Manager but this behaviour covers its dialog option) or not having PIN to their devices (when I disable windows hello entierly, since when there is no passkeys the option doesn't appear) Questions Is there any supported way to disable Windows Hello as a WebAuthn/passkey option in browsers, while keeping Hello enabled for local device login? Is this expected behavior from the Windows Hello, or is it considered a bug? Are there registry/policy settings (documented or upcoming) that allow disabling the Windows platform authenticator specifically for browsers like Chrome and Brave? Is Microsoft aware of this issue? If so, is it tracked anywhere? Additional notes This issue replicates 100% across (as long as there are passkeys configured): Windows 11 devices i've managed to get my hands on, Chrome and Brave (latest versions), multiple Microsoft accounts and tenants, multiple clean installations. Any guidance or clarification from the Windows security or identity teams would be greatly appreciated. And honestly if there is any more info i could possibly provide PLEASE ask away.Security Dashboard for AI: 3 Ways CISOs Drive Impact Today
AI is reshaping the enterprise and, with it, the threat landscape. Today's organizations face new threats with AI agents that modify configurations, execute workflows, and access data without direct human oversight. As a result, the gap between AI adoption and AI governance is widening, and CISOs face growing challenges to maintain visibility, control, and compliance across an increasingly complex ecosystem. As AI becomes embedded across the enterprise, CISOs face four key challenges: Scale without visibility: Over 75% of enterprises surveyed by PWC report they are already adopting AI agents. ¹ At the same time, over 80% of security teams surveyed by Nokod report visibility gaps into the applications and AI agents created within their organization. ² Rapid AI proliferation and evolving regulations make unified visibility across AI platforms, apps, and agents critical for CISOs. Fragmentation: Organizations rely on multiple siloed tools for AI asset visibility, making oversight fragmented and inefficient. According to Gartner’s 2024 survey of 162 enterprises, organizations use 45 cybersecurity tools on average. Expanding AI risk: AI proliferation is rapidly increasing the attack and risk surface, with the surge of AI-generated identities. By 2027, 4 out of 5 organizations will face phishing attacks powered by AI-generated synthetic identities, according to IDC. ³ This makes it harder for CISOs to track emerging threats, unmanaged assets, and shifting risk patterns. Overload: Alert fatigue is now a top challenge, with organizations now receiving an average of 2,992 security alerts daily, yet 63% go unaddressed. ⁴ Increasing AI risk without a way to prioritize what matters most compounds pressure on CISOs. In conversations between Microsoft and CISOs, one common need emerged: a single place to view integrated AI risk across the enterprise. To address these growing challenges, we are excited to provide CISOs with the Security Dashboard for AI, which recently became generally available. This unified dashboard aggregates posture and real-time risk signals from Microsoft Defender, Entra, and Purview into one unified, executive-level view of AI posture, risk, and inventory across agents, apps, and platforms. The Security Dashboard for AI helps CISOs: Gain unified AI risk visibility: Discover AI agents and applications and continuously monitor posture across the environment Prioritize critical risks: Correlate signals across identity, data, and threat protection to surface the most urgent issues Drive risk mitigations: Investigate activity and take action to help reduce exposure across the AI ecosystem The dashboard is capable of aggregating and surfacing AI risks from across Microsoft Defender, Entra, Purview - including Microsoft 365 Copilot, Microsoft Copilot Studio agents, and Microsoft Foundry applications and agents as well as cross-platform AI risks with Microsoft network-based or SDK-enabled integrations, and MCP servers. This supports comprehensive visibility and control, regardless of where applications and agents are built. As you activate Microsoft Security for AI capabilities, you can gain richer visibility into different aspects of your AI risk posture. Figure 1: Security Dashboard for AI in browser Getting Started with the Security Dashboard for AI The Security Dashboard for AI is provided at no additional cost to customers already using Defender, Entra, and/or Purview to protect their AI innovation. Based on how early adopter CISOs are using the dashboard, here are three ways you can start leveraging the dashboard today. 1. Manage Daily AI Risk Beyond reporting, you must stay hands-on with AI risks, scanning for emerging issues, verifying asset governance, and delegating remediations. The Security Dashboard for AI consolidates daily operations into a single pane of glass, surfacing critical alerts, unmanaged assets, and emerging risks. Use the dashboard as a daily AI risk radar, enabling rapid triage and ensuring you focus on the most urgent threats. Scan and triage daily AI risk: Start each day by identifying and prioritizing the highest-risk AI exposures. Risks are prioritized on severity reported by underlying security tools, helping you focus on the most critical exposures. Track AI asset inventory and monitor agent sprawl: Use the Inventory page to gain comprehensive visibility into all AI assets. Identify newly registered assets to mitigate the risk of shadow or unmanaged IT and surface inactive agents to proactively monitor and control agent sprawl. Delegate tasks for remediation: Move from insight to action by delegating tasks to your security team with easy click delegation. Delegation routes ownership via email or Microsoft Teams with notifications, due date, and ownership tracking. Delegate actions to specific roles such as global admin and AI administrator, without granting full access to underlying tools. Figure 2: Security Dashboard for AI risk page 2. Guide Briefings with Security Teams You require up-to-date intelligence to guide conversations with Security Teams about what is happening across the AI estate. The Security Dashboard for AI helps you anchor discussions in specific risks, trends, and ownership gaps surfaced in the data. The dashboard becomes a conversation driver, helping you ask the right questions about risk and security posture, to help ensure you and your team are triaging the right priorities. Because the dashboard consolidates signals from Defender, Entra, and Purview, both CISO and security teams operate from the same facts, enabling more outcome-driven discussions and faster prioritization, so you can shift the conversations from status updates to targeted action planning. Prioritize top AI Risk: Use the dashboard to help you prioritize the AI risk that matters the most. In preparation for team meetings, use Microsoft Security Copilot to explore AI risks, agent activity, and security recommendations via prompts to strengthen your AI security posture. With your team, take a closer look at risk vectors like data leakage, oversharing and unethical behavior, and discuss what actions need to be taken. Review Security Recommendations: Create a routine with your security team to review the recommended Microsoft security actions and track your progress over time. Across regular team check‑ins, review what has been addressed, what remains open, and which actions require follow‑up so you are prepared to respond to regulatory, audit, or executive questions with up‑to‑date metrics. Figure 3: Security Dashboard for AI inventory page Figure 4: Security Dashboard for AI delegation 3. Executive Reporting Reporting to the board on AI security posture has historically meant weeks of manual data gathering across multiple tools. The Security Dashboard for AI streamlines the data collection process with a single source of truth for AI risk, enabling confident, data-backed insights for your board presentations and conversations. Early adopters confirm the value and are using it for quarterly executive briefings. Prepare for Board Discussions: Use the dashboard to help get the right insights at the right altitude to help you prepare for discussions with your board. The Overview page aggregates identity, data security, and threat protection signals from Defender, Entra, and Purview into an AI risk scorecard with risk factors. The embedded Security Copilot AI-powered insights provide suggested prompts with risk assessments, summaries, and recommendations to help you prioritize what matters most. Extend Observability to Executive Stakeholders: Authorize AI risk follow‑ups to the appropriate security, identity, or governance owners using Microsoft Teams or email. Distribute visibility across GRC lead, AI governance, and IT leaders, while maintaining executive‑level oversight. Figure 5: Security Dashboard for AI Copilot prompt gallery Next Steps The Security Dashboard for AI helps CISOs manage AI risk faster, more confidently and more collaboratively with their team. Defender, Entra, and Purview signals are surfaced in a single pane of glass, providing observability across your AI estate. Drive faster triage, use data to support board-level discussions about AI risk, and enable coordinated action with integrated insights, recommendations, and delegation to help accelerate remediation across existing security workflows. The Security Dashboard for AI is generally available now. If your organization uses Microsoft Defender, Entra, and/or Purview, you already have access, no additional licensing is required. Visit ai.security.microsoft.com to access the dashboard directly, or navigate to it from the Defender, Entra, or Purview portals. Learn more about the Security Dashboard for AI on the MS Learn page and the Security Dashboard for AI Security Blog. Discover new features in the Security Dashboard for AI such as the Security Reader role, new delegation flow, and new identity risk section here. ¹AI agent survey. PwC, May 2025 ²Security Teams Taking on Expanded AI Data Responsibilities. Bedrock Data, March 2025 ³IDC FutureScape: Worldwide Security and Trust 2026 Predictions, November 2025 ⁴2026 State of Threat Detection and Response Report. Vectra AI, February 2026Security Dashboard for AI - Now Generally Available
AI proliferation in the enterprise, combined with the emergence of AI governance committees and evolving AI regulations, leaves CISOs and AI risk leaders needing a clear view of their AI risks, such as data leaks, model vulnerabilities, misconfigurations, and unethical agent actions across their entire AI estate, spanning AI platforms, apps, and agents. 53% of security professionals say their current AI risk management needs improvement, presenting an opportunity to better identify, assess and manage risk effectively. 1 At the same time, 86% of leaders prefer integrated platforms over fragmented tools, citing better visibility, fewer alerts and improved efficiency. 2 To address these needs, we are excited to announce the Security Dashboard for AI, previously announced at Microsoft Ignite, is now generally available. This unified dashboard aggregates posture and real-time risk signals from Microsoft Defender, Microsoft Entra, and Microsoft Purview - enabling users to see left-to-right across purpose-built security tools from within a single pane of glass. The dashboard equips CISOs and AI risk leaders with a governance tool to discover agents and AI apps, track AI posture and drift, and correlate risk signals to investigate and act across their entire AI ecosystem. Security teams can continue using the tools they trust while empowering security leaders to govern and collaborate effectively. Gain Unified AI Risk Visibility Consolidating risk signals from across purpose-built tools can simplify AI asset visibility and oversight, increase security teams’ efficiency, and reduce the opportunity for human error. The Security Dashboard for AI provides leaders with unified AI risk visibility by aggregating security, identity, and data risk across Defender, Entra, Purview into a single interactive dashboard experience. The Overview tab of the dashboard provides users with an AI risk scorecard, providing immediate visibility to where there may be risks for security teams to address. It also assesses an organization's implementation of Microsoft security for AI capabilities and provides recommendations for improving AI security posture. The dashboard also features an AI inventory with comprehensive views to support AI assets discovery, risk assessments, and remediation actions for broad coverage of AI agents, models, MCP servers, and applications. The dashboard provides coverage for all Microsoft AI solutions supported by Entra, Defender and Purview—including Microsoft 365 Copilot, Microsoft Copilot Studio agents, and Microsoft Foundry applications and agents—as well as third-party AI models, applications, and agents, such as Google Gemini, OpenAI ChatGPT, and MCP servers. This supports comprehensive visibility and control, regardless of where applications and agents are built. Prioritize Critical Risk with Security Copilots AI-Powered Insights Risk leaders must do more than just recognize existing risks—they also need to determine which ones pose the greatest threat to their business. The dashboard provides a consolidated view of AI-related security risks and leverages Security Copilot’s AI-powered insights to help find the most critical risks within an environment. For example, Security Copilot natural language interaction improves agent discovery and categorization, helping leaders identify unmanaged and shadow AI agents to enhance security posture. Furthermore, Security Copilot allows leaders to investigate AI risks and agent activities through prompt-based exploration, putting them in the driver’s seat for additional risk investigation. Drive Risk Mitigation By streamlining risk mitigation recommendations and automated task delegation, organizations can significantly improve the efficiency of their AI risk management processes. This approach can reduce the potential hidden AI risk and accelerate compliance efforts, helping to ensure that risk mitigation is timely and accurate. To address this, the Security Dashboard for AI evaluates how organizations put Microsoft’s AI security features into practice and offers tailored suggestions to strengthen AI security posture. It leverages Microsoft’s productivity tools for immediate action within the practitioner portal, making it easy for administrators to delegate recommendation tasks to designated users. With the Security Dashboard for AI, CISOs and risk leaders gain a clear, consolidated view of AI risks across agents, apps, and platforms—eliminating fragmented visibility, disconnected posture insights, and governance gaps as AI adoption scales. Best of all, the Security Dashboard for AI is included with eligible Microsoft security products customers already use. If an organization is already using Microsoft security products to secure AI, they are already a Security Dashboard for AI customer. Getting Started Existing Microsoft Security customers can start using Security Dashboard for AI today. It is included when a customer has the Microsoft Security products—Defender, Entra and Purview—with no additional licensing required. To begin using the Security Dashboard for AI, visit http://ai.security.microsoft.com or access the dashboard from the Defender, Entra or Purview portals. Learn more about the Security Dashboard for AI at Microsoft Security MS Learn. 1AuditBoard & Ascend2 Research. The Connected Risk Report: Uniting Teams and Insights to Drive Organizational Resilience. AuditBoard, October 2024. 2Microsoft. 2026 Data Security Index: Unifying Data Protection and AI Innovation. Microsoft Security, 2026The Advantages of Premium Cases in Purview eDiscovery
Capacity & Scale Feature Description Advantage over E3 Enhanced Limits Supports significantly higher limits, including eDiscovery case count and export volume. For example, up to 50,000 cases and 5 TB per search in E5 (versus 10,000 cases and 2 TB in E3). Handles large investigations without splitting into multiple cases or searches. E3’s lower limits would force breaking up big jobs, adding overhead and risk of errors. E5’s higher capacity means fewer workarounds and seamless handling of large-scale litigation. Tenant-Wide eDiscovery Process and Holds Reports (Preview) Provides a central dashboard of all eDiscovery activities and eDiscovery holds across the tenant. Compliance and IT teams get at-a-glance status of ongoing jobs and active holds. Improves oversight and management efficiency for eDiscovery. E3 lacks centralized reporting, making it harder to track many cases. E5’s reporting gives better visibility into operations, which is crucial for heavy workloads and tight deadlines. Expanded Hold Capacity Each legal hold in E5 can encompass up to 2,000 mailboxes and 2,000 sites in one policy. E3 holds are limited to 1,000 mailboxes or 100 sites per policy. Enables placing very large custodian sets on hold with a single action. In E3, exceeding hold limits means juggling multiple policies for one case, increasing complexity. E5 simplifies hold management by consolidating more custodians per hold, reducing admin burden. Search & Collection Feature Description Advantage over E3 Advanced Search Filters Offers richer search criteria beyond keywords. You can filter by sensitive info types (credit cards, SSNs), specific message IDs, or sensitivity labels on documents. This helps pinpoint relevant sensitive content directly. Enables more precise and speedy discovery of critical data. In E3, finding the same info might require complex keyword strings or separate tools (with a higher chance of missing items). E5’s advanced filters mean faster, targeted searches for things like confidential data or GDPR content. Data Source Sync Allows you to refresh custodians’ data sources in a search or hold to catch updates to locations. For example, if a custodian adds a new OneDrive, E5 will detect and prompt you to include it. Ensures no content location is overlooked as the case evolves. E3 has no easy way to know if data moved or new sites were created, potentially leaving gaps. E5’s sync provides complete and defensible collection by keeping holds/searches up-to-date. Cloud Attachment Collection (Hyper-linked Documents) Automatically collects the content of files shared via cloud links (OneDrive/SharePoint) in emails or chats. E5 can retrieve the actual document (and its versions) that was linked, even pulling the specific version that was shared at the time if the version shared feature is enabled. Preserves evidence that E3 would miss. E3 eDiscovery does not fetch linked file content. It would only show a hyperlink, making it difficult to return the associated file. E5 ensures linked documents (with version history) are collected, so the full context of communications is retained. Conversation Threading (Chats & Email) Reconstructs conversations in a threaded view for Microsoft Teams chats and email chains. Reviewers can see messages in context (like a chat transcript or email thread) rather than as isolated items. Greatly improves contextual understanding. E3 exports chats as separate messages with no threading, making it hard to follow the story. E5’s threaded view lets reviewers grasp the full conversation at a glance, reducing confusion and ensuring nothing is interpreted out of context. Custodian & Hold Management Feature Description Advantage over E3 Case-Level Custodian Management Provides a dedicated tab to manage custodians (people) within each case. You add custodians once and can easily apply holds or searches to all their data without re-entering their information each time. Streamlines hold setup and ensures clarity on who is in the case. E3 has no concept of custodians. You must manually input email or site addresses for each search/hold. E5’s approach saves time, reduces errors, and gives a clear view of all people involved in the matter. Bulk Custodian Import Supports importing up to 1,000 custodians at once from a list into a case. Useful for large investigations (e.g., adding an entire department as custodians in one go). Dramatically faster setup for big cases. In E3, adding hundreds of people means typing or pasting each individually, which is time-consuming and error prone. E5’s bulk import means quick, one-time setup for large custodian lists, ensuring no one is missed. “Explore & Add” Custodian Sources Provides an intelligent way to discover related data sources for a given custodian. For example, it can list Teams, SharePoint sites, or groups the person is part of, and let you add those to the case. Helps capture all relevant locations for each person. In E3, you might overlook a Teams channel or group mailbox a custodian was involved in. E5’s explore feature surfaces those connections, improving completeness of your holds and searches by including collaboration spaces that might otherwise be missed. In-Place Review & Analytics Feature Description Advantage over E3 Advanced Indexing and OCR Automatically re-indexes content that was partially indexed or had errors and performs OCR (Optical Character Recognition) on images to extract text. This means files with images or previously unsearchable formats become searchable in E5. Ensures “no stone is left unturned.” E3 would flag such content as “unindexed” (meaning you know a file exists but not what’s inside it). With E5, far more data is searchable, even text inside images or scanned PDFs, reducing the amount of partially indexed content and the chance of missing critical evidence due to format issues. In-Place Review Sets Lets you create a review set of collected data in the cloud. Review sets offer contextual review of conversations, powerful query and filtering capabilities, and query reports for additional insights. Pre-review culling is possible in E5. E3 has no in-product review capability. You must export everything to an outside tool for examination. E5’s review sets allow the team to filter out irrelevant data and focus on what matters before exporting. This reduces the volume (and cost) of data sent for attorney review and keeps data in a secure, auditable environment during analysis. Tagging and Metadata Filters Enables applying tags (labels like “Responsive,” “Privileged,” “Personal Data”) to documents and emails in a review set, and filtering by these tags or other metadata fields. Improves organization and review workflow. E3 cannot tag items in-place, so keeping track of important documents is harder. In E5, tagging allows systematic categorization for quick retrieval (e.g., find all items tagged Highly Relevant instantly). These tags also carry over on export, so any work done during review isn’t lost when handing off to external counsel. Email Threading and Analytics Automatically identifies and stitches together email threads, showing only the last inclusive email that contains the entire conversation. Earlier duplicate emails in the chain are noted and can be skipped. Cuts down review volume and improves context. E3 reviewers would see every single email (even if content repeats across replies). This saves review time and ensures attorneys see the full discussion in one place rather than piecemeal. Conversation View Displays collected Teams (and other chat) messages in a conversation format in a review set, similar to how one would view a chat in the app, instead of individual out-of-context messages. Makes reviewing chat evidence much easier. In E3, chat messages are isolated, forcing reviewers to manually piece together who said what when. E5’s conversational view provides full context at a glance, so nothing is misunderstood or missed in chat-based communications. Near-Duplicate Detection Finds and groups nearly identical documents (e.g. multiple versions of a file or emails with only slight differences). Reviewers are informed which items are alike. Saves time and ensures consistency. E3 requires manually spotting similar files. E5 can let a reviewer examine one version and then quickly tag all its close duplicates the same way. This speeds up review and ensures similar content is handled uniformly (no conflicting judgments on essentially the same document). Themes (Topic Analytics) Uses analytics to cluster documents by themes/topics. For example, it might reveal a group of emails all discussing “Project X” or detect an unusual theme (like frequent mentions of “resignation”). Uncovers hidden patterns that simple keyword searches in E3 might miss. This insight helps investigators spot important threads of discussion or issues they weren’t explicitly searching for, leading to a more thorough understanding of the data set. It adds a layer of proactive insight absent in E3. Global Deduplication Automatically de-duplicates exact copies of emails or files across all custodians using review sets. Each unique item is retained once for review, with duplicates noted. Prevents redundant review work. In E3, the same email stored in five mailboxes would appear five times and could be reviewed and tagged inconsistently by different people. E5’s deduplication means reviewers spend time only on unique content improving efficiency and ensuring consistency in treatment of identical items. Export & Integration Feature Description Advantage over E3 Guest Reviewer Access Allows secure, read-only external access to a review set for outside experts (like outside counsel). Guest reviewers can be invited to review and tag documents in your E5 case via secure Azure AD access (with MFA), without data leaving the tenant. Enables collaboration with outside counsel without exporting data. E3 cannot extend access to external users. You’d have to export files and send them out, which is slower and riskier. E5 keeps the data in-place and governed, letting external reviewers work more efficiently while your organization retains control and visibility. Import External Data Supports ingestion of data from outside M365 into eDiscovery. You can load files like PST emails, PDFs, or documents from file shares into an E5 review set, maintaining custodians’ identity and metadata. Brings all relevant data under one roof. E3 cannot handle content beyond Exchange/SharePoint/Teams, so any non-M365 data would be reviewed separately. E5’s ingestion means even file server or third-party data can be included in the case, making your eDiscovery truly comprehensive and eliminating blind spots between different systems. Rich Export with Metadata Exports include a detailed load file with extensive metadata from the review (custodian info, email thread indices, attachment names, message IDs, tags applied, etc.). This is in addition to the actual content files. Simplifies downstream processing and preserves review decisions. E3’s export is basic (limited metadata), often requiring additional data processing in third-party tools. E5’s comprehensive load file means that all important context (including tags like “Privileged” that your team applied) travels with the exported data, so external reviewers immediately see those cues. This saves time and prevents rework. MIP Search and Decryption Integration Can automatically decrypt protected content (encrypted by Microsoft Information Protection, e.g. with sensitivity labels/Azure RMS) during eDiscovery. Encrypted emails and documents are made readable and searchable when added to a review set. Ensures encrypted files aren’t “invisible” in your investigation. E3 often cannot search or preview MIP-protected emails/docs until they’re manually decrypted after export (if at all). E5 seamlessly includes these encrypted items in search results and review, so you don’t miss evidence that was simply locked behind encryption. Insider Risk Management Escalation Integrates with Microsoft Insider Risk Management (IRM) alerts. With E5, if an insider risk policy flags a user (e.g., for a potential data theft), you can one-click escalate to create an eDiscovery case that automatically targets that user’s content around the incident. Enables a fast, seamless response to insider threats. E3 has no IRM at all, so there’s no such trigger. In E5, the moment a high-risk activity is detected, the legal team can immediately jump into collecting and reviewing the related data. This tight integration means quicker investigations and potentially mitigating issues before they escalate. Communication Compliance Escalation Ties into Communication Compliance (E5’s internal communications monitoring for policy violations). If a serious policy violation is found (e.g., harassment in Teams chats or inappropriate sharing of sensitive info), it can be escalated directly into an eDiscovery case for further investigation. Offers proactive discovery of misconduct. E3 lacks built-in communication monitoring, so issues may go unnoticed until too late. With E5, compliance officers can swiftly pivot from detecting a problem to launching a full eDiscovery inquiry, ensuring faster and more thorough handling of incidents like HR violations or data leaks. Graph API & Automation Fully supports the Microsoft Graph API for eDiscovery. This means eDiscovery tasks (case creation, adding custodians, running searches, exporting data) can be automated or integrated into other applications via scripting/programming without additional cost. While API support is supported for E3, the E3 export API is a metered solution. E5 allows organizations to streamline eDiscovery workflows – for example, auto-create a case and hold when HR flags an employee exit, or integrate with third-party legal management tools without additional cost. Teams and Copilot Interactions Purge Provides an incident response capability to search and purge Teams chats or Microsoft 365 Copilot interactions if sensitive information was shared. Authorized investigators can directly delete up to 100 Teams chat messages (across participant mailboxes) in one go via the eDiscovery interface (leveraging Graph API) when necessary to contain a data leak. Allows quick containment of spills that E3 cannot do. E3’s content search can purge emails but cannot delete Teams messages or Copilot content. With E5, if confidential data pops up in a Teams chat, compliance can not only find it but also bulk-delete those messages from user mailboxes to mitigate further exposure. This capability is crucial for responding to internal data mishandling in real time.Collecting Microsoft 365 Copilot Data with Microsoft Purview eDiscovery
Copilot Data Collection Reference Table Data Type Storage Location Item Class Collection Strategy Copilot Prompts (user questions sent to M365 Copilot) Exchange Online: Hidden folder in the user's mailbox. Compliance copies stored similar to Teams chats, but with unique item classes. IPM.SkypeTeams.Message.Copilot.<AppName> (e.g., .Word, .Excel, .Outlook, .BizChat). Additional AI-related classes may also apply: IPM.SkypeTeams.Message.ConnectedAIApp*, IPM.SkypeTeams.Message.CloudAIApp*, IPM.SkypeTeams.Message.TeamCopilot*, IPM.SkypeTeams.TeamCopilot* 1. Add the user's Exchange mailbox as a data source to the search. 2. In the condition builder you can optionally filter the search to only return Copilot prompts by adding a condition of "Item class contains any of Copilot activity". This automatically applies all relevant M365 Copilot item classes as a condition of the search. 3. Add any further additional conditions such as date range or keywords to narrow results as required. You can also use the Item Class condition to exclude M365 Copilot interactions from your collections when targeting a user’s mailbox. Notes: · Additional item classes may be added. The item class condition will be updated accordingly. Copilot Responses (AI-generated answers) Exchange Online: The same hidden folder in the user's mailbox as prompts. The same IPM.SkypeTeams.Message.Copilot.<AppName> pattern as prompts The same collection strategy used for prompts. Copilot Memories (personalized saved information Copilot "remembers") Exchange Online: Hidden CopilotMemory subfolder within the user's mailbox contacts. Stored as contact entries separate from prompts and responses. IPM.Contact Each memory item appears as a contact card within Exchange, which is distinct from the message-based item classes used for prompts/responses. 1. Add the user's Exchange mailbox as a data source to the search. 2. In the condition builder you can optionally filter the search to only return Contacts by adding a condition of "Item class contains any of Contacts". Notes: · Copilot memories will not be preserved under a legal hold or retention policy. · This will return both Copilot memories stored in contacts as well as traditional contacts from the user’s Exchange mailbox. Copilot Pages (AI-generated, user-editable documents) SharePoint Online: Stored in a user-owned SharePoint embedded container (shared with Loop workspace content and Copilot Notebooks). File format is .page. Not stored in the user's mailbox. N/A These are SharePoint files (not Exchange items), so no item class applies. Identify them in search results by the .page file extension. 1. Add the custodian’s SharePoint embedded site URL as a data source to the search. Alternatively, tenant-wide searches of all SPO sites will include all SharePoint Embedded containers 2. Optionally use the condition builder with conditions such as date range, keywords or file type to further filter results returned Facilitator agent interactions in a Team meeting chat Exchange Online: Hidden folder in all meeting attendees’ mailboxes. Compliance copies stored as Teams chats IPM.SkypeTeams.Message 1. Add the user's Exchange mailbox as a data source to the search. 2. In the condition builder you can optionally filter the search to only return Copilot prompts by adding a condition of "Item class contains any of Instant messages". 3. Add any further additional conditions such as date range or keywords to narrow results as required. Facilitator agent meeting notes (loop) SharePoint Online: Facilitator meeting notes are stored as a .loop file in a OneDrive folder titled Meetings of the user who initiated Facilitator in Teams N/A These are SharePoint files (not Exchange items), so no item class applies. Identify them in search results by the .loop file extension. 1. Add the user's OneDrive URL as a data source to the search. 2. In the condition builder you can optionally filter the search to only return loop files by adding a condition of "File type equals any of loop". 3. Add any further additional conditions such as date range or keywords to narrow results as required. Notes: · With eDiscovery premium enabled cases you can follow the standard workflow for collecting Team meeting messages and select to include cloud attachments in your collection. This will automatically pull into the export or review set any Facilitator agent meeting notes. Facilitator created word/loop documents SharePoint Online: When the facilitator agent is asked to create a word or loop document during a meeting they are stored in the requesters OneDrive in a folder called N/A These are SharePoint files (not Exchange items), so no item class applies. Identify them in search results by the .loop file extension. 1. Add the user's OneDrive URL as a data source to the search. 2. In the condition builder you can optionally filter the search to only return loop and doc files by adding a condition of "File type equals any of loop, docx". 3. Add any further additional conditions such as date range or keywords to narrow results as required. Notes: · With eDiscovery premium enabled cases you can follow the standard workflow for collecting Team meeting messages and select to include cloud attachments in your collection. This will automatically pull into the export or review set any Facilitator generated loop or word documents. Facilitator generated and assigned tasks Exchange Online: When the facilitator agent creates and assigns a task to an individual, it is created as a to-do item in the assigned individual's Exchange Mailbox IPM.Task 1. Add the user's Exchange mailbox as a data source to the search. 2. In the condition builder you can optionally filter the search to only return Tasks by adding a condition of "Item class contains any of Tasks". 3. Add any further additional conditions such as date range or keywords to narrow results as required. Application-Specific Item Classes for Prompts & Responses For more granular filtering by Copilot application, the following item class values can be used in KQL queries: Application Context Item Class Value Microsoft Copilot Chat (BizChat / Teams) IPM.SkypeTeams.Message.Copilot.BizChat Copilot in Excel IPM.SkypeTeams.Message.Copilot.Excel Copilot in Loop IPM.SkypeTeams.Message.Copilot.Loop Copilot in Outlook IPM.SkypeTeams.Message.Copilot.Outlook Copilot in PowerPoint IPM.SkypeTeams.Message.Copilot.PowerPoint Copilot in Teams IPM.SkypeTeams.Message.Copilot.Teams Copilot in Whiteboard IPM.SkypeTeams.Message.Copilot.Whiteboard Copilot in Word IPM.SkypeTeams.Message.Copilot.Word To target all Copilot applications at once, use the wildcard query ItemClass:IPM.SkypeTeams.Message.Copilot.*. For a wider list of AI data sources, see the following link: https://learn.microsoft.com/en-us/purview/edisc-search-copilot-data#data-sources-for-ai-data Important Notes for eDiscovery Practitioners Excluding Copilot Data from Broader Searches Because Copilot prompts and responses reside in the same Exchange mailbox as emails and Teams chats, they will appear in broad mailbox searches unless explicitly filtered out. To exclude Copilot items, use the condition "Item Class Contains none of Copilot activity" in the condition builder, or add (-ItemClass:IPM.SkypeTeams.Message.Copilot.*) in KQL. Some eDiscovery managers run separate searches, one for Copilot data and one for other communications, to keep collections distinct. Copilot Memories: Retention & Hold Limitations Purview retention policies and eDiscovery holds do not currently apply to Copilot memory items. Memory items remain until a user deletes them or an admin explicitly removes them via eDiscovery or Graph API. Additionally, deleting a Copilot prompt and response does not delete any memory derived from that conversation. Memories must be removed separately if required. Copilot Pages: Do Not Treat Like Prompts/Responses Copilot Pages are not stored in Exchange mailboxes. Searching only a custodian’s mailbox will not return Copilot Pages. Treat Copilot Pages the same way as you do for SharePoint content in your existing eDiscovery workflow. For collections, keyword searches will generate hits on text content within the .page file if either the SharePoint Embedded URL is included in the search or the search is a tenant-wide search of all SharePoint sites Be aware that full-text search within .page files in Purview eDiscovery review sets is not currently available. Instead you can use filters such as Subject/Title or Native File Type to locate Copilot Pages in your review set and review the content. When an eDiscovery hold is placed on a custodian’s mailbox, it does not automatically extend to the SharePoint Embedded site where the Copilot Pages are stored. Instead, ensure the hold policy includes the URL for the user-owned SharePoint Embedded site that contains the Copilot Page(s) that must be preserved. Audit Logs vs. eDiscovery for Copilot Content Audit logs record that a Copilot interaction occurred (time, user, workload context) but do not include the actual prompt or response text. To retrieve the substance of Copilot interactions, use Purview eDiscovery searches against the mailbox. Copilot Prompts and Responses: HTML Transcription Copilot prompts and responses are stored as individual messages within the user’s mailbox. When collecting Copilot interactions, enabling the “Organize conversations into HTML transcripts” premium option will convert these individual messages into HTML transcripts making for easier review and linkage between the user’s original prompt and the Copilot responses. Copilot Prompts and Responses: Contextual prompts and responses When using the Keywords condition as part of your collection in eDiscovery, it will only return items that match the keywords included in the query. This means that you may only return a part of the Copilot interaction. If using keywords in your collection query you can enable the “Include full conversation for Copilot, Teams and Viva Engage messages” premium option. This will include in the export or review set any prompts or responses from the Copilot interaction within a 12-hour window before and after each responsive item. This means that you are able to see the full context of the prompt or response that was responsive to search. Collecting Referenced Documents (Cloud Attachments) Copilot responses may reference or summarize SharePoint/OneDrive files. When collecting Copilot interactions, enabling the "Access links (cloud attachments) in messages" premium option will additionally collect the files referenced in the prompt or response and include them in the export package. This provides full evidentiary context but can significantly increase export size and processing time so consider if collecting these artifacts are relevant to the investigation. If so, look to use additional conditions such as date to effectively manage volumes or reduce the number of custodians in the collection. Facilitator agent in Microsoft Teams Meetings The Facilitator agent in Microsoft Teams is an AI-powered assistant (included with Microsoft 365 Copilot) that enhances meeting productivity by generating real-time notes, summarizing key decisions, and managing action items. It acts as an active participant, allowing for collaborative editing of notes and answering chat questions during calls. As the Facilitator works within the context of Microsoft Teams meetings (scheduled private meetings only) your existing workflows for collecting Microsoft Teams meetings chat should be used. In addition, enabling the "Access links (cloud attachments) in messages" premium setting will automatically collect any meeting note (loop) or loop or word documents created by the Facilitator agent. Copilot Retention Reference Table Data Type Microsoft Purview Retention Policy Location/Scope Copilot prompts and responses Microsoft Copilot experiences Copilot Memories (personalized saved information Copilot "remembers") Not supported Copilot Pages (AI-generated, user-editable documents) SharePoint classic and communications sites (Static Scopes only) Facilitator interactions in a Team meeting Teams chats Facilitator meeting notes (loop) OneDrive Accounts Facilitator created word/loop documents OneDrive Accounts Facilitator generated and assigned tasks Exchange mailboxes (Tasks with end dates only)
Feature Request: Extend Security Copilot inclusion (M365 E5) to M365 A5 Education tenants
Background At Ignite 2025, Microsoft announced that Security Copilot is included for all Microsoft 365 E5 customers, with a phased rollout starting November 18, 2025. This is a significant step forward for security operations. The gap Microsoft 365 A5 for Education is the academic equivalent of E5 — it includes the same core security stack: Microsoft Defender, Entra, Intune, and Purview. However, the Security Copilot inclusion explicitly covers only commercial E5 customers. There is no public roadmap or timeline for extending this benefit to A5 education tenants. Why this matters Education institutions face the same cybersecurity threats as commercial organizations — often with fewer dedicated security resources. The A5 license was positioned as the premium security offering for education. Excluding it from Security Copilot inclusion creates an inequity between commercial and education customers holding functionally equivalent license tiers. Request We would like Microsoft to: Confirm whether Security Copilot inclusion will be extended to M365 A5 Education tenants If yes, provide an indicative timeline If no, clarify the rationale and what alternative paths exist for education customers Are other EDU admins in the same situation? Would appreciate any upvotes or comments to help raise visibility with the product team.Security Baseline for M365 Apps for enterprise v2512
Security baseline for Microsoft 365 Apps for enterprise (v2512, December 2025) Microsoft is pleased to announce the latest Security Baseline for Microsoft 365 Apps for enterprise, version 2512, is now available as part of the Microsoft Security Compliance Toolkit. This release builds on previous baselines and introduces updated, security‑hardened recommendations aligned with modern threat landscapes and the latest Office administrative templates. As with prior releases, this baseline is intended to help enterprise administrators quickly deploy Microsoft recommended security configurations, reduce configuration drift, and ensure consistent protection across user environments. Download the updated baseline today from the Microsoft Security Compliance Toolkit, test the recommended configurations, and implement as appropriate. This release introduces and updates several security focused policies designed to strengthen protections in Microsoft Excel, PowerPoint, and core Microsoft 365 Apps components. These changes reflect evolving attacker techniques, partner feedback, and Microsoft’s secure by design engineering standards. The recommended settings in this security baseline correspond with the administrative templates released in version 5516. Below are the updated settings included in this baseline: Excel: File Block Includes External Link Files Policy Path: User Configuration\Administrative Templates\Microsoft Excel 2016\Excel Options\Security\Trust Center\File Block Settings\File Block includes external link files The baseline will ensure that external links to workbooks blocked by File Block will no longer refresh. Attempts to create or update links to blocked files return an error. This prevents data ingestion from untrusted or potentially malicious sources. Block Insecure Protocols Across Microsoft 365 Apps Policy Path: User Configuration\Administrative Templates\Microsoft Office 2016\Security Settings\Block Insecure Protocols The baseline will block all non‑HTTPS protocols when opening documents, eliminating downgrade paths and unsafe connections. This aligns with Microsoft’s broader effort to enforce TLS‑secure communication across productivity and cloud services. Block OLE Graph Functionality Policy Path: User Configuration\Administrative Templates\Microsoft Office 2016\Security Settings\Block OLE Graph This setting will prevent MSGraph.Application and MSGraph.Chart (classic OLE Graph components) from executing. Microsoft 365 Apps will instead render a static image, mitigating a historically risky automation interface. Block OrgChart Add‑in Policy Path: User Configuration\Administrative Templates\Microsoft Office 2016\Security Settings\Block OrgChart The legacy OrgChart add‑in is disabled, preventing execution and replacing output with an image. This reduces exposure to outdated automation frameworks while maintaining visual fidelity. Restrict FPRPC Fallback in Microsoft 365 Apps Policy Path: User Configuration\Administrative Templates\Microsoft Office 2016\Security Settings\Restrict Apps from FPRPC Fallback The baseline disables the ability for Microsoft 365 Apps to fall back to FrontPage Server Extensions RPC which is an aging protocol not designed for modern security requirements. Avoiding fallback ensures consistent use of modern, authenticated file‑access methods. PowerPoint: OLE Active Content Controls Updated Policy Path: User Configuration\Administrative Templates\Microsoft PowerPoint 2016\PowerPoint Options\Security\OLE Active Content This baseline enforces disabling interactive OLE actions, no OLE content will be activate. The recommended baseline selection ensures secure‑by‑default OLE activation, reducing risk from embedded legacy objects. Deployment options for the baseline IT Admins can apply baseline settings in different ways. Depending on the method(s) chosen, different registry keys will be written, and they will be observed in order of precedence: Office cloud policies will override ADMX/Group Policies which will override end user settings in the Trust Center. Cloud policies may be deployed with the Office cloud policy service for policies in HKCU. Cloud policies apply to a user on any device accessing files in Office apps with their AAD account. In Office cloud policy service, you can create a filter for the Area column to display the current Security Baselines, and within each policy's context pane the recommended baseline setting is set by default. Learn more about Office cloud policy service. ADMX policies may be deployed with Microsoft Intune for both HKCU and HKLM policies. These settings are written to the same place as Group Policy, but managed from the cloud. There are two methods to create and deploy policy configurations: Administrative templates or the settings catalog. Group Policy may be deployed with on premise AD DS to deploy Group Policy Objects (GPO) to users and computers. The downloadable baseline package includes importable GPOs, a script to apply the GPOs to local policy, a script to import the GPOs into Active Directory Group Policy, updated custom administrative template (SecGuide.ADMX/L) file, all the recommended settings in spreadsheet form and a Policy Analyzer rules file. GPOs included in the baseline Most organizations can implement the baseline’s recommended settings without any problems. However, there are a few settings that will cause operational issues for some organizations. We've broken out related groups of such settings into their own GPOs to make it easier for organizations to add or remove these restrictions as a set. The local-policy script (Baseline-LocalInstall.ps1) offers command-line options to control whether these GPOs are installed. "MSFT Microsoft 365 Apps v2512" GPO set includes “Computer” and “User” GPOs that represent the “core” settings that should be trouble free, and each of these potentially challenging GPOs: “DDE Block - User” is a User Configuration GPO that blocks using DDE to search for existing DDE server processes or to start new ones. “Legacy File Block - User” is a User Configuration GPO that prevents Office applications from opening or saving legacy file formats. "Legacy JScript Block - Computer" disables the legacy JScript execution for websites in the Internet Zone and Restricted Sites Zone. “Require Macro Signing - User” is a User Configuration GPO that disables unsigned macros in each of the Office applications. If you have questions or issues, please let us know via the Security Baseline Community or this post. Related: Learn about Microsoft Baseline Security ModeHybrid Join Lifecycle Model
Microsoft Entra hybrid join is still a common reality in enterprise environments. For many organizations, it remains necessary because legacy applications still rely on Active Directory machine authentication, Group Policy is still in use, and on-premises operational dependencies have not fully been retired. At the same time, the long-term direction for endpoint identity is increasingly cloud-native. That creates an important architectural question: Should hybrid join be treated as a permanent device state, or as a lifecycle stage in a broader modernization journey? In practice, hybrid join is often discussed as a binary condition: the device is either hybrid joined or it is not. But from an operational perspective, that view is too limited. In real enterprise environments, hybrid join behaves much more like a lifecycle. A device moves through provisioning, registration, trust establishment, management attachment, steady-state operation, recovery, retirement, and eventually transition. That distinction matters because most hybrid join issues do not fail loudly. They usually appear as stale objects, pending registrations, broken trust, inconsistent management ownership, and environments that remain temporarily hybrid far longer than intended. Why a lifecycle model is useful Treating hybrid join as a lifecycle helps explain why so many organizations struggle with it even when the initial implementation appears technically correct. The challenge is usually not the first successful join. The challenge is everything that happens around it: Provisioning quality Trust validation Management ownership Drift detection Stale object cleanup Exit criteria for transition to Entra join Without that lifecycle view, hybrid join often becomes a static design decision with no clear operational model behind it. The eight phases 1. Provisioning The lifecycle starts when the device is built, imaged, or provisioned. This stage is more important than it looks. If the device is provisioned from a contaminated image, or if cloning and snapshot practices are not handled carefully, later identity issues are often inherited rather than newly created. Provisioning should be treated as an identity-controlled event, not just an OS deployment task. 2. Registration The device becomes known to Microsoft Entra. This is where many environments confuse visibility with readiness. A device object may exist in the cloud, but that does not automatically mean the hybrid identity state is healthy or operationally usable. 3. Trust Establishment This is the point where hybrid join becomes real. A device should not be considered fully onboarded until both sides of trust are present and healthy. In operational terms, this means the device is not only registered, but also capable of supporting the expected sign-in and identity flows. 4. Management Attachment Once trust exists, governance becomes the next question. Many organizations still balance Group Policy, Configuration Manager, Intune, and legacy application dependencies at the same time. That is exactly why hybrid join often persists. But if management ownership is not clearly defined, organizations end up with overlapping policy planes, inconsistent control, and unclear accountability. 5. Operational Steady State Hybrid join does not stop at successful registration. The device must remain healthy over time, and that means monitoring trust health, registration state, token health, line-of-sight to required infrastructure, and management consistency. A device that was healthy once is not necessarily healthy now. 6. Recovery Every real environment eventually encounters drift. Pending states, broken trust, orphaned records, reimaged devices, and inconsistent registration scenarios should not be treated as unusual edge cases. They should be expected and handled with formal recovery playbooks. Recovery is not an exception to the lifecycle. It is part of the lifecycle. 7. Retirement Retirement is one of the weakest areas in many hybrid environments. Devices are replaced or decommissioned, but their identity records often remain behind. That leads to stale objects, inventory noise, and administrative confusion. A proper lifecycle model should include a controlled retirement sequence rather than ad hoc cleanup. 8. Transition This is the most important strategic phase. The key question is no longer whether a device can remain hybrid joined, but whether there is still a justified reason to keep it there. Hybrid join may still be necessary in many environments today, but in many cases it should be treated as transitional architecture rather than the target end state. Practical takeaway Looking at hybrid join as a lifecycle creates a more useful framework for architecture decisions, operational ownership, troubleshooting, directory hygiene, governance, and transition planning toward Microsoft Entra join. That is the real value of this model. It does not replace technical implementation guidance, but it helps organizations think more clearly about why hybrid join exists, how it should be operated, and when it should eventually be retired. Final thought Hybrid join is still relevant in many enterprise environments, but it should not automatically be treated as a default destination. In many cases, it works best when it is managed as a lifecycle-driven operating model with defined phases, controls, and exit criteria. That makes it easier to stabilize operations today, while also creating a clearer path toward a more cloud-native endpoint identity model tomorrow. Full article: https://www.modernendpoint.tech/hybrid-join-lifecycle-model
