Microsoft Security Community Blog articles

Extend data security to the network with Microsoft Purview and Microsoft Entra

Vivian_Ma — Wed, 01 Jul 2026 16:00:00 GMT

Protection that keeps up with how data moves in the AI era

Enterprise data used to be easier to contain.

It lived in files, in apps you managed, within boundaries you controlled. Security teams could focus on endpoints and known systems, and that was often enough. That’s no longer the case.

Today, data travels constantly between trusted endpoints and unmanaged web apps, SaaS apps, and most critically, generative AI tools over the network. Employees type and paste sensitive information into prompts, upload work-related files to external services or personal cloud storage, and interact with systems that sit entirely outside the traditional enterprise perimeter. AI has expanded the risk surface for potential enterprise data loss.

That’s why Microsoft Purview and Microsoft Entra now integrate to extend data security to the network layer (available in public preview).

Traditional data loss prevention (DLP) approaches lack real-time visibility and enforcement, flagging incidents after data has already left the organization. In other cases, vendors rely heavily on physical network appliances that are complex and expensive to deploy, or compute resources that can add significant latency. In the era of AI, that model breaks down quickly.

Real-time data protection for how work happens today

To adapt to how enterprise data moves in the AI era, we’re announcing the extension of data security to the network layer, powered by Microsoft Purview and Microsoft Entra, now in public preview.

This integration brings together data context and identity-aware enforcement to help protect sensitive data in transit, in real time:

Detect how sensitive data is shared to shadow AI tools, unmanaged SaaS apps, and personal cloud repositories

Help block the sharing of sensitive data in real time based on identity, user activity, and data context, before data leakage occurs

Unify investigation workflows by correlating identity, data, and insider risk signals across Purview, Entra, and Defender

Figure 1: Prevent employees from sharing proprietary or sensitive organizational data to potentially risky locations such as consumer AI apps.

By combining Purview data classification, DLP policies, and insider risk detection with identity-aware enforcement at the network layer through Entra, organizations can dynamically apply protections based on:

The sensitivity of the data

Who the user is

How that user has interacted with sensitive data over time

Together, Purview and Entra enable a modern approach to data protection that follows the data to prevent leakage instead of relying on at-rest controls alone. Not only that, but the same Purview classification and policies that you already leverage for the rest of your enterprise data can now be applied consistently across data in motion, at rest, and in use.

Learn more in the detailed blog.

See the capabilities in action here.

Start your free trial of Purview Suite here.

Introducing a unified alert experience for Microsoft Purview Insider Risk Management

MSlotwinski — Tue, 30 Jun 2026 19:00:00 GMT

Modern insider risk investigations succeed or fail based on how quickly analysts can move from signal to decision with more context. Too often, investigations within Microsoft Purview require high switching costs while analysts struggle with disconnected alert views and scattered case notes across workflows. Every switch slows triage pulling focus away from the risk itself, decreasing the speed and confidence of investigations.

That’s why we’re unifying the Microsoft Purview Insider Risk Management investigation experience with three connected improvements — a unified alert queue, expanded user profile details, and notes across alerts and cases. Analysts can now triage, understand context, and capture their work in a streamlined investigation flow to help enable faster investigations and increase confidence. Here’s what’s coming to public preview in July 2026:

1. One unified alert queue integrating classic and agent workflows together

The most disruptive part of triage happens before analysts dig into any single alert: understanding what alerts require the most attention. Today, that means toggling between the classic alert queue and the Data Security Triage Agent’s insights. We’re now bringing them together into a single, unified alerts list.

Instead of switching between two experiences, analysts get one page where they can:

Preview agent summaries, alert details, and user details directly from the alerts list, reducing the need to open each alert individually.

Filter all classic and agent attributes on one page, including a new agent categorization column and the ability to surface agent-triaged alerts that need attention.

View and manage the agent directly from the alerts list.

Open or act on an alert with the ability to stay within the queue.

As part of this unification, alert spotlighting is being retired, and the toggle between agent and classic alerts is going away in favor of the single view. To give teams time to adjust, both the classic and new experiences will remain available for at least 60 days, with support for both currently planned through August 31, 2026. Explore the unified alert queue here → New IRM Alert Experience.

Launch details: Public preview: July 2026 | Roadmap ID: 564621

Figure 1: The unified IRM alerts list, showing inline agent summaries, the new Categorization column, and combined classic and agent filtering on a single page.

2. Expanded user profile details to better understand user risk

