Verify Signed AI Agent Audit Logs: A Runnable Example

A signed AI agent audit log answers an integrity question: do these records still match the bytes signed by the expected key? It does not establish complete event coverage or external tool execution. You can see those boundaries in a small example instead of relying on a claim that a log is tamper-proof.

This walkthrough uses a public signed-audit teaching lab. It creates three synthetic refund decisions in memory, signs them with an ephemeral Ed25519 key, and deliberately changes the evidence. No payment, agent, or external tool runs. For the broader design and procurement questions, read the AI agent audit trail guide.

Run the example

Download and inspect the file, then run it with Node.js 26. The example was tested with Node.js 26.10.0 on 7 October 2026. It uses built-in modules and writes no files.

node signed-audit-verification-lab.cjs --self-test
node signed-audit-verification-lab.cjs

The self-test prints PASS 9 checks. The demonstration prints:

intact trail: PASS (valid-prefix-only)
changed amount: FAIL (signature-invalid)
missing middle record: FAIL (chain-broken)
reordered records: FAIL (chain-broken)
unsigned record: FAIL (signature-format)
different signing key: FAIL (signature-invalid)
removed tail, no checkpoint: PASS (valid-prefix-only)
removed tail, trusted checkpoint: FAIL (checkpoint-mismatch)
intact trail, trusted checkpoint: PASS (matches-trusted-checkpoint)

The FAIL lines are expected negative cases. The demonstration reports each case; its process exit is not a production verification verdict. --self-test exits unsuccessfully if an expected result changes.

What the lab signs

Each record includes an ID, timestamp, actor, action, target, integer amount in minor units, decision, policy version, and previous-record hash. The amount and the decision are covered by the signature, as is the link to the previous record.

The teaching format turns those values into one fixed-order JSON array with a version marker, encoded as UTF-8. Both signing and verification use exactly those bytes. The verifier rejects unexpected fields rather than silently leaving a field outside the signature. This is a deliberately small format, not a general JSON canonicalization implementation or a supported format for customer exports.

Ed25519 verification checks a signature against the message and a public key. The signature algorithm is specified in RFC 8032. A verifier must use a key it already trusts for the expected signer; accepting an arbitrary key supplied alongside a forged history would defeat that identity check.

The lab keeps its trusted public key separately from the records being examined. It generates a new key on each run, so hashes and signatures change while the reported outcomes remain the same. It models a trusted signer for an exercise; it does not implement certificate validation, key rotation, revocation, or organizational identity.

Changing a record fails the signature check

The first negative case changes the first refund amount from 825000 to 100 after signing. The signed bytes no longer match the record, so verification returns signature-invalid.

Changing the decision or policy version would also change the signed bytes. Recomputing a record's hash does not repair its original signature. A person who controls the signing key is a different threat: they can sign new statements. Signatures alone do not protect against a dishonest or compromised signer.

An unsigned record fails the teaching format's signature check. A history signed with a different ephemeral key fails against the original trusted key, even when its other fields look plausible.

Removing a middle record breaks the chain

The second record links to the first; the third links to the second. When the second is removed, the third still names the second record's hash. It cannot follow the first directly, and verification returns chain-broken.

Reordering records also breaks the expected sequence. The lab hashes each record's signing bytes and signature to produce the next link. Its starting hash is fixed, so the verifier also checks the beginning of this teaching trail.

This demonstrates consistency within the supplied chain. It does not demonstrate that the writer observed every agent call or recorded every denied attempt.

Removing the tail can still pass

The surprising case is removing the third record. The first two retain valid signatures and a valid link between them. Without another reference, the verifier cannot tell whether two records were the whole history or only its beginning. It returns valid-prefix-only.

The lab then compares that shortened trail with a separately retained checkpoint containing the expected record count and final hash. The shortened trail does not match and returns checkpoint-mismatch. The intact trail matches.

The checkpoint is an in-memory reference retained by the exercise, not a real external transparency service. In a deployment, the reference must be authentic and held outside the history editor's control. A checkpoint that the editor can replace alongside the records adds no independent assurance. It also covers only the history up to that checkpoint; later events need a later reference.

Passing verification does not prove execution

Every record in this exercise describes an invented decision. Its signature can be valid even though no refund took place. An actual execution claim needs evidence from the target system, such as a verified receipt bound to the approved action and its parameters.

Likewise, the lab cannot detect an action that was never recorded, establish whether an approval was appropriate, or prove that a logging service was continuously available. Treat integrity, coverage, decision correctness, and external execution as separate questions in a review.

Applying the lesson to Praesidia

This public file is an ungated teaching resource. It does not read Praesidia bundles or substitute for praesidia-verify. Customers and their auditors obtain the production verifier directly from Praesidia; its checks, statuses, access model, and anchoring limits are described on verify your audit trail offline.

When evaluating any vendor, request a sample export, the expected trust material, a documented verification command, and negative cases. Ask what happens when a row changes, a middle row disappears, a key is untrusted, or the newest records are removed. Then ask which execution paths the evidence covers. A passing integrity check is one useful result in that assessment, with a defined scope.