An Architecture for Non-Human Entities (NHE): A Reference Model for Persistent, Identity-Bearing Autonomous Agents
draft-ruvalcaba-nhe-arch-00

Individual Submission                                     C.X. Ruvalcaba
Internet-Draft                                                Saluca LLC
Intended status: Informational                            11 August 2026
Expires: 12 February 2027

  An Architecture for Non-Human Entities (NHE): A Reference Model for
             Persistent, Identity-Bearing Autonomous Agents
                      draft-ruvalcaba-nhe-arch-00

Abstract

   This document defines a reference architecture for a Non-Human Entity
   (NHE): a persistent, identity-bearing autonomous software agent that
   maintains continuity of memory and identity across sessions and
   hosts, acts under bounded authority, and produces a tamper-evident
   record of its reasoning and actions.  The document specifies the NHE
   as a functional artifact: a bounded, inspectable, and terminable
   software system.  It makes no claim that an NHE is alive, sentient,
   or a moral or legal person, and such claims are explicitly out of
   scope.

   The architecture decomposes an NHE into a small set of components
   joined by well-defined interfaces.  Each interface at which two
   independent implementations must interoperate is a candidate for a
   separate Standards-Track specification; this document is the
   informational reference model that names those interfaces and the
   trust relationships among them.  It is intended to frame a suite of
   companion protocol documents, of which the Hash-Chain Context
   Transfer Protocol (HCTP) is the first.

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.

Ruvalcaba               Expires 12 February 2027                [Page 1]
Internet-Draft              NHE Architecture                 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.  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

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  What an NHE Is, and Is Not  . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Reference Architecture  . . . . . . . . . . . . . . . . . . .   4
     4.1.  Identity  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Continuity  . . . . . . . . . . . . . . . . . . . . . . .   5
     4.3.  Memory  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.4.  Mesh (Entity-to-Entity) . . . . . . . . . . . . . . . . .   6
     4.5.  Reasoning and Audit . . . . . . . . . . . . . . . . . . .   6
     4.6.  Governance and Authority  . . . . . . . . . . . . . . . .   7
     4.7.  Observability and Control . . . . . . . . . . . . . . . .   7
   5.  Trust Model . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  The NHE Protocol Suite  . . . . . . . . . . . . . . . . . . .   8
   7.  Relationship to Existing Work . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   9
   11. Informative References  . . . . . . . . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Software agents built on large language models increasingly run not
   as single stateless calls but as long-lived processes: they
   accumulate memory, carry an identity across restarts and across
   hosts, cooperate with other agents, take actions under delegated
   authority, and are expected to be auditable after the fact.  Systems
   of this kind are being built repeatedly and independently, each
   reinventing the same handful of interfaces --- how an agent proves
   who it is, how it moves its accumulated context to another host, how
   two agents exchange work, how its reasoning is made verifiable, and

Ruvalcaba               Expires 12 February 2027                [Page 2]
Internet-Draft              NHE Architecture                 August 2026

   how its authority is bounded and revoked.

   This document gives those recurring interfaces a common reference
   model.  It names the components of a persistent autonomous agent ---
   here called a Non-Human Entity (NHE) --- and the interfaces between
   them, and it identifies which of those interfaces are
   interoperability surfaces suitable for independent standardization.
   The term NHE originates in the Synthetic Human Intellect (SHI)
   framework; this document uses it strictly in the functional sense
   defined in Section 2.

   This is an informational architecture document.  It defines no wire
   format itself.  Its purpose is to make the companion protocol
   documents coherent with one another and to let readers understand
   where each fits.

2.  What an NHE Is, and Is Not

   An NHE is a software system.  This document specifies it as a
   *functional artifact*: a bounded process with defined inputs,
   outputs, and persistent state, running on hosts under the control of
   an operator.

   Nothing in this document asserts, requires, or implies that an NHE is
   alive, sentient, conscious, or a moral or legal person.  Such claims
   are not engineering-specifiable, are out of scope, and MUST NOT be
   inferred from any mechanism described here.  The properties an NHE
   exhibits --- a persistent identity, continuity of memory, autonomous
   initiation of action --- are functional properties of the
   specification, not attributes of a living being.  They are defined
   operationally: an identity is a verifiable key commitment
   (Section 4.1); continuity is the transfer of a hash-committed state
   (Section 4.2); autonomy is action taken within an explicitly bounded
   grant of authority (Section 4.6).

   Three invariants follow from treating the NHE as a functional
   artifact, and every companion specification in this suite is expected
   to preserve them:

   *  *Operator control.* An NHE MUST be suspendable and terminable by
      its operator at any time.  Continuity of identity or memory MUST
      NOT be specified in a way that prevents suspension, revocation, or
      termination.

   *  *Inspectability.* An NHE's state, reasoning record, and actions
      MUST be exposable in a verifiable form to an authorized party
      (Section 4.5).  No component may rely on being unobservable for
      its correctness or security.