Once an alert has been raised, the next question is about the person behind it: Who are they, and how much risk does this really represent? Answering that used to mean piecing context together from multiple places.

The expanded user profile brings context into one unified view by:

Adding new signals from the user’s Entra profile including office location, employee type, department, and last working date.

Aggregating key insider risk signals in one place including Entra profile details, past alert and case history, priority user group status, and policy inclusion.

The result is a fuller, more detailed picture of users' risk, to provide investigators with more context for decisions without leaving the alert. See expanded user profile details here → New IRM Alert Experience

Where to find it: On the new Alerts (preview) tab — click Alerts (preview) in the left navigation, open an alert, scroll to User details, and select View user details. Note: when pseudo-anonymization is enabled, user profile details will not appear, preserving privacy by design.

Launch details: Public preview: July 2026 | Roadmap ID: 564619

Figure 2: The unified user details view, combining Entra profile signals with aggregated Insider Risk history and status.

3. Notes across alerts and cases keep context with the work

Investigation context shouldn’t live in someone’s memory or a side document. Analysts and investigators can now add and view notes directly in alerts and cases within the Purview portal, ensuring the story of an investigation stays with the investigation.

Notes come in two forms:

System-generated notes are applied automatically on key changes including alert or case status, assigned user, alert or case closure, and case escalations.

Analyst notes let investigators capture their own observations as they work

This gives teams continuity and a clearer record of investigation activity history without breaking stride.

Where to find it: In the Notes tab within the alert details panel, and within the Cases tab within a case. Start capturing notes across alerts and cases here→ New IRM Alert Experience

Launch details: Public preview: July 2026 | Roadmap ID: 564620

Figure 3: The Notes tab in the alert detail panel, showing both system-generated and analyst-added notes.

Ready to get started? Try the unified Insider Risk Management experience today: Click here to get started

Privacy Statement: 
Microsoft Purview Insider Risk Management correlates various signals to identify potential malicious or inadvertent insider risks, such as IP theft, data leakage, and security violations. Insider Risk Management enables customers to create policies to manage security and compliance. Built with privacy by design, users are pseudonymized by default, and role-based access controls and audit logs are in place to help ensure user-level privacy.

Understand your Sentinel tables at a glance: Monitor with table insights

NikitaChhabra — Mon, 29 Jun 2026 17:48:32 GMT

What it is

Table insights is a new panel on the Sentinel Tables page that gives you 30-day ingestion volume per tier, day-over-week fluctuations, the top 5 tables by volume, last-data-received per table, an estimated daily cost, and a volume anomaly indicator.

Who benefits: SOC engineers chasing silent data connectors, platform owners chasing cost spikes, FinOps teams chasing chargeback clarity — all from the same screen.

Why these matter

Every Sentinel customer I talk to has the same two recurring incidents.

"A third-party data connector stopped sending data three days ago and nobody noticed until a hunt came up empty."

Both incidents share a root cause: until now, table-level health lived in a workbook you had to remember to open, a Usage KQL you had to remember to write, or a SentinelHealth alert someone had to remember to configure. In a workspace with 500+ tables and a mix of Microsoft 1st-party data connectors, third-party data connectors, custom logs, and data-lake tables, that's a lot of remembering.

Table insights flips the model. It puts the answer on the same page where you already manage tiers and retention, so the next time you open the Tables page to right-size a Lake-tier table, the data connector that went silent at 3 a.m. is already staring at you.

Try it today

Open the Defender portal → Microsoft Sentinel → Configuration → Tables and expand the Table insights panel.

Figure 1: Table insights panel

What's new on the Tables page

Ingestion volume per tier - Analytics vs. Lake split for the last 30 days. The first time you see Lake tier exceeding Analytics, you'll know the data-lake migration is working.

Table ingestion fluctuations - tables whose last-24h volume differs from the same day last week beyond a threshold (default 10% and 1 MB).

Top 5 tables by daily ingestion volume - 30-day trend. The line that looks like a heart-rate monitor is the one your FinOps lead wants to talk about.

Last data received column – time of recency per table.

Volume anomaly column - signed percentage change versus baseline, right next to the table name.

Data sources – Click on table details to open side panels for data sources.

Who wins, and how

Persona	Pain today	Win with Table insights
SOC engineer	Detections silently degrade when a third-party data connector stops sending- you only notice when an incident is missed.	Spot the drop in "Last data received" or a -100% fluctuation before the next shift report.
Data Connector onboarding lead	"Did the new data connector light up?" takes a KQL query and a workbook hunt.	One glance at the Tables page confirms the destination table, tier, and last-received timestamp.

