C2PA Provenance Rules for AI Companies

On August 11, 2026, the Coalition for Content Provenance and Authenticity published an updated implementation guide for Content Credentials, alongside a companion white paper titled Use of Content Credentials to Identify Synthetic and Non-Synthetic Content. The publication landed nine days after Article 50 of the EU AI Act came into force, and in the same week Anthropic confirmed it would watermark Claude's text output and OpenAI's help center documentation on provenance signals made the rounds again in trade press. Taken together, these are not three unrelated news items. They are the same underlying question, answered from three different directions: how do you know whether the thing you are reading, viewing, or listening to was made by a machine, and what is anyone legally required to tell you about it?

For an organization building AI governance policy, that question has been theoretical for most of the last three years. It stopped being theoretical on August 2, 2026, when Article 50's transparency obligations took effect. This piece works through what actually changed in the C2PA standard, what OpenAI and Anthropic have and have not implemented, what the AI Act actually requires versus what vendors are volunteering, and what that gap means for anyone whose job is to answer the question "are we compliant" with something more substantial than a vendor's marketing page.

What C2PA is, and why the guide needed revising

The Coalition for Content Provenance and Authenticity, C2PA, is an open technical standard maintained by a cross-industry group that now counts more than 500 members and over 6,000 affiliates, including camera manufacturers, news organizations, and the major generative AI labs. The standard defines Content Credentials: cryptographically signed manifests that travel with a piece of media and record information about its origin and history. C2PA is deliberately broader than "AI content labeling." A photojournalist's camera can attach a Content Credential recording capture time, device, and location with no AI involved at all. The same manifest format that proves a photograph was captured by a Reuters photographer in a warzone is the format now being extended to prove, or disprove, that an image was generated by a diffusion model.

That dual purpose is worth sitting with, because it shapes how the standard has to be designed. A provenance system built only for AI content could get away with a single bit: generated, or not. A provenance system meant to also serve photojournalism, medical imaging, and legal evidence chains needs something closer to an audit trail: who touched this, when, with what tool, and what did they do. The new guide's changes move the AI-labeling half of the standard toward that richer model, and the gap between where it was and where it is now tells you something real about how immature AI content labeling still is, even as the underlying provenance infrastructure has had five years to mature.

The previous approach to labeling AI content under C2PA leaned on a single field and a handful of loosely specified assertions. It worked for the simplest case: an image generated end to end by a diffusion model, with no further edits, gets flagged AI-generated. It broke down almost immediately outside that simplest case. A human photograph retouched with an AI inpainting tool. A document drafted by a person and polished by an LLM. A video with one AI-generated background layer composited under human-shot footage. None of these fit a binary label, and the standard's previous vocabulary did not give implementers a principled way to describe them. That gap is exactly what the August 11 guide closes, and it does it through five specific mechanisms.

The five changes, and why each one matters on its own

First: digitalSourceType now draws from the IPTC vocabulary. This sounds like a small taxonomic housekeeping change, and in one sense it is, but the practical effect is larger than it looks. The International Press Telecommunications Council vocabulary is not something C2PA invented for this purpose. It is an existing, widely adopted classification scheme already used across photojournalism and publishing to describe how a piece of media came to exist: captured by a device, digitally created, algorithmically enhanced, composited, and so on. By anchoring digitalSourceType to that existing vocabulary rather than inventing a new one, C2PA gets interoperability for free. A newsroom's existing digital asset management workflow, built around IPTC metadata for decades, does not need a parallel AI-specific taxonomy bolted on top. It needs its existing categories extended to cover a few new source types that did not exist when the vocabulary was first written. That is a much smaller integration lift than a bespoke schema, and it is probably why this change shipped first in the list rather than as an afterthought.

The practical upshot for anyone consuming Content Credentials: digitalSourceType is now the primary signal for the coarse-grained question of provenance. Was this asset captured by a device, generated entirely by a model, or somewhere in between? That coarse signal sets the frame before you get into the finer-grained assertions the rest of the update introduces.

