# AI agent provenance tools compared

> What tools exist for AI agent provenance? Write-once cloud storage (S3 Object Lock, Azure immutable storage, Google Cloud Bucket Lock), tamper-evident logs and databases (Certificate Transparency, Sigstore Rekor, immudb), and content-addressed storage on Swarm, compared fairly, with where the Datafund Provenance Toolkit fits.

- URL: https://datafund.io/learn/ai-agent-provenance-tools-compared/
- Published: 2026-10-28
- Author: Datafund
- Tags: provenance, ai-agents, comparison, worm-storage, s3-object-lock, transparency-logs, immudb, swarm, content-addressing

Tools for AI agent provenance fall into three groups: write-once cloud storage (S3 Object Lock, Azure immutable blob storage, Google Cloud Bucket Lock), tamper-evident logs and databases (Certificate Transparency-style transparency logs, Sigstore Rekor, immudb), and content-addressed decentralised storage such as Swarm, the decentralised storage network ([ethswarm.org](https://www.ethswarm.org/)). Each stops a different kind of change and asks you to trust a different party. The [Datafund Provenance Toolkit](https://github.com/datafund/provenance) belongs to the third group: it stores agent records on Swarm so the people entitled to check them can confirm nothing changed after storage.

## 1. Write-once cloud storage

Write-once (WORM, write once, read many) buckets are the most cited answer: mature, and assessed against financial record-keeping rules.

**S3 Object Lock.** In compliance mode, a protected object version "can't be overwritten or deleted by any user, including the root user", and the retention period can't be shortened. Governance mode can be bypassed by users with a special permission.

**Azure immutable blob storage and Google Cloud Bucket Lock** work by retention policy: once the policy is locked, it can't be removed or shortened, only extended. In Google's words, objects "can only be deleted or replaced once their age is greater than the retention period".

**Where they fit best.** If your agents already run in one cloud, you need years of retention, or a regulator expects WORM storage, a locked bucket is the plain, proven choice. The limit is the trust model: the protection lives inside one provider's account, and an outside reviewer has to rely on the provider and on how the owner set up that account. [Write-once storage for AI agent records](/learn/write-once-storage-for-ai-agent-records/) covers modes, locks and compliance statements.

## 2. Tamper-evident logs and databases

**Certificate Transparency-style transparency logs.** [RFC 9162](https://www.rfc-editor.org/rfc/rfc9162) defines append-only public logs of TLS certificates, in a manner "that allows anyone to audit certification authority (CA) activity". Inclusion proofs show an entry is in the log; consistency proofs show the log has only grown.

**Sigstore Rekor.** Rekor is Sigstore's transparency log, "an immutable, tamper-resistant ledger of metadata generated within a software project's supply chain". Auditors can monitor it to check that entries are never changed or removed. It is built to "record signed metadata", not to hold large records: uploads to the public instance have a 100 KB size limit, and the project points larger needs to your own instance.

**immudb.** A database whose makers say "Data can only be added, never changed or deleted", and whose clients verify integrity "without having to trust the server". It calls itself open source, but is licensed under the Business Source License 1.1.

**Amazon QLDB**, often named here, is on AWS's list of services in full shutdown (31 July 2025).

**Where they fit best.** If you need to prove ordering and completeness (this entry exists, nothing was removed, this came before that), a transparency log does what content addressing alone cannot. A transparency log for fingerprints plus separate storage for the records is a serious alternative to our approach. immudb fits when you want a verifiable database under your own control.

## 3. Content-addressed decentralised storage

**Swarm.** A chunk's address is computed from its content, so a changed record gets a new address and the original stays where it was. Each chunk is stored by several nearby nodes. Storage is paid for with a postage stamp; when its batch runs out of balance, nodes can remove the chunks. So a record on Swarm cannot be changed in place until its stated expiry. [Is Swarm write-once storage?](/learn/is-swarm-write-once-storage/) explains expiry.

**IPFS.** IPFS also uses content addressing: "Any difference in the content will produce a different CID." But content addressing by itself does not keep anything. The IPFS docs say adding content "doesn't guarantee that any content is persistently available"; nodes garbage-collect data unless it is pinned.

**Where they fit best.** When the person checking should not have to trust the owner's account: whoever holds the address can fetch the record and recompute it. Content addressing gives no ordering or completeness; for that you need an anchor on a blockchain or a transparency log.

## Side by side

| | What it protects against | Who can check | What trust it needs | Retention |
|---|---|---|---|---|
| Write-once buckets | Overwrite or deletion within the retention period | Whoever the owner gives access or a copy | The provider and the owner's account setup | Set by policy; locked policies extend, never shorten |
| Transparency logs (CT, Rekor) | Undetected removal, change or reordering of entries | Anyone who can query the log | The operator for availability; monitors for honesty | The log's; built for metadata, not large records |
| immudb | Changes to written data, detectable by clients | Clients with access | The operator for availability; clients verify integrity | As long as the operator keeps it |
| Swarm | Change in place: a changed record gets a new address | Whoever holds the address | The network to keep data while the stamp is funded | Until the postage stamp expires |
| IPFS | Undetected change: a changed record gets a new CID | Whoever holds the CID | Whoever pins it | Only while someone pins it |

## Where the Datafund Provenance Toolkit fits

The Datafund Provenance Toolkit is open source and in pre-release, meant for testing, on a test network (Base Sepolia). Mainnet anchoring and payments are not live.

Available today on the test network: it stores a record on Swarm and returns its address and fingerprint (the SHA-256 hash), with an optional notary signature and timestamp from the gateway; it can anchor the fingerprint, meaning write it on a blockchain through a smart contract; and it links records with transformation and merge links. During testing the notary is Datafund's public gateway, which is [open source](https://github.com/datafund/swarm_connect); its timestamp rests on trusting whoever runs it, unless the fingerprint is anchored.

Proposals, not built: the runtime (not the agent) writing the record, and sealed (encrypted) records.

The toolkit is for trying records that reviewers can check without relying on the owner's account; for regulated retention or proof of ordering, the tools above fit better. 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 [developer post](/blog/how-to-give-an-ai-agent-a-record-it-cant-rewrite/) shows the code, and [dataprovenance.app](https://dataprovenance.app) is the quickest test.

One limit applies to every tool here: each shows a record was not changed **after** it was stored, not that it is true or complete ([what agent provenance proves](/learn/what-is-agent-provenance/)). An agent that writes its own record can write anything first. The [story post](/blog/agents-using-swarm-cant-rewrite-their-history/) covers why that matters, and [how an auditor verifies AI agent transcripts](/learn/how-an-auditor-verifies-ai-agent-transcripts/) walks through a check.

## Questions people ask

**What tools exist for AI agent provenance?**
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, open source and in pre-release, stores agent records on Swarm so the people entitled to check them can confirm nothing changed.

**Is S3 Object Lock enough for AI agent records?**
Often, yes. In compliance mode no user, including the root user, can overwrite or delete a locked version before its retention date. An outside reviewer still has to trust the provider and the account setup; a fingerprint kept somewhere the owner does not control closes much of that gap.

**What is the difference between a transparency log and content-addressed storage?**
A transparency log, such as Certificate Transparency or Rekor, proves an entry exists and that the log has only grown, but holds fingerprints and metadata rather than large records. Content-addressed storage such as Swarm keeps the record itself at an address computed from its content, but says nothing about what else was stored, or in what order.

## Sources

- Amazon S3 Object Lock: https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
- Azure immutable storage for blob data: https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-storage-overview
- Google Cloud Storage, Bucket Lock: https://docs.cloud.google.com/storage/docs/bucket-lock
- Certificate Transparency, RFC 9162: https://www.rfc-editor.org/rfc/rfc9162
- Sigstore Rekor overview: https://docs.sigstore.dev/logging/overview/
- Sigstore Rekor repository (public instance upload limit): https://github.com/sigstore/rekor
- immudb: https://immudb.io/
- immudb repository: https://github.com/codenotary/immudb
- AWS, services in full shutdown (Amazon QLDB): https://docs.aws.amazon.com/general/latest/gr/full_shutdown_services.html
- Swarm, chunk storage and content addressing: https://docs.ethswarm.org/docs/concepts/DISC/
- Swarm, postage stamps: https://docs.ethswarm.org/docs/concepts/incentives/postage-stamps/
- IPFS, content addressing: https://docs.ipfs.tech/concepts/content-addressing/
- IPFS, persistence and pinning: https://docs.ipfs.tech/concepts/persistence/
- Datafund Provenance Toolkit: https://github.com/datafund/provenance
- Swarm gateway (open source): https://github.com/datafund/swarm_connect
- dataprovenance.app: https://dataprovenance.app