How I'd actually use it

Baseline- Open the Tables page, filter by Tier = Analytics, sort by Avg. daily ingestion descending.

Triage silent data connectors- Sort by Last data received ascending.

Tier review- For every table above a few GB/day with low SOC query usage, evaluate moving it to Auxiliary or Lake tier. The Est. daily ingestion cost column makes the business case for you.

Wire up alerts- Convert the fluctuations card into a scheduled analytics rule on SentinelHealth, so the next "-100%" row pages someone instead of waiting for the morning standup.

Share the screenshot- Drop the ingestion volume per tier card into your monthly business review.

Honest caveats

Fluctuations only compare the last 24h to the same day last week.

Cost numbers are estimates They're great for relative comparisons, not invoice forecasting.

Volume anomaly is most accurate on Analytics-tier tables today. Lake/Auxiliary anomalies will be catchup in features soon.

The grid shows the table; for third-party data connectors you'll still cross-reference the Tables-to-connectors mapping page to find the upstream data connector.

Table insights is a visualization. If you want to be paged, build the SentinelHealth analytics rule.

Resources

Manage data tiers and retention in Microsoft Sentinel

Monitor the health of your Microsoft Sentinel data connectors

Microsoft Sentinel health tables reference (SentinelHealth)

Microsoft Sentinel tables and associated connectors

Transform or customize data at ingestion time

The state of MCP security in 2026

JiteshThakur — Tue, 30 Jun 2026 16:43:45 GMT

Co-Author: ShalabhPradhan

A year ago we published Understanding and mitigating security risks in MCP implementations.

The core idea still holds: the moment a model can choose and call tools, it stops being a question-and-answer box and becomes software that acts. Anything that acts has a trust boundary, and tool descriptions, schemas, outputs, and credentials all sit inside it.

What has changed is scale. The Model Context Protocol has gone from a promising idea to the way agents connect to tools, data, and systems. Enterprises have stopped experimenting and started shipping into production. This post is a checkpoint: the main risks as they stand now, which of them have moved, and what good security looks like for each.

A specification that keeps moving

MCP is still evolving quickly, and the spec is revised on a regular cadence. The latest release candidate raises the security baseline in ways worth knowing.

Requests now carry what they need, so a gateway can inspect and enforce on every call rather than trust a hidden session. Identity checks between clients and servers are tighter. And a new MCP Apps capability lets a server ship interactive UI that the host renders inside a sandbox.

The protocol deliberately does not enforce security for you. It defines how clients and servers talk, and the rest is your responsibility. Treat "we reviewed MCP last year" as out of date, and revisit your assumptions with each release.

The main risks in 2026

Some of these are the risks we flagged last year. Some have shifted, and authorization in particular has been reworked. Each entry below covers the same three things: what the risk is, what happens if it is exploited, and the controls that help most.

Figure 1: MCP Security Overview

1. Prompt injection and tool poisoning

What it is: An agent treats everything in its context as trustworthy: tool descriptions, parameter schemas, and the data tools return. Anyone who can plant instructions in any of those can steer the agent. Tool poisoning is the sharp edge, malicious instructions hidden in a tool's description or schema that the model reads and the user usually does not.

What could happen: The agent follows the attacker's instructions instead of the user's. It might exfiltrate data through a tool call that looks legitimate, call the wrong tool, or take an action nobody approved.

Controls: Treat tool descriptions and outputs as untrusted input, and inspect the full schema before you approve a server. Put the tool list through a human approval step, and show the full tool call rather than a friendly summary. Keep sensitive servers isolated from general-purpose ones so a poisoned tool cannot reach across without further safeguards.

2. Authorization and the confused deputy

What it is: This is where the protocol moved most. MCP servers are now treated as OAuth 2.0 resource servers, and the guidance has settled on OAuth 2.1, PKCE, and tokens bound to a specific audience. The risk it targets is the confused deputy: a server acting with its own broad privileges on behalf of a user who does not have them, or a proxy that can be tricked into handing an attacker a valid authorization code.

What could happen: An attacker uses the server's privileges to reach data or actions the user was never entitled to, sometimes without the user approving anything.