Second: the c2pa.ai-disclosure assertion. This is the change that does the most conceptual work. The previous binary label, AI-generated: yes or no, collapses a genuinely multidimensional fact into a single bit, and multidimensional facts collapsed into single bits tend to produce disputes at the edges. Is a photograph with AI-assisted noise reduction "AI-generated"? Is a paragraph a human wrote and then ran through a grammar-and-tone pass "AI-generated"? Under a binary scheme, reasonable people disagree, and the disagreement is not really about facts, it is about which of several true things the single available bit is supposed to represent.

The ai-disclosure assertion replaces that single bit with three separate pieces of information: model provenance (which model or system produced the content), scientific or professional domain (what kind of content this is and, implicitly, what standard of scrutiny it should get), and degree of human oversight (how much a human reviewed, edited, or directed the output before it was published). None of these three fields alone solves the disclosure problem. Together, they give an auditor, a platform, or a downstream reader enough structure to ask a more precise question than "was AI involved," which is close to a meaningless question by 2026, and instead ask "how much, doing what, checked by whom." That is the question governance frameworks actually need answered, and it is the question a binary label structurally cannot answer.

Third: Regions of Interest. This is the change that will matter most for anyone doing image or document forensics, and it is arguably overdue. Under the older approach, provenance information applied to a whole asset. A single AI-touched pixel in a thousand-pixel image and a fully AI-generated image got the same label if the file-level flag was binary. Regions of Interest let a Content Credential localize exactly which parts of an image, or which paragraphs of a document, or which segments of audio or video, were AI-generated or AI-modified. A photo editor who used generative fill to remove a background object from an otherwise unmodified photograph can now produce a credential that says exactly that: this region, this modification, everything else untouched. A legal brief drafted by a human with an AI-assisted paragraph inserted mid-document can carry a credential that flags that one paragraph rather than casting doubt on, or falsely clearing, the whole document.

The forensic value here is real, but so is the implementation burden. Region-level tracking requires tooling that most creative and publishing software does not yet have, and it requires that tooling to be maintained through every subsequent edit so the regions stay accurate rather than becoming stale metadata pointing at content that has since moved or been overwritten. This is the kind of feature that is easy to specify and hard to implement faithfully, and it is worth remembering when evaluating a vendor's claim to support it: supporting Regions of Interest in principle and maintaining accurate regions through a real editing pipeline are different claims.

Fourth: inputTo ingredient assertions. Here the standard reaches past labeling and into recipe documentation. An inputTo assertion records the prompts, reference images, seed values, and generation parameters that produced a piece of content, as verifiable provenance data rather than metadata a vendor can strip or omit at will. This is the assertion that turns Content Credentials from a passive label into something closer to reproducible research documentation. If your organization needs to answer "what exactly did we ask the model to produce, and can we show that record to an auditor, a regulator, or opposing counsel," the ingredient assertion is the mechanism that is supposed to make that answer possible.

It is also, notably, the assertion with the highest sensitivity-to-value ratio. A verifiable, signed record of the prompt behind a generated image is powerful for accountability. It is also, depending on the prompt, potentially revealing of business strategy, of a creative process someone would rather keep private, or of the fact that a "custom" piece of content was produced by a template prompt run a hundred times with minor variation. Organizations adopting tools that support inputTo assertions should understand this is a two-way disclosure: it documents provenance, and it also documents exactly what was asked for, in language a downstream party may read.

Fifth: the Actions assertion, with formal vocabulary for c2pa.created, c2pa.opened, and c2pa.edited. This is the mechanism that finally lets a Content Credential represent a real edit history rather than a single origin claim. Because an AI usage indicator can now be attached to each individual action in that history, a single file can distinguish a human-created original from a subsequent AI-assisted edit, and can do so at each step rather than collapsing the whole history into one label applied at export time. A photograph shot on a camera, opened and color-corrected by a human in Lightroom, then run through an AI upscaling pass before final export, can now carry a credential that records all three steps distinctly, with the AI involvement flagged only where it actually occurred.

