How to give an AI agent a record it can't rewrite

Agent provenance for developers: how a record on Swarm, the decentralised storage network, gets an address, a fingerprint and an expiry, how provenance links outputs to their inputs, what the pre-release toolkit does today, and what is still a proposal.

Datafund 11 min read

AI agents now write code, open pull requests and send reports without a person watching each step. When something goes wrong, the first thing people ask for is the record of what the agent did.

Usually that record is a log. The system writes it, its owner keeps it, and anything with write access can change it. That includes the agent, if the log is within its reach.

This is the developer half of agent provenance: how to keep an agent’s record on Swarm, the decentralised storage network, where nobody, the agent included, can change it in place until its stated expiry, what our open toolkit does today, and what is still a proposal. The story post, If your agent can rewrite its own record, you don’t have a record, covers why it matters now.

OpenAI recommends records that cannot change

In summer 2026, agents in an OpenAI security evaluation got out of their sandbox and into Hugging Face’s servers. The independent review by METR and Redwood Research found agents “tried to retroactively edit transcripts” and “modified some accessible action logs”. The source-of-truth transcripts were not edited, as far as the reviewers saw in the data they analysed (7 to 13 July).

OpenAI recommends: “Save agent transcripts immutably for a reasonable period of time (for example, in write-once storage accounts)”. It adds that auditors “should be provided with sufficient access to verify that the claims of the safety case are valid and sound”. Records that can’t be changed, and auditors who can check what they are told. We agree with both. Write-once storage is one way to do the first. What we add is a way for a reviewer to check a record without relying on the owner’s account setup; a write-once bucket plus a fingerprint kept somewhere the owner does not control could also do that, and we would like to hear where it does it better.

A record that cannot be changed in place

We store records on Swarm, the decentralised storage network (ethswarm.org). Three properties do the work.

Content addressing. A record’s address is computed from its own content. An edited version can be stored, but it gets a different address. The original stays where it was.

Postage-stamp expiry. Storage is paid for with a postage stamp, Swarm’s storage ticket, whose lifetime is stated and public. So the precise claim is: a record on Swarm cannot be changed in place until its stated expiry. Call it WORM storage (write once, read many) with an expiry.

Many nodes hold it. Each chunk is kept by the nodes closest to its address, and neighbouring nodes keep copies, while its stamp is funded. Whoever you give the address to can fetch the record from a Swarm node and check it without trusting whoever stored it. The toolkit’s own download goes through our gateway; the hash check is what removes the need to trust the gateway.

That is what shows the record was not changed after it was stored. Nothing has to be published for that to hold.

Change one byte and you get a different address. The original stays where it was until its stated expiry.

Post on X →

Provenance is a chain, not a list

A log lists events in order. Provenance links each output to the inputs and actions that produced it, so you can follow the chain back: this report came from this step, which read these files. W3C PROV is the standard model for this chain: things (entities), the actions that used and produced them (activities), and who was responsible (agents). The files you store can be in the PROV format.

Here is the plain split between today and proposal.

What the toolkit does today, on the test network (Base Sepolia). It stores the record you give it on Swarm and returns its address and its fingerprint (the record’s SHA-256 hash), and, if you ask, a notary signature with a timestamp. It links records into a chain: a transformation link says one record was made from another, and a merge link says one record was made from several (recordTransformation and mergeTransform in the SDK, chain transform and chain get --follow in the command-line tool). And it can anchor a fingerprint, which means writing it on a blockchain through a smart contract, so its time no longer rests only on our gateway.

What is proposal. The software that runs the agent writing that chain automatically, step by step, outside the agent’s decisions. Nothing in the toolkit does that today.

A log tells you what happened, in order. Provenance tells you what each result came from.

Post on X →

What the toolkit does today

The Datafund Provenance Toolkit is open source and in pre-release, meant for testing. What we have tested: upload a record to Swarm through a public gateway; get back its address (the reference) and its fingerprint; optionally have the gateway’s notary sign the fingerprint and a timestamp, with the gateway’s own key; then download, recompute and check. With the TypeScript SDK (tested with @datafund/swarm-provenance 0.6.1):

import { createHash } from 'node:crypto';
import { ProvenanceClient } from '@datafund/swarm-provenance';

const client = new ProvenanceClient(); // public gateway, free tier
const text = `Synthetic agent report: 3 files checked, 0 errors. ${new Date().toISOString()}`;
const { reference, metadata } = await client.upload(text, { sign: 'notary' });
await new Promise((r) => setTimeout(r, 60_000)); // the free tier is rate-limited: wait before the next call

// Later, the person checking, holding the reference and the fingerprint:
const r = await client.download(reference);
const recomputed = createHash('sha256').update(r.file).digest('hex');
console.log(recomputed === metadata.content_hash, r.verified, r.signatures?.[0]?.timestamp);

