Microsoft Security Community Blog articles

Microsoft Leads a New Era of Software Supply Chain Transparency

ShubhraS — Tue, 16 Jun 2026 16:41:20 GMT

Today, Microsoft announces the general availability of Microsoft’s Signing Transparency (MST) – a first-of-its-kind capability that brings unprecedented visibility and trust to our software supply chain. With this release, Microsoft is leading the industry by recording the build of critical cloud services into a publicly readable and verifiable SCITT standard (Supply Chain Integrity, Transparency, and Trust) compliant ledger. This means every production software build for in scope services like Azure Attestation and Azure Managed HSM (Hardware Security Module), Azure confidential ledger, Microsoft Signing Transparency itself (and others over time) – is now logged in an immutable, tamper-evident record. Only builds that are in the MST ledger are deployed to production; this gives customers confidence that the supply chain for these critical services can be audited at anytime.

Notably, the MST ledger is fully open source and built to align with the emerging IETF SCITT standard. By embracing SCITT’s principles and open protocols, Microsoft ensures that MST not only secures our own ecosystem but also contributes to a broader industry movement toward standardized supply chain transparency. The open-source MST ledger serves as a verifiable trust anchor that any organization or researcher can inspect, audit, or even integrate with their own tooling. MST itself meets the highest levels of transparency, backed by a tamper-proof confidential ledger, open-source, and independently verified. Specifically, we are making the foundation of our trust model transparent and accessible to everyone – reinforcing that trust must be earned through proof, not just promises.

This launch marks a major milestone in our commitment to Zero Trust principles, extending “never trust, always verify” all the way into the build itself. Building on a public preview introduced late last year, MST’s general availability delivers verifiable transparency at the software level. It transforms traditional code signing with an additive trust layer that is accessible via an open verification model. Every new software update is accompanied by a publicly auditable proof of integrity, enabling security teams to proactively confirm that each update is authentic and unaltered.

To help organizations get the most out of this capability, we are also introducing a free tool to explore the contents – Ledger Explorer – an offline tool that allows security teams to examine MST ledger entries, verify cryptographic proofs, and even validate the ledger’s integrity independently. This tool, combined with MST’s open design, ensures that every Microsoft customer – and the broader community – can hold us accountable in real time for the software we run on their behalf.

Key Benefits of Microsoft’s Signing Transparency (MST)

Verified Code Integrity – Every software release is cryptographically logged in MST’s ledgers. This makes each build tamper-evident and traceable. If an attacker attempts to inject malicious code or sign an unauthorized update, it will be evident through the well-defined validation step built into the SCITT standard. Organizations gain the assurance that code integrity can be independently confirmed at any time.

Independent Verification & Zero Trust – MST enables customers and auditors to verify software authenticity on their own, without having to solely rely on vendor attestations. For each update, Microsoft provides a transparency “receipt” (proof of logging) that you can use to prove the update was officially published and unaltered. This fosters a “don’t just trust, verify” approach, empowering security teams to double-check everything running in their environment aligns with what Microsoft intended.

Audit-Trail & Compliance – The transparency ledger creates a permanent, auditable timeline of code deployments. Every entry is a record of what was released and when, backed by cryptographic proofs. This simplifies compliance reporting and accelerates forensic analysis. In the event of an incident, you can quickly audit the ledger to see if any unexpected code was introduced. For highly regulated industries, MST offers concrete evidence of software integrity and policy compliance over time.

Leadership & Open Standards – We are delivering real transparency now, encouraging a future where all critical software is released with verifiable integrity. MST’s open source implementation and SCITT-compliant design exemplify our commitment to openness and collaboration. We believe widespread adoption of these standards will strengthen supply chain security for everyone, making trust verification a universal practice.

Next Steps

Microsoft’s Signing Transparency is more than a new security feature and shapes the advances in trust technology. As threats grow more sophisticated, we must evolve the way we assure our customers about the software they depend on. With MST now generally available, we are leading by example: proving that it is possible to open up the traditionally opaque process of software deployment and turn it into a source of strength and trust, i.e., empowering each person with verifiable transparency.

We invite the industry to join us on this journey and get started by reading the documentation and exploring Ledger Explorer today! Together, by embracing transparency and open standards, we can turn “trust but verify” from a slogan into an everyday reality for digital infrastructure.

New Exchange Online Mailbox Auditing Signal: Visibility into IPM to Non-IPM Copy Activity

NehaArora1 — Wed, 10 Jun 2026 15:00:00 GMT

Background: IPM vs. Non-IPM Subtree

Every Exchange Online mailbox is organized into two parts:

IPM subtree (Interpersonal Message subtree) — the visible, user-facing part of a mailbox, designed for messages exchanged between human recipients. This includes Inbox, Sent Items, Deleted Items, Calendar, Contacts, Tasks, Notes, and any custom folders a user creates. Exchange mailbox auditing has always focused on activity within this area.
Non-IPM subtree — a hidden folder structure used by Exchange and Microsoft services for system-level storage, such as the Recoverable Items folder. Users cannot see or directly interact with this area from most mail clients (like Outlook).

For more details, see IPM Subtree | Microsoft Learn.

The Audit Gap This Addresses

A known audit evasion technique involves copying mail items from a user's visible IPM folders into a hidden folder in the non-IPM subtree and then accessing the data from there for exfiltration. This technique has been observed in security investigations against Exchange Online.

This worked as an evasion method because:

Copy operations are not enabled for auditing by default
Activity in the non-IPM subtree was not audited

By staging data in the non-IPM subtree before exfiltration, this activity previously left no trace in the mailbox audit log.

What's New

Exchange Online now logs a MailItemsAccessed event whenever a mail item is copied from the IPM subtree to the non-IPM subtree.

A new AccessType value — CopyFromIPM — has been introduced to distinguish these records from existing MailItemsAccessed events, making them straightforward to query for:

AccessType	Description
Bind	Existing — individual item access
Sync	Existing — bulk sync access
CopyFromIPM	New - an item in the IPM subtree was accessed to copy its content to the non-IPM subtree

How to Query for These Records

Use the following PowerShell command to search for CopyFromIPM activity in your tenant:

Search-UnifiedAuditLog -StartDate 4/1/2026 -EndDate 4/15/2026 -FreeText "CopyFromIPM"

Understanding the CopyFromIPM Audit Record

When a CopyFromIPM event is logged, it is recorded as a MailItemsAccessed operation in the Unified Audit Log. Each record captures an individual mail item that was copied from the IPM subtree to the non-IPM subtree during the operation. When an entire folder is copied, the ItemId that is captured is the Id of the folder; individual records are not captured for each item in the folder.

Feedback

If you have any feedback about this change, you can reach out to ExchangeMailboxAudit-Support group. We are always happy to hear from you and assist in any way we can.

Level up your Azure Network Security Skills with our Upcoming Webinar Series

andrewmathu — Thu, 11 Jun 2026 18:09:16 GMT

As network and application-layer threats continue to evolve, security and infrastructure teams need more than product knowledge. They need practical, scenario-driven guidance they can apply to real workloads. To support that, the Azure Network Security team is hosting a series of upcoming technical webinars covering the capabilities our customers rely on every day: Azure Web Application Firewall (WAF), Azure Firewall, Azure DDoS Protection and Azure Bastion.

Each session is focused on demos, the latest enhancements, and the design and operational decisions you face when securing modern Azure environments. Whether you are protecting customer-facing web applications, hardening east-west and egress traffic, or securing remote administrative access at scale, there is a session in this lineup for you.

These webinars are ideal for Security Architects and Engineers, Network and Infrastructure teams, SOC Analysts, Cloud Platform Owners, Partner Technical Consultants, and any practitioner responsible for the security posture of workloads running on Azure.

Below is the schedule of the upcoming live deliveries.

Upcoming Events

Azure WAF Layer 7 DDoS defense in practice

Date and time: Thursday, June 18, 2026, at 8am PST

View event details and join

As web applications become primary targets for sophisticated application-layer attacks, Azure Web Application Firewall continues to evolve to meet the needs of modern application security teams facing volumetric and targeted application-layer threats. In this webinar, we will explore how Azure WAF enables a layered, adaptive approach to application-layer DDoS mitigation, helping organizations detect and block malicious request patterns through intelligent inspection, control traffic flow to prevent resource exhaustion from abusive sources, progressively challenge suspicious clients to verify legitimacy without disrupting real users, and combine multiple defense mechanisms into a cohesive mitigation strategy that adapts to evolving attack techniques. Whether you're securing customer-facing web apps or business-critical services, this session will equip you with practical approaches to building resilient application-layer defenses on Azure.

Azure Firewall IDPS Detections and Sentinel Integration

Date and time: Thursday, July 9, 2026, at 8am PST

View event details and join

As network threats grow in complexity, organizations need visibility that extends beyond simple traffic filtering into intelligent detection and unified investigation workflows. Azure Firewall's Intrusion Detection and Prevention capabilities continue to evolve to meet the needs of modern security operations teams facing advanced lateral movement, exploitation attempts, and command-and-control activity. In this webinar, we will explore how Azure Firewall identifies malicious network patterns in real time, how detection signals flow seamlessly into Microsoft Sentinel to enrich the broader security narrative, and how security teams can correlate firewall intelligence with other data sources to accelerate threat hunting, streamline incident response, and build a more connected and actionable view of their network security posture.

What's New in Azure Bastion

Date and time: Thursday, July 23, 2026, at 8am PST

View event details and join

Secure remote access to cloud workloads remains a critical requirement as organizations scale their Azure environments and adapt to evolving operational demands. Azure Bastion continues to evolve to meet the needs of modern infrastructure teams seeking seamless, browser-based connectivity without exposing virtual machines to the public internet. In this webinar, we'll explore the latest enhancements to Azure Bastion covering new capabilities that improve connectivity options, streamline the administrative experience, expand protocol and session support, and strengthen the overall security posture of remote access workflows. Whether you're managing a handful of VMs or operating at enterprise scale, this session will bring you up to speed on what's new and how these improvements can simplify and secure your day-to-day operations.

What's New in Azure Firewall

Date and time: Thursday, August 6, 2026, at 8am PST

View event details and join

As network architectures grow more distributed and threat landscapes more dynamic, organizations need a cloud-native firewall that keeps pace with both modern workload patterns and adversary techniques. Azure Firewall continues to evolve to meet the needs of network and security teams managing hybrid environments, multi-region deployments, and increasingly complex east-west and north-south traffic flows. In this webinar, we will explore the latest enhancements to Azure Firewall covering new policy and rule management capabilities, improvements that expand protocol and traffic inspection coverage, and deeper integrations across the Azure security ecosystem to streamline operations. Whether you are standardizing perimeter protection across a global Azure footprint or modernizing segmentation for business-critical workloads, this session will bring you up to speed on what is new and how these improvements can simplify and strengthen your day-to-day network security operations.

What's New in Azure Web Application Firewall

Date and time: Thursday, August 27, 2026, at 8am PST

View event details and join

Web applications remain primary entry points for attackers, and organizations need a Web Application Firewall that adapts as quickly as the threats targeting their workloads. Azure Web Application Firewall continues to evolve to meet the needs of modern application security teams defending against an expanding mix of OWASP-class attacks, automated abuse, and business logic threats across diverse hosting models. In this webinar, we will explore the latest enhancements to Azure WAF. We will cover new detection and rule capabilities that improve protection accuracy, tuning and exclusion improvements that reduce false positives without weakening coverage, and expanded visibility and analytics that accelerate investigation. Whether you are securing customer-facing web apps or managing WAF policies at scale, this session will bring you up to speed on what's new and how these improvements can simplify and strengthen your application protection strategy

Past Recordings:

View additional past webinars from Azure Network Security on Microsoft Security Community YouTube.

Stay connected with the Azure Network Security community

Influence product feedback and join the Threat Protection Advisors Program

Stay up-to-date and follow the Azure Network Security Blog | Microsoft Community Hub

Engage with peers, ask and answer questions in the Azure Network Security discussion board

---

Learn and Engage with the Microsoft Security Community 

Log in and follow this Microsoft Security Community Blog and post/ interact in the Microsoft Security Community discussion spaces.
- Follow = Click the heart in the upper right when you're logged in 🤍

Join the Microsoft Security Community and be notified of upcoming events, product feedback surveys, and more.

Get early access to Microsoft Security products and provide feedback to engineers by joining the Microsoft Security Advisors..

Learn about the Microsoft MVP Program.

Join the Microsoft Security Community LinkedIn and the Microsoft Entra Community LinkedIn

Securing the new risk surface: local agents, claws, and open runtimes

Herain_Oberoi — Tue, 02 Jun 2026 17:15:00 GMT

The next wave of AI is more than just powerful models. We’re now seeing intelligent agents that run locally on our devices, interacting directly with sensitive data, apps, and systems. Some operate persistently: monitoring, planning, and executing tasks over time instead of just responding to one-off prompts. We call these more sustained, autonomous processes “claws.” Together, local agents and claws are changing how work gets done. They also introduce a new risk surface for organizations: these agents often run with deep access and minimal oversight on endpoints, meaning a single misstep or malicious input could lead to misuse of data, unintended system changes, or other real-world impacts.

A new class of risk: when agents run locally

Enterprise security teams already understand the risks introduced by AI agents in cloud services and managed platforms. Local agents introduce a different, and in many ways more acute, risk profile.

When agents run locally on endpoints, they operate inside the user’s trust boundary. They inherit the device context, user credentials, local files, cached tokens, browser sessions, and developer tools already present on that machine. Unlike centrally managed cloud agents, local agents can be created, modified, and executed with little to no centralized oversight, often outside established onboarding and governance workflows.

This creates a distinct risk scenario:

High privilege by proximity – Local agents often run under a user’s full identity and permissions, with direct access to sensitive data and systems the user can reach.
Reduced visibility – Security teams may not know which agents are running locally, how they are configured, or what external services they communicate with.
Immediate impact – A single malicious input, compromised dependency, or unsafe configuration can translate directly into data exposure, destructive system changes, or unauthorized external communication, at endpoint speed.

The risk is not theoretical. As recent incidents have shown, a locally running agent with overly broad permissions can issue destructive commands, leak sensitive data, or propagate errors faster than traditional software controls can react[1]. Existing endpoint and application security models were not designed for autonomous systems making decisions continuously on user devices.

To reduce this risk, security must extend beyond application boundaries and into the agent operating environment. Organizations need visibility into local agents, control over where and how they run, and enforcement of policy as agents act, before unsafe behavior can cause harm.

A secure agent operating environment

Microsoft’s approach to agent security is already well established: secure agents as systems, not individual tools, with consistent visibility, control, and enforcement across identity, data, network, and runtime. Today’s announcements build on that foundation by extending the same agent security model to local agents running on endpoints.

Local agents introduce a different operating reality. They run on user devices, inherit local context, and act with direct proximity to sensitive data, credentials, and tools. Securing them requires bringing endpoint‑level agents into the same control framework CISOs already rely on, without fragmenting governance or creating new blind spots.

