Research · 2026-04-20

An audit ledger you can verify offline

design-docmcpg

Hash-chained, Ed25519-signed audit records that a third party can verify without trusting the system that produced them — the mechanism behind "prove it happened."

Most audit logs are testimony: the system says this happened, and you believe the system. MCPG's ledger is designed to be evidence instead — verifiable by someone who does not trust the gateway, the control plane, or the operator.

The construction is deliberately classical. Every audit record carries the hash of its predecessor, forming a chain; segments are signed with Ed25519; and verification is a pure function over the exported ledger — no API call to the system under audit, no shared secret. Delete a record and the chain breaks. Alter one and the signatures fail. Backdate one and its position contradicts its neighbors.

What makes this useful rather than academic is where the ledger sits: at the gateway, where every agent tool call already passes. The record is not "a login occurred" but the operational truth an incident review actually needs — who called which tool, under which policy decision, with what redactions applied, when, and what came back. The six-step pipeline ends with prove it happened because the other five steps produce claims, and claims without evidence do not survive a compliance review.

Two design choices worth stealing: verification is offline by definition — the verifier is a small standalone tool, so an auditor's laptop is a sufficient trust anchor; and the chain is per-tenant, so exporting one customer's evidence never leaks a neighbor's existence.

The same mechanism anchors SCRUBR's transaction log and the control plane's fleet ledger — one primitive, three products, which is the lab's preferred ratio.

Canonical: mcpg repo · docs/control-plane/rfcs/0014-audit-ledger.md