Microsoft Security Community Blog articles

The Microsoft AI and Agent Platform — The Platform Behind Intelligent Agents

lmurthy — Wed, 29 Jul 2026 18:05:42 GMT

Why the platform around the model is the real enterprise differentiator

Enterprise AI has reached a turning point. Beyond answering questions, it can now reason over business context, retrieve knowledge, use tools, coordinate workflows, and act across enterprise systems. This shift raises a critical question: How can organizations build agents intelligent enough to transform work while ensuring they remain trusted, governed, and ready to operate at enterprise scale?

The answer is not a single model, chatbot, or orchestration framework. Foundation models are advancing quickly and increasingly becoming a commodity input — Azure AI Foundry alone provides access to more than 11,000 models. What determines enterprise value is not the model alone, but the platform around the model: the data that grounds it, the tools it can use, the experiences where people engage it, the runtime where it operates, and the enterprise foundation that gives it identity, context, governance, and operational control.

The Microsoft AI and Agent platform enables organizations to build, ground, govern, and operate AI apps and agents at scale, bringing together the full agent lifecycle with open development, built-in intelligence, and consistent security, compliance, and policy controls. One ecosystem, multiple experiences, shared intelligence, flexible build paths, multiple runtime choices, and an enterprise foundation that carries security, governance, compliance, and Responsible AI across the stack.

The reference mental model below expresses this as a layered platform — Users → Experiences → Agents → Intelligence → Runtime → Foundation with security, governance, compliance, and Responsible AI applied across every layer.

An agent that is brilliant but ungoverned never leaves the pilot stage. An agent that is locked down but context-blind never delivers real value. Impact compounds only when both dimensions advance together, on the same platform, so that intelligence and control share one identity model, one data plane, and one control plane.

Part 1 — Intelligence (this post): dives into how Microsoft's platform helps organizations build agents that understand work, reason over trusted context, and act through business systems to deliver real business value.
Part 2 — Trust: will go deeper on how those agents are secured, governed, monitored, and managed across their lifecycle.

Intelligence + Trust = Frontier Transformation

Part 1: Intelligence

Most enterprise AI programs begin with model experimentation - prompts, model comparisons, prototypes, accuracy evaluations. That is necessary but not sufficient. A model alone does not know your organization, your processes, your permissions, your systems of record, your compliance obligations, or your operating model.

Experience layer: meet users where work already happens

Agents deliver value only when they reach people in the flow of work.

Enterprise AI adoption rarely happens through a single interface or experience. A sales leader, financial analyst, security operator, developer, field technician, and HR specialist do not need the same interface they need agents surfaced in the tools and workflows they already use.

Microsoft's approach is not to force every agent into one portal. The platform supports multiple experiences over a shared foundation:

Microsoft 365 Copilot for productivity and business users.
Security Copilot for security operations.
Azure Copilot for IT operations, cloud, and infrastructure.
GitHub Copilot for developers.
Dynamics 365 experiences for sales, service, finance, and supply chain workflows.
Power Platform and Copilot Studio experiences for business applications and low-code extensions.
Custom experiences for line-of-business apps, portals, websites, and industry-specific workflows.

Regardless of where users engage, the underlying intelligence, governance, and runtime capabilities remain consistent across experiences.

Agent layer: specialize by domain, tools, and autonomy

Specialization with a shared substrate

Generic agents often fail because enterprise work is domain specific. A security agent must understand incidents, alerts, identities, and threat intelligence. A finance agent must understand reconciliations, receivables, approvals, and controls. A developer agent must understand repositories, branches, pull requests, tests, and pipelines.

Microsoft's platform supports both prebuilt domain agents and custom agents. Organizations should leverage the domain specific agents where possible and focus custom development on capabilities that create unique business value. Whether an agent is out of the box or custom, it inherits the same governance, so built-in and custom are never two different compliance islands.

Agent systems form an autonomy spectrum, allowing organizations to progressively increase capability while maintaining appropriate levels of human oversight.

Assistive: The agent recommends; a human decides. Example - A finance agent drafts a reconciliation for review.
Supervised autonomy: the agent acts within bounded authority and escalates exceptions. Example - An SRE agent auto-remediates known alert classes and escalates novel incidents.
Multi-agent orchestration: A coordinating agent decomposes a goal and delegates to specialist agents. Example - One agent retrieves data, another analyzes it, another drafts a response, and another executes an approved action.