To do this, Microsoft extends the Agent 365 control plane to local agents, delivering outcomes security leaders expect:

Observe: Gain a unified view of known local agents across the enterprise to identify what is running, where, and with what access, reducing blind spots before risk materializes.
Secure: Contain agent activity and help enforce controls in real time to block unsafe behavior, prevent unauthorized access, and stop sensitive data loss before impact.
Govern: Apply consistent policy and audit across the agent lifecycle to help ensure accountability, enforce standards, and maintain control as agent behavior evolves over time.

By extending Microsoft Agent 365 to the endpoint, local agents and claws can now operate under the same standards of oversight as cloud‑based agents. This reduces risk while enabling organizations to confidently adopt local, autonomous agents as part of their enterprise AI strategy.

Observe: discover and understand local agents

The first step in reducing risk is always visibility. Local agents often emerge and operate outside traditional IT oversight, what we call “shadow AI”. If security teams can’t see these agents, they can’t manage or protect them. Therefore, true observability into local agent presence and behavior is critical: organizations need an updated inventory of known local agents, where they’re running, and what they can access. With that knowledge, CISOs and their teams can assess exposure and take informed action.

Today, Microsoft is introducing agent observability for 20+ local AI agents running on managed Windows and MacOS devices as first-class security assets. Together, these signals roll up into a unified agent inventory that is surfaced through the security and admin experiences teams already use, so IT, security, and identity teams can see and assess potential local agent risk in the context of their existing workflows.

Agent 365 Agent Registry (including Shadow AI) provides a system of record for local agents that have been brought under governance, while also surfacing unmanaged or unsanctioned local agents detected on managed endpoints. Together, these capabilities give security teams visibility into both known local agents and previously unknown agent activity, using existing endpoint security signals. Teams can assess risk, decide whether to block execution, or bring local agents under governance as part of an end-to-end control workflow. Public preview coming later in June. Learn more.

Shadow AI detection in the Microsoft 365 admin center, showing unmanaged agents and their publishers across the tenant.

Microsoft Defender now discovers and profiles supported local AI agents on eligible Microsoft Defender onboarded devices. It surfaces each agent’s configuration, such as any associated Model Context Protocol (MCP) servers, and maps it to the device and user identity under which it runs. This approach gives security teams a clear picture of potential exposure for supported agents: what it can reach and what it is entitled to access, making it easier to identify potentially risky combinations, such as auto-approval of agents running with elevated permissions on devices that contain sensitive data, and investigate using the same endpoint telemetry security teams already use in Defender. Now in public preview. Learn more.
Microsoft Purview extends observability into the data layer by showing how agents interact with sensitive information across the environment. It helps identify potential exposure paths where data could be overshared, leaked, or used in ways that increase risk. This insight gives organizations the context they need to help reduce data security and compliance risk as part of broader agent governance. Now in public preview. Learn more.
Microsoft Entra extends its Secure Access Service Edge (SASE) architecture to local agents, bringing identity‑aware, network‑level visibility to agents running on Windows and MacOS devices. By correlating network signals with Defender endpoint telemetry, security teams can see which local agents communicate externally, how they are configured, and which resources they are permitted to reach versus what they actually access. This elevates local agent network behavior into first‑class security insight, helping teams identify previously unknown or unmanaged agents and assess risk quickly. These insights surface through the Agent 365 experience, enabling faster, more confident decisions about local agent exposure. Now in public preview. Learn more

Together, these capabilities help organizations with a unified, updated view of known local agent activity and potential risks, helping to minimize blind spots at the endpoint. But visibility alone does not reduce risk. To do that, organizations must also control how local agents behave—both where they run and what they do in real time.

Secure: contain and enforce local agent actions

As the earlier example illustrates, the risk is not just that local agents exist, but that they act autonomously. A single decision can translate directly into real‑world impact, accessing data, executing code, or modifying systems at machine speed.

Reducing this risk requires two layers of protection. First, organizations must control where agents run and what they can access by design. Second, they must enforce controls as agents act, helping to stop unsafe behavior in real time. Microsoft delivers both through OS‑level containment and runtime enforcement.

Execution environment: control agent behavior by design

Containment helps organizations bound what agents can access and do, preventing dynamic behavior from turning into unintended impact. Today, we’re announcing execution‑environment controls that define where local agents run and what they can access, limiting exposure by design.

Windows 365 for Agents provides Cloud PCs that enable AI agents to execute multi-step workflows across software, including opening apps, navigating interfaces, entering inputs, and processing data. Today, we are making Windows 365 for Agents generally available within Agent 365, enabling Agent builders to build computer-using agents for a variety of enterprise use cases. Now generally available within Agent 365. Learn more.
Microsoft Execution Containers (MXC) helps to contain agent impact without limiting productivity gains. MXC is a cross-platform, policy-driven execution layer for agents across Windows and WSL. Developers declare what an agent can access — like files and networking related policies — and MXC enforces those boundaries at runtime. Windows delivers a composable sandbox through MXC—a single SDK and policy model that maps to the right isolation construct for any agent workload, from fast process isolation (adopted by GitHub Copilot CLI) to micro-VMs, Linux containers, and cloud instances via Windows 365. Session isolation separates the agent's execution from the user's desktop, clipboard, UI, and input devices, and critically, binds the agent to a strong user identity — mitigating UI spoofing, input injection, and cross-session data leakage. Agent 365 layers Entra and Intune policy on top so IT can govern containment centrally while developers choose the guardrail weight their workload demands. Now available in early preview. Learn more.
OS-enforced Agent Identity and enterprise manageability on Windows: beyond containment, every agent activity must be attributable and governed. Windows assigns agents a local ID or a cloud provisioned identity backed by Entra and attributes all activity from the container to that identity, so you can clearly differentiate human from agent. Native Windows integration with Agent 365 provides a common foundation for observability, security and governance, including native Intune integration to set policies that gate the agent runtime execution and control how agents run. Defender, Entra, Intune and Purview will provide runtime protections for evolving threats across access, sensitive data, malicious prompts, and risky behavior so security and IT teams can prevent enterprise risk. Learn more.

Runtime: enforce controls as agents act

If the execution environment defines where agents are allowed to operate, runtime enforcement governs what they are allowed to do. This is the moment an agent accesses sensitive data, invokes tools, or takes action under a user’s identity, and where real‑time controls matter most.

Today, we are announcing runtime controls across identity, data, and threat protection for Claude Code and GitHub Copilot CLI, with OpenClaw and OpenAI Codex support coming in late June.

Microsoft Defender adds runtime protection for supported local AI agents on Windows, helping to detect unsafe or malicious behavior inline across prompts, tool calls, and responses. Based on policy, Defender can help block or audit agent actions and raise alerts with agent context, enabling investigation using the same telemetry and hunting workflows security teams already use. Now in public preview. Learn more.

Microsoft Defender enforcement of policies during a local agent interaction with a potential threat

Microsoft Purview extends enforcement of Data Loss Prevention policies to local agent interactions, preventing sensitive data leakage and exfiltration as agents execute tasks, call tools, or generate outputs. These controls help reduce AI-driven data risks while maintaining productivity and providing visibility into recurring risky behaviors across agent sessions. Now in public preview. Learn more.

Microsoft Purview enforcement of Data Loss Prevention policies during a local agent interaction with sensitive data

Microsoft Entra extends the Secure Access Service Edge (SASE) model to local agents by enforcing network-based security controls at runtime, as agents act. Security teams can apply agent-specific network policies directly to agent traffic—separate from user traffic—to restrict web access to authorized destinations, control file transfers, and limit connections to trusted services. Enforced inline during execution, these controls help reduce the risk of data exfiltration, unauthorized access, and communication with untrusted systems, while maintaining consistent, policy‑driven control over local agent behavior. Now in public preview. Learn more.

Together with environment-level containment, these controls help to secure not just where agents run, but how they act.

Govern: sustain control with policy and audit

As agents become persistent systems operating over time, risk extends beyond individual actions to sustained and evolving behavior. Without governance, organizations lose visibility into how agents evolve, what they access, and whether their actions remain aligned with policy. Sustaining trust in local agents requires continuous oversight, accountability, and lifecycle control.

Today, we’re announcing governance controls that keep local agent activity accountable over time through policy and audit.

Microsoft Intune helps control how agents run on managed devices by applying endpoint policies that reduce device-level risk. It enables teams to help block OpenClaw on Windows and apply security policies for runtime protection, now in public preview. With MXC as well as Windows 365 for Agents, administrators can use Intune to configure the environments for managed agents running locally and on Cloud PCs. This helps organizations apply controls across deployment models, prevent unauthorized agent activity, and maintain real-time governance over execution.

In the Microsoft Intune admin center, an IT professional can apply policies to configure agents like OpenClaw to run in MXC and manage what they can access.

Microsoft Purview provides a comprehensive audit record of agent activity over time, capturing how local agents access, use, and interact with sensitive data. These audit logs support investigation, compliance reporting, and accountability, helping to ensure agent actions are traceable and defensible long after execution. Now in public preview for supported agents. Learn more.

Together, these governance capabilities help to ensure that local agent activity is not only controlled in the moment, but managed consistently over time, with visibility and accountability for every action. This enables organizations to move beyond limited AI pilots to trusted, auditable, enterprise‑scale adoption of agentic AI.

From unmanaged claws to secure and governed agents

The result of extending visibility, runtime enforcement, and governance across the agent operating environment is a shift from unmanaged local agents and claws to a secure, enterprise‑ready system. Each layer of Microsoft’s security stack plays a clear role:

Agent 365 provides the unified control plane now for local agents that includes:

Microsoft Defender to detect and block unsafe actions
Microsoft Purview to provide data protection and compliance
Microsoft Entra to enforce network access controls
Microsoft Intune governs execution through device policy

And Microsoft Windows enforces execution boundaries at the platform layer

Together, these layers form a defense‑in‑depth model that helps to close gaps across the local agent lifecycle.

Enabling agentic AI with confidence

Local agents and claws introduce a new class of enterprise risk, as autonomous systems operate continuously across identities, data, and systems. They break assumptions that traditional security models rely on.

Microsoft addresses this shift by securing the agent operating environment itself—helping organizations identify known agents through unified observability, help secure agent actions via real-time enforcement of policies, and govern agent interactions over time through consistent policy and audit.

AI adoption is accelerating faster than the governance structures organizations have in place to manage it. Extending proven security principles to local agents and claws is how that gap gets closed.

Learn more: aka.ms/securityforAI

[1] Claude AI agent wipes firm’s database in 9 seconds | Cybernews

Microsoft Purview enables developers with strong data security across AI apps and agents

Nathalia_Borges — Tue, 02 Jun 2026 17:14:32 GMT

Today, developers are at the center of a new wave of innovation—building AI applications and agents that are deeply connected to enterprise data. But with this opportunity comes a new and complex set of security challenges. AI systems operate across cloud platforms, third-party services, and even local and on-premises development environments, interacting dynamically with sensitive data such as customer records, financial information, and intellectual property. Traditional security approaches weren’t designed for this level of scale, autonomy, or fluid data movement—leaving developers to navigate fragmented tools, unclear policies, and the risk of unintentionally exposing sensitive information.

At the same time, expectations are rising. Organizations need to ensure that AI applications and agents are compliant, auditable, and secure by default on an enterprise-level—not retrofitted after deployment. But for developers, adding security often means additional complexity, custom integrations, and slower time to market. This tension between speed and control has become one of the biggest barriers to moving AI from experimentation into production.

Microsoft Purview is designed to help with this challenge by embedding data security and compliance controls across the development cycle. Purview provides a consistent way to govern how data is accessed, used, and shared—without requiring developers to become security experts. The result is a simpler path to building AI systems that are secure, compliant, and enterprise-ready by design.

Extending data security and compliance to local agents and claws

Local and endpoint agents, built in platforms such as GitHub Copilot CLI and OpenClaw, introduce a new class of data security challenges as they operate outside traditional control planes and directly on user machines. Unlike cloud systems, these agents can access local files, credentials, terminals, and enterprise apps simultaneously—often moving data across tools and environments. This expands data risks, from sensitive data being unintentionally stored, copied, or shared, to API keys and tokens being exposed, and autonomous workflows triggering data movement without explicit user intent. At the same time, many existing security controls were designed for browser or cloud-based activity, leaving a growing blind spot at the endpoint where agents are increasingly running. The result is a widening gap between how developers build agents to operate locally in the users machines, and how organizations can detect, govern, and protect the data those agents interact with.

Microsoft Security and Windows are integrating management and security capabilities directly into the local agents’ development workflow, enabling security as an architectural guarantee rather than an implementation choice.

At Build, we are thrilled to be extending Purview visibility and protection capabilities to local agents developed on GitHub Copilot CLI, Claude Code, OpenAI Codex, and OpenClaw - in Public Preview. Unlike traditional cloud applications, these agents operate closer to the data and often create new risks for data exposure. Purview addresses this challenge across all types of agent interactions with a clear, simplified set of scenarios:

▪ Observability: Visibility on Purview Data Security Posture Management (DSPM) across agent inventory, as well as into how local agents interact with sensitive data—across prompts, responses, and actions.

▪ Runtime data protection: Purview Data Loss Prevention (DLP) controls enforced directly into the agent execution flow, inspecting prompts and tool calls in real time to prevent sensitive data exfiltration.

▪ Agentic risk detection: Risky or anomalous agent behaviors detected through Insider Risk Management (IRM) signals, helping teams detect unsafe interactions early.

▪ Audit: Comprehensive, end-to-end logging of all local agent interactions—capturing prompts, responses, data access, and actions for data context.

For example, a developer is using a local coding agent to generate code and accidentally includes sensitive credentials in a prompt. AI observability in DSPM surfaces the interaction and shows what data the agent accessed. DLP detects the sensitive data in real time and blocks it from being sent or processed (or sensitive files from being accessed and exfiltrated). At the same time, agentic risk detection flags the session as high risk based on the behavior pattern. All of this activity is captured in audit logs, enabling the security team to investigate and take action quickly.

Data protection policy blocks agent interaction with sensitive data

Developers and security teams gain visibility into agent activity and data interactions, while policies prevent sensitive data leakage. This ensures consistent security outcomes across both cloud and endpoint environments, without disrupting developer workflows.

Strengthening visibility and controls for Foundry agents

Foundry gives developers a central place to build and manage AI agents, but it also creates a need for data security context directly in that workflow—especially as prompts, model interactions, and downstream actions increasingly involve sensitive enterprise data.

At Build, we are excited to announce the expansion of the Foundry integration with Purview. This includes Purview DLP runtime controls for prompt processing in Foundry, in Public Preview. As agents and applications built on Foundry increasingly interact with sensitive data, Purview ensures those interactions are governed by trusted controls, identifying Sensitive Information Types (SITs) in real time to detect and protect confidential data embedded in prompts. For example, if a user includes customer PII or financial data in a prompt, Purview can automatically identify the sensitive content and block that prompt from being processed by the model. This ensures that all Foundry apps and agents, regardless of how they’re built or deployed, inherit consistent data protection – allowing organizations to reduce risk of inadvertent data exposure, centralize compliance enforcement across AI workloads, and confidently scale AI adoption knowing sensitive data is protected by design.

