The Email May Be Real – The Request May Not Be.

Why Communication Is Not Authorization in the Age of AI Impersonation

Suppose an email arrives from your CFO.

The email address is correct.

The writing sounds right.

The signature is right.

It continues an existing conversation.

There is no suspicious link. No strange attachment. No obvious spelling mistake.

It may even have come from the CFO’s real account.

The message says:

“We changed the vendor’s banking information. Please send today’s payment to the new account.”

Would you send the money?

This is where much of traditional security awareness starts asking the wrong question.

We teach people to ask:

Is this email real?

A more important question is:

Is this action authorized?

Those are not the same thing.

A Real Account Can Carry a Fraudulent Request

Business Email Compromise, or BEC, is one of the most financially damaging forms of online fraud.

The FBI describes BEC as frequently involving criminals compromising legitimate business or personal email accounts and using them to conduct unauthorized transfers. Between October 2013 and December 2023, the FBI recorded 305,033 domestic and international incidents with approximately $55.5 billion in exposed losses.

This matters because once a legitimate mailbox is compromised, many familiar warning signs disappear.

The attacker may know:

• who normally communicates with whom;
• current projects;
• invoice amounts;
• vendor names;
• payment schedules;
• writing styles;
• organizational relationships;
• previous email conversations.

The FBI specifically notes that attackers can gain access to legitimate email threads involving billing and invoices and use that information to time fraudulent requests.

Generative AI makes the human-recognition problem harder still.

The FBI has warned that criminals use generative AI to improve fraudulent text, reduce grammatical and spelling mistakes, clone voices, generate realistic images, and create video for real-time conversations involving supposed executives or other authority figures.

So perhaps the long-term security strategy cannot depend primarily on employees becoming increasingly talented human deepfake detectors.

Microsoft Provides an Interesting Example of the Trust Problem

Microsoft Defender for Office 365 includes sophisticated anti-phishing and impersonation protections.

One of those mechanisms, mailbox intelligence, uses AI to learn users’ normal email relationships and frequent contacts.

Microsoft’s current documentation contains an important qualification: when mailbox intelligence and intelligence for impersonation protection are enabled, certain user and domain impersonation protections do not operate in the same way when the sender and recipient have previously communicated. Mailbox-intelligence impersonation protection itself also does not identify the sender as an impersonation attempt when the two parties have an established communication history.

This should not be interpreted as “Microsoft cannot protect email from people you already know.”

Microsoft has many other layers, including spoof intelligence, SPF/DKIM/DMARC processing, Safe Links, Safe Attachments, phishing models, campaign detection, and other protections.

But the example illustrates something fundamental:

Previous legitimate communication establishes a relationship. It does not establish the legitimacy of today’s requested action.

That distinction becomes especially important when the real account itself has been compromised.

Communication Is Not Authorization

This leads to a simple principle:

Email may request a change. Email should not authorize the change.

The same should apply to other communication channels.

A Teams message may request a change.

A phone call may request a change.

A text message may request a change.

Even a video meeting may request a change.

But a high-consequence business action should have an authorization process appropriate to the consequence.

Consider the difference.

Identity question

“Is this really our CFO?”

Authorization question

“Is this CFO authorizing this exact transaction, for this amount, to this beneficiary, through an approved process?”

Those are fundamentally different questions.

Authentication tells us something about who is communicating.

Authorization determines what that identity is permitted to cause.

If Money Changes Direction, Verification Must Follow an Independent Trust Path

The FBI has recommended this kind of independent verification for years.

Its BEC guidance tells organizations to verify payment and purchase requests, confirm changes in account numbers or payment procedures, and use contact information independently obtained rather than a phone number supplied in the suspicious communication.

Older FBI guidance is even more explicit: companies should confirm transfer requests using previously known phone numbers and consider secondary approval when vendor payment locations change.

So the underlying control is not new.

What deserves more emphasis in the AI era is why it works.

You are not merely changing channels.

You are changing trust paths.

That distinction matters.

Email followed by a phone number contained in that email is not independent verification.

Email followed by a meeting invitation created by the suspicious sender is not necessarily independent verification.

A message followed by a WhatsApp number supplied in the message is not independent verification.

Different medium does not automatically mean independent trust.