Intelligence layer: grounding as a first-class platform tier

An agent is only as good as the context it can reason over.

The hardest part of building a useful enterprise agent is not calling a model. It is giving the agent the right context. Without trusted context, agents produce generic answers. The IQ Platform is the intelligence fabric that separates enterprise-grade agents from generic AI assistants. A generic model can answer questions based on its training data or a narrow retrieval source. A Microsoft agent, by contrast, can be grounded in multiple dimensions of your organizational intelligence: how people work, what business data means, which knowledge is authoritative, and what external signals matter. With the right intelligence fabric, agents become role-aware, process-aware, data-aware, and policy-aware. Microsoft's IQ model treats grounding as a reusable platform capability rather than per-project plumbing.

IQ layer	What it gives agents	Why it matters
Work IQ	Collaboration context: people, skills, meetings, documents, decisions, workflows, and organizational relationships.	Helps agents understand how work actually happens, not just what content exists.
Fabric IQ	Governed business data, metrics, semantic models, and analytical context.	Helps agents reason over trusted enterprise data with consistent business definitions.
Foundry IQ	Models, curated knowledge, retrieval assets, memory, guardrails, and AI development capabilities delivered from Microsoft Foundry with plug-and-play memory, knowledge, and tool integrations.	Helps teams build reliable, purpose-built agents with governed model and knowledge choices.
Web IQ	Public web, current external signals, research, news, and external context.	Helps agents augment internal context with timely external intelligence.

In a conventional application, data access is deterministic queries against known schemas. In an agentic system, the equivalent tier must serve retrieval for reasoning, semantically matching an ambiguous natural-language intent to the right passages, records, and metrics across unstructured collaboration content, structured business data, curated knowledge, and the live web. The four IQ sources correspond to those four retrieval modalities, and the IQ Platform gives agents a composable intelligence model. Each IQ layer adds a distinct signal, and together they allow agents to move from simple assistance to informed action.

Intelligence is more than model capability. It emerges from the combination of grounding, memory, model selection, orchestration, and guardrails working together as a coordinated system.

Grounding, fine-tuning, and adaptation

Microsoft gives teams multiple adaptation levers within a governed environment rather than forcing every use case into one technique. Grounding is not a sidecar retrieval capability; it is an enterprise intelligence layer. Because the model layer is a platform tier rather than a single endpoint, adaptation techniques fine-tuning, distillation into smaller task models, and retrieval-augmented grounding are first-class options selected per workload. The common pattern: prefer grounding (RAG) for freshness and provenance, reserve fine-tuning for durable behavior, format, or domain-tone requirements, and distill to smaller models where latency and cost dominate.

Memory

In addition to retrieval and reasoning, enterprise agents increasingly rely on memory to preserve context across conversations, tasks, and workflows. Memory enables agents to maintain continuity, learn from prior interactions, and provide more personalized, adaptive, and goal-oriented experiences over time.

Multi-model choice

Agent workloads are not uniform. Some steps require simple classification. Others require complex reasoning, synthesis, code generation, or tool orchestration. Model choice is becoming a strategic architecture decision, balancing quality, latency, cost, sovereignty, and specialization requirements. Microsoft Foundry supports model choice as part of the platform rather than forcing all workloads through one endpoint with a curated catalog of leading foundation, open-source, and partner models spanning capabilities, performance trade-offs, and use cases so teams can move from experimentation to production confidently.

Model routing

Microsoft Foundry's Model Router selects the optimal LLM for each agent request per turn, not per session — a simple greeting can route to a fast, inexpensive model, while a complex tool-calling chain can route to a frontier model, all through one endpoint with zero routing logic. Model selection becomes a runtime policy, not hard-coded application logic providing automatic failover when an upstream provider is unavailable, prompt caching across models for identical inputs, and consistent tool-use semantics regardless of which underlying model handles a call. Key routing capabilities include per-request optimization, complexity-aware model selection, tool-aware routing, multi-agent support, resiliency, and cost optimization.

Orchestration