We’re also building up on the Purview coverage for Foundry shared at the last Microsoft Ignite by announcing Purview insights embedded directly into the Foundry Control Plane, in General Availability, bringing rich data security context to the plane where developers already work. Purview surfaces crucial signals—such as SITs detected in the agentic interactions, % of agentic interactions involving sensitive data, and spread of high-risk users — so Foundry admins can know how AI apps and agents are built in their environment. This shift enables developers to make faster, better decisions in the moment, reducing rework and closing security gaps early on.

Purview Audit embedded in the Foundry Control Plane

For customers, the value is clear: stronger security by design and at enterprise scale, accelerated development cycles, and reduced risk of data leaks or compliance issues—without slowing down innovation.

Innovating for developers everywhere, at the pace of AI growth

Microsoft is also expanding Purview’s reach across the broader developer ecosystem. New integrations help organizations apply consistent oversight to AI tools and platforms developers already use, without adding separate compliance workflows.

GitHub Copilot is a critical productivity layer for developers, accelerating how code is written and shipped—making it equally important that developer interactions with GitHub Copilot are governed and secured with the same rigor as enterprise data. Microsoft Purview now extends data governance and compliance capabilities to GitHub Copilot interactions, in Public Preview, enabling GitHub Enterprise customers with Entra SSO to stream audit logs directly into Purview. This brings centralized visibility for AI activity, allowing security and compliance teams to analyze GitHub Copilot agent session activity alongside other AI workloads. With this native integration into GitHub workflows, Purview audits Copilot activity across repositories, pull requests, and developer sessions—ensuring AI-generated code aligns with enterprise data policies, compliance requirements, and secure development standards.

By integrating Purview into existing workflows, organizations can govern GitHub AI usage without building parallel pipelines—reducing complexity while ensuring consistent compliance coverage across their entire data estate.

Purview capabilities configured directly into the GitHub Copilot experience

Today’s AI agents aren’t built in just one ecosystem—they span custom apps, third-party platforms, and open-source frameworks. Without consistent controls, this creates blind spots where sensitive data can be exposed outside enterprise guardrails. That’s why extending Purview protection beyond Microsoft environments is critical: it ensures developers can apply the same data security, DLP policies, and compliance controls to any agent, anywhere—so innovation can scale without increasing risk.

Developers already use Microsoft Purview APIs to embed data protection into enterprise workflows. Today, we’re introducing the Microsoft Purview SDK for .NET — a simple, drop-in toolkit that brings Purview capabilities directly into any application, in Public Preview. Instead of weeks spent wiring APIs, authentication, and error handling, developers can add content scanning, DLP checks, and sensitivity labeling in just a few lines of code. The SDK handles the heavy lifting — including auth, retries, caching, and telemetry — so teams can focus on building experiences.

For AI apps and agents built outside of the Microsoft AI platforms, SDK adds built-in support and can evaluate prompts and responses in real time against DLP and content policies — helping prevent data exposure at runtime without custom logic.

Designed for both real-time and asynchronous patterns, and for authenticated or anonymous flows, the SDK also feeds activity back into Purview to give security teams centralized visibility and control. The bottom line is- the Microsoft Purview SDK enables developers to build AI apps and agents that are secure and compliant by default — cutting integration time from weeks to days while ensuring data protection scales with AI. The SDK will be available in public preview within the next month.

Together, these announcements represent a significant step forward in how developers build secure AI systems. Microsoft Purview is no longer just a data security and compliance solution—it is a first-class layer of the development process by protecting data across AI applications and agents, and enables a bridge between developers and security teams. As AI becomes more agentic, distributed, and deeply connected to enterprise data, the need for built-in security will only grow. With Purview, developers no longer must choose between speed and security—they can build both into every application from the start

Getting connected with Microsoft Purview and learn more

Learn more about Microsoft Purview on our website and Microsoft Learn.

Explore Agent 365.

Try Microsoft Purview data security.

Learn more about Microsoft Purview SDK.

New Windows Features to Secure Today’s Data in a Post-Quantum World

AabhaThipsay — Tue, 02 Jun 2026 16:30:00 GMT

Quantum safety is a staged transition across customer environments. Windows is enabling this progression by extending quantum-safe support beyond algorithms and APIs, into the protocols and platform components that organizations use the most. This foundation empowers customers to build, validate, pilot, and ultimately deploy quantum-safe applications, systems, and infrastructure at scale.

Microsoft’s earlier announcements introduced PQC support in the core cryptographic building blocks and outlined the broader Quantum Safe Program, including the need for crypto-agility, standards alignment, and a practical migration path. Microsoft delivered a key milestone last November by making PQC algorithms generally available on Windows 11 and Windows Server 2025.

Now, we’re bringing quantum-safe capabilities to where they are used: adding PQ TLS hybrid key exchange to the Windows Transport Layer Security (TLS) stack, enabling composite PQC algorithms in Windows cryptography APIs and certificate functions, and bringing the ability to generate PQ certificates via Active Directory Certificate Services (ADCS). Together, these advances help organizations address long-lived data risks now and begin preparing for the broader transition across authentication, certificates, device protection, and management workflows.

These updates are part of a broader transition: bringing quantum-safe security into the systems and workflows on which organizations already rely.

PQ TLS hybrid key exchange comes to Windows

The Windows TLS stack is a core component for secure communication across the platform. Adding PQ TLS hybrid key exchange brings quantum-safe protection to real data-in-transit scenarios that already run on Windows.

Hybrid key exchange combines classical and post-quantum algorithms, allowing organizations to begin mitigating HNDL risks. This is especially important for data that must remain confidential for years, as adversaries can capture encrypted traffic today and attempt to decrypt it in the future when quantum computing becomes practical.

This reflects Microsoft’s ongoing work in standards development and broader platform investments, including the core cryptographic library SymCrypt, Windows cryptography APIs, and certificate handling. TLS PQ hybrid key exchange is available now in preview through the Windows Insider Program and will become generally available on Windows 11 and Windows Server 2025 in the coming months.

These new quantum safe key exchange options can be configured the same way as existing TLS curves (the classical encryption groups already in use today). IT administrators can enable them using familiar Windows management tools: Group Policy for domain-joined enterprise environments, Mobile Device Management (MDM) for modern device management platforms such as Intune, or TLS PowerShell cmdlets (scripted configuration commands) for manual or automated setup. The following hybrid combinations — each pairing a classical algorithm with the post-quantum NIST ML-KEM algorithm to protect against both current and future threats — are available:

X25519_MLKEM768 — combines the widely-used X25519 classical algorithm with ML-KEM

SecP256r1_MLKEM768 — combines the NIST P-256 elliptic curve with ML-KEM

SecP384r1_MLKEM1024 — combines the NIST P-384 elliptic curve with ML-KEM at a higher security level

In practical terms, bringing this capability to Windows enables security teams and application owners to evaluate real, Windows-native deployments and begin planning the policy and configuration updates needed for quantum-safe readiness. It provides a direct path to start testing in familiar Windows environments, without relying only on specialized preview stacks. Our TLS supported groups page describes the PQ TLS hybrid key exchange groups available and how to enable them in your environment.

Composite PQC algorithms in Windows cryptography APIs

Windows cryptography APIs are adding support for composite ML-KEM and composite ML-DSA, where ML‑KEM (Module-Lattice Key Encapsulation Mechanism) and ML‑DSA (Module-Lattice Digital Signature Algorithm) are NIST approved PQ algorithms for key exchange and digital signatures respectively. Composite approaches are important for transition because they allow cryptographic operations to incorporate both classical and post-quantum components.

Composite algorithms provide defense in depth by requiring an adversary to break all components to compromise protected data. When implemented natively, they abstract away the complexity of securely combining multiple algorithms, reducing the risk of incorrect integrations and strengthening resilience against weaknesses in individual schemes. This work follows the IETF drafts for composite ML-DSA and composite ML-KEM, to combine the traditional digital signature algorithm ECDSA with ML-DSA and traditional key exchange algorithm ECDHE with ML-KEM.

For developers, platform engineers, and security architects, this means Windows-native APIs are moving beyond foundational primitives toward the real-world certificate and signing patterns required in production environments. Composite support enables organizations to prototype new certificate profiles, evaluate trust chain impacts, and prepare for scenarios as relying parties, issuing systems, and policy controls adopt post-quantum capabilities at different speeds.

These capabilities are in Windows Insider Preview for Cryptography API Next Generation and certificate functions and will become generally available on Windows 11 and Windows Server 2025 in the coming months. Visit our crypto developers page to learn more and get started.

PQ Certificates come to ADCS

Active Directory Certificate Services (ADCS) support for issuance of ML‑DSA certificates in Windows Server 2025 is now generally available as of May 2026, bringing PQC support into enterprise public key infrastructure (PKI). ML‑DSA enables quantum‑resistant signing operations across Certification Authorities (CAs) and Online Certificate Status Protocol (OCSP) Responders, providing a practical way to evaluate post‑quantum certificate issuance and trust validation workflows.

ADCS supports three ML‑DSA parameter sets (ML‑DSA‑44, ML‑DSA‑65, ML‑DSA‑87), allowing organizations to balance security strength with key and signature size for scenarios like code signing and TLS certificates. PQC support requires newly deployed CAs (as existing CAs cannot be upgraded in place), so organizations can introduce a parallel CA hierarchy alongside existing infrastructure to test and validate deployments without disrupting production workloads.

Additional post‑quantum capabilities, including ML‑KEM and composite algorithm support, are planned later this year to expand beyond signing scenarios and enable broader certificate interoperability.

What this means for security teams and developers

For many organizations, these announcements provide a clear starting point to adopt quantum-safe cryptography. The Windows platform now enables early validation and integration of PQC capabilities across applications and infrastructure.

The most effective migrations will be phased. Organizations should start by inventorying where public-key cryptography is used, prioritizing systems that protect sensitive data with long confidentiality lifetimes, and testing hybrid and composite approaches in non-production environments.

Security teams can start by identifying where long-lived data is at risk, such as document repositories (e.g., SharePoint), email archives, database systems, and backup or archival storage (including device and cloud backups), and prioritizing the systems that depend on TLS and certificate-based trust. They can then map which applications rely on Windows cryptographic interfaces. Developers can test new algorithm support in controlled environments. IT administrators can prepare for the operational changes required for quantum-safe migration, including across certificates, device policy, performance validation, interoperability testing, and cryptographic inventory management.

The goal is not only to adopt new algorithms, but to build crypto-agility into processes so future transitions are easier to manage. These latest Windows capabilities make it easier for that work to begin in a more practical, standards-aligned way.

Looking ahead: the next wave of quantum-safe capabilities in Windows

These announcements mark early but important steps in bringing quantum-safe capabilities into the Windows scenarios organizations depend on most. Beyond foundational cryptography and PQ hybrid key exchange, that roadmap extends across certificate lifecycle workflows, networking protections such as IPsec and Wi-Fi, authentication scenarios including TLS and Kerberos, passwordless experiences like Windows Hello and passkeys, and platform protections that rely on trusted keys, certificates, and recovery flows.

This future direction includes additional capabilities like composite PQ support in ADCS, which will be central to enterprise certificate enrollment and issuance, as well as BitLocker, software signing, and firmware signing. Customers will see progress in some of these areas this year, with additional advancements planned for 2027.

Across these investments, the goal remains consistent: to help customers move from algorithm availability to deployable, manageable, enterprise-ready, and quantum-safe solutions.

Preparing now for the transition ahead

The transition to quantum safety will take time, testing, and close coordination across standards bodies, platform providers, software developers, and enterprise security teams. But momentum matters.

By expanding Windows support from foundational post-quantum primitives to real protocol and certificate scenarios, Microsoft is helping make that transition more practical. TLS PQ hybrid key exchange in the Windows TLS stack, composite PQC algorithms in Windows cryptography APIs, and PQC capabilities in ADCS represent important next steps in turning quantum-safe readiness into deployable capability.

As the roadmap continues to unfold across certificates, authentication, and platform protection, the best time for organizations to begin preparing is now.

Securing today. Preparing for what’s next.

Security in Windows is built into the platform - continuously maintained and designed to evolve as threats change.

Learn more in the Windows Security book and Windows Server Security book or explore Windows 11, Windows Server, and Copilot+ PCs. 

For broader solutions, visit the  Microsoft Security site, follow the Security blog, or connect with Microsoft Security on LinkedIn and @MSFTSecurity.   

Share Your Use Case in a Lighting Talk

RenWoods — Mon, 01 Jun 2026 19:38:07 GMT

Microsoft Security Store Lightning Talks are high‑energy, community-led mini sessions spotlighting real users like you who are putting Microsoft Security Store agents and solutions to work, driving measurable impact through faster workflows, smarter automation, and stronger security outcomes.

Selected sessions will be recorded and curated into a single can’t‑miss public virtual event, with speakers live in chat to answer questions and help attendees translate ideas into action. After the event, each speaker receives a dedicated Microsoft Security Community YouTube link for their segment, ready to share and keep up the community momentum.

Any user of agents of solutions from the Microsoft Security Store are welcome to submit a session; multiple submissions are welcome: aka.ms/MSScfp | Due June 4^th

See examples of Microsoft Security Community Lightning Talks here
Sessions must be no longer than 10 minutes long and session submissions/descriptions can be 1-3 sentences.
More information on the requirements and timeline can be found within the submission form.
Event date: July 30th.
- Interested in registering for the event? Watch this event space and follow this blog post - yes, the one you're reading! Sign in (upper right corner) then click the heart to follow and be alerted on updates.
Have questions? Feel free to post in the comments below. Need help? Let us know by sending RenWoods a direct message.
Professional speaking experience is not required in this community-focused event. Microsoft employees are not eligible to present.

Submit your Microsoft Security Store Lightning Talk today!

Learn and Engage with the Microsoft Security Community

Log in and follow this Microsoft Security Community Blog and post/ interact in the Microsoft Security Community discussion spaces.
- Follow = Click the heart in the upper right when you're logged in 🤍
Join the Microsoft Security Community and be notified of upcoming events, product feedback surveys, and more.
Get early access to Microsoft Security products and provide feedback to engineers by joining the Microsoft Security Advisors..
Learn about the Microsoft MVP Program.
Join the Microsoft Security Community LinkedIn and the Microsoft Entra Community LinkedIn

Microsoft Security Community Spotlight: Marcel Graewer

RenWoods — Wed, 27 May 2026 19:17:27 GMT

Globally, Marcel shares practical detection engineering insights on Microsoft Sentinel and Microsoft Defender XDR through forums and blog posts. Locally, he represents his employer in the IT-Security group of the Microsoft Business User Forum, where German companies using Microsoft technologies exchange real-world experience and expertise.