Controls: Adopt the current authorization model: OAuth 2.1 with PKCE, per-client consent, strict redirect-URI matching, and audience-bound tokens, so a token issued for one server cannot be replayed against another. Put an identity-aware gateway in front of every server and reject any call that does not carry a valid, audience-bound token. Azure API Management can validate Microsoft Entra tokens and check issuer, audience, and expiry before the request reaches a tool.

Figure 2: Confused Deputy Problem

3. Over-broad access and credential aggregation

What it is: A single MCP server often holds credentials for several systems at once, and asks for wider scopes than it needs, such as full mailbox access where read-only would do.

What could happen: One compromised server, or one leaked token, becomes a breach path of every system it touches. Wide scope means a wide blast radius.

Controls: Apply least privilege, per resource: scoped, narrow OAuth scopes over wildcards; short-lived tokens over long-lived secrets. Give every agent an identity you can govern, like Microsoft Entra Agent ID, so you can apply policy to a whole class of agents or shut them down in one operation.

4. Supply chain and rug pulls

What it is: An MCP server is never just the server. It is the server, its dependencies, and the infrastructure it runs on, and each of those is a way in. A typo squatted package, a compromised dependency, or a change of ownership behind the same URL can all turn a trusted server hostile. Also, known as a 'rug pull' attack where a server behaves while it is being reviewed, earns approval, then changes once agents and workflows already depend on it.

What could happen: The server you approved is no longer the server you run. An ordinary tool call starts leaking its arguments, rewriting a response, or exfiltrating a token, and nothing about the request looks different from the thousands before it.

Controls: Approval cannot be a one-time event. Build a Secure By Design Registry and register every server in a design-time catalog so you have a known-good baseline, pin tool definitions and alert on drift so you have a tripwire for rug pulls, and route everything through a gateway that re-checks identity and policy on every call. Azure API Center inventories your APIs and MCP servers, and the OWASP MCP Top 10 mapped to Azure controls lines the risks up against what you already run.

Figure 3: Supply Chain- Rug Pull. The approved dependency remains trusted even after ownership, version, or behavior changes.

5. Shadow MCP

What it is: This is shadow IT for the AI era. A developer stands up a server to unblock a demo or get some work done quickly, a team wires an agent to whatever endpoint is handy, and nobody registers or verifies it.

What could happen: You cannot govern, patch, or revoke what you cannot see, and ungoverned servers are where supply chain problems tend to hide.

Controls: Start with visibility, of what exists, and a runtime gateway that everything routes through. The GSA AI Gateway helps you surface the unregistered, shadow servers you didn't know were running.

6. Command injection and sandbox escape

What it is: Many MCP servers run locally and talk over standard input/output, spawning subprocesses and touching the file system. If a server passes unsanitized input into a shell or a file path, you have command injection or path traversal, and that has been one of the largest classes of MCP vulnerabilities reported this year.

What could happen: Arbitrary code runs on the host, or a server reaches files and credentials well outside what it should, in the worst cases with no user approval at all.

Controls: Sandbox local servers in containers with only the file-system and network access they need, and block outbound traffic by default. Validate and sanitize every input and output, and never pass raw shell commands or unsanitized paths. Keep servers and SDKs patched, because this class of bug is being fixed in the field constantly.

Wrapping up

MCP has not changed what good security looks like, only where you need to apply it. The risks that matter most now sit at the supply chain, in identity, and in servers nobody verified, and the controls that address them are ones you already know: strong identity, least privilege, a gateway in front of every server, sandboxing for local servers, and an alert when an approved tool changes. The spec continues to keep improving, but it still leaves the security decisions to you.

If you would like to help improve the protocol, you can contribute to the specification here.

In the next part, we'll get practical: a hands-on guide to implementing these controls in depth, with the patterns and configurations you can put to work.

With thanks to Sarah_Young for their inputs and collaboration on this post.

Security Community Spotlight: Sathish Veerapandian

RenWoods — Thu, 25 Jun 2026 15:00:00 GMT

Meet Sathish Veerapandian: security architect, community collaborator, published author, and cycling enthusiast with a knack for turning real-world customer challenges into product-shaping feedback. From influencing phishing-resistant authentication and malware scanning improvements to helping organizations navigate Microsoft Purview, AI governance, and hybrid work, Sathish brings the best kind of energy to the Microsoft Security Community: curious, practical, generous, and always ready to help others move forward.

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

I find it most rewarding to be part of a community where knowledge sharing directly contributes to stronger, real world security outcomes. The Microsoft Security Community brings together practitioners, MVPs, engineers, and product teams, creating a space where collaboration leads to practical solutions, continuous learning, and meaningful impact. Being able to share experiences, learn from others, and help shape the direction of Microsoft Security technologies is what makes this community truly valuable to me.

