AI Video-Call Impersonation: A Verification Workflow for Teams

Treat the meeting as an unverified contact

A colleague joins a video call with the right display name, a familiar face, and a convincing voice. During the meeting, that person asks someone to change payment details, disclose account information, reset access, or send a file. The call may feel like confirmation because everyone can see and hear the participant. It is still only the channel through which the request arrived.

The FBI warns that criminals use generative AI to make fraud schemes more believable and to operate them at a larger scale. Its examples include AI-generated audio used to impersonate public figures or personal relations to obtain payments, as well as AI-generated video used to create believable depictions of public figures in support of fraud. The warning does not describe a particular corporate video-call incident or prescribe a meeting policy.

Teams therefore need a procedure that works without asking an employee to decide whether a face or voice is synthetic. The practical rule is to leave the incoming meeting before approving a high-risk action and verify the request through records and contacts the team already trusted.

Separate the participant, request, and approval

Write down three things before anyone acts. First, who does the participant claim to be? Second, what exact change or disclosure is being requested? Third, which existing approval is required for that action? A convincing participant does not answer the second or third question.

Describe the request in operational terms. Record the account, payment destination, employee record, credential, document, or permission that would change. Note the deadline and any instruction to skip a normal reviewer. This turns a vague sense of urgency into a request another person can check.

Do not use contact details supplied in the meeting to perform that check. Open the company directory, an existing conversation, a known phone number, or another record your team selected before the call. Start a new contact with the person being represented and repeat the requested action in your own words. If that person cannot be reached, keep the action pending and follow the escalation path already defined by your organization.

Then check approval separately. A verified identity does not automatically authorize every payment, data disclosure, account reset, or permission change. Keep the usual approvers and written records in the process. Record who verified the identity, who approved the action, which independent channels they used, and what was finally executed.

Run the check without staying inside the call

A short meeting response can be consistent across finance, support, HR, and operations: “We will verify this request through our normal channel and respond there.” The employee does not need to accuse anyone of using AI or argue about visual clues. The request simply remains unverified until the separate check is complete.

End or pause the meeting before opening the trusted contact record. Do not follow a new link, call a number posted in chat, or accept a replacement contact sent by the participant. Those details belong to the same unverified interaction.

Preserve what is available without editing the only copy. That may include the meeting invitation, participant name, chat messages, shared files, requested destination, time, and the decision record. If the event may involve financial fraud, the FBI directs victims to report it to the Internet Crime Complaint Center and include available details. Each organization should also follow its own legal, security, privacy, and incident-reporting obligations.

Use detection only on a saved file

A live video call may leave no recording that can be examined. If your team has a saved video, audio clip, image, or text message, DeepFakeCheck can analyze that file and return a probabilistic risk signal. It cannot verify the live participant's identity, approve the requested action, or prove that the meeting was legitimate.

Automated detection has false positives and false negatives. A false positive flags authentic material as suspicious; a false negative misses synthetic or manipulated material. A high score supports further review, while a low score does not clear the participant or the request. Continue the independent contact and approval checks regardless of the result.

Keep the detector output beside the source file and the verification notes. This separates what the tool indicated from what the team confirmed through its own records. It also prevents a risk score from silently becoming an identity decision.

Rehearse one high-risk request before it happens

Choose one action that would cause serious harm if approved for the wrong person, such as changing a supplier payment destination or resetting privileged access. Ask a staff member to locate the trusted contact, pause the request, reach the claimed participant outside the meeting, find the normal approver, and record the outcome.

If any step depends on information supplied during the incoming call, fix that gap before the next request. The meeting response should be short enough to use under pressure and specific enough that two employees follow the same path. A request moves forward only after the person, the action, and the required approval have each been checked outside the unverified meeting.

Sources

• FBI Internet Crime Complaint Center, “Criminals Use Generative Artificial Intelligence to Facilitate Financial Fraud”: https://www.ic3.gov/PSA/2024/PSA241203