NHE Reasoning-Audit Log: A Tamper-Evident, Content-Optional Audit Chain for Autonomous Agents

Introduction A persistent autonomous agent takes consequential actions and reasons its way to them. After the fact, an authorized party needs a record of what the agent reasoned and did, whose integrity does not depend on trusting the agent that produced it. A plain log does not provide that: the producer can rewrite it. This document specifies a tamper-evident audit chain that does, and that does so without forcing disclosure of the reasoning content itself. Two properties distinguish this from a generic hash-chained log (structurally, the audit chain is a close relative of transparency logs such as Certificate Transparency ). First, it is cross-layer: it captures reasoning at the boundary to a model provider and tool invocations at the execution boundary, normalized into one continuity-preserving chain. Second, it is content-optional with proof-without-exposing: the entry binds the reasoning's identity, provenance, and scale so a verifier can confirm "this subject produced reasoning of this provenance and magnitude, leading to this action" without the reasoning text ever crossing to the verifier.

Relationship to the NHE Architecture This document specifies the Reasoning-and-Audit interface of and is the concrete realization of that model's inspectability invariant: an authorized party can obtain a verifiable record whose integrity is independent of the NHE. The content-optional design is deliberate --- inspectability must not require surrendering the confidentiality of an agent's reasoning, or it will not be deployed. The audit chain's genesis is anchored to the subject's identity () as defined by the NHE identity interface , tying every record to a verified entity.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 .

Audit chain:: The append-only, hash-linked sequence of audit entries for one subject.
Subject:: The NHE whose reasoning and actions are audited, identified per .
Reasoning entry:: An audit entry recording a reasoning step obtained at the boundary to a model provider.
Action entry:: An audit entry recording a tool or command invocation obtained at the execution boundary.
Proof-access scope:: Authorization to obtain proofs and metadata about entries, distinct from and weaker than the content-access scope.
Content-access scope:: Authorization to obtain the stored content of an entry, where content is retained.

Audit Chain Model

Entry Structure Each entry binds, at minimum, the following fields into its entry hash. A verifier recomputes the entry hash over the identical field set, so any single-field alteration breaks the chain: Binding the provenance and scale fields (provider, model, token_count, byte_count) into the hash is essential: an audit that hashed only an opaque content digest would let an adversary alter "which model reasoned" or "how much reasoning occurred" without breaking the chain. byte_count is the always-present, deterministic scale attestation; token_count is present only when a provider-reported count or a named tokenizer makes it reproducible.

Canonical Serialization (CANON) CANON produces a deterministic preimage so that any verifier recomputes byte-identical input. Each field is encoded as an 8-octet big-endian length prefix followed by its octet payload; integers are encoded as fixed 8-octet big-endian values; timestamps are RFC 3339 UTC nanosecond strings. An absent optional field is encoded with a distinguished length sentinel of 0xFFFFFFFFFFFFFFFF, which is distinct from a present empty value (length 0), so that a null and an empty string can never collide. Length-prefixing removes the concatenation ambiguity by which ("ab","c") and ("a","bc") would otherwise share a preimage.

Genesis, Linkage, and Verification The prev_hash of the genesis entry is defined as HASH(CANON(subject_id)) --- the chain is anchored to the subject's identity, so an audit chain cannot be transplanted between subjects. For every non-genesis entry, the prev_hash MUST equal the entry hash of its immediate predecessor. Appends for a single subject MUST be serialized by a single writer (a queue or a compare-and-set on the chain head) so that linkage is well defined under concurrent events. To verify a range, a verifier recomputes each entry hash from CANON over the entry's fields, confirms each non-genesis prev_hash equals the predecessor's recomputed entry hash, and special-cases the genesis (comparing prev_hash against HASH(CANON(subject_id)) when the range starts at index 0, or trusting a caller-provided anchor link otherwise). Each recomputation is O(1); range verification is O(n).

