Automating Incident Response: How AI Can Help Your SOC

AI-assisted incident response applies machine learning and generative AI models to specific steps in the SOC workflow: scoring and prioritizing alerts, enriching indicators of compromise with context, drafting incident summaries, and translating analyst questions into SIEM queries. It does not replace analyst judgment on any action with real business impact, such as isolating a production server or disabling an executive’s account: that decision stays human.

The alert fatigue problem

Here's a typical day for a SOC analyst: 500 alerts, 8 hours, 2 actual incidents buried somewhere in the noise. The rest? False positives, low-priority events, and alerts that could have been auto-resolved.

This isn't sustainable. Analysts burn out, real threats get missed, and security suffers.

Automation isn't about replacing analysts. It's about handling the tedious stuff so humans can focus on what requires human judgment. For the manual steps automation should eventually replace, our Azure incident response playbook is a good baseline to start from.

What can (and should) be automated

Tier 1: full automation

These should happen without human involvement:

• Known false positives
• Automatic enrichment (adding context to alerts)
• Standard responses (password resets after phishing, blocking known-bad IPs)
• Compliance logging

Tier 2: automation with verification

Automation does the work, human confirms before execution:

• Account lockouts
• Quarantining endpoints
• Blocking domains/IPs

Tier 3: human-led, AI-assisted

Complex incidents where AI provides analysis:

• Advanced malware investigation
• Insider threat cases
• Incident scoping

The pattern across all three tiers is the same rule of thumb: automation owns volume and reversible, well-understood actions; a human owns anything destructive, ambiguous, or tied to business impact. That is the decision framework in one sentence. If an action can be undone in seconds and getting it wrong costs almost nothing, such as blocking a known-bad hash or tagging an alert resolved, automate it fully. If getting it wrong disrupts a production system, locks out a legitimate user, or carries legal or compliance weight, route it through a human approval step no matter how confident the model’s score is.

Building your automation stack

SOAR platforms

Popular options: Microsoft Sentinel + Logic Apps, Splunk SOAR, Palo Alto XSOAR, Tines. If Sentinel is part of your stack, our threat hunting with Microsoft Sentinel and KQL guide covers the queries that feed these automated playbooks.

Most of these platforms still run as linear playbooks: an alert comes in, fixed steps execute in order. That model breaks down once a playbook grows past a few dozen branches. Our comparison of agentic AI patterns vs traditional SOAR playbooks in Azure Logic Apps covers when a reasoning-loop agent with approved tools replaces part of that branching tree, and when a deterministic playbook is still the safer, more auditable choice.

AI-assisted alert triage: scoring, not just filtering

Traditional alert triage is binary: an alert either matches a rule and fires, or it doesn't. AI-assisted triage replaces that binary gate with a score, weighing several signals together before an alert ever reaches an analyst's queue:

• Asset criticality: is the affected host a domain controller or a break-room kiosk?
• Threat intelligence match: does the IOC appear on a feed your organization already trusts?
• User risk signals: has this account triggered impossible-travel or MFA-fatigue alerts recently?
• Historical outcome: has this specific alert rule been a false positive most of the time over the last quarter?

Microsoft Sentinel's Fusion detection engine is a production example of this approach: instead of scoring a single alert in isolation, it correlates multiple low-confidence signals from different data sources into one higher-confidence incident, the same logic a manual scoring rubric follows on a smaller scale. Microsoft Security Copilot extends this further inside Sentinel and Defender XDR, surfacing a prioritized, context-attached queue instead of a flat alert list. For a full walkthrough of what Copilot does across a security team's daily workflow, see our Microsoft Security Copilot guide.

Before wiring any scoring model into live alert data, review how it could be manipulated. An attacker who understands your scoring rubric can craft activity that scores deliberately low, the AI equivalent of an evasion technique. Our AI security risks and best practices guide covers prompt injection and data leakage risks that apply directly to a triage model reading attacker-controlled alert text.

Automated enrichment: building context before a human looks at the alert

Enrichment is the step between "an alert fired" and "an analyst can make a decision." Done manually, it is the single biggest source of wasted analyst time: pivoting across browser tabs to check a hash reputation, a domain’s registration date, and whether the affected account has admin rights. Automated enrichment does that lookup work before the alert reaches a human, attaching the answer instead of leaving a question.