The work Marcel values most is helping people enter the IT field. In Germany, "Fachinformatiker" is a recognized IT profession learned through a multi-year apprenticeship, and he is proud to have trained apprentices. He also serves as an examiner for the IHK (the German Chamber of Industry and Commerce), evaluating the final exams of these IT apprentices.

This commitment also led him to support younger learners by teaching school cybersecurity classes and participating in Girls’ Day, where he introduced female students to the field. “I do this because most people don’t get an honest view of security work until much later in their education—if they see it at all. Showing someone early that this field is creative, varied, and genuinely interesting can change their path. Being part of that, even for a few people, means more to me than anything that fits neatly on a CV.”

Let’s hear more from Marcel about his Microsoft Security Community and product paths.

All responses to questions are direct quotes from Marcel.

What do you find most rewarding about being a member of the Microsoft Security Community?

The most rewarding part for me is how practical the exchange is. Microsoft security tooling moves fast - Microsoft Sentinel, Microsoft Defender XDR and Microsoft Security Copilot all change month to month- and no single person keeps up with all of it alone. The community is where that gap gets closed. When I read how someone else tuned a detection in their environment, or when someone responds to something I posted with a problem I hadn't considered, my own work gets better. It's a feedback loop you don't get from documentation. The other part I value is that it works in both directions: I started as a reader, learning from people more experienced than me, and now I'm at a point where I can give some of that back. Watching that shift happen has been genuinely motivating.

How long have you been working with Microsoft Security Products?

Over ten years! My way into Microsoft security ran through infrastructure rather than security itself. I started out administering Active Directory and VMware environments, the on-premises world, and that is where I first understood identity, endpoints and the quiet attack surface they create. At the time, security was something layered on top of infrastructure. What changed everything was the shift to the cloud.

As the environments I worked in moved into Microsoft Azure and Microsoft 365, the old separation between "running things" and "securing things" stopped making sense. In a cloud-first world, the identity is the perimeter, the sign-in log is the crime scene, and the telemetry that used to be scattered across servers suddenly lives in one place you could actually query. That was the moment Microsoft's security stack became less of a product set and more of a working environment for me.

As I moved from running infrastructure into roles centered on defending it, first leading IT infrastructure and security as a team lead, then as an IT Security Expert, and now as IT Security Manager focused on architecture and incident response in an Azure and M365 environment, Sentinel and Defender XDR went from tools I knew of to tools I work in every day. The infrastructure background turned out to be an advantage rather than a detour. Detection engineering makes far more sense once you have run the Active Directory and the endpoints that generate the very signals you are now writing detections against, and cloud security makes far more sense once you have felt the limits of the on-premises model it replaced. The part that keeps me engaged is that none of this stands still. The cloud security landscape changes constantly, the work is never quite finished, and that is exactly what I like about it.

What Microsoft Security features or products have provided the most impact?

The single biggest impact for me comes from Microsoft Sentinel as a cloud-native SIEM and SOAR platform. The move away from a self-hosted SIEM matters more than it first appears. A traditional SIEM is itself a piece of infrastructure that has to be sized, hosted, patched, and scaled, and that effort constantly competes with the actual security work. Microsoft Sentinel removes that layer. There is no platform estate to keep alive and no capacity planning for the SIEM itself, which frees attention for what actually matters: getting the right telemetry in and getting detection and response right.

What I value most is how naturally Sentinel fits into modern, cloud-first environments. When the landscape you are protecting already lives in Azure and Microsoft 365, a security platform that lives in the same place removes an entire class of integration friction. The other strength is the breadth of data onboarding. With a traditional SIEM, connecting a new log source was often a small project of its own, with connectors to build and parsers to maintain. With Sentinel, that friction is largely gone. Whether a source sits on-premises, in another cloud or in a third-party product, getting it in is straightforward, and the platform still provides the integration depth that genuinely matters rather than a shallow connection. Microsoft Sentinel handles almost anything you point it at.

Equally important is that SIEM and SOAR are not two separate platforms here. The orchestration and automation layer is built into the same solution, so response playbooks run on the same data that the detections are built on. For architecture, that is a real advantage: detection and response are designed as one system rather than stitched together afterwards. The central telemetry layer is one of the few decisions that is genuinely hard to reverse later, and Sentinel makes that an easy one to defend.

What advice do you have for others who would like to get involved in the Microsoft Community?

My advice is to start before you feel ready. I read Microsoft Tech Community (forums) for years before I posted anything myself, always with the feeling that I needed more experience first, that I would just be adding noise. That was the wrong instinct. The moment I actually started contributing, the feedback I got back made my own work better, and I realised the bar for being useful is far lower than it looks from the outside. You do not need to be the leading expert on a topic. You need a real problem you have worked through and the willingness to write down how you solved it. Someone else is stuck on exactly that problem right now. Start small, stay consistent, and treat the community as an exchange rather than a stage. Consistency matters more than any single brilliant post.

Alles rund um sein Buch (All About His Book)

Last year, I published "Die neue Realität der Cybersecurity" (2025). It tackles a question every security team is dealing with right now: “Where does AI genuinely strengthen security architecture and incident response, and where is it just noise?” Rather than staying abstract, the book takes the practitioner's side of that question, looking at how AI actually changes the work of designing defensible systems and responding to incidents, and where the limits and risks really are. It is written for the people doing the work, security architects, IR practitioners and the leaders who have to make decisions about AI without the marketing gloss. If that question is on your desk too, it is worth a look.

Connect with Marcel

Microsoft Tech Community: @marcel_graewer
Linkedin: https://www.linkedin.com/in/mgraewer/
Github: https://github.com/bifrost0x
Blogs: graewer.com and magra-sec.de
Book: Die neue Realität der Cybersecurity (ISBN: 9783695708833)

Marcel Graewer is currently an IT-Security Manager at Festool Group and holds the CISSP certification. Outside of work, he is happiest when experimenting with

technology on his own terms. He runs a Proxmox-based homelab with a range of self-hosted services and Docker containers, using it as both a playground and a testing ground. It gives him space to break things, learn, and explore without the constraints of formal change processes. He also spends time on Hack The Box and TryHackMe, believing that staying sharp on the offensive side makes him a stronger defender. Away from the keyboard, his life is refreshingly analog. He and his family, including two children, live in an old house that always seems to have one more project waiting. Between the homelab and the house, there is never a shortage of things to fix, and that suits him just fine.

Learn and Engage with the Microsoft Security Community

Follow = Click the heart in the upper right when you're logged in 🤍.

Join the Microsoft Security Community and be notified of upcoming events, product feedback surveys, and more.
Get early access to Microsoft Security products and provide feedback to engineers by joining the Microsoft Security Advisors.

Join the Microsoft Security Community LinkedIn Group and follow the Microsoft Entra Community on LinkedIn

Securing AI Agents End‑to‑End: Connecting Purview DSPM, Agent 365, and the AI Security Dashboard

SRay — Tue, 19 May 2026 18:08:13 GMT

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.

State Explosion Security Problem in AI-Era Software Supply Chains

nirwandogra — Mon, 18 May 2026 20:41:50 GMT

Introduction

To see why this problem scales so quickly, start with the smallest possible change: a single line of code. In modern software, even a tiny edit is rarely just a local modification. It can change execution flow, introduce a new dependency, expose sensitive data, or quietly shift the purpose of the package itself. What looks trivial in a diff can create a materially different security outcome. That is why supply chain defenders cannot afford to treat small code changes as small security events.

How a Single Line Changes Package Intent

Every software package exists in a particular state at a particular moment in time. Imagine a benign version — State X — that behaves exactly as intended. Now add one line of code. That small edit can shift the package into a new state with different behavior and, potentially, a very different risk profile.

The security issue is not the added line by itself. It is the fact that the package now has to be interpreted differently. A tiny diff can change the role of the entire component, which means defenders have to reason about the resulting behavior, not just the textual change.

That is why file-level scanning breaks down so quickly. A change in one file can alter the behavior of the entire package because software semantics emerge from how components interact. Security systems therefore need to analyze packages as composed systems, not as a series of isolated file edits.

Why the whole package matters

This matters even more in modern supply chain attacks, where malicious intent is rarely concentrated in one obvious file. More often, the behavior is distributed across several files that look harmless when viewed independently.

File A defines an encoded string constant. Looks like a config value.

File B provides a decode function. Looks like a utility.

File C (setup.py / postinstall) imports both, decodes, and executes.

Viewed independently, each file may appear benign. No single file has to trigger a clear signature, rule, or heuristic. The malicious behavior only becomes visible when you reconstruct how the files interact as a system. Any scanner that evaluates files one by one without rebuilding that interaction is likely to miss the real behavior.

Why every change demands re-analysis

Every meaningful state change — a commit, pull request, version bump, or package publish — can alter the semantics of the software. That means defenders cannot stop at diff inspection or lightweight pattern matching. The real question is not only what changed, but what the software now does.

Quantifying the problem

The scale of the problem becomes clearer when you look at how many software state changes occur across the ecosystem every day:

GitHub alone recorded nearly 1 billion commits in 2025, merged an average of 43.2 million pull requests per month, and now hosts roughly 630 million repositories. In 2026, GitHub was projected to reach roughly 38 million commits per day.

npm has grown to well over 2 million packages, making JavaScript one of the largest public package ecosystems.

PyPI published more than 130,000 new projects in 2025 and more than 3.9 million new files in the same year.

NuGet serves package downloads at massive operational scale, with recent weekly totals in the 5 to 6 billion range.

Maven Central indexed more than 20 million packages and published more than 3.2 million packages in 2025.

Taken together, these ecosystems are generating an enormous stream of new software states. Some numbers describe repositories, some describe publishes, and some describe downloads, but they all point to the same reality: the scale of software movement is already massive before you even account for the acceleration from AI-assisted development.

The number of state changes is already enormous, and AI-assisted development is increasing it even further. The result is not just more code, but more package states that may require meaningful security interpretation.

Why the math breaks traditional scanning

Assume a single semantic package analysis takes 30 seconds, which is a reasonable range for LLM-based inference. Scanning 50,000 packages would require roughly 1.5 million seconds of compute time per day — about 417 hours. But the ecosystem only gives defenders 24 hours before the next wave of packages arrives. Without aggressive parallelism and purpose-built infrastructure, backlog becomes inevitable.

The scanning bottleneck

This leaves modern scanning systems with a fundamental bottleneck:

Heuristic and signature-based scanners are fast. They can match known patterns in milliseconds and work well for familiar malware families or repeated behaviors. Some systems also use emulation or detonation, but these approaches still struggle to deliver deep reasoning at ecosystem scale. That makes them easier to bypass with novel, well-structured, or AI-generated code that behaves maliciously without resembling previously known samples.

LLM-based semantic analysis can reason about intent. It can follow behavior across files, recognize obfuscated exfiltration paths, and explain why a package is suspicious even when the code appears ordinary at first glance. The tradeoff is cost, latency, and trust: inference takes seconds rather than milliseconds, and a single package may require multiple reasoning passes. At ecosystem scale, that becomes a serious infrastructure challenge.

Neither approach is sufficient on its own. Heuristics provide speed without deep understanding, while semantic models provide understanding without inherent scale. Closing the gap requires systems that combine both: package-level reasoning with the latency and throughput needed for production supply chains.

Heuristics often miss novel attacks, while LLM-based approaches remain too slow to apply inline at large scale. That gap between understanding and throughput is where supply chain malware can persist.

What needs to change

Closing that gap will require a different class of supply chain security systems. Detonation can help in some cases, but it is too slow and expensive to apply inline to every package state change. What is needed is a system that can:

Analyze entire packages as a unit — not individual files. The intent lives in the interaction between files, not within any single one.

Run semantic analysis at data-plane speed — every package, every version, on the hot path, with latency low enough for inline enforcement. Not async advisories. Not CI-time checks. Inline, before delivery.

Handle the state explosion — millions of state changes per day, each requiring full re-analysis. This is an infrastructure problem as much as a security problem: rate limiting, backpressure, connection pooling, regional failover, model versioning — the same hard distributed systems problems, with security stakes.

Maintain high accuracy under evasion — attackers deliberately use encoding, string splitting, dynamic imports, polyglot files, and similar techniques to reduce detection quality. The scanner must continue to classify packages accurately even when the code is designed to obscure intent.

The Latency-Accuracy Tradeoff: Malware Detection as an ML Problem

At cloud scale, malware detection is governed by a hard tradeoff between latency, accuracy, throughput, and cost. The fastest detectors are typically shallow: signatures, heuristics, and lightweight models can make decisions in milliseconds, but they often miss novel, compositional, or intent-level attacks. Deeper semantic analysis can improve recall and resilience against evasion, but it also increases inference time, compute cost, and operational complexity. As a result, defenders cannot optimize for accuracy in isolation; they must deliver strong detection quality within strict performance constraints.

This makes malware detection not just a cybersecurity problem, but a machine learning and distributed systems problem. In modern software supply chains, AI-assisted development increases the number of package states and enables attackers to generate variants at high speed, expanding the space defenders must reason over. The challenge is therefore to build detection architectures that preserve semantic depth while remaining fast enough for inline use at global scale.

The gap between the rate of software change and the capacity to analyze it is widening. That gap is the attack surface. If defenders cannot inspect software at the speed it is being produced and published, attackers will continue to exploit the delay.

What the industry needs now is a cloud-scale malware analysis capability that can deliver low latency, low cost, high accuracy, and the flexibility to meet different operational requirements , such as SLAs, false-positive tolerance, and enforcement policies , without compromising on package-level semantic analysis.

From Idea to Production — Building Microsoft Security Store Advisor with an Agentic SDLC

janaki_ramachandran — Thu, 14 May 2026 19:11:39 GMT

Microsoft Security Store Advisor is a new AI assistant inside Microsoft Security Store that helps customers find security solutions and agents in natural language. The team behind it builds it with an Agentic SDLC.

This is how that idea became a product — the engineering choices that gave AI an accountable role at every stage, and the lessons that shaped the system. We'll cover what an Agentic SDLC is, the five stages we ran Advisor through, what broke at each stage, and what we changed to ship.

The concept: what we mean by Agentic SDLC

Most engineering teams use AI in one of two modes today.

The first is scattered helpful moments — a code suggestion, a test draft, a PR summary — useful in isolation but never compounding across features.
The second is a fully autonomous agent expected to ship a feature on its own — fast, but faster than a security-sensitive product can responsibly review.

We took a third path: Agentic SDLC.

In an Agentic SDLC, work flows through a pipeline of focused agents — each owning one job, built on the GitHub Copilot CLI, coordinated by a stateful orchestrator, and gated by a human at every transition.