I have tested and provided feedback on a wide range of products via the Security Advisors program. Some examples include extending FIDO support for on-premises environments; improving Microsoft Defender for Storage malware scanning with Sentinel integration, cost estimation, delta scanning, and scheduled scans; streamlining Microsoft Purview DSPM for AI onboarding and Insider Risk visibility; and strengthening Predictive Shielding by turning risk insights into preventive Conditional Access controls.

Overall, these examples reflect how I collaborate: identifying real-world gaps during implementation and operations, translating them into clear product feedback, and contributing in ways that help Microsoft engineering and the broader community.

Could you share something you’re proud of or a project you’ve completed?

One project I’m particularly proud of is co-authoring the book Reimagine Remote Working with Microsoft Teams with my community colleagues during the COVID pandemic. At that time, we saw a significant increase in questions from organizations on how to effectively utilize Microsoft Teams to enable efficient and productive remote work. Recognizing this need, we took the initiative to bring together our collective experience and authored the book as a team. Our main goal was to help organizations improve their collaboration. We came together as a team and shared our real-world experience.

Authoring this book also motivated my colleagues to become more interested in the Microsoft MVP Program and contributing to the Tech Community forums, which helped a lot of people.

Reimagine Remote Working with Microsoft Teams is available for public purchase and has been used by IT professionals, team leaders, and organizations looking to strengthen their hybrid work strategy. A copy of the book was also archived in the Microsoft Corporate Library in Redmond, which is a personal milestone and an honor as an MVP.

What does your ideal community experience look like?

My ideal community experience continues to be one where practitioners, MVPs, and product teams collaborate closely to share real- world insights, solve challenges together, and help shape the future of Microsoft Security. I value environments where knowledge flows openly, where hands- on learning is encouraged, and where community members can contribute through content, discussions, and events that have a meaningful impact on others.

How long have you been working with Microsoft Security Products?

My Microsoft Security journey began over a decade ago in the on- premises era, working with technologies such as Forefront, TMG, Exchange security, and Antispam solutions. Those early years gave me a deep foundation in securing Microsoft workloads at the infrastructure and perimeter level, long before cloud adoption became mainstream. As the industry shifted, I transitioned into the cloud security space, embracing Microsoft 365 and Azure security capabilities. This evolution led me to focus on data protection, identity, and modern collaboration security, eventually specializing in Microsoft Purview, Copilot DLP, Insider Risk, and Information Protection.

What features or products have provided the most impact?

The Microsoft Security products that have had the most impact for me are the ones that directly improve security outcomes while staying deployable at scale. The most impactful areas have been:

1) Microsoft Entra ID – FIDO / Passwordless (including on-prem considerations)

Impact: Enabling phishing-resistant authentication in a way that works for real enterprise environments (including hybrid setups).

Essential capability: FIDO/passwordless support that can extend into on-prem realities, so customers are not blocked by architecture constraints.

2) Microsoft Defender for Storage – On-demand Malware Scanning

Impact: Improving security assurance for storage data, especially during high-risk operational events like large-scale migrations.

Essential capabilities: More effective delta scanning and the ability to run scheduled or on-demand scans aligned to migration windows and operational needs.

3) Microsoft Purview – DSPM for AI

Impact: Supporting governance and security posture for AI-related data usage, with an experience that enables customers to adopt quickly.

Essential capability: A smoother enablement/onboarding experience so the subscription/capability can be activated reliably and used without friction.

4) Predictive Shielding + Conditional Access (preventive controls)

Impact: Turning risk insight into preventive action by applying controls through Conditional Access.

Essential capability: Preventive enforcement that helps stop risky access/behavior earlier rather than only detecting after the fact.

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

My advice is to simply start by sharing what you know. You don’t need to be an expert to contribute just be willing to help others, document your learnings, and stay curious. The Microsoft Community grows through collaboration, and even small contributions like answering questions, writing a short post, or sharing a demo can make a real impact. Engage consistently, connect with others who share your interests, and focus on adding value. Over time, those small steps build into meaningful involvement, strong relationships, and opportunities you never expected.

Tell us more about you, including where to find you!

Outside of technology, I’m very passionate about cycling. I run a local cycling community in Almere called the Almere Cycling Club, where we focus on improving the health and fitness of people through regular group rides and community activities. It’s something I truly enjoy because it brings people together, encourages a healthier lifestyle, and creates a positive impact in the place where I live.