A useful minimum enrichment set for most alert types:

• Sender and domain reputation, including domain age and prior abuse reports
• File hash reputation against a threat intelligence feed
• URL detonation result from a sandboxing service
• Asset context: owner, department, criticality tag, patch status
• Identity context: recent sign-in locations, MFA status, group memberships

The phishing playbook below is a concrete example of this pattern in practice: steps 1 and 2 are pure enrichment, and only step 3 makes a decision based on what was collected.

Basic automation playbook: phishing response

1. Extract indicators (sender, URLs, attachment hashes)
2. Enrich (check threat intel, scan URLs, analyze attachments)
3. Auto-classify based on findings
4. Execute response actions
5. Document everything

AI-drafted incident summaries for handoff

Shift handoff is a documentation problem as much as a technical one. An analyst closing out an 8-hour shift needs to leave a clean summary: what happened, what was affected, what actions were already taken, what's still open. Writing that summary well takes time most analysts don't have at the end of a long shift, so it often gets skipped or reduced to a one-line ticket comment.

An LLM with access to the incident's raw data, meaning the alert timeline, enrichment results, actions taken, and analyst notes, can draft that summary in seconds, in a consistent format every time. That consistency is the real value: a night-shift analyst picking up an incident at 3 AM shouldn't have to guess which format the previous analyst used.

The risk is treating the draft as fact instead of a starting point. A generated summary can omit a detail that wasn't in its input, or state a timeline with more confidence than the underlying data supports. Before a handoff summary informs any containment decision, the receiving analyst should confirm the specific facts that matter (affected assets, IOCs, actions already taken) against the raw alert and log data, not just the AI's paraphrase of it.

Natural-language queries over SIEM data

Writing KQL well takes practice, and not every analyst on a rotation has it. Natural-language-to-query features, like the ones built into Microsoft Security Copilot for Sentinel, let an analyst ask something like "show me sign-ins from this user in the last 24 hours from outside the usual country" and get a generated KQL query back instead of writing one from scratch.

Treat the generated query as a draft, not a verified result. Confirm it is actually filtering on the fields you meant (a query scoped to the wrong sign-in log table will return a clean, confidently wrong empty result) before acting on what it returns. For hunts where the query itself is the deliverable and not just a one-off lookup, our threat hunting in Microsoft Sentinel guide linked above is written KQL-first for exactly that reason.

Measuring success

Common pitfalls and failure modes

1. Automating too much too fast

Start small. Pick one alert type, automate it well, measure results, then expand.

2. No human override

Always have a way to disable automation.

3. Poor documentation

Every automated action should be logged.

4. Set and forget

Automation needs maintenance. Threats evolve.

5. Alert fatigue from a poorly tuned triage model

A scoring model that is not tuned to your environment just moves the alert fatigue problem instead of solving it: if it scores too many low-value alerts as high-priority, analysts learn to ignore high scores the same way they learned to ignore raw alert floods. Tune the model against your own historical true- and false-positive labels before trusting its output, and re-tune it on a schedule, not once at rollout.

6. Trusting AI-generated summaries without verification

An incident summary that reads confidently and looks complete is not the same as one that is accurate. Treat AI-drafted summaries the way you'd treat a junior analyst's first draft: useful as a starting point, not as the record of what happened until a human confirms the key facts against source data.

7. Automation bias

Automation bias is the tendency to defer to a system's output even when your own judgment disagrees with it, simply because the system is usually right. It shows up in SOCs as analysts rubber-stamping AI triage scores or AI-suggested containment actions without independently checking them. The fix isn't distrust by default, it's making sure analysts still see the raw evidence alongside the AI's conclusion, not just the conclusion, so disagreeing with the model stays a normal, easy action instead of friction.

Guardrails for AI-driven actions

Human approval for destructive actions. Never let an automated or AI-recommended action execute unattended if it disables an account, isolates a production asset, deletes data, or otherwise carries real business impact, regardless of how confident the score is. Route those actions to a human approval step with the AI’s reasoning attached, so the approver sees why the system flagged it, not just a yes-or-no button.

Audit logging for every AI-driven decision. Log the alert, the score or recommendation, the model or prompt version that produced it, and the human's final decision, for every AI-assisted action, not just the ones that were auto-executed. That log is what lets you catch a drifting model before it causes damage, and it's what you'll need if an automated decision is ever questioned during a post-incident review or an audit.