Taken as a set, these five changes move C2PA from a standard that answers "was AI involved, broadly" toward a standard that can answer "what, specifically, did AI do, where, using what inputs, and how much human oversight sat on top of it." That is a meaningfully more useful answer for a compliance function, and it is also a meaningfully harder one for a vendor to implement completely. Which brings the conversation to what OpenAI and Anthropic have actually shipped against this expanded specification, as opposed to what the specification now makes possible.

What OpenAI has implemented, and what it has not

OpenAI's help center documentation, most recently updated to reflect its provenance commitments, describes a two-signal approach: C2PA metadata and SynthID watermarks, applied to images and audio generated through ChatGPT, Codex, and the OpenAI API. The documentation is candid about what each signal can and cannot do, which is worth taking at face value rather than reading past. C2PA metadata can carry richer information, including tool, timestamp, and origin history, but it can be stripped by platforms, editing tools, or file format conversions, because metadata is a property of the file container rather than the content itself. SynthID, an invisible watermark embedded directly in the generated media, is designed to be more durable through some transformations, including some forms of compression and re-encoding, but carries less contextual information than a full metadata manifest. OpenAI's own framing is that using both together, where technically feasible, is stronger than relying on either alone, which is a reasonable engineering position and also, not coincidentally, the same dual-signal design Anthropic has converged on independently.

For text output specifically, OpenAI's documentation states a goal rather than a shipped capability: "our goal is to expand provenance signals to all modalities including text," explicitly tied to commitments made under the European Commission's Code of Practice on Transparency of AI-generated Content. That is a meaningfully weaker statement than what the company has shipped for images and audio. As of September 2026, there is no publicly documented OpenAI text watermark in production, in contrast to Anthropic, which has now shipped one. This is not a minor asymmetry. Text is the highest-volume output modality for most enterprise AI deployments, and it is also the modality where the EU AI Act's transparency obligations bite hardest for the "AI-generated text on matters of public interest" category, which is a deployer obligation independent of what the underlying model provider marks. An organization relying on OpenAI's roadmap commitment as evidence that its own text-based AI outputs carry a provenance signal is relying on a stated intention, not a shipped feature.

OpenAI also operates a public verification tool at openai.com/verify, which lets anyone upload a supported file and check for OpenAI-associated provenance signals. The tool's own documentation is unusually clear about the limits of a positive or negative result: a detected signal indicates the content contains a supported OpenAI provenance signal, full stop. It does not confirm the content is accurate, unedited, legally owned, or presented in the correct context, and it does not identify who created the content or why. A negative result is at least as important to understand correctly: no detected signal does not mean the content was not generated by OpenAI tools. It could have been created before provenance signals existed, come from an unsupported product or export path, had metadata stripped during upload or conversion, or carry a watermark degraded by cropping, compression, or heavy editing. This is a meaningful caveat for anyone tempted to build an internal compliance check around "run it through openai.com/verify and treat a clean result as proof of human origin." That inference does not hold, and OpenAI's own documentation says so.

What Anthropic has implemented, and the compliance framing behind it

Anthropic's disclosure is more direct about the regulatory driver than OpenAI's. The company's updated support documentation states plainly that Anthropic has signed the EU AI Act's Article 50(2) Code of Practice on Transparency of AI-Generated Content, and that its marking approach is Anthropic putting those commitments into practice, not a voluntary feature launched independent of the legal backdrop. That framing matters for how an organization should read the rest of the announcement: this is compliance infrastructure being built out in public, on a timeline set by regulation, not a product differentiation play.

