Protect High Risk Requests from Synthetic Voice and Video

A member of staff receives a convincing video call from someone who appears to be an executive. The request is urgent: change a supplier's bank details before a payment is released. Training staff to look for strange shadows or an unnatural voice may help them notice some suspicious material. It is not a dependable authorization process.

A stronger design makes the sensitive request pass the same independent checks whether it arrives through ordinary email, synthetic audio, a real video call, or an AI assistant. The action needs a trusted identity, a verified scope, and the appropriate approval, not simply a familiar appearance.

Design around the action, not the deepfake detector

Identify requests that could create significant harm: payment-detail changes, unusual transfers, account recovery, access grants, confidential exports, or changes to operational controls.

The FBI's IC3 guidance describes criminals using generated audio and video and recommends verifying callers through independently obtained contact information. A recognizable voice is not enough.

Do not make staff decide whether every media artifact is AI-generated before they can follow the process. A real executive can have a compromised account; an ordinary email can carry a fraudulent instruction. Action-based controls address a broader problem.

Establish the verification channel before the incident

Maintain approved contact information and authenticated channels through a controlled process. A callback to a number provided in the suspicious request is not independent verification.

Define how the exact requested action is confirmed, which second approval is required, and how unavailable approvers are handled. An urgent message should not invent its own exception path. Provide an approved way to escalate a genuinely time-sensitive problem.

AI can help recognize that a request belongs to a sensitive category or prepare a factual case summary. Conventional systems should enforce account permissions, approval requirements, and record changes. A model's assessment that the caller seems genuine must not unlock the action.

Follow a supplier bank-change request

Consider an illustrative accounts-payable process. The supplier master record owns approved payment details, and the payment system enforces the organization's authorization rules. A request arrives through a convincing call and a matching attachment.

The intake workflow creates a pending change case. It preserves the request's origin and the requested fields while avoiding unnecessary sensitive copies. It does not update the supplier record.

An authorized staff member contacts the supplier through an independently established channel and confirms the precise change using the approved process. A separate approver checks the required evidence. If verification fails or the trusted contact is unavailable, the change remains pending through the established escalation path.

A successful authorized update produces a supplier-record version and a verified readback. The payment process checks the accepted current record, rather than acting on the original message. If there is concern about an already released payment, staff follow the appropriate financial and security incident procedures promptly.

The control works without requiring anyone to prove that the original caller was synthetic. The request simply failed or passed a defined verification process.

Understand what provenance can and cannot establish

C2PA develops a foundation for documenting media provenance. Such information can help establish aspects of a file's origin or history when the relevant credentials and trust relationships are available.

It does not prove that a statement in the file is true, that the apparent speaker has authority for a transaction, or that the business should act. Missing provenance is also not proof of fraud. Avoid treating a technical badge as a universal trust verdict.

Similarly, do not promise that blockchain or a detector will solve every impersonation problem. Choose technical measures for a defined role within the operating process.

The trusted directory needs its own controlled update process. A request to replace the supplier's contact number should not use the unverified new number to confirm itself. Test that circular path explicitly, and define who can approve a legitimate directory correction. Otherwise the apparent callback can reproduce the original impersonation through a second interface.

Test the process with realistic pressure

Run a supported exercise using fictional data and appropriate internal approval. Do not surprise customers or trigger real payments.

• Can staff identify the sensitive action without diagnosing the media?
• Do they know where to obtain the trusted contact details?
• Can they confirm the exact requested change?
• Is a separate approval actually enforced?
• Does an unavailable approver lead to a controlled pending state?
• Can the business retrieve the decision without exposing credentials or unnecessary personal data?

Review usability as well as security. A cumbersome process that staff routinely work around is a warning to improve the design, not simply to repeat the same training.

The objective is not universal suspicion. It is a calm, repeatable way for legitimate requests to earn the authority they need. That remains useful as synthetic media becomes more convincing and as ordinary communication failures continue to occur.