Does impersonation always require AI?

No. AI can assist imitation, but deceptive identity claims long predate modern generative systems.

Is detecting a deepfake the same as verifying identity?

No. Content origin, speaker identity, and permission to request an action are distinct questions.

What is a useful response to an unexpected familiar-sounding call?

Verify the claim through a contact route already known to be genuine, following the relevant organisational process.

AI Glossary / Governance, ethics and safety / Beginner

Impersonation

Definition

Impersonation is presenting oneself, a message, or a system as another person or trusted entity. In AI safety and security discussions, the concern is deceptive impersonation: using an assumed identity to mislead someone or gain trust, access, information, or influence. AI-generated text, images, audio, and video can support impersonation, but the underlying problem does not require AI.

What it means

A familiar name, voice, face, or writing style can make a communication feel authentic. Those features are evidence of appearance, not necessarily proof of who originated the message or whether the requested action is authorized.

AI can make some forms of imitation easier to produce. For example, synthetic audio may sound like a known person, while generated text can imitate a professional tone. The resulting content can be convincing without coming from the claimed source.

Context matters. A clearly disclosed fictional performance or an authorized synthetic voice is different from a deceptive identity claim. This entry concerns the security and trust problem, rather than treating every imitation as harmful or making a general legal judgment about all uses.

How it works

An impersonation attempt relies on a gap between claimed identity and verified identity. The recipient may recognize a name or other familiar cue and treat that recognition as enough to trust the request.

The attempted action can be disclosure, account access, a change to records, or acceptance of a false statement. AI-generated media may strengthen the appearance of authenticity, but compromised accounts and ordinary misleading messages can create the same underlying problem.

A defensive process separates identity verification from the content's persuasiveness. Use an independently established contact route or approved authentication process for consequential requests. Then check authority for the requested action as a separate question. A genuine employee may still lack permission to request a particular change.

Three practical examples

1. A caller sounds like a known colleague and asks staff to disclose confidential information. The voice alone does not verify the caller's identity or authority.

2. A public post uses a synthetic video to make it appear that an organization's spokesperson issued an announcement that the organization has not confirmed.

3. A message claims to come from a familiar supplier and requests a sensitive change. Staff verify through existing supplier records rather than relying on the contact details supplied in that message.

Think of it this way

Think of a costume and a staff badge printed on ordinary paper. They can resemble the visible signs of a role without granting the wearer that role's identity or permissions.

The analogy is limited because digital communications can also come through genuinely compromised accounts. In that case, the familiar channel itself may be part of the problem. The useful lesson is to check the trust relationship and the requested action, rather than deciding authenticity solely from appearance or fluency.

Worked example

Consider an invented training exercise involving 20 suspicious requests. Staff correctly challenge 16 and act on four without completing the required verification. The challenge rate is 16/20, or 80%; the unverified-action rate is 4/20, or 20%.

The exercise also includes 80 legitimate requests. Staff unnecessarily delay eight of these, a 10% delay rate for legitimate requests. Reporting only the 80% challenge rate would omit the cost and usability of the verification process.

These counts do not estimate real-world attack prevalence or prove that any detector works. They help evaluate a workflow: which cues led to uncertainty, whether staff could access a trusted contact route, and whether the procedure caused avoidable disruption.

The next step is to investigate the cases and improve the process, not blame individuals solely from a small simulated score. A control that is impossible to follow during ordinary work is unlikely to remain dependable.

Illustrative case study

Fictional case: Elmstone Design receives a voice message apparently from a senior manager requesting confidential client files. A staff member recognizes the voice but uses the organization's established directory to contact the manager separately.

The manager says they did not make the request. The staff member preserves the message and follows the internal reporting process. The organization reviews which requests need independent verification and whether employees can obtain it without unreasonable delay.

The case is an original defensive illustration. It does not establish that every unfamiliar request is malicious, or that a callback alone prevents every attack. It shows why familiar-sounding content should not replace the organization's identity and authorization controls.

Common misconceptions and mistakes

“I recognise the voice” is not sufficient verification when synthetic or replayed audio is possible. Equally, unusual audio quality does not prove deception.

An AI-generated-content detector is not an identity service. Even a correct finding that content is synthetic does not by itself explain who authorized it; a finding that content is genuine does not establish permission for the requested action.

Another mistake is assuming impersonation always uses sophisticated technology. Ordinary messages and compromised accounts can be effective. Defenses should address the trust and approval process, not depend entirely on identifying a particular generation technique.

Business use

Businesses can review the points where a claimed identity unlocks sensitive information or actions. Provide staff with established verification routes, clear approval responsibilities, and a straightforward way to report suspicious communications.

Test whether those arrangements work during absences, urgent requests, and handovers. Avoid processes in which the requester supplies every piece of evidence used to verify themselves. Where the organization uses authorized synthetic media, clear disclosure and controlled publishing channels can help audiences distinguish the organization's own communications from unsupported identity claims.

Check your understanding

A message sounds exactly like a manager and asks for a confidential file. What two issues still require checking?

Answer: Whether the request really came from the claimed person and whether that person is authorized to request the disclosure through the proposed process.

Related terms

Deepfake
Information security
Incident response
Spoofing
phishing
voice cloning
authentication
authorisation
social engineering

Learn next

Study authentication and authorization next. For one sensitive workflow, identify what proves the requester's identity, what proves their permission, and whether either check relies entirely on information supplied by the requester.

Sources

NIST CSRC Glossary, spoofing: https://csrc.nist.gov/glossary/term/spoofing

FTC, Fighting back against harmful voice cloning: https://consumer.ftc.gov/consumer-alerts/2024/04/fighting-back-against-harmful-voice-cloning

FTC, Approaches to Address AI-enabled Voice Cloning: https://www.ftc.gov/policy/advocacy-research/tech-at-ftc/2024/04/approaches-address-ai-enabled-voice-cloning

Official explanations were read. Examples and exercise counts are original; no claim is made about attack prevalence or the performance of a particular detection product.

Previous: Imperfect information Next: Implementation level