Why does AI make fraud and BEC harder to stop?

Why This Matters for Security Teams

AI changes fraud and business email compromise because the old detection cues are getting weaker. Grammar mistakes, awkward phrasing, and generic templates used to expose many scams early. Now attackers can generate polished lures, imitate executives, and tailor timing, tone, and business context at scale. That makes message inspection necessary but no longer sufficient.

The real issue is that fraud workflows increasingly begin with trusted-looking interaction, then move into identity, payment, and approval steps that appear routine. Security teams need to treat this as an identity and transaction integrity problem, not only a phishing problem. That is consistent with the NIST Cybersecurity Framework 2.0 focus on governance, detection, and response across the full attack path. NHIMG research on the State of Secrets in AppSec also shows how security teams are already dealing with scale, fragmentation, and delayed remediation in adjacent identity-heavy workflows.

In practice, many security teams encounter fraud only after a payment, credential handoff, or vendor change has already been approved, rather than through intentional detection of the request chain.

How It Works in Practice

Defenders should assume the attacker is optimising for plausibility, not just volume. AI helps create messages that reference real vendors, current projects, organisational structure, and even prior conversational style. That means security controls have to inspect more than content. They need identity context, device and session signals, transaction history, and out-of-band verification before any high-risk action is completed.

A practical control model usually combines four layers:

• Verify the requestor’s identity context, including mailbox integrity, account age, login source, and recent behaviour.
• Check for abnormal request patterns such as urgent payment changes, new bank details, or unusual approval paths.
• Require secondary confirmation for sensitive actions, especially finance, payroll, and vendor master changes.
• Use transaction validation that compares the request against prior business relationships and known baselines.

That approach aligns with the NIST Cybersecurity Framework 2.0 emphasis on protective and detective controls across business processes, not just email gateways. It also fits NHIMG’s guidance in DeepSeek breach, where exposure of sensitive material demonstrates how fast AI-enabled abuse can compound once trusted data or identities are compromised. Current guidance suggests moving verification into the approval workflow itself, rather than relying on a warning banner or a single mailbox rule.

These controls tend to break down in fast-moving, decentralised finance environments because approved exceptions and informal escalation paths can outrun the verification process.

Common Variations and Edge Cases

Tighter verification often increases friction, requiring organisations to balance fraud resistance against business speed. That tradeoff is especially visible in executive requests, M&A activity, payroll exceptions, and supplier onboarding, where teams may be tempted to bypass controls to avoid delay. Best practice is evolving, and there is no universal standard for the right approval threshold yet.

Some attacks are not classic BEC at all. Attackers may use AI-generated voice, cloned writing style, or synthetic meeting follow-up to validate a false request across channels. Others exploit compromised internal accounts rather than external spoofing, which makes the message look legitimate even when the intent is malicious. In those cases, content filters alone provide limited value. Organisations should combine alerting with account behaviour monitoring, payment hold rules, and step-up verification for any change that moves money or data.

Fraud controls also need different handling in high-trust environments such as legal, procurement, and senior leadership. A rigid rule set can create workarounds, but a purely manual process creates blind spots. The better pattern is risk-based validation, with stricter checks for first-time payees, banking changes, and urgent requests outside normal hours. Guidance from NIST Cybersecurity Framework 2.0 supports that layered approach, while NHIMG research on the State of Secrets in AppSec reinforces how organisational friction and fragmented controls can leave critical processes exposed.

Related resources from NHI Mgmt Group

• Why do agentic AI systems make fraud harder to stop with static rules?
• Why do generative AI tools make document fraud harder to stop?
• Why do AI-powered bots make identity-based fraud harder to stop?
• Why do AI deepfakes and voice cloning make fraud harder to stop?