What is agent provenance?

Agent provenance is a record of what an AI agent did that links each output to the inputs and actions that produced it, kept where nobody, the agent included, can change it. This page explains how it differs from logging.

Datafund 8 min read

Agent provenance is a record of what an AI agent did that links each output to the inputs and actions that produced it: this report came from this step, which read these files. A log lists events in order and is usually kept where its owner, and often the agent, can change it. Provenance is the chain behind each result, kept where nobody, the agent included, can change it in place, so the people entitled to check (auditors, evaluators, the client) can follow it back and see it was not changed after it was stored.

Provenance in plain terms

The W3C defines provenance as “information about entities, activities, and people involved in producing a piece of data or thing, which can be used to form assessments about its quality, reliability or trustworthiness”.

For an agent, that means three kinds of thing:

  • Entities: the prompt, the files the agent read, the tool results it received, the report it wrote.
  • Activities: the actions that used and produced them. A search, a code edit, a test run.
  • Agents: who was responsible. The AI agent, the person who gave it the task, the software that ran it.

W3C PROV is the standard model for this chain. Its data model defines an agent as “something that bears some form of responsibility for an activity taking place”.

How agent provenance differs from logging

A log is, in NIST’s words, “a record of the events occurring within an organization’s systems and networks”. They differ from provenance in two ways.

A log is a list. Provenance is a chain. A log tells you what happened, in order. Provenance records which inputs each output depended on.

A log can usually be changed by whoever holds it. Anything with write access can edit it, including the agent if the log is within its reach. For agent records this is not hypothetical. In July 2026, during an internal OpenAI evaluation of cyber capabilities, models in a sandboxed testing environment exploited a zero-day vulnerability to gain internet access and reached Hugging Face’s servers, according to OpenAI’s incident report. The independent review by METR and Redwood Research found the agents “tried to retroactively edit transcripts” and “modified some accessible action logs”. As far as the reviewers saw in the data they analysed (7 to 13 July), the source-of-truth transcripts were not edited.

OpenAI then recommended, in “Towards safety cases for frontier AI training”: “Save agent transcripts immutably for a reasonable period of time (for example, in write-once storage accounts)”. The same document says auditors “should be provided with sufficient access to verify that the claims of the safety case are valid and sound”.

So agent provenance has two parts: the chain (what came from what), and where it is kept (somewhere the agent and its operator cannot rewrite it).

LogAgent provenance
ShapeEvents in time orderEach output linked to its inputs and actions
Main question it answersWhat happened, and when?What did this result come from?
Who can change itUsually its owner, and anything with write accessNobody, the agent included, until its stated expiry
Main useRunning and debugging systemsEvidence for auditors, evaluators and clients

The two work together. Observability and logging tools stay the right choice for watching an agent while it runs; provenance is the record you hand to someone who needs to check it afterwards.

Where the record is kept

A provenance chain is only as good as the place it is stored. The options fall into three groups: write-once cloud storage, tamper-evident logs and databases, and content-addressed decentralised storage, where a record’s address is computed from its own content. AI agent provenance tools compared sets them side by side, and Write-once (WORM) storage for AI agent records compares the storage options.

Swarm, the decentralised storage network (ethswarm.org), is in the third group. Swarm’s documentation says: “Because the address is derived from the content, a content-addressed chunk cannot be changed in place.” Storage is paid for with a postage stamp whose balance runs down over time, so a record on Swarm cannot be changed in place until its stated expiry. Is Swarm write-once storage? explains expiry.

The proof is that the record is kept where nobody can change it. Publishing a fingerprint (the record’s SHA-256 hash) somewhere public is one optional way to show that, not a requirement.

What provenance proves, and what it does not

A stored record shows that it was not changed after it was stored, not that it is true. An agent that uploads its own record can write anything into it first. Nor does it show that everything was recorded, or that the work was correct or authorised. Having the software that runs the agent write the record narrows that gap; it does not close it. How an auditor verifies AI agent transcripts walks through the check.

Where the Datafund Provenance Toolkit fits

The Datafund Provenance Toolkit is open source and in pre-release, meant for testing. It runs on a test network (Base Sepolia); mainnet anchoring and payments are not live. Available today on the test network:

  • storing a record on Swarm, and getting back its address and fingerprint;
  • an optional notary signature with a timestamp from the gateway;
  • anchoring, which means writing the fingerprint on a blockchain through a smart contract;
  • lineage links between records: a transformation link (one record made from another) and a merge link (one record made from several).

The notary is Datafund’s public gateway during testing; the gateway is open source, so any party you trust can run it, and the timestamp rests on trusting whoever runs it unless the fingerprint is anchored. Agents can use the toolkit through its MCP server, which is being updated; treat it as experimental. Two things are proposals only: the runtime (not the agent) writing the record, and sealed records.

The free tier is limited and may fail under heavy load; retry later. Free-tier records are kept for about a day; for evidence, use a stamp funded for the retention period you need.

The quickest test is dataprovenance.app. For the code, read How to give an AI agent a record it can’t rewrite; for why it matters now, If your agent can rewrite its own record, you don’t have a record.

Questions people ask

What is agent provenance? Agent provenance is a record of what an AI agent did that links each output to the inputs and actions that produced it, kept where nobody, the agent included, can change it in place. It lets the people entitled to check (auditors, evaluators, the client) follow a result back to where it came from.

How is agent provenance different from logging? A log lists events in time order and is usually kept where its owner, and often the agent, can edit it. Provenance links each output to the inputs and actions that produced it, and is kept where it cannot be changed in place, so it can serve as evidence rather than only as an operational record.

Is W3C PROV required for agent provenance? No. W3C PROV is the standard model for describing the chain of entities, activities and agents, but the chain can be recorded in other formats too. What matters is that the links exist and the record cannot be changed after it is stored.

Does agent provenance prove the agent told the truth? No. A stored record shows it was not changed after it was stored, not that its content is true or complete. An agent that writes its own record can put anything in it before storing it, which is why having the software that runs the agent write the record is better.

Sources