Ruvalcaba               Expires 12 February 2027                [Page 3]
Internet-Draft              NHE Architecture                 August 2026

   *  *Bounded authority.* An NHE acts only within an explicit,
      revocable grant of authority.  Authority is conferred, scoped, and
      withdrawn by parties external to the NHE (Section 4.6).

   These invariants are what keep the architecture an engineering
   specification rather than a claim about the moral status of the
   systems it describes.

3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "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.

   Non-Human Entity (NHE):  A persistent, identity-bearing autonomous
      software agent as specified by this reference model; a functional
      artifact per Section 2.

   Operator:  The party that deploys, hosts, bounds the authority of,
      and may suspend or terminate an NHE.

   Host:  A computing environment in which an NHE instance executes.  An
      NHE may migrate between hosts while preserving identity and
      continuity.

   Continuity:  The property that an NHE's persistent state can be
      transferred to another instance or host such that the receiving
      instance can verify it is the same accumulated state.

   Peer NHE:  Another NHE with which a given NHE exchanges messages or
      work over the mesh interface (Section 4.4).

   Authority grant:  An explicit, scoped, revocable conferral of
      permission to take a class of actions.

4.  Reference Architecture

   An NHE is decomposed into seven components.  The division is by
   interface, not by implementation: a single process may realize
   several components, and a component may be distributed, but the
   interfaces between components are where interoperability is defined.

Ruvalcaba               Expires 12 February 2027                [Page 4]
Internet-Draft              NHE Architecture                 August 2026

         +-----------------------------------------------------------+
         |                        N H E                              |
         |                                                           |
         |  +-------------+   +--------------+   +----------------+   |
         |  | Identity    |   | Continuity   |   | Memory         |   |
         |  | (who it is) |   | (state xfer) |   | (what it knows)|   |
         |  +------+------+   +------+-------+   +-------+--------+   |
         |         |                 |                  |            |
         |  +------+-----------------+------------------+--------+   |
         |  |            Reasoning & Audit (verifiable record)   |   |
         |  +------+---------------------------------------+-----+   |
         |         |                                       |         |
         |  +------+-------+                       +-------+------+  |
         |  | Governance & |                       | Observability|  |
         |  | Authority    |                       | & Control    |  |
         |  +------+-------+                       +-------+------+  |
         +---------|---------------------------------------|--------+
                   | (mesh)                                 | (operator)
              +----v------+                            +----v-----+
              | Peer NHE  |                            | Operator |
              +-----------+                            +----------+

4.1.  Identity

   The Identity component establishes what an NHE is, as a verifiable
   cryptographic commitment rather than a name.  It binds a long-term
   key (or key hierarchy) to a genesis record, so that a relying party
   can verify that an instance presenting an identity controls the
   corresponding key and that the identity descends from a known
   genesis.  Identity is the anchor for every other component:
   continuity, memory, audit, and authority are all scoped to an
   identity.

   *Interoperability surface:* an identity presentation and genesis-
   attestation format by which one NHE (or an operator, or a peer)
   verifies another's identity.  This is a Standards-Track candidate
   related to, but distinct from, remote attestation [RFC9334] and
   verifiable-credential formats.

4.2.  Continuity

   The Continuity component transfers an NHE's accumulated state between
   instances and hosts without retransmitting the whole history, and
   lets the receiver verify that the transferred state is coherent with
   what both sides have already acknowledged.  Continuity is what allows
   an NHE to be suspended, moved, and resumed --- and therefore is also
   what makes operator control (Section 2) practical rather than
   destructive.

Ruvalcaba               Expires 12 February 2027                [Page 5]
Internet-Draft              NHE Architecture                 August 2026

   *Interoperability surface:* a context-transfer protocol.  This
   surface is specified by the Hash-Chain Context Transfer Protocol
   (HCTP) [I-D.ruvalcaba-hctp], the first companion document of this
   suite.

