Monitoring work from home
My boss has asked me if there is a way to see just how "busy" people who are working from home are. I have this data in Sentinel: Entra sign-in logs Defender for Endpoint logs Office 365 logs Most, if not all, on premise AD login events Netskope (current ZTNA solution) logs I have my known office location IPs so i could just exclude those and look for activity from other IPs however many times people will work in the morning or on the way to work appearing from a non corporate IP, come into the office appearing to come from a corporate IP, and then from home again in the evening. I need a way to query Sentinel looking for people who appear to be working but not coming from Corp IP. If they came from different IPs on the same day including Corp check to see if those non Corp are before and after business hours and exclude those. Anyone know of a good query to achieve this? Or maybe a tool that can extract and generate a report?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 LearnMonthly 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.Sentinel - Defender XDR KQL Queries Library
Hello all, I’ve been building something over the past few weeks that I think the security community might find useful. https://goxdr.fyi is a searchable KQL query library for Microsoft Sentinel and Defender XDR. The name comes from a nickname my colleagues gave me (GoX) combined with XDR. I also picked up https://goxdr.fyi as a short and easy to remember domain for it. You can check it out here: https://goxdr.fyi The idea came from my own day to day work as someone working in IAM and SOC operations. I constantly find myself writing and refining KQL queries for threat hunting, detection engineering and incident investigation. Over time I realized I had a growing collection of queries that I kept going back to and I thought why not make these available to others? It currently has 117 queries covering identity security, BEC/AiTM detection, NTLM and LDAP attack hunting, OAuth governance, AI/Copilot security, Sentinel alert trending, SOC performance metrics and more. Some of these queries are ones I wrote from scratch based on real scenarios I encountered in production environments. Others are community queries I tested and validated in my own setup. Only the ones I found genuinely useful and that actually worked against real data made it in. Each query comes with a description explaining what it detects and why it matters, along with severity levels, platform tags (Sentinel, XDR or both) and a copy button so you can paste it directly into Advanced Hunting or use it as the basis for an Analytics Rule. The site is open source, hosted on GitHub Pages and licensed under CC BY 4.0. No sign-up, no paywall, no tracking. The source is available. I’ll keep adding queries as new scenarios come up. If there’s enough interest I’m also considering adding Cortex XQL queries for Palo Alto environments. Suggestions, feedback or ideas for new detections are always welcome. Feel free to reach out. ThanksMonthly 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.Securing the invisible workforce
Non-human identities are now the majority of the identity estate in most enterprises. Service principals access organizational resources across SharePoint, Azure, and Microsoft 365, Service accounts run critical business processes on-premises, OAuth apps move data across SaaS boundaries, and AI agents increasingly operate autonomously at machine speed. As NHIs have grown in number and importance, so to have the threats targeting them. Midnight Blizzard showed how damaging compromised NHI can be. Attackers moved laterally across cloud resources and accessed sensitive data without ever triggering user-centric controls like MFA. The challenge many security teams are faced with however is that they simply do not have the visibility into what NHI’s even exist within their organization. Unlike their human counterparts, NHI can vary drastically in purpose, behaviour and risk profile. The one consistency is that most organizations lack a formal process for their creation, management and governance. For instance, while these identities often carry high and standing privileges, those permissions are typically granted at creation and never revisited. They authenticate programmatically so they cannot be enrolled in, or benefit from the protections of multi-factor authentication. As AI adoption accelerates, this issue has become even more urgent. Every AI agent needs an identity to function. That identity accesses data, invokes APIs, and takes action, autonomously, continuously, and at an unprecedented velocity. But because AI tooling has moved faster than guidance, many agents were never given identities of their own, many riding on existing Service Principles. This means that those ordinary app registrations may in fact represent autonomous agents making decisions and taking action. This new reality further compresses the window between compromise and impact and makes securing non-human identities a prerequisite for safely deploying AI at enterprise scale. Today, I am excited to share more about the non-human identity protection available within Microsoft Defender. These capabilities bring NHIs into the same unified platform where security teams already work and protect human identities with purpose-built experiences for discovery, risk assessment, business context, governance, threat detection, and attack disruption. The Challenge: We hear consistently from customers that they cannot answer fundamental questions about their NHI estate: How many non-human identities exist? Across Entra ID, Active Directory, and SaaS applications, the true count consistently exceeds expectations, often by an order of magnitude. Which ones are still in use? NHIs accumulate over time. Decommissioning is rare and dormant identities retain active permissions indefinitely. Which ones hold more access than they need? Permissions are granted broadly at provisioning and seldom revisited. Over-privilege is not the exception—it is the default state. Who is responsible for them? Without established ownership, remediating a risky NHI requires significant manual effort just to identify the right person to engage. Which ones are powering AI agents? Many agents ride on NHIs created long before the agent existed, making them indistinguishable from routine integrations. These are the questions that drive the capabilities we are delivering. Raising the bar for NHI protection with Defender Microsoft Defender helps protect non-human identities through six integrated focus areas: Visibility, Risk analysis, relationships and access mapping, governance policies, AI Agent awareness and Detection and Disruption. Together, these areas help organizations discover NHI risk, understand relationships and permissions, enforce governance, identify AI-driven identity activity, and detect or disrupt threats before they escalate. 1. Visibility: When Entra service principals, Active Directory service accounts, and SaaS-connected OAuth apps are managed in separate consoles with separate workflows, security teams cannot form a coherent picture of NHI exposure. These gaps in visibility translate directly into gaps in protection. Defender delivers a unified identity inventory for both human and non-human identities within a single view and investigation workflow. For non-human identities, coverage includes: Source Coverage Microsoft Entra ID All service principals Active Directory All service accounts SaaS Apps All OAuth-connected apps This consolidated inventory is the foundation that security insights, risk scoring, business context, governance, and threat detection all build on. Security teams work from one place, using the same investigation workflows they already use for human identities, across the entire NHI population. 2. Risk insights and analysis: Visibility into what exists is the starting point. What security teams need next is a clear understanding of which identities carry risk, what kind of risk, and how they should prioritize. Similar to how we review risk signals for human identities, Defender continuously evaluates the NHI estate and surfaces findings across key risk pivots: Unused Identities NHIs that have not authenticated over extended periods but retain active permissions. These identities serve no current business purpose while remaining fully available for misuse if compromised. Over-Privileged Identities NHIs whose granted permissions significantly exceed their observed usage. Defender analyses the gap between what an identity can do and what it actually does, identifying where privilege can be safely reduced without impacting operations. High-Privileged Identities Some NHI’s however require elevated roles or broad permissions to perform their intended use. These NHIs pose the highest lateral movement risk if compromised. For context, these privileges can sometimes exceed the access held by admins in the organization. Identity Risk Score for NHIs The new Identity Risk Score within Defender also extends to NHI. Ever NHI now has a dynamic risk score , informed by Microsoft’s global threat intelligence, exposure indicators, and observed activity patterns. The score is fully explainable. For every NHI, Defender shows the specific factors that contributed—what combination of privilege, exposure, and activity drove the assessment, and why. Analysts see the reasoning directly: an identity scored high because it is unused, holds broad directory permissions, and is published by an unverified publisher. This means analysts can act on the score with confidence, without needing to conduct a separate investigation to understand what it means. These insights allow teams to rank their entire NHI estate by risk and systematically focus investigation where it matters most. 3. Relationship mapping: Knowing that an NHI is risky is necessary but not sufficient for remediation. Security teams need business context: what application depends on this identity, who owns it, what resources can it access, and with what permissions. Without this information, even a critical finding stalls. Can we disable this identity, or will it break a production workflow? Who do we contact to coordinate? What is the scope of exposure if this identity is compromised? Defender introduces a Graph for NHIs that visually maps these relationships directly. What application depends on this NHI? Understanding downstream dependencies before taking remediation action. Who owns it? Identifying the owner for coordinated response. What resources or crown jewels does it access, and with what permissions? Determining the sensitivity of accessed resources to assess actual severity. With this context directly available in the investigation experience, security teams can assess risk, evaluate business impact, and coordinate remediation without switching tools or conducting manual discovery. 4. Governance policies When we extrapolate this out to enterprise scale, with thousands to tens of thousands of NHIs, manual remediation simply cannot keep pace with the rate at which risk accumulates. Organizations need governance policies that enforce decisions automatically and consistently. Defender enables this through governance policies. Organizations can define policies that leverage the insights Defender surfaces like unused timeframe, privilege level, risk score, over-privilege status, AI agent association and then map them to automated disablement of identities that exceed acceptable risk. Example: An NHI that has been unused for 90+ days, holds high-privilege roles, and carries a risk score above 70 exceeds the organization’s risk tolerance → disable the identity. This shifts NHI security from periodic audit cycles to continuous posture management. The NHI estate stays within organizational risk tolerance because policy enforces the standard automatically, at the scale the environment demands. 5. AI Agent awareness Agents built on platforms like Copilot Studio, Azure AI Foundry, and third-party frameworks require identities to authenticate, access data, and take action. In practice, many agents operate using traditional NHI that were provisioned for other workloads, making them indistinguishable from routine integrations at the identity layer. The risk profile, however, is materially different: Agents are autonomous. They make decisions and execute actions without human approval at each step. Agents are high-velocity. They perform hundreds of operations per minute across multiple systems. Agents interact with sensitive data. They access documents, query databases, read communications, and invoke APIs, often with broad permissions to support flexible workflows. When a misconfigured identity backs an AI agent, the risk compounds significantly because the agent continues to operate autonomously, with legitimate access, at machine speed, across whatever resources it can reach. Defender infers which NHIs are used by AI agents and surfaces this signal directly in the inventory, risk insights, and assessment. This enables security teams to prioritize investigation of agent-backed NHIs and apply differentiated governance like stricter controls, shorter review cycles, and tighter privilege boundaries for identities backing 6. Detection and disruption Posture and governance reduce the attack surface. But when an attacker compromises a non-human identity, detection speed and response automation determine whether the attack is contained or succeeds. Microsoft Defender brings the same detection and disruption capabilities that protect human identities to the non-human estate. Threat Detection for NHIs Defender detects anomalous and malicious activity involving non-human identities using behavioral analytics and Microsoft’s global threat intelligence. Detections are purpose-built for how NHIs operate because the signals indicating compromise in a NHI is fundamentally different from those in a human account, and our detection models reflect that. Every alert is enriched with full context from the identity inventory, risk insights, and graph. Analysts see not just what happened, but which identity was involved, what it can reach, who owns it, and how critical it is immediately, without manual correlation. Disrupting Attacker Persistence We are introducing new disruption capabilities designed to address the persistence techniques attackers use against non-human identities. These capabilities focus on the specific actions that turn a legitimate non-human Identity into an attack path, such as adding credentials for off-tenant use or modifying permissions and role assignments to expand access. Rather than broad remediation, the approach targets the exact moves attackers use to establish and maintain control. By directly addressing actions like unauthorized credential additions and privilege expansion, these capabilities help remove attacker access while preserving legitimate application functionality. Why This Maters Every AI agent requires an identity. As organizations scale agent deployments, the NHI estate grows with them and inherits every existing gap: over-privilege, absent ownership, insufficient monitoring. What has changed is speed. An AI agent with a compromised identity operates autonomously and never sleeps. The window between compromise and impact has compressed to the point where periodic manual review is no longer adequate. Automated visibility, continuous risk assessment, policy-driven governance, and real-time detection and disruption are now requirements. The organizations investing in NHI protection today are building the security foundation their AI strategy depends on. Getting Started Non-human identity protection is available in Microsoft Defender today: Visit the unified identity inventory in Defender to see all NHIs across Entra ID, Active Directory, and SaaS. Review risk insights to identify unused, over-privileged, high-risk NHIs, and NHIs used by agents. Explore the identity graph to understand business context, ownership, and resource access. Configure risk-based governance policies to enforce organizational risk tolerance at scale. These capabilities are integrated into the same platform and workflows security teams already use for human identity protection—no separate tools, no additional deployment. Learn more about the NHI protections provided by Defender within our docs here.Why UK Enterprise Cybersecurity Is Failing in 2026 (And What Leaders Must Change)
Enterprise cybersecurity in large organisations has always been an asymmetric game. But with the rise of AI‑enabled cyber attacks, that imbalance has widened dramatically - particularly for UK and EMEA enterprises operating complex cloud, SaaS, and identity‑driven environments. Microsoft Threat Intelligence and Microsoft Defender Security Research have publicly reported a clear shift in how attackers operate: AI is now embedded across the entire attack lifecycle. Threat actors use AI to accelerate reconnaissance, generate highly targeted phishing at scale, automate infrastructure, and adapt tactics in real time - dramatically reducing the time required to move from initial access to business impact. In recent months, Microsoft has documented AI‑enabled phishing campaigns abusing legitimate authentication mechanisms, including OAuth and device‑code flows, to compromise enterprise accounts at scale. These attacks rely on automation, dynamic code generation, and highly personalised lures - not on exploiting traditional vulnerabilities or stealing passwords. The Reality Gap: Adaptive Attackers vs. Static Enterprise Defences Meanwhile, many UK enterprises still rely on legacy cybersecurity controls designed for a very different threat model - one rooted in a far more predictable world. This creates a dangerous "Resilience Gap." Here is why your current stack is failing- and the C-Suite strategy required to fix it. 1. The Failure of Traditional Antivirus in the AI Era Traditional antivirus (AV) relies on static signatures and hashes. It assumes malicious code remains identical across different targets. AI has rendered this assumption obsolete. Modern malware now uses automated mutation to generate unique code variants at execution time, and adapts behaviour based on its environment. Microsoft Threat Intelligence has observed threat actors using AI‑assisted tooling to rapidly rewrite payload components, ensuring that every deployment looks subtly different. In this model, there is no reliable signature to detect. By the time a pattern exists, the attacker has already moved on. Signature‑based detection is not just slow - it is structurally misaligned with AI‑driven attacks. The Risk: If your security relies on "recognising" a threat, you are already breached. By the time a signature exists, the attacker has evolved. The C-Suite Pivot: Shift investment from artifact detection to EDR/XDR (Extended Detection and Response). We must prioritise behavioural analytics and machine learning models that identify intent rather than file names. 2. Why Perimeter Firewalls Fail in a Cloud-First World Many UK enterprise still rely on firewalls enforcing static allow/deny rules based on IP addresses and ports. This model worked when applications were predictable and networks clearly segmented. Today, enterprise traffic is encrypted, cloud‑hosted, API‑driven, and deeply integrated with SaaS and identity services. AI‑assisted phishing campaigns abusing OAuth and device‑code flows demonstrate this clearly. From a network perspective, everything looks legitimate: HTTPS traffic to trusted identity providers. No suspicious port. No malicious domain. Yet the attacker successfully compromises identity. The Risk: Traditional firewalls are "blind" to identity-based breaches in cloud environments. The C-Suite Pivot: Move to Identity-First Security. Treat Identity as the new Control Plane, integrating signals like user risk, device health, and geolocation into every access decision. 3. The Critical Weakness of Single-Factor Authentication Despite clear NCSC guidance, single-factor passwords remain a common vulnerability in legacy applications and VPNs. AI-driven credential abuse has changed the economics of these attacks. Threat actors now deploy adaptive phishing campaigns that evolve in real-time. Microsoft has observed attackers using AI to hyper-target high-value UK identities- specifically CEOs, Finance Directors, and Procurement leads. The Risk: Static passwords are now the primary weak link in UK supply chain security. The C-Suite Pivot: Mandate Phishing‑resistant MFA (Passkeys or hardware security keys). Implement Conditional Access policies that evaluate risk dynamically at the moment of access, not just at login. Legacy Security vs. AI‑Era Reality 4. The Inherent Risk of VPN-Centric Security VPNs were built on a flawed assumption: that anyone "inside" the network is trustworthy. In 2026, this logic is a liability. AI-assisted attackers now use automation to map internal networks and identify escalation paths the moment they gain VPN access. Furthermore, Microsoft has tracked nation-state actors using AI to create synthetic employee identities- complete with fake resumes and deepfake communication. In these scenarios, VPN access isn't "hacked"; it is legally granted to a fraudster. The Risk: A compromised VPN gives an attacker the "keys to the kingdom." The C-Suite Pivot: Transition to Zero Trust Architecture (ZTA). Access must be explicit, scoped to the specific application, and continuously re‑evaluated using behavioural signals. 5. Data: The High-Velocity Target Sensitive data sitting unencrypted in legacy databases or backups is a ticking time bomb. In the AI era, data discovery is no longer a slow, manual process for a hacker. Attackers now use AI to instantly analyse your directory structures, classify your files, and prioritise high-value data for theft. Unencrypted data significantly increases your "blast radius," turning a containable incident into a catastrophic board-level crisis. The Risk: Beyond the technical breach, unencrypted data leads to massive UK GDPR fines and irreparable brand damage. The C-Suite Pivot: Adopt Data-Centric Security. Implement encryption by default, classify data while adding sensitivity labels and start board-level discussions regarding post‑quantum cryptography (PQC) to future-proof your most sensitive assets. 6. The Failure of Static IDS Traditional Intrusion Detection Systems (IDS) rely on known indicators of compromise - assuming attackers reuse the same tools and techniques. AI‑driven attacks deliberately avoid that assumption. Threat actors are now using Large Language Models (LLMs) to weaponize newly disclosed vulnerabilities within hours. While your team waits for a "known pattern" to be updated in your system, the attacker is already using a custom, AI-generated exploit. The Risk: Your team is defending against yesterday's news while the attacker is moving at machine speed. The C-Suite Pivot: Invest in Adaptive Threat Detection. Move toward Graph‑based XDR platforms that correlate signals across email, endpoint, and cloud to automate investigation and response before the damage spreads. From Static Security to Continuous Security Closing Thought: Security Is a Journey, Not a Destination For UK enterprises, the shift toward adaptive cybersecurity is no longer optional - it is increasingly driven by regulatory expectation, board oversight, and accountability for operational resilience. Recent UK cyber resilience reforms and evolving regulatory frameworks signal a clear direction of travel: cybersecurity is now a board‑level responsibility, not a back‑office technical concern. Directors and executive leaders are expected to demonstrate effective governance, risk ownership, and preparedness for cyber disruption - particularly as AI reshapes the threat landscape. AI is not a future cybersecurity problem. It is a current force multiplier for attackers, exposing the limits of legacy enterprise security architectures faster than many organisations are willing to admit. The uncomfortable truth for boards in 2026 is that no enterprise is 100% secure. Intrusions are inevitable. Credentials will be compromised. Controls will be tested. The difference between a resilient enterprise and a vulnerable one is not the absence of incidents, but how risk is managed when they occur. In mature organisations, this means assuming breach and designing for containment: Access controls that limit blast radius Least privilege and conditional access restricting attackers to the smallest possible scope if an identity is compromised Data‑centric security using automated classification and encryption, ensuring that even when access is misused, sensitive data cannot be freely exfiltrated As a Senior Enterprise Cybersecurity Architect, I see this moment as a unique opportunity. AI adoption does not have to repeat the mistakes of earlier technology waves, where innovation moved fast and security followed years later. We now have a rare chance to embed security from day one - designing identity controls, data boundaries, automated monitoring, and governance before AI systems become business‑critical. When security is built in upfront, enterprises don’t just reduce risk - they gain the confidence to move faster and unlock AI’s value safely. Security is no longer a “department”. In the age of AI, it is a continuous business function - essential to preserving trust and maintaining operational continuity as attackers move at machine speed. References: Inside an AI‑enabled device code phishing campaign | Microsoft Security Blog AI as tradecraft: How threat actors operationalize AI | Microsoft Security Blog Detecting and analyzing prompt abuse in AI tools | Microsoft Security Blog Post-Quantum Cryptography | CSRC Microsoft Digital Defense Report 2025 | Microsoft https://www.ncsc.gov.uk/news/government-adopt-passkey-technology-digital-servicesAuthorization and Governance for AI Agents: Runtime Authorization Beyond Identity at Scale
Designing Authorization‑Aware AI Agents at Scale Enforcing Runtime RBAC + ABAC with Approval Injection (JIT) Microsoft Entra Agent Identity enables organizations to govern and manage AI agent identities in Copilot Studio, improving visibility and identity-level control. However, as enterprises deploy multiple autonomous AI agents, identity and OAuth permissions alone cannot answer a more critical question: “Should this action be executed now, by this agent, for this user, under the current business and regulatory context?” This post introduces a reusable Authorization Fabric—combining a Policy Enforcement Point (PEP) and Policy Decision Point (PDP)—implemented as a Microsoft Entra‑protected endpoint using Azure Functions/App Service authentication. Every AI agent (Copilot Studio or AI Foundry/Semantic Kernel) calls this fabric before tool execution, receiving a deterministic runtime decision: ALLOW / DENY / REQUIRE_APPROVAL / MASK Who this is for Anyone building AI agents (Copilot Studio, AI Foundry/Semantic Kernel) that call tools, workflows, or APIs Organizations scaling to multiple agents and needing consistent runtime controls Teams operating in regulated or security‑sensitive environments, where decisions must be deterministic and auditable Why a V2? Identity is necessary—runtime authorization is missing Entra Agent Identity (preview) integrates Copilot Studio agents with Microsoft Entra so that newly created agents automatically get an Entra agent identity, manageable in the Entra admin center, and identity activity is logged in Entra. That solves who the agent is and improves identity governance visibility. But multi-agent deployments introduce a new risk class: Autonomous execution sprawl — many agents, operating with delegated privileges, invoking the same backends independently. OAuth and API permissions answer “can the agent call this API?” They do not answer “should the agent execute this action under business policy, compliance constraints, data boundaries, and approval thresholds?” This is where a runtime authorization decision plane becomes essential. The pattern: Microsoft Entra‑Protected Authorization Fabric (PEP + PDP) Instead of embedding RBAC logic independently inside every agent, use a shared fabric: PEP (Policy Enforcement Point): Gatekeeper invoked before any tool/action PDP (Policy Decision Point): Evaluates RBAC + ABAC + approval policies Decision output: ALLOW / DENY / REQUIRE_APPROVAL / MASK This Authorization Fabric functions as a shared enterprise control plane, decoupling authorization logic from individual agents and enforcing policies consistently across all autonomous execution paths. Architecture (POC reference architecture) Use a single runtime decision plane that sits between agents and tools. What’s important here Every agent (Copilot Studio or AI Foundry/SK) calls the Authorization Fabric API first The fabric is a protected endpoint (Microsoft Entra‑protected endpoint required) Tools (Graph/ERP/CRM/custom APIs) are invoked only after an ALLOW decision (or approval) Trust boundaries enforced by this architecture Agents never call business tools directly without a prior authorization decision The Authorization Fabric validates caller identity via Microsoft Entra Authorization decisions are centralized, consistent, and auditable Approval workflows act as a runtime “break-glass” control for high-impact actions This ensures identity, intent, and execution are independently enforced, rather than implicitly trusted. Runtime flow (Decision → Approval → Execution) Here is the runtime sequence as a simple flow (you can keep your Mermaid diagram too). ```mermaid flowchart TD START(["START"]) --> S1["[1] User Request"] S1 --> S2["[2] Agent Extracts Intent\n(action, resource, attributes)"] S2 --> S3["[3] Call /authorize\n(Entra protected)"] S3 --> S4 subgraph S4["[4] PDP Evaluation"] ABAC["ABAC: Tenant · Region · Data Sensitivity"] RBAC["RBAC: Entitlement Check"] Threshold["Approval Threshold"] ABAC --> RBAC --> Threshold end S4 --> Decision{"[5] Decision?"} Decision -->|"ALLOW"| Exec["Execute Tool / API"] Decision -->|"MASK"| Masked["Execute with Masked Data"] Decision -->|"DENY"| Block["Block Request"] Decision -->|"REQUIRE_APPROVAL"| Approve{"[6] Approval Flow"} Approve -->|"Approved"| Exec Approve -->|"Rejected"| Block Exec --> Audit["[7] Audit & Telemetry"] Masked --> Audit Block --> Audit Audit --> ENDNODE(["END"]) style START fill:#4A90D9,stroke:#333,color:#fff style ENDNODE fill:#4A90D9,stroke:#333,color:#fff style S1 fill:#5B5FC7,stroke:#333,color:#fff style S2 fill:#5B5FC7,stroke:#333,color:#fff style S3 fill:#E8A838,stroke:#333,color:#fff style S4 fill:#FFF3E0,stroke:#E8A838,stroke-width:2px style ABAC fill:#FCE4B2,stroke:#999 style RBAC fill:#FCE4B2,stroke:#999 style Threshold fill:#FCE4B2,stroke:#999 style Decision fill:#fff,stroke:#333 style Exec fill:#2ECC71,stroke:#333,color:#fff style Masked fill:#27AE60,stroke:#333,color:#fff style Block fill:#C0392B,stroke:#333,color:#fff style Approve fill:#F39C12,stroke:#333,color:#fff style Audit fill:#3498DB,stroke:#333,color:#fff ``` Design principle: No tool execution occurs until the Authorization Fabric returns ALLOW or REQUIRE_APPROVAL is satisfied via an approval workflow. Where Power Automate fits (important for readers) In most Copilot Studio implementations, Agents calls Power Automate (agent flows), is the practical integration layer that calls enterprise services and APIs. Copilot Studio supports “agent flows” as a way to extend agent capabilities with low-code workflows. For this pattern, Power Automate typically: acquires/uses the right identity context for the call (depending on your tenant setup), and calls the /authorize endpoint of the Authorization Fabric, returns the decision payload to the agent for branching. Copilot Studio also supports calling REST endpoints directly using the HTTP Request node, including passing headers such as Authorization: Bearer <token>. Protected endpoint only: Securing the Authorization Fabric with Microsoft Entra For this V2 pattern, the Authorization Fabric must be protected using Microsoft Entra‑protected endpoint on Azure Functions/App Service (built‑in auth). Microsoft Learn provides the configuration guidance for enabling Microsoft Entra as the authentication provider for Azure App Service / Azure Functions. Step 1 — Create the Authorization Fabric API (Azure Function) Expose an authorization endpoint: HTTP Step 2 — Enable Microsoft Entra‑protected endpoint on the Function App In Azure Portal: Function App → Authentication Add identity provider → Microsoft Choose Workforce configuration (enterprise tenant) Set Require authentication for all requests This ensures the Authorization Fabric is not callable without a valid Entra token. Step 3 — Optional hardening (recommended) Depending on enterprise posture, layer: IP restrictions / Private endpoints APIM in front of the Function for rate limiting, request normalization, centralized logging (For a POC, keep it minimal—add hardening incrementally.) Externalizing policy (so governance scales) To make this pattern reusable across multiple agents, policies should not be hardcoded inside each agent. Instead, store policy definitions in a central policy store such as Cosmos DB (or equivalent configuration store), and have the PDP load/evaluate policies at runtime. Why this matters: Policy changes apply across all agents instantly (no agent republish) Central governance + versioning + rollback becomes possible Audit and reporting become consistent across environments (For the POC, a single JSON document per policy pack in Cosmos DB is sufficient. For production, add versioning and staged rollout.) Store one PolicyPack JSON document per environment (dev/test/prod). Include version, effectiveFrom, priority for safe rollout/rollback. Minimal decision contract (standard request / response) To keep the fabric reusable across agents, standardize the request payload. Request payload (example) Decision response (deterministic) Example scenario (1 minute to understand) Scenario: A user asks a Finance agent to create a Purchase Order for 70,000. Even if the user has API permission and the agent can technically call the ERP API, runtime policy should return: REQUIRE_APPROVAL (threshold exceeded) trigger an approval workflow execute only after approval is granted This is the difference between API access and authorized business execution. Sample Policy Model (RBAC + ABAC + Approval) This POC policy model intentionally stays simple while demonstrating both coarse and fine-grained governance. 1) Coarse‑grained RBAC (roles → actions) FinanceAnalyst CreatePO up to 50,000 ViewVendor FinanceManager CreatePO up to 100,000 and/or approve higher spend 2) Fine‑grained ABAC (conditions at runtime) ABAC evaluates context such as region, classification, tenant boundary, and risk: 3) Approval injection (Agent‑level JIT execution) For higher-risk/high-impact actions, the fabric returns REQUIRE_APPROVAL rather than hard deny (when appropriate): How policies should be evaluated (deterministic order) To ensure predictable and auditable behavior, evaluate in a deterministic order: Tenant isolation & residency (ABAC hard deny first) Classification rules (deny or mask) RBAC entitlement validation Threshold/risk evaluation Approval injection (JIT step-up) This prevents approval workflows from bypassing foundational security boundaries such as tenant isolation or data sovereignty. Copilot Studio integration (enforcing runtime authorization) Copilot Studio can call external REST APIs using the HTTP Request node, including passing headers such as Authorization: Bearer <token> and binding response schema for branching logic. Copilot Studio also supports using flows with agents (“agent flows”) to extend capabilities and orchestrate actions. Option A (Recommended): Copilot Studio → Agent Flow (Power Automate) → Authorization Fabric Why: Flows are a practical place to handle token acquisition patterns, approval orchestration, and standardized logging. Topic flow: Extract user intent + parameters Call an agent flow that: calls /authorize returns decision payload Branch in the topic: If ALLOW → proceed to tool call If REQUIRE_APPROVAL → trigger approval flow; proceed only if approved If DENY → stop and explain policy reason Important: Tool execution must never be reachable through an alternate topic path that bypasses the authorization check. Option B: Direct HTTP Request node to Authorization Fabric Use the Send HTTP request node to call the authorization endpoint and branch using the response schema. This approach is clean, but token acquisition and secure secretless authentication are often simpler when handled via a managed integration layer (flow + connector). AI Foundry / Semantic Kernel integration (tool invocation gate) For Foundry/SK agents, the integration point is before tool execution. Semantic Kernel supports Azure AI agent patterns and tool integration, making it a natural place to enforce a pre-tool authorization check. Pseudo-pattern: Agent extracts intent + context Calls Authorization Fabric Enforces decision Executes tool only when allowed (or after approval) Telemetry & audit (what Security Architects will ask for) Even the best policy engine is incomplete without audit trails. At minimum, log: agentId, userUPN, action, resource decision + reason + policyIds approval outcome (if any) correlationId for downstream tool execution Why it matters: you now have a defensible answer to: “Why did an autonomous agent execute this action?” Security signal bonus: Denials, unusual approval rates, and repeated policy mismatches can also indicate prompt injection attempts, mis-scoped agents, or governance drift. What this enables (and why it scales) With a shared Authorization Fabric: Avoid duplicating authorization logic across agents Standardize decisions across Copilot Studio + Foundry agents Update governance once (policy change) and apply everywhere Make autonomy safer without blocking productivity Closing: Identity gets you who. Runtime authorization gets you whether/when/how. Copilot Studio can automatically create Entra agent identities (preview), improving identity governance and visibility for agents. But safe autonomy requires a runtime decision plane. Securing that plane as an Entra-protected endpoint is foundational for enterprise deployments. In enterprise environments, autonomous execution without runtime authorization is equivalent to privileged access without PIM—powerful, fast, and operationally risky.Announcing public preview of custom graphs in Microsoft Sentinel
Security attacks span identities, devices, resources, and activity, making it critical to understand how these elements connect to expose real risk. In November, we shared how Sentinel graph brings these signals together into a relationship-aware view to help uncover hidden security risks. We’re excited to announce the public preview of custom graphs in Sentinel, available starting April 1 st . Custom graphs let defenders model relationships that are unique to their organization, then run graph analytics to surface blast radius, attack paths, privilege chains, chokepoints, and anomalies that are difficult to spot in tables alone. In this post, we’ll cover what custom graphs are, how they work, and how to get started so the entire team can use them. Custom graphs Security data is inherently connected: a sign-in leads to a token, a token touches a workload, a workload accesses data, and data movement triggers new activity. Graphs represent these relationships as nodes (entities) and edges (relationships), helping you answer questions like: “Who received the phishing email, who clicked, and which clicks were allowed by the proxy?” or “Show me users who exported notebooks, staged files in storage, then uploaded data to personal cloud storage- the full, three‑phase exfiltration chain through one identity.” With custom graphs, security teams can build, query, and visualize tailored security graphs using data from the Sentinel data lake and non-Microsoft sources, powered by Fabric. By uncovering hidden patterns and attack paths, graphs provide the relationship context needed to surface real risk. This context strengthens AI‑powered agent experiences, speeds investigations, clarifies blast radius, and helps teams move from noisy, disconnected alerts to confident decisions. In the words of our preview customers: “We ingested our Databricks management-plane telemetry into the Sentinel data lake and built a custom security graph. Without writing a single detection rule, the graph surfaced unusual patterns of activity and overprivileged access that we escalated for investigation. We didn't know what we were looking for, the graph surfaced the risk for us by revealing anomalous activity patterns and unusual access combinations driven by relationships, not alerts.” – SVP, Security Solutions | Financial Services organization Use cases Sentinel graph offers embedded, Microsoft managed, security graphs in Defender and Microsoft Purview experiences to help you at every stage of defense, from pre-breach to post-breach and across assets, activities, and threat intelligence. See here for more details. The new custom graph capability gives you full control to create your own graphs combining data from Microsoft sources, non-Microsoft sources, and federated sources in the Sentinel data lake. With custom graphs you can: Understand blast radius – Trace phishing campaigns, malware spread, OAuth abuse, or privilege escalation paths across identities, devices, apps, and data, without stitching together dozens of tables. Reconstruct real attack chains – Model multi-step attacker behavior (MITRE techniques, lateral movement, before/after malware) as connected sequences so investigations are complete and explainable, not a set of partial pivots. Reconstruct these chains from historical data in the Sentinel data lake. Figure 2: Drill into which specific MITRE techniques each IP is executing and in which tactic category Spot hidden risks and anomalies – Detect structural outliers like users with unusually broad access, anomalous email exfiltration, or dangerous permission combinations that are invisible in flat logs. Figure 3: OAuth consent chain – a single compromised user consented four dangerous permissions Creating custom graph Using the Sentinel VS Code extension, you can generate graphs to validate hunting hypotheses, such as understanding attack paths and blast radius of a phishing campaign, reconstructing multi‑step attack chains, and identifying structurally unusual or high‑risk behavior, making it accessible to your team and AI agents. Once persisted via a schedule job, you can access these custom graphs from the ready-to-use section in the graphs section in the Defender portal. Figure 4: Use AI-assisted vibe coding in Visual Studio Code to create tailored security graphs powered by Sentinel data lake and Fabric Graphs experience in the Microsoft Defender portal After creating your custom graphs, you can access them in the Graphs section of the Microsoft Defender portal under Sentinel. From there, you can perform interactive, graph-based investigations, for example, using a graph built for phishing analysis to quickly evaluate the impact of a recent incident, profile the attacker, and trace paths across Microsoft telemetry and third-party data. The graph experience lets you run Graph Query Language (GQL) queries, view the graph schema, visualize results, see results in a table, and interactively traverse to the next hop with a single click. Figure 5: Query, visualize, and traverse custom graphs with the new graph experience in Sentinel Billing Custom graph API usage for creating graph and querying graph is billed according to the Sentinel graph meter. Get started To use custom graphs, you’ll need Microsoft Sentinel data lake enabled in your tenant, since the lake provides the scalable, open-format foundation that custom graphs build on. Use the Sentinel data lake onboarding flow to provision the data lake if it isn’t already enabled. Ensure the required connectors are configured to populate your data lake. See Manage data tiers and retention in Microsoft Sentinel | Microsoft Learn. Create and persist a custom graph. See Get started with custom graphs in Microsoft Sentinel (preview) | Microsoft Learn. Run adhoc graph queries and visualize graph results. See Visualize custom graphs in Microsoft Sentinel graph (preview) | Microsoft Learn. [Optional] Schedule jobs to write graph query results to the lake tier and analytics tier using notebooks. See Exploring and interacting with lake data using Jupyter Notebooks - Microsoft Security | Microsoft Learn. Learn more Earlier posts (Sentinel graph general availability) RSAC 2026 announcement roundup Custom graphs documentation Custom graph billingRedefining identity security for the modern enterprise
Every breach has one thing in common: an identity was exploited. Attackers have learned that identity is the fastest path to lateral movement and escalation. The challenge for defenders is that today's identity landscape is vast and fragmented — spanning hybrid environments, SaaS apps, cloud platforms, and autonomous agents. Protecting it demands more than point solutions. It requires continuous visibility, proactive posture reduction, and the ability to detect and disrupt identity threats across the full attack lifecycle. Leveraging our expertise as a leader in both Identity and Access Management (IAM) and Security, our focus has been to deliver a fast, comprehensive, and increasingly autonomous approach to identity security. It is designed to continuously strengthen identity posture and help SOC teams act faster with less manual effort. Today, I am excited to announce the next set of innovations including: Reimagined Identity Security dashboard and experiences to surface identity insights Expanded protection for more elements of modern identity fabrics including non-human identities. Streamlined detections including a new identity-level risk score that can be applied directly within risk-based conditional access policies. Unified identity view & protection across Active Directory, Entra ID, IAM solutions, SaaS and Cloud – with improved at-scale identity correlations New autonomous response capabilities to further speed identity threat triage, disruption and response. Below is a deeper look at what’s new. Turning identity sprawl into clarity Security teams don’t suffer from a lack of identity data — they suffer from a lack of insight across that data. Without context, the flood of activity from various directories, SaaS platforms, cloud services, and on‑premises infrastructure simply becomes noise. Disconnected alerts, isolated accounts, and fragmented investigations make it harder, not easier, to determine what actually matters. The updated Identity security dashboard is one of the new experiences designed to help with just that. It serves as the starting point for the SOC to gain a birds eye view of their entire identity security status, surfacing critical information on the human and non-human identities from across on-premises, SaaS and cloud environments. Fueling this, and other identity security experiences within Defender, are the advancements we have made in unifying the identity inventories. First, for human users we have expanded the account correlation capabilities we released at Ignite to include SaaS and cloud accounts. This means that security professionals will have an even more comprehensive view of related accounts, their holistic posture and identity risk. Additionally, we are also introducing new, policy-based linkage to help organizations customize these connections at scale. But modern identity fabrics extend far beyond human users. To address this shift, we are also expanding identity security coverage to include a greater focus on non‑human identities. The new non‑human identity inventory helps security teams to discover, understand, and protect these critical identities within the same identity‑centric view as human accounts. Defender helps teams see the full identity fabric — not as disconnected components, but as an interconnected system — so they can reduce blind spots, prioritize exposure, and apply consistent protection across the identities attackers increasingly rely on. Expanded coverage across the modern identity fabric Staying one step ahead of attackers starts with having a better understanding of what makes you vulnerable and closing those gaps before they can be exploited. With this mission in mind, I am excited to announce a new coverage and maturity view that shows how identity infrastructure, protections, and risk actually connect across your environment. This view serves as a snapshot revealing which access paths are protected, which are exposed, and what to fix next to meaningfully reduce blast radius. Rather than treating coverage as a static checklist, this experience surfaces actionable insights that show both current status and prioritized next steps, helping teams understand not only what needs to be protected, but also how to systematically improve identity security posture over time. With this clear guidance Defender empowers SOC teams to move from fragmented awareness to confident, identity‑centric protection. This new view is powered by the native integration available out-of-the-box with Microsoft Entra ID and the dedicated sensors and connectors available for other identity components like Privilege Access Management (PAM) solutions and other identity providers. Given this, I am pleased to share that we are adding new integrations with solutions like SailPoint and CyberArk that further our commitment to bringing additional depth and coverage for more elements of modern identity landscapes within Defender. In this same vein, we're making it easier for customers to activate protections across their on-premises identity infrastructure. Today we are excited to share that the unified identity and endpoint agent is extending support for more identity infrastructure and releasing a streamlined experience for existing customers looking to migrate to the new sensor. In addition to all this we are also adding a new identity explorer experience that is designed to help security professionals uncover identity-based exposures and lateral movement paths within their organization. Leveraging the graph capabilities within Defender and a robust set of pre-defined queries, SOC teams gain new visibility into potential exposure scenarios and end-to-end attack paths. Streamlined protections and workflows across Defender and Entra Security teams need to understand how the individual role, privilege, activity and alerts for each individual account relate to the risk of the identity as a whole. To address this, we’re introducing a new unified risk score that aggregates signals across all linked accounts to calculate a single risk score for the identity. As you can see in the image above the score considers the observed activity, criticality, privilege and likelihood of compromise for each linked account and produces a single, actionable view of risk. This means analysts no longer need to decipher various alerts themselves, they can quickly prioritize investigations based on the potential impact and urgency of identity‑driven threats. But the value of this new unified risk score doesn’t stop at investigation. Entra ID customers can now leverage these new risk signals directly within their risk-based conditional access policies. This gives admins a stronger signal for access decisions, resulting in earlier prevention, detection, and response across the identity control plane. This powers the feedback loop between identity and SOC teams, ensuring that insights gained in the SOC can immediately reduce exposure across the identity fabric. Together, these advances transform identity sprawl into clarity. By automatically connecting the dots and surfacing insights instead of raw data Defender is elevating what matters most, helping security teams cut through noise, focus on true risk, and respond to identity‑based threats with greater speed and confidence. New Identity detections using novel and unique sensor capabilities Detection opportunities start with visibility and sensor capabilities and we are excited to share a new capability that significantly improves how we see identity-based attacks on Domain Controllers. We work closely with the Windows team within Microsoft and are introducing a new Event Tracking for Windows (ETW) that gives us richer insight into Kerberos activity. This allows us to safely access important ticket details that were previously hidden while the ticket was in use, without needing to break or decrypt the ticket itself. With this additional context, we can spot unusual behavior that points to forged or tampered Kerberos tickets more accurately than before. By connecting this new operating system signal directly into our identity threat detection capabilities, we unlock a unique level of protection. It also opens up new investigation and hunting scenarios for SOC analysts who want deeper visibility into Kerberos related activity. Our first detection using this new sensor capability (“Possible golden ticket attack (suspicious ticket)”) is now generally available, and further exemplifies why our strategy is so revolutionary. Previously detecting these types of attacks would require decrypting the ticket/token itself, introducing even more potential for exposure. With this ETW however we have the same visibility without the risk. We know that Identity attacks no longer stop at the perimeter. Recognizing that modern adversaries target on‑premises, hybrid, and cloud identities alike, we invested heavily in expanding also our detection capabilities across this full spectrum. In particular, we introduced new detections for emerging attack techniques targeting Entra ID as a platform. While Entra ID Protection continues to deliver broad, native protection for Entra users and identities, the core mission of Identity Threat Protection products is to go further— detecting also sophisticated post‑breach activity and lateral movements where attackers directly target the identity provider itself, often by exploiting the hybrid trust and linkage between on‑premises and cloud environments. We are excited to announce the availability of the following new detections: 4 new detections for anomalies and attacks targeting Entra ID sync application in hybrid environments 2 new detections for suspicious device registration/join across Entra and Intune 1 new detection for techniques abusing Oauth Authorization Flow for browser-based attacks, as observed in-the-wild recently (“ConsentFix”) Powering autonomous Identity Threat Protection When a security incident is unfolding, every second matters. Attackers are already operating at machine speed, and human response alone can’t keep up, which is why AI-powered capabilities are essential for detecting, triaging and remediating identity threats in time. As part of our push toward autonomous Identity Threat Protection, we’re extending Security Copilot’s agentic triage capabilities to identity. We’ve already seen the impact of outcome-driven autonomous workflows in phishing, where our agent identifies 6.5 times more malicious alerts than human analysts working alone. Today, that same capability is extending beyond phishing to include identity alerts. The new Security Alert Triage Agent autonomously evaluates high‑volume identity alerts, distinguishing true threats from noise, and surfacing clear, explainable verdicts so analysts can focus immediately on what requires action. At Public Preview, it supports triage of alert types involving password spray attempts, suspicious inbox rules associated with business email compromise (BEC), and accounts potentially compromised following a password spray attack. Learn more about Security Copilot in Defender announcements here. In parallel, we’re expanding identity takeover predictive shielding, using real‑time exposure and attack path insights to proactively harden the identity attack surface during an active incident—blocking attacker progression before high‑value identities can be compromised. Together, these capabilities shift identity defense from reactive investigation to real‑time disruption, helping security teams contain attacks faster, reduce blast radius, and stay ahead of adversaries when it matters most. At Ignite, we introduced predictive shielding, an AI-powered capability in automatic attack disruption that predicts an attacker’s next move in an active attack and applies targeted, just-in-time hardening to block them before they can pivot. Today, predictive shielding proactively hardens many of the controls attackers most often rely on to regain access, such as SafeBoot abuse and Group Policy Objects. We’ve already seen tremendous impact across our customers, including a large public university: “During a ransomware incident, Microsoft Defender’s attack disruption stopped the attack before it could progress. In parallel, predictive shielding applied Safe Boot hardening across key devices, helping protect against a common evasion tactic—rebooting endpoints into Safe Mode to try and bypass protections like disruption. Together, these layers increased our confidence and resilience during the incident.” This speed and accuracy matter because identity-based attacks now operate at massive scale, with each user tied to many accounts across the environment, making it increasingly difficult to protect every identity. We are excited to share that we’re expanding this set of just-in-time hardening actions tailored for identity-based attacks. This includes: RemoteOps hardening: restricts high-risk remote administrative operations such as RPC-based actions that attackers rely on for lateral movement and hands-on-keyboard control. Remote Registry hardening: prevents attackers from remotely modifying sensitive registry settings often used to weaken security controls or enable credential theft. What makes these controls unique is their precision: Defender shields only the specific assets at risk, rather than applying broad, organization-wide restrictions, maximizing security while minimizing business impact. Looking ahead Identity has become the foundation of access, trust, and control in modern enterprises—and the primary target for attackers. The announcements detailed throughout this blog reflect our continued commitment to advancing identity security and to helping customers stay ahead of rapidly evolving identity-based threats. We’re excited to share more throughout the week at RSA, and we look forward to partnering with customers as they continue their journey toward comprehensive, identity centric security.
