0.8 Defender XDR Automation Architecture

Attack disruption: containment in three minutes

Attack disruption is the most aggressive automation in the Microsoft security stack. It does not investigate. It does not recommend. It contains. The correlation engine identifies an in-progress attack by aggregating signals from Defender for Endpoint, Defender for Identity, Defender for Office 365, and Defender for Cloud Apps into a single high-confidence incident. The response engine selects the containment action. The action executes automatically, typically within three minutes of initial signal correlation.

The system recognizes three attack patterns: adversary-in-the-middle (session hijacking via real-time credential relay), business email compromise (fraudulent financial requests using compromised mailboxes), and human-operated ransomware (lateral movement toward domain-wide encryption). These three patterns represent the highest-impact attack types in M365 environments, where minutes of delay in containment can mean the difference between a contained incident and a catastrophic breach.

Three containment actions are available. Device containment through Defender for Endpoint blocks all inbound and outbound network communication on the compromised device while preserving the Defender agent's connection for continued monitoring. User disablement through Defender for Identity suspends the compromised account across the tenant. IP containment blocks traffic from malicious IP addresses associated with undiscovered or non-onboarded devices, preventing lateral movement to endpoints that Defender for Endpoint manages.

The scope limitation is the critical architectural constraint. Attack disruption fires only on patterns that Microsoft's ML models recognize with high confidence. A custom attack tool that doesn't match known ransomware behavior will not trigger disruption. A credential theft technique that operates below the detection threshold will not trigger disruption. An attack chain that spans M365 and a non-Microsoft data source (on-premises firewall, third-party cloud application) will not trigger disruption because the correlation engine only processes Microsoft signal sources. This is where your Sentinel automation fills the gap: custom detections with custom containment logic for the threats that are specific to your environment.

The agent version prerequisite catches organizations off guard. The Contain User action requires Defender for Endpoint agent version 10.8470 or later. NE's manufacturing floor has 53 devices running an older version, which means attack disruption cannot contain users authenticating from those devices. The fix is an agent update, but the diagnostic step matters: if you don't audit agent versions, you don't know which devices are outside the containment boundary.

Automated Investigation and Response

AIR is the second automation layer. When an alert fires from any Defender product, AIR automatically investigates: it examines the process tree, checks related files, reviews network connections, queries identity activity, and identifies other entities that may be affected. Based on the investigation findings, AIR recommends or executes remediation actions.

AIR operates in four automation levels, configured per device group. Full automation investigates and remediates without human approval. Semi-automation investigates automatically but holds remediation actions in the Action Center for analyst approval. The third level requires approval for any remediation. The fourth disables AIR entirely. The level is set per device group, which means you can configure full automation for standard workstations (low blast radius, high false-positive tolerance) and semi-automation for servers and VIP devices (high blast radius, where false containment is expensive).

Action Center — AIR Investigation #4782 (NE Tenant)
=====================================================
Investigation ID:   4782
Trigger:            Malware alert on WKSTN-FIN-042
Start time:         2026-05-12T14:23:18Z
Duration:           3m 47s
Automation level:   Full (Workstation device group)
Actions Taken:
  [COMPLETED] Quarantine file: C:\Users\j.morrison\AppData\invoice_q2.exe
              SHA256: 8a4f2c... (Trojan:Win32/Casdet!rfn)
  [COMPLETED] Block file hash tenant-wide
              SHA256: 8a4f2c... added to custom indicators
  [COMPLETED] Quarantine email: message containing invoice_q2.exe
              Sender: external-supplier@contoso-fake.com
  [COMPLETED] Block sender domain: contoso-fake.com
  [SKIPPED]   Isolate device: WKSTN-FIN-042
              Reason: File already quarantined, no active process
Entities Investigated:
  Device:     WKSTN-FIN-042 (compliant, agent v10.8560)
  User:       j.morrison@northgate-eng.com (risk: low)
  File:       invoice_q2.exe (VT: 48/72 detections)
  Email:      3 recipients, 1 opened attachment
  Related:    0 additional devices with same file hash

This log shows what full-automation AIR produces. The investigation started on a malware alert, examined the process tree, found the file was delivered via email, quarantined both the file and the email, blocked the file hash and sender domain tenant-wide, and determined that device isolation was unnecessary because the threat was already neutralized. The entire sequence completed in under four minutes without analyst involvement.

The distinction between AIR and attack disruption matters for your automation design. Attack disruption acts on attack patterns (multi-signal correlation across products). AIR acts on individual alerts (single-product investigation triggered by one detection). Attack disruption contains. AIR investigates and remediates. In an AiTM attack, disruption might disable the compromised account within three minutes. AIR might separately investigate the phishing email that delivered the credential harvesting page and quarantine it. Both actions are correct. Both happen independently.

Built-in alert tuning rules, which became generally available in April 2026, add a third automation layer. These rules suppress alerts from common benign activity in Defender for Endpoint and Defender for Office 365 without affecting AIR investigations or email notifications. Microsoft ships 12 initial rules targeting MDO alerts. The tuning rules reduce the alert volume that reaches your SOC queue, which directly reduces the volume that your Sentinel automation rules process. If built-in tuning suppresses 200 benign email alerts per day, your Sentinel enrichment playbooks run 200 fewer times per day.

Custom detection rules with auto-actions

Custom detection rules are KQL queries that run against the advanced hunting tables on a schedule. When the query returns results, Defender creates an alert and can automatically execute response actions on the entities in the results: isolate the device, quarantine the file, disable the user, block the URL, or force a password reset.

