Audit Chain
Tamper-evident audit logging for Drupal, usable by any module.
Each entry's hash covers its own content and the previous entry's hash. Any later insertion, deletion or edit breaks that chain and is detectable by an independent verification pass. With an HMAC key configured, forging a repair also requires the key, so an edit made straight in the database cannot be quietly papered over.
The difference that matters: not "the application says it logged that", but a record that can be shown not to have been altered since it was written.
Using it
Inject Drupal\audit_chain\AuditChainLoggerInterface and write an entry:
\Drupal::service('audit_chain.logger')->log('personnel', 'field_read', ['entity_type' => 'node', 'id' => $node->id(), 'field' => 'field_salary']);
entity_type, bundle, id and label become indexed columns; every other key is serialised into the metadata column. All of it — plus the actor, timestamp, IP and user agent — is covered by the hash.
The first argument is the channel, a short name identifying the consumer. It is bound into the hash, so an entry cannot be re-attributed to a different channel after the fact — which matters when one channel is the thing being audited.
Verifying
drush audit-chain:verify
The exit code is the contract: non-zero means the chain does not verify. Wire it into monitoring or a deploy gate without parsing output.
Two constraints for consumers
Do not log per access check. A hook like hook_entity_field_access() fires per field, per entity, per render. An entry each time produces a chain nobody can read and a write-amplified request. Dedupe per request and flush once at kernel.terminate.
Rotating the encryption profile orphans existing entries. Metadata encrypted under one profile cannot be decrypted after switching to another, and the chain is computed over the plaintext — so those entries stop verifying, and the failure looks exactly like tampering. Export or re-encrypt first.
Configuration
Configuration → System → Audit Chain:
- Signing key — a Key entity. Empty means plain SHA-256, which detects accidental corruption and careless edits but not someone with database access recomputing the chain. Store the key outside the database.
- Encryption profile — encrypts metadata at rest. See the rotation caveat above.
- Stream entries — emits each entry to the
audit_chainlogger channel as a structured record, so syslog or Monolog can forward it to a SIEM without polling.
What it does not do
- It does not make deletion impossible. Nothing at the application layer can. It makes deletion evident: the seam shows at the next verification.
- It does not order events across servers. The chain is one sequence in one database.
- It does not replace dblog or syslog. Those are operational logs. This is an evidentiary one, and deliberately narrower.
Origin
Extracted from MCP Sentinel, where it had grown up as the audit trail for AI-agent traffic. It was never specific to that: personnel-record reads, permission grants, configuration changes and break-glass logins all want the same guarantee, and none of them should require an AI-governance module to get it. MCP Sentinel remains its first consumer.