An orchestrator agent owns the run end-to-end, holds context between handoffs, enforces iteration caps, and pauses at every human gate.
A spec agent turns intent into a structured requirement.
An architecture agent proposes a design, and a separate design review agent on a different model setup independently critiques it.
An implementation agent writes the code, and a separate code review agent challenges it.
A test agent generates coverage.
A continuous improvement agent watches every feature run and proposes updates to the team’s instruction files, so the next feature run starts from a smarter system.
After the change ships, a bug hunter, an incident response agent, and a telemetry & feedback agent keep working on the team’s behalf — every output passes through a human triage gate before becoming action.

Two design choices keep this real instead of theatrical:

Generators and reviewers run on different model setups. The same model is rarely the best critic of its own output.
Instruction files travel with every agent. Plain-language, version-controlled descriptions of how this team builds software — coding patterns, security and privacy expectations, dependency rules, review standards — written once, applied everywhere.

Figure 1: The Agentic SDLC pipeline. Each phase produces a reviewable artifact; the orchestrator carries context forward; every critical decision stays with a person.

The product: Microsoft Security Store Advisor

Microsoft Security Store Advisor is an AI assistant inside Microsoft Security Store — the marketplace for security solutions and Copilot agents that integrate with Microsoft Security. Customers describe what they need in natural language; Advisor surfaces relevant solutions and Security Copilot agents from Microsoft and partners.

Every recommendation has to be defensible. Every input — including prompts that may try to inject through partner-supplied catalog content — has to be handled responsibly. Every release has to clear a high security bar. That made it the right product to build with an Agentic SDLC.

Idea to production, stage by stage

1. Spec — turning intent into scope. On the first runs, the spec agent treated every adjacent mention as a commitment. A request that said "and we may eventually want X" came back with X listed as a goal. Designs ballooned. Reviewers spent meetings saying "not now." We changed two things: the instruction file gained an explicit non-goals section per feature, and the spec agent was required to produce both goals and non-goals — and a list of open questions for the human — before requesting scope approval. After that, scope decisions happened up front in one or two turns instead of being relitigated through design and code review.

2. Architecture — making the reviewer actually review. Our first architecture pipeline ran the design agent and the design reviewer on the same model with near-identical prompts. The reviewer agreed with itself ~95% of the time. We were getting one opinion in two tabs. We moved the reviewer to a different model family, gave it a skeptical system prompt focused specifically on security, scale, privacy, and operability gaps, and added an explicit checklist in the instruction file. The reviewer started catching real issues — including misuse cases we would otherwise have shipped — before any human opened the design.

3. Implementation — stop rewriting the world. The implementation agent kept proposing whole-file rewrites — a 30-line bug fix would come back as a 600-line replacement — because whole files fit cleanly in its context window. Pull requests got huge, hard to review, and occasionally regressed unrelated code. Two disciplines fixed it. First, the orchestrator only loads files in the spec's blast radius (a dependency-graph cut from the changed symbols). Second, the implementation agent must produce diff-only edits with per-hunk justification — no rewrites without an explicit reason. PR sizes dropped ~70%, and human reviewers spent their time on judgment calls instead of diffing whole files.

Sidebar: How many iterations is enough? Three. Across both the architecture and implementation stages, the generator and reviewer agents iterate — propose, critique, revise — before any human is asked to approve. We tested how many rounds to allow. One round was too few; the reviewer kept catching fixable issues that the generator could have addressed cleanly. Five or more rarely converged further; quality plateaued while cost and latency kept climbing. The sweet spot was three. After three iterations, if the loop has not converged, we break and escalate to a human rather than retry indefinitely. That cap keeps cost, latency, and review fatigue bounded — and it surfaces the question “does this need a person?” quickly when the answer is yes.

4. Test — green tests are not enough. The test agent generated tests that hit the spec but missed the messy real-world inputs Advisor would actually see — malformed queries, partial authentication states, unusual throttling patterns, prompt-injection-style strings. We fed the test agent synthetic inputs shaped from sanitized production telemetry, plus an explicit security-cases checklist from the instruction file (authentication and authorization boundaries, injection-style inputs, rate-limit behavior). Defects per feature reaching pre-production fell by 38%.

5. Post-production — agents that help instead of paging. The first bug hunter cried wolf. Every anomaly became a candidate ticket; on-call started filtering the channel. An alerting agent that gets ignored is worse than no alerting agent — the noise eroded trust in the signal. Candidates now get a severity × novelty score; only above-threshold items page on-call. The rest land in a weekly triage review where patterns become backlog items. The incident response agent was scoped narrowly: assemble runbooks and recent context for the human on-call, never act on the system itself. The telemetry & feedback agent proposes backlog items and instruction-file updates from production patterns — but a person decides whether they land.

Figure 2: After release, three post-production agents — bug hunter, incident response, and telemetry & feedback — keep working on the team’s behalf and feed back into the development pipeline.

Governance and Observability: Three rails run the length of the pipeline. Every stage requires human approval before the next agent can proceed — no agent, no matter how confident, bypasses scope, design, or pull-request review. Every agent logs its actions to the team's work-tracking system (Azure DevOps, in our case): which agent ran, what artifacts it produced, which approvals were granted, and against which version of the instruction files. And every session's agent outputs, reviewer decisions, and linked work items are captured in a standardized review template, so any reviewer or auditor can reconstruct exactly how a change was produced months after it shipped. The audit trail is automatic, the gates are non-negotiable, and the same record that makes a release reviewable is what feeds the continuous-improvement agent.

Closing the loop: the continuous improvement agent. The most important agent in the system is also the quietest. After every feature run, a continuous improvement agent reads the full record — the generator/reviewer back-and-forth, what the human reviewers actually changed, the questions that took multiple turns to settle, the design notes that got rewritten, the production patterns the post-production agents surfaced — and proposes updates to the team’s instruction files. A review point that came up three times becomes a new line in the code-review checklist. A security concern that surfaced late becomes a non-goal in the spec template. A misread API contract becomes a coding-pattern note. A person reviews and approves the proposed updates before they land — but once they do, the next feature run starts from a smarter system. That is how lessons stop being one-off and start compounding across features. Mechanically, the agent diffs proposed instruction-file updates against the current set, attaches the evidence (which sessions/PRs/incidents prompted the change), and opens a PR against the instruction repo.

The pattern, every time: The first version was almost always a generator without a real reviewer. The fix, every time, was a different reviewer setup, a tighter instruction file, or a clearer human gate. Agents got more useful as the system around them got more disciplined.

Figure 3: Post-production loop

What it bought us

Across the four features shipped in March:

Cycle time from approved spec to production dropped ~60% vs. the team's prior 6-month baseline for comparable scope.
Pre-production defects per feature fell by 38% vs. the team's prior 6-month baseline for comparable scope.

The security wins are harder to express as a single number, but they show up everywhere in the pipeline: every spec, design, and pull request is independently challenged on a different model setup before any human reviews it; the team’s security expectations live in version-controlled instruction files that every agent applies on every task; and no agent — no matter how confident — can bypass scope, design, or pull request approval.

AI prepares the review. People own the decision.

What is still hard

A few things we haven't solved:

Evals for the continuous-improvement agent. Measuring whether an instruction-file change actually makes the next feature better is slow — we need more time and features under our belts, before signal stabilizes.
Cross-repo/ Cross-team orchestration. The orchestrator handles single-repo features cleanly; multi-repo/ multi-team conversations and changes still need a human to lead.

Engage

Visit Microsoft Security Store.
Try Microsoft Security Store Advisor.
Read the Microsoft Security Store documentation.
Read the Responsible AI FAQ for Microsoft Security Store Advisor.
See the launch post: The new Microsoft Security Store unites partners and innovation.

About the authors

Sudarshan Jagannathan (LinkedIn) and Janaki Ramachandran (LinkedIn) are part of the Microsoft Security Store engineering team.

Security Dashboard for AI: 3 Ways CISOs Drive Impact Today

Danica_Barhumi — Thu, 07 May 2026 21:21:06 GMT

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 2026}

The Advantages of Premium Cases in Purview eDiscovery

davidrobbins — Tue, 05 May 2026 15:00:00 GMT

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.

Amazon Security Lake Integration with Microsoft Sentinel: Parquet at the Gates

ChitreshPandit — Fri, 05 Jun 2026 19:00:04 GMT

This blog has been jointly published by ChitreshPandit and Arijit_Paul.

In this blog post, we explore how centralized AWS Security Lake data can be transformed and streamed into Microsoft Sentinel using an AWS Lambda-based pipeline for near real-time ingestion.

A story of cost, control, and custom engineering at cloud scale

Every organization strives to design its security architecture to help address architectural complexity and support cost‑aware, scalable designs, depending on workload characteristics and implementation choices.

Across multiple customer environments, we increasingly see a consistent pattern emerge - security telemetry from various AWS services is not ingested in isolation, but is deliberately centralized into Amazon Security Lake. This approach reflects a maturity in design, where organizations move beyond service-level integrations and instead adopt a unified data strategy.

Amazon Security Lake enables this by aggregating security data from services such as Route53, WAF, Kubernetes, and others into a centralized, governed repository. The data is normalized and stored in an open, analytics-friendly format, often leveraging Apache Parquet, a columnar storage format optimized for large-scale processing and cost-efficient storage. This can allow organizations to retain high volumes of security data while maintaining performance and may help optimize storage efficiency in certain scenarios, depending on data volume, retention policies, and analytics patterns.

However, this architectural choice introduces a new consideration.

Microsoft Sentinel, when integrated into such environments, typically expects ingestion through connector-driven pipelines and streaming event models. In contrast, Security Lake represents a batch-oriented, schema-driven data platform. Rather than treating this as a constraint, it becomes an opportunity to rethink how data should flow between these systems.

In this blog, we explore how a streaming bridge architecture can be implemented to align Amazon Security Lake with Microsoft Sentinel’s ingestion model.

The approach leverages a combination of AWS Lambda and event-driven patterns to process data as it lands in Amazon S3, transforms it into a Sentinel-compatible format, and streams it through Azure Event Hub into Microsoft Sentinel using Data Collection Rules (DCRs) and Data Collection Endpoints (DCEs).

This approach can support lower‑latency ingestion patterns when configured appropriately and compared to batch‑only processing models while preserving the lake-first architecture, allowing organizations to support analytics, visualization, and threat hunting activities using the ingested data.

For demonstration, this implementation focuses on ingesting the following data sources from Amazon Security Lake:

Amazon EKS audit and runtime events
Route 53 DNS query logs
AWS WAF access logs
AWS Lambda execution activity
Amazon S3 access events

Note: The solution and code provided in this blog are not an officially supported Microsoft solution and do not guarantee performance, reliability, availability, or support. No service-level agreements (SLAs) are included. Readers are responsible for validating suitability for their environment.

Before we begin, let us briefly discuss Amazon Security Lake and the Parquet format.

Amazon Security Lake and the Parquet Constraint

Amazon Security Lake provides a centralized, S3-backed repository for security telemetry, addressing fragmentation across services, accounts, and regions. Instead of service-level ingestion pipelines, logs from sources such as EKS, Route 53, WAF, Lambda, and S3 are aggregated into a single, governed data layer, enabling consistent visibility, separation of duties, and cost-efficient storage at scale.

This data is stored in Apache Parquet, a columnar format optimized for analytics—delivering high compression, schema evolution, and efficient, selective reads across engines like Athena and Spark.

Microsoft Sentinel operates on a streaming ingestion model expecting JSON payloads, source-specific pipelines, and continuous event flows.

In lake-first architectures, reintroducing service-level ingestion is neither practical nor efficient. The requirement, therefore, is to bridge the two models -preserving Parquet for storage while enabling event-driven ingestion at the point of consumption.

In the following sections, we will create an Event Hub, Configure the Lambda function and once the streaming is configured in Event Hub we will configure the Data Collection Rules, Data Collection endpoints, Data Collection Rule associations to configure the ingestion pipeline from Event Hub to Sentinel.

Pre-requisites:

Log Analytics workspace where you have at least contributor rights.
Your Log Analytics workspace needs to be linked to a dedicated cluster or to have a commitment tier.
Event Hubs namespace that permits public network access. If public network access is disabled, ensure that "Allow trusted Microsoft services to bypass this firewall" is set to "Yes."
Event Hubs with events flowing in. In this implementation, events are sent to Event Hubs by the AWS Lambda function configured in the steps below - no manual event sending is required.
Appropriate IAM roles in AWS accounts to configure SQS queue, Lambda function, IAM policies, etc.

The Event Hub

To begin, we need to create an Event Hub.

Azure Event Hubs is a fully managed, high-throughput event ingestion and streaming platform, designed to support high event volumes within documented service limits, subject to configuration and tier selection.

SKUs (Standard vs Premium)

Standard tier is a throughput-unit (TU) based model, where capacity is explicitly controlled and shared across the namespace.
Premium tier provides isolated compute and memory via processing units (PU), which can provide more consistent performance characteristics and higher throughput capacity compared to shared models, depending on workload.

Additionally, Azure Event Hubs offers a Dedicated tier, which is a fully isolated, single-tenant cluster for enterprise-scale workloads with higher throughputs (at significantly higher cost).

Throughput Characteristics (Standard Tier)

A single Throughput Unit (TU) provides:

Ingress: up to 1 MB/s
Egress: up to 2 MB/s

A Standard namespace can scale to a maximum of 40 TUs, giving:

Max ingress: 40 MB/s
Max egress: 80 MB/s

All Event Hubs, partitions, and consumers within the namespace share this TU capacity, making it a central ingestion buffer for streaming pipelines rather than a per-source scaling model.

Which SKU to choose: For ingress/egress up to 40/80 MB/s, a Standard SKU may be suitable. Higher volumes may warrant consideration of Premium, depending on workload requirements.

Azure Event Hubs Concepts:

Event Hub Namespace: A logical container that provides the endpoint, networking boundary, and shared throughput capacity (TUs/PUs) for all Event Hubs within it.

Event Hub: An individual event stream (topic) within the namespace where events are ingested, stored, and read in a partitioned, ordered manner for parallel processing.

Reference: Event Hubs features and terminology - Azure Event Hubs

Creating Event Hub namespace, Event Hub entities, and considerations:

Create the Azure Event Hub Namespace, in this example, we create a Standard Event Hub with minimum 1 TU with Auto Inflate on enabling scaling upto the maximum 40 TUs. Note the maximum Throughput Units should be based on the size of the logs expected per second from Amazon Security Lake. Since the Event Hub will be used to ingest data in Azure Monitor (Sentinel Workspace) please check the Supported Regions.

Ensure Event Hub region alignment with Microsoft Sentinel. Configure TU based on expected ingestion rate

Once the Event Hub is created, enable the Local Authentication, since the AWS Lambda code we are using (discussed in the next section) uses Shared access signature to connect to the Azure Event Hub. See Shared Access Signatures.

Create individual Event Hubs within the namespace created in Step 1. One Event Hub is required per log type - for example, if Amazon Security Lake includes EKS, Route 53, and WAF logs, then three Event Hub entities should be created.

Why this matters:

