Why do phishing and BEC still require layered controls instead of one AI model?

Why This Matters for Security Teams

Phishing and business email compromise succeed because they rarely depend on a single weak signal. One message may look legitimate at the domain level, but still carry subtle changes in reply chain, invoice language, payment instructions, or link destinations. That is why a single AI model cannot be treated as a complete control. The more reliable pattern is layered detection and response, with email security, identity controls, user reporting, and human review reinforcing one another. NIST Cybersecurity Framework 2.0 helps explain this well: risk reduction depends on coordinated governance, protection, detection, and response, not a single point solution. See the NIST Cybersecurity Framework 2.0 for the broader control model.

Practitioners often underestimate how BEC adapts around whatever control is currently strongest. If the model is good at language analysis, attackers shift to sender infrastructure, account takeover, or payment workflow abuse. If the model is good at link analysis, they use plain-text persuasion and timing pressure instead. In practice, many security teams encounter BEC only after a payment process or mailbox has already been influenced, rather than through intentional layered prevention.

How It Works in Practice

Layered control design works because each control can catch a different phase of the attack chain. Email authentication can reduce spoofing, sandboxing can inspect attachments and URLs, identity controls can flag impossible travel or anomalous mailbox access, and user reporting can surface social engineering that technical filters miss. AI adds value when it scores and correlates signals, but it should not be asked to replace the controls that generate those signals in the first place.

A practical approach usually combines:

• Sender authentication and domain protections to reduce impersonation risk.
• URL and attachment inspection to detect malicious payloads and redirect chains.
• Identity and mailbox telemetry to identify account takeover or abnormal login patterns.
• Business process checks for payment changes, supplier onboarding, and urgent transfer requests.
• AI-assisted triage that prioritises suspicious messages, while preserving analyst context for review.

This is consistent with the detection-and-response emphasis in MITRE ATT&CK, where techniques such as phishing, valid accounts, and email collection are treated as distinct behaviours rather than a single event. For teams building AI-assisted workflows, the guidance from OWASP Top 10 for LLM Applications is also relevant, especially around output trust and prompt manipulation risks when an assistant is used to summarise or classify suspicious mail. These controls tend to break down when organisations route all trust decisions through a single inbox plugin or scoring model because business exceptions and adversary adaptation quickly outpace the model’s visible evidence.

Common Variations and Edge Cases

Tighter layered control often increases operational overhead, requiring organisations to balance faster user experience against stronger verification and review. That tradeoff becomes especially visible in finance, procurement, and executive communications, where legitimate urgency is common and false positives can delay business operations. Best practice is evolving, but current guidance suggests that high-risk workflows should have separate verification paths rather than relying on one model verdict.

There is also no universal standard for this yet in AI-driven email defence. Some organisations use the model only for ranking and summarisation, while others allow it to recommend blocking actions. The safer pattern is to treat AI as decision support, not final authority, unless the surrounding controls are mature and continuously tested. That matters even more where an attacker can combine phishing with session theft, compromised mailboxes, or vendor impersonation. In those environments, the main failure is not model accuracy alone, but weak process controls around payment approval, mailbox delegation, and exception handling.

For governance and operating model design, Zero Trust Architecture reinforces the idea that trust should be continually evaluated across identity, device, and session context. Layered control does not mean more tools for their own sake. It means making sure each tool contributes a distinct signal so the organisation can detect manipulation before a payment is approved or a mailbox compromise becomes a fraud event.

Related resources from NHI Mgmt Group

• Why do AI systems require continuous governance instead of one-time approval?
• How should teams govern AI agent access when downstream systems still require secrets?
• Why do phishing-resistant MFA controls still fail against social engineering?
• Why do AI agents require stronger identity controls than standard applications?