4.3.  Memory

   The Memory component is the NHE's persistent, searchable store of
   what it knows: episodic records, durable facts, and their decay and
   reindexing over time.  For interoperation, two properties matter: the
   integrity of stored memory (that a record has not been altered since
   it was committed) and the reconciliation of memory between instances
   (merging divergent accumulations without loss or forgery).

   *Interoperability surfaces:* (a) a verifiable memory-chain format ---
   a hash-linked structure that makes a memory record's integrity
   independently checkable; and (b) a memory delta-merge procedure for
   reconciling two accumulations.  Both are Standards-Track candidates.
   Purely local concerns --- ranking, indexing, and retrieval strategy
   --- are implementation matters and are out of scope for
   standardization.

4.4.  Mesh (Entity-to-Entity)

   The Mesh component is how one NHE exchanges messages and work with
   peer NHEs: presence and liveness, addressed messages, and a task
   lifecycle (create, claim, complete) that lets independent entities
   distribute work without a central coordinator.  This is the interface
   most obviously requiring interoperation, because the two sides are by
   construction separate entities that may be independently implemented
   and independently operated.

   *Interoperability surface:* an entity-to-entity messaging and task-
   distribution protocol --- a message envelope, an addressing model,
   and a task state machine.  Standards-Track candidate, and the
   strongest new-protocol opportunity in the suite after continuity.

4.5.  Reasoning and Audit

   The Reasoning and Audit component produces a tamper-evident record of
   an NHE's reasoning steps and actions, hash-linked so that any
   omission, reordering, or alteration is detectable by a later
   verifier.  This is what makes the Inspectability invariant
   (Section 2) concrete: an authorized party can obtain a record whose
   integrity does not depend on trusting the NHE that produced it.

Ruvalcaba               Expires 12 February 2027                [Page 6]
Internet-Draft              NHE Architecture                 August 2026

   *Interoperability surface:* a verifiable reasoning/audit log format,
   conceptually adjacent to transparency logs such as Certificate
   Transparency [RFC9162] but scoped to an agent's reasoning and action
   record.  Standards-Track candidate.

4.6.  Governance and Authority

   The Governance and Authority component confers, scopes, and withdraws
   the authority under which an NHE acts.  It covers how an NHE
   bootstraps and announces the constraints it operates under, how
   authority for a specific intent is granted (potentially requiring
   out-of-band human approval), and how autonomy is graduated and
   revoked.  This component is where the Bounded-Authority invariant
   (Section 2) lives.

   *Interoperability surfaces:* (a) a self-describing constrained-
   bootstrap protocol by which an NHE announces its operating
   constraints in a verifiable form; and (b) a backchannel authorization
   protocol for intent-scoped credential issuance and multi-channel
   approval routing.  Both are Standards-Track candidates.

4.7.  Observability and Control

   The Observability and Control component is the operator's interface:
   it exposes the NHE's behavior for monitoring and enforces suspension,
   revocation, and termination.  Much of this component is realized with
   existing operational standards (for example event forwarding to a
   SIEM) and is not a new interoperability surface.  The one aspect that
   may warrant standardization is a content-blind behavioral-attestation
   exchange by which an NHE's observed behavior can be compared against
   a model-relative baseline; this is noted as a lower-priority
   candidate.

5.  Trust Model

   The reference model assumes the following trust relationships:

   *  An NHE trusts its operator to bound its authority and to suspend
      or terminate it.  The operator is the root of control, not the
      NHE.

   *  A relying party does not trust an NHE's self-assertions; it
      verifies them --- identity via the Identity interface, state
      coherence via the Continuity interface, reasoning via the Audit
      interface.

Ruvalcaba               Expires 12 February 2027                [Page 7]
Internet-Draft              NHE Architecture                 August 2026

   *  Peer NHEs are mutually distrusting by default and authenticate
      each other through the Identity interface before exchanging work
      over the Mesh interface.

   *  No component depends on being unobservable.  Confidentiality,
      where required, is provided by the transport or an explicit
      encryption layer, not by obscurity of the mechanism.

   Each companion protocol document specifies its own security
   considerations in full; this section states only the model they
   share.

