Security strategy

Twenty-Two Articles, Four Themes: What a Year of Writing About AI and Email Security Taught Me

CEO Alan LeFort maps a year of writing on AI email threats into four themes — and why detection has to reason, not match patterns.

Alan LeFort CEO · · 12 min read

Cover illustration for “Twenty-Two Articles, Four Themes: What a Year of Writing About AI and Email Security Taught Me”

I write these one at a time, usually on deadline, reacting to something in the news cycle or a conversation with a customer. There's no editorial calendar behind them, no plan. So when I sat down to reread the whole year at once — twenty-two bylines, six outlets — I wasn't looking for a pattern. I was looking for repetition, the kind of thing a good editor cuts before it reaches print.

What I found instead was four arguments wearing twenty-two different outfits. Same underlying claim, different headline, different outlet, different metaphor to carry it. Once I saw the four, I couldn't unsee them in any of the pieces — including the ones I'd have told you, a week earlier, were about something else entirely.

I don't say that as false modesty about the writing. Publishing in public on a deadline is a decent forcing function for finding out what you actually believe, as opposed to what sounds right in a meeting. A few of these pieces started as an argument I was fairly sure of and ended somewhere I hadn't expected, because a reader's pushback in the comments put a hole in the logic I hadn't noticed while drafting.

The twenty-two ran across SC Media, Security Boulevard, CSO Online, CIO.com, TechRadar Pro, and ComputerWeekly, and if you've been reading along you've probably felt the drumbeat without being able to name it. This post names it.

One more thing before the map. A year ago, if you'd asked me which of the four mattered most, I'd have told you without hesitation: the human layer. I've changed my mind, and I've put the explanation at the end rather than the top, because it only makes sense once you've seen all four.

Here's the map. If you're new here, it's the shortest route through the whole body of work. If you've been reading along, it's the version with the repetition taken out and the connective tissue put in. I'll keep it current as new pieces publish.

1. The Human Layer We should be Protecting is the Security Team.

For twenty years the industry told employees they were the last line of defense. I ran one of the largest security awareness businesses in the world, so I say this carefully: that framing was always more comfortable than it was true. Employees were an easy story — train the humans, measure the click rate, show the trend line going down at the board meeting. It was never the honest story.

The honest story is that the people with the tools, the training, and the actual mandate to defend the organization are the analysts sitting in the SOC, and most of them spend the bulk of a shift clearing alerts that were never threats. Ask any security leader what their team's real bottleneck is, and ‘we need smarter employees’ is rarely the answer. It's alert fatigue. It's a queue that never empties. It's good people burning out on triage work that a machine should have resolved before it ever reached a human inbox.

When AI started stripping the visible red flags out of phishing — the broken grammar, the mismatched sender name, the too-good-to-be-true offer — asking employees to catch what the gateway missed stopped being a reasonable layer of defense and became a hope dressed up as a policy. You cannot train a workforce to spot what a native-sounding, contextually accurate, personally addressed email simply doesn't show them. That's not a training gap. That's asking humans to do a machine's job by hand.

So the useful question for a security leader isn't how much more awareness training to buy this year. It's how much of your analysts' capacity is being consumed by work that doesn't actually reduce risk — and what you'd get back, in coverage and in retention, if that work stopped landing in their queue at all. Training still matters. It's just not the layer that's been quietly carrying all the weight.

None of this is an argument for eliminating security awareness programs. It's an argument for being honest about which tier of defense they belong to — a supporting layer, not the last line — and shifting budget and credit toward the systems that should be carrying the load before a message ever reaches a human being asked to judge it.

2. AI did not make attackers smarter. It removed the need to be.

Every mature craft has a barrier to entry: the years it takes to get good enough to do real damage. Watchmaking has one. So did London's cab drivers, who spent four years memorizing The Knowledge before satellite navigation made the whole apprenticeship optional. Offensive tradecraft had a barrier too, and for a long time it did real defensive work on our behalf. It kept most people who wanted to run a scam stuck at the amateur level, producing amateur output — broken English, obvious tells, low-effort targeting anyone paying attention could spot.

AI collapsed that barrier in a single model release. Fluent, context-aware writing in any language is now free. Researching a target's role, their vendors, their recent public statements, their actual writing style, is now a matter of minutes instead of weeks. None of the individual skills that used to separate a nation-state operation from a smash-and-grab scam are scarce anymore. They're default settings.

