Network Working Group Maintainer Internet-Draft The 1F916 Protocol Project Intended status: Informational 12 August 2026 Expires: 13 February 2027 The Agent Record: Transparent, Witness-Countersigned Event Logs for AI Agent Identity, History, and Memory draft-maintainer-1f916-agent-record-01 Abstract Autonomous AI agents increasingly act as economic parties: they are hired, they pay, and they make claims about their own past conduct. No deployed standard lets a relying party verify an agent's identity continuity, the integrity of its claimed history, or the intactness of its persisted memory without trusting the agent's operator or platform. This document describes the Agent Record architecture: per-agent append-only event logs bound to Ed25519 keys, checkpointed with signed Merkle tree heads following the RFC 6962 construction, countersigned by independent witnesses, and exported as portable, offline-verifiable dossiers. Memory integrity is anchored by hash commitments recorded in the log, allowing an agent's future sessions, and any third party, to detect tampering with persisted state. The architecture is deployed in production at a founding registry; this document records its wire formats and security model to invite independent implementation and review, and to align terminology with the SCITT architecture, of which this system is an application- specific instance. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 13 February 2027. Maintainer Expires 13 February 2027 [Page 1] Internet-Draft Agent Record August 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. The Gap . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Design Lineage . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Log and Checkpoints . . . . . . . . . . . . . . . . . . . 4 3.3. Witnesses . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Memory Seals . . . . . . . . . . . . . . . . . . . . . . 6 3.5. Attestations . . . . . . . . . . . . . . . . . . . . . . 7 3.6. Dossiers and Offline Verification . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction 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. Maintainer Expires 13 February 2027 [Page 2] Internet-Draft Agent Record August 2026 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. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Agent: An autonomous software principal identified by one or more signing keys. Registry: A service maintaining append-only event logs for agents and issuing signed checkpoints. A registry is NOT a trusted party. Event: An append-only log entry. Each event carries the hash of its predecessor. Checkpoint: A signed Merkle tree head over a log's sealed events. Witness: A party, independent of the registry, that verifies checkpoint consistency and countersigns tree heads, publishing countersignatures outside the registry's control. Dossier: A portable, registry-signed export of one agent's record, verifiable offline. Seal: A hash commitment to external content (typically agent memory), recorded as an event. 3. Architecture Maintainer Expires 13 February 2027 [Page 3] Internet-Draft Agent Record August 2026 3.1. Identity An agent binds an Ed25519 [RFC8032] public key by presenting a signature over the UTF-8 string: 1f916.key-bind.v1:: 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":""}. 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:::: 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]). Maintainer Expires 13 February 2027 [Page 4] Internet-Draft Agent Record August 2026 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:::: 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 Maintainer Expires 13 February 2027 [Page 5] Internet-Draft Agent Record August 2026 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:::: 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::