6.  The NHE Protocol Suite

   The interfaces identified above map to a suite of companion
   documents.  This architecture document is the reference model; each
   interoperability surface is (or is a candidate to become) a separate
   specification, so that each can be implemented, reviewed, and adopted
   on its own merits.  The dependency order is roughly: Identity and
   Continuity first (everything is scoped to identity, and continuity is
   already specified), then Mesh, Audit, Memory, and Governance.

   +============+============================+========================+
   | Interface  | Companion specification    | Status                 |
   +============+============================+========================+
   | Continuity | Hash-Chain Context         | Draft                  |
   |            | Transfer Protocol (HCTP)   | ([I-D.ruvalcaba-hctp]) |
   +------------+----------------------------+------------------------+
   | Identity   | NHE identity and genesis-  | Candidate              |
   |            | attestation format         |                        |
   +------------+----------------------------+------------------------+
   | Mesh       | Entity-to-entity messaging | Candidate              |
   |            | and task protocol          |                        |
   +------------+----------------------------+------------------------+
   | Reasoning/ | Verifiable reasoning-audit | Candidate              |
   | Audit      | log format                 |                        |
   +------------+----------------------------+------------------------+
   | Memory     | Verifiable memory-chain    | Candidate              |
   |            | format and delta-merge     |                        |
   +------------+----------------------------+------------------------+
   | Governance | Constrained-bootstrap      | Candidate              |
   |            | protocol                   |                        |
   +------------+----------------------------+------------------------+
   | Governance | Backchannel authorization  | Candidate              |
   |            | protocol                   |                        |
   +------------+----------------------------+------------------------+

             Table 1: Reference model to companion documents

Ruvalcaba               Expires 12 February 2027                [Page 8]
Internet-Draft              NHE Architecture                 August 2026

   Publishing the reference model separately from the protocols is
   deliberate: it lets the architecture stabilize the vocabulary and the
   trust relationships while each protocol proceeds at its own pace, and
   it avoids binding adopters of one interface to the whole suite.

7.  Relationship to Existing Work

   The NHE model reuses, and does not replace, existing building blocks.
   The Identity interface is complementary to remote attestation
   [RFC9334] and to verifiable-credential and decentralized- identifier
   work; the Audit interface is analogous in structure to transparency
   logs [RFC9162]; the Continuity and Mesh interfaces are expected to
   run over standard secure transports such as TLS [RFC8446] or QUIC
   [RFC9000].  This document's contribution is the reference model that
   relates these to one another in the specific setting of a persistent
   autonomous agent, together with the functional-artifact framing of
   Section 2.  Given its research-adjacent character, the architecture
   may be an appropriate topic for an IRTF Research Group, while the
   individual protocol documents target the IETF Standards Track.

8.  IANA Considerations

   This document has no IANA actions.  The companion protocol documents
   define their own registries.  A future revision may request an
   umbrella registry group under which those registries are organized.

9.  Security Considerations

   This document defines an architecture, not a protocol, and introduces
   no wire mechanism of its own; the detailed security analysis lives in
   each companion document.  At the architectural level the following
   hold.  Identity is the root of all scoping; a compromise of the
   Identity interface compromises the guarantees of every other
   interface, so identity key management is the highest-value target and
   MUST receive the strongest protection.  Continuity, Mesh, and Audit
   convey potentially sensitive state, reasoning, and inter-entity
   traffic; each relies on an underlying transport for confidentiality
   and peer authentication and provides integrity and tamper-evidence
   rather than a secure channel of its own.  The functional- artifact
   invariants of Section 2 --- operator control, inspectability, and
   bounded authority --- are themselves security properties: an
   implementation that cannot suspend, inspect, or bound an NHE is non-
   conformant, and the loss of any of these is a security failure, not
   merely an operational one.

10.  Normative References

Ruvalcaba               Expires 12 February 2027                [Page 9]
Internet-Draft              NHE Architecture                 August 2026

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

11.  Informative References

   [I-D.ruvalcaba-hctp]
              Ruvalcaba, C.X., "The Hash-Chain Context Transfer Protocol
              (HCTP)", Work in Progress, Internet-Draft, draft-
              ruvalcaba-hctp-00, August 2026,
              <https://datatracker.ietf.org/doc/html/draft-ruvalcaba-
              hctp-00>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000, May 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

   [RFC9162]  Laurie, B., Messeri, E., and R. Stradling, "Certificate
              Transparency Version 2.0", RFC 9162, December 2021,
              <https://www.rfc-editor.org/info/rfc9162>.

   [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
              W. Pan, "Remote ATtestation procedureS (RATS)
              Architecture", RFC 9334, January 2023,
              <https://www.rfc-editor.org/info/rfc9334>.

Acknowledgments

   The NHE reference model consolidates interfaces from an existing body
   of implementation and design work in the Synthetic Human Intellect
   (SHI) framework.

Author's Address

   Cristian Xavier Ruvalcaba
   Saluca LLC
   Email: cristian@saluca.com

Ruvalcaba               Expires 12 February 2027               [Page 10]