Orchestration transforms individual model interactions into coordinated agentic and multi-agent workflows. An LLM-driven planning layer that interprets user intent, breaks down complex requests, selects the right tools and knowledge, and executes multi-step plans and multi-agent workflows with guardrails for safety and compliance.

Guardrails

A guardrail is a named collection of controls; each control defines a risk to be detected, intervention points to scan the risk, and the response action to take when the risk is detected. Guardrails help ensure that agent behavior remains aligned with organizational policies, safety requirements, and business objectives.

How agents are built: one continuum from no-code to pro-code

Different builders. Different depth. One platform.

The progression from no-code to low-code to pro-code is more than a tooling choice; it reflects increasing levels of customization, control, and organizational maturity. Different teams need different levels of control. A business user may need a simple knowledge agent. A process owner may need a workflow agent with connectors and approvals. An engineering team may need a custom multi-agent system with model routing, evaluation, tool use, and deployment automation. Organizations can start with simple productivity agents, evolve into governed workflow agents, and eventually build deeply integrated agentic systems.

No-code - M365 Agent Builder: create simple agents from natural language and your organizational data. This is useful for lightweight departmental workflows, knowledge assistants, and task-specific copilots.
Low-code - Copilot Studio: design, extend, and orchestrate agents with connectors, workflows, and enterprise governance. This is where business technologists and app makers can build more sophisticated agents that integrate with systems, automate processes, and enforce organizational rules.
Pro-code - Microsoft Foundry: enables developers to build custom AI systems with full control over models, orchestration, infrastructure, and code. This is where organizations can build highly specialized agents with advanced reasoning patterns, custom retrieval, tool use, evaluation pipelines, and deployment strategies.

The key principle is continuity; moving from no-code to low-code to pro-code should not require rethinking the architecture. Identity, grounding, governance, policy, and operational controls should carry forward including centralized identity and policy enforcement. Regardless of the development approach, the same intelligence, runtime, governance, and operational capabilities can be reused across the platform.

Where agents run: one platform, multiple runtime choices

Match the runtime to the requirement

A mature enterprise platform must support more than one runtime pattern. Some agents need elastic cloud scale. Others need local execution because of latency, data sensitivity, offline operation, or regulated environments. Some need to interact with legacy applications that do not expose APIs. Runtime should be selected based on business, operational, and regulatory requirements rather than tooling limitations. Build path and runtime path should vary independently over a shared foundation.

The ability to deploy the same agent architecture across multiple runtime environments helps organizations balance performance, compliance, and operational flexibility.

Local / edge (Foundry Local, Windows AI): Local or edge execution supports scenarios where data sensitivity, latency, offline access, regulatory requirements, disconnected operation or device-specific context matter. Examples include on-device models, Windows AI capabilities, and local execution for regulated or disconnected environments.
Cloud runtime (Azure / Copilot stack): supports scalable, API-driven agents with multi-agent orchestration running in Azure and Copilot with the default for enterprise workflows, multi-agent orchestration, connected systems, and data-connected scenarios that need elasticity.
Cloud PC (Windows 365 agents): enables agents to operate in managed desktop environments. agents run on a Windows 365 Cloud PC using a check-out/check-in model, driving UI automation, browsers, and legacy apps as a human operator would in a managed and governed environment. This is the bridge to systems that expose no API, the agent operates the actual application UI in a governed, isolated desktop.

Foundation layer: shared trust fabric

The enterprise foundation for intelligence and trust

The same enterprise services that secure, govern, and operate modern organizations now extend to agents, creating a shared foundation for both intelligence and trust. This inheritance model allows organizations to extend existing investments in identity, governance, security, compliance, and operations directly to agent systems rather than introducing a separate control model for AI. Key foundation services include:

