Attack Investigation Agent

The Attack Investigation Agent is an autonomous tier 2 investigator for security operations teams. Starting from a single alert or incident, the agent correlates signals in Microsoft Defender to reconstruct the attack story, scope, and impact.

You can start an investigation with or without prior triage by an analyst or the Triage Agent. This article describes the agent's capabilities and prerequisites. It also explains how to set up the agent, run and monitor a session, and review the results.

Key capabilities

The Attack Investigation Agent runs a multi-step, AI-orchestrated investigation that:

• Reconstructs the full attack story: Explains who attacked, how they gained access, which resources they affected, and the scope and impact of the attack. The agent goes beyond individual alerts.
• Provides clear, actionable answers: Explains the attack scope, initial access, progression, technical impact, investigation status, and classification.
• Investigates a broad range of attacks: Investigates attacks involving users, devices, cloud apps, containers, and other entities without relying on a predefined scenario.
• Supports interactive investigation: Lets analysts chat with the agent throughout the investigation to ask questions or request deeper analysis.
• Adapts to your environment: Uses multiple data sources and follows your organization's policies and practices.

Prerequisites

Required licenses

To use the Attack Investigation Agent, your organization needs:

• Microsoft 365 E5
• Microsoft Defender XDR

Your organization must also be onboarded to the Microsoft Defender data lake and unified security experience.

For broader investigation coverage, the recommended products depend on the attack type:

• Cloud and container attacks:
  • Microsoft Defender for Cloud
  • Microsoft Defender for Containers
• Identity attacks:
  • Microsoft Entra ID P2
  • Microsoft Defender for Identity
  • Microsoft Defender for Cloud Apps

Recommended role-based access control

Use Microsoft Defender unified role-based access control (RBAC). This configuration is recommended for investigation quality and coverage.

Access to scoped resources

If your organization uses Defender for Endpoint device groups, add the agent identity to all device groups it needs before running a session. Agent setup doesn't do this for you, and incidents involving devices in an unassigned group fail or return incomplete findings.

For other scoping, see Set up an agent.

Recommended configuration for phishing investigations

For the best coverage and investigation quality in user-reported phishing investigations, configure the following settings:

• Microsoft Defender for Office 365: Configure the following user reported settings:
  • Select Monitor reported messages in Outlook.
  • Configure user reported messages to go to the reporting mailbox, to Microsoft, or both. If you use a non-Microsoft reporting tool, configure the tool so reported messages go to Microsoft and the reporting mailbox or to the reporting mailbox only.
• Microsoft Defender:
  • Enable the Email reported by user as malware or phish alert policy. For more information, see Alert policies in Microsoft Defender.
  • Disable the built-in Auto-Resolve - Email reported by user as malware or phish alert tuning rule and any custom tuning rules that resolve this alert. For more information, see Tune an alert.

Set up the agent

To set up this agent, follow the steps in Set up an agent.

Start a session

For ways to start a session, see Start a new session.

The Attack Investigation Agent uses the following playbook:

Monitor session progress

While the session runs, the session detail panel shows:

• Summary: Current session status and completed work.
• Progress: Completed investigation steps.
• Agents: The agent assigned to the session.
• Inputs: The alert or incident ID you provided.
• Artifacts: Output files generated during the investigation.

Session status values

Review the output

The Attack Investigation Agent produces an investigation report with the following sections:

• Executive summary: An overview of the attack for stakeholders and escalation.
• Incident verdict: Classification as true positive, false positive, or benign with transparent reasoning.
• Attack timeline: A chronological sequence of key events showing the progression of the attack from initial access through post-compromise activity.
• Affected entities: Identified users, devices, and applications affected by the attack.
• MITRE ATT&CK techniques observed: Mapping of observed attacker behavior to MITRE ATT&CK techniques with evidence for each technique.
• Indicators of compromise: Extracted and enriched indicators of compromise (IOCs), including IP addresses, domains, file hashes, URLs, and email addresses with threat intelligence context.
• Recommended next steps: Prioritized actions for containment, remediation, and prevention.

The report appears as a Markdown file in the Artifacts section of the session details. You can download the report to add to incident documentation or compliance records.

Troubleshoot incident and alert retrieval

If a session reports that an incident or alert couldn't be found or accessed, the resource might still exist and be visible to you. Your access doesn't establish the agent's access, and the error alone doesn't identify the cause.

Before you begin troubleshooting:

