Phishing triage

Triage of an email someone reported as phishing: your mail pipeline makes the sender a subject with the scan, DMARC and reputation results, events count how often the sender is reported, and uncertain messages go to a security analyst. Pack: examples/policies/phishing-triage/.

A pattern for expressing a email & messaging policy, not compliance guidance: the thresholds, lists and fields are placeholders chosen to make the example run; a real policy comes from the business's own rules. It calls no app, so it runs in an empty workspace as it is.

The decision it automates

Whether to release the message (approve), send it to an analyst, or quarantine it (reject), when your mail pipeline starts the run.

Data expected

• The sender as a subject (kind user) with email, reputation and lastMessage (dmarc, linkScanMalicious), written by your mail pipeline before it starts the run.
• message.reported events carrying the sender's address in the promoted email key, posted through POST /events.

Steps and rules

Step	Type	Why
rules	evaluate_rules	The phishing-triage rule set under max_severity; nothing is collected.
route	branch	rules.outcome == manual_review opens a case.
review	create_case	security_triage, priority high, 30-minute SLA; case.sla.breached can page the on-call analyst.
decide	emit_decision	From the rules, or the reviewer's decision.

The rule set phishing-triage (useCase: monitoring) uses max_severity: a failed block rule rejects, a failed warn rule sends the run to review, and the weights add up to the score.

Rule	Type	Severity, weight	Fails when
phish_links_clean	comparison	block, 100	lastMessage.linkScanMalicious is not false
phish_authentication	comparison	warn, 30	lastMessage.dmarc is fail
phish_sender_reputation	score threshold	warn, 30	reputation is below 40
phish_report_burst	velocity	warn, 20	more than five message.reported events for the sender's address in 24 hours

What a reviewer sees

A security_triage case with the rule results and the sender's timeline of reports. The analyst's reject quarantines; decision.created tells your mail gateway to purge the message.

How to adapt it

Call your link scanner, reputation service and mail API from the workflow as apps you build instead of writing their answers on the subject, and add a call_app step after the decision that purges the message from every inbox.

Run it

pnpm policy:import examples/policies/phishing-triage --publish

The fixture reports a message that failed DMARC from a sender with a reputation of 35, reported twice: the authentication and reputation rules fail, a security_triage case opens, the check quarantines it (reject) and the run completes with a manual reject.