What breaks when organisations trust live video for approval decisions?

The approval process starts using appearance as proof of identity, which is exactly what deepfake attackers exploit. Once the meeting itself becomes the validation step, there is no independent control left to challenge the request. Organisations need separate verification channels for urgent or high-value actions so the meeting cannot function as the only gate.

Why This Matters for Security Teams

Live video is often treated as a human trust signal, but it is not a reliable approval control when attackers can synthesize faces, voices, backgrounds, and timing cues in real time. The failure is structural: once a meeting becomes the validation step, the organisation has abandoned independent verification and handed the attacker a channel to impersonate authority. That is why current guidance on identity assurance and control separation matters, including NIST SP 800-53 Rev 5 Security and Privacy Controls.

NHI Management Group has repeatedly shown that organisations struggle when identity proof, privilege, and approval are collapsed into one step, especially in high-pressure workflows. The same pattern appears in compromise cases where trust is built on convenience instead of verification, as seen in JetBrains GitHub plugin token exposure and the broader risk of Code Formatting Tools Credential Leaks.

Security teams get this wrong when they assume the video call is a compensating control. In practice, many security teams encounter approval fraud only after the money, token, or privileged change has already been authorised, rather than through intentional separation of verification and execution.

How It Works in Practice

The safer model is to treat live video as communication, not authentication. Approval decisions for urgent or high-value actions should require an independent verification path that is outside the meeting itself. That may include callback procedures, signed requests, out-of-band confirmation through a known identity, or a pre-registered workflow in a ticketing or PAM system. The point is to verify the request through controls that an impersonator in the call cannot easily influence.

For organisations managing NHI and agentic workflows, the same principle applies to machine-led approvals: runtime authorisation should depend on policy, context, and cryptographic identity, not on a convincing interaction. That is consistent with the direction of Ultimate Guide to NHIs, which emphasizes lifecycle control, visibility, and revocation, and with the threat lessons in JetBrains Marketplace AI Plugin Campaign.

• Use the meeting to discuss intent, but require a separate control to approve action.
• Bind approvals to known approvers, not to whoever appears on screen.
• Use step-up verification for payments, key rotation, access grants, and vendor changes.
• Keep a tamper-evident record of who approved, from which channel, and under what policy.
• Block emergency exceptions from bypassing the independent verification path.

Where this guidance breaks down is in fast-moving incident response environments that rely on informal war rooms, because pressure to act quickly often overrides the discipline of out-of-band verification.

Common Variations and Edge Cases

Tighter approval controls often increase operational friction, requiring organisations to balance fraud resistance against response speed. That tradeoff is real, especially when executives, finance teams, or incident responders expect immediate action. Best practice is evolving, but current guidance suggests that speed should come from pre-arranged workflows, not from relaxing verification at the moment of decision.

Some organisations use live video as one signal among many, which is acceptable if it is not the deciding factor. Others require dual approval, signed request artifacts, or a second channel owned by a different control domain. For sensitive identity and access changes, this matters even more when secrets and tokens are already exposed in places like CI/CD tools and developer extensions, a risk pattern highlighted by Hard-Coded Secrets in VSCode Extensions.

There is no universal standard that says video can never be used, but there is a clear operational rule: it should never be the sole gate for privileged approval. Organisations that permit that exception usually discover the gap only after a fake executive, fake vendor, or deepfake-enabled request has already triggered a loss.

Related resources from NHI Mgmt Group

• What breaks when organisations stop at AI inventory and do not enforce policy?
• What breaks when organisations rely on SSPM without identity governance?
• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?