TL;DR: Phishing triage becomes campaign detection when an agent uses mail evidence to hunt for technique across the inbox, then drafts a detection rule from that same query so the response can cover mail nobody flagged, according to Tracecat. Query-driven hunts shift the decisive control from message review to method-based validation.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Tracecat's blog post: Agentic phishing triage uses one workflow to scope campaigns, hunt across mailboxes and draft a detection rule from the same evidence.
Why it matters: This matters because phishing response now depends on whether teams can turn mail evidence into repeatable hunt logic and governed detections, not just triage individual messages.
Context
Phishing response is a governance problem as much as an investigation problem. The first decision is whether a message is a real attempt, but the harder work is proving whether the same technique is still circulating elsewhere and whether the detection stack would already catch it.
When an agent writes the hunt query and the candidate detection, the team is no longer just reviewing messages. It is governing how evidence becomes automation, which makes control over query scope, approval and write access the real boundary around phishing response.
Key questions
Q: How do I hunt phishing campaigns across mailboxes?
A: Use the first confirmed message to derive the attacker method, then run a query across the full retention window for mail that matches that technique. Search for behaviour such as lure structure, link patterns, reply-to mismatch and sender change, because those survive infrastructure changes better than a single address or subject line.
Q: Why do phishing detections miss copied messages?
A: Phishing detections miss copied messages when they rely on exact text matches, sender reputation, or known URLs, because attackers often reuse the same lure with a new domain, attachment, or account. Good detections combine header analysis, URL rewriting or detonation, attachment sandboxing, and similarity scoring across copied content, while also checking newly registered senders and impersonated identities.
Q: What is the difference between a phishing triage case and a hunt?
A: A phishing triage case is the handling of a specific suspected message or user report, where an analyst validates indicators, scopes impact, and decides containment. A hunt is proactive searching across mail, logs, and endpoints for similar activity or overlooked indicators, even without a fresh alert. Triage is incident-specific, while hunting is hypothesis-driven and broader.
Q: How should teams approve agent-written detection rules?
A: Teams should approve agent-written detection rules through the same change control used for human-authored rules, with peer review, test data, rollback, and clear ownership before production use. The review should check logic, false-positive risk, required data sources, and whether the rule is aligned to the intended threat model for agent-written detections, rather than accepting code automatically because an agent generated it.
Technical breakdown
Method-based hunting across the full retention window
A campaign hunt is not the same as searching for one sender or subject line. The useful unit is the attacker method, which may show up through link shape, reply-to mismatch, sender reputation drift or a lure pattern that survives changes in infrastructure. Querying the full retention window lets the defender find copies that never hit the alert queue. In practice, the hunt has to describe the attack behaviour, not the individual indicators that were already visible in the first case. See the Threat Hunting Guide.
Practical implication: Build hunt logic around technique descriptions that survive sender and subject changes, not on a single observed message.
Why an agent can draft a rule but should not deploy it
Detection engineering and deployment are different controls. An agent can read existing detections, propose a candidate rule, test it against mail and write the result into a case. But once that same path can enable the rule, the system has crossed from analysis into production change. The safe pattern is to let the agent produce evidence, keep approval outside the agent, and make the activation step explicit and reviewable.
Practical implication: Separate rule authoring from rule activation so the agent can assist with detection without owning production changes.
Why triage, hunt and detection should share one evidence model
The strongest pattern here is not the agent itself, but the shared case record. Triage writes the verdict and evidence, the hunt appends results, and the detection step reuses the same artefacts to build a candidate rule. That reduces drift between what was seen, what was searched and what was blocked. It also makes the workflow auditable, because each step can be checked against the same evidence trail instead of a series of summaries.
Practical implication: Keep triage, hunt output and rule proposals in one governed case record so evidence does not diverge across tools.
Threat narrative
Attacker objective: The attacker wants a lure that keeps landing in mailboxes without being caught by the initial alert, so the campaign can continue after the first message is triaged.
- Entry starts with a phishing message that reaches the mailbox and is triaged through headers, authentication results, link destination and domain age.
- Credential or lure abuse follows when the attacker uses the same technique across other mailboxes, changing sender details while keeping the lure method intact.
- Escalation occurs when the workflow searches beyond the alert queue and identifies unflagged copies that show the campaign is broader than the first message.
- Impact is the operational decision to turn the hunt into a detection rule so future copies can be surfaced before a human manually reviews them.
Breaches seen in the wild
- Mailchimp breach 2022: Attackers socially engineered Mailchimp staff, used a support tool to export 102 customer lists and exposed customer API keys for phishing.
- EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Campaign-level phishing response is now a control problem, not a queue problem. The important decision is no longer only whether one email is malicious. It is whether the organisation can turn that verdict into a hunt and a detection that covers the next delivery of the same method. That shifts the governance burden from message review to evidence handling, query quality and approval boundaries.
Agentic triage works only when the agent is constrained to evidence production. The workflow can let a model derive queries, draft detections and assemble case context, but deployment and destructive action must stay outside its authority. Otherwise the organisation confuses summarisation with control, and a plausible answer can become an unsafe action.
Method-based phishing detection is a named concept worth keeping. The post shows a pattern where the defender searches for the attacker technique rather than the sender identity or the first flagged message. That matters because infrastructure changes are cheap for the attacker, while the underlying lure method is harder to change. The practitioner implication is to make technique the unit of search and response.
Shared evidence pipelines reduce drift between triage and detection. When the case, the hunt and the rule proposal all reference the same parsed mail evidence, the organisation has a much better chance of keeping verdicts, searches and blocks aligned. That is especially important when an agent is involved, because any mismatch between those steps becomes harder to spot.
Mailbox-level hunting exposes the gap between alert coverage and actual exposure. A reported or flagged email is only the floor. If the same campaign reached mailboxes without triggering rules, the governance gap is in search scope and detection design, not in the quality of one analyst's verdict. Practitioners should treat unseen copies as the real measure of response quality.
From our research library:
- Roughly 1 in 3 phishing payloads are delivered outside email, through channels such as social media, search ads and messaging apps.
What this signals
Method-based phishing hunting is likely to become the more durable response model because sender identity and subject lines are trivial to vary, while the underlying lure pattern is not. That pushes teams toward query discipline, evidence quality and reviewable automation rather than alert-only handling.
Agent-written detections need to be governed as change, not just as output. Once an automation can transform a hunt into an executable rule, the approval boundary becomes the control that keeps response useful without letting a plausible but wrong query alter production behaviour.
Mailbox response will increasingly depend on whether teams can prove the negative: which copies were not found by rules but were recovered by search. That makes alert coverage, retention scope and approval workflow part of the same operating model.
For practitioners
- Constrain agent output to proposed evidence Let the agent draft hunt queries, case notes and detection candidates, but require a human to approve anything that changes mail handling or enables a rule.
- Search for technique, not just indicators Write hunt logic around the lure method, then test it against the full retention window so unflagged copies surface even when the sender or subject changes.
- Separate detection authoring from activation Keep detection proposals in a reviewable queue until a named approver validates the tests and deliberately enables the rule.
- Preserve one case record for verdict and hunt evidence Store the triage outcome, hunt results and proposed detection together so responders can compare what was seen, what was searched and what was blocked.
- Measure the unflagged copies, not just the flagged ones Track how many mailbox matches were found outside the alert queue, because that number shows whether the detection stack actually covered the campaign.
Key takeaways
- Phishing triage is only the first step; the real control question is whether the same attack method can be found elsewhere in the mailbox estate.
- The workflow described here turns evidence into a hunt query and then into a rule candidate, which means response quality depends on query design and approval discipline.
- Teams should separate agent-assisted analysis from deployment, because a convincing detection proposal is not the same thing as a safe production change.
Related NHI Mgmt Group resources: Threat Hunting Guide · AI Coding Agents Security Guide · Shadow AI and AI Agent Discovery Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0001; TA0006; TA0007; TA0010 — Initial Access; Credential Access; Discovery; Exfiltration | Phishing campaigns use initial access, credential-focused lure behaviour and mailbox discovery patterns. |
| Recommendation — Map campaign logic to ATT&CK tactics so hunts and detections track attacker behaviour, not just one indicator. | ||
| NIST CSF 2.0 | DE.AE-02 — Automated Detection and Analysis | Agent-assisted phishing response depends on turning evidence into repeatable detection and analysis. |
| Recommendation — Use DE.AE-02 to validate that detections and hunts are based on observable attack behaviour. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Phishing triage relies on mailbox, directory and delivery evidence that must be retained and queryable. |
| Recommendation — Centralise and retain mail, directory and delivery logs so phishing hunts can be repeated and audited. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The workflow's safety depends on keeping agent permissions and deployment paths narrowly configured. |
| Recommendation — Restrict automation privileges so agent output cannot directly alter production mail controls. | ||
Key terms
- Phishing Campaign: A controlled simulation that sends deceptive messages to employees to measure whether they click, respond, or report suspicious content. It is used to assess real-world susceptibility to social engineering and to identify where awareness training needs reinforcement or more realistic scenarios.
- Mailbox Retention Window: A mailbox retention window is the period during which email messages remain preserved before deletion, purge, or archiving policies take effect. It is set by retention rules or legal hold controls and determines how long mail stays available for search, recovery, investigation, and compliance.
- Threat Hunting: Threat hunting is the proactive search for signs of compromise that bypassed normal detection controls. It combines logs, telemetry, and investigator judgement to find hidden attacker behaviour before it becomes a larger incident or disrupts recovery.
- Detection Rule: A repeatable security condition that turns a hunt result into automated alerting or response. It usually codifies a pattern, threshold, or combination of signals so analysts do not have to rediscover the same behaviour manually each time.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity and secrets management. It helps practitioners connect identity controls to the broader security workflows their programmes depend on.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org