Binding Synthetic-Content Marking to an Attested Execution, v1¶

Defines one C2PA assertion, com.agentrust-io.trace, that ties a marked asset to the Trust Record of the execution that produced it.

0. What this does not do, first¶

It does not stop anyone stripping the mark. Removing a C2PA manifest from a file is trivial and nothing here changes that. Article 50(2) asks for marking that is machine readable and, so far as technically feasible, robust; a C2PA soft binding is metadata, and metadata travels only as long as nobody removes it.

What binding buys is narrower and worth stating exactly: a mark that is present becomes checkable against a hardware-rooted claim rather than being an unverifiable label, and in a channel that requires marks, an absent one is detectable. Those are real and they are not un-strippability.

It is not watermarking. TRACE does not embed signals in pixels or audio and this document does not pretend to. Where an obligation calls for a hard binding, a watermark is a separate control and this composes with it rather than replacing it.

It does not make a deployment compliant. It produces one checkable artifact for one part of one obligation. Any claim beyond that is the operator's to make and defend.

It says nothing about whether the content is true, safe, or good. It says which attested execution produced it.

1. Why bind at all¶

A C2PA manifest already says who signed this asset. It does not say what produced it: a signed claim of "generated by Acme Studio" is an assertion about a company, not about a model, a prompt, a policy or a runtime. The gap is the same one the whole specification exists to close, arriving in a different place.

A Trust Record answers those questions and is verifiable without trusting the operator. So the assertion carries a reference to the record rather than restating its contents, which would create two copies to disagree.

2. The assertion¶

Label: com.agentrust-io.trace, per the C2PA reverse-DNS convention for entity-specific namespaces.

{
  "label": "com.agentrust-io.trace",
  "data": {
    "version": 1,
    "record": {
      "url": "https://registry.example/records/2026/08/09/abc123.json",
      "hash": "sha256:<64 hex>",
      "alg": "sha256"
    },
    "subject": "spiffe://example.org/agent/image-bot",
    "eat_profile": "tag:agentrust-io.com,2026:trace-v0.2",
    "anchor": "https://registry.example/entries/2026-08-09-001"
  }
}

record follows the shape of C2PA's hashed-ext-uri-map: a URI plus a hash of what is at it. The hash is the binding. Without it, the assertion points at a document the publisher can change after signing.

3. Two signatures, and neither replaces the other¶

A C2PA manifest is signed by the asset's signer. A Trust Record is signed by the key in its cnf. These are different signatures made by potentially different parties, and the assertion does not merge them.

• The C2PA signature says: this assertion was in this manifest when the asset was signed.
• The TRACE signature says: this execution happened as described.
• The hash says: the record the assertion points to is the record the signer meant.

A verifier that checks only one has checked half. Checking the C2PA signature alone proves the asset carries an assertion, not that the assertion is true. Checking the record alone proves an execution happened, not that this asset came from it.

4. Verification¶

1. Verify the C2PA manifest per C2PA 2.1. Failure here ends it.
2. Read com.agentrust-io.trace. An unknown version is rejected, not best-effort parsed.
3. Fetch record.url and check the bytes against record.hash. A mismatch means the record was changed after the asset was signed, and is the finding.
4. Verify the Trust Record per TRACE v0.2 §3.3, against a key you already trust.
5. Check subject and eat_profile in the assertion match the fetched record. A mismatch means the assertion describes a different record than it points at.
6. If anchor is present, verify inclusion per Anchor Format v1 §5.1.
7. Weigh the result by the record's conformance level. A Level 0 record binds this asset to an unattested software execution. That is worth having and it is not hardware-rooted provenance, and a consumer that reports the two identically has lost the distinction the record exists to carry.

5. What a verifier reports when there is no assertion¶

Absence is not a finding about the content. It means the asset carries no binding, which is the state of essentially all content today. A consumer SHOULD record absence explicitly and MUST NOT report it as a failed check, for the same reason absence of a server-provenance record is recorded rather than fatal: a control that makes the common case an error gets turned off.

Where a channel requires marks, absence is a policy violation of that channel's rule. That is a decision the channel makes, not something this document can assert.

6. Conformance¶

A producer conforms if it emits the §2 assertion with a hash over the exact record bytes it references, and does not emit one for content produced by an execution it has no record of.

A consumer conforms if it performs §4 steps 1 through 5, records absence per §5, and reports the conformance level per step 7 rather than a bare pass.

Step 3 is the one most likely to be skipped, because it requires a fetch. An assertion whose hash was never checked is a URL in a file.