Audit Chain
Audit Chain is an open-source Drupal module for tamper-evident audit records. It gives security and compliance operators a narrow evidentiary log whose later insertion, deletion, or alteration can be detected by an independent verification pass.
The operator problem
Ordinary application logs can show what an application says happened, but they do not prove that earlier rows were left unchanged. Audit Chain links every entry to the previous entry's hash. Optional HMAC signing means quietly repairing a modified chain also requires signing-key access; optional metadata encryption protects the detail stored with each record.
What the module implements
- Reusable logging service for any Drupal module, with channel, operation, actor, timestamp, network context, promoted entity identifiers, and metadata covered by the chain.
- Independent Drush verification through
drush audit-chain:verify; a nonzero exit status is the automation contract for monitoring and deployment gates. - Distinct failure reporting for a broken chain versus intact but unsigned entries, because those conditions require different operator responses.
- Signing-key rotation with explicitly trusted retired keys, and encryption-profile migration without silently rewriting evidence.
- Request-level collection and deduplication so access hooks can record meaningful events without turning per-field checks into write-amplified noise.
- Structured log streaming to the
audit_chainchannel for forwarding to syslog, Monolog, or a SIEM. - Operational status checks that raise an error when a configured signing key no longer resolves, and warn when encrypted rows still depend on a retired profile or when a historical prefix seal is active.
How integrity is preserved
The module keeps one global sequence rather than independent per-channel chains. Events from different consumers are interleaved, so deleting one channel's records still breaks the shared chain. Appends are serialized with a lock, while the request-scoped collector writes after the response to keep that lock off the operator's critical path. Each channel is bound into the canonical payload, preventing a row from being reassigned to a different consumer without detection.
Verification distinguishes three materially different states: altered content or ordering, intact rows written without the configured signing key, and a broken historical prefix seal. The Drush command reports those states separately while preserving a simple nonzero failure contract for automation. When unverifiable legacy history must be retained, an operator can seal its stored hashes as a new local genesis point; the seal does not claim the old content was trustworthy, only that future changes to that frozen prefix become detectable.
Honest boundaries
Audit Chain does not make deletion impossible; it makes deletion evident at the next verification. It orders one sequence in one database, not events across databases or servers. It is not a replacement for operational logging such as dblog or syslog. Unsigned history cannot be signed retroactively. A prefix seal freezes unverifiable history but does not prove that history was accurate. Encrypted metadata must be re-encrypted before its old Encryption Profile is removed.
Where it fits
The module was extracted from MCP Sentinel, where it began as the audit trail for governed AI-agent traffic. The mechanism also applies to configuration changes, permission grants, sensitive-record access, controlled file delivery, and break-glass operations. It supports our Compliance & Security Governance, AI Governance & MCP Integration, and Observability & Monitoring Architecture practices.
Install and inspect
composer require drupal/audit_chain
drush en audit_chain
drush audit-chain:verifyAudit Chain supports Drupal 10.6+ and 11.3+ on PHP 8.1 or newer. It requires the Drupal Key and Encrypt modules; sites that use signing should keep key material outside the database through an appropriate Key provider.