How is embedded media provenance different from EXIF or file metadata?

EXIF and file headers are stripped by most platforms on upload — the first thing a social network or messaging app does is rewrite the file. Embedded provenance lives in the pixels themselves as a recoverable strip, so it survives re-encoding and redistribution. Metadata describes the file; the strip is part of the image.

Is this a C2PA-certified workflow?

No. Media Provenance embeds a verifiable origin strip — model, session, and prompt hash — in a format verified on your infrastructure. It is compatible in spirit with content-credential thinking, but it carries no C2PA certification, badge, or standards claim. Your auditors verify the strip, not a third-party registry.

What survives re-encoding, cropping, and screenshots?

The strip is designed to survive platform re-encoding, resizing, and moderate cropping — the transforms that cover most real redistribution. Heavy destruction (severe crops, screenshots of screenshots) may degrade it; the verifier reports integrity rather than silently passing. Pair the strip with a hash-anchored record so origin is provable even when the pixels are damaged.

Who is the provenance for — our team, the public, or both?

Both, in layers. Your team gets the full record: model version, session, prompt hash, and operator. External viewers get what your policy discloses — typically an origin attestation without internal details. Disclosure policy is configured on your infrastructure, so nothing internal leaks by default.

What does deployment look like on our infrastructure?

The embed step runs in your generation pipeline — next to the model endpoint or render job — and verification runs wherever you need it: editorial desk, trust-and-safety queue, or an offline lab. No media leaves your network for embedding or verification. A no-signup studio experiment runs against an isolated demo host so your team can try the flow before installing.

Media provenance — Guide

Synthetic media is cheap to produce and expensive to disown. When an AI-generated image shows up in a dispute, a news cycle, or a compliance review, the question is whether you can prove its origin from the file itself — not from a database entry or a platform label.

1. The problem: origin claims evaporate on upload

Your team generates an image — a product render, a marketing visual, a synthetic training sample, an illustrative exhibit. At generation time you know exactly what made it: which model, which version, which prompt, which operator, which session. An hour later that file has been downloaded, reposted, recompressed, cropped for a slide, and forwarded through a messaging app. Every one of those steps strips metadata. What arrives at the dispute is a bare grid of pixels with no history attached.

Three common answers fail at exactly this point:

File metadata. EXIF, XMP, and sidecar JSON are removed by default on most platforms. A recipient cannot verify what was stripped, and an adversary strips deliberately.
Platform labels. “AI-generated” badges live on the platform surface. Download the file and the label stays behind. The asset and the claim travel separately — so they separate.
Internal databases. A registry entry that says “we generated file X on Tuesday” helps only if you can prove the file in front of you is file X. Without a content-bound link, the database is hearsay about a different object.

The cost lands in predictable places. Marketing cannot confirm which variant actually shipped. Legal cannot bind a generated exhibit to its generation record. Trust-and-safety cannot distinguish your synthetic content from a third-party fake of similar content. Compliance cannot demonstrate provenance for AI-generated material under emerging disclosure expectations.

The requirement: origin information must travel in the media, recoverable from the pixels with no platform cooperation and no network lookup.

2. What good looks like on your infrastructure

A workable provenance design has four properties:

Embedded at generation. The origin strip — model identity, session, prompt hash — is written into the image by the generation pipeline itself, before the file ever reaches a CDN, DAM, or social account. Late stamping misses internal forks.
Recoverable from pixels. Verification needs only the file and your verifier. No registry lookup, no vendor API, no surviving metadata required.
Bound to content by hash. The strip references a hash of the original pixels, so a verifier can tell whether the image was altered after embedding — and the record is anchored so the claim is timestamped.
Disclosed by policy. Internal detail (full prompts, operator identity) stays internal; external parties see only the attestation your policy permits. One strip, layered disclosure.

Everything here runs on your infrastructure. Embedding happens in your pipeline, verification runs on your hosts, and no media is sent to a vendor for either step.

3. How embedded provenance works — generate, embed, verify

Generate

The generation event produces the image plus a record: model name and version, session or job identifier, a hash of the prompt, the operator or service identity, and a timestamp. Keep prompts themselves out of the strip — store a hash and keep the text in your own systems. Short payloads survive redistribution better than long ones.

Embed

Media Provenance writes that record as an imperceptible strip into the image carrier and returns an embed receipt: content hash before and after, strip parameters, key identifier. Immediately anchor the receipt hash with Hash Anchor so the claim “we generated this, then” is timestamped independently of your asset store. For proprietary artifacts distributed to specific recipients, add a Confidential IP Watermarking layer with per-cohort payloads so a leaked copy also maps to a distribution cohort.

Verify

Any holder of a suspect file submits it to your verifier — on your network or offline. The verifier extracts the strip, checks it against the anchored receipt, and reports origin plus an integrity verdict: intact, degraded-but-attributable, or unverifiable. External verifiers receive the manifest and anchor receipt; they confirm the hash chain without needing your keys or your originals.

4. The components

One primary module, two natural companions. Adopt incrementally.

5. How to verify it — strips, hashes, and disclosure policy

Embed receipt. Key identifier, timestamp, payload, and content hash before and after embedding. Proves what was marked and when.
Anchor receipt. The hash-anchor proof binding the manifest to time. Proves you are not backdating the claim.
Verifier report. Extraction result plus integrity verdict — intact, degraded, or unverifiable — never a silent pass.
Disclosure policy. A written rule for what each audience sees: internal teams see full records; external parties see attestations. Review it the way you review access control.
Robustness baseline. Run each template through your actual pipeline — recompress, crop, transcode — once, and record detection rates at your chosen strength before relying on the strip.

6. Buying checklist

☐ Embedding runs in your generation pipeline — no media sent to a vendor
☐ Verification needs only the file — no network lookup, no surviving metadata
☐ Strip carries model, session, and prompt hash — prompts stored as hashes, not plaintext
☐ Embed receipts are hash-anchored with independent timestamps
☐ Verifier reports integrity verdicts instead of silently passing degraded strips
☐ Layered disclosure: internal detail stays internal by policy
☐ Robustness baseline measured against your real transforms before reliance
☐ Studio experiment available without signup — isolated demo host, try before installing
☐ No C2PA certification or standards claims — verification speaks for itself

7. Common anti-patterns to avoid

Metadata as the whole plan. If your provenance dies the first time a file passes through a messaging app, it was never provenance.
Stamping at the CDN edge. Late embedding misses every internal fork and confuses key ownership. Embed where the pixels are born.
Plaintext prompts in the strip. Prompts are often sensitive or proprietary. Hash them; keep the text in your own store.
One mark doing two jobs. Attribution (what generated this) and distribution tracing (who received this copy) have different payload and robustness needs. Use provenance for the first, watermarking for the second.
Trusting the badge. A platform label is a claim about the platform's view, not a property of the file. Verify from the pixels.