Microsoft Graph – Provides agents the context across users, groups, files, meetings, messages, relationships, and activity signals. It gives agents a permission-aware understanding of work, not just isolated documents.
Microsoft Entra – Agents are governed using the same identity fabric that governs users, devices, apps, and resources enabling role-based and attribute-based access control plus risk-based Conditional Access policies.
Microsoft Fabric - Governed data, analytics, semantic models, and business metrics. Foundry includes SharePoint and Microsoft Fabric among its built-in tools. Agents reason over trusted business definitions instead of disconnected raw tables.
Microsoft Purview - Data protection, sensitivity labeling, DLP, compliance, and governance. Agent 365 uses Microsoft Purview for data protection and compliance controls on agent activity and data, complementing Microsoft Defender for threat detection and behavior monitoring. Agent interactions inherit enterprise compliance expectations.
Azure - Provides enterprise-grade cloud infrastructure and operational maturity. Foundry emphasizes centralized observability, traces, evaluated runs, and production performance monitoring with full traceability for enterprise-scale security, audit, and compliance requirements.
Microsoft 365 - Brings agents into the tools where employees already work. Agents can be surfaced in the productivity tools users already leverage.
Dynamics 365 - Business application context for sales, service, finance, supply chain, and operations. Grounds agents in business processes and systems of record.
Power Platform - Low-code apps, automation, connectors, and business process integration — reachable via Foundry through Azure Logic Apps integration with more than 1,400 connectors. Business technologists can extend agent workflows without building everything in code.
GitHub - Developer workflows, repositories, pull requests, code context, and DevOps integration. Extends agentic assistance into software development lifecycle.
Windows & Windows 365 - Endpoint and Cloud PC environments for local, desktop, and legacy app scenarios. Extends agent reach beyond APIs into managed desktop execution patterns.

Alongside these services, Agent 365 and the Foundry Control Plane provide the trust layer for enterprise agents, combining security, governance, compliance, and Responsible AI with centralized visibility, policy enforcement, lifecycle management, and secure AI operations from development through production.

End-to-end request journey: how the layers work together

The true value of the platform emerges when all the layers work together as a coordinated system. Intelligence emerges from the combined effect of experience, domain specialization, grounding, memory, models, orchestration, runtime, and foundation. An example request, from a user - “Reconcile last month's receivables and flag anomalies for my region."

Experience - The user asks from Microsoft 365 Copilot or a finance workflow surface, the agent is reached through the same stable endpoint used across Microsoft 365 and Teams.
Identity context - The platform attaches user identity, and, for the agent, its Microsoft Entra Agent ID assigned in Foundry.
Agent selection - A finance agent interprets the goal. If the request spans domains, Copilot Studio generative orchestration decomposes it into a plan, choosing tools, topics, knowledge sources, or connected agents.
Grounding - Fabric IQ provides receivables data and metric definitions; Work IQ provides relevant approvals and prior decisions; Foundry IQ provides reconciliation rules and policy knowledge; Web IQ can add external signals when needed.
Model routing - The Foundry Model Router selects the model per turn. A simple classification step goes to a nano-tier model; anomaly reasoning routes to a mid-tier model; multi-document synthesis routes to a frontier model, all through one endpoint with zero routing logic.
Guardrails - Foundry guardrails scan user input, tool calls, tool responses, and final output for defined risks and take the configured action (annotate or annotate-and-block).
Tool use - The agent queries systems, invokes reconciliation logic, runs anomaly detection, or calls another specialist agent via Copilot Studio connected agents or Foundry's MCP integration.
Runtime execution - The workflow runs in cloud, local, or Windows 365 Cloud PC environments depending on system access, data sensitivity, latency, and legacy application constraints.
Response - The agent returns a reconciled view, flagged anomalies, rationale, and recommended next steps — with citations pulled from the knowledge layer for transparency.
Bridge to Trust - Every action generated by the agent remains observable, governable, and auditable through the platform's trust capabilities, which are explored further in Part 2.

Conclusion

The hard problem in enterprise AI was never obtaining a capable model; it was grounding that model in governed enterprise context, enabling it to act through governed tools, and doing so within the security, compliance, and operational controls organizations already rely on. Microsoft's answer is a platform approach: a dedicated grounding tier through the IQ Platform, a flexible intelligence layer spanning models, memory, routing, orchestration, and guardrails, specialized agent families aligned to business domains, a build-to-run continuum spanning no-code to pro-code, and a shared trust foundation that every agent inherits.

Integrate once with this fabric, and the payoff compounds: one identity model, one grounding tier, and one governance spine become reusable across every persona surface, every agent family, every build-and-run target.

Coming next — Part 2: Trust