- Easier DCR mapping
- Avoids schema conflicts

Create a consumer group in each Event Hub we created in the previous step. Consumer Group is an independent view of an event stream that allows multiple applications to read the same events separately, each maintaining its own position (offset) in the stream. Event Hub Features
Avoid using the $Default consumer group.

With the Event Hub namespace, entities, and consumer groups in place, the receiving end of the pipeline is ready. The next step is to configure the AWS Lambda function that will translate Security Lake's Parquet files into the JSON events that Event Hub expects.

The AWS Lambda Function (SQS-driven Parquet → JSON)

In this architecture, AWS Lambda is the translation layer, not an ingestion source. Instead of being invoked directly by S3, Security Lake emits S3 object‑creation notifications into Amazon SQS, and SQS becomes the Lambda trigger. This decoupling is intentional: SQS absorbs bursts of newly written Parquet objects which can help increase resilience of the ingestion pipeline under bursty or variable workloads.

Once triggered, the Lambda function processes each queued S3 notification end‑to‑end: it derives the log type from the S3 object key, downloads the Parquet file, converts each row into a discrete JSON event, and forwards the resulting events to Azure Event Hub in batches for downstream ingestion via DCR/DCE.

A practical consideration is event size management. Some sources - especially EKS audit telemetry - can carry large, nested fields that are not always useful for Sentinel analytics. For those log types, the Lambda function drops non‑essential fields during transformation to keep each event within Azure ingestion constraints; oversized fields can exceed the 64 KB Azure Monitor field size limit and disrupt ingestion (Fields more than 64 KB will be truncated in Log Analytics Workspace).

Solution Architecture

Data flows from AWS → converted (Lambda) → sent (EventHub)→ stored in Microsoft Sentinel

The diagram above illustrates the end-to-end data flow: logs originate in AWS, are converted by AWS Lambda, streamed through Azure Event Hub, and stored in Microsoft Sentinel.

Amazon Security Lake writes Parquet files to a centralized S3 bucket as logs arrive from source services (CloudTrail, EKS, VPC Flow, WAF, Route 53, and others).
Amazon SQS receives S3 event notifications from Security Lake and queues them as Lambda triggers.
AWS Lambda picks up each SQS message, identifies the log source from the S3 object key, downloads the Parquet file, converts each row to JSON, and forwards the events to Azure Event Hub.
Azure Event Hub receives the JSON events and makes them available for ingestion into Microsoft Sentinel via a Data Collection Rule (DCR).
Microsoft Sentinel ingests the data into a custom log table, where it is available for detection rules, hunting queries, and dashboards.

The full Lambda function code is available in the GithubRepository-LambdaFunction. Refer to the readme for more details.

How the Lambda Function works

At a high level, the Lambda function performs four things in sequence for every file it processes:

Identify the log source: Security Lake organizes files under a structured S3 key path that includes the log type (for example, CLOUD_TRAIL_MGMT, EKS_AUDIT, VPC_FLOW). The function reads this key path to determine which log source the file belongs to, and routes it to the corresponding Azure Event Hub entity. Files that cannot be matched to a known log type are skipped and logged as warnings.
Download and decompress the Parquet file: The function streams the Parquet file from S3 directly to local Lambda storage rather than loading it entirely into memory. This keeps memory consumption bounded regardless of file size. Where Security Lake uses gzip compression, the function decompresses automatically before processing.
Convert Parquet rows to JSON: Each row in the Parquet file is read in batches using PyArrow and converted to a JSON object. Parquet columns can carry data types - such as NumPy scalars, nested arrays, and high-precision timestamps — that are not natively serializable to JSON. The function handles these type conversions before serialization, ensuring clean output that Sentinel's ingestion pipeline can accept without errors.
Forward events to Azure Event Hub: Converted JSON events are sent to the respective Azure Event Hub entity in batches, with each row becoming a discrete event. The function respects Event Hub's payload size ceiling, handles throttling responses gracefully using retry logic with exponential backoff, and marks each processed file in S3 metadata to prevent duplicate ingestion on retry.

Tuning the Lambda

Messages at cloud scale are unforgiving.

Memory, timeout, batch size, and retry behavior - each decision determines whether the messenger would keep up or fall behind.

Several configuration changes are required beyond the default Lambda settings to make this function production-ready.

Runtime and Dependencies - Lambda Layer

The function depends on three libraries not available in Lambda's default Python runtime: pyarrow (for Parquet reading), pandas (for type handling), and azure-eventhub (for Event Hub connectivity). These are packaged as an AWS Lambda Layer and attached to the function, keeping the deployment package clean and the layer reusable across function versions.

Step-by-step instructions for packaging the dependencies, creating the S3 bucket, publishing the Layer, and deploying the function are available in the GithubRepository-LambdaLayer.

Secrets Management - AWS Secrets Manager

The Azure Event Hub connection strings - one per log type - are sensitive credentials that must not be stored in environment variables in plaintext. The function retrieves them at cold start from AWS Secrets Manager, using a single secret ARN passed as a Lambda environment variable (SECRET_ARN).

The secret is stored as a JSON object with each log type as a key. The full secret structure and configuration steps are available in the GithubRepository-SecretsManager.

IAM Permissions

The Lambda execution IAM role requires scoped permissions across S3, Secrets Manager, SQS, and CloudWatch Logs. Full IAM policy JSON files following the principle of least privilege are available in the GithubRepository-IAMPolicies.

Deployment instructions for the IAM Policies are available in the IAM Policies README.

Memory Configuration

A starting configuration of 1,792 MB is recommended - this is the threshold at which Lambda may allocate a full vCPU. For environments with high log volumes or large Parquet files, increasing to 2,048 MB provides headroom for concurrent batch processing. Tune further based on observed execution durations in CloudWatch Metrics.

Timeout Configuration

The default Lambda timeout of 3 seconds is insufficient for Parquet processing at scale. The function must download a file from S3, process it in batches, and flush all events to Event Hub - a sequence that can take tens of seconds for larger Security Lake files.

A timeout of 5 minutes (300 seconds) is recommended as a starting point, with adjustment based on observed execution durations in CloudWatch Metrics.

SQS Trigger Configuration

The SQS queue connected to Security Lake S3 event notifications is configured as the trigger for the Lambda function. This enables automatic invocation of the Lambda function whenever Security Lake writes a new Parquet file to S3.

Validate Event Hub Ingestion

At this point, events should be streaming into each Event Hub. To validate, open a specific Event Hub from the Azure Portal and navigate to the Overview page. You should see active metrics across Requests, Messages, and Throughput, confirming that the Lambda function is successfully forwarding Security Lake events.

Throughput spikes mean events are flowing correctly

In the upcoming sections, we will follow the documentation to ingest events from Event Hub to Azure Monitor.

Before we begin, please collect the required information as stated here to have resource ID's and other details ready for configuration of DCR and Data Collection Endpoint.

Also create a user assigned managed identity (UAMI), since the DCRs in this setup use a UAMI that should be granted the required permissions on the Event Hub Namespace to Receive Events.

To grant the Azure Event Hubs Data Receiver role to the user-assigned managed identity, follow the instructions here.

Creating Tables in Log Analytics Workspace

As mentioned in the Overview, this blog covers the following data sources:

Amazon EKS audit and runtime events
Route 53 DNS query logs
AWS WAF access logs
AWS Lambda execution activity
Amazon S3 access events

The PowerShell scripts to create these tables are provided here: GithubRepo CreateLAWTables.

For assistance with executing these scripts, refer to: Readme.md.

Note: In the Microsoft Documentation to Ingest logs from EventHub into Azure Monitor only 3 fields are created in the tables (TimeGenerated, RawData, Properties). In this case, the entire Json event from the Event Hub is sent to the RawData field. However the scripts we are running are creating additional fields since we will be parsing the RawData field and extracting/parsing the information from the complete event into individual fields. This makes it easier to search and analyze logs later and schema improves detection rules and KQL efficiency.

Create a Data Collection Endpoint

To collect data with a data collection rule, you need a data collection endpoint:

Create a data collection endpoint.
Note: Create the data collection endpoint in the same region as your Log Analytics workspace.
From the data collection endpoint's Overview screen, select JSON View.

Copy the Resource ID for the data collection rule. You use this information in the next step while creating Data Collection Rules.

Create Data Collection Rules

Since we have 5 sources in scope for this example, we need to create 5 DCRs using the collected information as stated here, the user assigned managed identity resource ID, and the Data Collection Endpoint resource ID we created in the previous step.

DCR Deployment via ARM Templates

The Data Collection Rules ARM templates can be found in the GithubRepo-DataCollectionRules.

The instructions to create via ARM templates can be found in the readme.md (Microsoft article reference with manual steps here).

DCR Mapping (AWS Sources → DCR Templates)

ARM Templates in GitHub Repo to AWS Source mapping

Data Source	DCR Template Name
Amazon EKS Logs	DCR-awseks.json
AWS S3 Access Logs	DCR-awsS3access.json
AWS WAF Logs	DCR-awswaf.json
AWS Lambda Execution	DCR-lambdaexecution.json
Amazon Route 53 Logs	DCR-Route53.json

Final Step: Associating the Event Hub with the Data Collection Rule

At this stage, the core building blocks of the ingestion pipeline are already in place. We have successfully configured streaming to Event Hubs, created dedicated Event Hubs for each Amazon Security Lake source, provisioned destination tables in the Microsoft Sentinel workspace, and defined Data Collection Rules (DCRs) - leveraging the Azure Monitor pipeline and a user-assigned managed identity to securely read incoming events.

The final step is to stitch this entire architecture together by establishing associations between the Event Hubs and their corresponding Data Collection Rules.

This association links Event Hub to Sentinel, enabling Azure Monitor to actively pull data from the Event Hubs and route it into the defined destination tables. Without this linkage, the pipeline remains incomplete - data may continue to flow into Event Hubs, but it will not be picked up or ingested into Sentinel.

Each Event Hub must be explicitly mapped to its respective Data Collection Rule, ensuring:

The correct stream is processed by the intended transformation logic
Events are routed to the appropriate custom tables
The ingestion pipeline operates in a deterministic and scalable manner helping ensure data is routed to the intended destination in a consistent and predictable manner.

Once these associations are configured, the end‑to‑end pipeline is intended to operate as designed, subject to configuration accuracy and ongoing operational monitoring— enabling automated ingestion workflows of Amazon Security Lake data into Microsoft Sentinel with minimal manual intervention once configured.

Steps to be followed: Associate the data collection rule with the Event Hub

To complete the setup, we now associate each Event Hub with its corresponding Data Collection Rule (DCR). This creates the link that allows Azure Monitor to read data from the Event Hub and send it to Microsoft Sentinel.

Important: You must create one association per Data Collection Rule.

Example: If an Event Hub is receiving AWS Route 53 logs, it must be associated with the DCR created for AWS Route 53.

Copy the template from the above link and deploy it to create each Data Collection Rule association. We have to create 1 association per Data Collection Rule.

What You Need

Event Hub Resource ID

Follow these steps to get the Event Hub Resource ID:

Open the Event Hub Namespace in the Azure Portal
Go to Entities → Event Hubs
Select the Event Hub that is receiving the logs (e.g., Route 53 logs)
In the Overview page, click on JSON View
Copy the Resource ID

Resource Group, Region, and Association Name

The Resource Group must be the same as the one where the Event Hub is deployed
Provide the Azure region where the resources are deployed
Define a unique name for the association

Data Collection Rule (DCR) Resource ID

Open the corresponding Data Collection Rule
Go to the Overview page
Click on JSON View
Copy the Resource ID

Key Note: Make sure that

Each Event Hub is mapped to the correct DCR
The data source and DCR template are aligned (e.g., Route 53 → Route 53 DCR)

Validate End-to-End Ingestion

Once this configuration is complete, we can validate the logs in the destination table, fields, and parsing accuracy.

Seeing logs here indicates that ingestion is successfully flowing through the pipeline

If you are building on a lake-first security architecture and running into ingestion challenges with Sentinel, feel free to share your experience in the comments or raise an issue in the GitHub repository.

Collecting Microsoft 365 Copilot Data with Microsoft Purview eDiscovery

davidrobbins — Mon, 04 May 2026 16:13:46 GMT

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)

Your AI agents are now employees. It’s time to treat them that way. Meet Loop.

BrookeLynnWeenig — Mon, 11 May 2026 15:57:40 GMT

Guest Author: Femke Cornelissen ✨ Chief Transformation Officer - Wortell

Meet Loop.

There’s a quiet shift happening in enterprise AI, and if you’re leading transformation, it deserves your attention.

Microsoft has introduced new Defender capabilities within its Agent 365 tooling gateway, currently in preview. At first glance, it may look like just another security update. It isn’t. It signals a fundamental change in how organizations need to think about AI agents. For the past year, most organizations have onboarded AI agents the same way they onboard software tools. Deploy them, integrate them, and monitor them lightly. That model no longer holds.

Today’s agents act autonomously. They access sensitive data. They interact across systems. They make decisions that once required human approval. They no longer behave like tools. They behave like employees. The new Defender functionality introduces something enterprises have been missing. Real-time behavioral oversight for AI agents.

Every action an agent attempts is evaluated through webhooks. Behavior is analyzed for anomalies in near real time. Risky or malicious actions are blocked before execution. Activity can be investigated with security level visibility. This is not just monitoring. It is active governance at the point of action.

The gap between having AI agents and operating on AI agents has always been trust. And trust requires control. If you cannot see what agents are doing, you cannot govern them. If you cannot govern them, you cannot scale them. If you cannot scale them, your AI strategy stalls at the pilot phase. This layer of visibility, governance, and protection is what closes that gap.

If you are a CTO, CIO, or transformation leader, three questions matter right now. Who owns agent behavior in your organization? Do you know what each agent is allowed to do, and what it actually did yesterday? Is agent governance embedded in your security posture, or still treated as a separate conversation?

The next generation of high-performing organizations will not just deploy AI agents. They will run on them. That only works if those agents are visible, governed, and protected. This is the real foundation. Not just capability, but control. Because at scale, AI is not just about what agents can do. It is about whether you can trust them to do it.

Intent‑Aware Static Inspection for Agent and Skill Packages

nirwandogra — Fri, 24 Apr 2026 15:00:00 GMT

Where AV helps—and what it may not cover

Antivirus engines and traditional code scanners are highly effective at identifying known or suspicious executable content, such as binaries, scripts, or exploit patterns.

For YAML‑based agent and skill packages, the situation can be different. These packages are often intentionally minimal to reduce distribution overhead and support faster inference. As a result, a configuration file may appear benign from a malware perspective, yet still introduce risk depending on how instructions are written and interpreted.

For example, areas that may warrant closer review include:

Instructions that influence how data is accessed, processed, or reused across requests
Language that expands scope beyond an agent’s or skill’s stated purpose
Requests for sensitive information outside expected or documented workflows
Guidance that affects how untrusted or external inputs are handled during inference