This is the Defender equivalent of a Sentinel analytics rule combined with a playbook, compressed into a single configuration. The advantage is speed: the response action executes directly from the detection with no Logic App overhead, no managed identity configuration, and no connector setup. The disadvantage is scope: the response actions are limited to Defender's built-in capabilities. You cannot call external APIs, query non-Microsoft data sources, check a VIP watchlist, or implement approval gates.

// Custom detection: encoded PowerShell downloading from external URL
// Auto-action: Isolate device on match
// Frequency: Every hour (balance detection speed vs query quota)
DeviceProcessEvents
| where Timestamp > ago(1h)
| where FileName =~ "powershell.exe"
    or FileName =~ "pwsh.exe"
| where ProcessCommandLine has_any (
    "-EncodedCommand", "-enc", "-e ",
    "FromBase64String", "[Convert]::"
)
| where ProcessCommandLine has_any (
    "http://", "https://", "Invoke-WebRequest",
    "wget", "DownloadString", "DownloadFile"
)
| project Timestamp, DeviceId, DeviceName,
    AccountName, ProcessCommandLine, InitiatingProcessFileName

This detection identifies encoded PowerShell commands that also reference external URLs, a common initial access and execution pattern. The custom detection rule runs this query every hour against DeviceProcessEvents. When it returns results, Defender creates an alert and automatically isolates the matching device. The detection and the response are both within Defender's product scope: the query reads from an MDE table, and the response action uses MDE's isolation API. No Sentinel playbook, no Logic App, no external integration needed.

Custom detections gained near-real-time (NRT) capability in October 2025 for Defender data and expanded to Sentinel data in January 2026. NRT rules run within minutes of data ingestion rather than on a fixed schedule. For high-severity detections where hourly frequency is too slow, NRT provides faster detection without the query quota cost of running every five minutes. As of April 2026, custom detection rules also require projecting the SentinelScope_CF column for queries that target Sentinel-scoped data, or alerts generated by those rules may be invisible to scoped analysts.

The scheduling and quota constraints shape how you use custom detections. Every rule consumes query quota from the advanced hunting allocation. Running 20 rules every hour consumes significantly more quota than running 20 rules every 24 hours. The design principle is to match frequency to severity: high-severity detections (ransomware indicators, credential theft patterns) run hourly or NRT. Medium-severity detections (suspicious process execution, anomalous network connections) run every 12 or 24 hours.

Predictive shielding

Predictive shielding entered preview in December 2025 and represents the next evolution of Defender XDR's automated protection. While attack disruption reacts to attacks in progress, predictive shielding aims to block attacks before they execute by applying temporary protective measures to assets that show early indicators of compromise. The capability is still in preview as of May 2026, but it signals the direction: Defender XDR is moving from reactive containment toward preemptive protection.

For NE's automation design, the practical impact is straightforward. Predictive shielding actions appear alongside attack disruption actions in the Action Center. The same monitoring process applies: review the Action Center weekly, validate that predictive actions are not disrupting legitimate business operations, and verify that the assets receiving shielding are the assets you expect.

The coordination problem

The architectural challenge is not that either platform is insufficient. The challenge is that both operate independently. Defender XDR's attack disruption disables a compromised account. Ten minutes later, a Sentinel containment playbook fires on the same incident and attempts to disable the same account. The Graph API call returns an error because the account is already disabled. The playbook logs a failure. The SentinelHealth table shows a failed playbook execution. The analyst sees the failure and spends twenty minutes diagnosing a problem that does not exist.

The coordination framework has three components. First, the Sentinel playbook checks the current entity state before acting. For identity containment, query the Graph API for the account's current status. If the account is already disabled, skip the disable action, log "already contained by Defender XDR," and proceed with the remaining playbook steps (MFA reset, inbox rule audit, delegate removal) that Defender's containment did not perform. Second, the Action Center review is a weekly governance task. The SOC lead reviews every attack disruption and AIR action, verifies that containment was appropriate, and documents the actions in the incident report. Third, the automation health dashboard (built in Section 0.9) tracks both platforms: Sentinel playbook execution alongside Defender Action Center actions, on a single pane.

The decision framework: where to automate

Every automation requirement maps to one of two platforms based on two questions. Is the detection and the response entirely within Defender's product scope? And does the response require environmental context, conditional logic, or external integration?

Single-product, fast-action responses belong in Defender XDR. A custom detection for encoded PowerShell that auto-isolates the device. AIR investigating a malware alert and quarantining the file. Attack disruption containing a compromised account during an AiTM attack. These are self-contained: detection and response use the same product APIs with no external dependencies.

Cross-product orchestration belongs in Sentinel. A detection that correlates identity anomalies with endpoint behavior and firewall logs. A response that revokes sessions, resets MFA, audits inbox rules, notifies the SOC channel via Teams, creates a ServiceNow ticket, and routes the containment decision through an approval gate for VIP users. These require Logic Apps because the workflow spans multiple APIs, multiple products, and conditional decision points that Defender's built-in actions cannot express.

Both platforms should be active simultaneously. The correct architecture uses Defender for fast, high-confidence, single-product actions and Sentinel for complex, context-aware, multi-product orchestration. Disabling Defender AIR because "we want all automation in Sentinel" removes real-time investigation capability that operates faster than any Logic App. Ignoring Sentinel because "Defender handles it" removes the ability to automate anything that requires your environment's context: your VIP watchlist, your blast radius classifications, your notification routing, your approval gates.