Does S3 Object Lock in compliance mode prevent AWS Support from deleting objects?

Compliance mode limits the ability to shorten retention. AWS documents a process for the account root to reduce retention on objects under compliance mode, and the process requires interaction with AWS Support. The pattern is not zero-modification, and the process is auditable through AWS CloudTrail. For most regulatory audit purposes, compliance mode meets the reconstruction expectation.

How large can the audit log volume get?

Audit log volume scales with AI request volume. A deployment doing 100,000 AI requests per day at 4 KB per record produces roughly 400 MB per day of audit log content, plus the prompt and response content in the object store. Six months of retention at that volume is around 75 GB of records plus the prompt and response objects, which at typical prompt sizes runs into single-digit terabytes.

Does the hash chain add latency to the write path?

The hash chain requires the writer to know the hash of the previous record before writing the current record. In a single-writer configuration, the hash is available in memory and the added latency is negligible. In a multi-writer configuration, the chain runs per partition, and each partition has its own single-writer path. The added latency stays under a millisecond in typical configurations.

What happens if an auditor requests reconstruction after the retention period expires?

Objects deleted after the retention period expires are not recoverable. The retention floor under Article 19 is six months minimum. Deployments subject to longer sectoral rules configure the retention period to match the sectoral ceiling. Regulator requests that arrive after the retention period expires are answered with the retention policy documentation and the confirmation that the records have been deleted per the policy.

Can the inspection layer support customer-managed encryption keys on the audit store?

Yes. The audit store can be configured with customer-managed encryption keys (S3 SSE-C or SSE-KMS with customer keys, Azure customer-managed keys, GCS customer-managed encryption keys). The immutability contract is orthogonal to the encryption contract, and both apply to the audit records.

Does the hash-chain design require a specific hashing algorithm?

SHA-256 is the default because it is the current industry standard for audit records and satisfies the collision resistance expectations for the retention windows involved. The record structure allows the algorithm to be pinned in a header field, which lets the deployment upgrade to a stronger algorithm without invalid

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. The assumption is not automatic. It 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.

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. The log record persists for the full retention period regardless of who has access. Delete operations against the record fail during the retention window.

Cryptographically verifiable. The log record includes a hash of its own content, and the hash is 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 period. Retention can only be shortened by contacting AWS Support and following a documented process. This mode is the one a regulator expects for AI audit logs.

Governance mode. The object cannot be deleted or overwritten by users without the s3:BypassGovernanceRetention permission. Retention can be shortened by an authorized user. This mode is less operationally strict but weaker for compliance because the bypass permission is 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. The policy can be modified by users with the appropriate role. This mode is not suitable 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 to the bucket during the retention period cannot be deleted before the period 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). The hash is computed at the moment of decision and included in the record.

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 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.

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.

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

The SOC 2 CC7.3 security-event evaluation criterion requires evidence that events are captured and preserved. The write-once, retention-locked audit log is the evidence.

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 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.