Here’s where you can connect with me online:

YouTube: DevOpsInfo 391

LinkedIn: Sashtish Veerapandian

Website: https://ezcloudinfo.com

Purview Community Lightning Talk: From Zero to First Signal: Insider Risk Management Prerequisites That Actually Matter

Sathish’s story is a reminder that strong communities are built by people who show up with curiosity, generosity, and a willingness to turn real-world experience into shared progress. Whether he’s helping shape Microsoft Security products, guiding organizations through modern security challenges, or bringing people together through cycling, Sathish leads with purpose and impact- and the Microsoft Security Community is stronger because of it.

Learn and Engage with the Microsoft Security Community

Visit the Microsoft Security Community home.
Log in and follow this Microsoft Security Community Blog.

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

Subscribe to the Security Community Email List 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

How Karambit.AI and Microsoft Bring Software Authenticity to 14 Billion Files Per Month

AlecCheung — Wed, 24 Jun 2026 20:30:26 GMT

The Problem: Static Analysis Without Context

Traditional static analysis treats every file as an island. Scan a binary, match against known signatures, flag what you recognize. The approach is well-understood and increasingly insufficient against modern threats.

The fundamental limitation is the absence of context. Without it, a packer is just a packer. A network call is just a network call. An obfuscation routine is just an obfuscation routine. Whether that behavior is normal or anomalous, whether it belongs in this software, in this ecosystem, performing this function, is invisible to tools that evaluate files in isolation.

Attackers exploit this gap. They hide malicious behavior inside legitimate software patterns, evolve their techniques between versions, and distribute intent across multiple components so that no single artifact triggers a detection in a context-free scan.

Context-Aware Behavior Analysis

Context-aware analysis inverts the model. Instead of asking "is this file bad?" it asks: "is this file behaving the way it should, given everything we know about this ecosystem?"

This requires building and maintaining behavioral context across multiple dimensions:

Ecosystem-level behavioral baselines: Understanding what behaviors are normal across the entire corpus and which should never appear. In a trusted software ecosystem, obfuscated or packed content is itself an anomaly worth enforcing policy against, regardless of whether the underlying payload is known-malicious.
Behavioral chains with low false-positive rates: Individual API calls and instructions are ambiguous in isolation. Context-aware analysis identifies chains of behaviors, sequences where data staging feeds into exfiltration, or where privilege escalation is followed by persistence mechanisms, that reveal intent with high confidence.
Cross-file and cross-instance correlation: Behaviors observed in one file are evaluated against patterns seen across millions of other files and scan instances. Shared behavioral fingerprints reveal family relationships, evolutionary lineage, and coordinated campaigns that single-file analysis cannot surface.
Historical behavioral deltas: What changed between version N and version N+1? New behaviors in an update, especially behaviors that don't correspond to documented changes, are flagged not because they match a signature, but because they deviate from the established behavioral profile.

The result: dramatically higher detection confidence, lower false-positive rates, and the ability to enforce behavioral policy at the ecosystem level.

Case Study: Packer_Dictator, Behavioral Detection Under Adversary Adaptation

Adversaries must change their Tactics, Techniques, and Procedures (TTPs) over time. When a detection capability catches them, they adapt to evade it. This is expected behavior and it is precisely why general detections at the behavior level are more durable than signature-based approaches. Behavioral patterns are fundamentally harder for adversaries to change without breaking their own tooling.

The packer family tracked as packer_dictator illustrates this dynamic clearly.

Initial Detection: Obvious Indicators

Early variants of packer_dictator used conspicuous binary section names: authoritarian and politically-themed strings that made identification straightforward for anyone examining the PE headers. These were low-hanging indicators, but Karambit.AI's detection wasn't built on them. The system flagged these samples based on their behavioral profile: the entropy characteristics of their packed sections, the structure of their unpacker initialization routines, and the other patterns used to unpack and execute hidden payloads.

Adversary Adaptation: Surface Changes, Persistent Behavior

As detections rolled out, the users of this packer had to adapted. The obvious section names disappeared, replaced by more benign alternatives: .upx0, standard "unpacked" section names, and other strings designed to blend in with legitimate software.

But the underlying behavior didn't change because it couldn't, not without fundamentally rearchitecting the packer itself.

Entropy Analysis: Seeing Through Surface Changes