Practical guide: PowerShell and CLI commands for incident response

These are real commands you can use during incident response. Copy, adapt, and automate them.

Initial triage commands

Get system information:

# Windows - Basic system info
Get-ComputerInfo | Select-Object CsName, WindowsVersion, OsArchitecture, LastBootUpTime

# Linux - System overview
hostnamectl && uptime && who

Check running processes:

# Windows - Find suspicious processes
Get-Process | Sort-Object CPU -Descending | Select-Object -First 20 Name, Id, CPU, Path

# Windows - Processes with network connections
Get-NetTCPConnection | Where-Object {$_.State -eq 'Established'} |
    Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, OwningProcess,
    @{Name='ProcessName';Expression={(Get-Process -Id $_.OwningProcess).ProcessName}}

# Linux - Active connections with processes
ss -tunapl | grep ESTAB

Check scheduled tasks and persistence:

# Windows - Scheduled tasks (common persistence mechanism)
Get-ScheduledTask | Where-Object {$_.State -eq 'Ready'} |
    Select-Object TaskName, TaskPath, State

# Windows - Startup programs
Get-CimInstance Win32_StartupCommand | Select-Object Name, Command, Location

# Linux - Cron jobs for all users
for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l 2>/dev/null; done

Log collection commands

Windows Event Logs:

# Failed login attempts (last 24 hours)
Get-WinEvent -FilterHashtable @{LogName='Security';Id=4625;StartTime=(Get-Date).AddHours(-24)} |
    Select-Object TimeCreated, @{N='User';E={$_.Properties[5].Value}},
    @{N='Source IP';E={$_.Properties[19].Value}}

# Successful logins from new sources
Get-WinEvent -FilterHashtable @{LogName='Security';Id=4624;StartTime=(Get-Date).AddHours(-24)} |
    Where-Object {$_.Properties[8].Value -notin @(2,7)} |
    Select-Object TimeCreated, @{N='User';E={$_.Properties[5].Value}},
    @{N='LogonType';E={$_.Properties[8].Value}}

# PowerShell execution logs
Get-WinEvent -LogName 'Microsoft-Windows-PowerShell/Operational' -MaxEvents 100 |
    Where-Object {$_.Id -eq 4104} | Select-Object TimeCreated, Message

Linux Logs:

# Authentication failures
grep -i 'failed\|failure' /var/log/auth.log | tail -50

# SSH access
grep 'sshd' /var/log/auth.log | grep -E 'Accepted|Failed' | tail -50

# Sudo usage
grep 'sudo' /var/log/auth.log | tail -50

Containment actions

Isolate a compromised machine:

# Windows - Block all outbound except management
New-NetFirewallRule -DisplayName 'IR-Block-Outbound' -Direction Outbound -Action Block
New-NetFirewallRule -DisplayName 'IR-Allow-Management' -Direction Outbound -Action Allow -RemotePort 22,3389 -Protocol TCP

# Linux - Block all outbound (iptables)
iptables -I OUTPUT -p tcp --dport 1:65535 -j DROP
iptables -I OUTPUT -p tcp --dport 22 -j ACCEPT  # Keep SSH

Disable compromised account:

# Windows - Disable AD account
Disable-ADAccount -Identity 'compromised_user'

# Windows - Force logout
query user /server:COMPUTERNAME
logoff SESSION_ID /server:COMPUTERNAME

# Linux - Lock account
passwd -l compromised_user
pkill -u compromised_user

Kill malicious process:

# Windows - Kill by name
Stop-Process -Name 'malware' -Force

# Windows - Kill by PID
Stop-Process -Id 1234 -Force

# Linux
kill -9 1234

Evidence preservation

Hash suspicious files:

# Windows
Get-FileHash -Path 'C:\suspicious\file.exe' -Algorithm SHA256

# Linux
sha256sum /path/to/suspicious/file

Copy evidence with metadata:

# Windows - Copy preserving timestamps
robocopy 'C:\Users\victim\' 'E:\Evidence\' /COPY:DAT /E /LOG:evidence.log

# Linux - Copy with metadata
cp -a --preserve=all /home/victim /evidence/

Automation script template

Here's a basic PowerShell script to automate initial triage:

# IR-Triage.ps1 - Run on suspected compromised machine
$OutputPath = 'C:\IR-Evidence'
New-Item -ItemType Directory -Path $OutputPath -Force

# System Info
Get-ComputerInfo | Out-File "$OutputPath\system-info.txt"

# Network Connections
Get-NetTCPConnection | Export-Csv "$OutputPath\connections.csv"

# Running Processes
Get-Process | Select-Object Name, Id, Path, CPU | Export-Csv "$OutputPath\processes.csv"

# Recent Security Events
Get-WinEvent -FilterHashtable @{LogName='Security';StartTime=(Get-Date).AddHours(-24)} |
    Export-Csv "$OutputPath\security-events.csv"

# Create archive
Compress-Archive -Path $OutputPath -DestinationPath 'C:\IR-Evidence.zip'

Getting started this week

Day 1-2: Pick one high-volume, low-complexity alert type
Day 3-4: Build enrichment automation
Day 5: Add auto-classification
Week 2: Add response actions for clear-cut cases
Week 3+: Expand to other alert types

Automation is a force multiplier, not a replacement. The goal is a team of 5 operating like a team of 20, not a team of 0.

Frequently asked questions

What types of SOC tasks are best suited for full automation without human review?

Tasks best suited for full automation are those with well-understood, deterministic outcomes: enriching alerts with threat intelligence context, blocking known-bad IPs or domains from active blocklists, resetting passwords after confirmed phishing where policy requires it, and logging compliance events. These qualify because the correct action is unambiguous and the risk of an incorrect automated action is low. Tasks requiring judgment, such as account lockouts or endpoint quarantine, should include a human confirmation step.

What is SOAR and how does it differ from a SIEM?

SIEM (Security Information and Event Management) collects, normalizes, and correlates log data to surface alerts. SOAR (Security Orchestration, Automation, and Response) takes action on those alerts: enrichment, notifications, and containment steps. A SIEM tells you what happened; a SOAR does something about it. Microsoft Sentinel bundles both functions in one platform, while dedicated SOAR tools like Tines or Palo Alto XSOAR integrate with an existing SIEM. Our SIEM vs SOAR vs XDR guide breaks down all three categories and 8 comparison criteria in full.

How do you measure the success of SOC automation?

The four metrics that best capture automation effectiveness are Mean Time to Acknowledge (MTTA), Mean Time to Respond (MTTR), alerts per analyst per day, and false positive rate. Targets vary by organization, but meaningful benchmarks are: MTTA under 10 minutes, MTTR under 2 hours for high-severity incidents, fewer than 50 meaningful (non-false-positive) alerts per analyst per day, and a false positive rate below 50%. Track these monthly and compare pre- and post-automation baselines.

What is the biggest mistake teams make when starting SOC automation?

The most common mistake is trying to automate too many alert types simultaneously without validating each one first. Automation errors compound: if a playbook incorrectly classifies a legitimate action as malicious and auto-blocks it at scale, the impact is much larger than a single analyst making the same mistake. The correct approach is to start with one high-volume, low-complexity alert type, run the playbook in observation mode for two weeks to validate its decisions, then enable automated response for that single type before expanding.

What are the most important forensic evidence preservation steps during incident response?

Preserve evidence before any remediation action. The critical steps are: create memory dumps of running systems before rebooting (memory contains process lists, network connections, and encryption keys), hash all suspicious files with SHA-256 and document the hash before touching them, use forensic copy tools that preserve metadata and timestamps rather than standard file copy, and document the chain of custody for all collected evidence. Evidence collected carelessly or after remediation is often inadmissible in legal proceedings and insufficient for insurance claims.

How do you prevent an AI triage model from creating a new kind of alert fatigue?

Tune the scoring model against your own environment's historical true-positive and false-positive labels before trusting its output in production, run it in observation mode alongside your existing triage process for two to four weeks, and re-tune it on a recurring schedule as your asset inventory and threat landscape change. A model trained once and never revisited drifts the same way a static detection rule does, just with less visibility into why.

Should AI ever be allowed to take containment actions without human approval?

Only for narrow, low-risk, easily reversible actions with a well-understood blast radius, such as blocking a hash or IP address already confirmed malicious by multiple threat intelligence sources. Any action that disables an account, isolates a production system, or otherwise carries real business or legal impact should require a human approval step, with the AI's reasoning and confidence score attached so the approver isn't deciding blind.