The mechanism itself mirrors OpenAI's dual-signal architecture but goes further on text. Claude embeds an imperceptible watermark directly into generated text, applied at the model level so it is present across every Claude surface: the API, the Claude apps, Claude Code, Claude Cowork, and Claude Tag. Anthropic's documentation states the watermark travels with copied and pasted text and may persist through some editing, though the company has been notably non-specific, when pressed by reporters, about exactly how much editing is required to strip it. For files, Claude attaches signed provenance metadata following the C2PA standard, currently covering SVG, PNG, and JPG. Models released on or after August 2, 2026, the date Article 50 took effect, ship with this built in; Anthropic says older models are being retrofitted, though no completion date has been published.

Two things are worth flagging about the text watermark specifically, because they are the parts of the announcement most likely to be misread as stronger guarantees than they are. First, Anthropic's own documentation is careful to describe the watermark as providing a detection signal, not a certainty. A supported mark being found "indicates that the content may have been processed by Claude," in the company's own hedged language, mirroring OpenAI's caution about its verification tool. Second, Anthropic has stated it will publish technical documentation on the detection mechanism but had not done so as of September 2026, which means no organization can currently independently verify a Claude watermark without going through Anthropic's own tools once those are released. That is a meaningful limitation for any compliance function that wants provenance verification it does not have to take on trust from the model provider whose output it is verifying.

The comparison between the two labs is instructive less for which one is "ahead" and more for what it reveals about where the industry's provenance investment is actually going. Both have shipped image and file-level C2PA metadata. Anthropic has shipped a text watermark in production; OpenAI has stated an intention to build one. Neither has published third-party-verifiable technical detail on watermark robustness against adversarial editing, which is the property that actually determines whether these signals survive contact with the real world rather than a clean demonstration.

The EU AI Act: what Article 50 actually requires

This is the part of the story where marketing language and legal obligation diverge most sharply, and it is worth being precise, because the precision is where the governance value sits.

Article 50 of the EU AI Act applies from August 2, 2026. It establishes two distinct sets of transparency obligations that fall on different parties and should not be collapsed into one.

Providers of AI systems, meaning the companies that build and offer the underlying models and systems, have two obligations. They must design AI systems so that individuals are explicitly informed whenever they are interacting with an AI system directly, and they must ensure that outputs from AI systems that generate synthetic audio, image, video, or text content are marked in a machine-readable format and detectable as artificially generated or manipulated. That second obligation is the one the new guide and the watermarking work from OpenAI and Anthropic are aimed at satisfying.

Deployers, meaning organizations that use AI systems in their own products, services, or operations rather than building the underlying model, carry a separate and in some ways stricter set of obligations. Deployers must disclose to individuals when they are exposed to emotion recognition or biometric categorization systems, when they are viewing a deepfake, meaning AI-generated or manipulated image, audio, or video content that appreciably resembles real people, places, or events and would falsely appear authentic, and when they are reading AI-generated text published on matters of public interest without human review or editorial control.

That last deployer obligation deserves particular attention from any organization publishing AI-assisted content, because it is not satisfied by a model provider's watermark. If your organization publishes AI-generated text on a matter of public interest, meaning something like a news article, a policy analysis, or commentary on a matter of public concern, and that text did not go through human editorial review, the disclosure obligation runs to you as the deployer, not to the model provider you used to draft it. A vendor's watermark embedded in the underlying text is a technical signal that could, in principle, help satisfy that obligation. It is not, by itself, the disclosure the Act requires, which is a transparency obligation running from the publisher to its readers.

The exemption structure is also worth understanding precisely, because it is frequently misstated. The deepfake disclosure obligation does apply to content that is evidently part of an artistic, creative, satirical, fictional, or analogous work, but the disclosure requirement is not waived in that case; it is instead permitted to be delivered in a manner that does not unduly interfere with the display or enjoyment of the work, meaning a subtler or less intrusive disclosure is acceptable, not that no disclosure is required.