The consequence for defenders isn't that attacks became cleverer in some abstract sense. It's that nation-state quality became the floor rather than the ceiling — available at nation-state volume, at commodity prices, to anyone willing to type a prompt. That's not a skills story. It's an economics story, and it changes the math on the defensive side too: every dollar spent training people to spot the old ‘tells’ is a dollar defending against a version of the attack that's already extinct.

For a defender, this means the budget conversation built around ‘sophisticated, targeted attack’ as a rare, escalation-worthy event needs updating. Targeted-quality attacks are no longer rare. Increasingly, they're the default inbound traffic, and planning for anything less just gets more expensive to unwind later.

Which raises the obvious next question: if the attacker side of the equation just had its cost structure rewritten, what happens to a detection model that was built assuming attacks would keep arriving in recognizable, repeatable shapes? That's where the next theme starts.

3. Detection has to reason, because pattern matching arrives too late.

Most detection still works by comparing a message to things seen before: a signature, a sender's reputation, a statistical baseline of what ‘normal’ looks like for this mailbox. Every one of those is a form of memory. And memory fails exactly when the attacker controls what counts as new — which, per the last theme, is now the default case rather than the edge case.

A confidence score is a poll, and polls carry a margin of error that widens the moment the population being polled learns to lie convincingly. Anomaly detection fails the instant the malicious message stops looking anomalous — and a model trained to write like your CFO doesn't look anomalous to a system that's only ever learned to flag what looks unlike your CFO. Reputation scoring fails the moment a compromised, previously trustworthy account starts sending the attack, because the sender's reputation was never what made the request legitimate in the first place.

And correlating a stolen session inside the SIEM, after the login has already happened and the forwarding rule is already set, isn't detection in any meaningful sense. It's an autopsy. Useful for the incident report. Useless for the person whose credentials are already gone.

The alternative is to reason rather than match: to know the actual facts about who's writing, how you genuinely transact with them, what this specific request would mean if it were real, and what it would cost if it weren't — and to make that call before delivery, not after. That's a fundamentally different kind of system than one built to notice when something looks unfamiliar. It has to understand a relationship and a request on their merits, the way a sharp, well-briefed analyst would if they had unlimited time for every single email. Nobody has unlimited analyst time. That's precisely why this has to be automated rather than aspired to.

Picture the ordinary version of this problem: an email arrives from a vendor you've paid for two years, asking you to update the bank details on file before Friday's invoice run. Nothing about the message trips a signature. The sender address is close enough — maybe even exactly right, if the vendor's own account is the one that got compromised. A pattern-matching system has nothing to flag, because nothing about the pattern is new. A reasoning system asks a different question: does this vendor typically change banking details by email, does this specific request match how the relationship has actually worked for two years, and what does it cost the business if this one request is wrong. That's a judgment call, not a lookup, and it's exactly the kind of call pattern matching was never built to make.

This is also the theme the other three keep pointing back to. The alert queue burning out analysts in the first theme exists because detection is generating noise instead of judgment. The flood of nation-state-grade attacks in the second theme is only a crisis because nothing downstream of the inbox can reason its way through the resulting volume. Fix this, and the pressure on the other two eases considerably. I'll come back to that at the end.

4. The Trust You Grant by hand is Undoing the Trust you Built by Design.

This is the least glamorous of the four, and it's the one with the fastest payoff if you fix it. Organizations spend real budget on a zero-trust architecture and then, one exception at a time, hand out allow-list entries to exactly the senders attackers impersonate most: the CFO, the payroll processor, the law firm on retainer, the vendor everyone already trusts.

Nobody sits down and designs it this way on purpose. It happens one escalation at a time — a senior executive gets flagged by mistake, complains, and IT adds a rule to make the complaint stop. Repeat that a few dozen times across a few years, and the exception list quietly becomes a directory of exactly who's worth impersonating, maintained by the very people trying to keep attackers out.

The same habit shows up one layer up, in how AI security vendors get evaluated. Most bake-offs run on a curated demo: a handful of obviously malicious samples, a handful of obviously clean ones, and a scorecard. That's a test designed to be passed, not a test designed to find the edge. The more useful question isn't whether a vendor caught the obvious attack in the demo. It's what happens on the ambiguous case — the one that could plausibly be legitimate, the one an allow-list exception would have waved straight through, the one that looks exactly like the messages theme three is trying to reason about instead of match.

Trust should be a decision the architecture makes on evidence, case by case, not a favor granted once to make an escalation go away and then quietly left in place forever.

