AI-Assisted Spear Phishing Is Now Available to Everyone

The email came from the CFO. It referenced a specific acquisition the company was working on. It addressed the treasury analyst by name and asked for a wire transfer to an account set up last week for the deal. The grammar was clean. The pretext was plausible. The CFO's name was right, the project name was right, and the timeline was consistent with what the analyst knew.

The CFO had not sent the email.

This attack did not require a skilled social engineer with weeks of research. It required an LLM, a few minutes of OSINT from LinkedIn and the company's recent press releases, and someone willing to run it.

What Actually Changed

Spear phishing has been a meaningful threat for years. What made it expensive was the research burden. A convincing, personalized attack required time on the target's public profiles, enough familiarity with their organization to get names and projects right, and the ability to write something that matched the target's communication context. That constraint kept volume low and made high-quality attacks rare.

LLMs removed both bottlenecks simultaneously.

The research step can now be automated. Give a model a target name and company, tell it to summarize publicly available information about their role, colleagues, recent announcements, and likely concerns, and it produces a dossier in seconds. The writing step is what LLMs do. A model given that dossier and a social engineering objective generates a convincing email faster than a human reader can assess it.

A single operator with basic tooling can now produce hundreds of individually personalized, contextually accurate spear phishing emails per day. That is not a marginal improvement over prior capability. It is a different threat model.

What Personalization Looks Like Now

The classic phishing tells were linguistic: awkward phrasing, odd formatting, mismatched formality. These were useful heuristics because most phishing was written by non-native speakers working quickly or processed through automated tools that introduced characteristic errors.

LLM-generated phishing has none of those properties. The writing is fluent. The tone matches the sender's expected style. The email references things that are actually true about the target's work environment: their manager's name, a project in progress, a public announcement from the prior week. It asks for something plausible from someone in a position to make that kind of request.

There is no broken grammar to catch. There is no request that is conspicuously out of character. The attack passes casual inspection because it was built to pass casual inspection.

The Volume Problem

Security awareness training implicitly assumes that personalized, convincing attacks are resource-intensive and therefore rare. Training programs help people detect the bulk, low-quality phishing that most organizations see most of the time. When the signal-to-noise ratio is high, asking users to develop judgment about suspicious characteristics makes sense.

When the volume of convincing attacks increases by an order of magnitude, that model breaks. Users cannot reliably distinguish an AI-generated email that references their real manager and their real project from a legitimate communication. The attack surface for user error scales with attack volume, and volume just scaled significantly upward.

Why Traditional Defenses Are Struggling

Email security infrastructure catches a lot. SPF, DKIM, and DMARC block spoofed domains. Content filters catch known malicious links and attachments. Reputation systems flag senders with no history. These controls are worth keeping and are not obsolete.

They were not designed to detect a well-written email sent from a legitimate-looking domain about a real topic. Content-based filtering looks for patterns associated with malicious intent. A personalized, accurate, grammatically correct email from a domain registered last week has few of those patterns.

The gap is specific: high-quality, low-volume, personalized attacks that are accurate enough to pass user judgment and clean enough to pass content filters have always been hard to stop at the email layer. What changed is that they are no longer rare enough to treat as exceptional cases.

What Actually Works

The defenses that hold up under this threat model operate at the process level rather than the "identify the bad email" level.

Any high-stakes action - fund transfers, credential changes, new vendor payments, access provisioning, data exports - should require verification through a channel separate from the one that initiated the request. If a manager emails asking for a wire transfer, the verification call happens over a known phone number, not in reply to the email that requested it. This control is not elegant. It is also reliable in a way that "does this email seem suspicious" is not.

Privileged actions should require out-of-band approval regardless of who appears to be asking. The action itself is what matters, not the apparent legitimacy of the requester. When approval processes are structured around the assumption that sophisticated requests may be AI-generated impersonations, the verification step becomes routine rather than exceptional.

Investing in post-compromise detection matters more when the initial phishing vector becomes harder to catch. If an attacker tricks someone into providing credentials through a convincing pretext, the next detection opportunity is anomalous account behavior. Monitoring for unusual access patterns, logins from unexpected locations, and out-of-character data access is the backstop when the phishing prevention layer has a gap.

What Does Not Work Anymore

Training people to look for poor grammar is now largely unhelpful against AI-generated attacks. Training people to recognize AI-generated text is even less reliable, and it is getting less reliable as models improve.

The "think before you click" advice is not wrong. It is insufficient when the email is convincing enough that careful thought produces the wrong answer. The meaningful organizational protection is not in sharpening user judgment. It is in designing processes where even a deceived user cannot take a high-consequence action unilaterally.

The threat is familiar: account compromise, fraud, data theft, ransomware foothold. The economics changed. The countermeasures that need to change are the ones that assumed the attack would be detectable. The ones that remain effective are the ones that assumed it would not be.