On 1 October 2026, Section 15 of Connecticut's Senate Bill 5 — the CART Act — begins requiring producers of generative AI systems with more than one million users per month to include provenance data in audio, image and video content their systems create or materially alter, and to make that data accessible to consumers. Text is excluded. The statute points to the Coalition for Content Provenance and Authenticity as the source of acceptable methods, and it asks that the provenance data be difficult to tamper with.

It also contains the phrase “commercially and technically reasonable.” Every law-firm client alert published since the bill was signed in June quotes those four words. They do not all put them in the same place, and where they sit determines how much of the obligation survives contact with an engineering team.

What provenance data is, at the level that matters

The statute defines provenance data functionally: data embedded in digital content for the purpose of determining its authenticity, origin or modification history. In practice, for anyone shipping a consumer generative feature at scale, that means a C2PA manifest.

A C2PA manifest is a set of signed assertions bound to an asset. The assertions describe what made the content and what has happened to it since. The binding is cryptographic: a hash over the asset's pixels or samples, signed with a credential that a verifier can check against a trust list. Two properties follow from that design, and they are frequently confused.

  • You cannot forge one. Altering the content breaks the hash; altering the assertions breaks the signature. A manifest that verifies is strong evidence about origin.
  • You can trivially remove one. A manifest is metadata travelling alongside the bits. Nothing about the signature makes it sticky.

That distinction has a name worth using: C2PA gives you tamper-evidence. The statute asks for tamper-resistance. Those are not the same property, and the gap is not an implementation detail that a vendor will close next quarter. It is what the technology is.

What survives, and what a screenshot does

A manifest survives operations that preserve the file and its metadata container: a plain copy, a download, a transfer between systems that carry the metadata through. It survives editing by a C2PA-aware tool, which appends a new signed assertion describing the edit rather than invalidating what came before. That appending behaviour is the standard's central design idea and it works.

It does not survive much else. A screenshot is a new capture: the manifest is not copied because nothing is copied, only re-rendered pixels. A re-encode by a tool that does not implement C2PA drops the metadata or breaks the binding. Many platform upload pipelines strip metadata as a matter of course — to save bytes, and because metadata is a privacy liability. A crop, a colour adjustment or a format conversion performed by any non-participating editor ends the chain.

So the practical reach of a provenance mandate is bounded in a specific way. Where a manifest is present and verifies, a viewer learns something reliable. Where it is absent, they learn nothing at all, because absence is indistinguishable across three cases: the content is not synthetic; the content is synthetic and the manifest was stripped; the content is synthetic and came from a provider the statute does not cover. A law can require marking. It cannot make the absence of a mark mean anything.

Where the four words sit — and why we can't tell you for certain

Two readings of the qualifier circulate in the alerts published since June, and they differ materially.

On the first reading, the qualifier attaches to method: covered providers must use commercially and technically reasonable methods, such as those established by C2PA, to make provenance data difficult to tamper with. The duty to embed is unqualified; only the engineering choice is subject to reasonableness.

On the second, it attaches to the duty: covered providers must embed tamper-resistant provenance data to the extent commercially and technically reasonable. Here the obligation itself bends, and a provider who documents that embedding was not reasonable in a given pipeline has an argument for not doing it.

The difference is the entire compliance question. Under the first reading you have to mark, and you argue about how. Under the second you can argue about whether. DrafterDaily could not resolve the placement against the enrolled text: the Connecticut General Assembly's posted bill document did not return readable text on retrieval, and the figures and wording above therefore rest on law-firm client alerts — reliable summaries, but summaries. Both readings come from firms describing the same statute. Anyone whose compliance posture depends on the second reading should have counsel confirm it against the enrolled bill rather than an alert.

No enforcement guidance exists yet to settle it either. The obligation is twelve days old at the point it becomes live, with nothing on the record about how the state intends to read its own qualifier. There are also privacy and trade-secret carve-outs in the section, which narrow it further in ways that have not been tested.

Why one million users, and what that threshold exempts

The obligation attaches to consumer-facing systems above one million monthly users. That is a compliance-cost line rather than a harm line, and it is worth being explicit about what it does and does not catch.

Above the threshold, a provider is covered regardless of how little synthetic media it generates. Below it, a provider is exempt regardless of how much. And the threshold exempts, as a class, every self-hosted deployment and every user running open-weight image, audio or video models locally — a set with no monthly-user count at all in the relevant sense, and one that produces a large share of the unmarked synthetic media actually in circulation. The duty lands on the parties who are easiest to identify and serve process on. Those are not the same parties as the ones generating the most unmarked output.

Set against other regimes, the threshold is the distinguishing feature rather than the marking duty. The EU AI Act's Article 50 transparency obligations, which began being enforced on 2 August 2026, apply to providers of generative systems without a user-count floor of this kind. Colorado, whose Attorney General is separately writing chatbot-safety rules that the underlying statute did not require, has taken a different route entirely and imposed no provenance mandate. Connecticut's choice is narrower than the EU's and more prescriptive than Colorado's, and the one-million line is where that tradeoff is expressed.

What to check before 1 October

  • Whether your generation path writes a manifest at all, and whether it is signed with a credential in a published trust list rather than a self-signed test certificate.
  • Whether your own delivery pipeline strips it. Resizing, transcoding and CDN transforms are the usual culprits, and they are frequently invisible to the team that added the manifest.
  • Which of your surfaces count toward the monthly-user threshold, and whether you can evidence the count if asked.
  • Whether your consumer-accessibility path exists — the section requires the data be accessible to consumers, not merely embedded, and a manifest nobody can inspect satisfies half the duty.
  • Whether your documented reason for any gap is written down now rather than reconstructed later, whichever reading of the qualifier turns out to govern.

The honest summary is that Connecticut has mandated a technology that does one thing well and the adjacent thing not at all. Signed provenance makes claims about origin checkable. It does not make synthetic content traceable once it leaves the system that made it. A statute can require the first. The second is not available to be required.