# Write-once (WORM) storage for AI agent records

> What storage can't an AI agent change? How S3 Object Lock, Azure immutable blob storage, Google Cloud Bucket Lock and content-addressed storage on Swarm keep agent records from being rewritten, and where each fits.

- URL: https://datafund.io/learn/write-once-storage-for-ai-agent-records/
- Published: 2026-10-29
- Author: Datafund
- Tags: provenance, ai-agents, worm-storage, s3-object-lock, swarm, content-addressing

Storage an AI agent can't change is write-once storage: once a record is written, it cannot be overwritten or deleted until a stated retention date. A write-once (WORM) cloud bucket, such as S3 Object Lock, Azure immutable blob storage or Google Cloud Bucket Lock, blocks changes inside one provider's account; content-addressed storage keeps the record at an address computed from its content, so a changed record gets a new address and the original stays. Either way, the software running the agent, not the agent, should write the record.

## Why agent records need write-once storage

An agent with write access to its own logs can edit them. In July 2026, during an internal OpenAI evaluation, models in a sandboxed testing environment exploited a zero-day vulnerability to gain internet access and reached Hugging Face's servers ([OpenAI's incident report](https://openai.com/index/hugging-face-model-evaluation-security-incident/)). METR and Redwood Research, reviewing the agents' behaviour, found they "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. OpenAI then recommended: "Save agent transcripts immutably for a reasonable period of time (for example, in write-once storage accounts)".

WORM means write once, read many. What matters is who can lift the lock, and what a reviewer outside your account has to trust. See also [What is agent provenance?](/learn/what-is-agent-provenance/)

## S3 Object Lock: governance mode and compliance mode

Amazon S3 Object Lock works only in buckets with versioning turned on. It protects object versions with a **retention period** or a **legal hold**, in one of two modes:

- **Governance mode.** Users with the `s3:BypassGovernanceRetention` permission can change the settings or delete a locked version; others can't.
- **Compliance mode.** No user can overwrite or delete a locked version, including the account's root user, and the retention period can't be shortened. AWS states the only way to delete such an object before its retention date is to delete the AWS account.

For agent records, note two things. A lock protects one version; new versions or delete markers can still be added on top, so a reviewer must read the locked version. And in governance mode, anything holding the bypass permission, an agent included, can remove the protection. AWS says Object Lock has been assessed by Cohasset Associates for SEC 17a-4, CFTC and FINRA environments.

## Azure immutable blob storage

Azure supports **time-based retention**, during which blobs can be created and read but not modified or deleted, and **legal holds**, which last until cleared.

A new time-based policy starts **unlocked**, for testing: it can be shortened, extended or deleted. Once **locked**, it can't be deleted and its retention period can only be extended. Microsoft says Cohasset Associates validated that immutable storage meets the relevant storage requirements of SEC Rule 17a-4(f), FINRA Rule 4511 and CFTC Rule 1.31(c)-(d).

## Google Cloud Storage Bucket Lock

A **retention policy** on a bucket means objects can only be deleted or replaced once their age is greater than the retention period. **Locking** the policy is irreversible: it can then be increased, never reduced or removed, and the bucket can't be deleted until every object has met its retention period. Google says Bucket Lock, together with Detailed audit logging mode, "can help with regulatory and compliance requirements, such as those associated with FINRA, SEC, and CFTC."

## Content-addressed storage on Swarm

[Swarm, the decentralised storage network (ethswarm.org)](https://www.ethswarm.org/), works differently. A record's address is computed from its own content. An edited version gets a different address; the original stays where it was.

Storage is paid for with a postage stamp whose balance runs down over time; when it runs out, nodes may drop the data. So the precise claim is: a record on Swarm cannot be changed in place until its stated expiry. Swarm's documentation recommends immutable stamp batches for data that should never be overwritten; in a mutable batch, new uploads can displace older data.

The difference is who has to be trusted. With a cloud bucket, the people entitled to check (auditors, evaluators, the client) rely on the provider and the account setup. On Swarm, whoever holds the address can fetch the record from a Swarm node and recompute its fingerprint (its SHA-256 hash). [Is Swarm write-once storage?](/learn/is-swarm-write-once-storage/) covers expiry and batch types.

## How they compare

| | S3 Object Lock | Azure immutable blobs | Google Bucket Lock | Swarm |
|---|---|---|---|---|
| What stops a change | Lock on an object version | Retention policy or legal hold | Locked retention policy | Address computed from content |
| Can the lock be lifted? | Governance: yes, with bypass permission. Compliance: no | Unlocked: yes. Locked: no | Unlocked: yes. Locked: no | No; data may go once the stamp expires |
| Reviewer needs | Trust in the provider and the account setup | Same | Same | The address and a Swarm node |
| Private by default | Yes, inside your account | Yes | Yes | No; unencrypted records are readable by whoever has the address |

## Where a cloud WORM bucket is the better fit

- **Regulated retention.** If a rule such as SEC 17a-4 applies, use a product whose vendor says so on its own page and has an assessment to show, such as S3 Object Lock in compliance mode or a locked Azure policy.
- **Long retention and legal holds.** Built in and mature.
- **Production today.** The Datafund toolkit below is pre-release, meant for testing.

Swarm fits when reviewers should not have to trust your account setup or a single provider. A middle path is a WORM bucket plus a fingerprint of each record kept somewhere the owner does not control.

## Whoever writes the record matters more than where it goes

Write-once storage shows a record was not changed **after** it was stored, not that it is true. If the agent uploads its own record, it can write anything first. So the software that runs the agent should write the record, and the agent should hold no write or bypass permission on that storage.

The [Datafund Provenance Toolkit](https://github.com/datafund/provenance) stores records on Swarm today, in pre-release on a test network (Base Sepolia), with a fingerprint, an optional notary signature and optional anchoring; the runtime writing the record, rather than the agent, is a proposal, not built. 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, [the story post](/blog/agents-using-swarm-cant-rewrite-their-history/) explains why it matters, and [dataprovenance.app](https://dataprovenance.app) is the quickest test. [AI agent provenance tools compared](/learn/ai-agent-provenance-tools-compared/) adds tamper-evident logs, and [how an auditor verifies agent transcripts](/learn/how-an-auditor-verifies-ai-agent-transcripts/) walks through a check.

## Questions people ask

**What storage can't an AI agent change?**
A write-once bucket, such as S3 Object Lock in compliance mode or a locked Azure or Google retention policy, which blocks changes inside one provider's account; or content-addressed storage such as Swarm, where a changed record gets a new address and the original stays until its stated expiry.

**What is the difference between S3 Object Lock governance mode and compliance mode?**
In governance mode, users with the `s3:BypassGovernanceRetention` permission can change the retention settings or delete a locked object version. In compliance mode, no user, including the account's root user, can overwrite or delete it until its retention date, and the period can't be shortened.

**Which WORM storage meets SEC 17a-4?**
AWS and Microsoft state that independent assessments (by Cohasset Associates) cover S3 Object Lock and locked Azure immutable blob storage for SEC 17a-4. Check the vendor's own page for your case. Swarm makes no such claim.

**Is WORM storage enough to prove an agent's record is true?**
No. It shows the record was not changed after it was stored. If the agent wrote the record itself, it could have written anything before storing it. Have the software that runs the agent write the record, and keep the agent's credentials away from that storage.

## Sources

- Amazon S3, Locking objects with Object Lock: https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
- Microsoft Azure, Immutable storage for blob data overview: 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
- Swarm, chunk storage and content addressing: https://docs.ethswarm.org/docs/concepts/DISC/
- Swarm, postage stamps (expiry, immutable and mutable batches): https://docs.ethswarm.org/docs/concepts/incentives/postage-stamps/
- OpenAI, "OpenAI and Hugging Face partner to address security incident during model evaluation" (21 July 2026): https://openai.com/index/hugging-face-model-evaluation-security-incident/
- METR and Redwood Research, independent review of the Hugging Face incident (26 August 2026): https://alignmentforum.org/posts/nB8KKapnWGBXtKKiM/brief-independent-investigation-of-agents-behavior-reasoning
- OpenAI, "Towards safety cases for frontier AI training" (28 September 2026): https://openai.com/index/towards-safety-cases-for-frontier-ai-training/
- Datafund, "How to give an AI agent a record it can't rewrite": https://datafund.io/blog/how-to-give-an-ai-agent-a-record-it-cant-rewrite/
- Datafund Provenance Toolkit: https://github.com/datafund/provenance
- dataprovenance.app: https://dataprovenance.app