Intelligence is only half the equation. In Part 2 we turn to the other axis: how Microsoft secures and governs every component of an agent - models, tools, MCP connectors, memory, and orchestration across the full lifecycle.

Securing AI Agents at Runtime: Real-Time Protection and Threat Detection for Microsoft Agent 365

llevy — Mon, 27 Jul 2026 17:37:49 GMT

Organizations are rapidly adopting AI agents to automate workflows, access enterprise data, invoke tools, and take actions on behalf of users. This autonomy creates a fundamentally new security challenge.

Unlike traditional AI applications, agents operate across dynamic execution flows, interacting with external content, calling tools, and accessing sensitive resources. These interactions create new attack paths that traditional security controls were not designed to address.

Today, we're announcing two major milestones for Security for AI in Microsoft Defender for Microsoft Agent 365:

Threat detection for Microsoft Agent 365 agents — now in public preview.

Real-time protection for Microsoft Agent 365 tooling servers — now generally available.

Together, these capabilities help security teams detect, investigate, and block attacks targeting AI agents, extending Microsoft Defender's threat protection capabilities into the agent runtime.

Threat detection for Microsoft Agent 365 Agents (Public Preview)

Threat detection provides SOC teams with detailed visibility into attacks and suspicious activity targeting AI agents. By analyzing runtime signals across agent interactions, tool usage, and execution patterns, Microsoft Defender identifies suspicious and malicious behavior throughout the agent execution lifecycle and surfaces actionable security alerts for SOC teams.

Threat detection supports cloud agent types that emit observability logs to Microsoft Agent 365, including:

Microsoft Copilot Studio

Microsoft Foundry

Microsoft 365 Copilot Agent Builder

Agents integrated through the Microsoft Agent 365 SDK

This provides consistent threat visibility across supported Microsoft Agent 365 agent experiences, regardless of how the agent was built.

Fig. 1. Microsoft Security for AI alerts in Microsoft Defender XDR (Preview)

Microsoft Defender identifies a broad range of AI-specific threats, including:

Indirect prompt injection (XPIA) — malicious instructions embedded in external content designed to manipulate agent behavior.

Evasion techniques — attempts to bypass agent instructions or security controls.

Malicious content propagation — attempts to use agents to generate or distribute malicious content.

Secret leakage — exposure of credentials, API keys, or other sensitive information through agent interactions.

LLM reconnaissance — attempts to probe agent capabilities, instructions, or security boundaries.

Suspicious IP access — agent access originating from anonymized or suspicious IP addresses.

Alerts are surfaced directly in Microsoft Defender, enabling SOC analysts to investigate and respond using familiar workflows, Advanced Hunting queries, and the Defender XDR investigation experience.

Real-time protection for WorkIQ and Custom MCP servers (General Availability)

Real-time protection moves beyond detection by blocking threats inline when AI agents interact with WorkIQ and custom MCP servers (see Microsoft Agent 365 tooling servers).

When an agent invokes a registered tool or receives a tool response, Defender evaluates the interaction against configured security policies and determines whether to allow or block it directly within the agent's execution flow.

This helps prevent malicious actions and data leakage in real time, without requiring agent developers to implement custom security logic.

Fig. 2. Microsoft Security for AI Real-Time Protection policy in Defender

Real-time protection currently guards against high-impact threats, including:

Evasion techniques — attempts to bypass agent guardrails or security controls.

Malicious content propagation — preventing agents from spreading malicious content through tool actions.

Secret leakage — blocking agents from inadvertently exposing credentials or sensitive data through tool calls.

Communication with untrusted domains — preventing agents from sending email or data to high-risk or untrusted email domains.

Better Together: Detection and Protection

Threat detection and real-time protection address complementary parts of the agent security lifecycle.

Real-time protection provides inline enforcement to block malicious interactions during execution, while threat detection gives SOC teams the visibility and investigation context needed to identify attack patterns, assess impact, and respond to suspicious activity.

Together, they provide a defense-in-depth approach that combines runtime enforcement with SOC-driven detection and investigation, purpose-built for AI agents.

Getting Started

Both capabilities are available through Microsoft Defender, using a dedicated Security for AI workload experience that brings together AI threat detections, investigations, and runtime protection policies.

To learn more:

Enable security for AI agents using Microsoft Defender

