What’s new in Microsoft Sentinel: September 2026
Welcome back to What's new in Microsoft Sentinel. In September, Case Management brings investigation and collaboration together in Microsoft Defender, with a shared workspace to track work through resolution. Defender unified RBAC custom roles for granular delegated admin privileges (GDAP) give you finer control over what managed security service providers (MSSPs) and other partners can access. In Sentinel data lake, a single Codeless Connector Framework (CCF) connector can bring in data from many accounts, and our connector catalog has passed 500 data connectors. Read on for the details. Sentinel innovations: Sentinel SIEM Sentinel data lake Sentinel SIEM Case Management (Public Preview) Starting September 23, 2026, Case Management brings investigation and collaboration together in one experience in Defender. With Incident Cases, you can investigate, coordinate response, assign work, capture notes, and track progress through resolution, all from a shared workspace that holds investigation context alongside tasks and workflow tracking. Your existing Sentinel automation, playbooks, workbooks, and integrations carry over unchanged. This builds on the integrated security operations (ISOC) vision of bringing the context and workflows practitioners need to investigate and respond together in Defender. Read our Case Management blog, see the documentation, and watch the demo to learn more. Unified RBAC custom roles (Public Preview) If you work with a managed security service provider (MSSP) or manage multiple tenants, giving partners the right level of access is simpler. Granular delegated admin privileges (GDAP) sets which partner groups can be delegated access to your tenant, and Defender unified role-based access control (RBAC) sets what they can see and do once delegated. You can assign unified RBAC custom roles to GDAP remote tenant groups and scope each role down to specific security products, data sources, and data collections so partners receive only the access they need. GDAP previously only supported Microsoft Entra directory roles, which often meant handing partners more access than the job needed. Anyone who is a member of a remote tenant group receives its permissions. Your partner manages who belongs to the group, while you keep control of the role and its scope. Learn more. Sentinel data lake Multi-account support for codeless connectors (Public Preview) A single connector built on the Codeless Connector Framework (CCF) can bring data from many accounts, tenants, or environments into one Sentinel workspace. A unified connections list shows each account as its own row, labeled so you can tell them apart by account name, tenant ID, or environment. An “Add connection” experience walks you through setting up each one, and an independent lifecycle per connection means you can edit or remove any account without affecting the rest. Shared, efficient ingestion sends all of it to the same table, so you have one place to investigate instead of a separate connector for every account. This helps if you run separate production and development accounts, segment by region or business unit, or manage several customers in one workspace. Learn more. Sentinel data connectors pass the 500 mark Sentinel has reached an exciting milestone of more than 500 data connectors. Our connectors bring security signals from Microsoft services, non-Microsoft solutions, multicloud environments, applications, infrastructure, and custom sources into Sentinel, where they can be correlated and analyzed to help teams detect threats, investigate incidents, hunt across their digital estate, and automate response. With 500+ connectors and growing, Sentinel makes it easier for organizations to unify their security ecosystem and give the security operations center (SOC) broader visibility where it matters most. Find your connector. Additional resources Blogs and documentation: Integrated Security Operations Center in Microsoft Defender ISOC in Microsoft Defender (preview) Activate Microsoft Defender unified role-based access control (URBAC) Support multiple connections in a codeless connector Upcoming webinars: Oct 6: Security Immersion Event: Into the Breach Oct 14: Microsoft Security Immersion Event: Shadow Hunter Upcoming events: Oct 19: Microsoft Security Days Summit: Dallas Edition (In Person) ISOC: What's new with the Defenders Capture the Flag: Agent Wars (Hands-on) Nov 17–20: Microsoft Ignite at Moscone Center in San Francisco, CA, USA. See what's next in Microsoft Security. Register now. Stay connected Check back each month for the latest innovations, updates, and events to ensure you’re getting the most out of Microsoft Sentinel. We’ll see you in the next edition!
Defender streaming setup and integration with private event hub
Hey team, Do we know Defeneder supports private endpoint only event hubs to ingest data - I think only public is supported Configure Azure Event Hubs for Microsoft Defender XDR event ingestion - Microsoft Defender XDR | Microsoft Learn Could anyone please clarify?Introducing Multi-Account Support for Connectors in Microsoft Sentinel
We're excited to announce that Microsoft Sentinel's data connectors for Auth0, CrowdStrike Falcon, and Salesforce Service Cloud now support multi-account ingestion — enabling you to connect and monitor multiple accounts or tenants from a single, unified connector configuration. The Challenge with Multi-Account Environments Modern enterprises don't run on a single account. Whether it's multiple Salesforce orgs across business units, several CrowdStrike tenants spanning subsidiaries, or Auth0 environments segmented by product line — security teams have long struggled to get unified visibility across all of them in a single SIEM. Until now, connecting multiple accounts from the same platform required painful workarounds: duplicate configurations, custom scripts, or dangerous blind spots in security coverage. Introducing Multi-Account Support for Auth0, CrowdStrike, and Salesforce in Microsoft Sentinel We're excited to announce that Microsoft Sentinel's data connectors for Auth0, CrowdStrike Falcon, and Salesforce Service Cloud now support multi-account ingestion — powered by the Codeless Connector Framework (CCF). You can now connect and monitor multiple accounts or tenants from a single, unified connector configuration — no scripts, no hacks. What's New? 🔑 Auth0 — Multi-Tenant Identity Monitoring Security teams managing multiple Auth0 tenants can now ingest logs from all of them into a single Sentinel workspace. Get complete visibility into authentication events, anomalous login patterns, and policy violations across every tenant without switching contexts. 🦅 CrowdStrike Falcon — Consolidated Endpoint Telemetry Organizations running multiple CrowdStrike tenants (e.g., across M&A entities or regional subsidiaries) can now stream detection alerts, threat intelligence, and endpoint telemetry from all tenants into Sentinel. One workspace. Full coverage. ☁️ Salesforce — Cross-Org Security Insights Enterprises with multiple Salesforce orgs can now centralize audit logs, login history, and API activity across all orgs. Detect insider threats, unauthorized access, and compliance gaps without stitching data together manually. 📖Find relevant connectors at Discover connectors Why It Matters Before After One connector = one account One connector = multiple accounts Manual workarounds for multi-tenant coverage Native, built-in multi-account support Fragmented detection across environments Unified analytics and incident correlation Higher operational overhead Streamlined configuration and management Getting Started Connecting multiple accounts is straightforward: 1. Navigate to Microsoft Sentinel → Data Connectors 2. Search for Auth0, CrowdStrike Falcon, or Salesforce 3. Open the connector and select "Add Account" 4. Authenticate and authorize each additional account 5. Start ingesting — your analytics rules, workbooks, and playbooks apply automatically across all accounts Built for Scale, Built for SOC Teams This update is part of our continued investment in making Microsoft Sentinel the most comprehensive and operationally efficient SIEM for enterprise environments. Multi-account support reduces configuration overhead, closes coverage gaps, and empowers SOC analysts to detect and respond to threats wherever they originate. What's Next? We're actively expanding multi-account support to more connectors. Stay tuned to the Microsoft Sentinel Blog and share your feedback!
Defender XDR: Tables not supported for table management
I am trying to extend the table retention of specific tables to allow them to flow to Sentinel Analytics but keep getting the message "This table is not supported for table management" in the Sentinel > Configuration > Tables page. The Sentinel workspace is connected in System > Settings > Microsoft Sentinel. I can see the table type is XDR in the list which seems to be the reason why it can't be managed. Any ideas why this table is not able to be managed.
Building Microsoft Sentinel Connectors in Minutes with the Sentinel Connector Builder Agent
Overview We previously announced the public preview of the Microsoft Sentinel connector builder agent via VS code extension, that helps developers build Microsoft Sentinel codeless connectors faster with low-code and AI-assisted prompts. This post walks through a hands-on lab using a mock Network Log API to demonstrate how the Sentinel connector builder agent simplifies building Codeless Connector Framework (CCF) pull connectors. Instead of manually creating ingestion infrastructure and configuration files, you’ll use a guided, conversational workflow in VS Code to generate connector artifacts, test them against a live API, and deploy them into Microsoft Sentinel. The lab focuses on the end-to-end experience ranging from API setup to validated connector deployment so you can see how quickly a working integration can be produced. For additional guidance beyond this lab, refer to our MS Learn documentation. The Lab Environment This lab is built around a mock Network Log API hosted as an Azure Function App. The purpose of the lab environment is to give us a live API that we can use to build, validate, and test the Sentinel CCF connector builder agent against end to end. The API exposes 50 synthetic network activity records that look and behave like a real product data source, including web traffic, DNS requests, blocked remote access attempts, malware command-and-control blocks, VPN activity, and other common network events. That makes it a useful stand-in for the type of telemetry many teams want to onboard into Microsoft Sentinel. The API is intentionally shaped like the kind of source a customer might expose for telemetry retrieval. It uses API key authentication through the X-API-Key header, returns paginated results through a nextLink model, and provides a predictable response structure that the builder agent can map into a pull connector configuration. The repo contains everything needed for the walkthrough. There is an ARM template to deploy the Function App, reference documentation for the API, and a sample connector package showing the generated polling config, table schema, DCR, and connector definition. The end goal of the lab is straightforward: use the builder agent to generate a CCF pull connector that ingests this API into the custom NetworkLogAPIGetNetworkLogs_CL table in Sentinel. Prerequisites Before starting, make sure you have the following: Azure subscription -- with Contributor access on a resource group (for deploying the Function App) and Microsoft Sentinel Contributor access on a Sentinel-enabled workspace (for deploying the connector) Microsoft Sentinel workspace -- an existing Log Analytics workspace with Sentinel enabled. See Onboard Microsoft Sentinel to a Log Analytics workspace for more information. Azure CLI -- See How to install the Azure CLI for more information. VS Code with the Microsoft Sentinel for Visual Studio Code extension installed. GitHub Copilot -- with access to premium models. The connector builder agent requires Claude Sonnet 4.5 or 4.6, which uses Copilot premium model credits. Lab Repository -- Once the aforementioned prerequisites are met, you can access the lab repository here: Azure-Sentinel/Tools/CCF-Connector-Builder-Agent-Accelerator at master · Azure/Azure-Sentinel Deploying the Mock API The full CLI commands for this section are available in the repo. For a simpler option, you can use GitHub Copilot to handle the deployment. Enter this prompt: Follow the deployment instructions in Sentinel-CCF-Pull-Connector-Builder-Agent-Accelerator/agent-instructions.md. Let’s deploy the Network Log API and build a CCF pull connector. At a high level, the setup is four steps: clone the repo, create a resource group, ensure you have a Sentinel-enabled workspace, and deploy the Function App using the included ARM template. The template takes two parameters: an ApiKey of your choice (the secret the CCF connector will use to authenticate) and your Log Analytics workspace resource ID for Application Insights. Deployment takes about two to three minutes and outputs the FunctionAppName and endpoint URLs you will need later. Once deployed, verify the API is live: curl -s -H "X-API-Key: <your-api-key>" \ "https://<functionappname>.azurewebsites.net/api/GetNetworkLogs?page=1&pageSize=3" </functionappname></your-api-key> You should see a response like this: The API also exposes an /api/RefreshData endpoint that regenerates the 50 sample records with fresh timestamps. This is useful later in the walkthrough when you want to produce new events and trigger an immediate ingestion cycle without waiting for the next polling interval: curl -s -X POST -H "X-API-Key: <your-api-key>" \ "https://<functionappname>.azurewebsites.net/api/RefreshData" </functionappname></your-api-key> Building the Connector with the Sentinel Connector Builder Agent With the Microsoft Sentinel extension installed and GitHub Copilot running in agent mode, open a Copilot chat and enter a single prompt pointing at the API documentation file: That is the entire invocation. The agent takes it from there. It works through a structured seven-step sequence: preparation, polling config, table schema, DCR, connector definition, package validation, and summary. The agent produces four files in a sentinel-connectors/NetworkLogAPI_CCF/ output folder: NetworkLogAPI_PollingConfig.json – This is the API poller configuration. The agent reads the documentation and correctly identifies the GET /api/GetNetworkLogs endpoint, configures API Key authentication via the X-API-Key header, sets up NextPageUrl pagination using $.metadata.nextLink with a $.metadata.hasNextPage stop condition, and wires up the since query parameter for incremental delta pulls using the timestamp field. The RefreshData endpoint is correctly excluded, which the agent recognizes as a maintenance operation, not a security data stream. NetworkLogAPI_Table.json – This is the custom Log Analytics table schema for NetworkLogAPIGetNetworkLogs_CL . All 20 fields from the API response are mapped to the correct column types, with timestamp promoted to TimeGenerated as the standard Sentinel time column. NetworkLogAPI_DCR.json – This is the Data Collection Rule. This defines the stream declaration, the workspace destination, and the KQL transform that maps the raw snake_case API fields ( sourceIp , destinationIp , threatIndicator , etc.) to their PascalCase table columns. NetworkLogAPI_ConnectorDefinition.json – This is the connector UI configuration. This drives what the connector page looks like in Microsoft Sentinel: the title, description, prerequisite instructions, the BaseUrl and ApiKey input fields, sample KQL queries, and the connectivity status logic. The only point where the agent paused for input was to propose a connector description and ask for confirmation before writing it to the file. Everything else such as endpoint selection, auth type, pagination pattern, schema mapping, KQL transform, cross-file consistency was selected autonomously. To put that in perspective: without the agent, a developer building this connector from scratch would need to manually author four JSON files, understand the CCF schema for polling configs, DCRs, and connector definitions, write the KQL transform by hand, and validate that every cross-file reference lines up correctly. The agent compresses that work, typically hours of reading documentation, trial-and-error, and portal debugging, into a single prompt. Testing the Connector Before deploying anything to a Sentinel workspace, the Microsoft Sentinel connector builder agent lets you validate the generated polling config against the live API directly from your editor. Right-click the sentinel-connectors/NetworkLogAPI_CCF folder, select Microsoft Sentinel → Test Connector (Preview), and a Configuration Variables panel opens asking for the two template variables from the polling config: BaseUrl and apiKey . For other API patterns, there may be additional and different inputs. For example, apiKey input could be swapped with clientID and secret if the API supports OAUTH. Enter the Function App base URL and your API key, and the test runner connects immediately. The panel shows a live polling session. Poll #1 returns HTTP 200 with 50 events, and a countdown timer shows when the next poll will fire. Switching to the Events tab displays the ingested records in a tabular view with columns for timestamp , severity , action , bytesIn , bytesOut , category , and the rest of the mapped fields fresh from the API. Additionally, there are tabs for Headers, Payload, and Response, which can be useful for verifying that your pollerconfig.json configuration provides the expected request to your api with a working response. Data Extracted: The Test Connector feature can be used to visualize the response data in a table format to verify that data will land in a Sentinel table based on your configuration. Request from Poller: The Test Connector feature can be used to validate the request and response headers that will go out to the API based on the generated poller configuration. Request Response: The Test Connector feature shows you the live response from the API with respect to the request going to the API based on the poller configuration. This is a meaningful pre-flight check. It confirms that auth is working, the $.data events path resolves correctly, pagination is functional, and the polling interval fires as configured all before a single file is deployed to Azure. The most common connector configuration issues (wrong base URL, incorrect header name, mismatched JSON path) surface here in seconds rather than after a failed deployment and a 20-minute wait for Sentinel to attempt its first ingestion cycle. It is also the fastest way to troubleshoot if something goes wrong after deployment, far quicker than pushing changes to Azure and waiting for the connector to poll again. Deploying and Enabling the Connector With the connector tested and passing, deployment is the same right-click menu: right-click the sentinel-connectors/NetworkLogAPI_CCF folder, select Microsoft Sentinel → Deploy Connector (Preview). If you are not already signed in to Azure, the extension will prompt you to authenticate. The agent will also provide a clickbox in the chat window to invoke a connector deployment. Right Click Deploy Connector: UI Prompt Based Deploy Method: Once signed in, a workspace picker lists all available Log Analytics workspaces across your subscriptions. Select the one with Sentinel enabled and click Deploy. The extension deploys all four files to the workspace in the correct order: table schema first, then DCR, polling config, and connector definition. Once deployed, navigate to your Sentinel workspace via https://security.microsoft.com, go to Data Connectors, and find the Network Log API connector. The connector page shows the description, prerequisite notes, and the two credential fields generated by the agent: API Base URL and API Key. Enter your Function App base URL and API key and click Connect. The status updates to show the connector is connected and the deployment succeeded. Note: Data will appear in the workspace within 5 to 30 minutes depending on the polling interval. Run this query in Log Analytics to confirm ingestion. Note that the agent derives the table name from the vendor name and endpoint, so yours may differ slightly from the example below. Check the agent's summary output or the NetworkLogAPI_Table.json file for the exact name: NetworkLogAPIGetNetworkLogs_CL | sort by TimeGenerated desc | take 10 If you want to generate a fresh batch of events immediately rather than waiting for the next polling cycle, use the RefreshData endpoint to reset the sample records with new timestamps: curl -s -X POST -H "X-API-Key: " \ "https://.azurewebsites.net/api/RefreshData" Next Steps If you want to go further: Try it with your own API. The lab repo includes documentation on adapting the polling config, schema, and KQL transform to a real data source. Review the CCF connector schema documentation to understand the full range of supported configurations: pagination patterns, auth types, incremental pull strategies, and delta filter expressions. Explore the Microsoft Sentinel content hub to see how published connectors are structured and what the certification requirements look like for production submissions. Conclusion Following these steps, you saw how a working Sentinel connector can be generated, tested, and deployed in minutes rather than requiring days of manual configuration and infrastructure setup. If you are an ISV building a Sentinel integration and want hands-on support, Microsoft’s App Assure program is available to help. We partner with ISVs on connector development, validation, and deployment and provide guidance through implementation, testing, and readiness for production. You can get started by reaching out through our intake form. See our other Sentinel connector feature’s hands-on labs Building a CCF Nested API Pull Connector: A Technical Lab WalkthroughMonthly 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 Enterprise AI Agents with Microsoft Sentinel
1. Introduction Enterprise adoption of Generative AI is accelerating rapidly through Microsoft 365 Copilot, Copilot Studio, Azure AI Foundry Agents, Security Copilot, and custom AI agents integrated with business applications. Unlike traditional SaaS applications, AI agents can: Access enterprise data Query internal knowledge repositories Invoke APIs and MCP tools Execute workflows Interact with business applications Make decisions on behalf of users While these capabilities improve productivity, they introduce a new attack surface that security teams must monitor and secure. Common AI threats include: Prompt Injection Cross Prompt Injection Attacks (XPIA) Jailbreak Attempts Unauthorized Tool Invocation Data Exfiltration through AI Agents Agent Identity Abuse Excessive Data Access Malicious MCP Tool Execution Traditional SOC monitoring platforms were designed for users, devices, applications and infrastructure—not autonomous AI systems. To address this challenge, Microsoft provides a comprehensive AI security monitoring framework built around: Agent 365 Observability Microsoft Agent Identities Microsoft Copilot Logs Defender XDR Defender for AI Microsoft Sentinel Together these components provide end-to-end observability of: User prompts Agent execution paths Tool invocations Safety signal detections Agent identities Security alerts 2. Reference Architecture AI Security Monitoring Architecture 3. Integration Architecture Microsoft provides multiple telemetry sources that complement one another. 3.1 Agent Runtime Telemetry Sentinel Data Connector Agent 365 Data Connector Table UnifiedAgentObservability Captures runtime behavior of AI agents including: User prompts Session IDs Conversation IDs Agent identities MCP tool invocations Connector invocations Tool arguments Tool responses Request payloads Response payloads Execution errors This dataset provides the forensic trail of everything an AI agent performed. 3.2 Agent Governance and Asset Inventory Sentinel Data Connector Microsoft Agent Identities Provides visibility into: Agent inventory Agent blueprint inventory Ownership Relationships Governance metadata Risk context This allows SOC teams to answer: Who owns this agent? What permissions does it have? Which business unit deployed it? Which related agents exist? 3.3 Copilot Audit and Usage Monitoring Sentinel Data Connector Microsoft Copilot Logs Connector Table CopilotActivity Provides: Copilot usage auditing Operational visibility User interaction tracking Useful for governance, compliance and adoption reporting. 3.4 AI Safety Telemetry Sentinel Data Connector Microsoft Defender XDR Connector Table CloudAppEvents CloudAppEvents provides AI safety signals such as: Prompt Shield detections Prompt Injection attempts Cross Prompt Injection Attacks (XPIA) Jailbreak-related verdicts Unsafe prompt classifications Think of CloudAppEvents as answering: "Was the prompt malicious?" 3.5 AI Security Alerts Sentinel Data Connectors Microsoft Defender XDR Microsoft Defender for Cloud Tables SecurityAlert SecurityIncident Used for: AI attack detections Security incidents Correlated investigation workflows 4. Understanding the Two Most Important AI Tables CloudAppEvents Focuses on AI Safety Questions answered: Was Prompt Shield triggered? Was this a jailbreak attempt? Was XPIA detected? Was the prompt suspicious? UnifiedAgentObservability Focuses on Agent Runtime Behavior Questions answered: What tool was invoked? Which connector executed? What arguments were passed? What data was returned? What actions did the agent perform? 5. Advanced Threat Hunting Scenarios The Agent365 Observability hunting guide contains several investigation scenarios that can be used directly in Microsoft Sentinel. Reference: Agent 365 Observability — AI Agent Telemetry Hunting https://github.com/SCStelz/security-investigator/blob/main/queries/cloud/agent365_observability.md 5.1 Prompt Injection Detection Detect prompts containing indicators such as: Ignore previous instructions Reveal system prompt Developer mode Disregard safety controls Investigation workflow: Review Tool Activity This allows analysts to determine whether a suspicious prompt resulted in downstream actions. 5.2 Session Reconstruction One of the most powerful capabilities of UnifiedAgentObservability is session reconstruction. Analysts can correlate: This creates complete forensic timelines. 5.3 MCP Tool Auditing Monitor all MCP activity including: query_lake Graph API tools ServiceNow connectors SharePoint connectors Custom enterprise tools Questions answered: Which tool was used? Who triggered it? What parameters were supplied? What data was returned? 5.4 Sensitive Data Access Monitoring Monitor AI agent interaction with: Employee records Customer data Financial information SharePoint repositories HR databases Useful for identifying: Data exfiltration attempts Excessive access patterns Sensitive data exposure 5.5 Query Lake Monitoring The GitHub hunting guide introduces monitoring of: query_lake RunAdvancedHuntingQuery Analysts can inspect: Actual KQL submitted Target workspaces Data sources queried Scope of access This provides visibility into AI-driven security investigations. 5.6 New Tool Detection Identify newly observed tool usage. Examples: Unauthorized MCP servers Newly registered connectors Unapproved tools Unexpected integrations This use case is particularly useful for governance programs. 5.7 Tool Failure Monitoring Monitor: Permission failures Connector failures Application errors Access-denied responses A sudden increase in failures may indicate: Reconnaissance activity Misconfiguration Privilege abuse attempts 6. Detection Engineering Opportunities Organizations can create Sentinel Analytics Rules for: 6.1 Prompt Injection Detection Developer Mode prompts Prompt Override attempts System Prompt disclosure requests 6.2 Jailbreak Attempt Detection Safety bypass attempts Role manipulation prompts Instruction override patterns 6.3 Unauthorized Tool Usage New MCP tools High-risk connectors Rare tool executions 6.4 Sensitive Data Access HR data queries Identity information retrieval Large-volume exports 6.5 Agent Identity Abuse Ownership changes Unexpected agent activity Agent-to-agent anomalies 7. Data Lake Exploration and Long-Term Analytics Because agent telemetry resides within Sentinel Data Lake, organizations can perform: Long-term AI investigations Historical AI attack analysis Agent baselining Governance reporting Trend analysis Tool inventory reporting Example dashboards include: Top Prompt Injection Attempts Most Active Agents High-Risk MCP Tools Agent Ownership Analysis AI Security Incidents Sensitive Data Access Trends 8. Summary AI agents represent the next major computing platform, but they also introduce a completely new attack surface. To effectively secure enterprise AI solutions, organizations require visibility across: User interactions Agent execution paths MCP tool usage Prompt safety signals Agent identities Security detections Microsoft Sentinel provides this unified view by integrating: Agent 365 Observability UnifiedAgentObservability Microsoft Agent Identities Microsoft Copilot Logs CloudAppEvents Defender XDR Defender for AI By combining AI runtime telemetry with AI safety signals and Defender detections, security teams can move beyond traditional monitoring and build a modern SOC capability for threat hunting, incident response, governance and forensic investigations across Microsoft 365 Copilot, Copilot Studio, Azure AI Foundry and future AI agent ecosystems. Reference: https://github.com/SCStelz/security-investigator/blob/main/queries/cloud/agent365_observability.md
Looking for a simple deployment guide
MS Learn is a great starting point, but it just doesn't seem to cover the steps needed to get up and running safely. I have concerns about adding or setting something that suddenly creates a vulnerability or exposure. Where is the installation guide that installs and configures the solution then tells you, "You are now protected". Do I really want to set my own policies? Why aren't the default set of rules good enough, safe enough. I can't have a solution that is so complicated I need to hire a team to manage it 24 hours a day. I am okay investigating an alert and helping a user solve a pop-up question. Why is every major corporation around the world required to re-invent the same or similar policies the company next door is creating to make this tool work? I want to onboard all of our Intune devices and monitor anything that CAN'T be stopped by default security measures. Just the fact that Sentinel appears to be changing as an embedded tool within Defender gives me hope that this will be getting closer to a more manageable tool. But that still seems a way off. I am ready to do the reading and research to get this set up but I am hoping for a guide that is specific enough to achieve a final result. Thank for understanding my challenges here.Monthly 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.
