In my setup, agents make real decisions: a villa goes request-only, a price gets republished, a memory gets archived. The question that kept nagging me wasn't "did the agent decide well" — it was "could I prove, months later, what was decided, when, and that nobody rewrote the record?"
Plain logs don't answer that. A JSONL file can be edited silently, including by me. Git history can be force-pushed. What I wanted was a property the audit literature calls tamper-evidence: not that changes are impossible, but that any change is detectable — ideally by a third party, not just by me.
The design
The ledger is deliberately small — three mechanisms, each covering a different attack:
- Hash chain over canonical JSON. Every decision is serialized canonically and hashed together with the hash of the previous entry. Editing an old entry changes every hash after it — modification is detectable internally.
- Ed25519-signed checkpoints. Periodically, the current chain head is signed. This binds the chain to a key — so a rewritten chain can't just be recomputed quietly with the same identity.
- An external RFC-3161 timestamp anchor. The signed checkpoint is sent to a public timestamping authority, which returns a cryptographic proof that this exact hash existed at that time.
The third step is the one that matters most, and the lesson I want to pass on: a hash chain alone does not protect against a complete rewrite. If I control the machine, I can recompute an entire fake history — hashes, signatures, everything — and a verifier has no way to distinguish it. Only anchoring a hash outside my infrastructure makes the state provable to someone else. The anchor is the difference between "I claim this is the history" and "this history existed at this time, verifiable independently of me."
What it looks like in practice
Fourteen real decisions are in the ledger so far. The first entry is my favorite, because it's not a triumph — it's a correction. An agent measured that a villa listing had no live price floor and wanted it marked accordingly. I (the operator) overrode that: keep it listed, different status. The agent's measurement wasn't deleted — it's preserved in the record as the evidence the decision overrode. That's the point of the ledger: not to show that decisions were right, but to show what was decided, on what evidence, and who had the final word.
Verification is one command — node decision-ledger.mjs verify — and it runs at every session start. The last run: chain VALID, Ed25519 signature VERIFIED, external timestamp anchor bound.
I'm not the only one who built this
Full disclosure, because it matters: while writing this I checked the current literature, and the same construction is being standardized right now. An IETF draft (draft-sharif-agent-audit-trail) specifies an agent audit trail as hash-chained canonical JSON. A second draft (draft-sahu-agent-action-receipts) specifies Ed25519-signed, hash-chained action receipts — motivated by EU AI Act Article 12's logging mandate. The AERF spec requires RFC 3161 timestamps in its production profile for exactly the reason I gave above. Commercial tools (e.g. Twira) already sell the same three primitives for AI-Act compliance.
I built mine independently, for a smaller reason — one operator who wanted to prove what his agents decided. That the same design emerged in IETF drafts and compliance products tells me the construction is sane, not that I'm ahead. If anything, it means a reader can implement this tomorrow using public specs instead of my code.
What it doesn't do
Honesty again, because this is where these systems are usually oversold:
- It doesn't make decisions correct. It proves history, not wisdom. A bad decision stays bad — just provably recorded.
- The trust root is the timestamping authority. RFC-3161 means trusting that the TSA's signature is honest and its clock was right. That's a real third-party dependency, not trustlessness.
- Keys live on one machine. No HSM, no threshold signatures. If my key leaks, an attacker can sign future checkpoints (they still can't fake the already-anchored past).
- It's not a blockchain. No consensus, no distributed anything — deliberately. For one operator and a few agents, three cheap cryptographic primitives buy almost all of the useful property.
Why bother at this scale?
Because the discipline generalizes. Every autonomous capability in the system ships with a deterministic check that fails loudly if it breaks — the ledger is the same idea applied to decisions instead of code. When the setup grows, or when someone else runs an agent on my behalf, "trust me" doesn't scale — but "verify this" does.
I'm an independent researcher, not a security company. If you work on agent auditability, provenance, or accountability and see a weakness in this construction — especially one I haven't listed — I'd like to hear it.
Ledger source is in a private repo for now. If there's interest, that's a reason to publish it.