Detect and investigate threats to AI agents using Microsoft Defender (Preview)

Protect AI agents in real time using Microsoft Defender

As AI agents become more autonomous and gain access to enterprise data and tools, securing their runtime behavior becomes critical. With Threat Detection and Real-Time Protection, Microsoft Defender helps organizations adopt AI agents with security controls designed for how agents actually operate—detecting attacks, enabling SOC investigation, and blocking malicious interactions at runtime.

Level Up Your Security Skills This August with the Microsoft Defender Challenge and Learn Live

ShirleyseHaley — Mon, 27 Jul 2026 16:47:02 GMT

Security teams face an increasingly complex landscape. Threats span identities, endpoints, email, cloud workloads, and emerging AI environments. The best defenders aren't just reacting to threats—they're continuously building the skills needed to stay ahead.

That's why we're inviting security practitioners to build practical security operations expertise while working toward their next certification goal. Running from July 20 through August 21, 2026, and focused on skills across Microsoft Defender XDR, Microsoft Sentinel, and Microsoft Defender for Cloud, this hands-on learning experience is the Microsoft Defender Challenge.

Build Skills That Matter to the Modern SOC

The Microsoft Defender Challenge isn't about memorizing content for an exam. It's designed to help you develop real-world security skills you can apply immediately in your organization. Through curated Microsoft Learn content, you'll strengthen your ability to:

Detect, investigate, and respond to threats across Microsoft Defender XDR

Manage incidents and automate workflows with Microsoft Sentinel

Triage and remediate security alerts in Microsoft Defender for Cloud

Secure cloud and AI workloads using modern security practices

Improve operational readiness for today's evolving threat landscape

Whether you're a SOC analyst, security engineer, cloud security practitioner, or IT professional looking to expand your security expertise, the challenge is an opportunity to sharpen skills that map directly to modern security operations.

Complete the Challenge and Enter the Sweepstakes

Learning is the real reward, but there's an added incentive. Participants who complete the Microsoft Defender Challenge and submit the official sweepstakes entry form by August 21, 2026 will have the opportunity to win one of 500 certification exam vouchers worth 50% off one of the following Microsoft Certifications:

SC-200: Microsoft Security Operations Analyst

SC-500: Microsoft Cloud and AI Security Engineer

How to Enter

Complete the Microsoft Defender Challenge on Microsoft Learn.

Before the entry period closes, submit the official sweepstakes entry form.

If selected, you'll receive instructions for redeeming your certification discount voucher.

Challenge window: July 20 – August 21, 2026. Sweepstakes entry deadline: August 21, 2026 at 11:59 PM UTC.

No purchase necessary. See official rules for eligibility and sweepstakes details.

Join Learn Live: Remediating Threats Using Microsoft Defender

Want a guided walkthrough of the skills featured in the challenge? Join a live, interactive event where you can learn directly from Microsoft experts, ask questions in real time, and explore security operations scenarios together. Save your spot for our August Learn Live session.

Date: Wednesday, August 19, 2026 | Time: 12:00 PM PT / 3:00 PM ET

You'll be guided by Scott Landry, Microsoft Security Customer Experience Engineering, as you explore practical approaches to investigating security incidents, managing and remediating threats across the Microsoft Defender ecosystem, automating investigations and response actions, strengthening security operations processes, and applying Microsoft Defender capabilities to real-world scenarios.

Start Building Your Skills Today

Ready to level up? Sign up today to take the Microsoft Defender Challenge, then join us for the Learn Live session on August 19. Your skilling journey doesn't end here—keep learning, keep growing, and keep building beyond August at the Security Hub on Microsoft Learn.

How Nationwide stays ahead of attackers with Project Perception

julievanloef — Mon, 27 Jul 2026 12:30:00 GMT

Nationwide, the world’s largest building society, is among the first organizations to put Microsoft’s new agentic security system to work. Facing adversaries who now regularly weaponize AI, the society is using Project Perception’s coordinated multi-agent defense—red, blue, and green agents working alongside its analysts—to find and remediate threats faster, while its security experts stay firmly in command. Their team has already seen work that once took weeks compressed into hours.

Defending against AI-driven threats

