C2PA Content Credentials in AI Images

TL;DR: C2PA Content Credentials can show who signed an AI image, which tool created it, what AI-related actions were declared, and whether the signed file has changed. In our August 17, 2026 test, all three GPT Image 2 outputs and all three Gemini 3.1 Flash Image edit outputs returned by LinkModel contained signed C2PA manifests with valid signatures and content bindings. That is strong provenance evidence, but not a truth score or, by itself, proof of an exact model ID.

AI image provenance becomes useful when it survives contact with a real API workflow. We generated six PNG files through LinkModel CLI, inspected them with the official open-source c2patool, and checked the signatures against the C2PA Trust List. The credentials identified Microsoft and Google signing entities, named the generation tools, declared AI-generated media, and—in the Gemini edit samples—recorded the source image as an ingredient.

What is C2PA metadata in an AI image?

C2PA stands for the Coalition for Content Provenance and Authenticity. Its open standard defines how media can carry cryptographically verifiable provenance information. The consumer-facing name for that information is Content Credentials.

A credential is more than a loose EXIF tag. A C2PA manifest combines:

• Assertions about creation, editing, ingredients, or AI use.
• A claim that references those assertions.
• A digital signature made with the signer's credential.
• A content binding, usually a cryptographic hash, that links the manifest to the asset bytes.

The C2PA 2.4 specification deliberately avoids judging whether provenance is “good” or “bad.” It gives validators a way to check that statements are well formed, signed, associated with the asset, and free from unauthorized modification. People and applications still decide whether they trust the signer and the statements.

That distinction makes C2PA useful for AI products. Instead of asking an unreliable detector to guess how pixels were made, a product can inspect a signed declaration attached during creation or editing.

How does C2PA work?

The shortest useful mental model is statement + signer + binding.

1. A claim generator creates assertions such as “created with AI” or “this source image was an input.”
2. It hashes the assertions and binds the manifest to the output asset.
3. A signing service signs the claim with a certificate.
4. A validator recomputes the hashes, validates the signature and time stamp, and evaluates the certificate against its configured trust anchors.

If the image bytes or signed assertions change, validation can surface the mismatch. The C2PA security model also states an important limit: C2PA can detect tampering with a present manifest, but it cannot prevent someone from removing the manifest entirely.

This is why provenance should be treated as positive evidence. A valid credential is meaningful. A missing credential is inconclusive because an app, social platform, screenshot, or conversion step may have stripped it.

What can C2PA prove—and what can it not prove?

The exact-model boundary matters. In our GPT Image 2 samples, the credential named Azure OpenAI ImageGen, not the literal model ID gpt-image-2. The API request and task record establish which LinkModel model was called; the signed credential independently ties the returned bytes to Microsoft's image-generation infrastructure and its AI declaration. Together, those signals are stronger than a filename, but the C2PA manifest alone does not name the exact model.

What did GPT Image 2 and Gemini 3.1 credentials reveal?

We generated three samples per model with lkm 0.1.5 and validated them with the official c2patool 0.27.15. GPT Image 2 used text-to-image. The current LinkModel schema for Gemini 3.1 required an input image, so that model was tested through image editing.

Across all six files, c2patool validated the claim signatures, time stamps, assertion hashes, and asset content bindings. A spot check also redownloaded one temporary CDN asset per model; each was byte-identical to the file saved by LinkModel CLI. On this path, the delivery layer did not re-encode the images or strip their C2PA data.

These findings align with OpenAI's provenance documentation, which says supported OpenAI images include C2PA metadata and SynthID, while coverage can vary by product, model, export path, file type, and creation date. Google's Gemini image documentation identifies gemini-3.1-flash-image as Nano Banana 2 and states that generated Gemini images include SynthID.

What did the GPT Image 2 signer show?

The active manifests attributed the signature to Microsoft Corporation and identified the software agent as Azure OpenAI ImageGen. The action assertion described the asset as generated with AI and used the IPTC digital source type trainedAlgorithmicMedia. Another signed action named Microsoft Responsible AI Provenance as the watermarking software agent.

This does two useful things for a downstream product. First, it makes the provider path inspectable. Second, it binds that provider declaration to the exact file that the application received. A copied filename or JSON field cannot provide the second property.

What did the Gemini 3.1 ingredient show?

The Gemini 3.1 Flash Image edit outputs were signed by Google Media Processing Services, with Google Generative AI named in the creation assertion. The credential also declared an imperceptible SynthID watermark.