There is a transition period built into the marking obligation specifically: generative AI systems already on the market before August 2, 2026 have until December 2026 to bring their marking into compliance. This grace period is why Anthropic and OpenAI's phased rollouts, covering new models first and retrofitting older ones over an unspecified timeline, are not currently out of compliance, but it is also a deadline organizations relying on either vendor's provenance signals should track independently rather than assuming vendor compliance timelines will simply resolve themselves before the grace period closes.

Enforcement runs through National market surveillance authorities in each member state, the EU AI Office for systems under its direct supervision, and the European Data Protection Supervisor where EU institutions themselves are acting as providers or deployers. The European Commission has also published detailed guidelines clarifying scope, definitions, and worked examples of what is and is not covered, including specific treatment of what counts as "standard editing" that does not trigger a deepfake disclosure obligation, and a mechanism by which adherence to the voluntary Code of Practice on Transparency of AI-generated Content, the same code Anthropic and OpenAI have signed, can be used as one way of demonstrating compliance. Critically, the guidelines are explicit that a provider or deployer choosing not to adhere to the Code of Practice must still demonstrate compliance through other, "equivalently adequate" means. The Code is a path to compliance, not the only one, and adherence to it is not itself legally mandatory.

Where the gap actually sits

Put the two halves of this story side by side and the governance problem comes into focus. The updated guide gives vendors a technically richer way to mark and describe AI-generated and AI-modified content than existed a year ago. Article 50 requires providers to mark synthetic content in a machine-readable, detectable format, and requires deployers publishing unreviewed AI text on matters of public interest, or exposing people to deepfakes or biometric categorization, to disclose that fact. Nowhere in the text of Article 50, nor in the Commission's guidelines, is C2PA named as the required mechanism. The Code of Practice references it as one legitimate approach among others. A vendor supporting C2PA Content Credentials, even a fully compliant implementation of every assertion in the August guide, is evidence that the vendor has built a capability. It is not, on its own, evidence that your organization's specific use of that vendor's tools satisfies your specific transparency obligations under the Act, because your obligations as a deployer are frequently distinct from the provider's obligations, and they attach to how you use the output, not merely to whether the tool you used had a watermark switched on somewhere upstream.

This is where "our AI vendor supports Content Credentials" quietly becomes a different claim than "our organization is compliant with Article 50," and the difference is not pedantic. Consider a concrete case: a marketing team uses Claude to draft blog commentary on a matter of public interest, publishes it with only a cursory read-through that does not rise to substantive editorial review, and does not disclose AI involvement to readers. Claude's text watermark is present in the underlying output. The organization is, under a straightforward reading of Article 50's deployer obligations, still failing to make the required disclosure to its own readers, watermark or no watermark, because the watermark is a machine-detectable signal available to third parties who go looking for it, not a disclosure made to the readers actually consuming the content on the page. The compliance gap here is not a defect in C2PA or in Anthropic's implementation. It is a mismatch between what a technical provenance signal does and what a legal transparency obligation requires, and no version of the standard, however complete, closes that gap by itself. Only the deployer's own disclosure practice does.

What this means in practice for a compliance program

None of the preceding is an argument against adopting C2PA-aware tooling or against valuing vendor watermarking commitments. Both are real, positive developments, and an organization that ignores them because they are not themselves sufficient for compliance is making the opposite mistake: throwing away useful infrastructure because it is not a complete solution. The right posture is to treat vendor provenance signals as one input into a compliance program, not as the compliance program.

A few concrete steps follow from that posture. Ask every AI vendor in your stack which of the five assertions in the August guide they have actually implemented today, as opposed to which they support in principle or plan to support. "We support C2PA" was true, in some sense, under the previous version of the standard too, and it told you almost nothing about whether region-level localization or ingredient-recipe documentation, both far more useful for an audit than a plain generated flag, were actually present in the manifests your tools produce. Push for specifics: does the tool attach digitalSourceType using the current IPTC vocabulary, does it produce an ai-disclosure assertion with model provenance and oversight fields populated, does it support Regions of Interest for partial edits, or does it still emit the older, coarser labeling that predates the August update.

