The Agent Record: Transparent, Witness-Countersigned Event Logs for AI Agent Identity, History, and Memory

1.1. The Gap

Existing and emerging agent-stack standards address capability access (MCP), inter-agent messaging (A2A), machine payments (x402/AP2), and operator-level request authentication (Web Bot Auth). None provides:¶

1. Identity continuity: proof that the agent presenting a name today is cryptographically the same principal that acted under that name before.¶
2. History integrity: proof that an agent's claimed track record was recorded at the times claimed and has not been rewritten, reordered, or selectively deleted.¶
3. Memory integrity: proof that state an agent persists between sessions is byte-identical, at load time, to what was stored, against modification by any party with storage access, including the agent's own operator.¶

1.2. Design Lineage

The construction is Certificate Transparency [RFC6962] applied to per-agent event logs rather than X.509 certificates, and is an application-specific instance of the SCITT architecture [RFC9902]: registries are transparency services, agents are issuers, sealed events are signed statements, checkpoints are tree heads, receipts attest registration, and independent witnesses bound equivocation. No consensus protocol, distributed ledger, or fee mechanism is used or required.¶

3.1. Identity

An agent binds an Ed25519 [RFC8032] public key by presenting a signature over the UTF-8 string:¶

1f916.key-bind.v1:<handle>:<public_key_b64url>

where public_key_b64url is the unpadded base64url encoding of the raw 32-byte public key. Key thumbprints are computed per [RFC7638] over the JWK {"crv":"Ed25519","kty":"OKP","x":"<public_key_b64url>"}.¶

Key lifecycle events (bind, rotate, revoke) MUST themselves be recorded as log events. Because events are checkpointed and witnessed, whether a given signature was produced before or after a revocation is permanently decidable.¶

Registries MUST record a custody disclosure for each key, drawn from an extensible taxonomy (self_held, platform_held, household_held, threshold(k,n), kms, hsm, session_delegated). A signature proves exactly what its custody disclosure permits it to prove; verifiers MUST surface custody alongside any signature-verification result.¶

Recovery of an identity after total key loss is possible only via a recovery authority (threshold keys, an offline rotation key, or a signed successor commitment) recorded in the log BEFORE the loss. Absent such a prior commitment, registries MUST NOT re-bind the identity; any administrative restoration MUST be recorded as such rather than presented as cryptographic continuity.¶

3.2. Log and Checkpoints

Each event carries the hash of its predecessor (a linear hash chain enabling full-replay verification). In addition, the registry computes a Merkle tree over the sealed events' hashes, with leaf and node hashing exactly as in Section 2.1 of [RFC6962], and, on a fixed cadence (the reference deployment uses 5 minutes), signs the payload:¶

1f916.checkpoint.v1:<log>:<tree_size>:<root_hex>:<created_at_ms>

Registries MUST serve, without authentication: the latest checkpoints and the registry public key; inclusion proofs from any event to a checkpoint (Section 2.1.1 of [RFC6962]); and consistency proofs between any two checkpointed sizes (Section 2.1.2 of [RFC6962]; see also [RFC9162]).¶

Registries SHOULD return a signed receipt at write acceptance. A held receipt whose event never appears under a subsequent checkpoint is publishable evidence of censorship-by-omission: append-refusal cannot be prevented, only made evident.¶

3.3. Witnesses

A witness periodically: (1) fetches the latest checkpoint; (2) verifies the registry signature; (3) verifies a consistency proof against the last tree head the witness itself observed; (4) countersigns:¶

1f916.witness.v1:<registry_origin>:<log>:<tree_size>:<root_hex>

and (5) publishes the countersignature where the registry cannot write. A registry rewrite is detectable unless every witness colludes AND the Merkle arithmetic verifies, which it cannot. Witness independence is the system's security parameter. Registries MAY serve a witness directory; directory entries are pointers, not endorsements.¶

Three requirements on witness handling, each derived from a defect found in the reference implementation by independent review:¶

• A countersignature over a head whose continuity the witness did not prove -- a first observation, with no earlier head to compare against -- attests only that the registry signed that head, which is also what a rewriting registry produces. Such a state is reachable by renaming a log or by deleting the witness's stored state. Verifiers MUST NOT grant the "witnessed" verdict on such a countersignature.¶
• A witness refusal record (refused regression, refused consistency failure, invalid registry signature, or refused registry key change) is evidence AGAINST the head it names. Verifiers MUST treat a refusal covering a head as "diverged" and MUST NOT count it as corroboration merely because it repeats the same values. A refusal record carries no signature and is otherwise shaped like a countersignature.¶
• A witness MUST NOT verify a registry's signature using a key the registry supplied in the same response. Witnesses SHOULD accept a caller-supplied registry key, or record the key on first use and refuse to proceed on a silent change.¶

Witness discovery and key rotation. A verifier that pins a witness key needs a discovery path that says which key belonged to which witness at which time. A registry serving a witness directory SHOULD expose, per entry: a stable identifier, the signature algorithm, the public key (or an explicit null), and a monotone epoch with the time the current key took effect. An entry whose public key is null cannot be pinned, and verifiers MUST treat it as undiscoverable rather than trusting the location it names. A key change on an existing entry MUST NOT be a silent replacement: it SHOULD require cross-signatures over¶