Nationwide Building Society is a member-owned mutual serving 19 million members across the UK, and that responsibility is becoming increasingly complex as AI reshapes the threat landscape. Attackers can now scale campaigns faster and automate more of their operations. "AI is giving attackers a real advantage over defenders in terms of pace and scale," says David Boda, Chief Security and Resilience Officer.

For its security teams, the mission is clear: protect the customers who trust the organization with some of the most important aspects of their lives. "The things that matter most are protecting their money, protecting their livelihoods." says Tim Russell, Cybersecurity Director.

For Nationwide Building Society, keeping pace means human-led, agent-driven defense that helps its team act faster, together and stay ahead.

Coordinated multi-agent defense, built on Microsoft Security

Nationwide Building Society’s response is to get ahead of the change in the threat landscape—identifying potential risks faster and accelerating response across its environment. Building on Microsoft Defender, which its teams have run for years, the society adopted Project Perception to bring coordinated multi-agent defense into its existing operations. "This solution for multi-agent defense allows us to move to a more proactive way of working," says Boda.

The system puts specialized agents to work as a team. "Red agents are offensive cyber agents used to explore the vulnerabilities and the attack paths in our environment. Blue agents are the defensive agents and reflect the work that a security operation center analyst might do," Boda explains, while green agents remediate and harden—with people in command throughout. "The power of the solution is it brings those agents together to achieve a better cybersecurity posture."

For analysts, that coordination removes long-standing friction. "We're able to use agentic workflows to identify threats and then track them through into remediation, which previously we would've had to have engaged with a number of different tools to achieve," says Russell.

Human-led, agent-driven defense

The impact is already tangible. "My team came to me and said, look, we've just taken four weeks of threat intelligence analysis and collapsed that down into four hours—and for me, that was the moment that really brought this to life," Boda recalls. Just as important to Nationwide Building Society is what the technology does for its people. "This technology helps to amplify their skill sets, not to replace them," says Russell.

For Nationwide Building Society, the future is humans and agents working as one. "Agents can work twenty-four-seven, but as humans, we can't do that. So, by harnessing humans and agents operating together, we can achieve so much more collectively," says Boda. And the ambition reaches further than the society itself: "Being able to develop this solution together with Microsoft allows us not just to protect Nationwide Building Society, but also to protect wider society—and that feels really positive."

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, 14 Jul 2026 18:24:17 GMT

***July 14 Update: TLS Hybrid Key Exchange using ML-KEM groups is now available on Windows 11 starting with update KB5089573 for 24H2 and 25H2 and KB5095091 for 26H1. Composite algorithms are now available on Windows 11 starting with update KB5095093 for 24H2 and 25H2 and KB5095091 for 26H1. Both features are available for Windows Server 2025 with the July 14th patch - July 14, 2026—KB5099536 (OS Build 26100.33158)

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.

Microsoft Security Community Blog articles

The Microsoft AI and Agent Platform — The Platform Behind Intelligent Agents

Why the platform around the model is the real enterprise differentiator

Intelligence + Trust = Frontier Transformation

Part 1: Intelligence

Experience layer: meet users where work already happens

Agent layer: specialize by domain, tools, and autonomy

Intelligence layer: grounding as a first-class platform tier

Grounding, fine-tuning, and adaptation

Memory

Multi-model choice

Model routing

Orchestration

Guardrails

How agents are built: one continuum from no-code to pro-code

Where agents run: one platform, multiple runtime choices

Foundation layer: shared trust fabric

End-to-end request journey: how the layers work together

Conclusion

Securing AI Agents at Runtime: Real-Time Protection and Threat Detection for Microsoft Agent 365

Threat detection for Microsoft Agent 365 Agents (Public Preview)

Real-time protection for WorkIQ and Custom MCP servers (General Availability)

Better Together: Detection and Protection

Getting Started

Level Up Your Security Skills This August with the Microsoft Defender Challenge and Learn Live

Build Skills That Matter to the Modern SOC

Complete the Challenge and Enter the Sweepstakes

Start Building Your Skills Today

How Nationwide stays ahead of attackers with Project Perception

Defending against AI-driven threats

Coordinated multi-agent defense, built on Microsoft Security

Human-led, agent-driven defense

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

What features or products have provided the most impact?