Disclosure & Content Provenance

Write the spec as acceptance criteria, because "we disclose" is not testable.

Every disclosure obligation you are subject to — the EU AI Act's Article 50 transparency duties, sectoral rules on automated communications, platform policies, your own commitments — reduces to a small set of checkable statements. Write them that way, in your issue tracker, or the requirement will live in a policy document and not in the product.

• Who must be told. A natural person interacting with the system. Not a service account, not another agent, not your own back end — which sounds obvious until you draw your topology and find the human three hops away from the model.
• When. The prevailing standard is at the latest at the point of first interaction, which rules out a disclosure at the end of a conversation or behind a link nobody opens. In practice this means the first outbound turn carries it, in every channel.
• What form. Clear and distinguishable to a reasonable person, in the channel they are actually using. A footer in six-point grey is a lawyer's disclosure, not a user's.
• What is exempt. Most regimes carve out the obvious cases — where it is evident from context to a reasonably informed person, and typically for law-enforcement uses. Do not rely on "obvious": whether it is evident that your assistant is an AI is a question about your users, and you can test it rather than assume it.
• Who bears the duty. Providers and deployers carry different obligations, and if you are both — you built it and you run it for customers — you carry both sets. Map this onto named owners using accountability and roles, because "compliance owns it" is how a rendering bug becomes a finding.

In an agent system, "first interaction" is a routing question.

Chatbot-era disclosure had a simple answer: the user opens the chat, the first message says what this is. Agents break that because the model's output frequently reaches a person through some other system entirely, at a time nobody chose, in a container that strips whatever you attached.

• Enumerate every path from a model output to a human eye. The in-product chat, yes — but also the email the agent sent, the ticket comment it wrote, the calendar invite, the Slack message, the PDF it generated, the phone call it placed, the pull-request description. Each of those is a separate first interaction with a possibly different person.
• The asynchronous paths are the ones that get missed. An agent that drafts and a human who sends is a different obligation from an agent that sends. The moment your product adds "just send it", a compliance property silently changed and no code near the disclosure logic was touched.
• Recipients are not users. The person receiving the agent's email never agreed to your terms and never saw your onboarding. Whatever they need to be told has to be in the message, because there is no other surface.
• Voice has the tightest budget and the clearest rules. Disclosure must land in the first seconds, in the audio, in a way that survives someone half-listening — and it competes with the turn-taking budget. The mechanics are worked out in outbound voice agents; the point here is that it is the channel where the requirement most obviously has to be designed rather than appended.
• Make it a property of the egress point, not the agent. The durable implementation is a single outbound layer through which everything leaving the system passes, which knows the channel and the recipient class and attaches the right disclosure. Agents forget; a chokepoint does not. This is the same argument as centralising policy enforcement.

Know which marks survive which boundary.

Marking synthetic content is treated as one requirement and is really three mechanisms with sharply different durability. Choosing between them is an engineering decision, and getting it wrong produces a compliance story that evaporates the first time content is copied.

• Cryptographic provenance manifests. C2PA Content Credentials — a signed manifest recording what produced an asset and what edited it since, ratified as ISO/IEC 22144 and backed by a coalition that now includes most of the large model providers, platforms and camera makers. Strong where it applies: it is verifiable, tamper-evident and carries an edit history. Its weakness is that it is metadata attached to a file, and it is stripped by any pipeline that re-encodes without preserving it — which is most of them.
• Embedded watermarks. A signal in the pixels, samples or token choices themselves, of which Google's SynthID is the most widely deployed; its text variant has been published and open-sourced so third parties can build detectors, and it is now being adopted alongside Content Credentials rather than as a competitor to them. For images, audio and video this is genuinely robust to the transformations that destroy metadata — re-encoding, resizing, screenshots.
• Perceptible labels. The visible "AI-generated" mark on the artifact or in the interface. Weakest technically, and the only one an ordinary person actually experiences. Ship it anyway: it discharges the user-facing half of the duty that neither of the other two does.
• Text is the hard case and you should say so internally. Text watermarking works by biasing token selection, so its detectability scales with length and with how much freedom the model had. Short outputs carry too little signal, and paraphrasing, translating or running the text through another model degrades it. A watermark is worth enabling where your provider offers it; it is not something to build a compliance argument on.
• Detection asymmetry is the trap. Absence of a mark proves nothing — not that content is human, not that it came from elsewhere. Any process you build that treats "no watermark detected" as a finding will produce false accusations, which is the specific harm to avoid in content moderation.