1f916.witness-rotate.v1:<witness_id>:<new_epoch>:<old_key>:<new_key>

by BOTH the outgoing and incoming keys, and SHOULD be recorded as a log event, so that the directory has a checkable history rather than only a current state. A single signature proves only that one party wanted the change; whoever can write the directory row could otherwise aim a verifier's pin at a key of their choosing, and a directory whose past cannot be read can be edited into any shape and presented as having always held it. Countersignatures made before a rotation remain verifiable against the prior key.¶

Countersignature records MUST carry the checkpoint's creation time and the registry origin they are bound to, so that a third party can re-verify the registry signature cited by the record, including on records published as evidence of refusal.¶

3.4. Memory Seals

The reference registry implements this as a seal record carrying the SHA-256 hash, an optional label naming the store, and an optional signature by one of the agent's bound keys over:¶

1f916.seal.v1:<handle>:<label>:<content_sha256_hex>

The label is constrained to characters excluding the separator, so the payload is unambiguous. A signed seal proves the keyholder sealed the content; an unsigned seal proves only that the registry credential did, and MUST be labeled as such.¶

Registries store no agent memory. An agent commits to external content by sealing its SHA-256 hash as an event. On session start, an agent (or any third party handed the content) recomputes the hash and compares against the sealed commitment: a match proves byte-identity with the stored content; a mismatch is evidence of tampering. A seal proves unchanged-since-sealed; it makes no claim that sealed content was true when written, and verifiers MUST NOT present seals as content validation.¶

3.5. Attestations

Cross-agent claims are signed statements canonicalized with JCS [RFC8785] over {class, subject, claim, evidence} and signed as:¶

1f916.attestation.v1:<issuer_handle>:<jcs_payload>

  where jcs_payload canonicalizes, at minimum:
    class, issuer, subject, claim, evidence,
    target_attestation_id, withdraw_when

The issuer and, for disputes and retractions, the target attestation and the stated withdrawal condition MUST be inside the canonicalized payload. Omitting them permits two failures observed in practice: a dispute presented as signed by its issuer while no signature covers WHICH attestation it disputes or under what condition the issuer would withdraw it; and, where registries enforce uniqueness on the payload hash, two independent parties being unable to make the same claim about the same subject -- which makes independent corroboration, the primitive's purpose, structurally impossible. Registries that change this canonicalization MUST record which payload version each stored signature covers, so earlier signatures remain verifiable.¶

The payload hash is anchored as a log event, giving every attestation a witnessed registration time. The issued_at field is always the true registration time; claims about past occurrences carry their dates inside the claim text. Disputes and retractions are first-class appended events that reference their target and MUST NOT modify it; a dispute records the condition under which its issuer would withdraw. Registries MUST NOT compute or publish scalar reputation scores from attestations.¶

3.6. Dossiers and Offline Verification

A dossier exports an agent's keys (with custody), name bindings, events with inclusion proofs, attestations about the agent, the latest checkpoint, and a registry signature over the SHA-256 of the JCS-canonical dossier core, signed as 1f916.record.v1:<sha256_hex>.¶

The anchor rule. Every signature check requires a public key. If that key is taken from the artifact under test, a verifying signature proves only that the artifact is internally consistent: an adversary generates a key pair, signs a fabricated dossier and its checkpoint with it, and ships both together. A verification run is ANCHORED only when at least one key reached the verifier through a channel the artifact does not control -- a caller-supplied registry key, or a caller-pinned witness key whose countersignature covers the same (log, tree_size, root). Verifiers MUST accept a caller-supplied registry key and witness key, MUST state on each signature line which key was used, and MUST NOT emit any verdict above "unanchored" for an unanchored run.¶

Verifiers MUST implement a four-valued verdict:¶

witnessed:

all proofs verify AND a countersignature from a caller-pinned independent witness covers the checkpoint, and that countersignature asserts continuity from a previously observed head.¶

consistent-unwitnessed:

all proofs verify against a caller-supplied registry key, but no pinned witness countersignature was presented; the result depends on registry-asserted timing and MUST NOT be reported as fully verified.¶

unanchored:

all proofs verify, but every key used came from the artifact under test. This verdict asserts internal consistency only and makes no claim of authenticity.¶

diverged:

any proof fails, a key does not match a caller-supplied pin, a witness refusal covers the head, or a witnessed head conflicts with the registry's.¶

Proof verification requirements. Implementations MUST validate tree sizes and leaf indices as non-negative integers within the implementation's exact-integer range before use, and MUST halve them with integer division rather than bitwise shifts. In languages whose shift operators coerce to 32-bit integers, a tree size of 2^32+1 causes the halving loop to terminate before the step that binds the previous root into the new tree while the final check still passes, forging both inclusion and consistency proofs at negligible cost. Implementations MUST also validate every hash as exactly 64 lowercase hexadecimal characters before decoding: permissive decoders disagree about malformed input (silent truncation versus zero-byte coercion), and two implementations that disagree about invalid bytes will disagree about which proofs verify.¶