Sora 2 Identity Bypass: Can Text-to-Video Deepfakes Fool Selfie and Video KYC?

What is a Sora 2 identity bypass?

A Sora 2 identity bypass is the use of a text-to-video clip, generated with Sora 2 or a comparable model, as the face evidence in an identity check. The attacker submits or injects a short video of a person looking at the camera, speaking or moving on cue, and hopes the liveness and face-match steps accept it as a real capture. The term describes a class of attack; there is no single published exploit with that name.

OpenAI announced Sora 2 on 30 September 2025, describing it as more physically accurate, realistic and controllable than earlier systems, with synchronized dialogue and sound effects. Those are the qualities that matter to an identity check: plausible skin, lighting and motion, and lips that match speech.

Sora itself is gone. OpenAI's help centre says the Sora web and app experiences were discontinued on 26 April 2026 and the Sora API on 24 September 2026. Identity teams should still plan for the attack, because generated clips persist after a product closes and other models offer similar output. Google said on 20 May 2025 that Veo 3 can generate video with audio, including dialogue between characters.

Which identity checks can a text-to-video clip beat?

A text-to-video clip is rendered before the attack, which limits where it works. It cannot react to an instruction it did not anticipate. That makes the exposure depend on how the verification flow collects its evidence.

Flows that accept an uploaded selfie video, or that ask every user for the same gestures, are the most exposed, since an attacker can generate a clip that blinks, smiles and turns on schedule. Flows with randomised, server-issued prompts are harder, because the attacker would need a clip for every possible prompt order. Live agent calls are harder still for prerecorded media, though a real-time face swap is a different and more flexible tool.

Delivery is the second hurdle. On a mobile app that opens the camera directly, a prerecorded clip has to be injected through a virtual camera, emulator or hooked app, or replayed on a screen in front of the lens. Injection is covered in the digital injection attacks guide; presentation attack detection is designed to catch the screen replay.

Did Sora 2's safeguards stop identity misuse?

OpenAI built several safeguards into Sora 2, and they reduce misuse inside the product without protecting a third party's KYC flow. At launch OpenAI said every Sora video carried a visible watermark and C2PA metadata, and that it kept internal reverse-image and audio search tools to trace videos back to Sora. Google says Veo 3 outputs carry SynthID watermarks.

Likeness controls targeted impersonation directly. OpenAI's characters feature required a short one-time video-and-audio recording in the app to verify the user's identity and capture their likeness, let users decide who could use it, and blocked depictions of public figures. That design meant generating a specific private person through Sora required either that person's consent or a way around the guardrails.

Attackers look for that way around. FinCEN noted in November 2024 that criminals may develop methods to evade the safeguards of leading AI developers, and that open-source tools can be modified to circumvent controls. For identity teams the practical point is narrower: a verification server receives frames, and frames that were cropped, re-encoded or injected carry no watermark or metadata to inspect. The guide to detecting Sora videos explains how provenance checks work on files that keep their marks.

How to harden selfie and video KYC against text-to-video deepfakes

NIST SP 800-63A-4 gives the frame for remote identity proofing. Providers shall implement controls that raise confidence media comes from a genuine sensor and shall analyse all submitted media for manipulation, and they should analyse media for signatures of generative AI and deepfake tools. For attended video sessions, NIST also requires random human-in-the-loop cues such as moving objects between the sensor and the face.

Applied to text-to-video risk, that becomes a short list of changes:

• Stop accepting uploaded or gallery video for liveness; require a capture inside the app or browser session.
• Issue randomised prompts from the server, bind them to the session, and include occlusion, such as a hand passing across the face.
• Add device and capture-integrity checks for virtual cameras, emulators and modified apps, so pre-rendered clips cannot be injected quietly.
• Run every selfie and video through media analysis for generative-model and manipulation artifacts before the face match decides.
• Build a test set of clips from current text-to-video models and rerun it whenever a new generator is released or your vendor updates models.

How NeuroVerify flags generated faces and video

NeuroVerify checks the selfie, video or audio your flow received and returns one unified risk score with signal-level evidence, so your policy can step up or reject before the face match approves. Of its six signals, AI Generative Model Analysis looks for traces left by generative models, and Face Manipulation Detection and AI Pixel-Level Manipulation cover swaps and edits; Visual Safety Screening, Live Presence Verification and AI Content Compliance run in the same request.

Eligible image requests return in under 200 ms p95 under defined test conditions. Integration uses Android, iOS and Flutter SDKs, backend SDKs for Python, TypeScript, Go and Java, or the REST API, with managed cloud, private cloud, on-premises and air-gapped deployment.

The models build on ARCAS 1B, Neural Defend's deepfake detection foundation model. The ARCAS paper reports pooled accuracy of 99.99% on GenImage, 99.92% on WildFake and 97.65% on OpenFake, all image benchmarks. The public VendorBench-100 benchmark includes text-to-video stills among its 100 adversarial images; Neural Defend ranked first of 36 systems there with an MCC of 0.876 against 0.646 for the next vendor. One VendorBench author also co-authored the ARCAS paper, the corpus and results are public, and neither study measures full video or Sora-specific accuracy.

What detection cannot settle about generated video

A generative-model score is evidence about the media, and it says nothing about intent or about which product made a clip. Attributing a video to Sora 2 specifically needs provenance data or the vendor's own tracing, which a verification server rarely has.

New generators can produce artifacts a model has not seen, and heavy compression weakens every signal. Keep a review path for borderline scores, log model versions with each decision, and retest when the generative landscape shifts, as it did when Sora closed and other video models took its place.