More importantly for editing workflows, all three manifests contained a c2pa.ingredient.v3 assertion with the relationship inputTo. In plain language, the output recorded that another image was an input ingredient. That gives asset-management and review systems a machine-readable way to preserve a source-to-result relationship instead of treating every generated file as an isolated blob.

Does “Trusted” mean the image is more authentic?

No. C2PA separates cryptographic validity from certificate trust.

Our test produced a trust-store difference between the two signing chains, but that is not a useful model-quality comparison. It reflects whether a particular validator configuration could chain a credential to its current trust anchors. The specification explicitly allows custom trust stores, and trust-list membership can change independently of a file's valid signature and content binding.

The safe product design is to expose the dimensions separately: manifest present, signature valid, asset unchanged, signer identity, declared actions, and trust-chain result. Collapsing all of them into one green “authentic” badge hides information users need.

How can you verify C2PA metadata yourself?

Install the official open-source c2patool, generate an image, and inspect the saved file.

# Generate through LinkModel CLI
lkm image gen \
  "A cobalt-blue ceramic teapot on a neutral background, no text" \
  --model gpt-image-2 \
  --quality low \
  --size 1024x1024 \
  --out ./c2pa-test \
  --json
 
# Read the active manifest and validation results
c2patool ./c2pa-test/output.png --info

To evaluate certificate trust with the public C2PA list, configure the trust anchors and allowed list documented by the tool:

export C2PATOOL_TRUST_ANCHORS="https://raw.githubusercontent.com/c2pa-org/conformance-public/refs/heads/main/trust-list/C2PA-TRUST-LIST.pem"
 
c2patool ./c2pa-test/output.png trust

Do not stop at a single status word. Check these fields in order:

1. An active_manifest exists.
2. The claim signature validates.
3. The data hash or content binding matches the current asset.
4. The signer and claim generator are the entities you expected.
5. AI creation, editing, watermark, and ingredient assertions match your workflow.
6. The trust-chain result is evaluated under a trust policy you understand.

For a no-code inspection, the Content Credentials Verify tool presents manifests visually. Uploading a file to any third-party verifier is still a data transfer, so use a local validator for confidential assets.

How should an API pipeline preserve Content Credentials?

Verification only helps if the credential survives delivery. Treat the original output as an immutable source asset and derive display variants from it.

• Store the original response bytes before optimization.
• Hash the original file and keep the generation task ID beside it.
• Run C2PA validation at ingestion, not only when a dispute appears.
• Save structured fields such as signer, claim generator, AI declaration, ingredient relationships, and validation results.
• Test every resize, CDN, transcoder, editor, upload, and download path for credential preservation.
• Keep the original even if a delivery format strips metadata.
• Re-sign edited assets when your workflow and credential policy support it.

A practical audit record joins three layers: API evidence (model ID, task ID, timestamp), asset evidence (hash and immutable original), and provenance evidence (C2PA manifest and validation output). This combination is more defensible than any one layer alone.

How is C2PA different from SynthID, EXIF, and AI detectors?

These approaches are complementary. OpenAI's guidance makes the same architectural point: metadata can carry more context, while embedded watermarks may be more durable through some transformations. A production policy can check signed provenance first, inspect an embedded watermark when supported, and use detectors only as a lower-confidence signal.

Frequently asked questions

What does C2PA stand for?
C2PA stands for the Coalition for Content Provenance and Authenticity. It publishes an open technical standard for cryptographically verifiable media provenance.

Can C2PA prove the exact AI model that made an image?
Not always. C2PA can identify the signer, claim generator, and declared actions, but it proves an exact model ID only when that identifier is included in the signed manifest.

Can C2PA metadata be removed?
Yes. C2PA can detect unauthorized changes while a manifest is present, but screenshots, conversions, editors, and platforms can remove metadata, so absence is not proof that an image was not AI-generated.

What does signingCredential.untrusted mean?
It means the validator could not chain the signing certificate to its configured trust anchors. It does not by itself mean that the cryptographic signature failed or that the image is fake.

How do I verify C2PA Content Credentials?
Use LinkModel CLI to generate the file, then c2patool locally or the Content Credentials Verify website to inspect it. Check the manifest, signature, content binding, signer, assertions, and certificate trust result as separate signals.

The bottom line

C2PA does not tell you what to believe. It gives your application signed, inspectable evidence about where an asset came from, what was declared about its creation, and whether the signed file still matches those claims. Our LinkModel test found that both GPT Image 2 and Gemini 3.1 Flash Image outputs carried that evidence; the next step is to preserve it and surface each validation dimension honestly.

Methodology: six PNG samples generated through LinkModel and checked with c2patool 0.27.15 on August 17, 2026. See the C2PA specification for normative behavior.