An audit log needs a way to show that it changed

A database row can record a permission change. By itself, it does not show whether someone edited that record afterward. An audit trail needs an integrity check as well as an event history.

Audit Chain provides that check for Drupal modules. Each record incorporates its own content and the preceding record's hash. A verification pass can detect inconsistencies in the retained chain. When an HMAC signing key is configured, rewriting a consistent signed chain also requires access to that key.

Check integrity and signing separately

An intact sequence of unkeyed hashes is different from a sequence authenticated with a separately held key. An actor who can rewrite the database can recompute unkeyed hashes. A verifier needs to distinguish that condition from a broken record sequence.

Audit Chain's verification command reports broken and unsigned records separately and returns a nonzero exit status for either condition. That makes verification usable by monitoring without relying on an operator to notice a sentence in command output. An unsigned record does not become signed merely because the key is repaired later.

The evidence boundary matters

A signing key stored with the database weakens the separation the signature is meant to provide. Keep key access deliberate, test that it resolves in the writing environment, and retain evidence outside the system being audited when independent assurance is required.

Even a valid chain cannot establish that the application recorded every event it should have recorded. It also cannot, by itself, prove that a complete surviving history has been supplied to the verifier. External evidence retention and known checkpoints help an operator reason about those limits.

A shared primitive for different consumers

The module originated in the audit implementation used by MCP Sentinel and is available independently. Other Drupal modules can use the logging service without adopting an AI-governance integration.

The project documentation describes the logger and verification workflow. Treat the result as evidence about recorded data under a stated trust model, rather than a blanket claim that the whole system is tamper-proof.