A stronger rule is:

If money changes direction, verification must follow an independently established trust path.

What Should Trigger It?

Organizations do not need to stop and investigate every ordinary email.

The trigger should be the consequence.

Examples include:

• a new bank account;
• changed routing information;
• a new beneficiary;
• a previously unused vendor;
• an unusual payment amount;
• a payroll direct-deposit change;
• a request for gift cards or cryptocurrency;
• an MFA reset;
• creation of privileged access;
• release of sensitive company or employee data;
• redirection of an expensive shipment;
• an exception to an established approval process.

The request itself may be perfectly legitimate.

But the consequence justifies additional authorization.

Banking Already Uses a Version of This Logic

There is an instructive parallel in European payment security.

Under PSD2-related strong-customer-authentication rules for remote electronic payments, authentication can be dynamically linked to the specific amount and specific payee. If the amount or payee changes, the authentication code is invalidated.

That is a powerful distinction.

It is not simply:

“We authenticated Nikolay.”

It is closer to:

“Nikolay authorized this particular amount to this particular recipient.”

The authorization is tied to the consequence.

That idea should extend far beyond banking.

The “Secret Question” Is Not Enough

One tempting response to AI impersonation is a prearranged secret word or question.

The FBI itself recommends a family secret word or phrase as one protection against personal impersonation fraud involving AI-generated voices.

For enterprise use, however, static challenge questions are weak as a primary control.

If an attacker owns an executive’s mailbox, years of correspondence may contain enough information to answer supposedly private questions.

Shared business secrets also create storage, rotation, employee-turnover, and disclosure problems.

A stronger system uses an independently established process, ideally with short-lived or cryptographically protected verification for higher-risk transactions.

NIST’s current digital-identity guidance illustrates why independence matters: an out-of-band authentication mechanism uses a separate secondary channel and short-lived verifier-generated secrets. NIST explicitly prohibits email itself from serving as an out-of-band authentication channel and notes that ordinary out-of-band authentication is still not inherently phishing-resistant.

In other words:

Adding another check helps. Designing the check so that it cannot simply be relayed or socially engineered is better.

A Practical Business Model

For a small organization, the policy can remain simple.

A vendor emails new banking instructions.

Do not approve the change from that email.

Retrieve the vendor contact from the existing vendor record.

Verify the change independently.

Require a second person for significant payments.

Record the approval.

For a larger organization, the same principle can be enforced technologically:

Request → consequence identified → independent authorization → execution

Vendor master data can have separate access controls.

Payment changes can require maker-checker approval.

High-value transfers can require multiple authorized parties.

Privileged-access changes can require step-up authentication and separate approval.

Payroll changes can use an authenticated HR portal rather than email authorization.

The objective is not to make employees perfect at recognizing deception.

The objective is to make a successful deception insufficient to complete the attack.

The Most Important Mental Shift

Cybersecurity awareness often asks employees to inspect the communication:

Does the domain look right?

Does the language seem unusual?

Is the request urgent?

Is the link suspicious?

Those checks remain useful.

But generative AI and account compromise make them less suitable as the final security boundary.

So consider adding one more question:

What will happen if I obey this message?

If the answer is:

“Money moves.”

“Credentials change.”

“Access expands.”

“Sensitive information leaves.”

“A trusted record changes.”

Then the consequence—not merely the appearance of the message—should determine the verification requirement.

This Is Common Sense. That Is Exactly Why It Matters.

None of the underlying controls described here are new.

Out-of-band verification, callbacks to known numbers, dual control, segregation of duties, transaction authorization, MFA, and payment-specific authentication have existed for years.

The interesting problem is that organizations can possess all of that security knowledge and still psychologically treat a convincing communication as authorization.

AI makes that assumption increasingly dangerous.

The message may be fake.

The message may be genuine.

The account may be compromised.

The voice may be synthetic.

The video may be manipulated.

But organizations do not necessarily need to solve every one of those questions before protecting themselves.

They can start with a simpler principle:

Communication is not authorization.

And for the people responsible for moving money:

If money changes direction, verification must follow an independent trust path.

The future of BEC defense may involve increasingly sophisticated AI detection.

But some of the strongest defenses may begin with something much simpler:

Do not give a communication more authority than it deserves.