Because generative AI can reproduce public speech and appearance well enough to satisfy human recognition without proving the person is real, present, or authorised. Familiarity is a signal, not a control. High-risk approvals now need an external verification step such as a known callback path or separate approver.
Why Familiarity Stops Being a Reliable Approval Signal
High-risk approvals fail when people treat recognition as proof. A familiar face or voice may be real, but it does not prove the person is present, authorised, or acting under the right conditions. That matters most when the request can trigger money movement, access changes, data exposure, or urgent operational action. Controls should therefore verify the approval through an independent path, not through appearance or tone alone.
Security teams are seeing this shift because synthetic media now lowers the cost of believable impersonation. Publicly available images, recordings, and meeting clips can be recombined into convincing requests that feel routine to the recipient. The problem is not only deception, but also speed: rushed approvals are often made in channels where staff are conditioned to trust what looks familiar. NIST's NIST SP 800-63 Digital Identity Guidelines are built around stronger proof of identity than casual recognition, which is the right direction for approvals that carry material risk.
In practice, the failure usually appears first as a process shortcut, not as an obvious compromise.
How Strong Approval Checks Work in Practice
Robust approval workflows separate recognition from verification. The person asking for the action may be familiar, but the approver should confirm the request through a channel that is harder to spoof and easier to audit. For high-risk actions, that often means a callback to a known number, a second approver in a separate workflow, or a signed request passed through a controlled system rather than an informal chat thread.
Effective organisations also define which requests are inherently unsafe to approve on social trust alone. A common pattern is to require extra verification when the request involves one of these triggers:
- payment release, bank detail changes, or urgent financial exceptions
- privilege escalation, access grants, or credential resets
- data export, contract approval, or legal sign-off
- changes that bypass normal waiting periods or review steps
The control is strongest when it combines process design and evidence. The approver should be able to show what was verified, through which channel, and against which known contact path. Where a workflow already exists, the question is whether it can resist impersonation without relying on human memory. NIST's NIST Cybersecurity Framework 2.0 is useful here because it pushes teams to formalise governance, verification, and response rather than depending on informal confidence. These controls tend to break down when organisations allow exception handling through ad hoc messaging channels because the audit trail and challenge step disappear.
Common Variations and Edge Cases
Tighter approval checks often add friction, so organisations have to balance speed against the blast radius of a wrong decision. That tradeoff is acceptable for low-impact requests, but it becomes costly when teams apply the same relaxed standard to high-risk actions as they do to everyday collaboration. The right level of assurance depends on the consequence of the approval, not on how familiar the requester seems.
There are also cases where voice alone may still be acceptable as a convenience signal, but not as the final control. For example, a known internal request may help route the ticket or prioritise response, yet the actual approval should still be confirmed in a separate system or through a pre-established callback path. The same is true in fast-moving incidents, where urgency tempts people to skip validation. Current guidance suggests treating urgency as a reason to tighten verification, not weaken it.
Teams should be especially cautious when employees work across time zones, use personal devices, or collaborate heavily over chat and video. Those environments create more opportunities for misheard context, cloned voices, and assumptions that “everyone knows everyone.” The strongest pattern is to reserve human familiarity for relationship context and use a formal control for the actual authorisation decision. High-risk approvals fail when organisations let convenience become the test of truth.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines — Digital Identity Guidelines | Strong identity assurance is needed when approval must prove who is authorised. |
| Recommendation — Use higher-assurance verification before accepting any high-risk approval. | ||
| NIST CSF 2.0 | GV.OV — Oversight | Approval processes need governance and oversight when trust can be abused. |
| PR.AA — Identity Management, Authentication, and Access Control | Access-changing approvals require verified identity and controlled authorisation. | |
| Recommendation — Define approval thresholds and independent verification for consequential requests. Require separate verification before granting access or privilege changes. | ||
| CIS Controls v8 | 6 — Access Control Management | High-risk approvals often grant access or privilege and need stricter control. |
| 8 — Audit Log Management | Approval decisions need evidence when voice or familiarity could be spoofed. | |
| Recommendation — Apply stronger approval gates before any access or privilege change. Log the verification step, approver, and channel used for each high-risk approval. | ||
| NIST Zero Trust (SP 800-207) | ID — Identity | Zero trust requires verifying identity before trusting an approval request. |
| Recommendation — Verify identity independently before allowing consequential actions. | ||
| MITRE ATT&CK | T1656 — Impersonation | Synthetic voice and likeness abuse fits impersonation-based social engineering. |
| Recommendation — Hunt for impersonation attempts and train approvers to verify out of band. | ||
Practitioner Guidance
What to prioritise: Classify which approvals can cause material loss, privilege change, or irreversible action, then require an independent verification step for those cases first. Low-risk convenience requests can remain lightweight, but high-risk paths should never rely on recognition alone.
Decision rule: If a request would still be dangerous after one mistaken approval, treat it as a high-risk approval and require a separate confirmation path that does not depend on the same communication channel as the request.
What to verify: Confirm that the approver can evidence the known callback path, the second approver, or the signed workflow record. If the process only proves that someone sounded familiar, it is too weak for consequential decisions.
Common mistake: Teams often add more training instead of a stronger control. Training helps, but it does not stop a convincing synthetic request from reaching a rushed human approver.
Practitioner takeaway: Familiarity should help a human interpret a request, but it should never be the mechanism that authorises it.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
