# HMAC Hash Chains: Cryptographic Proof for AI Decision Logs

When an AI system makes a decision—approving a credit application, routing a medical referral, executing a trade—the decision is gone a microsecond later. What remains is a record: the inputs, the model's choice, the timestamp, the authorization gates that approved it. If that record lives only in a mutable database, it is not evidence. It is a claim. An HMAC hash chain transforms a claim into proof.

HMAC (Hash-Based Message Authentication Code) is a cryptographic primitive that's been battle-tested since the 1990s in banking, TLS, and authentication protocols. Yet it remains underused in AI audit trails. This article explains what HMAC chains are, why they work, and how to use them to build AI systems that prove their own behavior.

What an HMAC Is

An HMAC is a signature that proves two things:

  1. Authenticity: the record came from a specific source (in this case, your AI system) and was created with a secret key only that source holds
  2. Integrity: the record has not been altered since it was signed

To create an HMAC, you:

  1. Take the message (the decision record: inputs, outputs, timestamp, etc.)
  2. Combine it with a secret key that only your system knows
  3. Hash the combination using SHA-256 (or another strong hash function)
  4. The resulting hash is the HMAC

The HMAC is 32 bytes (256 bits), roughly the size of a checksum. It looks random—there's no way to forge it without the secret key.

The magic is that changing even one bit of the record breaks the HMAC. If a bad actor alters the decision from "APPROVE" to "DENY," the HMAC no longer matches. An auditor can verify the signature; if it fails, the record has been tampered with.

Why HMAC Alone Is Not Enough

A single HMAC on a single record prevents tampering with that record. But it doesn't prevent an attacker from:

To address this, you chain the records together. Each record includes the HMAC of the previous record, forming a linked list. Now altering any past record breaks the chain, making the tampering obvious.

Here's the structure:

``` Record 1: - Decision: "APPROVE" - Timestamp: 2026-06-01 10:00:00 - Model version: v1.2.3 - Previous HMAC: null (first record) - HMAC: SHA256(HMAC(secret + Record1))

Record 2: - Decision: "DENY" - Timestamp: 2026-06-01 10:00:05 - Model version: v1.2.3 - Previous HMAC: "abc123..." (HMAC from Record 1) - HMAC: SHA256(HMAC(secret + Record2))

Record 3: - Decision: "APPROVE" - Timestamp: 2026-06-01 10:00:12 - Model version: v1.2.3 - Previous HMAC: "def456..." (HMAC from Record 2) - HMAC: SHA256(HMAC(secret + Record3)) ```

If an attacker changes Record 1's decision to "DENY," the HMAC for Record 1 changes. But now Record 2 points to the wrong HMAC (it still points to the original). The chain is broken. A verifier scanning the chain will detect the break immediately.

Double HMAC for Added Security

A single HMAC chain is strong, but sophisticated attackers might compromise your system's key. To defend against key compromise, use a double HMAC:

  1. HMAC Layer 1: compute HMAC-SHA256(internal_key + record)
  2. HMAC Layer 2: compute HMAC-SHA256(external_key + result_from_layer1)

The internal key is stored by the system (and can be rotated if compromised). The external key is held by an external party or published to an external service. An attacker would need to compromise both keys to forge a valid record.

This is standard practice in high-security environments like cryptographic timestamp authorities and blockchain systems.

Practical Implementation: Receipt Ledgers

A common pattern is to store decision records in an append-only receipt ledger. Each receipt captures:

The ledger is append-only: once written, records cannot be deleted or modified. New records can only be appended. Old records can be archived to immutable storage (cloud append-only blobs, write-once media, blockchain).

A typical receipt looks like:

```json { "receipt_id": "rec_20260601_00042", "timestamp": "2026-06-01T10:00:05.234Z", "model_version": "v1.2.3", "decision": "APPROVE", "inputs": { "applicant_id": "app_xyz", "credit_score": 742, "income_verified": true }, "gates": { "policy_check": "PASS", "risk_limit": "PASS", "manual_review": "PASS" }, "previous_hmac": "abc123def456...", "hmac": "xyz789uvw012..." } ```

The system writes this to append-only storage (a cloud blob, a write-once database, or a local file with integrity guarantees). The receipt ledger becomes an immutable history of every decision the system made.

Verification: Walking the Chain

To audit a decision, a verifier:

  1. Retrieves the receipt from storage
  2. Computes HMAC-SHA256(secret_key + receipt_contents)
  3. Compares the computed HMAC to the receipt's "hmac" field
  4. If they match, the receipt has not been tampered with
  5. Then follows the chain backward, verifying each link:
- Compute the HMAC of receipt N - Confirm it matches the "previous_hmac" in receipt N+1 - Repeat for all N down to the first receipt

If any link is broken, the chain is invalid. If all links verify, the auditor has cryptographic proof that every record from the first receipt through the current one is authentic and unchanged.

This can be done by an external auditor without the system's cooperation. The system cannot retroactively alter records; doing so would break the chain, leaving detectable evidence.

Key Rotation and Lifecycle

HMAC keys must be rotated periodically (monthly, quarterly, or per regulatory requirement). This limits the damage if a key is ever compromised:

  1. At rotation time, sign a "key rotation" receipt with the old key
  2. Create a new receipt with the new key, pointing to the last receipt signed with the old key
  3. The chain remains unbroken; the transition is auditable

If an old key is compromised, an attacker can forge receipts only within the period that key was active. Auditors can detect forged receipts by checking which key's signature they carry and whether that key was active at the purported timestamp.

Performance and Latency

HMAC computation is fast:

For most AI decision systems, this is negligible. A high-frequency trading system making 10,000 decisions per second would add ~30 milliseconds of latency from HMAC computation—acceptable for most applications.

Storage overhead is small:

For a system making 1 million decisions per day, the overhead is ~500 MB per year—trivial by modern storage standards.

External Verification and Notarization

For systems that require the strongest audit trail, receipts can be published to an external service the system cannot control. Options include:

These approaches prevent the system from deleting or reordering receipts post-hoc. Even if the system's own ledger is compromised, external notarizations provide an independent copy of the evidence.

Designing for Auditability

To build an AI system with robust tamper-evident logging:

  1. Decide upfront: are audit logs a compliance checkbox or a core architectural responsibility?
  2. Design the receipt schema: what information must each decision record contain?
  3. Choose your ledger: append-only database, cloud blob, or blockchain?
  4. Implement key management: how will you store, rotate, and revoke HMAC keys?
  5. Plan for external verification: will auditors verify logs with your keys, or independently?
  6. Fail safely: if logging fails, what happens? (Never silently drop a log.)
  7. Test at scale: verify that logging doesn't create bottlenecks under production load

HMAC chains are not novel technology. They've been used in banking, PKI, and cryptographic systems for decades. Applying them to AI audit trails is straightforward once you accept that auditability is a first-class architectural concern, not an afterthought.

The result is a system that doesn't ask users to trust it—it proves its behavior through cryptography.