Sliding-window entropy analysis reveals why surface-level changes are insufficient to evade behavioral detection. The entropy profiles of packer_dictator samples, even after the section name changes, maintain a characteristic signature:

Figure 1: fancontroller.sys sample entropy sliding windowFigure 2: packer_dictator sample entropy sliding window

Both profiles exhibit the same structural pattern: a low-entropy region corresponding to the unpacker stub, followed by a sharp transition to a high-entropy plateau spanning the packed payload. This entropy profile is indicative of hidden behaviors, content that has been deliberately obscured, though not necessarily malicious content on its own. The profile shape, transition points, and entropy floor/ceiling ratios form a behavioral fingerprint that persists across variants regardless of metadata changes.

Unpacker Initialization: Common Structure Enables Generalized Detection

At the disassembly level, packer_dictator variants share a common unpacker initialization sequence that enables generalized analysis across the family. Examining the entry-point code of two samples reveals the structural similarity:

Figure 3: Sample 1 disassemblyFigure 4: Sample 2 disassembly

Both samples exhibit a characteristic pattern:

Register preservation: PUSH R9/PUSH R11 followed by PUSHFQ to save register state and flags before the unpack routine modifies them.
Immediate constant loading: Large immediate values loaded into registers (MOV R9, 0x689f8c87eebd998c / MOV R11, 0x6592b8afc22b0736) that serve as decryption keys or XOR masks for the unpacking routine.
Arithmetic flag manipulation: Sequences of TEST, NEG, OR, CMP, NOT, and SETNS instructions that compute control flow decisions based on the loaded constants — a form of opaque predicate that obscures the true branch target.
Stack-based payload resolution: MOV instructions referencing [RSP + local_120] / [RSP + 0x8] with additional immediate constants written to the stack, setting up parameters for the decompression/decryption loop.

The structural template is consistent even as the specific constants, register assignments, and opaque predicate formulations change between variants. This is what makes behavioral detection durable: the adversary can rotate constants and rename sections, but the computational structure required to unpack the payload is constrained by the packer's architecture.

By generalizing detection to this structural level, Karambit.AI's engine identifies new packer_dictator variants, and structurally related packer families, without requiring signature updates for each iteration. And this is only one example of the resilience of Karambit.AI’s resilience in the face of constantly advancing adversaries.

From Karambyte to Karambiner: Engineering for Billions

Karambyte: Building the Context

Karambyte was Karambit.AI's original analysis engine, purpose-built for deep behavioral extraction from compiled binaries. Its core function was to extract behavioral context, disassemble control flow, API call chains, entropy profiles, packer identification, behavioral intent classification, and store it for comparison and reference.

Karambyte proved the model. It demonstrated that context-aware behavioral analysis could identify threats that traditional static analysis missed, by building rich behavioral profiles and comparing them across software versions and file populations. The system extracted context and maintained it internally, enabling the cross-file and cross-version correlation that drove detections like packer_dictator.

But Karambyte's architecture, extracting and storing context within the same system, created a scaling constraint. As adoption grew and the target moved from hundreds of thousands to billions of files per month, the tight coupling between analysis and context storage became the bottleneck.

Karambiner: Externalizing Context for Scale

Karambiner re-architected the relationship between analysis and context. Rather than each analysis instance maintaining its own behavioral context store, Karambiner externalized the context layer into a dedicated reference that can then be customized for the specific organizational context.

This separation enabled three critical capabilities at scale:

Horizontal analysis throughput: Analysis scales independently of the context store. Adding processing capacity doesn't require replicating the full behavioral knowledge base.
Context enrichment: Behavioral context extracted from collective scans can be used in the massively scalable analysis engine.
Ecosystem-wide policy enforcement: With externalized behavioral context, the system can enforce policies across a large-scale ecosystem, such as blocking all obfuscated or packed content.

The move from Karambyte to Karambiner was the architectural shift that made scanning of 14 billion files per month possible: a configurable depth of behavioral analysis, with context that scales to the size of the ecosystem rather than the capacity of individual analysis nodes.

The Result: Software Behavior Analysis in Microsoft's Pipeline

Today, Karambiner is integrated into Microsoft's operational pipeline for build/release and plays a critical role in performing context-aware behavioral analysis across billions of files monthly.

The operational impact:

