microsoft 365 defender
594 TopicsSecuring AI Agents at Runtime: Real-Time Protection and Threat Detection for Microsoft Agent 365
Organizations are rapidly adopting AI agents to automate workflows, access enterprise data, invoke tools, and take actions on behalf of users. This autonomy creates a fundamentally new security challenge. Unlike traditional AI applications, agents operate across dynamic execution flows, interacting with external content, calling tools, and accessing sensitive resources. These interactions create new attack paths that traditional security controls were not designed to address. Today, we're announcing two major milestones for Security for AI in Microsoft Defender for Microsoft Agent 365: Threat detection for Microsoft Agent 365 agents — now in public preview. Real-time protection for Microsoft Agent 365 tooling servers — now generally available. Together, these capabilities help security teams detect, investigate, and block attacks targeting AI agents, extending Microsoft Defender's threat protection capabilities into the agent runtime. Threat detection for Microsoft Agent 365 Agents (Public Preview) Threat detection provides SOC teams with detailed visibility into attacks and suspicious activity targeting AI agents. By analyzing runtime signals across agent interactions, tool usage, and execution patterns, Microsoft Defender identifies suspicious and malicious behavior throughout the agent execution lifecycle and surfaces actionable security alerts for SOC teams. Threat detection supports cloud agent types that emit observability logs to Microsoft Agent 365, including: Microsoft Copilot Studio Microsoft Foundry Microsoft 365 Copilot Agent Builder Agents integrated through the Microsoft Agent 365 SDK This provides consistent threat visibility across supported Microsoft Agent 365 agent experiences, regardless of how the agent was built. Fig. 1. Microsoft Security for AI alerts in Microsoft Defender XDR (Preview) Microsoft Defender identifies a broad range of AI-specific threats, including: Indirect prompt injection (XPIA) — malicious instructions embedded in external content designed to manipulate agent behavior. Evasion techniques — attempts to bypass agent instructions or security controls. Malicious content propagation — attempts to use agents to generate or distribute malicious content. Secret leakage — exposure of credentials, API keys, or other sensitive information through agent interactions. LLM reconnaissance — attempts to probe agent capabilities, instructions, or security boundaries. Suspicious IP access — agent access originating from anonymized or suspicious IP addresses. Alerts are surfaced directly in Microsoft Defender, enabling SOC analysts to investigate and respond using familiar workflows, Advanced Hunting queries, and the Defender XDR investigation experience. Real-time protection for WorkIQ and Custom MCP servers (General Availability) Real-time protection moves beyond detection by blocking threats inline when AI agents interact with WorkIQ and custom MCP servers (see Microsoft Agent 365 tooling servers). When an agent invokes a registered tool or receives a tool response, Defender evaluates the interaction against configured security policies and determines whether to allow or block it directly within the agent's execution flow. This helps prevent malicious actions and data leakage in real time, without requiring agent developers to implement custom security logic. Fig. 2. Microsoft Security for AI Real-Time Protection policy in Defender Real-time protection currently guards against high-impact threats, including: Evasion techniques — attempts to bypass agent guardrails or security controls. Malicious content propagation — preventing agents from spreading malicious content through tool actions. Secret leakage — blocking agents from inadvertently exposing credentials or sensitive data through tool calls. Communication with untrusted domains — preventing agents from sending email or data to high-risk or untrusted email domains. Better Together: Detection and Protection Threat detection and real-time protection address complementary parts of the agent security lifecycle. Real-time protection provides inline enforcement to block malicious interactions during execution, while threat detection gives SOC teams the visibility and investigation context needed to identify attack patterns, assess impact, and respond to suspicious activity. Together, they provide a defense-in-depth approach that combines runtime enforcement with SOC-driven detection and investigation, purpose-built for AI agents. Getting Started Both capabilities are available through Microsoft Defender, using a dedicated Security for AI workload experience that brings together AI threat detections, investigations, and runtime protection policies. To learn more: Enable security for AI agents using Microsoft Defender Detect and investigate threats to AI agents using Microsoft Defender (Preview) Protect AI agents in real time using Microsoft Defender As AI agents become more autonomous and gain access to enterprise data and tools, securing their runtime behavior becomes critical. With Threat Detection and Real-Time Protection, Microsoft Defender helps organizations adopt AI agents with security controls designed for how agents actually operate—detecting attacks, enabling SOC investigation, and blocking malicious interactions at runtime.1.2KViews1like0CommentsWindows defender is having a lot of problems.
So I have a Microsoft 365 Family subscription, and Dark Web Monitoring shows 0 monitored items. SSN verification fails and advises you to contact support. I was also unable to delete the monitored information. I’m receive the error "Something went wrong, try again in a bit." The issue occurs in the Microsoft Defender app, web portal, and across devices. Is there anyway that I can get help with this?Custom Detection Rules as Code in Sentinel Repositories: What Your Pipeline Owns Now
While going through the June Sentinel updates I almost scrolled past this one, and I think that would have been a mistake: custom detection rules can now be managed as code in Sentinel Repositories, the same way analytics rules, playbooks, parsers and workbooks already are. You connect a GitHub or Azure DevOps repo, enable the Custom Detection Rules content type, and rules are synced on every commit. There is also a standalone path via the Bicep CLI for teams running their own pipelines. The feature is in preview per the Learn documentation, and in my view it matters more than the low-key rollout suggests. Microsoft has been positioning custom detections as the unified experience for building rules over both Defender XDR and Sentinel data since late 2025. If custom detections are becoming the primary detection type, then this preview is the moment your primary detection type becomes pipeline-managed. I spent some time in the documentation to understand what that actually means, and there is one implication I have not seen anyone talk about yet. How it works Custom detection rules use a different mechanism than every other content type in Repositories. Analytics rules deploy as Microsoft.OperationalInsights/workspaces/providers/alertRules resources, with the Microsoft.SecurityInsights provider sitting in the resource name. Custom detection rules instead use a dedicated Bicep extension. You declare it in a `bicepconfig.json` at the repo root: { "extensions": { "MicrosoftSecurity": "br:mcr.microsoft.com/bicep/extensions/microsoftsecurity:v1.0.1" } } The rule itself is a `Microsoft.Security/detectionRules` resource. This is the structure from the Microsoft documentation: extension MicrosoftSecurity resource detectionRule 'Microsoft.Security/detectionRules@2026-06-01-preview' = { id: 'custom-rule-id' displayName: 'Custom Rule Display Name' status: 'enabled' queryCondition: { queryText: 'DeviceProcessEvents | take 10 | project DeviceId, Timestamp, FileName' } schedule: { frequency: 'PT1H' } detectionAction: { alertTemplate: { title: '<ruleTitle>' description: 'Custom detection rule' severity: 'medium' tactics: [ { tactic: 'Execution' techniques: [ { technique: 'T1059' } ] } ] entityMappings: { hosts: [ { id: 'h' deviceIdColumn: 'DeviceId' } ] } } } } Rules are uniquely identified by the `id` property, which you provide in the template. Deployment is either the automatic Repositories sync or a plain `az deployment group create` against a resource group. That last part is what I like most about the design: any CI/CD system that can run Azure CLI can ship these rules. Prerequisites beyond the standard Repositories setup: a Microsoft 365 E5 license or equivalent that includes Defender XDR, and a Sentinel workspace onboarded to the Defender portal. Two preview limitations are documented: custom frequency for Sentinel-only data is not supported yet, and neither are custom details. The part that made me stop reading and think Repositories are designed as the single source of truth. The documentation is explicit that content in your repo overwrites changes made through the portal. That is the whole point of the feature, and for analytics rules it has been mostly harmless. For custom detections I see a wrinkle. When Microsoft renames tables or columns in the advanced hunting schema, those naming changes are applied automatically to queries saved in Microsoft Defender, including the queries inside custom detection rules. The docs are equally explicit that this automatic migration does not cover queries run via API or saved anywhere outside Defender. A Git repo is outside Defender. Play that forward with a current example. The `AIAgentsInfo` table stopped being accessible on July 1, 2026, replaced by the unified `AgentsInfo` table with a changed column set. A portal-managed custom detection referencing the old table got migrated automatically. The same rule managed as code did not, because the authoritative copy of the query now lives in your repo, and nothing in the sync path rewrites your Bicep files. Your repo is now the thing standing between Microsoft's server-side fix and your production detection. Either the sync starts failing, or the stale query gets reasserted over the migrated rule. The documentation does not say which of the two happens, and honestly, neither is good. No alert fires for either. And if smart deployments, which skip files that have not changed since the last deployment, apply to this content type the same way they do to the rest of Repositories, it gets slightly worse in a way I find almost funny: a stale rule would sit untouched until someone happens to edit it. What I would put in front of the merge To be clear, none of this is an argument against the feature. I want detections in Git, and I suspect most people reading this do too. It is an argument that moving custom detections into a repo moves the schema lifecycle responsibility into your review process, because the portal safety net explicitly does not reach into source control. Concretely, a PR touching detection content should be checked for references to deprecated or transitioning advanced hunting tables, for the result columns the custom detection docs recommend (`Timestamp` or `TimeGenerated`, plus `DeviceId` or `DeviceName` for Defender for Endpoint tables, plus `Timestamp` and `ReportId` from the same event for the other Defender tables), and for complete entity mappings, since entities drive how alerts group into incidents. One more detail from the custom detection docs that I suspect will trip up people coming from analytics rules, because it goes against years of muscle memory: avoid filtering on `Timestamp` or `TimeGenerated` in the query itself. The service prefilters data based on the detection lookback using ingestion time. The scheduled-analytics-rule reflex of always pinning a time window works against you here. Whether you enforce these checks with a homegrown script or a linting step in the pipeline matters less than doing it before merge rather than discovering it in the alert queue. The deployment mechanics are now solved. The content governance is yours. Full transparency: I have worked through the documentation and the sample content, but I have not yet run a retired-table scenario through the sync myself. So if you are testing the preview, I would genuinely like to hear how it behaves in your environment when a repo-managed rule references a table like `AIAgentsInfo`. That failure mode is the one I want to understand before this reaches GA. Beyond that specific case, I am curious where you all stand: are you moving custom detections into Git now, or waiting for GA? And if you already run detections as code for analytics rules, what checks have earned a permanent place in your PR pipeline? My used references: Manage content as code with Microsoft Sentinel repositories: https://learn.microsoft.com/en-us/azure/sentinel/ci-cd-custom-content Advanced hunting schema naming changes: https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-schema-changes Create custom detection rules in Microsoft Defender XDR: https://learn.microsoft.com/en-us/defender-xdr/custom-detection-rules Custom detections as the unified detection experience: https://techcommunity.microsoft.com/t5/microsoft-defender-threat-protection/custom-detections-are-now-the-unified-experience-for-creating/ba-p/4463875SolvedMicrosoft Defender for Office 365 Plan 1 is now rolling out to Microsoft 365 E3 and Office 365 E3
Starting today, Microsoft Defender for Office 365 Plan 1 is rolling out to customers with Microsoft 365 E3/G3 and Office 365 E3/G3 licenses, with rollout expected to complete by Fall 2026. For security teams, this means added protection against phishing, malware, and malicious links across email and collaboration, without needing to purchase or deploy a separate email security solution. It also means some protections will turn on automatically, so now is the right time to review your configuration and prepare for any changes to mail flow, policies, and end-user experience. What E3 customers are getting Previously, these subscriptions included built-in security to help filter spam and known malware. Defender for Office 365 Plan 1 builds on that foundation with additional protections designed to catch more sophisticated phishing attempts, malicious links, and zero-day threats, while giving your team better visibility into what is happening in your environment. Safe Links: Helps protect users with time-of-click protection by checking URLs and blocking malicious destinations, including QR code-based attacks. Safe Attachments: Helps stop unknown and zero-day malware before harmful files reach users. Advanced anti-phishing: Helps detect impersonation attacks that target your users, executives, and trusted domains. Expanded visibility and reporting: Gives security teams more actionable detections, alerts, and reporting in the Microsoft Defender portal. What changes automatically As the plan rolls out, protection will turn on automatically for licensed users. That is good news from a security perspective, but it is still important to understand what is changing in your environment. New protections can affect how messages are processed, how suspicious links are handled, what users see when they click blocked content, and how your team monitors and tunes policy settings after rollout. Read more about it here: https://learn.microsoft.com/en-us/defender-office-365/preset-security-policies#use-the-microsoft-defender-portal-to-add-exclusions-to-the-built-in-protection-preset-security-policy. How to prepare for the rollout Review your current mail flow and security configuration. If you know how mail is routed today and which protections are already in place, it will be easier to spot what changes once Defender for Office 365 Plan 1 is active. Decide how you want to manage policies. When the plan becomes available in your tenant, built-in protection is applied automatically for licensed users. If you want Microsoft recommended settings beyond that baseline, consider enabling the Standard or Strict preset security policies. Prepare your help desk and users. Users may start seeing warning or block experiences when Safe Links identifies a malicious destination. A simple heads-up can reduce confusion and support tickets. For more details and how to customize user notification, see Set up Safe Links policies. Plan for exceptions and tuning. If you have specific users, domains, or workflows that need exclusions, review those requirements early so your team is ready to adjust policies after rollout. Monitor what changes. Use the Microsoft Defender portal and Microsoft Secure Score to track new detections, review improvement actions, and prioritize follow-up configuration work. If you use a third-party secure email gateway If your organization routes email through a third-party secure email gateway such as Proofpoint, Mimecast, or Barracuda before it reaches Microsoft 365, you should review your configuration now. In many environments, it is recommended to configure Enhanced Filtering for Connectors, preserve original sender details in Exchange Online, and decide which service will handle link rewriting to avoid unnecessary overlap. If you are evaluating a broader consolidation of your email security stack, our guides on defense in depth and migration to Defender for Office 365 can help. Protection also extends to Microsoft Teams The plan also extends protection to Microsoft Teams chats and channels. That includes protection for shared links and files, post-delivery removal of malicious content, admin controls to manage enforcement, and user reporting to help your security team investigate suspicious messages faster. For practitioners, this adds another layer of coverage across the collaboration tools users rely on every day. Learn more For implementation guidance, visit the Microsoft Defender for Office 365 security documentation, review the step-by-step guides, and use the preset policy, defense in depth, migration, and connector configuration resources linked above to plan your rollout.Microsoft 365 Developer E5 license lacking endpoints and device ON defender portal
Dear Support Team, I am a microsoft certified trainer (MCT). I currently have a Microsoft 365 Developer E5 license assigned to my tenant. However, I have noticed that my Microsoft Defender portal (security.microsoft.com) is missing several critical features. For example, I cannot see the Endpoints or Devices menus, which is preventing me from implementing and testing Microsoft Defender for Endpoint. Additionally, my Azure tenant and Microsoft 365 tenant are separate. This has created challenges when configuring security services such as Microsoft Sentinel (SIEM), as certain prerequisites and integrations require configuration through the Microsoft Defender portal. Due to the missing Defender features, I am unable to complete the necessary setup. I would appreciate your assistance in understanding: Why the Endpoints and Devices sections are unavailable in my Defender portal despite having a Microsoft 365 Developer E5 license. Whether additional licensing, onboarding steps, or tenant configurations are required to enable Microsoft Defender for Endpoint features. How best to integrate or align my separate Azure and Microsoft 365 tenants to support services such as Microsoft Sentinel and Defender XDR. These issues are significantly impacting my ability to evaluate and implement Microsoft's security solutions. I would appreciate any guidance or recommendations to resolve them.217Views1like1CommentNo way to automate restoring user‑reported emails after “no threats found”
When a user reports an email as phishing in Defender, the message gets moved to Deleted Items. After we triage it, if we mark it as “no threats found,” there’s no way to push it back to the user’s inbox as part of that workflow. That creates a bit of a broken experience: User is told the email is safe with our customized email response, but has to go find it themselves In a lot of cases they don’t (Outlook search won’t find it) We end up with follow‑ups like “where did it go?” Technically we could restore the email as part of our triage process, but that just shifts the effort onto the SOC. It doesn’t scale, and it’s not really the right place for that work. We have tried to create an automation to do this, but we have not been able to create an advanced hunting query based on our triage result that can then trigger an action to restore it to the mailbox. So we end up choosing between: Users having a bad experience, or Analysts doing manual mailbox work Neither is ideal. Other platforms (like Proofpoint) handle this end‑to‑end — once something is confirmed clean, it can be returned to the user automatically. Right now Defender stops at classification instead of completing the workflow. Is there a reason this isn’t wired in, or anything on the roadmap to address it?Granular email content access with unified RBAC – now the default for new Defender tenants
Email investigations are a key part of detecting and responding to phishing and malware. As security workflows continue to evolve, there is an increasing need to align email content visibility more closely with specific roles and scenarios, such as Tier‑1 analysis or specialized workflows like user‑reported phishing triage. Today we’re announcing additional “read-only” controls for more granular email access in Microsoft Defender and that starting on May 30 th , 2026, unified RBAC will become the new default for permission modeling for new tenants. Unified RBAC in Microsoft Defender: a single, consistent permissions model Microsoft Defender unified role‑based access control (RBAC) provides a centralized way to manage permissions across the Defender security portfolio, replacing the need to configure and audit access separately for each solution, including endpoint, identity, SaaS, Cloud, and more. Instead of stitching together service‑specific role models, unified RBAC gives security teams one consistent authorization framework to control what users can see and do across the Microsoft Defender portal. Unified RBAC is designed to support modern security operations by aligning access with real‑world roles, such as analysts, investigators, and administrators, while reducing the risk that comes from over‑permissioned accounts including: Enforcing least‑privilege access consistently Understanding who has access to sensitive data across services Performing clean access reviews and audits Scaling permissions safely in tiered SOC or partner‑managed environments Unified RBAC addresses these challenges by converging permissions into a single model and separates read-only (data access) and manage (action‑taking) permissions by design, making access intent explicit and reducing accidental overexposure of sensitive security data. More granular email permissions within unified RBAC Unified RBAC now supports additional read‑only permissions for specific email content scenarios—so access can be matched precisely to investigation and review workflows. 1. New permission-Email & collaboration content: Emails associated with alerts The new Emails associated with alerts permission allows analysts to preview or download emails only when they are directly associated with a security alert, without granting access to all email content. Initially, this permission applies to alerts of type Email reported by user as malware or phish and Email reported by user as junk, which is one of the most common investigation entry points for security teams. Only emails tied to that alert type can be previewed or downloaded. Support for additional alert types will expand in future updates. Why this matters: Tier‑1 analysts and triage teams can investigate user‑reported threats quickly and effectively, without being granted visibility into unrelated emails. 2. New permission- Email and Collaboration content: Quarantine Emails This new permission allows previewing and downloading only emails that are in admin quarantine, supporting roles responsible for reviewing or validating quarantined messages – without broader email access. Important: After this update, Email & collaboration quarantine and Security data basics will no longer provide email content preview or download by themselves. To allow content visibility for quarantined messages, you must explicitly assign Emails in Quarantine. This change clarifies role boundaries and simplifies audits by making content access intentional and explicit. Read more here. Why this matters: Quarantine review teams can access exactly what they need—no more, no less—supporting least-privilege access by design. These permissions extend the Unified RBAC model for email & collaboration by separating visibility from action. They allow security teams to grant targeted access to email content only where it’s required, while preserving full content access for senior investigators and incident response teams. Full email content access remains available through existing permissions—such as Email & collaboration content: All emails—for senior investigators and incident response teams who require unrestricted visibility. Unified RBAC becomes the default for new Microsoft Defender tenants Starting May 30 th , 2026, Unified RBAC will be enabled by default for new Microsoft Defender for Office 365 Plan 2 tenants, making it the primary permissions model that enables a single, unified authorization model across the Defender suite. Permissions are managed through Defender unified RBAC roles, alongside Microsoft Entra roles where applicable (e.g. for Attack Simulation Training). Making Unified RBAC the default for new tenants is a key step toward simplifying permissions management and embeds least-privilege access by design. Learn more Microsoft Defender Unified role-based access control (RBAC) Create custom roles with Microsoft Defender Unified role-based access control (RBAC) Manage quarantined messages and files as an admin The Email entity page in Defender for Office 365Security Copilot Agents in Defender XDR: where things actually stand
With RSAC 2026 behind us and the E5 inclusion now rolling out between April 20 and June 30, anyone planning SOC workflows or sitting on a capacity budget needs to get a clear picture of what is GA, what is preview, and what was just announced. The marketing pages tend to blur those lines. This is my sober look at the current state, with the operational details that matter for adoption decisions. What is actually shipping right now The Phishing Triage Agent is GA. It only handles user-reported phish through Defender for Office 365 P2, but for most SOCs that is a meaningful chunk of the L1 queue. Verdicts come with a natural-language rationale rather than just a label, which is the part that determines whether analysts will trust it. The agent learns from analyst confirmations and overrides, so the feedback loop matters more than the initial setup. There is a setup detail that is easy to miss: the agent will not classify alerts that have already been suppressed by alert tuning. The built-in rule "Auto-Resolve - Email reported by user as malware or phish" needs to be off, and any custom tuning rules that touch this alert type need review. If you skip this, the agent runs on an empty queue and you wonder why nothing is happening. The Threat Intelligence Briefing Agent is also GA. It produces tenant-tailored intel briefings on a regular cadence. Useful, but lower operational impact than the triage agents. Copilot Chat in Defender went GA with the April 2026 update. Conversational Q&A inside the portal, grounded in your incident and entity data. This is the lowest-risk way to get value out of Security Copilot and probably where most teams should start. Public preview, worth watching The Dynamic Threat Detection Agent is the most technically interesting one. It runs continuously in the Defender backend, correlates across Defender and Sentinel telemetry, generates its own hypotheses, and emits a dynamic alert when the evidence converges. Detection source on the alert is Security Copilot. Each alert includes the structured fields (severity, MITRE techniques, remediation) plus a narrative explaining the reasoning. For EU tenants the residency point is worth confirming with whoever owns data protection in your org: the service runs region-local, so customer data and required telemetry stay inside the designated geographic boundary. During public preview it is enabled by default for eligible customers and is free. At GA, currently targeted for late 2026, it transitions to the SCU consumption model and can be disabled. The Threat Hunting Agent is also in public preview. Natural language to KQL with guided hunting. Lower stakes, but useful for teams without deep KQL expertise on hand. Announced at RSAC, still preview Two agents got the headlines in March: The Security Alert Triage Agent extends the agentic triage approach beyond phishing into identity and cloud alerts. The longer-term direction is consolidating phishing, identity, and cloud triage under a single agent. Rollout is from April 2026, in preview. The Security Analyst Agent is the multi-step investigation agent. Deeper context across Defender and Sentinel, prioritised findings, transparent reasoning trace. Preview since March 26. Both look promising on paper, but Microsoft's history of preview features that take a long time to mature is well-documented. I would not plan production workflows around either of them yet. What you actually get with the E5 inclusion This is the licensing change most people are dealing with right now. Security Copilot has been part of the E5 product terms since January 1, 2026. Tenant rollout is phased between April 20 and June 30, 2026, with a 7-day notification before activation. The numbers: 400 SCUs per month for every 1,000 paid user licenses Capped at 10,000 SCUs per month, which you hit at around 25,000 seats Linear scaling below that, so a 3,000-seat tenant gets 1,200 SCUs per month No rollover, the pool resets monthly What is included: chat, promptbooks, agentic scenarios across Defender, Entra, Intune, Purview, and the standalone portal. Agent Builder and the Graph APIs are in. If you also run Sentinel, the included SCUs apply to Security Copilot scenarios there. What is not included: Sentinel data lake compute and storage. Those still run through Azure on the regular meters. Beyond the included pool you pay 6 USD per SCU pay-as-you-go, with 30 days notice before that mode kicks in. Practical things worth knowing before activation A few details that are easy to miss in the docs: Under System > Settings > Copilot in Defender > Preferences, switch from Auto-generate to Generate on demand. Auto-generate will burn SCUs on incidents nobody is going to look at. Generate on demand gives you direct control. In the Security Copilot portal workspace settings, check the data storage location and the data sharing toggle. Data sharing is on by default, which means Microsoft uses interaction data for product improvement. If your compliance position does not allow that, change it before agents start running. Changing it requires the Capacity Contributor role. Agent runs are not equivalent to the same number of analyst chat prompts. A triage agent processing fifty alerts in one run consumes meaningfully more SCUs than fifty manual prompts on the same data. If you have a high-volume phishing pipeline, model that out before you flip the switch broadly. The usage dashboard in the Security Copilot portal breaks down consumption by day, user, and scenario. Output quality depends on telemetry quality. Flaky connectors, gaps in log sources, or a high baseline of misconfigured alerts will produce verdicts that match. Connector health monitoring (the SentinelHealth table in Advanced Hunting is a sensible starting point) is a precondition. The agents only improve if analysts feed the override loop. If your team treats the verdicts as background noise rather than confirming or correcting them, the feedback signal is lost and calibration stays where it shipped. That is a process problem, not a product problem, but it determines whether any of this is worth the SCUs. A reasonable adoption order A rough sequence that minimises capacity surprises: Copilot Chat in Defender first. Lowest risk, immediate value through natural language Q&A in the investigation context. Phishing Triage Agent on a controlled subset, with a review cadence in place. Check the built-in tuning rules first. Watch the SCU dashboard for the first month before adding anything else. Let the Dynamic Threat Detection Agent run while it is in public preview, since it is default-on and free anyway. Compare its alerts against existing Sentinel detections. Security Alert Triage Agent for identity and cloud once the phishing baseline is stable. Establish a monthly review covering agent decisions, false-positive rate, SCU cost, and MTTD/MTTR trends. Technically, agentic triage is moving past phishing into identity and cloud, and the Dynamic Threat Detection Agent represents a genuine attempt at the false-negative problem rather than just another rule engine. Lizenziell, the E5 inclusion removes the biggest barrier to adoption that previously existed. The risk is enabling everything at once. Agents that nobody reviews are agents that consume capacity without delivering value, and the SCU dashboard is the only thing that will tell you that is happening. One agent, one use case, a 30-day baseline, then the next one. The order matters more than the speed.Declutter and Defend: Reducing promotional mail noise with Microsoft Defender
Enterprise inboxes are overwhelmed with graymail — legitimate, bulk email like newsletters, vendor promotions, and product updates that isn't malicious but buries the messages that matter. When high volumes of these mails land in the inbox, it crowds out priority communications and can dull security vigilance. Employees conditioned to ignore repetitive emails may miss signs of a real threat. It also creates recurring work for admins and security teams who must continuously tune filters, manage exception requests, and chase noise from user reports for email that isn’t malicious. Because graymail passes every spam filter check, traditional defenses don't separate it — leaving this signal-to-noise gap unaddressed. Today we’re excited to announce that Microsoft Defender now includes built-in graymail filtering. It is delivered natively through a new Promotions experience in Outlook that automatically classifies and separates bulk email, so it no longer competes with business-critical communication in the inbox. Now in Public Preview, this capability learns from how users interact with graymail to become more accurate over time. Coupled with the existing Bulk Senders Insight report, Defender brings data-driven bulk classification and control into the security workflows you already use. What Is Graymail? Graymail is legitimate bulk email that isn't malicious—product newsletters, event announcements, marketing promotions, and software update notifications from reputable, authenticated senders. It is distinct from spam and from phishing - graymail comes from real organizations with proper authentication and traditional spam filters aren't designed to handle it. Graymail handling in Microsoft Defender Microsoft Defender's approach is built on three principles: classify intelligently, deliver natively, and learn continuously. Promotions Folder — Intelligent Inbox Organization A dedicated Promotions folder, natively provisioned in Outlook, now keeps legitimate bulk mail out of the primary inbox. Promotional content is separated from priority emails without being sent to Junk, which means users can still access and browse newsletters and updates at their own pace. The folder appears at the top level of the mailbox for easy discovery and is visible across all Outlook experiences. Non-spam bulk mail below the organization's configured Bulk Complaint Level threshold is automatically routed to the Promotions folder. Messages from senders the user has explicitly allowed continue to land in the Inbox. Messages identified as spam continue to go to Junk. To enable the Promotions folder administrators need to enable the "Bulk Moves Enabled" setting in their anti-spam policy. The Promotions folder is then created for all users and used for routing only when this setting is ON. Existing mail flow is unaffected. Promotional mail tagging and Mailbox Rule Support Messages classified as graymail will automatically be labeled with a "Promotions" system tag in Outlook. The tag provides instant visual context without requiring users to open each message and is visible in Outlook on the Web and the native Outlook desktop apps for Windows and Mac. During Public Preview, the tagging component is opt-in, requiring administrators to enable it by configuring an Exchange Transport Rule. Once generally available, it will be enabled by default. Because this classification is integrated at the client level, the Promotions tag can also be used as a condition in Outlook mailbox rules. This enables custom routing logic for advanced scenarios like moving all promotions-tagged messages from a specific sender to a custom folder, flagging certain promotional emails for follow-up, or auto-forwarding or deleting promotions that meet specific criteria. This transforms the Promotions classification from a one-way filter into a flexible building block for personal and organizational workflows—particularly valuable for power users and teams with compliance or archival requirements. Adaptive Learning Microsoft Defender's graymail filtering gets smarter with every interaction. The system learns directly from how users handle their mail. When a user moves a message out of the Promotions folder and back to the Inbox, future emails from that sender will no longer be placed in the Promotions folder. When a user moves a message from the Inbox into the Promotions folder, future emails from that sender will be routed to the Promotions folder automatically. This creates a personalized, self-improving experience that becomes more accurate over time - no manual rule configuration required, no safe-sender lists to maintain, and no filtering rules for IT teams to manage on behalf of individual employees. Built into existing Security Workflows Administrators also gain visibility through the Bulk Senders Insight report, which provides data-driven guidance on what your organization actually receives and can help tune your bulk mail filtering. Graymail has long been the unsolved middle ground of email security—too legitimate to block, too noisy to ignore. Microsoft Defender now handles it where it should be handled: inside the platform, inside the mailbox, and inside the security workflows your organization already relies on. No new portals, no new vendors, no compromise between security and user experience. Get Started Configure promotions tagging and the promotions folder today - Bulk email detection documentation on Microsoft Learn. Monitor the experience using the Bulk Senders Insight report.Enable per‑user language selection for phishing simulation emails and landing pages
We use Attack Simulation Training to deliver phishing simulations to a global, multilingual user base. While Microsoft Defender supports multi‑language content, phishing simulation emails and landing pages are currently delivered in a single selected language per campaign. We are requesting a feature that allows phishing simulation emails and associated landing pages (including credential‑harvest pages) to automatically render in each user’s preferred language, based on: Outlook mailbox language settings, and/or Microsoft Entra ID user language preferences This capability would: Improve realism and accuracy of phishing simulations Ensure users experience simulations in the same language they normally work in Improve behavioral measurement in global organizations Reduce the need to create and manage multiple parallel simulations by language Providing consistent, per‑user language alignment across simulation emails, landing pages, and follow‑up training would significantly enhance the effectiveness of Attack Simulation Training for large, multilingual enterprises.227Views2likes2Comments