Verify a hash-chained agent audit trail

An audit trail becomes useful evidence only when another party can test it. The verifier below demonstrates the minimum mechanics on a small public reference format: canonicalize a record, prepend its previous digest, compute SHA-512, compare the result and continue in order.

Verify a reference audit chain in your browser

Paste a JSON array that follows the public reference format below. The verifier canonicalizes each record and recomputes its SHA-512 link locally. Nothing is uploaded.

Audit records

Maximum 500 records and 250,000 UTF-8 bytes. The reduced demo accepts exactly seq, timestamp, actor, action, outcome, previous_hash, and hash. Actor, action, and outcome must be non-empty strings; timestamp must be a valid UTC ISO timestamp.

Load verified sampleVerify chainAlter one recordClear

Load the sample or paste a chain to begin.

What does the verifier calculate?

For each record, the tool removes the stored digest, serializes the remaining fields in a deterministic order, combines that value with the prior digest and computes SHA-512 through the browser Web Crypto API.

expected_digest = SHA-512(previous_digest || canonical_record_without_digest)

The current record must also name the digest of its predecessor. A mismatch identifies the first point at which the supplied history no longer agrees with the chain.

How should a team test an implementation?

Use a known-good fixture, then make one controlled mutation at a time.

Test	Mutation	Expected outcome
Content edit	Change one material parameter	Current record digest fails
Deletion	Remove a middle record	Next record's pointer fails
Reordering	Swap two records	Pointer or digest fails at the swap
Insertion	Add a record without rebuilding	Pointer fails at the insertion
Truncation	Remove the tail	Internal chain may remain valid; external checkpoint detects the shorter head
Full rewrite	Recompute every digest	Internal chain may pass; trusted checkpoint or signature must fail

Run the same tests after any serialization, schema or cryptographic-library change. A verifier that accepts more representations than the writer creates can produce ambiguous results.

What must be canonicalized?

JSON object key order, number representation, timestamps, Unicode normalization, absent fields and byte encoding must have one documented representation. Otherwise two systems can read the same logical event and hash different bytes.

The reduced browser demo accepts exactly seven fields: seq, timestamp, actor, action, outcome, previous_hash, and hash. It hashes the first five in that fixed order, using JSON string encoding and UTF-8. Sequence starts at one; timestamp is valid UTC ISO text with seconds and optional three-digit milliseconds; actor, action, and outcome are non-empty strings. Extra fields are rejected because they would not be protected by the demo digest. The limit is 250,000 UTF-8 bytes and 500 records. A production format should version its own rules and include cross-language fixtures; this reduced demo does not implement the larger reference specification's schema or domain prefix.

What does a passing chain not prove?

A valid hash chain does not prove that the first record is genuine, that every action was recorded, that the clock was correct, that identities were authentic, or that data was lawfully retained. It proves a narrower fact: the supplied sequence has not changed relative to the digest and checkpoint you trust.

Close the other gaps with authenticated identities, monotonic sequence rules, boundary coverage, signed or independently retained checkpoints, downstream receipts, access control, retention policy and incident reconciliation.

How should checkpoints be retained?

Store periodic chain heads outside the authority that writes the main log. Depending on the assurance need, that can mean a signed checkpoint, a protected security account, an evidence repository, a transparency service or an authorized independent recipient.

Record the segment, sequence range, algorithm, canonicalization version, chain head, signer or publisher, timestamp source and verification status. A checkpoint without scope is difficult to use during investigation.

How should verification fit an audit process?

Verification should be repeatable, not a one-time demo. Define who runs it, on what cadence, against which exports, how failures are triaged and which artifacts are retained. Include exact verifier versions and test fixtures in release evidence.

For higher consequence workflows, pair scheduled verification with event-count reconciliation against tool gateways and systems of record. That is how a team distinguishes an intact partial log from a complete execution history.