Sora 2 is dead.
The bytes remain.

OpenAI shut down the Sora 2 app on April 26, 2026. Six months in the wild. The API gets pulled September 24, 2026. Millions of Sora 2 videos remain in election ads, Russian disinformation, fake-celebrity shorts, and recompressed reuploads on every platform that doesn't preserve cryptographic provenance. Which is every platform.

OpenAI's C2PA implementation was technically excellent. It used the canonical Truepic Lens CLI to sign every output with a certificate naming OpenAI, issued by the Truepic Inc. CA, embed the IPTC trainedAlgorithmicMedia digital-source-type in a properly-versioned BMFF hash assertion, and stamp a cryptographic generation timestamp inside the signed manifest even when the container's own CreateDate was zeroed. By the standard of a closed room with a verifier running c2patool, Sora 2 did everything right.

Then it left the closed room. We took the canonical Sora 2 sample from the Content Authenticity Initiative's public reference repo and ran it through five common video pipelines, including the most conservative ffmpeg -c copy remux that doesn't even re-encode the streams. Every one destroyed the C2PA manifest. By the time a Sora 2 video reaches the audience, the cryptographic chain of trust is gone. What remains is the visible logo overlay, removable in 2 to 10 seconds by free LaMA-inpainting tools, plus a handful of stream-level fingerprints that an investigator has to know to look for.

This is a forensic post-mortem on Sora 2: what was inside it, what survived, and why the most ambitious AI-provenance project of 2025 ended with millions of unattributable videos and a quiet shutdown.

OpenAI launched Sora 2 as a free iOS app on September 30, 2025. NewsGuard, the press-credibility tracker, ran 20 known-false claims through it during a 17-day test window from September 24 to October 10. Sora 2 produced convincing news-style fakes of 16 of them. 11 succeeded on the first prompt. Five of the false claims originated with Russian disinformation operations.

Within five days, the app had 1 million downloads.

On October 20, Bryan Cranston went public after Sora 2 generated unauthorized clips of his voice and likeness. SAG-AFTRA, United Talent Agency, Creative Artists Agency, and the Association of Talent Agents joined the pressure. OpenAI issued a joint statement that day saying voice and likeness had been "opt-in from the start" and announced strengthened guardrails. Cranston thanked OpenAI for the response.

On November 11, Public Citizen sent a demand letter to Sam Altman authored by Big Tech accountability advocate J.B. Branch, urging the immediate withdrawal of Sora 2 from the iOS app, the Android app, sora.com, and the Azure AI Foundry API. The letter cited mass-generated deepfakes of Robin Williams, George Carlin, and Martin Luther King Jr. (each requiring direct estate complaints to compel a "temporary, reactive pause"), nonconsensual fetish content built on the cameo feature, threats to the 2026 midterms, anti-impersonation safeguards bypassed within 24 hours of launch, and the line that became the most-quoted of the letter: "mandatory" safety watermarks "removable in under four minutes with free online tools."

OpenAI did not pull Sora 2 in response.

Two days later, on November 13, France 24 published the first identification of Sora 2 deepfakes circulating in a Russian disinformation campaign about the war in Ukraine. NewsGuard's Reality Check identified seven specific Sora 2 videos showing Ukrainian soldiers surrendering en masse in Pokrovsk. NBC News separately reviewed twenty-one AI-generated videos of Ukrainian soldiers, of which at least half still carried a visible Sora 2 logo in the corner. The faces of two Russian streamers, Aleksei Gubanov and kussia88 (the latter has 1.3 million Twitch followers), had been pulled into "Ukrainian soldier" deepfakes. The videos accumulated millions of views across X, TikTok, Facebook, and Telegram. Watermarked deepfakes spread on platforms that strip C2PA manifests, while the watermarks themselves were one click and ten seconds away from removal.

The shutdown came on March 24, 2026. OpenAI announced the discontinuation of Sora with no specific reason given. Industry coverage attributed the decision to compute and cost pressures, a pivot to core enterprise products, and accumulated brand risk. Per OpenAI's help center, the Sora "web and app experiences" were discontinued on April 26, 2026, and the Sora API will be discontinued on September 24, 2026.

Sora 2 is dead. The bytes remain.

