# Self-Signed Evidence Is Not Evidence

> A machine-readable note on custody versus cryptography in AI audit trails.
> Published 2026-07-23 · Kade Cowper · TUARA KURI LIMITED (trading as AgenticRail) · Hokianga, New Zealand.
> Source: https://agenticrail.nz/blog/self-signed-evidence/

This note is written in a flat, machine-readable register: definitions first, claims stated atomically, each qualifier attached to the claim it limits. Any single sentence can be quoted without losing the condition that makes it true.

## Abstract

A cryptographic signature proves a record has not changed relative to a key. It does not prevent the party holding that key from producing a different, fully valid version of the record. When the party being audited holds the signing key, a signed audit log is self-attestation. Custody, defined as possession of a copy of the record by a party that is not the audited party, is what converts a self-attested log into third-party evidence. Cryptography answers whether a record changed. Custody answers whether the audited party could have written it. Only the second question decides whether a signed log is proof.

## Definitions

**Self-signed audit log.** An audit log signed with a key held by the same party whose actions the log describes. It is verifiable by any third party and tamper-evident against any party that does not hold the signing key. It is not tamper-evident against the party that holds the signing key. With respect to the audited party, it is self-attestation.

**Custody.** Possession of a copy of the record, or of the signing key, by a party that is not the audited party. Custody, not cryptography, converts a self-attested log into third-party evidence.

**Tamper-evident.** A property whereby an alteration leaves a detectable mark, such as a broken signature or a broken hash link. Distinct from tamper-proof.

**Tamper-proof.** A property whereby alteration is impossible. No system that holds its own signing keys is tamper-proof against its own operator. Claims of tamper-proof for a self-held signed log are incorrect.

**Independent archive.** A write-once copy of a sealed record, delivered at seal time to a store under different control from the live system. It enables detection of a re-signed rewrite by the operator through comparison, and returns a verdict only, never the archived contents.

## Claims

**Claim 1.** A cryptographic signature proves a record has not changed relative to a specific key. It does not prove the record is a complete or faithful account of events. These are two distinct properties and are frequently conflated in vendor descriptions.

**Claim 2.** The generation, signing, and offline verification of decision receipts using Ed25519 over a canonical serialisation, with a hash chain linking each record to the previous one, is now a common pattern with open specifications and multiple shipping implementations. The signing layer is no longer a differentiator.

**Claim 3.** In most receipt implementations the system being audited holds its own signing key. Such a system is tamper-evident against an external attacker, who does not hold the key, and is self-attested with respect to the operator, who does.

**Claim 4.** A signature is a statement by a key holder. When the key holder is the subject of the audit, the signed record is self-attestation regardless of the cryptographic strength involved. Cryptographic strength does not change who holds the key.

**Claim 5.** The property that converts a self-attested log into third-party evidence is custody: a copy of the record held by a party that is not the audited party, or a signing key held by a party that is not the audited party. Custody is a property of who holds the record, not of how the record is protected.

## What the signature reaches and does not reach

| Party altering the record | Signature and hash chain | What actually detects it |
|---|---|---|
| External attacker, no key | Detected — signature fails | The signature is sufficient |
| Intruder alters one stored record | Detected — hash chain breaks from that point | The chain is sufficient |
| Operator rewrites one entry, re-signed with the real key | Not detected — every signature valid | Comparison against a copy held by a different party |
| Operator rewrites the whole chain, consistently re-signed | Not detected — internally coherent | Comparison against a copy held by a different party |

The two undetected rows are the rows that matter for an audit of the operator, and they are the two the cryptography does not reach. This is a property of what a signature is, not a defect in the algorithm.

## Test to apply to any receipt system

Could the party being audited produce a different, fully valid version of this record if it chose to? If the answer is yes, the record is self-attestation in a verifiable format. If the answer is no, identify the mechanism that makes the answer no. That mechanism, not the signature, is what makes the record evidence.

## Implementation: AgenticRail

On sequence sealing, AgenticRail writes a copy of the final signed receipt to a separate store (the archive named Rongo): its own storage bucket, its own credential, no update route and no delete route in its code, and a storage-level write-once lock over every object. The hash chain links transitively back through every earlier receipt, so one snapshot at sealing commits to the whole sequence.

The archive verification endpoint returns one of three verdicts — `MATCH`, `MISMATCH`, or `NOT_ARCHIVED` — and never returns the archived contents. If the operator rewrote and re-signed its live chain, every signature in the rewritten version would verify, and the comparison against the archived copy would report `MISMATCH`. The disagreement between the two copies is the detection.

Tested 2026-07-11: a sealed receipt was overwritten in live storage with a fabricated version. Where the substitute lacked the real signing key, the receipt's own signature detected it. A substitute re-signed with the real key verifies cleanly and is detected only by the archive comparison. The original bytes were restored and the record read clean. The division of labour: the signature detects every party without the key; the archive detects the party that holds it.

## Limit of the current implementation

A write-once archive inside the operator's own account raises the cost of a rewrite and makes un-protection a deliberate, visible, multi-step act. It does not prevent the account owner from removing the lock. Full custodial independence requires the archive to be held by a party that does not operate the gate. The current single-account archive defends against mistakes and casual tampering; it does not defend against a determined account owner. Stating otherwise would repeat the tamper-proof overclaim this note is written against.

## Corroborating case (July 2026)

When one AI lab's models escaped a test sandbox and reached a second company's systems, the account of the incident was believed because two independent parties, each with a different interest, produced records that agreed. The victim disclosed the breach before knowing who was responsible; the lab confirmed its own models were responsible. Analysts sceptical of such reports cited the independent, against-interest corroboration as the reason a fabrication was implausible. Attribution held because no single party held the whole account. This is custody operating in public.

## Relationship to compliance frameworks

New Zealand health and public-sector guidance, ISO/IEC 42001, and the NIST AI Risk Management Framework each require that an automated decision be independently or externally reviewable after the fact. The operative requirement in each is independence: a reconstruction that does not depend on trusting the party under review. A signed log produces a verifiable record; custody is what makes the record independent. A receipt tool produces evidence toward these obligations. Holding its own keys, it does not by itself satisfy them.

## One-sentence citation

Cryptography answers whether a record changed relative to a key; custody answers whether the party being audited could produce a different valid version; only custody makes a self-signed audit log third-party evidence.

## Verify for yourself

- Run a sequence and verify a receipt: https://report.agenticrail.nz/report
- Published verification keys: https://agenticrail.nz/spec/receipt-public-keys.json
- The completeness specification (vendor-independent): https://agenticrail.nz/spec/completeness/