Individual Submission C.X. Ruvalcaba Internet-Draft Saluca LLC Intended status: Standards Track 11 August 2026 Expires: 12 February 2027 NHE Constrained Bootstrap: A Self-Describing Capability and Constraint Declaration Protocol for Autonomous Agents draft-ruvalcaba-nhe-bootstrap-00 Abstract This document specifies how a Non-Human Entity (NHE) declares, at bootstrap, what it is capable of and is thereby bounded in what it is permitted to do. An entity produces a signed, self-describing capability manifest through automated introspection; a coordinator classifies the manifest into a capability tier that maps to a permission matrix --- the set of task types the entity is authorized to perform --- and every subsequent task dispatch is gated against that envelope. The result is a verifiable, self-describing constraint on an entity established at the moment it joins, realizing the bounded-authority invariant of the NHE architecture at boot time. The manifest and handshake data model is specified here; the wire encoding is deferred to the next revision. 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. Ruvalcaba Expires 12 February 2027 [Page 1] Internet-Draft NHE Bootstrap August 2026 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. Relationship to the NHE Architecture . . . . . . . . . . . . 2 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. The Capability Manifest . . . . . . . . . . . . . . . . . . . 3 5. Capability Tiers and the Permission Matrix . . . . . . . . . 4 6. The Bootstrap Handshake . . . . . . . . . . . . . . . . . . . 4 7. Dispatch Gating and Capability Assurance . . . . . . . . . . 5 8. Wire Format (to be specified in -01) . . . . . . . . . . . . 5 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 11. Normative References . . . . . . . . . . . . . . . . . . . . 6 12. Informative References . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction An autonomous entity should not be trusted to do whatever it asks to do; it should be bounded to what it is actually capable of and authorized for, and that bound should be established verifiably when it joins, not assumed. This document specifies a bootstrap in which an entity *describes itself* --- its resources, its capabilities, the actions it can perform --- in a signed manifest, is classified into a permission envelope on that basis, and is thereafter gated so that a task exceeding its declared and authorized capability is never dispatched to it. The motivating case is an entity that can drive physical actuation: dispatching an actuator task to an entity not tier-authorized for it is a safety failure, not merely a routing error. 2. Relationship to the NHE Architecture This document specifies part of the Governance interface of [I-D.ruvalcaba-nhe-arch] and is the boot-time realization of that model's *bounded-authority* invariant: authority is conferred by classification of a verifiable self-description into a permission envelope, and is exercised only within it. The entity is named by its NHE identity [I-D.ruvalcaba-nhe-identity], and the key that signs Ruvalcaba Expires 12 February 2027 [Page 2] Internet-Draft NHE Bootstrap August 2026 its manifest is bound to that identity, so a capability assertion is tied to the entity making it. This protocol governs what an entity may ever do; the companion backchannel-authorization protocol [I-D.ruvalcaba-nhe-authz] governs whether a specific action is permitted at the time it is attempted. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119] [RFC8174]. Capability manifest: A self-describing declaration of an entity's resources and capabilities, produced by introspection and signed by the entity. Capability tier: A class assigned by the coordinator from the manifest via quantitative thresholds. Permission matrix: The set of task types and subtypes a tier is authorized to perform. Constraint manifest: The capability manifest together with the tier- derived permission matrix; the entity's full authorization envelope. Coordinator: The party that classifies manifests, registers entities, and gates task dispatch. 4. The Capability Manifest An entity produces its capability manifest by automated introspection. The manifest declares at least: a stable entity identifier bound to the entity's identity, an enumeration of computational resources, an enumeration of the classes of action the entity can perform (including any that affect the physical world), an enumeration of locally available inference capabilities with measured throughput, and network characteristics. The specific fields are extensible; the requirement is that the manifest be a complete, honest self-description sufficient for classification. Ruvalcaba Expires 12 February 2027 [Page 3] Internet-Draft NHE Bootstrap August 2026 The manifest is signed over its *canonical serialization* --- JSON Canonicalization Scheme [RFC8785], with the signature and signature- method fields excluded from the signed content --- so any verifier recomputes byte-identical signed input. The signature MAY be a symmetric MAC under a coordinator-derived per-entity key (integrity relative to a key-holder) or, where non-repudiation is required, an asymmetric signature under an entity-generated key whose public half is registered (Section 6). 5. Capability Tiers and the Permission Matrix The coordinator classifies a manifest into a capability tier by applying quantitative thresholds to the declared resources and capabilities. Each tier maps to a permission matrix: the task types and subtypes an entity in that tier is authorized to perform. The pairing of the capability manifest with the tier-derived permission matrix is the entity's constraint manifest --- its authorization envelope. Classification is the point at which a self-description becomes a bounded authority. 6. The Bootstrap Handshake The bootstrap is a fixed, non-recursive sequence: 1. The entity introspects and builds its capability manifest. 2. The entity registers with the coordinator over a mutually authenticated transport. 3. The coordinator derives a per-entity key --- for example by an HKDF [RFC5869] from the entity's identity-bound identifier, giving certificate-less identity without PKI provisioning --- and returns it once, over the mutually authenticated channel (a trust-on-first-use root), together with a scoped namespace and a poll interval calibrated to the entity's tier. 4. The entity re-signs its manifest with the derived (or its own asymmetric) key and returns it. 5. The coordinator verifies the re-signed manifest by independently re-deriving the key (or checking the registered public key) and recomputing the signature. 6. The coordinator registers the entity with its verified manifest, computed tier, and key identifier. Ruvalcaba Expires 12 February 2027 [Page 4] Internet-Draft NHE Bootstrap August 2026 Because the per-entity key is derived from the same identity-bound identifier that the signed manifest asserts, the capability assertion is cryptographically knotted to the entity's derived identity: a manifest cannot be presented under one identity but signed as another. 7. Dispatch Gating and Capability Assurance For each proposed task dispatch, the coordinator MUST verify that the task type and subtype are permitted by the target entity's permission matrix, that the capabilities the task requires are declared present in the target's manifest, and that the target is active. A task is enqueued only if all hold; otherwise it is rerouted to an entity whose tier and manifest permit it, or denied. This is what prevents capability-exceeding dispatch. Because a self-description is self-reported and therefore potentially false, the coordinator SHOULD perform capability assurance under trust-on-first-use: it dispatches a test task exercising a claimed capability and compares the result to an expected oracle, demoting or quarantining an entity whose claimed capability does not check out. Self-report establishes the envelope; spot-check and identity binding keep it honest. 8. Wire Format (to be specified in -01) The manifest content model, its canonical serialization and signature, the tier-and-permission-matrix model, the six-step handshake, and the dispatch gating rule are fixed by this revision. The concrete encodings of the manifest and the handshake messages are deferred to the next revision. 9. Security Considerations A capability manifest is self-reported, so its declarations authenticate an entity only as strongly as the key that signs it and the assurance that backs it. A symmetric-MAC manifest provides integrity relative to a key-holder but not non-repudiation, and an identifier derived from semi-public attributes does not by itself authenticate hardware; deployments needing non-repudiation or hardware assurance MUST use the asymmetric-key variant bound to identity [I-D.ruvalcaba-nhe-identity] and/or the hardware-rooted attestation profile referenced there, plus spot-check capability assurance (Section 7). The derived per-entity key is returned once over the mutually authenticated channel; that channel is the trust- on-first-use root and MUST be strongly authenticated. Canonicalization [RFC8785] MUST be identical at signing and verification, or valid manifests will be rejected or, worse, a Ruvalcaba Expires 12 February 2027 [Page 5] Internet-Draft NHE Bootstrap August 2026 binding gap will open. Dispatch gating is a safety control, not only an authorization one: for actions affecting the physical world, a gating bypass can cause physical harm, so gating MUST fail closed --- an unclassifiable or unverifiable entity receives no permissions. 10. IANA Considerations A future revision will request registries for capability-manifest field identifiers and for task-type/subtype identifiers used in permission matrices, under a Specification Required policy [RFC8126]. No IANA action is requested by this skeleton revision. 11. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, . 12. Informative References [I-D.ruvalcaba-nhe-arch] Ruvalcaba, C.X., "An Architecture for Non-Human Entities (NHE)", Work in Progress, Internet-Draft, draft-ruvalcaba- nhe-arch-00, August 2026, . [I-D.ruvalcaba-nhe-authz] Ruvalcaba, C.X., "NHE Backchannel Authorization", Work in Progress, Internet-Draft, draft-ruvalcaba-nhe-authz-00, August 2026, . [I-D.ruvalcaba-nhe-identity] Ruvalcaba, C.X., "NHE Identity", Work in Progress, Internet-Draft, draft-ruvalcaba-nhe-identity-00, August 2026, . Ruvalcaba Expires 12 February 2027 [Page 6] Internet-Draft NHE Bootstrap August 2026 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017, . Author's Address Cristian Xavier Ruvalcaba Saluca LLC Email: cristian@saluca.com Ruvalcaba Expires 12 February 2027 [Page 7]