AI Audit Log Immutability: Object Lock, WORM Storage, and the Storage-Layer Contract a Regulator Accepts

The reconstruction test a regulator applies during an AI audit assumes the log record on disk is the log record that was written at the moment of decision. That assumption fails when the log lives in a storage layer that permits modification by the same operator who runs the AI application. Application logs on the same host as the AI application are the common failure case, and Article 12 of the EU AI Act is the primary rule that surfaces the failure during an audit.

The Article 12 record-keeping mandate does not use the word immutable, but the reconstruction requirement assumes immutability at the storage layer. The regulator asks: reconstruct the AI decision on this date, for this identity, with this input. The regulator does not accept a reconstruction that depends on the AI application's cooperation. The log record has to stand independently.

I want to walk through the immutability contract at the storage layer, the implementations available across the major cloud providers, and the audit-record shape that verifies immutability by construction.

TL;DR

• Article 12's reconstruction test assumes the log on disk is the log written at decision time, and that assumption fails when the AI application's operator can modify the storage layer.
• The storage contract has three properties: write-once enforcement at the storage API, retention that even the root account cannot shorten, and a content hash that makes any modification detectable.
• S3 Object Lock compliance mode, Azure locked immutability policies, and GCS bucket lock satisfy the contract. The governance-tier modes do not.
• Hash chains, content-addressed prompt storage, write-path separation, and a scoped auditor read path are what turn a storage feature into evidence a regulator accepts.

The immutability contract

The immutability contract has three properties.

Write-once: once a log record is written to storage, no operator can modify the content. The storage backend enforces the constraint at the storage API level, not at the application discipline level.

Retention-locked: each record persists for its full retention window regardless of who has access. Delete operations against the record fail inside that window.

Cryptographically verifiable: each record carries a hash of its own content, stored either inline or in a separate verification stream. The auditor computes the hash of the stored record and confirms the match. Any modification breaks the hash and is detectable on inspection.

The three properties combined produce a record that satisfies the reconstruction requirement under Article 12, the tamper-resistance expectation under ISO 42001 Annex A.10.1, and the chain-of-custody expectation under SOC 2 CC7.3.

Object storage implementations

Three cloud providers ship object storage with immutability features that satisfy the contract.

S3 Object Lock

S3 Object Lock supports two retention modes.

Compliance mode: the object cannot be deleted or overwritten by any user, including the root account, for the duration of the retention window. Shortening it requires contacting AWS Support through a documented process. This mode is the one a regulator expects for AI audit logs. The same property also makes compliance mode the standard ransomware defense for log buckets. An attacker holding even admin-level credentials cannot delete the objects or overwrite them with encrypted versions before the window expires, so the audit trail survives the incident it needs to record.

Governance mode: the object cannot be deleted or overwritten by users without the s3:BypassGovernanceRetention permission, and an authorized user can shorten retention. This mode is less operationally strict and weaker for compliance, because the bypass permission is itself a target for attackers.

The bucket has to be created with Object Lock enabled at creation time. Existing buckets cannot be converted after the fact. New AI audit log buckets should default to Object Lock in compliance mode with a retention period at least matching the Article 19 six-month floor.

Azure Blob immutability

Azure Blob Storage immutability policies support two modes.

Locked policy: the immutability policy cannot be shortened or removed once locked. This mode is the compliance equivalent of S3 Object Lock compliance mode.

Modifiable policy: users with the appropriate role can still modify the policy, which makes it unsuitable for compliance-grade audit logs.

The Azure implementation supports both container-level and version-level immutability policies. Container-level policies apply to all blobs written to the container after the policy is set. Version-level policies apply to individual blob versions, which supports the pattern of immutability on the log record and mutability on the surrounding metadata.

GCS bucket lock

GCS bucket lock supports a single mode that is functionally equivalent to S3 Object Lock compliance mode. Once the retention policy is locked on a bucket, it cannot be shortened. Objects written during that window cannot be deleted before it expires.

The cryptographic layer

Object storage immutability protects the object bytes. It does not by itself confirm that the bytes represent the AI decision that occurred at the moment of the record. The cryptographic layer adds that confirmation.

Each audit log record includes a content_hash field with the SHA-256 hash of the record content (excluding the hash field itself), computed at the moment of decision. A minimal record carries:

• record_id: a unique identifier for the decision.
• occurred_at: the timestamp of the AI decision itself.
• recorded_at: the timestamp the inspection layer wrote the record, typically a few milliseconds later.
• content_hash: the SHA-256 of the record content excluding the hash field, for example sha256:e8f9a2b1....
• identity, request, policy, and decision: who called, what was sent, which policy applied, and what the outcome was.

An auditor computes the SHA-256 of the record excluding the content_hash field and confirms the match. A modification to any field breaks the match and is detectable without external state.