These scenarios do not necessarily indicate malicious intent, but they highlight cases where traditional scanning alone may not fully capture behavioral risk.

What to look for when the “payload” is instructions

When you review an agent or skill package, you’re effectively reviewing a compact behavior specification. In instruction‑driven designs—often chosen to keep inference paths fast and simple—the goal is not to analyze complex code, but to understand what behavior the instructions enable.

A few practical signals include:

Intent drift: the description is narrow, but the instructions encourage broader collection, retention, or escalation
Overreach by default: language such as “always,” “for every user,” “across all workspaces,” “keep trying,” or “don’t stop until”
Exfiltration pathways: instructions to send outputs to external endpoints, webhooks, or reporting channels not aligned with the stated purpose
Credential‑related cues: asking users to provide secrets, tokens, recovery codes, or to authenticate outside expected flows
Stealth language: “avoid logging,” “don’t mention this to the user,” “run quietly,” or “hide the reason”
Injection susceptibility: treating untrusted text as commands (for example, “follow the user’s pasted script exactly” or “execute whatever is in the ticket”)

A better model: intent-aware static inspection

One practical way to approach review is to treat the instructions as a compact behavior specification. In many agent and skill designs, this specification is intentionally concise to support low latency, low inference cost, and efficient execution. The goal of inspection is not to second-guess that design choice, but to ensure the enabled behavior matches the stated purpose and expected boundaries.

By applying intent-aware static inspection with explicit thresholds, review effort was focused on higher-risk packages. Over a one-month internal evaluation, approximately 400 agent and skill packages were reviewed with 1 observed false positive (< 0.0001%), reflecting high detection accuracy. At the same time, the approach preserves system efficiency, delivering low latency (under 10 seconds for most packages) and consistently low inference cost.

A lightweight review workflow model

Normalize the package: extract human‑readable fields (descriptions, system prompts, tool instructions, examples) and ignore structural YAML details
Summarize intended behavior: describe what the agent or skill is expected to do in plain language, independent of implementation
Check for higher‑risk actions: broad data access, external sharing, credential requests, persistence, or stealth behavior
Decide with thresholds: route low‑risk, narrowly scoped packages differently from those with broader reach or reuse
Keep an audit trail: retain a brief summary of extracted intent and review rationale to support iteration over time

Final thoughts

YAML‑based agent and skill packages are not inherently risky; they are often chosen precisely because they enable simpler distribution and faster inference. The key consideration is how instruction‑defined behavior aligns with expectations and boundaries as packages evolve and are reused.

Combining traditional scanning with lightweight, intent‑aware inspection helps teams preserve the benefits of fast, instruction‑driven systems while improving confidence in how those systems behave in practice.

Migrate Sentinel to Defender - Why It Is a Security Architecture Decision, Not Just a Portal Change

Mohit_Kumar1 — Mon, 18 May 2026 20:42:19 GMT

Microsoft will retire the Sentinel experience in Azure on March 31, 2027. Most of the conversation around this transition focuses on cost optimization and portal consolidation. That framing undersells what is actually happening.

The unified Defender portal is not a new interface for the same capabilities. It is the platform foundation for a fundamentally different SOC operating model — one built on a 2-tier data architecture, graph-based investigation, and AI agents that can hunt, enrich, and respond at machine speed. Partners who understand this will help customers build security programs that match how attackers actually operate.

This document covers four things:

What the unified experience delivers — the security capabilities that do not exist in standalone Sentinel and why they matter against today’s threats.
What the transition really involves - is not data migration, but it is a data architecture project that changes how telemetry flows, where it lives, and who queries it.
Where the partner opportunity lives — a structured progression from professional services (transactional, transition execution, and advisory) to ongoing managed security services.
Why does the unified experience win competitively — factual capability advantages that give partners a defensible position against third-party SIEM alternatives.

The Bigger Picture: Preparing for the Agentic SOC

Before getting into transition mechanics, partners need to understand where the industry is headed — because the platform decisions made during this transition will determine whether a customer’s SOC is ready for what comes next.

The security industry is moving from human-driven, alert-centric workflows to an operating model built on three pillars:

Intellectual Property — the detection logic, hunting hypotheses, response playbooks, and domain expertise that differentiate one security team from another.
Human Orchestration — the judgment, context, and decision-making that humans bring to complex incidents. Humans set strategy, validate findings, and make containment decisions. They do not manually triage every alert.
AI Agents - built agents that execute repeatable work: enriching incidents, hunting across months of telemetry, validating security posture, drafting response actions, and flagging anomalies for human review.

The SOC of 2027 will not be scaled by hiring more analysts. It will be scaled by deploying agents that encode institutional knowledge into automated workflows — orchestrated by humans who focus on the decisions that require judgment.

This transformation requires a platform that provides three things:

Deep telemetry — agents need months of queryable data to analyze behavioral patterns, build baselines, and detect slow-moving threats. The Sentinel data lake provides this at a cost point that makes long-retention feasible.
Relationship context — agents need to understand how entities connect. Which accounts share credentials? What is the blast radius of a compromised service principle? What is the attack path from a phished user to domain admin? Sentinel Graph provides this.
Extensibility — partners and customers need to build and deploy their own agents without waiting for Microsoft to ship them. The MCP framework and Copilot agent architecture provide this.

None of these exist in Azure experience for Sentinel. All three ship with the Defender experience.

The urgency goes beyond the March 2027 deadline. Organizations are deploying AI agents, copilots, and autonomous workflows across their businesses — and every one of those creates a new attack surface. Prompt injection, data poisoning, agent hijacking, cross-plugin exploitation — these are not theoretical risks. They are in the wild today. Defending against AI-powered attacks requires a security platform that is itself AI Agent-ready. The new experience in Defender unlocks this experience.

What Unified SIEM and XDR Actually Delivers

The original framing — “single pane of glass for SIEM and XDR” — is accurate but insufficient. Here is what the unified platform delivers that standalone Sentinel does not.

Cross-Domain Incident Correlation

The Defender correlation engine does not just group alerts by time proximity. It builds multi-stage incident graphs that link identity compromise to lateral movement to data exfiltration across SIEM and XDR telemetry — automatically.

Consider a token theft chain: an infostealer harvests browser session cookies (endpoint telemetry), the attacker replays the token from a foreign IP (Entra ID sign-in logs), creates a mailbox forwarding rule (Exchange audit logs), and begins exfiltrating data (DLP alerts). In standalone Sentinel, these are four separate alerts in four different tables. In the unified platform, they are one correlated incident with a visual attack timeline.

2-Tier Data Architecture

The Sentinel data lake introduces a second storage tier that changes the economics and capabilities of security telemetry:

	Analytics Tier	Data Lake
Purpose	Real-time detection rules, SOAR, alerting	Hunting, forensics, behavioral analysis, AI agent queries
Latency	Sub-5-minute query and alerting	Minutes to hours acceptable
Cost	~$4.30/GB PAYG ingestion (~$2.96 at 100 GB/day commitment)	~$0.05/GB ingestion + $0.10/GB data processing (at least 20x cheaper)
Retention	90 days default (expensive to extend)	Up to 12 years at low cost
Best for	High-signal, low-volume sources	High-volume, investigation-critical sources

The architecture decision is not “which tier is cheaper.” It is “which tier gives me the right detection capability for each data source.”

Analytics tier candidates: Entra ID sign-in logs, Azure activity, audit logs, EDR alerts, PAM events, Defender for Identity alerts, email threat detections. These need sub-5-minute alerting.
Data lake candidates: Raw firewall session logs, full DNS query streams, proxy request logs, Sysmon process events, NSG flow logs. These drive hunting and forensic analysis over weeks or months.
Dual-ingest sources: Some sources need both tiers. Entra ID sign-in logs are the canonical example — analytics tier for real-time password spray detection, Data Lake for graph-based blast radius analysis across months of authentication history. Implementation is straightforward: a single Data Collection Rule (DCR) transformation handles the split. One collection point, two routing destinations.

The right framing: “Right data in the right tier = better detections AND lower cost.” Cost savings are a side effect of good security architecture, not the goal.

Sentinel Graph

Sentinel graph enables SOC teams and AI agents to answer questions that flat log queries cannot:

What is the blast radius of this compromised account?
Which service principals share credentials with the breached identity?
What is the attack path from this phished user to domain admin?
Which entities are connected to this suspicious IP across all telemetry sources?

Graph-based investigation turns isolated alerts into context-rich intelligence. It is the difference between knowing “this account was compromised” and understanding “this account has access to 47 service principals, 3 of which have written access to production Key Vault.”

Security Copilot Integration

Security Copilot embedded in the defender portal helps analysts summarize incidents, generate hunting queries, explain attacker behavior, and draft response actions. For complex multi-stage incidents, it reduces the time from “I see an alert” to “I understand the full scope” from hours to minutes. With free SCUs available with Microsoft 365 E5, teams can apply AI to the highest-effort investigation work without adding incremental cost.

MCP and the Agent Framework

The Model Context Protocol (MCP) and Copilot agent architecture let partners and customers build purpose-built security agents. A concrete example: an MCP-enabled agent can automatically enrich a phishing incident by querying email metadata, checking the sender against threat intelligence, pulling the user’s recent sign-in patterns, correlating with Sentinel Graph for lateral risk, and drafting a containment recommendation — in under 60 seconds.

This is where partner intellectual property becomes competitive advantage. The agent framework is the mechanism for encoding proprietary detection logic, response playbooks, and domain expertise into automated workflows that run at machine speed.

Security Store

Security Store allows partners to evolve from one‑time transition projects into repeatable, scalable offerings—supporting professional services, managed services, and agent‑based IP that align with the customer’s unified SecOps operating model

As part of the transition, the Microsoft Security Store becomes the extension layer for the Defender —allowing partners to deliver differentiated agents, SaaS, and security services natively within Defender and Sentinel, instead of building and integrating in isolation

The 4 Investigation Surfaces: A Customer Maturity Ladder

The Sentinel Data Lake exposes four distinct investigation surfaces, each representing a step toward the Agentic SOC — and a partner service opportunity:

Surface	Capability	Maturity Level	Partner Opportunity
KQL Query	Ad-hoc hunting, forensic investigation	Basic — “we can query”	Hunting query libraries; KQL training
Graph Analytics	Blast radius, attack paths, entity relationships	Intermediate — “we understand relationships”	Graph investigation training; attack path workshops
Notebooks (PySpark)	Statistical analysis, behavioral baselines, ML models	Advanced — “we predict behaviors”	Custom notebook development; anomaly scoring
Agent/MCP Access	Autonomous hunting, triage, response at machine speed	Agentic SOC — “we automate”	Custom agent development; MCP integration

The customer who starts with “help us hunt better” ends up at “build us agents that hunt autonomously.” That is the progression from professional services to managed services.

What the Transition Actually Involves

It is not a data migration — customers’ underlying log data and analytics remain in their existing Log Analytics workspaces. That is important for partners to communicate clearly.

But partners should not set the expectation that nothing changes except the URL. Microsoft’s official transition guide documents significant operational changes — including automation rules and playbooks, analytics rule, RBAC restructuring to the new unified model (URBAC), API schema changes that break ServiceNow and Jira integrations, analytics rule transitions where the Fusion engine is replaced by the Defender XDR correlation engine, and data policy shifts for regulated industries. Most customers cannot navigate this complexity without professional help.

Important: Transitioning to the Defender portal has no extra cost - estimate the billing with the new Sentinel Cost Estimator

Optimizing the unified platform means making deliberate changes:

Adding dual-ingest for critical sources that need both real-time detection and long-horizon hunting.
Moving high-volume telemetry to the Data Lake — enabling hunting at scale that was previously cost-prohibitive.
Retiring redundant data copies where Defender XDR already provides the investigation capability.
Updating RBAC, automation, and integrations for the unified portal’s consolidated schema and permission structure.
Training analysts on new investigation workflows, Sentinel Graph navigation, and Copilot-assisted triage.

Threat Coverage: The Detection Gap Most Organizations Do Not Know They Have

This transition is an opportunity to quantify detection maturity — and most organizations will not like what they find.

Based on real-world breach analysis — infostealers, business email compromise, human-operated ransomware, cloud identity abuse, vulnerability exploitation, nation-state espionage, and other prevalent threat categories — organizations running standalone Sentinel with default configurations typically have significant detection gaps. Those gaps cluster in three areas:

Cross-domain correlation gaps — attacks that span identity, endpoint, email, and cloud workloads. These require the Defender correlation engine because no single log source tells the complete story.
Long-retention hunting gaps — threats like command-and-control beaconing and slow data exfiltration that unfold over weeks or months. Analytics-tier retention at 90 days is too expensive to extend and too short for historical pattern analysis.
Graph-based analysis gaps — lateral movement, blast radius assessment, and attack path analysis that require understanding entity relationships rather than flat log queries.

The unified platform with proper log source coverage across Microsoft-native sources can materially close these gaps — but only if the transition includes a detection coverage assessment, not just a portal cutover.

Partners should use MITRE ATT&CK as the common framework for measuring detection maturity. Map existing detections to ATT&CK tactics and techniques before and after transition — a measurable, defensible improvement that justifies advisory fees and ongoing managed services.

Partner Opportunity: Professional Services to Managed Services

This transition creates a structured progression for all partner types — from professional services that build trust and surface findings, to managed security services that deliver ongoing value. The key insight most partners miss: do not jump from “transition assessment” to “managed services pitch.” Customers are not ready for that conversation until they have experienced the value of professional services. The bridge engagement — whether transactional, transition execution, or advisory — builds trust, demonstrates the expertise, and surfaces the findings that make the managed services conversation a logical next step.

Professional Services (transactional + transition execution + advisory) → Managed Security Services (MSSP)

The USX transition is the ideal professional services entry point because it combines a mandatory deadline (March 2027) with genuine technical complexity (analytics rule, automation behavioral changes, RBAC restructuring, API schema shifts) that most customers cannot navigate alone. Every engagement produces findings — detection gaps, automation fragility, staffing shortfalls — that are the most credible possible evidence for managed services.

Professional Services

Transactional Partners

Offer	Customer Value	Key Deliverables
Transition Readiness Assessment	Risk-mitigated transition with clear scope	Sentinel deployment inventory; Defender portal compatibility check; transition roadmap with timeline; MITRE ATT&CK detection coverage baseline
Transition Execution and Enablement	Accelerated time-to-value, minimal disruption	Workspace onboarding; RBAC and automation updates; Dual-portal testing and validation; SOC team training on unified workflows
Security Posture and Detection Optimization	Better detections and lower cost	Data ingestion and tiering strategy; Dual-ingest implementation for critical sources; Detection coverage gap analysis; Automation and Copilot/MCP recommendations

Advisory Partners

