California's AI Transparency Act Is Live: C2PA Explained

On August 2, California's AI Transparency Act became operative. Almost none of you have to comply with it. Almost all of you will break it anyway, because the provenance metadata the law now requires gets deleted by ordinary image tooling, and probably by yours.

Here's what actually shipped, how the underlying format works, and the one method call most Node image pipelines are missing.

What became law on August 2

The law is SB 942, passed in 2024, then amended by AB 853, signed October 13, 2025. AB 853 pushed the start date from January 1, 2026 to August 2, 2026, lining it up with the EU AI Act so teams could do one compliance pass instead of two.

It binds a "covered provider": anyone who creates, codes, or otherwise produces a generative AI system with more than 1,000,000 monthly users that is publicly accessible in California. That threshold does most of the work. Running a side project or a Series A product on somebody else's model API does not make you a covered provider. OpenAI, Google, Adobe, and Meta are.

Covered providers now owe three things:

• A free, publicly accessible AI detection tool. Anyone can upload a file, paste a URL, or call an API and learn whether that system produced the content.
• An optional manifest disclosure, meaning users get the choice to stamp a visible "AI-generated" marking on output.
• A mandatory latent disclosure. Every generated image, video, and audio file carries embedded metadata naming the provider, the system and its version, the creation time, and a unique identifier.

Two enforcement details worth knowing. If a covered provider licenses its system to a third party and finds that licensee has switched latent disclosures off, it must revoke the license within 96 hours of discovering it. And violations run $5,000 each, with every day of non-compliance counting as its own violation. The state attorney general and city and county attorneys enforce it. There is no private right of action, so your users cannot sue you over this.

What a latent disclosure actually is

The statute never says "C2PA". It says providers must use "widely adopted specifications adopted by an established standards-setting body." In practice that means C2PA Content Credentials, because it is the only thing that fits and it is where the EU AI Act's Article 50 work is heading too.

C2PA is simpler than the branding suggests. Three layers:

• Assertions are individual facts. Who made this, which device or software, what edits happened, whether AI was involved.
• A claim bundles assertions together with hashes that bind them to the actual bytes of the file.
• A signature signs the claim with an X.509 certificate, the same machinery behind HTTPS.

Bundle those together and you have a manifest, which rides inside the file.

Verification happens locally. A verifier checks the signature and the hash without calling back to whoever signed it, so it works offline and does not leak who is inspecting what.

You can look at a real one right now. c2patool is the official CLI:

brew tap contentauth/tools
brew install c2patool
 
# prints the manifest as JSON to stdout
c2patool photo.jpg

No manifest and it tells you so. If there is one, you get the provider, the system, the timestamp, and the chain of edits that led to this file.

The part that will actually bite you

Now the gap between the law and the real internet. A C2PA manifest lives in the file's metadata block. Nearly every image pipeline in production deletes metadata by default, deliberately, because metadata is bytes and bytes cost bandwidth.

sharp is the clearest case, since it sits in a huge share of Node apps. Straight from its docs: "By default all metadata will be removed."

import sharp from "sharp";
 
// Silently drops the C2PA manifest. Also EXIF, ICC, XMP, IPTC.
await sharp("upload.jpg")
  .resize(1200)
  .toFile("thumb.jpg");
 
// Keeps all of it.
await sharp("upload.jpg")
  .resize(1200)
  .keepMetadata()
  .toFile("thumb.jpg");

keepMetadata() arrived in sharp 0.33.0. There is also withMetadata(), which keeps most metadata and attaches a web-friendly sRGB profile, plus the narrower keepExif() and keepIccProfile() if you want finer control.

The same trap sits in your CDN. Any image optimizer that re-encodes on the fly, and that is most of them, destroys provenance unless it has been built to carry it through.

What 2027 and 2028 add

The law rolls out in phases, and the later ones are where this stops being someone else's problem.

From January 1, 2027, large online platforms have to detect provenance data, give users an interface that shows whether content carries it, let them inspect it, and stop stripping it "to the extent technically feasible." A large online platform is a public-facing social media, file-sharing, or mass messaging platform, or a standalone search engine, with more than 2,000,000 unique monthly users over the preceding 12 months. That "technically feasible" phrase is carrying a lot of weight, and it is the first thing lawyers will reach for.

From January 1, 2028, capture device makers join in. Cameras, phones with built-in cameras or microphones, and voice recorders must offer latent disclosure in captured content, embedded by default.

Put the phases together and the intent is clear. Provenance should flow from the camera, through editing tools, out to the platform, and still be readable at the end. The weak link in that chain today is the middle, which is us.

Metadata alone was never going to hold

Anyone who has watched an image go through three chat apps knows how this ends. Metadata is fragile by design, and a screenshot defeats it completely.

That is why the serious implementations pair the manifest with a soft binding: an invisible watermark plus a perceptual fingerprint of the content itself, which survives re-encoding, resizing, and screenshots. Google's SynthID works this way. The watermark says "this came from us" even after every byte of metadata is gone, and the manifest supplies the detail when it is still intact. Neither half is sufficient on its own, which is roughly the state of the art.

What to do this week

None of this requires a lawyer unless you are genuinely near that million-user line. It does require about an hour:

1. Grep for your image and audio processing calls. sharp, ImageMagick, Pillow, whatever resizes uploads. Check what each one does to metadata, and assume it deletes everything until proven otherwise.
2. Keep the signed original. Derivatives can be regenerated, a discarded manifest cannot.
3. If you display user-uploaded media, read the manifest and surface it. c2patool on a sample of your uploads will tell you how much provenance you are already receiving and throwing away.
4. If you ship a generative feature that is anywhere near a million monthly users in California, hand this to counsel now rather than in December.

The compliance burden here lands on a handful of very large companies. The engineering burden lands on everyone who touches a file in between, and that part starts with one method call you probably have not made yet.

If you are thinking about the security side of shipping AI features, prompt injection is still the risk that should worry you more than this one. And for another look at a web standard that reads well on paper and meets a messier reality in production, see WebMCP in Chrome.