AegisAI Perspectives · 008
A model, with rules kept for hard policy. Payloadless BEC gives a rule little fixed to match; the signals that expose it are relational and linguistic.
A model, with rules kept for hard policy. About 60 percent of 3,000 BEC attacks in one sample carried no link, leaving a rule little fixed to match18. Mailbox intelligence uses AI to learn each user's email patterns with frequent contacts11.
An Exchange Online mail flow rule is built from conditions, exceptions, actions and properties, and its conditions examine header fields or message properties such as subject, body or attachments5. It matches a sender address, a sender domain, an IP range, or an address against a regular expression7. Gmail content rules match words, regular expressions, header or envelope senders, source IP range or attachment types14.
Listed words in a mail flow rule do not support wildcards or partial matches8. An advanced content match in Gmail must be an exact string15. When a rule has several conditions, a message must match all of them6.
Payloadless BEC is built for that gap. It carries no clearly malicious payload and is personalized to the recipient17. IC3 describes BEC as a scam frequently carried out by compromising legitimate business email accounts to get unauthorized transfers of funds4. Researchers writing on arXiv in 2023 found that spam and phishing techniques fall short because tailored BEC blends in with regular benign traffic21. For the wider gateway picture, see why a secure email gateway still misses phishing.
IC3 recorded $3,046,598,558 in BEC losses in 2025, second only to investment fraud among cyber-enabled fraud types1. The figure was $2,770,151,146 in 20242.
Run this on BEC cases you already hold, with no change to mail flow.
Pull every reported BEC message from your incident tickets and user reports. Keep only those with no link and no attachment. In the USENIX Security 2019 sample, that was about 60 percent of attacks.
For every case, record the ten signals in the table below: authentication result, lookalike domain, display name, reply-to, keywords, first contact, payment change, tone, sender pattern, thread history.
Build mail flow rules in Exchange Online, or content compliance rules in Google Workspace, from sender domains, patterns or keyword lists. Remember that every condition in one rule must match.
Record which rule fired on which case. Then reword each case with synonyms and replay again. A keyword list in the USENIX Security 2019 work missed attacks when wording varied slightly20.
Point it at the same mailboxes with verdicts that take no action.
For each method, divide true catches by everything it flagged. Ask for those denominators from any method you test.
Read every benign message each method flagged. Note which signal caused it. A display name with an embedded address is a common benign trigger23.
Run the same cases and the new ones again. Keyword lists drift out of date: the USENIX Security 2019 authors had to update theirs daily.
Keep rules for fixed policy such as blocked domains and attachment types. Give the judgement on intent and relationship to the model.
| Signal | Can a rule read it? | What a model adds |
|---|---|---|
| Sender authentication (SPF, DKIM, DMARC) | Yes, as a pass or fail. A lookalike domain with valid DNS records passes all three10 | Treats a pass as one input, not a verdict |
| Lookalike domain | Only if the domain is listed | Counts how often a name and an address have appeared together in this organization19 |
| Display name | Yes, by pattern or regular expression on the address | Weighs the name against the address history; an embedded address also appears in legitimate mail |
| Reply-to mismatch | Yes, conditions examine header fields | Scores the mismatch with statistics unique to each organization |
| Keywords ("wire", "urgent", "bank") | Yes, exact listed words only, no partial matches | Learns BEC expressions instead of a hard-coded list |
| First contact | No. No mail flow condition counts how often two people have emailed9 | Learns each user's email patterns with frequent contacts |
| Payment detail change | Only through keywords | Reads the request: a trusted sender asking for a payment or transfer13 |
| Tone and urgency | Only through keywords | Reads wording that varies, which a fixed list misses |
| Request out of pattern for this sender | No. Conditions compare manager relationships and directory attributes, not message history | Compares the request with the sender's past mail to this recipient |
| Thread and relationship history | No. The condition list has no history condition | Uses the organization's own sender and recipient statistics |
Illustrative example, figures are fictional. A finance clerk at a 600 person manufacturer receives this message from "Dana Ortiz, Accounts, Northfield Supply" at northfie1d-supply.com, a domain registered nine days earlier with valid DNS authentication records. The reply-to is a different address at the same lookalike domain. The text: "Hi, our bank has moved us to a new account. Please update our remittance details before Friday's run. New details below. Thanks, Dana." No link. No attachment. The clerk has paid Northfield Supply 14 times from northfield-supply.com.
Rule by rule. Authentication: pass, because the lookalike publishes valid records. Sender domain rule: no match, because northfie1d-supply.com is on no list. Impersonation protection: no match, because the supplier was never added. Keyword rule for "wire transfer" or "urgent": no match, because the message says "remittance details" and "Friday's run". Reply-to rule: fires only if someone wrote a condition for that header.
Model signal by signal. First contact: this address has never written to the clerk. Name and address pairing: "Dana Ortiz" has always arrived from northfield-supply.com, never from this domain. Language: a payment change with a deadline, in wording no keyword list holds. A call to the supplier on a number already on file still decides the payment.
Rules match exact strings only. They need constant upkeep: the hard-coded keyword list in the USENIX Security 2019 work was updated by hand every day.
Models learn from history, so they need statistics unique to each organization before they judge well. They raise false positives on benign mail that looks odd, such as services that put a user's address in a display name.
A hijacked real account sends from a legitimate mailbox, with real history and real authentication. A model can still compare the request with the sender's usual email patterns, but a payment control still decides the transfer. Chat generators now write official-sounding CEO emails quickly, and IC3 reported over $30 million in 2025 BEC losses involving AI3. For the payment controls that sit around the inbox, see how to prevent business email compromise. For how a model reads a message step by step, see how AI-powered email security works.
Track three numbers from the replay above.
AI-based detection, with rules kept for policy. Payloadless BEC has no clearly malicious payload and is personalized to the recipient. Rules match fixed strings and headers. A model reads relationship and language signals, such as first contact and an unusual request from a known name.
It is a business email compromise message with no link and no attachment. It asks for a payment, a transfer or data, in the name of a trusted or lookalike sender. About 60 percent of a 3,000 attack sample had no link.
Only exact domain spoofing. A lookalike domain with its own valid DNS records passes all three authentication checks. A hijacked real account passes too, because the mail is genuine. Set DMARC to reject anyway.
Yes. Rules enforce fixed policy instantly: blocked domains, IP ranges, attachment types. Use them for what is known and let the model judge what is new.
Listed words match exactly, with no wildcards or partial matches. A keyword classifier described at USENIX Security 2019 missed attacks on slight wording changes and needed a daily manual update.
