NHE Constrained Bootstrap: A Self-Describing Capability and Constraint Declaration Protocol for Autonomous Agents

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.

Relationship to the NHE Architecture This document specifies part of the Governance interface of 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 , and the key that signs 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 governs whether a specific action is permitted at the time it is attempted.

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

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.

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. The manifest is signed over its canonical serialization --- JSON Canonicalization Scheme , 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 ().

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.

The Bootstrap Handshake The bootstrap is a fixed, non-recursive sequence:

The entity introspects and builds its capability manifest.
The entity registers with the coordinator over a mutually authenticated transport.
The coordinator derives a per-entity key --- for example by an HKDF 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.
The entity re-signs its manifest with the derived (or its own asymmetric) key and returns it.
The coordinator verifies the re-signed manifest by independently re-deriving the key (or checking the registered public key) and recomputing the signature.
The coordinator registers the entity with its verified manifest, computed tier, and key identifier.

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.

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.

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.

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 and/or the hardware-rooted attestation profile referenced there, plus spot-check capability assurance (). 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 MUST be identical at signing and verification, or valid manifests will be rejected or, worse, a 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.

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 . No IANA action is requested by this skeleton revision.