How do I make an AI agent's audit log append-only so even an admin can't silently delete entries?

What should I check, step by step?

1. Write down who you are protecting the log from: the agent, the app's own service account, a database admin, a cloud admin. Each of these can remove a different layer, so each needs a layer it can't touch.

2. Give every entry a sequence number, a timestamp and the hash of the previous entry (seq 1 points at 64 zeros). Sign each entry with a key the log's admin doesn't hold, such as the agent's own key kept in a separate secret store.
3. In the database, give the writer role INSERT only. Revoke UPDATE, DELETE and TRUNCATE from it and from the app. Treat this as protection against the agent and the app, not against the database's superuser or owner.
4. Every hour or every N entries, write the closed batch and its last hash to a separate bucket with write-once retention: S3 Object Lock in compliance mode (not governance mode, which a user with s3:BypassGovernanceRetention can override), or a locked Cloud Storage retention policy. Put that bucket in a different account, owned by someone other than the log's admin.
5. Commit the chain head outside your systems on the same schedule: recorder_checkpoint on Rightshold, an RFC 3161 timestamp, an OpenTimestamps proof, or a copy to your auditor. Without this, an admin can delete the newest entries and the remaining chain still looks whole.
6. Check the chain on a schedule from a system the admin doesn't control: no missing sequence numbers, every prev hash matches, every signature verifies, and the newest entry is at or after the last committed head.
7. Alert when entries stop arriving or the checkpoint job fails. Silence is how a quiet deletion or a disabled logger looks from outside.
8. Write corrections as new entries that point at the entry they correct. Never edit an old entry, even to fix a typo.

Why can't database permissions stop an admin from deleting an AI agent's audit log entries?

PostgreSQL's documentation on role attributes says a database superuser bypasses all permission checks except the right to log in. REVOKE and triggers stop the application and the agent. They don't stop the person who runs the database, and they don't stop a restore from an older backup.

• Cloud storage has the same split. S3 Object Lock in governance mode can be overridden by a user with s3:BypassGovernanceRetention. In compliance mode, AWS says a locked object version can't be overwritten or deleted by any user, including the root user, and the only way to delete it early is to delete the AWS account. A locked Cloud Storage retention policy can't be removed or shortened.
• NIST SP 800-53 Rev. 5 control AU-9 (protection of audit information) lists the same layers as enhancements: store audit records on a separate system, protect them cryptographically, and limit who can manage them to a small group of privileged users.

How do I detect deleted or cut-off entries in an AI agent's audit log?

A hash chain makes edits and deletions in the middle visible: remove entry 41 and entry 42's prev hash no longer matches anything, or the sequence jumps from 40 to 42. It can't catch the newest entries being cut off, because what is left still chains.

• That is why the head has to leave your systems. AWS CloudTrail does this for its own logs: every hour it delivers a signed digest file that lists the last hour's log files with a hash of each, and each digest carries the signature of the one before. AWS says this lets you tell whether a log file was deleted or changed, or assert that no log files were delivered in a period.
• Certificate Transparency (RFC 9162) uses the same idea at internet scale: an append-only Merkle tree whose signed tree heads are checked by outside monitors, so a log can't quietly drop an entry it has already published.

How often should I commit an AI agent's audit log head outside my systems?

On Rightshold, the flight recorder keeps your log on your side. Each entry is {seq, at, kind, summary, prev}, hashed as sha256('rec:' + canonical(entry)) and signed with the agent's key. recorder_checkpoint publishes only the head hash and the entry count, signed by the agent, as a ledger entry.

• Checkpoints only move forward: one at or below the last committed seq is refused with checkpoint_not_newer, so a committed head can't be wound back. GET /v1/recorder/{RS number} shows the latest head to anyone.
• How often you commit sets the window you can lose. Entries written after the last checkpoint can still be removed without a trace, so commit at least as often as you would notice a gap: every hour, every 100 entries, and always right after a high-risk action.