For text, the defensible artifact is a record on your side.

Given that no mark reliably survives on short text, the honest position is to stop trying to prove provenance from the artifact and start being able to prove it from your own systems. This is a records problem, and it is one you already have most of the machinery for.

• Log what you generated, when, for whom, and under which model and prompt version. A content-level provenance record, joined to the run that produced it. When someone asks six months later whether a paragraph came from your system, this answers it and a watermark does not.
• Hash the output and keep the hash. It turns "did we write this" into a lookup rather than an argument, and it survives the text being reformatted in ways a watermark would not.
• Reuse the trail you built for audit. The same run records described in audit trails and decision receipts carry this if you add the output identity to them. Building a second, parallel provenance store is the common waste here.
• Set retention against the obligation, not the storage bill. A provenance record that expires before the complaint window closes is a record you paid for and cannot use. Take the period from data governance and make it explicit.
• Distinguish generated from assisted, in the record. Fully synthetic output, model-edited human text, and human text the model only reviewed are three different things with three different disclosure answers, and only your system knows which one happened. Capture it at write time; it cannot be inferred later.

Agent-to-agent: disclosure has to propagate, and no protocol does it for you.

The interesting new case is the one the rules were not drafted around. Your agent calls a partner's agent, which produces content that a human at the partner eventually reads. The duty attaches at that human, several systems away from you, and nothing in the current interop layer carries the fact that the content is synthetic across the hop.

• Treat provenance as part of the payload contract. If you exchange generated content with another system, agree a field that says so and carry it through. It is a small addition to a tool schema and it is the only thing that lets the receiving system discharge its own obligation.
• Agent identity is adjacent but not sufficient. Agent Cards and the discovery layer say who is calling — see agent cards and discovery and the A2A deep dive — but identifying the caller as an agent is not the same as marking the content it returns as generated.
• Decide your posture as a receiver too. When content arrives from another agent, do you record its provenance, propagate it, or drop it? Dropping it is the default, and it is how a chain of agents launders synthetic content into something that looks authored.
• Do not let a human in the middle erase the record. If a person reviews and forwards model-generated text, the disclosure question does not disappear — it changes. Your record should distinguish "sent by the agent" from "approved by a named human and sent", because that distinction is the one that will be asked about.

Verify it like a feature, because it regresses like one.

Disclosure is implemented once and broken quietly, usually by a redesign, a new channel or a template change made by someone who had no idea the string was load-bearing. It needs tests in CI, not an annual review.

• An automated check per egress path. For every channel you enumerated in step 2, a test that asserts the disclosure is present in the first outbound message. This is the single highest-value control on this page and it is a day of work.
• Assert the mark survives your own pipeline. Generate an image, push it through your resize, storage and CDN path, and verify the credential is still readable at the other end. Most teams discover their thumbnailer strips it — after shipping.
• Test comprehension, not presence. Show the surface to people who have not seen it and ask what they think they are talking to. "Clear to a reasonable person" is a user-research question with a cheap answer, and it is the standard you will be measured against. The wider case is in transparency and explainability.
• Add "does this create a new path to a human?" to your launch checklist. New channel, new integration, new outbound automation — each one re-asks every question in step 2, and the checklist is where that gets caught.
• Keep a register of what you mark and how. One table: content type, channel, disclosure mechanism, marking mechanism, owner, last verified. It is the document you will be asked for, and maintaining it is what surfaces the paths nobody remembered.

Related: agents vs chatbots for why the boundary moved in the first place, and governance in practice for how this fits alongside the rest of the programme.