Stop identity attacks before they start with Microsoft ISPM recommendations
Many major breaches involve compromised identities, excessive privileges, or misconfigured access. Long before ransomware detonates or data leaves the building, adversaries are quietly abusing valid accounts, excessive privileges or other misconfigurations to move deeper into the environment. Identity has become one of the most important attack surfaces you defend. That is why Microsoft has a dedicated team of researchers who study how identity attacks actually happen. Just as important, we turn what they learn into action. Real attacker behavior becomes concrete recommendations you can use to harden your environment before an attack begins. With Microsoft Defender, that research reaches you as Identity Security Posture Management (ISPM) recommendations: prioritized guidance that tells you what to fix, why it matters, and how to remediate it. What are identity security posture recommendations? Identity security posture recommendations are prioritized, attack-driven recommendations that address the weaknesses attackers exploit most, from overprivileged accounts to weak credentials and risky permissions. Rather than handing you a long hygiene checklist, ISPM recommendations tie each recommendation to a real attack technique. That shifts the question from "what setting do I need to change?" to "what attack am I going to prevent today?" That framing also changes how you prioritize. You can start with the fixes that close the most dangerous attack paths first, not just the ones that are quickest to clear. It gives identity admins and the SOC and others shared view of the same risk, and as our researchers uncover new techniques, the recommendations evolve, so your posture keeps pace with the threat. New recommendations We are excited to announce five new ISPM recommendations geared toward emerging attack patterns you need to be aware of: Ensure no privileged SaaS app accounts exist outside of IdP control Most SaaS platforms let you create admin accounts directly inside the app, separate from your corporate identity provider (IdP). Those local admins are convenient, but they sit outside the protections every other identity relies on: No outside centrally managed identity controls as Conditional Access, and little to no monitoring. Attackers know it. We’ve seen a rise in SaaS data-exfiltration campaigns that specifically hunt for these app-native admin accounts, because once they find one they can sign in and operate without tripping any of your usual defenses. This recommendation surfaces those accounts so you can bring them under your identity provider, where you can manage them with single sign-on, multifactor authentication, Conditional Access, and lifecycle governance apply automatically and where your SOC can finally see them. This attack pattern aligns with MITRE ATT&CK techniques including Valid Cloud Accounts (T1078.004) and Account Manipulation (T1098). Ensure service accounts are not assigned Domain Admin or Global Admin roles Service accounts run your apps and integrations, and because they are not tied to a person, they are easy to over-provision and easy to forget. When one is assigned Domain Admin or Global Admin, it becomes a quiet path to the top of your environment. Supply-chain intrusions like SolarWinds showed how attackers ride a trusted service identity straight into the highest levels of access, often without anyone noticing, because no one watches a service account the way they watch a user. This recommendation flags service accounts holding those top-tier roles so you can right-size them. It shrinks the blast radius if one is ever compromised and keeps a non-human account from becoming a hidden administrative backdoor. This attack pattern aligns with MITRE ATT&CK techniques including Valid Accounts: Domain Accounts (T1078.002) and Cloud Accounts (T1078.004) Ensure non-admin accounts cannot reset passwords for sensitive groups Sometimes a standard user account quietly holds the ability to reset passwords for members of a sensitive group, a leftover of delegated permissions no one revisited. On paper that user is low privilege. In practice they are one password reset away from becoming an administrator. Attackers look for exactly this kind of shadow admin: compromise an unremarkable account, reset a privileged password, and walk in through the front door, no exploit required. This recommendation finds those unintended password-reset rights over sensitive groups and helps you remove them, closing a direct path from ordinary user to full administrator. This attack pattern aligns with MITRE ATT&CK techniques as Account Manipulation (T1098) Ensure non-admin identities cannot have WriteDACL permissions on sensitive groups Deep in Active Directory, some permissions can be abused to grant additional rights and gain control of a sensitive group. One of them, the right to modify an object's access control list (known as WriteDACL), is especially dangerous in the wrong hands. If a non-admin identity holds it over a sensitive group, that identity can simply rewrite the group's permissions and grant itself privileged control. It is one of the most reliable escalation paths attackers use. This recommendation identifies non-admin identities with that permission over sensitive groups so you can strip it, eliminating a well-worn route from a regular account to Domain Admin. This attack pattern aligns with MITRE ATT&CK techniques as Account Manipulation (T1098) Ensure external and guest accounts are not granted privileged roles Guest and external accounts make collaboration easy, but they live partly outside your control. Their security depends on another organization's hygiene, and they blend in, which makes them an attractive target. When one of these accounts is also granted a privileged role, a single compromise on the other side of that relationship becomes a privileged foothold inside your tenant. This recommendation highlights external and guest identities holding sensitive roles so you can remove that access, preventing an outside account from being used for persistence, escalation, or reaching your data. This attack pattern aligns with MITRE ATT&CK techniques as Valid Cloud Accounts (T1078.004) and Account Manipulation Cloud Roles (T1098.003) Additional high-impact identity posture recommendations In addition to the five new recommendations, several existing ISPM recommendations remain especially important. We continue to see attackers exploit the weaknesses they address, which makes them high-value fixes for strengthening your identity posture. Here is why each one still earns priority. Remove dormant accounts from sensitive groups A privileged account no one uses is a gift to an attacker. It still carries powerful access, but because nobody signs into it, nobody notices when someone else does. Ransomware crews and intrusion groups seek out these forgotten admin accounts precisely because they can operate from one for weeks without raising suspicion. Removing dormant privileged accounts takes that stealthy, high-impact option off the table before it is ever used. Reduce lateral movement path risk to sensitive entities Reduce lateral movement path risk to sensitive entities helps close one of the most common ways identity attacks become domain-wide compromises: an attacker starts with a non-sensitive account, then follows permissions, group memberships, local admin rights, active sessions, or other identity relationships until they can reach highly sensitive credentials. This maps to well-known lateral movement and privilege escalation techniques, where adversaries abuse excessive permissions or exposed credential paths to move from an initial foothold toward Domain Admin or another high-value identity. This recommendation highlights exposed entities with risky lateral movement paths and provides remediation guidance to reduce the number of non-sensitive accounts on each path. By removing unnecessary privileges and memberships, teams can shrink the attack graph around sensitive entities and prevent a small compromise from becoming a privileged identity breach Use least privileged administrative role Use least privileged administrative roles in Microsoft Entra ID reduces the blast radius of a compromised admin account. In many identity attacks, adversaries first gain access through phishing, password spray, or stolen credentials, then abuse valid cloud accounts to escalate privileges, create persistence, or access sensitive data. This maps to the known attack technique Valid Accounts where an attacker uses a legitimate account’s assigned permissions instead of malware or exploits. Assigning narrow, task-specific admin roles instead of broad roles like Global Administrator limits what an attacker can do if that account is compromised and makes privilege escalation harder. Ensure Sign-in frequency is enabled and browser sessions are not persistent for Administrative users Ensure Sign-in frequency is enabled and browser sessions are not persistent for Administrative users reduces the window of opportunity after an admin session is stolen. This maps to known session-theft techniques such as Steal Web Session Cookie and Web Session Cookie, where adversaries use stolen authentication cookies to access cloud services as an already-authenticated user, sometimes bypassing MFA because the session was established before the theft. By requiring admins to reauthenticate more often and preventing persistent browser sessions, organizations make stolen sessions expire sooner and reduce the chance that a compromised admin browser session becomes long-lived access to sensitive systems. Stay ahead of attackers Attackers keep evolving, so your identity posture has to evolve with them. The strongest defense is not a one-time cleanup, it is continuously closing the gaps attackers depend on, from stolen credentials to excessive privilege and lateral movement. That is exactly what ISPM recommendations are built to help you do, turning live attacker research into clear actions you can take today. In the Microsoft Defender portal, review your ISPM recommendations, start with the five new proactive exposures, and prioritize the highest-risk attack paths first. Every path you close is one an attacker cannot take. Next steps Start by reviewing your identity security posture recommendations in the Microsoft Defender portal under Exposure management > Recommendations. Prioritize recommendations that expose privileged identities, sensitive groups, service accounts, or attack paths to critical assets, then remediate unnecessary privileges, delegated permissions, and unmanaged identity access. To explore your Microsoft Identity Security Posture Management (ISPM) recommendations, see: https://security.microsoft.com/exposure-secure-scores Documentation For more details as licensing and prerequisites, see: Microsoft Defender for Identity security posture assessments - Microsoft Defender for Identity | Microsoft Learn
One SOC, Many Tenants: Centralizing Microsoft Sentinel with Azure Lighthouse
Most large organizations don’t live in a single Microsoft Entra ID tenant. Acquisitions, regulatory separation, sovereignty mandates, and mission boundaries all multiply tenants over time. For a security operations team, that sprawl creates one hard question: how do you run a single security operations center (SOC) with one pane of glass, without copying every tenant’s logs into a central bucket and inheriting the compliance risk that comes with it? Azure Lighthouse provides delegated resource management for this scenario. It lets authorized operators in a central hub tenant work with scoped resources in spoke tenants from their own tenant. Paired with Microsoft Sentinel, it supports cross-tenant visibility while source logs remain stored in each spoke workspace. Group-based RBAC and Privileged Identity Management (PIM) can help govern privileged access. This practical blueprint applies least privilege to that pattern: one Sentinel deployment in the hub, delegated read access to the Log Analytics workspaces in each spoke, and RBAC and PIM controls that support auditability. The delegation is scoped to the workspaces the SOC needs. Before you begin: prerequisites Gather the identifiers and identity groups below before you touch any tenant. The consistency you establish here is what makes the per-spoke procedure repeatable across an entire estate. Collect tenant and workspace identifiers Hub CSOC tenant ID and hub Sentinel workspace resource ID. For each spoke: tenant ID, subscription ID, workspace resource group, and workspace resource ID. Create hub security groups in Microsoft Entra ID SOC-Readers, the required core query-access group. SOC-Responders, an optional group for response-specific actions. SOC-Admins, an optional and tightly controlled group. Define the minimum RBAC baseline Assign Log Analytics Reader to SOC-Readers at the spoke workspace or resource-group scope. Add elevated roles only when a documented use case requires them. Register the required resource providers Lighthouse and Sentinel both depend on resource providers being registered before delegation will work. In every spoke subscription, register Microsoft.ManagedServices so the delegation can be created. And because Sentinel lives only in the hub, register Microsoft.SecurityInsights and Microsoft.OperationalInsights on at least one subscription in the hub tenant. That last step is easy to overlook, and skipping it quietly blocks cross-tenant operations. What you’ll find here The architecture, and why data residency makes hub-and-spoke the right call. Prerequisites, including the resource providers teams most often forget to register. A repeatable, per-spoke delegation procedure. Validation queries that prove the access path actually works. A complete RBAC assignment matrix and PIM activation policy. Troubleshooting for the errors you’ll actually hit. Why hub-and-spoke for a cross-tenant SOC In this model, Microsoft Sentinel is deployed once, in the hub (CSOC) tenant. Each spoke tenant keeps its own Log Analytics workspace, where its logs are collected and retained. Azure Lighthouse connects the two: the spoke delegates scoped access to the hub, and authorized hub analysts query spoke workspaces from their own tenant. The source logs remain stored in the spoke workspace, while query results are returned across tenant boundaries to authorized users and services. Figure 1. The hub runs Sentinel and queries each spoke’s Log Analytics workspace through a scoped Azure Lighthouse delegation; logs never leave the spoke tenant. That separation is the entire point, and it lines up with the advantages Microsoft calls out for centralized cross-tenant management: Workspace ownership and source-log storage remain with each spoke tenant. Source telemetry remains stored in the configured spoke workspace and region, subject to the service configuration and authorized query access. Separate workspaces help maintain tenant isolation between spokes. Cross-tenant detection and hunting can query spoke workspaces without centralizing the underlying source logs; authorized query results are returned across tenant boundaries. Ingestion and retention costs are billed to the tenant that generates the data, not to the hub. What this runbook delivers The objective is a centralized CSOC with scoped, governed access across spoke tenants from a single Sentinel instance. Hub SOC teams query spoke Log Analytics workspaces through delegation, run cross-tenant analytics, and create and manage incidents centrally, while spoke logs stay in spoke workspaces and tenant isolation is preserved. Just as important is how that access is granted. The target state is least-privilege by construction: RBAC assignments carry only the permissions the SOC needs, privileged roles are PIM-governed rather than standing, and every delegation is scoped to the specific resources in play. When the build is complete, the operating model is both active and auditable. Configuring the delegation (per spoke tenant) Repeat the three steps below for each spoke. For fleets larger than a handful of tenants, capture the same authorization in an Azure Lighthouse ARM template and deploy it per spoke, so the scope and role assignments stay identical across the estate. Step 1: Register the provider in the spoke subscription Register Microsoft.ManagedServices in the spoke subscription. Confirm the provider registration state is Registered before continuing. Step 2: Create the Lighthouse delegation from spoke to hub Open Azure Lighthouse in the spoke tenant. Create a delegation, or offer, and set the managing tenant to the hub CSOC tenant ID. Add an authorization with the principal set to the hub SOC-Readers group and the role set to Log Analytics Reader. Set the scope to the workspace resource group (preferred) or to the individual workspace. Prefer group-based assignments and avoid direct user assignments. Step 3: Repeat across all spoke tenants Apply the same pattern and naming convention every time. Document any scope or role exceptions for security review. Validating the delegation Three checks confirm the delegation is wired correctly: visibility, query access, and incident generation. Run them in order, because each one depends on the check before it. Figure 2. The three validation checks run in sequence — visibility, then cross-tenant query, then incident generation — each building on the one before. Confirm delegated visibility From the hub context, verify that each spoke appears under Azure Lighthouse delegated resources. Confirm that the expected principals and scopes are listed. Run a cross-tenant query from hub Sentinel Run a simple take query to verify that the access path resolves. Run a data query against a known active table to confirm you can see ingestion. Confirm the access path resolves: workspace("/subscriptions/<spoke-sub-id>/resourceGroups/<spoke-rg>/providers/Microsoft.OperationalInsights/workspaces/<spoke-ws>") | take 1 Check that a known table is receiving data: workspace("/subscriptions/<spoke-sub-id>/resourceGroups/<spoke-rg>/providers/Microsoft.OperationalInsights/workspaces/<spoke-ws>").Heartbeat | where TimeGenerated > ago(24h) | summarize Events = count() Verify incident generation in hub Sentinel Create a temporary scheduled analytics rule that uses cross-tenant query logic. Trigger the test condition and confirm that the incident is created in the hub. Standardizing new-spoke onboarding Turn the procedure into a checklist so every new spoke is onboarded the same way and nothing slips. Resource provider registered. Delegation deployed with the hub as managing tenant. Roles assigned to hub SOC groups. Cross-tenant query test passed. Hub incident-generation test passed. Access-review owner assigned. Security and governance Delegation connects the hub to scoped spoke resources; governance helps control that access. Three controls do most of the work. Enforce privileged identity controls Make privileged groups PIM-eligible rather than permanently assigned. Require MFA, approval, justification, and time-bound activation. Maintain separation of duties Keep SOC monitoring, content engineering, and platform administration in separate roles. Review delegated access on a recurring governance cadence. Manage exceptions with formal controls Document every elevated-access and broad-scope delegation exception. Require security-architecture approval for any non-standard scope. Role and RBAC assignment matrix The tables below translate those principles into concrete assignments: first the hub-local roles, then the delegated spoke roles, and finally the PIM activation policy that governs both. Hub (CSOC) tenant: local assignments Spoke (service) tenant: delegated via Azure Lighthouse PIM activation requirements Key design rules Minimum privilege governs spoke delegation. Log Analytics Reader covers every cross-tenant detection and query operation, so Owner and broad Contributor at subscription scope have no place in a SOC delegation. Sentinel Responder in a spoke is rarely needed. It matters only when analysts must acknowledge, close, or act on spoke-level resources directly, and in a hub-only Sentinel model spoke incidents don’t exist, so the role usually isn’t required. Separation of duties is strict. Content engineers don’t get responder rights, responders don’t get content-deployment rights, and platform admins sit apart from both monitoring and detection engineering. Routine privileged roles are eligible and time-bound. SOC responders, hunters, content engineers, and platform admins use PIM rather than permanent assignment. Emergency-access accounts are the exception and should follow Microsoft Entra emergency-access guidance, including monitoring and regular validation. Troubleshooting common issues Most problems fall into three buckets, and each has a short diagnostic path. Design notes and what’s next By default, Sentinel stays enabled in the hub only, unless a spoke-specific requirement is approved. Spoke tenants remain data-source focused and don’t generate local Sentinel incidents; detection, incident management, and automation all live in hub Sentinel, giving you one place to build content and one place to respond. A centralized SOC does not require centralizing every source workspace. With scoped Azure Lighthouse delegation and PIM-governed access, a CSOC can query a multitenant estate while source logs remain stored in their spoke workspaces. Further reading Manage Microsoft Sentinel workspaces at scale (Azure Lighthouse) Manage multiple tenants in Microsoft Sentinel as an MSSP Extend Microsoft Sentinel across workspaces and tenantsMonthly News-August 2026
Microsoft Defender Monthly news - August 2026 Edition This is our monthly "What's new" blog post, summarizing product updates and various new assets we released over the past month across our Defender products. In this edition, we are looking at all the goodness from July 2026. We are now including news related to Defender for Cloud in the Defender portal. For all other Defender for Cloud news, have a look at the dedicated Defender for Cloud Monthly News here. 🚀 New Virtual Ninja Show episode: Redefining identity security for the modern enterprise One policy engine to govern them all: Securing agentic AI with Microsoft Purview Building a modern detection pipeline with ContentOps Securing local AI agents with Microsoft Defender Microsoft Defender: Extending critical protection for emerging threats in Team Actionable threat insights (find all of them here) Email threat landscape: Q2 2026 trends and insights Enhancing AI security through global AI red teaming Least privilege for AI agents: Identity, access, and tool binding Microsoft Defender (Public Preview) Microsoft Defender now assesses posture risk for AI agents, including enterprise agents and local agents discovered on endpoint devices. Risk levels are based on active risk indicators, such as configuration, access, runtime activity, endpoint and user context, and active alerts. Security teams can use posture risk and recommendations to prioritize risky agents and improve agent security posture. For more information, see AI agent posture risk in Microsoft Defender. (Generally available) The Domain investigation page allows you to investigate an Active Directory domain. It shows Active Directory domain security, including domain properties, deployment health, identity summary, service account breakdown, sensitive entities, active recommendations, group policies, and trust relationships. For more information, see Investigate a domain . (Generally available) With a Microsoft Agent 365 license, Microsoft Defender provides discovery, security posture, threat detection and investigation, and real-time protection for the AI agents in your tenant. Onboarding includes enabling data collection, connecting the Microsoft 365 app connector, and connecting Copilot Studio for real-time protection of Copilot Studio agents. For more information, see Protect AI agents using Microsoft Defender. (Generally available) Improved access to Playbook Generator: Following the GA release of Playbook Generator May 31st, the team focused on streamlining the onboarding experience and reducing friction related to Security Copilot wallet provisioning. Playbook Generator remains included with Microsoft Sentinel and does not consume SCUs for generating, testing, or running playbooks, yet customer feedback highlighted friction around Security Copilot wallet provisioning and initial setup requirements. The team worked on simplifying access and reducing onboarding barriers so organizations can more quickly take advantage of AI-assisted playbook creation, testing, and automation capabilities. For all other Sentinel News, have a look at the "What's new in Microsoft Sentinel blog post - July edition" Identity Security (Generally available) Migration of Defender for Identity sensors from v2.x to v3.x is now generally available. For more information, see Migrate to Defender for Identity sensor v3.x. Migration readiness reasons on the Sensors page: When a server is marked Not ready for migration on the Sensors page, you can now hover over the status to see a tooltip that lists the specific reasons the server doesn't meet the migration prerequisites. For more information, see Troubleshoot "Not ready for migration" status. (Public Preview) Expanded SaaS app support in Password protection. The Password protection page now includes password risks from SaaS apps connected through Defender for Cloud Apps, in addition to Active Directory, Microsoft Entra ID, and Okta. SaaS apps that support SaaS Security Posture Management (SSPM), such as Salesforce and ServiceNow, appear on the Password Hygiene and Password Policies tabs. Each SaaS app requires a Defender for Cloud Apps app connector. For more information, see Investigate identity password protection. Automatic RPC auditing on domain controllers: Defender for Identity now automatically enables RPC auditing on domain controllers when you upgrade to sensor version 3.0.8 or later. You no longer need to apply a tag manually to enable RPC auditing. For more information, see Configure RPC auditing. Microsoft Defender Experts MDR General Availability of Microsoft Defender Experts MDR P2: Microsoft Defender Experts MDR (formerly Microsoft Defender Experts for XDR) is expanding with new third-party and multi-cloud coverage powered by Microsoft Sentinel, with the launch of Defender Experts MDR P2 service. Defender Experts MDR provides a 24/7 managed detection and response service that reduces noise, adds expert context, and drives action. In addition to the Microsoft Defender products, this new service supports key non-Microsoft sources across cloud (AWS), identity (Okta), email (Proofpoint), network (Palo Alto Networks, Cisco, Fortinet, ZScaler), and endpoint (CrowdStrike) that are ingested in Microsoft Sentinel, providing E2E visibility and protection for customers operating heterogenous environments. Defender Experts will continue expanding our scope to other non-Microsoft products to deliver on this promise. For more information, see the Microsoft Defender Experts MDR documentation. Microsoft Security Exposure Management / Defender Vulnerability Management (Private Preview) Codename MDASH - Agentic code scanner is now available in private preview in Microsoft Security Exposure Management. Codename MDASH uses a multi-model agentic AI system to detect code vulnerabilities with greater depth and accuracy than traditional static analysis. Security teams can run scans from Defender CLI or through a GitHub connector, review findings in the Defender portal, and use results to help prioritize code security risks. For more information, see Agentic code security overview. (Private Preview) Codename MDASH - MAI-Augmented scan profile private preview. The MAI-Augmented scan profile is now available in preview as part of Codename MDASH. The MAI-Augmented profile can be used when triggering a scan through the Defender CLI. It includes MAI-Cyber-1-Flash, a new cyber-specialized model that extends the current agentic scanner in addition to the existing required models. Security teams can choose this profile when triggering a scan from Defender CLI or continue using a scan profile based on the existing models. For more information, see Scan with a scan profile. OT data connectors in Microsoft Security Exposure Management: Microsoft Security Exposure Management now supports operational technology (OT) data connectors for Armis, Dragos, and Forescout. OT data connectors bring OT asset and vulnerability data from supported third-party OT platforms into the Defender portal. This helps security teams view OT devices alongside other assets, enrich device inventory with OT context, and investigate vulnerabilities across IT and OT environments. For more information, see OT data connectors. Microsoft Defender for Endpoint (Public Preview) AI agent runtime protection includes these enhancements: - Vendor-supported agent event interfaces now work with standard platform and engine update channels, so no Beta channel configuration is required. Agent-native event inspection now supports Codex CLI and the GitHub Copilot app. - Network inspection is now supported for agents that don't expose vendor-supported event interfaces, including OpenClaw and similar Node.js-based Claw agents. For more information, see AI agent runtime protection with Defender for Endpoint. (Generally available) Available from Defender for Endpoint on Linux version 101.26042.0011 and later. The Defender Deployment Tool for Linux simplifies deployment by combining installation, onboarding, upgrades, and uninstallation into a single workflow. The tool automates prerequisite validation, supports custom installation paths, enables deployment of specific Defender versions from preferred update channels, and works seamlessly in environments that use local repositories. In addition to a simplified deployment experience, customers can now gain complete visibility into deployment progress through Device Timeline integration, providing step-by-step installation, upgrade, and onboarding status, Advanced Hunting queries for fleet-wide deployment monitoring, and detailed error reporting, including deployment stage, status, exit code, and failure reason to simplify troubleshooting. These capabilities help administrators quickly identify deployment issues, track onboarding progress, and understand deployment outcomes across their Linux estate. Microsoft Defender for Office 365 Unified RBAC is the default permission model for new Defender for Office 365 Plan 2 organizations. Starting July 2026, new Defender for Office 365 Plan 2 organizations use the Microsoft Defender unified role-based access control (Unified RBAC) model by default. For more information, see Configure Unified RBAC for Defender for Office 365 and MC1246006. Microsoft 365 E3 now includes Microsoft Defender for Office 365 Plan 1. For more information about what's included in each plan, see Microsoft Defender for Office 365 Plan 1 vs. Plan 2 cheat sheet. Prompt injection protection: Defender for Office 365 now detects prompt injection attacks hidden in inbound email. For more information, see Prompt injection protection in Defender for Office 365.Securing AI Agents at Runtime: Real-Time Protection and Threat Detection for Microsoft Agent 365
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.
Custom detections are now the unified experience for creating detections in Microsoft Defender
As we continue to deliver on our vision to simplify security workflows for the SOC, we are making custom detections the unified solution for building and managing rules over Defender XDR and Sentinel data. While analytics rules remain available, we recommend using custom detections for access to new features and enhancements. Benefits of unified custom detections Adopting custom detections as the primary method for rule management helps streamline operations and enhance security. You can refer to this page for a full list of the benefits. Some highlights include: Single experience – One interface for managing detections across all data sources, and the ability to create rules across SIEM and XDR without additional ingestion costs. Cost reduction – Write a detection combining XDR and Sentinel data without extra Sentinel ingestion costs. Faster detection – Near real-time streaming technology. Custom detection reduces Kusto cluster load and allows unlimited number of NRT rules. Built-in XDR functions – Expand functionality previously only available in XDR to use in SIEM detections, such as FileProfile(), SeenBy(), DeviceFromIP() and AssignedIPAddresses(). Native XDR remediation actions – Native XDR remediation actions are available to be configured to automatically run when a custom detection fires. The new experience for unified rules management Custom detection is the default wizard when creating a detection from advanced hunting. If your use case still requires using an analytics rule, you can click on the “create analytics rule” button from the custom detection wizard. FAQs Q: Should I stop using analytics rules? A: While we continue to build out custom detections as the primary engine for rule creation across SIEM and XDR, analytics rules may still be required in some use cases. You are encouraged to use the comparison table in our public documentation to decide if analytics rules is needed for a specific use case. No immediate action is necessary for moving existing analytics rules to detection rules. Q: Are any immediate actions required? A: No action is currently necessary. Custom detections should be used when suitable for a scenario, as we will continue to invest in new capabilities for this feature. Q: Will custom detections have feature parity with Analytics Rules? A: Yes, we are working toward parity. Learn more about adopting custom detections Please refer to our public documentation for a detailed and updated comparison. What's next? Join us at Microsoft Ignite in San Francisco on November 17–21, or online, November 18–20, for deep dives and practical labs to help you maximize your Microsoft Defender investments and to get more from the Microsoft capabilities you already use. Security is a core focus at Ignite this year, with the Security Forum on November 17th, deep dive technical sessions, theater talks, and hands-on labs designed for security leaders and practitioners Featured sessions BRK237: Identity Under Siege: Modern ITDR from Microsoft Join experts in Identity and Security to hear how Microsoft is streamlining collaboration across teams and helping customers better protect, detect, and respond to threats targeting your identity fabric. BRK240 – Endpoint security in the AI era: What's new in Defender Discover how Microsoft Defender’s AI-powered endpoint security empowers you to do more, better, faster. BRK236 – Your SOC’s ally against cyber threats, Microsoft Defender Experts See how Defender Experts detect, halt, and manage threats for you, with real-world outcomes and demos. LAB541 – Defend against threats with Microsoft Defender Get hands-on with Defender for Office 365 and Defender for Endpoint, from onboarding devices to advanced attack mitigation. Explore and filter the full security catalog by topic, format, and role: aka.ms/SessionCatalogSecurity. Why attend? Ignite is the place to learn about the latest Defender capabilities, including new agentic AI integrations and unified threat protection. We will also share future-facing innovations in Defender, as part of our ongoing commitment to autonomous defense. Security Forum—Make day 0 count (November 17) Kick off with an immersive, in person preday focused on strategic security discussions and real-world guidance from Microsoft leaders and industry experts. Select Security Forum during registration. Register for Microsoft Ignite >Microsoft Defender now integrates with Dragos, Forescout, & Armis for OT Security
Co-author(s): Amit Cohen and Hadar Shindler Operational technology (OT) environments are unlike anything else in cybersecurity. The systems that run our factories, power grids, water treatment plants, pipelines, and transportation networks weren’t built with modern threats in mind — and they can’t simply be patched, rebooted, or scanned the way IT systems can. A misstep doesn’t just create an alert backlog; it can stop a production line, disrupt critical services, or put physical safety at risk. To support customers in bringing their OT security solutions into their Security Operation (SOC) platform, we’re excited to announce an expansion of the Microsoft ecosystem with new OT security integrations from Dragos, Forescout, and Armis from ServiceNow. This gives customers greater flexibility to use the OT security solutions that best fit their environments. Expanding OT coverage in Defender with new partner integrations We’ve built new connectors for Dragos, Forescout and Armis that are now ready for customers to start using. Dragos "Strong OT defense starts with knowing what is running in your operational environment, the vulnerabilities those assets carry, the threats targeting your systems, and the data to determine root cause. That kind of intelligence comes from years of operating inside OT environments and tracking the groups behind those threats. As OT threats continue to grow and AI accelerates how quickly adversaries can approach the OT boundary, integrating Dragos into Microsoft Defender strengthens how organizations see, understand, and defend their OT environments." -Robert M. Lee, CEO and Co-Founder, Dragos, Inc. Forescout "Our integration with Microsoft Defender represents a significant step forward in helping organizations defend their most critical operations against today's rapidly evolving cyber threats. By combining Forescout's industry-leading visibility and protection for IoT, OT, and network-connected assets with Microsoft's leadership in endpoint, identity, cloud, and security operations, we're delivering a more unified approach to cyber defense. Together, we're enabling healthcare providers, government agencies, critical infrastructure operators, and enterprises comprehensive visibility across IT and OT environments while empowering security teams to detect, investigate, and respond to threats faster and with greater confidence." -Robert McNutt, Chief Strategy Officer, Forescout Armis “Fragmented security is no longer an option as threats to critical infrastructure evolve at machine speed. By deepening our integration with Microsoft, we are unifying visibility and context in complex OT and IoT environments. Integrating Armis Centrix™ with Microsoft Defender equips security teams with real-time, actionable insights to identify and mitigate risks across their entire operational footprint.” -Nadir Izrael, Group Vice President, Armis from ServiceNow Bringing OT and IT Security Together With these new integrations, signals, asset inventory and vulnerabilities from Dragos, Forescout, and Armis from ServiceNow flow directly into Microsoft Defender — giving security operations teams a single, unified view across IT, OT, and IoT. What this means for customers: Unified visibility across IT and OT. OT assets and vulnerabilities surface alongside IT signals in Defender, so the SOC can see and reason about them in one place. Cross-domain correlation. Identity, endpoint, cloud, and OT signals are correlated automatically. Streamlined investigation and response. Analysts can pivot from an OT detection to related IT activity (and back) without switching tools or losing context. Specialized depth, unified breadth. Customers keep the deep OT expertise of their chosen partner platform and gain the enterprise-wide coverage of Defender. Let’s take a look at some of new the user experience updates that showcase these integrations. Figure 1. Discovered devices by OT partner in device inventory The Device Inventory now will show OT devices discovered through a new partner integration (see Figure 1). Industrial assets like substation relays and switches from vendors are automatically surfaced with rich context, criticality, vendor, model, firmware, and discovery source alongside built-in recommendations to classify critical assets and protect unmanaged OT devices. The result: unified visibility across IT and OT from a single view, so security teams can find, prioritize, and protect previously unseen devices faster. Figure 2. Vulnerabilities and exposure across OT devices The Vulnerabilities view now includes a dedicated OT Partner CVEs tab, surfacing thousands of vulnerabilities on operational technology devices discovered through partner integrations. Every CVE is enriched with severity, CVSS score, age, active threats, and exposed device count, and the list is sorted by exposure so the most widespread, highest-impact risks rise to the top. Most importantly, security teams can now see OT vulnerabilities alongside IT in a single, prioritized view, making it faster to focus remediation where it matters most. Figure 3. Discovered devices exposed by OT integration Selecting a CVE opens a detail panel with a dedicated Exposed devices discovered by OT partner tab, listing every affected device along with its OS platform and last seen date. For CVE-2024-7264, that means a clear view of all 75 exposed devices in one place, from OT controllers to sales workstations. The benefit is that security teams can move from a single vulnerability straight to the exact devices at risk, making it easy to scope impact and drive targeted remediation without leaving the view. Figure 4. Discovered vulnerabilities by OT integration Drilling into a specific device, like the Substation-North-HMI2 shown here, reveals a dedicated Discovered vulnerabilities by OT partner tab alongside the standard device views such as incidents, timeline, and security recommendations. It lists every vulnerability found on that device by the OT partner, complete with severity, CVSS score, publication and detection dates, and active threats. The benefit is a complete, device-level picture of OT risk right where analysts investigate, so they can see exactly what a single asset is exposed to and prioritize remediation without switching tools or context. Built for customer choice and flexibility We’re excited to expand our integration ecosystem, giving customers the flexibility to work with the OT solutions they already trust. These integrations help bring specialized OT context into broader security workflows, enabling SOC teams, risk managers, and security leaders to collaborate more effectively while using the tools that best fit their environment. Get started The Dragos, Forescout, and Armis integrations are available in public preview starting today. Customers can enable them through the Defender portal and begin ingesting OT signals from their partner platform of choice. Integrate the Dragos OT data connector in Microsoft Security Exposure Management - Microsoft Security Exposure Management | Microsoft Learn Integrate the Forescout OT data connector in Microsoft Security Exposure Management - Microsoft Security Exposure Management | Microsoft Learn Integrate the Armis OT data connector in Microsoft Security Exposure Management - Microsoft Security Exposure Management | Microsoft LearnMonthly news - July 2026
Microsoft Defender Monthly news - July 2026 Edition This is our monthly "What's new" blog post, summarizing product updates and various new assets we released over the past month across our Defender products. In this edition, we are looking at all the goodness from June 2026. We are now including news related to Defender for Cloud in the Defender portal. For all other Defender for Cloud news, have a look at the dedicated Defender for Cloud Monthly News here. 🚀 New Virtual Ninja Show episode: Redefining identity security for the modern enterprise One policy engine to govern them all: Securing agentic AI with Microsoft Purview Building a modern detection pipeline with ContentOps Securing local AI agents with Microsoft Defender Microsoft Defender: Extending critical protection for emerging threats in Team Weekly Security News: We publish a short 1ish minute video every week with updates across our Microsoft Security stack. Subscribe to our YouTube channel, so you don't miss the next episode. Actionable threat insights (find all of them here) Securing AI agents: When AI tools move from reading to acting Chromium extension uses AI‑related branding to redirect browser search Photo ZIP campaign targeting hospitality industry delivers Node.js implant for persistent access Microsoft Defender Two Workbooks capabilities in the unified Microsoft Defender portal moved to GA: Advanced Hunting connector - build custom dashboards directly on top of Advanced Hunting (XDR) dat. Query XDR tables and visualize them in Workbooks for richer investigations and reports. Workspace filter / multi-workspace experience - scope and filter workbooks by workspace, with workspace selection integrated into the workbook itself rather than relying on the global selector. MTO Tenant Groups let MSSPs and large enterprises organize their multitenant view in Microsoft Defender by grouping tenants logically (e.g., by region, business unit, or customer cohort). Learn more here. Custom Detections support in Microsoft Sentinel Repositories. Custom Detections can now be managed as code in Microsoft Sentinel Repositories, the same way customers already manage analytic rules, playbooks, parsers and workbooks. Detection engineers connect a GitHub or Azure DevOps repo to their workspace; Custom Detections placed in the repo are reconciled on every commit. A standalone Bicep path via the Microsoft Security Bicep extension lets teams deploy from any CI/CD pipeline (ADO Pipelines, GitHub Actions, custom runners). (General Availability) The following advanced hunting schema tables are now generally available: The CloudAuditEvents table contains information about cloud audit events for various cloud platforms protected by the organization's Defender for Cloud. The CloudDnsEvents table contains information about DNS activity events from cloud infrastructure environments. The CloudProcessEvents table contains information about process events in multicloud hosted environments. (Public Preview) The AgentsInfo table in advanced hunting is now available in preview. The AIAgentsInfo table is transitioning to this new table, which provides a unified schema that supports agent inventory and governance for all agent types, including Copilot Studio, Microsoft Foundry, Microsoft 365 Copilot, third-party, and endpoint-discovered agents. Microsoft Agent 365 customers should use the AgentsInfo table today. The AIAgentsInfo table remains accessible until July 1, 2026. Update your queries to use AgentsInfo before this date. For more information, see Advanced hunting schema - Naming changes. For all other Sentinel News, have a look at the "What's new in Microsoft Sentinel blog post - June edition" Identity Security (Public Preview) The Identity Security dashboard now includes a new Human identities card that shows your human identities by source (Entra ID, SaaS, and on-premises), giving you a single view of where your human identities live. For more information, see Identity Security dashboard. (Public Preview) On the Coverage and maturity page, the Review and improve coverage side panel for SaaS Identities now includes an Observed column and a Show Only Observed Applications toggle. By default, the panel shows only SaaS applications detected in your environment. Turn off the toggle to see other supported SaaS applications you can onboard to expand your identity coverage. For more information, see Coverage and maturity. New alerts were added to the Defender for Identity security alerts related to Microsoft Entra ID, Active Directory as well as other identity providers. For a full list of those new alerts, check out our documentation. Recent ShinyHunters attacks on Salesforce show how OAuth tokens and connected apps are being weaponized to bypass MFA at scale. The upgraded Salesforce connector for Defender for Cloud Apps helps detect these attacks faster, with richer connected-app context and investigation-ready signals. Customers already using the connector are advised to enable the additional events in the Salesforce console for tighter protection, and eligible customers not yet using it are advised to connect Salesforce. Learn more. Microsoft Defender for Endpoint / Microsoft Defender Vulnerability Management (Public Preview) Local AI agent discovery: as part of the Defender AI agents experience, Microsoft Defender now automatically discovers supported local AI agents running on onboarded Windows & macOS devices. Discovered agents appear as assets in the AI agent inventory, exposure map, and advanced hunting, giving security teams visibility into local AI agent usage across the organization. For more information, see Discover local AI agents. (Preview) Local AI agent runtime protection on Windows endpoints is now available in public preview. Microsoft Defender inspects the agent loop (user prompts, tool calls, and tool responses) and can block risky activity before it executes, helping stop prompt injection and unsafe agent actions at the device level. Blocked and audited events appear as alerts in Microsoft Defender to support incident correlation and investigation workflows. The new version of the Defender deployment tool for Windows streamlines onboarding and enhances security by: Bundling the onboarding package directly into the tool's executable. Generating a key during deployment package creation that is required for running the tool. Enabling users to configure an expiry date for the package to reduce the risk of unauthorized use. In addition: You have the option of downloading the package as either an .exe or a .zip file, whichever best suits your organization's needs. A new Deployment packages page in the Defender portal facilitates management of downloaded packages by providing centralized visibility into all the packages and their current status. Now generally available: Selective Response Actions enables organizations to tailor high-impact security operations on devices during onboarding. It provides precise control over how response actions are applied on Tier-0 systems and other high-value assets, helping maintain operational stability while delivering strong protection. The new exposure score model in Defender Vulnerability Management is now generally available. This model improves risk prioritization and recommendation impact accuracy by incorporating exploit prediction data (EPSS) and asset context factors such as internet-facing status and criticality. More details here. Microsoft Secure Score now includes the Reduce unnecessary inbound internet exposure on internet-facing devices recommendation, which helps identify devices that are accessible from the public internet and may represent unnecessary attack surface. This recommendation provides centralized visibility into internet-facing devices across the environment. Many predefined SaaS application classification rules were added to the critical assets list. Have a look at our documentation for the full list. These classifications require onboarding to Microsoft Defender for Cloud Apps.Empowering SOC Analysts: Investigating Identity Threats with Microsoft Defender XDR
Identities have been a top threat vector forever. However, the rise of cloud identity attacks and an ever increasingly complex digital estate has made a tough problem even harder. Securing identities has always required a close partnership between two different functional teams – the identity and access management teams that are responsible for managing, authenticating, and authorizing user access to protected systems and data; and the security teams that detect and respond to threats across the entire digital estate. Nowhere is this more apparent than during a security incident. Let’s take a look at a common attack type like this phishing email example below: While this is a straightforward scenario, it’s still extremely effective as many organizations aren’t equipped to protect against it. The 2024 Verizon Data Breach Investigation report detailed how the median time for an attacker to access data from phishing is now just 60 seconds, giving the security team little time to triage alerts across email, identity, and endpoints, coordinate with the IAM team to disable the user and reset the password, and clean up any affected devices and inboxes. This is where implementing an integrated Identity Threat Detection and Response (ITDR) solution comes in. Our solution breaks down the existing silos between your identity and security teams by natively integrating our IAM solution, Microsoft Entra ID, and our identity threat protection solution, Microsoft Defender for Identity into our Extended Detection and Response (XDR) platform. Our ITDR offering is unique in that it delivers robust ITDR capabilities where your teams already work today. This means empowering the SOC to investigate identity alerts directly within Defender while also surfacing necessary insights from those investigations for Identity Admins directly within the Entra experience. Enhancing XDR with ITDR Identity is a core pillar of our XDR solution. Capitalizing on Microsoft’s leadership in both Identity and Access Management (IAM) and security, Defender correlates identity data and insights with Endpoint, Cloud, SaaS app and collaboration alerts to help security professionals better understand the full scope of security threats without spending hours triaging and correlating alerts. Customers benefit from the following within the Defender experience: 1. Enriched visibility across the identity fabric The ITDR dashboard provides the SOC with a single, prioritized view of Identity-specific security information and recommendations. Pulling relevant alerts and insights from across their identity footprint, this pane helps SOC teams better understand their identity posture and quickly manage potential identity-related security risks. Additionally, the recently updated identity inventory provides visibility into all the identities within their fabric including human and non-human, on-premises or in the cloud, from Microsoft or another provider. Each one of those identities also has a corresponding identity page which offers even more insights into the identity itself and allows the SOC to take action on that identity, right from the experience. 2. Proactive Identity posture and prevention The robust posture recommendations within Microsoft Security Exposure Management include Identity-specific posture recommendations (ISPM’s) that range from spotting common misconfigurations to helping customers address vulnerabilities across Active Directory, Entra ID and other common identity fabric elements, before they can be exploited. This is further enriched with attack path modeling, which provides a prioritized queue of possible attack paths that could be exploited by a threat actor. This helps the SOC and identity teams understand the entire scope of vulnerabilities—from initial access to reach critical data—and work together to prioritize the highest priority exposures. Again, because of the native integration between Entra ID and Defender the recommendations surfaced to identity admins and SOC professionals are consistent, helping the two teams work in unison to strengthen their overall identity. Defender for Identity provides dedicated sensors for Domain Controllers, Active Directory Federation Services (ADFS), Active Directory Certificate Services (AD CS) and Entra ID Connect to provide comprehensive visibility into on-premises identity environments while Entra ID does the same for cloud identities. 3. Incident-level visibility Microsoft Defender uses XDR-level detections to automatically correlate all related alerts into prioritized incidents – making it easy for analysts to see which alerts are tied to a broader incident and need to be addressed first. Incidents are automatically updated if new related alerts are triggered, so analysts can be confident they’re always looking at the latest info. Incidents are also automatically enriched with identity-related insights – like recently logged on users on an endpoint, recent activity, MFA type, open incidents, Entra ID risk level, and more—so the SOC team can quickly understand the full context of a user without needing to go hunting. All of this information is synced automatically with Microsoft Entra, ensuring both the identity and SOC teams are looking at the same data. This context is also showcased within the hunting experience. Customers can hunt for emerging threats across identity and other domains right from the same pane. 4. Automated Threats Response With attackers moving laterally in just minutes, even the best security teams will be challenged to respond in time with manual processes. Microsoft Defender utilizes AI to automatically take action on in-progress attacks and prevent lateral movement. This built-in, self-defense capability uses the correlated signals in XDR, the latest threat intelligence, and machine learning backed models to accurately predict the attack path used and block an attacker’s next move before it happens with above 99% confidence. Disruption attacks only take the minimum action necessary to stop the attacker – like disabling a compromise user or containing an affected endpoint – limiting the impact on the organization and leaving the SOC and identity teams in control to complete the investigation and bring assets back online. Security professionals can take direct action on identities right from the XDR experience through actions like “Confirm user as compromised” or “Disable user,” to mitigate an active threat. These updates are reflected automatically in the Entra portal, so they work in conjunction with Entra’s risk based conditional access. That way, when an identity is confirmed as compromised by the SOC, the risk level within Entra will automatically be raised and the relevant conditional access policies will be triggered at the next login to prevent future attacks. This signal loop protects customers both proactively through continuous monitoring and zero-trust policy engine , and reactively through real-time alerts and response from both Entra ID and Defender XDR. Conclusion In today's dynamic cyber landscape and with the complexity of modern identity environments, SOC analysts require a single pane of glass view into and the ability to effectively combat identity threats. Microsoft XDR, with its integration of Microsoft Defender for Identity and Microsoft Entra ID, provides a unified platform that enhances identity threat detection, investigation, and response capabilities, across on-prem and cloud. The seamless flow of data, alerts and workflows between IAM and Security teams created by this integration closes the loop between reactive and preventative identity protection helping organizations stay ahead of adversaries and ensure the security and integrity of their systems and data.The next frontier in endpoint security: Securing local AI agents with Microsoft Defender
AI agents are now doing real work on the endpoint — reading files, running commands, browsing the web, and acting on behalf of the users they run under. That same power is also what makes them dangerous: agents act on whatever content they take in, and much of it comes from outside the user's control — a web page, a repository, a command's output. A single malicious instruction hidden in that content can turn an agent against the very environment it's trusted to work in. With access to source code, secrets, and the corporate resources, its identity can reach — from cloud infrastructure to SharePoint, email, and internal apps — a compromised agent becomes a path to everything that identity is trusted with. Yet most security teams can't see this activity at all. Local AI agents run as ordinary processes, with little of the visibility or context SOC teams need to understand — let alone investigate — what an agent actually did. That’s why today, we're extending Microsoft Defender to secure AI agents running locally on devices. Security teams now have the visibility, context, and control needed to manage this new frontier of endpoint risk without slowing down the developers driving innovation forward. This includes: Discover 20+ types of local AI agents running on managed Windows and macOS devices Block malicious AI agent activity on the device in real time Assess local agent exposure across identities and reachable resources Investigate local AI agent activity in Advanced Hunting In preview, Defender now discovers these agents across the endpoint — AI coding agents, AI assistants, local AI runtimes, agentic IDE extensions, and Model Context Protocol (MCP) servers — and adds runtime protection for popular coding agents, with coverage expanding over time. Just as important, it brings them into the same security platform teams already use for endpoints, identities, email, and cloud, so local agents are no longer running unseen alongside the tools security teams already protect, but part of one coordinated defense. Watch this episode of the Ninja Show to see how Microsoft Defender brings visibility, context, and control to local AI agents, helping security teams securely adopt AI and stay ahead of emerging threats. Discover local AI agents on managed devices Security Operation Center (SOC) teams can now identify AI agents running locally as first-class assets, not just operating system (OS) processes. In the Defender portal, security teams can view a dedicated inventory of AI agents across their environment, spanning categories such as: Coding CLIs and terminal agents: GitHub Copilot CLI, Codex CLI, Claude Code CLI, Gemini CLI, Antigravity CLI, OpenCode Agentic IDEs and VS Code extensions: Cursor, Windsurf, Antigravity, Claude Code, Codex, Cline, Gemini, GitHub Copilot, Roo Code Desktop AI assistants: ChatGPT Desktop, Claude Desktop, Codex Desktop, Poe Desktop, Antigravity Desktop, GitHub Copilot App Local AI runtimes and autonomous platforms: OpenClaw, Nanobot, ZeroClaw, Ollama Desktop Each agent is surfaced as a security asset, with runtime context including user identity, device and process relationships, trust indicators, and integrity level. Security teams can also see configuration signals, such as “auto-approve” settings and connected services via MCP servers. Defender discovers more than 20 supported local AI agents across Windows and macOS, with coverage continuing to expand. Block malicious AI agent activity in real time Discovery is the starting point. Once SOC teams know which agents are present, they need confidence that malicious behavior will be stopped to reduce impact to their organization’s environment. For popular coding agents, Defender now provides runtime protection that helps block malicious behavior inline and in real time. This capability starts with Claude Code and GitHub Copilot CLI, with OpenClaw and OpenAI Codex coming soon. When Defender identifies that an agent activity is malicious, it can automatically block it. As with other threats, the user can be notified, and the activity is logged in the protection history. The SOC analyst receives a detailed alert with agent and session context for investigation, including details on the detected threat. At the same time, the user sees a notification on the device that the activity was blocked. The corresponding security alert in the Defender portal, with the process tree and session context for investigation Assess local agent exposure Knowing an agent exists is only half the picture. The next step is mapping the potential blast radius: the resources the agent touches, the identities it can use, and the assets exposed to its next moves. That’s why every agent discovered is automatically mapped to the device it runs on, the identity associated with that device, the MCP servers it’s connected to, and the cloud resources the identity can reach. The exposure graph turns "this agent exists" into “this agent can do these things” by providing an understanding of the agent’s connectivity across your environment. As an example, in the map below, the SOC analyst can see that a ChatGPT Desktop agent is tied to a single AWS account, and from that identity its reach extends to S3 buckets, an AWS KMS key, EC2 instances, and an AWS Bedrock agent. The agent has no cloud permissions of its own, but it inherits the account's — so if it were compromised or misused, that reach becomes a path to encrypted data and key material. This view gives security teams a clear picture of the agent's blast radius, so they can decide how to contain it before it's abused. Investigate local AI agent activity in Advanced Hunting Beyond the inventory and exposure views, security teams often need to hunt across the environment — to ask which agents are behaving unusually, and what else they touch. Every AI agent discovery event, MCP server connection, and configuration signal is queryable in Advanced Hunting, alongside the endpoint, identity, email, and cloud security telemetry your team already uses every day. This capability unlocks two use cases that security teams have been asking for: Correlate agent activity with process, file, network, identity, and cloud telemetry to see the full picture of what the agent did Hunt for risky configurations – for example, agents running in auto-approve mode under an identity with privileged access to production, source code, or CI/CD systems Security teams can turn any of these queries into a custom detection rule — for instance, raising an alert whenever a newly discovered agent appears with a risky configuration on a device tied to a privileged identity. Securing the next frontier of endpoint activity The risk that opened this post — an agent acting on a malicious instruction and reaching everything its identity can touch — is exactly what this protection is built to contain. By bringing local AI agents into the same platform teams already use for endpoints, identities, and cloud, Defender turns that blind spot into something security teams can see, investigate, and stop — without getting in the developer's way. Developers keep the AI tools accelerating their work. Defenders get the visibility and real-time protection to stay ahead of attackers as they turn to this new surface. That balance — speed for builders, control for defenders — is what securing the AI era actually requires. Learn more Discover local AI agents with Microsoft Defender Block malicious AI agent behavior with runtime protection Manage and secure your agents with Microsoft Agent 365Organize your multitenant view with Tenant Groups in Microsoft Defender
Managing security across many tenants shouldn’t mean drowning in a single, flat list. We’re excited to share a new capability, now in public preview in the Microsoft Defender multitenant (MTO) portal: Tenant Groups—a flexible way to organize the tenants you manage and switch your view between them with a single click. If you’re a managed security service provider (MSSP), a cloud service provider (CSP), or a security team operating across multiple Entra ID tenants, this one’s for you. What’s new Tenant Groups let you create logical groupings of tenants (by customer segment, geography, criticality, onboarding stage—whatever fits how you work) and seamlessly switch the Defender MTO view to show data from only the tenants in that group. NOTICE: The feature previously called Tenant groups—used for content distribution—has been renamed to Deployment profiles. The name “Tenant Groups” now refers to this new grouping experience. Why it matters Focus, faster – Investigate incidents, hunt threats, and review posture against just the tenants you care about right now—without noise from the rest. Operational clarity – Group tenants the way your team actually works (e.g., Tier 1 customers, EMEA, Pilot rollout). Permissions-aware – Even if a Tenant Group contains more tenants, you’ll only see the ones where you have B2B/GDAP (granular delegated admin privileges) access. Your existing access controls stay in charge. Permissions you’ll need To work with Tenant Groups, your account needs one of the following: Entra ID roles Security Administrator Security Operator Global Administrator Product-specific (MDE, MDI, etc.) role-based access control (RBAC) Global Administrator Security Administrator Plus, any custom RBAC roles required to see data across products Unified RBAC (URBAC) Security/read—to view Tenant Groups Security/manage—to create Tenant Groups Remember: A Tenant Group can include tenants you don’t have access to. You’ll only ever see the ones your permissions allow. Getting started 1. Open Tenant Groups Sign in to the Microsoft Defender portal with administrative credentials, then navigate to Multitenant Management > Tenant Groups. You’ll find a built-in group called My private group that contains all the tenants from your previous setup. You can add or remove tenants from it, but it can’t be deleted. 2. Create a Tenant Group Select + Create tenant group. Give it a descriptive name (e.g., Healthcare customers, EMEA Tier 1). Optionally, add a description so teammates know the group’s intent. Select the tenants you want to include. That’s it—your group is ready. 3. Switch between Tenant Groups In the top-left corner of the portal, select Open multitenant management. Choose the group you just created. Navigate around the Defender MTO portal—incidents, alerts, devices, hunting—and you’ll see only data from the tenants in that group. Switch groups anytime to refocus. Live change detection: If a teammate edits a Tenant Group (adds or removes tenants) while you’re viewing it, the portal surfaces a notification so you know the underlying scope has changed. No stale views, no surprises. 4. Edit a Tenant Group Go back to Multitenant Management > Tenant Groups. Select the group and choose Edit. Add or remove tenants as your environment evolves, then re-test your views. Tips for getting the most out of Tenant Groups Start with how your team triages – Name groups after the workflows you actually run (On-call queue, Customer A—production). Keep groups small and purposeful – Overlapping, focused groups beat one giant catch-all. Pair with Deployment profiles – Use Tenant Groups for viewing, and Deployment profiles for distributing content—two clean, complementary concepts. Audit access regularly – Because group membership is independent of B2B/GDAP access, periodic reviews keep expectations aligned. We want your feedback Tenant Groups are designed around real multitenant operations work—and we’d love to hear how you’re using them. Try it out in your environment, share what’s working (and what isn’t), and let us know what you’d like to see next.