Content Handling and Retention The content_mode field records, per entry, whether the reasoning or action content is stored in full, represented only by its content_hash, or not captured at all. Content retention is configurable independently of chain retention. Because the chain binds only the content_hash and the metadata, content may be deleted or redacted without breaking the chain: the entry continues to prove that an event with the attested provenance, scale, and identity occurred at its position, even after its content is gone. This separation is what lets an operator satisfy data-minimization or erasure obligations while preserving a verifiable audit. Where content is stored, it SHOULD be protected with an authenticated encryption scheme (for example AES-256-GCM) that binds the entry hash as additional authenticated data, so that ciphertext cannot be transplanted between entries. Implementations MUST preserve nonce uniqueness: under a long-lived per-subject key with random 96-bit nonces, the key MUST be rotated before the per-key record count approaches the birthday bound ( and NIST SP 800-38D), or a deterministic per-record nonce MUST be used.

Prove-Without-Exposing A holder of the proof-access scope, without the content-access scope, can obtain a proof that a given entry exists in the chain at a given index with the attested metadata (subject, provider, model, scale, capture and content modes) and is correctly linked to its neighbors --- without receiving the entry's content. This is the property that makes inspectability deployable: an auditor confirms "the correct model was used, reasoning of the expected magnitude occurred, and it led to this action" while the reasoning text itself remains confidential. The proof-access scope and the content-access scope MUST be separately enforceable; granting proof access MUST NOT imply content access.

Cross-Layer Capture Reasoning entries are produced at the boundary between the subject and a model provider, extracting the reasoning trace from the provider's response according to a provider-specific procedure and normalizing heterogeneous provider formats into one chain. Action entries are produced at the execution boundary, capturing a tool or command invocation and its outcome. Both kinds share the entry structure and the single chain, so a verifier sees one continuity-preserving record that correlates reasoning with the actions it led to. An implementation MAY additionally maintain a local, identity-anchored copy of the chain so that a failure to append remotely is itself detectable on later reconciliation rather than silently lost.

Complexity-Divergence Signal (Optional) An implementation MAY compute, over a trailing window of a subject's entries, a reasoning-complexity measure (token_count, or byte_count when tokens are absent) and an action-complexity measure (a defined function of an action's argument count, size, and sensitivity), and flag an entry whose standardized residual between the two exceeds a configurable multiple of the windowed standard deviation. A large divergence --- a consequential action preceded by little reasoning, or vice versa --- is a signal worth surfacing. This is an analysis over the chain, not a property of it, and is out of scope for interoperation beyond the fields the chain already binds.

Wire and Proof Encoding (to be specified in -01) The entry data model, CANON, the identity-anchored genesis, and the verification procedure are fixed by this revision. The concrete encodings --- of entries on the wire, of the prove-without-exposing proof object, and of the encrypted-content envelope --- are deferred to the next revision, following the compact-binary approach of HCTP .

Security Considerations The chain provides tamper-evidence, not authorship: an unkeyed hash chain proves internal linkage and that no entry was altered after the fact relative to its neighbors, but a party able to rebuild the whole chain can produce a consistent alternative. Authorship and non-repudiation require signing the chain head (or entries) under the subject's identity key and/or periodic external anchoring (for example publishing chain heads to a transparency log ); deployments needing to prove the log was not wholesale rewritten MUST do one of these. The genesis anchor to subject identity prevents cross-subject transplant and MUST be verified. Content, where stored, is the sensitive part; its confidentiality rests on the AEAD layer and on strict separation of the content-access and proof-access scopes (). A verifier MUST NOT be able to escalate from proof access to content access. Redaction of content MUST leave the bound content_hash and metadata intact so that verification still succeeds over the remaining entries; an implementation that deletes bound fields rather than only unbound content breaks verifiability and is non-conformant. Single-writer serialization () is security-relevant: concurrent appends without it can fork the chain. Finally, a failure to record MUST be treated as a security event, not an operational nuisance --- the local identity-anchored chain exists so that gaps are detectable rather than deniable.

IANA Considerations A future revision will request registries for "NHE Audit Capture Modes" (reasoning, action), "NHE Audit Content Modes" (full, hash-only, none), and the hash and AEAD suites used by the chain, each under a Specification Required policy . No IANA action is requested by this skeleton revision.