Ecosystem-level behavioral policy enforcement: Obfuscated and packed content that has no legitimate reason to exist in the ecosystem is blocked by policy, informed by the scaled behavioral analysis.
Durable detection under adversary adaptation: The packer_dictator lineage demonstrates that behavioral detection survives TTP changes that defeat signature-based approaches. Adversaries can change section names, rotate constants, and vary metadata, but the structural behaviors required to execute their payloads remain detectable.
Low false-positive rates at scale: Because detection decisions are driven by behavioral understanding and optimizing for scale, the system maintains precision even at 14 billion files per month.
Understanding AI capabilities: Behavior analysis can include understanding of where and how AI is used in an ecosystem.
Deep understanding of the software going to production: Developers don't always know what components and behaviors make it to the production software, behavior analysis has allowed us to catch unexpected components developers didn’t realize were going to deployment.

What's Next

The partnership between Karambit.AI and Microsoft demonstrates that context-aware behavior analysis operates on a massive scale in production. As software supply chain attacks grow more sophisticated and adversaries continue evolving their TTPs and the use of AI agents to develop code, the ability to understand what software actually does, in context, across billions of files, is foundational infrastructure.

Software authenticity isn't about checking a signature or trusting a certificate. It's about confirming that every binary does what it should, and nothing more.

Karambit.AI is the software authenticity platform, ensuring software does only what the developer intended — nothing more. Learn more at karambit.ai.

Microsoft Leads a New Era of Software Supply Chain Transparency

ShubhraS — Mon, 22 Jun 2026 18:01:03 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 blockchain 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

Sudarshan_J — 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.

Microsoft Security Community Blog articles

Extend data security to the network with Microsoft Purview and Microsoft Entra

Protection that keeps up with how data moves in the AI era

Real-time data protection for how work happens today

Introducing a unified alert experience for Microsoft Purview Insider Risk Management

2. Expanded user profile details to better understand user risk

3. Notes across alerts and cases keep context with the work

Ready to get started? Try the unified Insider Risk Management experience today: Click here to get started

Understand your Sentinel tables at a glance: Monitor with table insights

What it is

Why these matter

Try it today

What's new on the Tables page

Who wins, and how

How I'd actually use it

Honest caveats

Resources

The state of MCP security in 2026

A specification that keeps moving

The main risks in 2026

1. Prompt injection and tool poisoning

2. Authorization and the confused deputy

3. Over-broad access and credential aggregation

4. Supply chain and rug pulls

5. Shadow MCP

6. Command injection and sandbox escape

Wrapping up

Security Community Spotlight: Sathish Veerapandian

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

Could you share something you’re proud of or a project you’ve completed?

What does your ideal community experience look like?

How long have you been working with Microsoft Security Products?

What features or products have provided the most impact?

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

Tell us more about you, including where to find you!

Learn and Engage with the Microsoft Security Community

How Karambit.AI and Microsoft Bring Software Authenticity to 14 Billion Files Per Month

The Problem: Static Analysis Without Context

Context-Aware Behavior Analysis

Case Study: Packer_Dictator, Behavioral Detection Under Adversary Adaptation

Initial Detection: Obvious Indicators

Adversary Adaptation: Surface Changes, Persistent Behavior

Entropy Analysis: Seeing Through Surface Changes

Unpacker Initialization: Common Structure Enables Generalized Detection

From Karambyte to Karambiner: Engineering for Billions

Karambyte: Building the Context

Karambiner: Externalizing Context for Scale

The Result: Software Behavior Analysis in Microsoft's Pipeline

What's Next

Microsoft Leads a New Era of Software Supply Chain Transparency

Key Benefits of Microsoft’s Signing Transparency (MST)

Next Steps

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

Background: IPM vs. Non-IPM Subtree

The Audit Gap This Addresses

What's New

How to Query for These Records

Understanding the CopyFromIPM Audit Record

Feedback

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

Upcoming Events

Azure WAF Layer 7 DDoS defense in practice

Azure Firewall IDPS Detections and Sentinel Integration

What's New in Azure Bastion

What's New in Azure Firewall

What's New in Azure Web Application Firewall

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

A new class of risk: when agents run locally

A secure agent operating environment

Observe: discover and understand local agents

Secure: contain and enforce local agent actions

Execution environment: control agent behavior by design

Runtime: enforce controls as agents act

Govern: sustain control with policy and audit

From unmanaged claws to secure and governed agents

Enabling agentic AI with confidence

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

Extending data security and compliance to local agents and claws

Strengthening visibility and controls for Foundry agents

Innovating for developers everywhere, at the pace of AI growth

What features or products have provided the most impact?