The canonical Sora 2 reference sample lives in the Content Authenticity Initiative's public example-assets repository, in videos/sora.mp4. The published manifest sits next to it at videos/manifests/sora.json. We read both, and we extracted everything we could from the video file with three forensic tools: ExifTool 13.58 (the canonical metadata extractor maintained by Phil Harvey), ffprobe 8.1.1 (the FFmpeg project's introspector), and c2patool 0.26.56 (the Coalition for Content Provenance and Authenticity's reference C2PA validator).

Here is what a Sora 2 video looked like, in metadata form.

The file is an MP4 in the ISO Base Media File Format, with brands isom, iso2, avc1, mp41. Hex-dumping the first kilobyte shows the box structure that makes a Sora 2 video distinguishable from a phone-shot MP4:

1. ftyp box: standard MP4 file-type header.
2. uuid box: a Sora-specific 16-byte UUID box, base64 value 2P7D1hsOSDySl1goh37EgQ==. C2PA's hash assertion explicitly excludes this box from the integrity hash, suggesting it carries Sora-specific runtime data that may change without invalidating provenance.
3. jumb box: the JUMBF (JPEG Universal Metadata Box Format) superbox carrying the C2PA manifest. About 1.4 KB total. This is where the cryptographic provenance lives.
4. mdat box: the actual video payload (encoded H.264 and AAC).
5. moov box: track headers including codec metadata, timestamps, and encoder strings.

Phone video has ftyp + mdat + moov. Sora 2 video has ftyp + uuid + jumb + mdat + moov. The two extra boxes (uuid and jumb) are the Sora 2 fingerprint at the file-structure level.

This is where Sora 2 made a deliberate, defensible privacy choice that produced a strange artifact.

In the QuickTime metadata block, every container timestamp is zeroed:

[QuickTime] CreateDate         : 0000:00:00 00:00:00
[QuickTime] ModifyDate         : 0000:00:00 00:00:00
[QuickTime] MediaCreateDate    : 0000:00:00 00:00:00
[QuickTime] MediaModifyDate    : 0000:00:00 00:00:00
[QuickTime] TrackCreateDate    : 0000:00:00 00:00:00
[QuickTime] TrackModifyDate    : 0000:00:00 00:00:00

A casual viewer pulling the file's properties in macOS Finder or Windows File Properties sees no creation date.

But the C2PA manifest, a few hundred bytes earlier in the file, is signed and timestamped:

"signature_info": {
  "alg": "Es256",
  "issuer": "OpenAI",
  "common_name": "Truepic Lens CLI in Sora",
  "cert_serial_number": "617499572571975960762842960741769199804397700166",
  "time": "2025-10-10T03:06:10+00:00"
}

October 10, 2025 at 3:06:10 UTC. Cryptographically signed. Tamper-evident. Preserved for any verifier with c2patool or the contentcredentials.org public verifier.

Sora 2 wrote two truths into the same file. The casual truth, presented to any normal viewer, is that the video has no creation date. The cryptographic truth, presented to any forensic verifier, is the exact second when the video was generated. The privacy choice was real (the casual user can't tell when the video was made), and so was the provenance commitment (anyone with the verifier can tell). Both stayed in the file together, until one of them got stripped on upload. We will get to which one.

To test what happens to a Sora 2 video as it travels through the world, we ran the canonical sample through five video pipelines designed to mirror what real platforms and users do to uploaded media.

Once the manifest is gone, what's left? A few stream-level signals that a determined investigator can use, none of them conclusive on their own:

The Pokrovsk campaign is the cleanest case study. Russian disinformation operators, possibly state-aligned, generated at least seven Sora 2 videos in November 2025 showing fictitious Ukrainian soldiers surrendering en masse and pleading with Russia for forgiveness. The faces were pulled from two real Russian streamers, including kussia88 (1.3M Twitch followers). The videos accumulated millions of views across X, TikTok, Facebook, and Telegram.

NBC News, France 24, NewsGuard, and Scroll Media independently identified the videos as AI-generated, often by visual analysis (looping motion patterns, characteristic facial dynamics, mispronunciation of Ukrainian city names, wrong gear and uniforms). At least half the analyzed videos still had the Sora 2 logo visible in the corner.

What none of those analyses could rely on, by the time the videos were spreading, was the C2PA manifest. The original signed manifests were stripped on first upload. The forensic answer was always going to be a mix of visual analysis, contextual reporting, and the rare residual fingerprint. Provenance, in the wild, was not what saved the day. It would have been, if any of the platforms had preserved the C2PA chain. None did.

Sora 2 is dead. The space is not empty.

Google Veo 3.1 and Veo 2-fast. We pulled both Google video models from the same Hugging Face dataset and ran the same forensic pipeline. Both Veo variants ship with the same Google in-house C2PA implementation, distinct from what Sora 2 used. claim_generator reads "Google C2PA Core Generator Library" (not Adobe's c2pa-rs, which Sora used). The signing certificate is issued by Google LLC with common name "Google Media Processing Services"; the timestamp comes from "Google Core Time Stamping Authority T8" (Google runs its own TSA rather than relying on a partner). The Veo 3.1 manifest carries two c2pa.ingredient.v3 assertions tracking input-to-output relationships, a richer provenance graph than Sora 2's simpler created-only assertion. Container is 1280×720 landscape at 24 fps, the inverse of Sora 2's 704×1280 portrait at 30 fps. Two findings worth flagging from c2patool's validation output: Veo's signing certificate is reported as "signingCredential.untrusted" (the cert is not in the standard C2PA trust list as of May 2026) and the timestamp authority is similarly "timeStamp.untrusted". Final validation_state is "Valid" because the cryptographic checks pass, but a strict verifier would flag the trust gaps. The fact that Veo 2-fast and Veo 3.1 use identical signing infrastructure suggests Google's C2PA pipeline is shared across model versions and stable. Sora 2 chose a trusted partner (Truepic) and wired an Adobe SDK; Veo chose to roll its own and is currently outside the trust list. Both produce signed, parseable manifests; both face the same platform-stripping problem we demonstrated above.

Vidu Q2 (Shengshu Technology). We pulled a Vidu Q2 sample from the same dataset and ran the full pipeline. The result is the third pattern in the comparison: no C2PA at all. No JUMBF box. No claim_generator. No trainedAlgorithmicMedia assertion. No signing certificate. Vidu Q2 ships zero AI-provenance metadata as of May 2026. A strict reading of EU AI Act Article 50 (enforcement August 2, 2026) means Vidu's outputs would not satisfy the machine-readable-labeling requirement out of the box. Three vendors, three postures: OpenAI Sora chose exemplary technical implementation that gets stripped on platform upload; Google Veo chose untrusted-but-self-managed signing that still gets stripped on platform upload; Vidu chose to ship nothing. Sora 2's death removes the strongest voluntary implementer from the consumer market, leaving the field tilted toward Google's untrusted-cert posture and Vidu's no-posture-at-all.

Runway Gen-4 and Pika 2.2. Both vendors document C2PA Content Credentials embedded in their generated videos as of May 2026. Runway's published documentation states that all generated outputs include C2PA metadata; Pika's 2.2 release notes describe automatic embedding of "invisible metadata (C2PA) into videos to identify them as AI-generated." Neither is on the C2PA Steering Committee, whose 2026 membership is Adobe, Amazon, Arm, BBC, Canon, Google, Intel, Meta, Microsoft, OpenAI, Publicis Groupe, Sony, and Truepic. We did not pull Runway or Pika samples through our forensic pipeline for this post (no public canonical reference asset in the contentauth example-assets repo), so we are reporting their stated posture rather than empirically verified output. The platform-stripping problem we demonstrated above is independent of vendor: any embedded JUMBF box gets dropped by the same MP4 muxers regardless of who signed the manifest.

Luma Dream Machine. Luma's published FAQ uses qualified language: "Metadata markers (C2PA-compatible provenance data) may be included to identify content as AI-generated, but these are not visible in the video itself." The "may" rather than "is" matters. Luma reserves the right to omit C2PA on a given output, and a viewer cannot tell from the API contract whether a particular Luma video carries provenance until they verify it. We did not test Luma samples either, but the documented posture is itself a regression from the explicit "all outputs are signed" guarantee that Sora 2 (Truepic-trusted) and Veo (Google-self-signed but consistent across N=2 samples we tested) both honored.

The empirically confirmed pattern, across the four vendors we did pull samples from: three of four ship C2PA in some form (Sora 2, Veo 2-fast, Veo 3.1) and one ships nothing (Vidu Q2). Of the three that ship, only Sora's chain is publicly trusted; Google's is currently outside the C2PA Trust List per c2patool's own validation output. Sora 2's death removes the strongest publicly-trusted voluntary implementer from the consumer market. The EU AI Act Article 50 enforcement deadline (August 2, 2026) requires machine-readable labeling of AI-generated content distributed in the EU; vendors shipping C2PA-by-default are positioned to comply, vendors shipping nothing (Vidu) or qualified language (Luma) are not.

The deeper pattern: AI video provenance is moving forward across the industry on the producer side. The platform layer that distributes AI-generated content still strips what gets shipped. Whether a vendor signs with a trusted Truepic chain or a self-signed Google cert or no chain at all becomes academic once Instagram, X, TikTok, LinkedIn, Facebook, YouTube, or Discord have processed the upload.

Six findings, one paragraph each.

Sora 2's C2PA implementation was the strongest of any AI video tool in 2025. Truepic Lens, OpenAI as issuer, ECDSA P-256 signing, IPTC standardized digital-source-type vocabulary, BMFF v3 hash with intentional exclusion list, cryptographic generation timestamp preserved separately from container timestamps. By every internal-quality metric, OpenAI did the C2PA project right. The implementation was not where the failure happened.

The platform layer is where the failure happened, and it's universal. Instagram, X, TikTok, LinkedIn, Facebook, YouTube, Discord all rebuild MP4 containers on upload and don't preserve JUMBF boxes by default. The behavior is not deliberate manifest-stripping; it's the natural consequence of how every modern video pipeline has worked for years. Until platforms add explicit JUMBF preservation (an option exists in the spec, just nobody implements it), the C2PA chain of trust ends at the first upload step.

The privacy/provenance contradiction inside Sora 2 is real and instructive. Container timestamps zeroed (privacy choice for the casual viewer); cryptographic timestamp preserved inside the signed manifest (provenance commitment for the verifier). When the manifest gets stripped on upload, only the privacy half survives. The user has no way to verify when a Sora 2 video was generated. The investigator has no way to verify it either. The party that benefits from manifest stripping is the bad actor, not the privacy-conscious user.

Watermark overlays are theater for the casual viewer and irrelevant to the determined adversary. Public Citizen's letter cited the watermark removability and OpenAI did not address it. The remover ecosystem matured quickly and is now free, fast, and effortless. A "mandatory" visible watermark removable in 2 to 10 seconds with no skill or money is not a deterrent. It is a UX label.

Document Inspector for Word and Sora 2's C2PA share a structural problem: provenance fields exist in the file, but the system around them doesn't preserve them through normal use. Our /docx work showed Microsoft's Document Inspector leaves more than a dozen identity surfaces untouched even when the user explicitly invokes "Remove All". The Sora 2 work shows that when the implementation is exemplary, the platform layer destroys it anyway. Different companies, different file formats, same failure mode: a provenance system that's correct in theory and useless in deployment.

EU AI Act Article 50 reached its enforcement date on August 2, 2026. When this was written that date was three months off; it has now passed. Article 50 requires machine-readable labeling on AI-generated content distributed in the EU. The two operative mechanisms named in the regulation are watermarks and metadata. We demonstrated empirically that current visible watermarks are removable in seconds and that current metadata-based provenance is destroyed by every video pipeline we tested. That gap between what the regulation asks for and what the technology delivers is no longer a forecast, and nothing in the measurements above has changed to close it.

For investigators, journalists, and content moderators who need to identify videos that may have come from Sora 2 even after manifest stripping and watermark removal:

1. Check the C2PA manifest first. Use c2patool <file> or upload to contentcredentials.org/verify. If a manifest is present and the claim_generator is "Sora," definitive. If absent, proceed.
2. Check resolution and aspect ratio. 704 × 1280 portrait is non-standard for organic phone-shot content. Most phones export portrait video at 1080 × 1920 or 720 × 1280. The 704 width is a Sora 2 default.
3. Check duration. Sora 2 standard outputs are between 5 and 15 seconds; Sora 2 Pro extends up to 25 seconds. Real-life clips vary much more widely. A clip in the 5 to 15 second range, paired with the resolution and encoder signals below, is consistent with Sora 2 standard.
4. Check the encoder string in the video stream's tags. Run ffprobe -show_streams <file> and look at the video stream's tags.encoder. A value like Lavc60.31.102 libx264 (or any Lavc60.x.x revision) is consistent with Sora 2's encoding pipeline. This signal is destroyed by re-encoding but survives -c copy remux, which is what most casual download tools do.
5. Check container timestamps. Sora 2 zeroes CreateDate and ModifyDate in the QuickTime metadata. If both are zero in addition to the other Sora 2 markers, that's another confirmatory signal. Many tools zero timestamps; this isn't dispositive on its own.
6. Check the corner for residual logo or inpainting artifacts. An unmodified Sora 2 export carries a ghost-icon logo and the "Sora" text in the bottom-left. Removal artifacts (slight blurring, inpainting halo) in that specific location are themselves a signal.
7. Use a frame-level AI-content detector for confirmation. Sora 2 has known motion-trajectory and physics-approximation patterns. Sightengine, DeepGuard, and other AI-content detectors run on visual analysis rather than metadata. Combine with the metadata signals above for the highest-confidence identification.

The honest conclusion: post-manifest-strip, no single metadata signal is conclusive. A combination of Sora-default specs, contextual reporting, and visual analysis is what investigators should rely on. The cryptographic provenance OpenAI invested in is, in practice, available only inside the closed room of the unmodified file. The moment that file enters any platform pipeline, the signal goes silent.

The work in this post is reproducible. We documented every tool, every command, every sample.

Tools. ExifTool 13.58 (canonical metadata extractor), ffmpeg 8.1.1 and ffprobe 8.1.1 (the FFmpeg project's encoding and introspection tools), c2patool 0.26.56 (the C2PA reference implementation maintained by Adobe and the Content Authenticity Initiative). All three are open source and free.

Sample. sora.mp4 from the Content Authenticity Initiative's example-assets repository at github.com/contentauth/example-assets/videos/sora.mp4. SHA-256: 7d750b0c9cb9c1ab162a067cf128213590da2b858f2e1de336190427a77f75cf. 5,278,370 bytes. The published manifest reference (videos/manifests/sora.json) was used to cross-check c2patool's extraction. This is the canonical Sora reference asset and as of May 2026 it is the only public Sora sample distributed by an authoritative source.

Re-encoding pipelines. Five ffmpeg pipelines were run: a YouTube-style high-profile re-encode at CRF 23, a Twitter-style main-profile re-encode at CRF 26 with adjusted audio, a pure -c copy remux with +faststart, a vanilla -c copy remux preserving the original moov ordering, and a Discord-style downscaled re-encode at 480p. Each output was extracted with all three tools.

Cross-checks against published empirical work. Truescreen's April 2026 "C2PA Standard in 2026" report and AIIP Protection's "Why C2PA Watermarks Fail on Social Media" (also April 2026) both empirically confirmed that Instagram, X, LinkedIn, TikTok, and Facebook strip C2PA manifests at effectively 100% rate during upload processing. Our ffmpeg simulation matches their real-platform tests because the underlying behavior is identical: container rewriting without JUMBF preservation.

File X-Ray parser extension shipped with this post. Our videoParser.ts previously did not detect C2PA manifests in video files. We extracted the C2PA detection logic that has lived in imageParser.ts since the /c2pa post into a shared module at src/parsers/common/c2paDetect.ts and wired the video parser to use it. Runtime-tested: on the unmodified sora.mp4 sample the parser correctly surfaces C2PA Content Credentials present, claim generator "OpenAI Sora", signing organisation "OpenAI", and AI-generated flag true. On all five re-encoded variants from the survival test (youtube, twitter, remux, remux-vanilla, discord) the parser correctly returns C2PA absent with no false positives. For any unmodified Sora 2 (or Veo 3, or Runway, or other C2PA-signed AI video) dropped into filexray.orygn.tech/scan, the same surfaces appear. For any re-encoded copy the parser reports nothing at all, which is the honest outcome: a stripped manifest is indistinguishable from a file that never carried one, so there is no finding to show.

Findings replicated across 10 OpenAI samples and 3 vendors. The contentauth repo has the single canonical Sora reference asset, but a public Hugging Face dataset (YF789/sora2) preserved a comparison study including Sora 2 standard, Sora 2 Pro, Veo 2-fast, Veo 3.1, and Vidu Q2 outputs across multiple prompt categories (Accessories, Clothing tryon, Footwear living, Jewelry). We pulled six additional Sora 2 standard samples (Belts, Luggage, Sunglasses, Tops, Boots), three additional Sora 2 Pro samples (Belts, Tops, Boots), one Veo 2-fast sample, one Veo 3.1 sample, and one Vidu Q2 sample. We ran our parser, c2patool, and ExifTool on every one. The Sora 2 results: every single sample (N=10 across standard and Pro variants spanning four content categories and a 4.3 MB to 15 MB size range) shows the identical pattern: JUMBF box present, claim_generator "Sora", c2pa-rs SDK 0.67.1, a leaf certificate naming OpenAI, issued by the Truepic Inc. CA, IPTC trainedAlgorithmicMedia assertion. Sora 2 standard and Sora 2 Pro use identical C2PA infrastructure; the Pro tier did not get a more advanced provenance setup, only a different model behind the API. The 10-sample replication confirms the structure described above is the Sora 2 production signature, not a one-off artifact.

For technical background on the AI-image side of provenance, see /c2pa. For document residue forensics in the same family, see /docx. For the byte-level methodology, see /leaks.