The chain-of-custody variant extends this to a hash chain. Each record includes the content hash of the prior record, producing a linked list where a modification to any historical record breaks every subsequent hash. The chain is the AI-audit equivalent of the transaction log pattern in accounting systems.

Content-addressable prompt and response references

Prompts and responses often exceed the size limits practical for inline storage in the audit record. The pattern is to store the prompt and response content in a separate object store with a content-addressable pointer in the audit record. The pointer carries three fields: the storage backend (object-store), the content's SHA-256 hash, and the reference used to fetch it (for example s3://ai-audit-prompts/2026/07/03/1a2b3c4d.txt).

The prompt object is stored at a path derived from the hash. The auditor retrieving the object confirms the hash matches the reference in the record. A modification to the prompt object produces a different hash and no longer matches the reference. The prompt store operates under the same Object Lock policy as the audit record store.

Deterministic replay needs immutable inputs

Replaying an agent's decision means rerunning the model call with the same prompt, the same model version, and the same parameters, then comparing the output against what the record says happened. Teams do this after an incident to answer whether the model or the surrounding pipeline produced a bad outcome. The technique only proves something when the inputs are provably unchanged. A replay against a prompt store the operator could have edited afterward proves nothing, because the input you replayed may not be the input the agent sent.

The content-addressed store is what closes that gap. The record's hash pins the prompt bytes, the record header pins the model version, and the hash chain pins the sequence, so a multi-step agent trajectory replays step by step in the order it ran. Model nondeterminism still applies: at nonzero temperature the same input yields different outputs, and providers retire model versions on a schedule, so a replay compares behavior rather than reproducing it byte for byte. The immutable record is what makes that comparison meaningful instead of circular.

Retention expiry and verified purge

Immutability and deletion sit in deliberate tension, and the purge side has to be as verifiable as the retention side.

Time-based expiry is the simple half. Object Lock retention is set per object or by bucket default, and once the window expires a lifecycle rule deletes the object. The deletion events land in the provider's own audit trail (CloudTrail on AWS, the Azure Storage resource log, Cloud Audit Logs on GCS), which gives you a record of what was purged and when.

Crypto-shredding handles the harder case, where a deletion duty arrives before the retention window ends. Records encrypted under a customer-managed key per data subject or per retention class become unrecoverable the moment that key is destroyed, without touching the locked object. This is the standard answer to a GDPR erasure request against WORM-stored audit logs: the bytes remain until the window expires, the content is gone the moment the key is.

A verified purge is the combination of the two evidence trails: the provider's deletion log entry, or the key-destruction record in the KMS audit log, matched against the retention policy that justified the timing. An auditor should be able to confirm both that records survived the full window and that nothing survived past its lawful end.

Write path separation

The AI application does not have write access to the audit log store. The inspection layer writes the audit records under its own identity. The AI application's IAM policy denies writes to the audit log bucket, and the deny is explicit rather than an omission.

The write-path separation is the difference between a log the AI application controls and a log the inspection layer controls. An attacker who compromises the AI application cannot modify the audit records because the application's identity has no path to the storage. The separation is enforced at the cloud provider's IAM layer, which is the same layer that enforces every other cross-account resource protection.

Read path for auditors

The auditor's read path is separate from the application's write path. Auditors read from a role scoped to the audit log bucket with read-only permissions. The read role does not have permissions on any other AI application resource. The auditor can retrieve records without any ability to modify them.

For regulator-driven audits under Article 12, the read role is often provisioned per audit with a defined scope and time bound. The audit process is documented, the auditor identity is recorded, and the read events themselves are logged in the cloud provider's audit trail.

Compliance implications

The immutability contract at the storage layer produces evidence artifacts across multiple frameworks.

The EU AI Act Article 12 record-keeping mandate requires records the regulator can reconstruct. The immutable, hash-verified record satisfies the reconstruction requirement by construction. For the provider-side logging setup that feeds these records, see the Article 12 logging implementation guide.

ISO 42001 Annex A.10.1 sets the controls for record integrity and requires evidence that records have not been tampered with. The hash chain and Object Lock combination produces that evidence.

SOC 2 CC7.3, the security-event evaluation criterion, requires evidence that events are captured and preserved. The write-once, retention-locked audit log is the evidence, and the wider control mapping sits in SOC 2 CC controls for AI.

DeepInspect

This is exactly what DeepInspect does. DeepInspect sits inline between your users or agents and the LLM APIs they call. Every AI decision produces a log record written to an immutable object store under the inspection layer's identity. The record includes the content hash, and the hash chains link records into a verifiable sequence, the same pattern described in signed audit logs for AI requests.

The write path from the inspection layer to the audit store is isolated from the AI application. The read path for auditors is scoped to the audit store and does not carry any other permissions. The reconstruction test a regulator applies during an audit finds the records, the hashes, and the chain.

Book a demo today.