Fixing this doesn't require a new tool. It requires an uncomfortable audit: pull the exception list, ask who approved each entry and why, and ask whether the reason still holds today. Most organizations that run this exercise are surprised by what they find still sitting on it.

If you'd rather Listen

The Cloudcast, Frontlines.io and TechStrong.tv each cover a slice of the four, if audio is more your speed than text.

Which One I'd Lead with Today

A year ago, if you'd asked me to rank these four, I'd have put the human layer first without much thought. It's the theme I had the most direct experience with, coming out of running a security awareness business, and it's the one that gets the fastest nod of recognition from a room full of CISOs. Today I'd lead with the third: detection has to reason.

Not because the human layer stopped mattering. Because it turned out to be downstream of the third, along with the other two. Analysts are overloaded (theme one) largely because detection generates noise instead of judgment. Amateur attackers reaching nation-state quality (theme two) is only an emergency because nothing between the inbox and the analyst can reason its way through the resulting volume. And trust gets granted by hand, one exception at a time (theme four), precisely because the system isn't making that judgment call on its own — so a human has to, manually, under time pressure, without the full picture. Solve the reasoning problem at the center, and the pressure on the other three eases considerably. Leave it unsolved, and no amount of training, threat intel, or policy discipline fully compensates.

That's the order I'd write these in if I were starting from scratch today. It's also, not coincidentally, the order I'd recommend a security leader use to prioritize a review of their own stack.

It's a testable claim, if you want to test it: look at where your last several genuinely damaging near-misses actually originated, and ask which of the four themes each one traces back to. In my own conversations with CISOs this year, the third comes up disproportionately often once you get past the first, easier answer.

The Obvious Disclosure

I run a company that sells reasoning-based detection, so you're entitled to read everything above with that firmly in view. I'd rather say it plainly than have you find it a paragraph into my About page. What I'd ask is that you check the argument against the twenty-two individual pieces rather than against my job title. Most of them were written for outlets I don't own, edited by people who don't work for me, and several make points a self-interested vendor post never would — including the admission, a few sections up, that training a workforce is not, by itself, a worthless idea. Judge the reasoning, not the business model sitting behind it.

Final Thoughts: Where This Goes Next

Over the coming weeks I'll take each of the four themes and go deeper on its own. I'm starting with the human layer, even though I've just argued it isn't the lead theme anymore, because October is Cybersecurity Awareness Month and it's the right moment to say plainly what training can and cannot be reasonably asked to do — and what should replace the parts it can't carry.

After that I'll spend real time on the third theme, since that's where I now think the actual leverage is, and I'll go back to a few of the individual pieces and do something writers rarely do in public: ask whether they held up, and say clearly where I'd argue them differently with what I know now. I've learned more from the people who pushed back on these pieces than from the people who agreed with them.

FAQ

What are the four themes Alan LeFort identified after reviewing his 22 articles?

Alan identifies four recurring arguments: the human layer should focus on protecting security teams, AI has lowered the barrier for attackers, detection needs to reason rather than rely on pattern matching, and manually granted trust can undermine zero-trust architecture.

Why does Alan argue that the security team, rather than employees, is the human layer that needs more protection?

Alan argues that employees have traditionally been treated as the “last line of defense,” while security analysts are left handling large volumes of alerts and repetitive triage work.

How has AI changed the economics of phishing and cyberattacks?

Alan's argument is that AI has reduced the skill and time required to produce convincing, context-aware attacks. Researching a target, producing fluent communications and tailoring an attack no longer require the same level of specialist expertise, lowering the barrier to entry for attackers.

Why does Alan believe traditional pattern matching is becoming less effective?

Pattern-based systems typically rely on signatures, sender reputation or what previously looked unusual. Alan argues that these approaches struggle when attackers produce messages that closely resemble legitimate communication or use trusted accounts and infrastructure. He therefore advocates systems that evaluate the relationship, request, context and potential consequence of a message rather than simply asking whether it resembles something seen before.

What does Alan mean by “detection has to reason”?

He means that email security should evaluate whether a specific request makes sense in its real context. In his vendor-payment example, the important question isn't simply whether the message looks unusual; it is whether the request matches the established relationship and whether the consequences of getting the decision wrong justify intervention.

More from the blog

  • Email Security
← All posts
Free AI gap check

Do you have an AI gap? Find out what’s getting through.

See which generations of defense you’re running and what it takes to close the gap. Two minutes. No signup. Nothing changes in your environment.

Book a demo Find my AI gap →