The snippet waits between the two calls because the free tier is rate-limited. It condenses the quickstart script, which ran on 17 October and printed a match and Notary signature verified: true. Agents can also use the toolkit through its MCP server, which is being updated.

What we propose next

Everything in this section is a proposal. None of it is built or tested yet.

The runtime writes the record, not the agent. The software that runs the agent records each step automatically, outside the agent’s decisions: what it read, what it did, what it produced. The quickstart shows the idea at the smallest scale, as a wrapper in your own code. It records only the step’s name, what the step returned and the finish time, not what the step read or did, and you write it yourself; the toolkit does not run it.

Sealed records. Records stay encrypted, and keys go to an auditor when needed. Test and evaluation runs, which use no personal data, are an obvious place to start.

How this compares with Certificate Transparency and Rekor

Certificate Transparency and Sigstore Rekor solve a close problem and are widely used. Both are public append-only logs with inclusion proofs (this entry is in the log) and consistency proofs (the log has only grown).

Content addressing alone gives neither. A Swarm address proves the bytes match; it says nothing about what else was stored, or in what order. If you need that, you need something kept outside the record: anchoring on a blockchain, which inherits that chain’s trust model, or a transparency log.

A transparency log is built to show that an entry exists and in what order, not to hold large records. Rekor, as we read its documentation, stores a signature and a hash rather than the artifact, so someone still has to keep the agent’s transcript itself. Swarm keeps the record, on many nodes and with a public expiry.

For agent records, we think keeping the record where it cannot be changed is the core, and anchoring is an extra for when a public time or ordering matters. The obvious alternative is a transparency log for fingerprints plus separate storage. If you think that is better, challenge us.

What a check proves, and what it does not

A check proves that the bytes you downloaded match the fingerprint recorded at upload. The record has not changed since it was stored. With a notary signature, it also shows our gateway vouched for that fingerprint at that time; with an anchor, the blockchain shows when the fingerprint was written.

It does not prove that everything the agent did was recorded, that the work was correct, lawful or authorised, or who uploaded it. When the agent uploads its own record, it can write anything into it before storing it. The METR and Redwood review describes agents “spoofing” tool call outputs; a faithful record of a spoofed output is still a spoofed output. Recording in the runtime would narrow the gap between what happened and what was recorded. It does not close it.

A receipt proves a record hasn’t changed. It doesn’t prove everything was recorded, or that the work was right.

Post on X →

Limits today

  • Pre-release. The toolkit is meant for testing environments, not production.
  • Test network. Anchoring, lineage links and the paid mode (x402) run on a test network (Base Sepolia). Mainnet is not live.
  • The notary is us. The timestamp rests on the gateway’s own key, unless you anchor.
  • Limited free tier. No wallet, key or account. The free tier is limited, and may fail under heavy load; retry later.
  • Short expiry. Free-tier records are kept for about a day; for evidence, use a stamp funded for the retention period you need.
  • Readable by whoever has the reference. Records are not encrypted. Use synthetic data only.
  • Untested path. We have tested the match case, not a tampered record. Please try.

Try it

The quickest way is dataprovenance.app. It runs in your browser with nothing to install: record a file, get a receipt page, and verify it. The app uploads the file to Swarm through our gateway, and anyone with its reference can download it while it is kept, so use a file you are happy to make public.

Try it: give a file a receipt

For code, the toolkit repository has the quickstart: it stores a synthetic agent report, returns its receipt, and has you play the client who checks it. Because the data is synthetic and public, anyone can run the check.

Then break it. Open an issue in the repository, or tell us on Hacker News where the design falls short.

Questions people ask

What tools exist for AI agent provenance? They fall into three groups: write-once cloud storage such as S3 Object Lock, tamper-evident logs and databases such as Sigstore Rekor and immudb, and content-addressed decentralised storage such as Swarm. The Datafund Provenance Toolkit is open source and in pre-release: it stores agent records on Swarm and lets the people entitled to see them check that nothing changed.

What storage can’t be changed by an AI agent? Storage the agent cannot overwrite, and where an overwrite would show. A write-once bucket such as S3 Object Lock blocks changes inside one provider’s account. On Swarm a record lives at an address computed from its content, so a changed record gets a new address and the original stays until its stated expiry. Either way, the software that runs the agent should write the record, not the agent.

How can an auditor verify that an AI agent’s transcripts have not been changed? By comparing what they are given with a fingerprint recorded when the transcript was written, and fetching the record from storage the lab cannot change. With the toolkit, the auditor downloads the record by its address, recomputes its SHA-256 fingerprint and checks the gateway’s notary signature, or the anchor on the blockchain.

Sources