What the Receipt Chain Proves

You kept a journal when you were younger. Maybe you still do. The thing about a journal is that someone could tear out a page, and unless you noticed the page numbers skipping, you’d never know.

Imagine a journal where every page contained a fingerprint of the previous page. Tear one out, and every page after it has the wrong fingerprint. You’d know instantly that something was missing.

That’s what GuardClaw’s receipt chain does for your agent’s activity.

Every decision GuardClaw makes — every allow, every deny — generates a receipt that’s cryptographically linked to the one before it. This post explains how that works, what it proves, and why it matters when someone asks for evidence.

What a receipt contains

Every time GuardClaw evaluates an action, it creates a receipt with these fields:

• Run ID: which agent session this belongs to
• Sequence number: the position in the chain (receipt #1, #2, #3…)
• Event type: what kind of action was evaluated (file read, shell command, API call)
• Decision: what GuardClaw decided (allow, deny, or ask-human)
• Tool and action: what the agent tried to do
• Policy ID: which rule triggered the decision
• Timestamp: when it happened (UTC)
• Hash: a SHA-256 fingerprint of this receipt
• Previous hash: the SHA-256 fingerprint of the receipt before this one

That last field — the previous hash — is what makes this a chain and not just a log.

How the chain works

When GuardClaw creates receipt #1, it calculates a hash of all the fields in that receipt. That hash is a unique fingerprint — change any field, even by one character, and the hash changes completely.

When it creates receipt #2, it includes the hash of receipt #1 as one of its own fields. Then it hashes everything, including that previous hash. Receipt #3 includes the hash of #2. And so on.

The result: every receipt is connected to every receipt before it. If someone tried to change receipt #47 — editing the decision from “deny” to “allow,” for example — the hash of receipt #47 would change. But receipt #48 has the original hash of #47 baked into it. The mismatch is immediately detectable.

You can’t fix it by updating receipt #48, because that would change its hash too, and receipt #49 has the original hash of #48. The entire chain after the tampered receipt breaks.

This is the same concept behind blockchain technology, applied to your audit log. The difference is simpler: there’s no consensus mechanism, no mining, no cryptocurrency. Just a chain of hashes that proves the record hasn’t been altered.

What it proves

The receipt chain answers three questions:

1. What happened? Every action your agent took and every decision GuardClaw made is recorded. Not a summary. Not a sample. Every single one.

2. When did it happen? Timestamps are part of the hashed data. You can’t change when something happened without breaking the chain.

3. Has the record been changed? This is the big one. Traditional logs can be edited — delete a line, change a value, truncate the file. Nobody would know. With a hash chain, any modification to any entry breaks the chain from that point forward.

Verifying the chain

You don’t have to trust anyone’s word that the chain is intact. The dashboard verifies the chain automatically when it loads your data. It re-computes the hash of every receipt and checks it against the stored hashes. If everything matches, the chain is intact. If any receipt has been tampered with, the dashboard flags it and tells you which entry is broken.

You can also verify locally. When you run guardclaw sync, the CLI checks chain integrity before uploading. If the local chain has been tampered with, the sync will report the broken link.

Why auditors care

When a compliance auditor asks about your AI agent security, they’re usually asking three things:

1. What controls are in place? (Your security policies and detection engine.)
2. Are those controls actually enforced? (The receipt chain proves enforcement happened.)
3. Can you prove the evidence hasn’t been altered? (Hash chain verification.)

Traditional audit logs answer the first two questions but fail on the third. A log file is just a file — anyone with write access can modify it. An auditor has to trust that nobody did.

The receipt chain removes that trust requirement. The math proves the integrity. It doesn’t matter who has access to the file — if someone changed it, the hashes don’t match.

This is particularly important for regulated industries:

• Healthcare (HIPAA): You need to prove what your systems accessed and when. An AI agent reading patient records needs the same audit trail as a human employee.
• Finance (SOC 2): Audit log integrity is an explicit control requirement. A tamper-evident chain satisfies it directly.
• Government (FedRAMP): System activity logging with integrity verification maps to multiple controls.

The human version of this

Think about a notarized document. You sign it. The notary stamps it. The stamp proves the document existed in that form on that date. If someone alters the document, the notary’s stamp no longer matches.

The receipt chain is a digital notary for every action your agent takes. Except instead of one stamp at the end, every single receipt is stamped with a cryptographic link to the one before it. Thousands of notarizations, automatic, continuous.

What to look for in practice

When you review your receipt chain in the dashboard or via guardclaw sync:

• Denial clusters: Multiple denials in a short time window might indicate a prompt injection attempt or a misconfigured agent. Worth investigating.
• Unusual patterns: An agent that normally does file reads suddenly making shell commands. The receipt chain shows when behavior changed.
• Chain breaks: If the verification ever fails, something modified the data. Investigate immediately.

Next post: how GuardClaw maps to SOC 2 controls — which requirements it satisfies and what evidence to present to your auditor.