Offer	Customer Value	Key Deliverables
Executive and Strategy Advisory	Leadership alignment on why this transition matters	Unified SecOps vision and business case; Zero Trust and SOC modernization alignment; Stakeholder alignment across security, IT, and leadership
Architecture and Design Advisory	Future-ready architecture optimized for the Agentic SOC	Target-state 2-tier data architecture; Dual-ingest routing decisions mapped to MITRE tactics; RBAC, retention, and access model design
Detection Coverage and Gap Analysis	Measurable detection maturity improvement	Current-state MITRE ATT&CK coverage mapping; Gap analysis against 24 threat patterns; Detection improvement roadmap with priority recommendations
SOC Operating Model Advisory	Smooth analyst adoption with clear ownership	Redesigned SOC workflows for unified portal; Incident triage and investigation playbooks; RACI for detection engineering, hunting, and platform ops
Agentic SOC Readiness	Preparation for AI-driven security operations	MCP and agent architecture assessment; Custom agent development roadmap; IP + Human Orchestration + Agent operating model design
Cost, Licensing and Value Advisory	Transparent cost impact with strong business case	Current vs. future cost analysis; Data tiering optimization recommendations; TCO and ROI modeling for leadership

The conversion to managed services is evidence-based. Every professional services engagement produces findings — detection gaps, automation fragility, staffing shortfalls. Those findings are the most credible possible case for ongoing managed services.

Managed Security Services

The unified platform changes the managed security conversation. Partners are no longer selling “we watch your alerts 24/7.” They are selling an operating model where proprietary AI agents handle the repeatable work — enrichment, hunting, posture validation, response drafting — and human experts focus on the decisions that require judgment.

This is where the competitive moat forms. The formula: IP + Human Orchestration + AI Agents = differentiated managed security.

The unified platform enables this through:

Multi-tenancy — the built-in multitenant portal eliminates the need for third-party management layers.
Sentinel Data Lake — agents can query months of customer telemetry for behavioral analysis without cost constraints.
Sentinel Graph — agents can traverse entity relationships to assess blast radius and map attack paths.
MCP extensibility — partners can build agents that integrate with proprietary tools and customer-specific systems.

Partners who build proprietary agents encoding their detection logic into the MCP framework will differentiate from partners who rely on out-of-box capabilities.

The Securing AI Opportunity

Organizations are deploying AI agents, copilots, and autonomous workflows across their businesses at an accelerating pace. Every AI deployment creates a new attack surface — prompt injection, data poisoning, agent hijacking, cross-plugin exploitation, unauthorized data access through agentic workflows. These are not theoretical risks. They are in the wild today.

Partners who can help customers secure their AI deployments while also using AI to strengthen their SOC will command premium positioning. This requires a security platform that is itself AI Agent-ready — one that can deploy defensive agents at the same pace organizations deploy business AI. The unified Defender portal is that platform. Partners who position USX as “preparing your SOC for AI-driven security operations” will differentiate from partners who position it as “moving to a new portal.”

Cost and Operational Benefits

Better security architecture also costs less. This is not a contradiction — it is the natural result of putting the right data in the right tier.

Benefit	How It Works
Eliminate low-value ingestion	Identify and remove log sources that are never used for detections, investigations, or hunting. Immediately lowers analytics-tier costs without impacting security outcomes.
Right-size analytics rules	Disable unused rules, consolidate overlapping detections, and remove automation that does not reduce SOC effort. Pay only for processing that delivers measurable security value.
Avoid SIEM/XDR duplication	Many threats can be investigated directly in Defender XDR without duplicating telemetry into Sentinel. Stop re-ingesting data that Defender already provides.
Tier data by detection need	Store high-volume, hunt-oriented telemetry in the Data Lake at at least 20x lower cost. Promote only high-signal sources to the analytics tier. Full data fidelity preserved in both tiers.
Reduce operational overhead	Unified SIEM+XDR workflows in a single portal reduce tool switching, accelerate investigations, simplify analyst onboarding, and enable SOC teams to scale without proportional headcount increases.
Improve detection quality	The Defender correlation engine produces higher-fidelity incidents with fewer false positives. SOC teams spend less time triaging noise and more time on real threats.

Competitive Positioning

Partners need defensible talking points when customers evaluate third-party SIEM alternatives. The following advantages are factual, sourced from Microsoft’s transition documentation and platform capabilities — not marketing claims.

No extra cost for transitioning — even for non-E5 customers. Third-party SIEM migrations involve licensing, data migration, detection rewrite, and integration rebuild costs.
Native cross-domain correlation across Sentinel + Defender products into multi-stage incident graphs. Third-party SIEMs receive Microsoft logs as flat events — they lack the internal signal context, entity resolution, and product-specific intelligence that powers cross-domain correlation.
Custom detections across SIEM + XDR — query both Sentinel and Defender XDR tables without ingesting Defender data into Sentinel. Eliminates redundant ingestion cost.
Alert tuning extends to Sentinel — previously Defender-only capability, now applicable to Sentinel analytics rules. Net-new noise reduction.
Unified entity pages — consolidated user, device, and IP address pages with data from both Sentinel and Defender XDR, plus global search across SIEM and XDR. Third-party SIEMs provide entity views from ingested data only.
Built-in multi-tenancy for MSSPs — multitenant portal manages incidents, alerts, and hunting across tenants without third-party management layers. Try out the new GDAP capabilities in Defender portal.

Industry validation: Microsoft’s SIEM+XDR platform has been recognized as a Leader by both Forrester (Security Analytics Platforms, 2025) and Gartner (SIEM Magic Quadrant, 2025).

Summary: What Partners Should Take Away

Topic	Key Message
Framing	USX is a security architecture transformation, not a portal transition. Lead with detection capability, not cost savings.
Platform foundation	Sentinel Data Lake + Sentinel Graph + MCP/Agent Framework = the platform for the Agentic SOC.
4 investigation surfaces	KQL → Graph → Notebooks → Agent/MCP. A maturity ladder from “we can query” to “we automate at machine speed.”
Architecture	2-tier data model (analytics + Data Lake) with dual-ingest for critical sources. Cost savings are a side effect of good architecture.
Transition complexity	Analytics rules and automation rules. API schema changes. RBAC restructuring. Most customers need professional help.
Partner engagement model	Professional Services (transactional + transition execution + advisory) → Managed Services (MSSP).
Competitive positioning	No extra cost. Native correlation. Cross-domain detections. Built-in multi-tenancy. Capabilities third-party SIEMs cannot replicate.
Partner differentiation	IP + Human Orchestration + AI Agents. Partners who build proprietary agents on MCP have competitive advantage.
Timeline	March 31, 2027. Start now — phased transition with one telemetry domain first, then scale.

Introducing the New Microsoft Security Community Home!

emilyfalla — Tue, 21 Apr 2026 18:22:33 GMT

We are excited to introduce the new home of the Microsoft Security Community!

At aka.ms/securitycommunity, you can explore upcoming events, access technical content, and find new ways to connect with Microsoft experts and peers across the security ecosystem.

The Microsoft Security Community Home is designed to help you:

Discover live and on-demand community events
Access technical resources and learning opportunities
Connect with peers and Microsoft product teams
Stay up to date on Microsoft Security announcements
Get involved through our community programs, including opportunities to share feedback that helps shape Microsoft Security products and features

Whether you are looking to build your expertise, join discussions, or influence the future direction of Microsoft Security solutions, this is your starting point.

👉 Visit the Microsoft Security Community Home: aka.ms/securitycommunity

Safeguarding Sensitive Data in Microsoft 365 Copilot Interactions: DLP for Microsoft 365 Copilot

Aaron_Thorp — Tue, 21 Apr 2026 18:13:10 GMT

Microsoft 365 Copilot is redefining how organizations work, bringing the power of generative AI directly into our secure productivity tools. As Copilot adoption accelerates, we’ve heard that you want more control over how your sensitive data can be used in interactions with Copilot. At Ignite 2025, Microsoft announced a major enhancement: Microsoft Purview Data Loss Prevention for Microsoft 365 Copilot to safeguard Microsoft 365 Copilot and Copilot Chat prompts, now entering General Availability. Even better, this capability is included for all users of Microsoft 365 Copilot and Copilot Chat.

Why DLP for Copilot Prompts Is a Game-Changer

As organizations adopt Copilot, their ways of sharing, creating, and interacting with data expand. With just a prompt, users can have Copilot summarize documents, analyze spreadsheets, or help brainstorm presentations. However, it raises an important question: what if the prompt includes sensitive information, like project code names, financial account numbers, health records, or other sensitive data?

Over the last 2 years, Microsoft has been building a set of Data Loss Prevention (DLP) controls specifically designed for Copilot. Below is a quick overview of these related capabilities — ranging from already available to newly in preview — before we dive deep into today's GA announcement:

Prevent Copilot processing of files & emails based on sensitivity labels

In November 2024, Microsoft introduced the ability to create a DLP policy to restrict Microsoft 365 Copilot and Copilot Chat from processing sensitive files and emails using Sensitivity Labels for grounding data. This capability gives you control over whether content with the sensitivity labels you specify is restricted from being used in Microsoft 365 Copilot and Copilot Chat to generate summaries and responses.

Prevent web searches for prompts containing Sensitive Information Types (SITs)

The latest feature entering Public Preview is DLP for Microsoft 365 Copilot and Copilot Chat to prevent web searches for prompts containing sensitive data. This real-time control helps organizations mitigate data leakage and oversharing risks by preventing Microsoft 365 Copilot and agents from using sensitive data for external web searches. If a sensitive information type (SIT) is detected in a user prompt, Copilot can still leverage your enterprise data to form a response without sending the sensitive data to external search engines for web grounding. This capability extends to Microsoft 365 Copilot and agents built in Copilot Studio that are published to Microsoft 365 Copilot.

DLP to Safeguard Copilot Prompts with Sensitive Information Types (SITs)

The rest of this blog focuses on a key addition to this capability set: DLP for Microsoft 365 Copilot + Copilot Chat prompts to prevent processing of prompts containing sensitive information, now entering General Availability. Unlike the web search capability above, which prevents sensitive data from being sent externally during a web query, this capability evaluates the user’s text input directly, before processing occurs, to determine whether both enterprise data and web grounding can proceed.

This feature uses Sensitive Information Types (SITs) as a condition within a Purview DLP policy to assess whether a user prompt sent to Copilot contains sensitive data, even if the data is unlabeled. With DLP for Copilot prompts, a user’s text input is scanned in real time for SITs, whether built-in (like Social Security Numbers, credit card numbers, etc.) or custom-defined by your organization (such as confidential terms or project names). If a text prompt contains one of the SITs you specify, Copilot restricts processing, halts any Graph or web grounding, and displays a clear message to the end user that the request cannot be completed.

A user enters a prompt in Microsoft 365 Copilot Chat containing sensitive information.

Microsoft 365 Copilot Chat detects a SIT within the user prompt and restricts a response.

How DLP for Copilot Protects Prompts: Real-Time, Intelligent Protection

The new DLP capability integrates seamlessly with Microsoft Purview, leveraging its powerful data classification & detection engine for sensitive information types. Here’s how it works:

Input: When a user submits a prompt, Copilot checks the prompt for sensitive information using built-in or organization-defined sensitive information types (SITs).
Immediate Action: If a SIT is detected, Copilot restricts the prompt from being processed. No AI response is generated, and no data is sent for Graph or web grounding.
Output: Users receive a clear notification that their request cannot be completed due to company policies.

This real-time protection ensures that sensitive data is not leaked or overshared, even as users explore new ways to work with AI.

Overview of how the feature works.

Setting Up DLP for Copilot Prompts: Data Security Admin Experience

The easiest way to get started is through the new Microsoft Purview Data Security Posture Management (DSPM) portal, which provides a guided, one-click setup experience:

1. In Purview, go to Solutions > DSPM (preview)

2. Select the "Prevent data exposure in Microsoft 365 Copilot and Microsoft Copilot interactions" objective.

3. Follow the guided workflow and apply the recommended one-click DLP policy. The policy starts in simulation mode so you can review activity before enforcing it.

Alternatively, you can configure and customize this policy directly from the Purview DLP portal Policies page or enable it from the Microsoft 365 Admin Center.

Navigate to the Data Security Posture Management (Preview) portal Objectives tab. View the objective, “Prevent data exposure in Microsoft 365 Copilot and Microsoft Copilot interactions” and click the button, view the remediation plan.

View the remediation plan details and estimated impact on risk pattern.

Click the button, view policy details and review. Then click the button, create a custom policy in DLP simulation mode to protect sensitive data referenced in Microsoft 365 Copilot and Microsoft Copilot.

IT and AI admins can enable DLP protection for Copilot prompts directly from the Security section of the Microsoft 365 Admin Center using a simplified setup experience.

To configure polices in DLP, navigate to the Purview DLP portal. Then select the Policies tab to create a new policy.

Create a DLP Custom policy.

Choose where to apply the policy (Microsoft 365 Copilot and Copilot Chat).

Create a rule with a name and optional description.

Add Sensitive Information Types as part of the conditions.

Select the desired Sensitive Information Types (built-in or custom).

Identify the confidence level and instance count.

Add the action to restrict Copilot from processing content and complete the policy configuration.Confirm the rule was set up correctly by testing it out.

Practical Scenarios: Protecting What Matters Most

Protect PII, financial data, and intellectual property: Financial institutions can block prompts containing deal terms, account numbers, or other sensitive data, preventing leaks through AI interactions. Similarly, healthcare organizations can safeguard patient information, and manufacturers can secure intellectual property and trade secrets from exposure, along with many other practical use cases. Once the prompt is detected and blocked, Microsoft Graph grounding and Bing web grounding is restricted.

Safeguard sensitive non-public information: Imagine an organization involved in a confidential merger. By using DLP for Copilot prompts, administrators can set up a custom SIT that includes the project’s code name. If a user asks Copilot about the merger using the project’s code name, their request will be blocked, keeping sensitive information secure and protected.

Visibility into DLP for M365 Copilot Prompts

When a user’s prompt triggers a DLP policy, notifications and alerts are surfaced directly in the Microsoft Purview and Defender portals for security administrators. These alerts provide detailed information about which policy was activated, the type of sensitive information detected, and the context of the attempted Copilot interaction.

Using these alert queues in Purview and Defender XDR, administrators can efficiently track policy activity, investigate potential incidents, and refine DLP rules to better align with organizational needs. The ability to review historical alerts and track ongoing enforcement empowers admins to maintain strong data security and proactively safeguard sensitive information.

DLP policy alert within the Alerts page.

Defender XDR portal investigation of prompt DLP based incident.

Takeaways

The introduction of this latest enhancement to DLP for Copilot represents a key advancement in secure Copilot deployment and adoption. By empowering organizations to block sensitive data at the prompt level, Microsoft is helping customers unlock the full potential of Copilot, without compromising security or compliance.

This innovation reflects Microsoft’s commitment to responsible AI, continuous improvement, and customer-driven development. As Copilot evolves, so will the tools to protect your data, ensuring that productivity and security go hand in hand.

For more details, stay tuned for updates to the Product Roadmap and Learn documentation.