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

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 12 February 2027.¶

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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

4. Audit Chain Model

  entry = {
    entry_index      : monotonic position in the chain (integer)
    request_id       : correlator for the audited transaction
    timestamp        : RFC 3339 UTC, nanosecond precision
    subject_id       : identity of the audited NHE
    provider         : model/tool provider identifier (nullable)
    model            : model identifier (nullable)
    content_hash     : digest of the reasoning/action content
    token_count      : reasoning size in tokens (nullable)
    byte_count       : reasoning size in bytes (always present)
    tokenizer_id     : named, versioned tokenizer (nullable)
    capture_mode     : reasoning | action
    content_mode     : full | hash-only | none
    prev_hash        : link to the immediate predecessor
  }
  entry_hash = HASH( CANON(entry) )

  [ genesis ]           [ entry 1 ]         [ entry 2 ]
  prev = H(subject) <-  prev = eh(0)  <-    prev = eh(1)
  eh(0)                 eh(1)               eh(2)

5. 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 ([RFC5116] and NIST SP 800-38D), or a deterministic per-record nonce MUST be used.¶

6. 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.¶

7. 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.¶

8. 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.¶

9. 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 [I-D.ruvalcaba-hctp].¶

10. 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 [I-D.ruvalcaba-nhe-identity] and/or periodic external anchoring (for example publishing chain heads to a transparency log [RFC9162]); 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 (Section 6). 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 (Section 4.3) 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.¶

11. 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 [RFC8126]. No IANA action is requested by this skeleton revision.¶

Author's Address