Security Copilot: Agents

What it does

Security Copilot agents are autonomous, task-specific workers that run high-volume security jobs on their own — triaging phishing reports, prioritising alerts, tuning Conditional Access, remediating device vulnerabilities — and record their reasoning back in the product for a human to check.

Key facts

Phishing Triage Agent (Defender): classifies user-reported phishing, decides real threat vs false alarm, and explains its verdict. Runs autonomously against the submission queue.
Alert Triage Agent (Defender): triages alerts at scale, reaches a verdict with AI reasoning, and writes conclusions into Defender incidents so analysts prioritise faster.
Alert Triage for Purview: applies the same pattern to DLP and insider-risk (IRM) alerts.
Conditional Access Optimization Agent (Entra): finds gaps in CA policy coverage and proposes fixes; Microsoft cites large accuracy gains at spotting missing Zero Trust policies.
Vulnerability Remediation Agent (Intune): surfaces and helps remediate endpoint vulnerabilities and misconfigurations.
Threat Intelligence Briefing Agent: produces tailored threat-intel briefings relevant to the organisation.
At Ignite 2025 (18 Nov 2025) Microsoft expanded the line-up — roughly 12 Microsoft-built agents across Defender, Entra, Intune, and Purview, plus 30+ partner-built agents. Many are in preview.
Agents are built and governed through the agent framework / Copilot Studio tooling and the Microsoft 365 Agents SDK; partners publish agents into the same ecosystem.
Agents consume SCU capacity as they run — they're the biggest continuous consumer of units.

When to use / skip

If a specific high-volume queue is burying your team — reported phishing, low-fidelity alerts, CA drift — the matching agent is the strongest reason to buy Security Copilot at all. Turn them on where you have the volume and the trust to let something act semi-autonomously. Skip agents you don't have the workload for; an agent watching an empty queue still costs capacity and adds governance overhead. And don't switch on an autonomous agent until you've watched its verdicts long enough to trust them.

Configuration decisions

Which agents to deploy, and in which product — driven by where your actual pain and volume sit.
Autonomy level and human-in-the-loop: how much you let the agent close/action versus recommend-and-wait for an analyst.
The identity/permissions the agent runs under — an agent acts within a scope you grant, so scope it tightly.
Capacity budget per agent, given they run continuously and draw SCUs.
Whether to use Microsoft-built agents only, or bring in partner agents (and vet those partners' data access).

Gotchas

Agents are the silent SCU eater — a phishing agent on a busy tenant runs constantly and moves your bill in a way interactive prompting doesn't.
Many flagship agents are still preview; verdict quality and behaviour can change, and preview terms may not suit regulated clients.
"Autonomous" needs oversight — you own the agent's scope and its mistakes. Give it too much permission and it can act more broadly than intended.
Partner agents mean third-party access to your security data; treat onboarding one like any other vendor data-access review.
Microsoft's headline metrics (e.g. detection "550% faster", "204% greater accuracy") come from controlled/simulated tests — useful for direction, not for your SLA.

Consultant notes

Agents are the current sales narrative — lead with the one that maps to the client's loudest pain (usually phishing triage or alert triage).
Frame them as force-multipliers for tier-1 toil, not headcount replacement; that lands better with security leadership and is honest.
Build capacity planning around agents specifically — they change the SCU maths more than anything else.
With E5/E7 inclusion, agents are the reason to actually spend the included SCUs; pair the licence conversation with an agent that solves a real queue.

Most of the newer agents are preview — confirm GA status and current agent list per product before you scope any into a delivery.