Purview triage agents: what they actually do before you turn them on
Security Copilot agents can now triage DLP and Insider Risk alerts inside Purview. What they prioritise, the alerts they quietly skip, and the SCU and identity details to sort out before deployment.
What they are
Purview now hosts Security Copilot agents, in preview: a Triage Agent for DLP, a Triage Agent for Insider Risk Management, and posture agents for DSPM and Data Security Investigations.
The triage agents do one job: work the alert queue. Each agent evaluates alerts, sorts them into categories (Needs attention, Less urgent, Not categorized), and writes an explanation of its reasoning. The Alerts page gets a toggle between the standard view and the triage agent view.
That job description matters. These are queue sorters with explanations, not investigators. They reduce the time your team spends deciding what to look at first; they do not decide what to do about it.
How they prioritise
The DLP agent weighs content risk (SITs, trainable classifiers, and sensitivity labels found in the matched content), exfiltration risk (sensitive data shared externally), and policy risk (the mode and actions of the rule that fired). Label removals and downgrades raise the score.
The IRM agent weighs activity risk (which activities carry the highest exfiltration likelihood, with historical alert insights) and user risk (priority user group membership, number of active cases).
You can steer both with custom instructions in the agent's triggers, and choose between scheduled automatic runs or manual one-alert-at-a-time triage. The alert timeframe is configurable from new-alerts-only up to a 30-day lookback, and the lookback needs sufficient SCU capacity to chew through the backlog.
The alerts they quietly skip
This is the section to read before trusting the categorised queue.
The DLP agent only triages alerts from policies in active mode. Simulation-mode alerts are ignored entirely.
It only evaluates conditions built on SITs and trainable classifiers. A rule that fires on email subject matches alone will not be triaged. Rules mixing supported and unsupported conditions get partially triaged, with caveats.
Device alerts need evidence collection for file activities enabled before the agent can triage them.
Big alerts get sampled. Ten or more files and the agent summarises the top ten by classifier hits, size, and recency, with a note saying so.
The IRM agent, during preview, only analyses SharePoint file content. Alerts built solely on email or device activity are skipped.
None of this is hidden, but the portal does not shout it either. An alert the agent never evaluated still needs a human, so keep a manual sweep of the uncategorised bucket.
The operational details that bite
Agents run as the admin who enabled them, and that authentication expires after 90 days. Put the renewal in the calendar, or the agent quietly stops running.
SCUs are the meter. Agents consume Security Compute Units per alert processed, on top of per-seat licensing for the underlying solution plus pay-as-you-go billing. Monitor consumption in the usage tool from day one, because a noisy DLP policy feeding an agent is a noisy bill.
Permissions split between viewing and managing. Analysts see triaged alerts with their existing IRM or DLP roles; managing the agent itself needs the agent management roles on top.
The sensible rollout: fix the noisiest policies first, because an agent triaging junk alerts is expensive noise sorting. Deploy against new alerts only, check its categorisation against your own for a couple of weeks, then widen the timeframe and trust it with the morning queue.
Tune the policies feeding the alert queue before you pay an agent to sort it.
Plan your IRM policiesPlan this in a tool
Free planners to design and test this before you deploy. No login.