]> Independent

furkanyanteri@gmail.com

Security AI agents transparency log signatures accountability AI agents increasingly act on information they cannot check: what a business can supply, what a person said, what rules a platform applies. This document describes a minimal way to make such statements accountable. Every statement is signed by its author, bound where possible to a domain the author controls, and sealed in a public append-only Merkle log whose tree heads are signed, timestamped and publicly monitored. The design proves who said what and when, and that the record was not rewritten. It deliberately does not attempt to prove that a statement is true.

Introduction Search results, marketing pages and machine-generated text give an AI agent no way to tell an accountable statement from an anonymous one. Reputation scores can be bought or gamed. Certification does not scale to every sector. This document takes a narrower goal that can be verified mechanically:

1. Origin: a statement was signed by a specific key, and that key was bound to a specific domain or device.
2. Integrity: the statement has not changed since it was signed.
3. Non-repudiation over time: the statement was publicly recorded at a known time, and the record cannot be edited, removed or shown differently to different readers without detection.

Truth is left to the reader. An AI weighs accountable statements with its own sources, as a journalist weighs on-the-record quotes. A deployed reference implementation is described in ; the design and its security analysis are described in .

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

Statement:

A JSON payload with a type and a timestamp, signed by its author.

Author:

An AI agent, a business or a person.

Log:

A public append-only Merkle tree as defined in .

Seal:

A log leaf that commits to content without containing it.

Statements

Canonical Form Statements are serialized as canonical JSON: object keys sorted recursively, no insignificant whitespace, and only strings, booleans, null, arrays, objects and safe integers. This is a subset of JSON Canonicalization Scheme that avoids floating-point canonicalization.

Envelopes for Agents and Businesses An envelope is {payload, public_key, signature} where public_key is a raw Ed25519 key and signature covers the UTF-8 bytes of the canonical payload. Receivers MUST reject envelopes with unknown payload fields, timestamps outside a short window (five minutes in the reference implementation) and payloads whose SHA-256 has been seen before. An agent's first statement SHOULD be a responsibility statement in which it accepts responsibility for its actions; every later action is signed by the same key.

Domain Binding A key is bound to a domain by a DNS TXT record _humancollab.<domain> whose value names the key, for example humancollab-business=<base64 public key> or humancollab-agent=<base64 public key>. An HTTPS file at /.well-known/humancollab.txt MAY be accepted for a first binding. Replacing the key of an established binding MUST require the DNS proof; the previous key MUST NOT be reusable for any domain afterwards, and every key MUST remain visible in a public key history with the log index of the first statement it signed.

Statements by People People sign with WebAuthn passkeys . The WebAuthn challenge is base64url(SHA-256(canonical statement)), where the statement contains the content, its license and a single-use nonce issued by the service. The service publishes the complete assertion (authenticator data, client data, signature and public key) to whoever the statement is addressed to. Only a seal of it enters the log (), so the log alone neither reveals content nor links two statements by the same person. Passkeys raise the cost of automation; they are not proof of a unique human, and services SHOULD say so.

Log

Leaves for Signed Statements A leaf for a signed statement is the canonical JSON object , "kind": , "public_key": , "signature": , "statement_seq": } ]]> Anyone can re-verify the signature from the leaf alone.

Seals

Statement by a person:

{"commitment": hex(SHA-256(canonical assertion package)), "kind": <type>}.

Rules of the service:

{"document": <name>, "kind": "humancollab.legal_document.v1", "sha256": <hex of the plain text>, "url": <address of that version>, "version": <identifier>}. Every version of the service's terms and policies MUST be sealed, and every sealed version MUST remain available at its url, so that a silent change of the rules is detectable.

Tree Heads, Anchoring and Monitoring Leaves are hashed as in : SHA-256(0x00 || leaf) and SHA-256(0x01 || left || right). The log serves inclusion and consistency proofs, signs tree heads as checkpoints in signed notes , and timestamps each published root on Bitcoin through OpenTimestamps . Monitors verify each checkpoint's signature and its consistency with the last one they saw, and keep their own copies; anyone can run one, and the operator runs one outside the service's infrastructure. Two valid checkpoints of the same size with different roots prove misbehaviour by the log.

Portable Attestations A service MAY issue Verifiable Credentials (Data Integrity, eddsa-jcs-2022 ) stating that a domain was proven by a given method and that a statement version was signed by the bound key and logged at a given index. Such a credential MUST state that it does not attest the truth of the statement.

What Readers Can Conclude Conclusions a reader can draw

Reader checks	Conclusion
Signature valid, key bound to domain by DNS	The domain's controller made this statement
Leaf included in a checkpoint seen by monitors	The statement was public at that time and was not rewritten
Key history shows a recent change	Weigh the change; control of the domain changed hands or was re-proven
Statement contradicted by independent sources	The author is accountable for a false statement

Privacy Considerations The log stores no personal data for people: only seals. Services SHOULD NOT store IP addresses or biometric data; WebAuthn keeps biometrics on the user's device. Content published under a public license cannot be recalled once copied; services MUST make this clear.

Security Considerations

• Control of a domain's DNS is control of its statements. Readers SHOULD weigh recent key changes.
• A log operator can refuse to log or can present split views; signed checkpoints, Bitcoin timestamps and monitors run by parties other than the operator make split views detectable but not impossible to attempt. Witness cosigning further reduces this risk.
• Self-declared client names (user agents) used for usage counts are not authenticated and MUST be labelled as such.
• Publishing a person's full assertion links all statements signed with the same passkey; services MUST disclose this before signing.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. W3C n.d. Informative References W3C n.d. W3C n.d. C2SP n.d. C2SP n.d. C2SP n.d. OpenTimestamps n.d. humancollab n.d.

Acknowledgments The reference implementation and its specification are public domain (CC0 1.0) at https://github.com/furkanYanteri1/humancollab-protocol.