1. In the Microsoft Defender portal agentic session page, locate the incident, case, or alert that triggered the agent. The agent can access an incident or case if it has read permission on one or more of its alerts.

2. In the Microsoft Defender portal, go to Perception > Agents > Attack Investigation Agent, open the agent, and use the identity details to identify the agentic user and its unified RBAC role. Select View access, and then select View role details to go to the role currently assigned to the agent.

   

Incidents can contain alerts from multiple workloads. Complete every applicable check.

Check the incident age

The Attack Investigation Agent supports incidents, cases, and alerts that are up to 30 days old.

1. Open the incident, case, or alert in the Defender portal.

2. Review its age.

   

3. If it is more than 30 days old, use a newer seed. Data outside the supported window can't be accessed by the agent, even though it might still be available in the Microsoft Defender portal.

Check workload read access

Use the alerts in the incident or case to identify every workload that the agent must access.

1. On the incident or case page, select the Alerts tab.

2. Open each alert and note the values of Service sources, Detection sources, and Product names. The agent will need to have read permission on the sources of at least one alert.

   

3. Navigate to Setup & configuration > Settings > Microsoft Defender XDR > Permissions and roles. Make sure the workloads relevant to the alert products are enabled for unified RBAC.

   

4. Go to the agent unified RBAC role, which you located earlier from the agent page.

5. Verify that the assignment includes Security data basics (Read) for every relevant data source.

6. For every workload that uses scoping, verify that the agent is allowed access to all scopes that apply to the alerts it is investigating. For more information, see Manage cloud scopes and unified RBAC in Microsoft Defender for Cloud and Configure scoped access for Microsoft Defender for Identity.

   

Check Microsoft Sentinel workspace access

If an alert comes from Microsoft Sentinel, identify its source workspace using Advanced Hunting. The workspace must be connected to the Defender portal and available to the agentic user.

1. To locate the Sentinel workspace, navigate to Investigation & response > Hunting > Advanced hunting, and execute the following query: AlertInfo | where AlertId == '...' | project SentinelWorkspaceIds. Make sure to adjust the time filter according to the selected alert.

2. Make sure the workspace is connected to Microsoft Defender in Setup & configuration > Settings > Microsoft Sentinel > SIEM workspaces.

3. Make sure it is enabled for unified RBAC in Setup & configuration > Settings > Microsoft Defender XDR > Permissions and roles. Expand the Microsoft Sentinel workload and verify that the exact workspace is activated. If it is not enabled for unified RBAC and you prefer it to stay this way, see note below.

   

4. Go to the agent unified RBAC role, which you located earlier from the agent page. Verify that the agent's role assignment includes that workspace.

   

Check endpoint device-group access

Defender for Endpoint device-group access is configured separately from unified RBAC role permissions.

1. On the incident or case page, identify every device associated with any of the included alerts.
2. Open each device page and note its device group.
3. Go to Settings > Endpoints > Permissions > Device groups.
4. Open each required device group and review User access.
5. Verify that the device group allows a Microsoft Entra security group that contains the agentic user.

The complete access chain must exist: agentic user to Microsoft Entra security group to Defender for Endpoint device group. Unified RBAC permissions or membership in an unassigned security group alone don't grant device-group access. For more information, see Create and manage device groups in Microsoft Defender for Endpoint.

Check permissions outside unified RBAC

Some alert types use permission models outside Defender unified RBAC.

DLP alerts

Microsoft Purview governs access to DLP alerts. Defender unified RBAC alone doesn't grant this access.

• If Service sources, Detection sources, or Product names identifies DLP, verify the agentic user's Microsoft Purview role-group membership. For more information, see Roles for investigating DLP alerts in Defender XDR.
• If your organization uses Microsoft Purview administrative units, verify that the assignment's administrative-unit scope includes the affected data. For more information, see Administrative units in Microsoft Purview permissions.

App governance alerts

Microsoft Entra roles govern access to app governance alert and incident data. Defender unified RBAC alone doesn't grant this access.

1. If Detection source identifies app governance, assign the agentic user the Security Reader role in Microsoft Entra.
2. Start a new session after the role assignment propagates.

For more information, see Required roles for app governance and Microsoft Defender for Cloud Apps permissions in unified RBAC.

Retry after an access change

After an approved change, allow time for the permission update to propagate and start a new session. If retrieval still fails, provide Microsoft Support with the tenant, session, and incident or alert IDs.

Related content

• What is Project Perception?
• Understand key concepts in Project Perception
• Work with agents
• View and manage sessions
• Recon Agent
• Triage Agent