# Signing the evidence behind an agent change

Updated September 24, 2026 to reflect the current kernel implementation.

The previous post made the case for a verifiable record of an agent’s work. Signing such a record takes more than adding a signature field to a JSON object. We need to say exactly what was signed, by which key, and how that evidence relates to the code under review.

What Logposa verifies today

The kernel’s reconstruction module can verify an Ed25519 attestation on a revision. Each revision names its parent and its file operations. The canonical signing payload covers the operation paths, preconditions, evidence states, content hashes, and the paths the signer claims to cover. The verifier rejects missing signatures, unknown or revoked keys, invalid signatures, and incomplete coverage.

That is a useful proof about a revision’s contents. A signed explanation attached to every Git commit and a separate signed review are still work to do.

What a decision record would need

A future record should separate observable evidence from someone’s account of the decision. For example, it could name the instruction the agent received, the files and checks it actually touched, the alternatives a person chose to record, and the resulting Git change. A summary of why an option was rejected is a claim by its author; a passing test is an observation with its own source.

The record needs a defined byte format for signing. Its identifier must be computed from a canonical payload that excludes the signature itself. A signer controlled by the agent runtime can then sign those bytes with an enrolled key. The signature establishes that key’s endorsement of the bytes; it cannot prove that every statement in the record is true, or that the model itself holds a key.

A review attestation would be a separate act. It should name the exact record and code revision the person reviewed, and be signed by a key tied to that person. If the attestation is absent, the accurate statement is no signed review is recorded here. A review may still have happened elsewhere.

Git history can move

A rebase creates new commit IDs. A cherry-pick creates another commit, often with a different parent and sometimes different content. A record linked only to the old ID does not automatically follow either operation. Verification needs an explicit, checkable link between the original change and its rewritten form. Logposa already uses recorded rewrite events to associate some rebased commits with agent sessions; that association is not a cryptographic proof that the contents stayed the same.

Offline verification would also require the record’s bytes, the relevant Git objects, the signers’ public keys, and a stated trust policy for those keys. No network call should be needed to check the signatures. Deciding whether a signer was authorized at the time is a separate question that the trust policy must answer.

This is the standard we are working toward: a record that lets a third party check the evidence and the signatures, while keeping claims about intent and approval as precise as the proof allows.