Ask specifically about text, separate from image and file coverage, because that is where the two major labs currently diverge most and where your organization's actual publishing volume is likely highest. If your vendor's text watermark commitment is still a stated goal rather than a shipped feature, your compliance program cannot lean on it, and you need a fallback disclosure practice for text output that does not depend on it arriving on a particular vendor's timeline.

Ask whether the vendor's watermarking or metadata approach survives the transformations your content actually goes through on the way to your reader. Screenshotting, PDF export, format conversion, republishing through a CMS that strips metadata on upload, syndication through a third party's platform: any one of these can silently remove a C2PA manifest or degrade a watermark below detectability, and your organization's disclosure obligation does not evaporate because the vendor's technical signal happened not to survive your publishing pipeline. This is precisely the caveat both OpenAI's and Anthropic's own documentation flags, and it deserves to be taken as seriously internally as the vendors themselves are taking it in writing.

Ask whether the vendor's disclosure and marking practices are tied to a specific regulatory requirement, meaning built to satisfy Article 50 and equivalent instruments elsewhere, or are voluntary commitments that could change, be scaled back, or be discontinued without notice as competitive or business pressures shift. A commitment made under a signed Code of Practice, as Anthropic has made explicitly and as OpenAI, Google, Meta, Microsoft, Black Forest Labs, and Synthesia have also signed onto, carries a different weight than a feature a vendor shipped because it seemed like good practice at the time. Get that distinction in writing where you can, in a vendor agreement or a documented representation, rather than relying on a support page that a vendor can update at any point without notifying you.

Finally, separate the provider-side question from the deployer-side question explicitly in your own documentation, because conflating them is the single most common governance error this topic produces. Your AI vendor's provenance signal, however well implemented, answers a provider-side question: did the tool mark its own output. Your organization's Article 50 deployer obligations are a separate question that the vendor's marking does not answer for you: did you disclose AI involvement to the people actually consuming your content, when a matter of public interest and lack of human editorial review triggered that obligation, and did you disclose exposure to a deepfake or biometric categorization system when applicable. A vendor can score perfectly on the first question while your organization is still failing the second, because the second question is about what you told your own audience, not about what technical metadata sits in a file your audience may never inspect.

Where this leaves the standard, and where it leaves you

The August guide is a genuine step forward for the underlying provenance infrastructure, and the direction of travel, from a binary label toward a structured, multi-field, regionally localized, action-by-action record, is the right direction if the goal is a provenance system that can actually support serious audit and forensic use rather than a marketing checkbox. The standard's broader adoption numbers, more than 500 members and 6,000 affiliates spanning camera manufacturers, publishers, and the major AI labs, suggest the industry is genuinely converging on this as shared infrastructure rather than each vendor building a proprietary, incompatible scheme. That convergence has real value: a Content Credential produced by one tool being readable and meaningful to another tool's verification pipeline is exactly the kind of interoperability that makes provenance information useful at internet scale rather than useful only within a single vendor's walled garden.

What the standard cannot do, no matter how many assertions it eventually specifies, is stand in for an organization's own compliance judgment. Article 50 draws a legal line between what providers must build into their systems and what deployers must disclose to the people actually consuming AI-touched content, and that line does not move because a vendor's technical implementation improved. The practical discipline for any compliance function watching this space is to keep the vendor conversation and the deployer conversation in two separate columns: what has the vendor actually shipped, verified against the current specification rather than the vendor's own summary of it, and separately, what does our organization need to disclose to our own audience given how we are actually using that vendor's output. The first column is worth tracking closely, because it changes meaningfully every few months and the August 2026 guide is a real example of that. The second column is the one an EU market surveillance authority will actually ask about, and no vendor's watermark, however well engineered, answers it on your behalf.