C2PA and Content Credentials in FLUX outputs
Last updated: July 30, 2026
Black Forest Labs (BFL) embeds C2PA Content Credentials into images and videos generated by the FLUX model family. This document explains what Content Credentials are, how BFL implements them, what information they contain, how you can verify them, and what you should know about their limitations.
Content Credentials are a standardised, open-source mechanism for attaching tamper-evident provenance metadata to digital media. They are defined by the Coalition for Content Provenance and Authenticity (C2PA), a cross-industry standards body. To learn more about C2PA see https://c2pa.org.
What are Content Credentials?
A Content Credential is a digitally signed record that is cryptographically bound to an image file. It travels with the file and can be inspected by any C2PA-compatible tool or platform.
Key concepts
Term | Meaning |
|---|---|
Manifest | The signed data package attached to the file. Contains one or more assertions. |
Assertion | An individual claim within the manifest (e.g. “this image was generated by an AI model”). |
Claim | A summary record within the manifest that is cryptographically signed by the issuing party. |
Hard binding | A cryptographic hash of image or video pixels, ensuring the manifest cannot be silently detached or transferred to a different image. |
Soft binding | An invisible watermark that links the image to its credentials even if the file container is stripped or re-encoded. |
Provenance chain | A linked sequence of manifests showing the history of a file across multiple creation or editing steps. |
Where BFL attaches credentials
Content Credentials are attached to all images generated through:
The BFL API (api.bfl.ai), across all FLUX model endpoints that return a final image
The Developer Playground (https://dashboard.bfl.aii)
BFL’s hosted inference integrations where BFL controls the output pipeline
Note: Outputs such as videos and images generated through self-hosted or on-premise deployments of open-weight FLUX models are outside BFL’s signing infrastructure. BFL does not attach or validate Content Credentials for outputs produced by third-party inference environments. |
How credentials are attached
BFL implements C2PA at the output pipeline level. After inference completes and a final image is produced, the signing service:
Computes a cryptographic hash (SHA-256) of the image or video pixel data.
Constructs a C2PA manifest containing the assertions listed in Section 3.3.
Signs the manifest using BFL’s X.509 signing certificate, issued under a trusted Certificate Authority.
Embeds the signed manifest into the image file’s metadata (JUMBF block for JPEG and PNG; XMP for formats that do not support JUMBF natively).
Optionally embeds a soft-binding watermark to enable recovery of credentials after format stripping.
Information in the credential
Assertion | What it records |
|---|---|
AI generative | The media was created using generative AI. |
Claim generator | Black Forest Labs and the signing software version. |
Created action | The creation event and UTC timestamp. |
Model metadata | The FLUX model name and version. |
Hard binding | The cryptographic hash binding the credential to the media. |
Information not recorded
Text prompts or negative prompts.
API keys or user-account identifiers.
IP addresses or request metadata.
Intermediate outputs, including intermediate latents.
Credentials contain no personal data attributable to the requesting user.
How to verify an output
Save the original file returned by the supported BFL product or API.
Open Content Credentials Verify or another compatible C2PA tool.
Review the signer, assertions, validation status, and any post-signing changes.
A successful verification confirms that the credential was signed by a recognized certificate, the media matches its signed hash, Black Forest Labs is identified as the signer, and the media was declared AI-generated at signing time.
Compatible verification tools include Content Credentials Verify (web), the open-source c2patool CLI and c2pa-rs / c2pa-js SDKs, and the Leica Verify mobile app (iOS and Android).
Verification failures
Result | What it means |
|---|---|
No credential found | The pathway may not support credentials, or a later service removed the metadata. |
Hash mismatch | The media changed after signing through editing, cropping, compression, or watermarking. |
Certificate validation failure | The certificate expired, was revoked, or its chain could not be validated. |
Manifest parse error | The metadata is corrupted or uses an unsupported C2PA version. |
Untrusted signer | The signer is not yet recognized by the verifier’s trust list. |
Preserving credentials
Social platforms and content-management systems may strip or modify metadata. Keep an original file, check whether downstream services preserve C2PA data, and test every cropping, compression, re-encoding, transcoding, and export step. Soft binding improves resilience but cannot guarantee recovery.
Open-weight and self-hosted models
FLUX.1 [dev] and FLUX.1 [schnell] can run outside BFL’s hosted environment. For outputs created outside BFL-operated pipelines:
BFL cannot guarantee that Content Credentials are attached.
Deployers are responsible for applicable content-marking obligations.
BFL signing certificates are not available for third-party use.
Operators requiring C2PA signing must run their own signing infrastructure and obtain an appropriate signing certificate.
Developer guidance
Supported BFL API outputs include their credential in the returned media binary. Preserve the original response bytes where possible; re-encoding or metadata stripping can remove the embedded manifest.
npm install -g c2patool
c2patool image.jpg --output-manifest-json manifest.json
c2patool image.jpgDevelopers can also inspect credentials using the current c2pa-js libraries or c2pa-rs SDK.
Limitations
Embedded manifests can be removed.
Editing after signing can break the hard binding.
A valid credential does not establish safety, lawfulness, appropriateness, or licensing.
Credentials do not disclose prompts.
Verification depends on the verifier’s trust list.
Self-hosted FLUX inference is outside BFL’s signing infrastructure.
Further resources
This documentation is informational and does not constitute legal advice.