Loading page
About this tool
Check JSON or JSONL agent audit logs locally for structural continuity and optionally recompute an explicitly configured SHA-256 canonical hash chain.
The Agent Audit Log Integrity Verifier checks a JSON or JSONL audit log for internal continuity — duplicate or missing entry IDs, gaps and reordering in the sequence numbers, timestamps that run backwards, and broken previous-hash links where one entry's previousHash should equal the prior entry's hash — and can optionally recompute a SHA-256 hash chain using a recipe you select explicitly. It is for anyone who has to answer 'has this agent's log been altered or truncated?' with something better than a visual scan: platform engineers, auditors and incident responders. Parsing, canonicalisation and hashing all run locally through the browser's Web Crypto API, and the exportable report contains counts and states only, never log contents.
Open Agent Audit Log Integrity Verifier on AltFTool — it loads instantly in your browser.
Paste entries into the "Audit log" box or use "Choose text file" (.json, .jsonl, .ndjson or .txt, up to 10 MB and 25,000 checked entries), then press "Parse locally".
Confirm the audit schema — "Entry ID field", "Sequence field", "Timestamp field", "Previous-hash field" and "Stored-hash field" — pick a "Documented SHA-256 recipe" (canonical entry without stored hash, or previous hash + LF + canonical payload), then press "Run configured checks".
Read the verified, mismatch or not-checkable state for Entry IDs, sequence, timestamps and hash links, then press "Download counts-only report" to save agent-audit-integrity-counts.csv.
IDs, sequence, timestamps and previous-hash links each get their own verified, mismatch or not-checkable state, so you can tell a missing field apart from a real break.
You pick either canonical-entry or previous-hash-plus-entry, and the tool canonicalises with sorted keys and omits the hash field itself — so a match means a match against a stated rule rather than a lucky heuristic.
Entries that lack a well-formed digest are marked not-checkable rather than quietly passing, and the report never reads a null result as a clean bill of health.
A JSON array of objects, a JSON object containing an entries, events, logs, records, auditLog or audit_log array, or newline-delimited JSONL. Up to 25,000 entries are checked in one pass, and field paths for ID, sequence, timestamp, hash and previousHash are auto-discovered from the first 50 entries down to three levels of nesting — you can override any of them.
It recomputes each entry's digest and compares it to the stored one. The canonical-entry recipe hashes the entry with its own hash field removed and all object keys sorted; the previous-plus-entry recipe hashes the previous hash, a newline, then the canonical entry with both the hash and previousHash fields removed. A stored value must be exactly 64 hexadecimal characters (case-insensitive) to be checkable at all, since that is the length of a SHA-256 digest.
No, and this is the important limit. A hash chain only proves internal consistency: anyone who could edit an entry could also recompute every hash after it and produce a perfectly verified log. Tamper-evidence requires something outside the file — a digital signature, a write-once store, or a digest anchored with a third party — so treat a pass as 'no accidental corruption or truncation found', not as proof of authenticity.
That the data needed for that check was absent, not that the check passed. A missing sequence field, an unconfigured hash path, a digest that is not 64 hex characters, or a single-entry log with no genesis hash all produce not-checkable — which is a prompt to configure the field or fix the writer, not a clean result.