Phishing prevention is more important than phishing triage

Our series on detection architecture argued that the most consequential shift in security is from AI as a classifier to AI as an operator. We need AI security that doesn't just judge the attack in front of it, but one that learns from each attack and updates defenses to prevent similar attacks in the future. The AI-powered phishing tools built to automate triage are the clearest test of that need.

There is an assumption embedded in most of these tools that investigation is the hard part, so they stay focused on lightning fast triage. And while AI phishing tools excel at triage, that is also where most stop. They handle the current attack quickly and efficiently, but do nothing to prevent future attacks.

AI-powered triage has been a game changer in terms of saving SOC analyst hours, but it’s giving a false sense of security and efficiency. It creates a compounding gap where every variant sitting in inboxes is a standing risk, and every re-report is AI or analyst time wasted on an attack the org has already seen. Good AI triage without prevention is like grabbing a bigger bucket to bail out a sinking ship, while new attacks blast more holes in the hull.

Platform gaps create prevention gaps

SOARs and AI-SOC tools are a cornerstone of modern security operations, and the best teams use them to automate enrichment, route alerts, and coordinate response across the stack. What follows is not a critique of those tools. The gap described below is structural: it comes from where these platforms sit relative to the email environment, not from how well they are built.

The current generation of AI-powered phishing investigation tools (AI-SOC platforms, SOAR tools, phishing triage automation, etc.) all work the same way. They receive an email as an artifact after it has been forwarded, flagged, or alerted on. Then they enrich it against external sources like reputation feeds and sandboxes and produce a classification. Finally, they act by quarantining the reported message, blocking the sender, blocklisting the domain or URL, or performing some other automated action.

This is an outside-in approach as the SOAR sits outside of the email environment and reconstructs what happened after the fact. This is excellent for investigation and triage, but is structurally limited for prevention.

Augmenting SOAR with Sublime

Rather than simply passing email threat investigations along to a SOAR, Sublime is built to autonomously handle all the tasks from email threat investigation to email threat prevention. Sublime is able to close novel email attack gaps agentically, while still handing off enriched, contextualized data to a SOAR for use within the broad threat prevention environment.

SOARs are excellent at workflow orchestration, and Sublime is built to work with them. Unlike other email security platforms that share raw artifacts that need enrichment and scope discovery, Sublime sends the SOAR a finished verdict with full structural context, campaign scope, and affected mailboxes already resolved. From there the SOAR does what it does best: open the ticket, notify the user, trigger an endpoint investigation, update a threat intelligence platform.

By resolving the detection and investigation within Sublime itself, we’re accelerating the loop dramatically and refining the outcome so that what Sublime gives to the downstream SOAR and SOC tools are far more distilled and impactful.

The point is not that orchestration is unnecessary, it’s that email intelligence cannot be reconstructed from the outside. It has to be generated inside the email environment, as messages flow. Sublime integrates with SOAR platforms in a way that gives them something no external feed can provide. The detection logic Sublime generates is customizable, version-controlled, and deployable directly into existing workflows. Mature SOAR teams recognize the difference from the static, pre-built integrations other vendors offer.

Let’s take a look at what happens when email investigations are handed off to a SOAR.

Outside-in whack-a-mole

Because a SOAR sits outside the email environment, it runs into visibility issues. When a user reports a phishing email, the tool does not already know which other mailboxes received it. It has to call the Microsoft 365 or Google Workspace API and search, after the fact, for messages matching the reported indicators: the sender address, the sending domain, the URL.

That search only finds what it is looking for, but attackers don’t use one sender address in a campaign. Like masks, they rotate aliases, register fresh lookalike domains, and swap URLs between sends. Any variant that carries different indicators than the reported email gets missed entirely. So even if one is caught, an entire campaign can be spread out across other inboxes.

This makes prevention even harder. When remediation is indicator-based, blocking a sender alias just means the next message arrives from a new one. Each reported email closes one instance of the attack while the underlying technique keeps working. Without preventative controls, the cycle restarts every time a new user reports a new variant.

Email intelligence has to come from inside email

Every message flows through Sublime as it arrives at Microsoft 365 or Google Workspace. Sublime is not an orchestration layer that connects to the email platform and queries it later, it is the security layer that processes every message in line. The investigation happens inside the email environment and is then shared out (inside-out).

Sitting outside-in forces vendor-owned, indicator-based responses that always lag the attack, while inside-out is what lets detections adapt to your environment and close gaps in hours. That single architectural difference changes what’s possible. Sublime starts protecting from day one, and every action it takes traces to detection logic your team can read and tune.

When a user reports a phishing email, Sublime’s AI triage agent – ASA (Autonomous Security Analyst) – begins analysis immediately. ASA is not working from a forwarded copy with stripped headers. It saw the original message when it arrived with full context intact. It returns a verdict in seconds, and escalates any message it can’t classify confidently. Everything else is remediated autonomously, around the clock, whether or not an analyst is online. Security teams choose the posture: full autonomous remediation or analyze-and-alert with a human taking the final action. This is AI-phishing triage and it’s only half the battle.

The first step in closing the whack-a-mole gap is grouping. As messages arrive, Sublime sees through the masks, it automatically clusters them into message groups by structural similarity, subject and body patterns, attachments, and sender behavior, not an exact match on a single indicator. So when a user reports one phishing email, Sublime already knows every similar message across every mailbox, with no after-the-fact API call and no scope-discovery delay. ASA remediates the whole group in one operation, sweeping every variant of the campaign from every inbox, including the ones that rotated their indicators. This isn’t simple filtering that can be easily evaded.

Security teams that move to this model report real reductions in analyst time. For example, Personio now auto-remediates 95% of user-reported emails through ASA.

Stopping the next attack, not just this one

Triage and group remediation handle the attack in front of you. Prevention means the next variant never reaches an inbox in the first place. We have an AI agent for that too: ADÉ, the Autonomous Detection Engineer.

When Sublime encounters a new or evolving attack pattern, ADÉ analyzes the structural characteristics of the messages and generates new detections from them, typically within 30 minutes to a couple of hours. These detections are written in logic purpose-built for email, expressing why a message is malicious from its header anomalies, HTML structure, and lookalike-domain behavior, not just the specific sender or URL that happened to appear this time.

That distinction changes everything. A blocklist stops one attack, whereas a detection prevents any attack with similar threat signals. Even if the attacker rotates the sender, the domain, and the URL, if the underlying technique remains the same, the detection will still prevent the next variant before a user ever has to report it. Across customers this compounds: Elastic now detects 20x more email attacks, and in a single quarter Snyk auto-remediated 40,000 emails across more than 1,000 mailboxes.

An ounce of prevention is worth a pound of triage

When evaluating an AI phishing tool, look past the triage demo and ask what determines whether the program scales: after this email is handled, what stops the next one? If the answer is another blocklist entry and another user report, you have faster cleanup, not fewer attacks. The teams that get ahead turn every reported phish into a durable detection that closes the door behind it. That is the difference between investigation and prevention.

Ready to see the full loop in action, from user report to full-campaign remediation to autonomous detection, in your own environment? Book a live demo.