AI Phishing and Deepfakes. Verify the Sensitive Request

A supplier's email asks you to change its bank details. The tone is familiar. Verify the request through a known contact before paying. FBI IC3 recommends a secondary channel for account changes, because the message alone cannot establish authority.

Correct language does not establish identity

An attacker can draw on company websites, social posts or earlier correspondence. Generative tools can help with tone and language. The text may not reveal whether AI was involved at all.

Do not make spelling your identity check. Inspect the address, unusual requests and changed payment details. A legitimate account can also be compromised, so a sensitive operation needs a step independent of the received message.

Treat the voice as part of the request

A caller may demand an urgent transfer, replacement bank details or credentials. You do not need to prove the voice is synthetic before pausing the operation. Call back using the known number in a contract or directory rather than a contact supplied in the suspicious request.

Give bank-detail changes an independent approver. The procedure should work whether or not the attacker used AI.

How to Defend: Technical Measures

Email Security

• SPF, DKIM, DMARC as the foundation for sender verification
• AI-powered email filtering for analyzing content and behavioral patterns
• Link sandboxing for automatic link verification in a safe environment

Multi-Factor Authentication

• MFA on all critical systems
• Hardware keys (FIDO2) for the most sensitive access
• Biometrics as an additional factor

Zero Trust Architecture

• Verify every access, not just at the perimeter
• Minimum privileges (least privilege)
• Continuous anomaly monitoring

How to Defend: Internal Procedures

Technology alone isn't enough. Write the procedure down and rehearse it with the people who will use it.

Verification Protocol for Financial Operations

• No transfer above a defined amount without second-channel verification
• Callback to a verified number (not the number from the email)
• Dual signature for changes to supplier banking details

Reporting Suspicious Messages

• Simple way to report a suspicious email (button in the email client)
• No penalties for false alarms, better to report 10 false ones than miss 1 real one
• Quick feedback from the security team
• Monthly reports on the number of reported messages and their evaluation

Regular Training

• Simulated phishing campaigns (not as punishment, but as training)
• Updated examples of real attacks
• Special training for management and finance departments

Put account verification in the workflow

A request that changes banking details should trigger verification through a second channel, and the change belongs in an audit log. The rule should be evaluated from confirmed incidents and false positives, not an unsupported marketing anecdote.

Checklist for Your Company

• Do you have SPF, DKIM, and DMARC set up for your email domain?
• Do you use MFA on all critical systems?
• Do you have a defined procedure for verifying financial operations?
• Have your employees completed security training in the last 6 months?
• Do you have a simple way to report suspicious messages?
• Do you have an incident response plan in case of a successful attack?

Prioritise missing controls by risk and name an owner for the exercise. Test the reporting route and the response. Our security guidance covers access questions. We can help design the exercise.