Provenance standards for AI agent actions: PROV, FHIR, C2PA, SLSA and AAP-H compared

The short answer

No single provenance standard was designed for AI agent actions, but several cover parts of the job. W3C PROV gives a general vocabulary of entities, activities and agents, including delegation (“acted on behalf of”).¹ FHIR R4 Provenance records who created, revised or signed a version of a health resource.² C2PA signs the provenance of media files⁴, and SLSA records how software was built.⁵ What none of them has is a slot for what the agent claimed it did next to what the system shows afterwards, plus the rule decision and approver in one signed record. Our open draft, AAP-H, tries to fill that for health data.⁷

What an agent action record needs

The standards, one by one

W3C PROV (2013). PROV defines provenance as information about entities, activities and people involved in producing data or things. Its data model defines an entity, an activity (something that occurs over time and acts on entities), and an agent (something bearing responsibility for an activity), with relations for generation, usage, association, attribution and delegation.¹ Delegation, “acted on behalf of”, maps neatly onto an AI agent working for a clinician. PROV is a vocabulary, not a signed format.

FHIR R4 Provenance and AuditEvent. Provenance tracks the activity that created, revised, deleted or signed a version of a resource, with agents that have a type, role, who and onBehalfOf, and an optional signature.² AuditEvent is a security log record of events as they occur.³ Provenance is close to PROV in spirit and native to health data. HL7’s AI Transparency on FHIR guide adds AI Provenance and AI Device profiles to mark data an AI influenced; it went to its first ballot in January 2026 and has no official published version yet.⁶

C2PA (2.2, May 2025). C2PA records the provenance of digital assets in a manifest of assertions (capture details, edit actions, content hashes), a claim referencing them, and a claim signature using COSE and X.509 signing credentials, with RFC 3161 time-stamps.⁴ The spec says it shouldn’t make value judgements about whether provenance is good or bad; validation checks binding, form and tampering, not truth.⁴

SLSA provenance. SLSA records where, when and how a software artifact was built, as an in-toto statement: the build definition (type, external parameters, resolved dependencies) and run details (builder identity, timing). It treats external parameters as untrusted inputs to verify downstream.⁵

AAP-H (v0.1 draft). Agent Action Provenance for Health is FHIR R4 Provenance and AuditEvent profiles plus a JSON envelope recording which agent acted, what the rules decided, who approved, what the agent claimed and what the system of record shows afterwards.⁷ Each record is signed and chained so it can be checked offline with the issuer’s public keys.⁷ It’s a draft for comment, not an HL7 or IHE publication, and no standards body has reviewed it.⁷

Side by side

The gap: claim versus outcome

Every standard above records an actor and an action. That’s enough when the actor is a person using trusted software, because what they did is what the system did. Agents break that assumption. An agent can report “updated the allergy list” when the server dropped the field, or created a duplicate. A provenance record built from the agent’s report then signs a falsehood, very securely.

So agent records need two parts: what the agent said, and what an independent read of the system showed. The difference is the most useful field in the record. C2PA’s principle applies here too: a valid signature shows the record wasn’t changed, not that its content is true.⁴ AAP-H states the same limit: a valid record means the issuer wrote those values and nothing covered by the signature changed since; it doesn’t mean the AI was right, or that the issuer saw every action.⁷

Choosing what to use

• Already on FHIR? Use Provenance and AuditEvent as the base; add AI profiles as HL7’s guide matures.²⁶
• Need a general model across systems? Map to PROV terms; it’s the shared vocabulary.¹
• Signing AI-generated images or documents? Look at C2PA.⁴
• Shipping agent software? Publish SLSA provenance for your builds.⁵
• Recording agent writes to health data? Add the claim, observed outcome, rule decision and approver, whether through AAP-H or your own extension. AAP-H defines three conformance levels (record, verify, signed and approved), and a conformance claim is the implementer’s own statement.⁷

Questions people ask

Is there a standard for AI agent provenance?

Not one built for agent actions. PROV, FHIR Provenance, C2PA and SLSA each cover parts. AAP-H is an open draft for health data.⁷

Does a signed provenance record show the AI was right?

No. It shows the record wasn’t changed after signing.⁴⁷

What’s the difference between FHIR Provenance and AuditEvent?

Provenance records the activity that produced a resource version; AuditEvent is a security log of events.²³ See our comparison post.

The AAP-H spec has examples, the FHIR write integrity study shows why the observed-outcome field matters, and our healthcare page shows how Deedglass records AI writes to health systems today. To try approvals and read-backs on a real database in your browser, open the playground; to grade what an agent can reach on your own machine, run npx deedglass scan (the grade, explained).

Written with AI assistance and checked against our claims register.