| Internet-Draft | NHE Authz | August 2026 |
| Ruvalcaba | Expires 12 February 2027 | [Page] |
This document specifies how a consequential action attempted by a Non-Human Entity (NHE) is authorized at the time it is attempted. A security runtime transparently intercepts an entity's outbound action, so the entity holds no standing credentials, and classifies it under graduated autonomy as autonomous, supervised, or denied. A supervised action triggers a backchannel approval flow that presents a human approver with a human-readable rendering of the exact operation; on approval the runtime issues an intent-scoped, single-use, short-lived credential cryptographically bound to that specific action, which an enforcement point verifies against the operation actually being forwarded. The same canonical parameter digest scopes the credential and appears in the human-facing description, so the approver provably authorizes exactly what the credential permits. The flow and credential data model are specified here; the wire encoding is deferred to the next revision.¶
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 (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.¶
A persistent autonomous entity will attempt actions of widely varying consequence, from the trivial to the irreversible. Granting it standing credentials broad enough for all of them makes every prompt injection or reasoning error a potential catastrophe. This document specifies an authorization model in which the entity holds no standing credentials at all: a security runtime transparently intercepts each outbound action --- with no change to the entity's own logic --- decides, by the action's sensitivity, whether it may proceed autonomously, requires human approval, or is denied, and, when it proceeds, authorizes it with a credential scoped to that one action and no more.¶
This document specifies part of the Governance interface of [I-D.ruvalcaba-nhe-arch] and is the action-time realization of that model's bounded-authority invariant: authority for a specific action is conferred as a single-use, scope-bound, short-lived grant, and consequential actions require an external human grant. It complements the bootstrap protocol [I-D.ruvalcaba-nhe-bootstrap], which bounds what an entity may ever do; this protocol bounds whether a particular action is permitted now. The acting entity and the human approver are named by NHE identity [I-D.ruvalcaba-nhe-identity], and the authorization flow SHOULD be recorded in the audit chain [I-D.ruvalcaba-nhe-audit].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119] [RFC8174].¶
The security runtime classifies each intercepted action by a sensitivity assessment into one of three autonomy modes: autonomous (the runtime authorizes it directly), supervised (the action requires human approval via the backchannel flow of Section 5), or denied (the action is refused outright). The sensitivity assessment is policy; interoperation requires agreement on the three-mode outcome and the flow each triggers, not on a single classification function.¶
A supervised action triggers an out-of-band approval, decoupled from the entity's action channel (a backchannel flow in the manner of OAuth 2.0 [RFC6749] CIBA). The runtime creates an authorization request with an authentication-request identifier and routes it to the approver over one or more channels, carrying a binding message: a human-readable rendering of the exact operation to be performed. The approver grants or denies; the response MUST carry and be verified against the authentication-request identifier, and for link or reply channels MUST carry an HMAC-signed, single-use, expiring action token so an approver cannot inadvertently approve a different pending request and a response cannot be forged. Critical-sensitivity actions MUST use a channel providing authenticated delivery confirmation. Absent a positive approval --- on denial, delivery failure, approver timeout, or expiry --- the action is denied (Section 9).¶
On authorization (autonomous, or supervised-and-approved), the runtime issues a short-lived credential --- for example a JWT [RFC7519] --- cryptographically bound to the specific action by carrying, as signed claims, the target resource identifier, the operation type, and a digest of the canonicalized operation parameters (JSON Canonicalization Scheme [RFC8785], hashed with a named function), in the spirit of rich, fine-grained authorization [RFC9396]. Altering any bound field invalidates the signature.¶
The single most important property is the digest linkage: the same canonicalized-parameter digest that scopes the credential is the digest rendered to the approver in the binding message. The human therefore provably approves exactly the operation the credential authorizes --- closing the confused-deputy gap in which an approver okays one thing while a different thing is executed.¶
An enforcement point MUST verify, before an operation is forwarded, that the credential's bound claims match the operation actually being forwarded, and MUST reject any presentation whose bound claims do not match. Two modes are supported: in resource-validated mode a credential-aware target validates the credential directly; in enforcement-point mode --- for targets that cannot validate the credential --- the enforcement point verifies it and only then obtains a just-in-time, single-operation backend secret, so credential-unaware targets are supported while the runtime still holds no standing target credential.¶
Authority is single-use and consumed at forward time: the enforcement point MUST atomically mark an identifier of the credential consumed before forwarding, and MUST reject any later presentation of that identifier, using a shared, durable, low-latency consumption store so the guarantee holds across replicas and restarts (defeating replay and time-of-check/time-of-use races). Credential lifetime MUST be measured from issuance and enforced at the enforcement point against a synchronized time source with a bounded skew tolerance.¶
The three-mode autonomy model, the backchannel approval flow, the intent-scoped credential's bound-claim structure and its canonicalization, the digest linkage to the binding message, and the enforcement semantics (bound-claim match, forward-time single-use, fail-closed) are fixed by this revision. The concrete encodings of the approval-flow messages and the credential profile are deferred to the next revision, reusing existing OAuth and JWT encodings where practical.¶
The model's purpose is to shrink the blast radius of a compromised or misled entity: with no standing credentials and per-action scope, a prompt injection can at most attempt one narrowly-scoped, possibly human-gated action rather than wield broad authority. The digest linkage (Section 6) is the anti-confused-deputy control and MUST be preserved end to end: the canonicalization [RFC8785] MUST be identical at binding-message construction, credential issuance, and enforcement, or the human sees one operation while another is authorized. Replay is defeated only if consumption is recorded at forward time in a shared, durable store (Section 7); an in-memory or after-response revocation list leaves an exploitable window. The system MUST fail closed: on authorization-server error, all-channel delivery failure, approver timeout, or expiry, the action is denied and the denial is logged; no positive approval means no credential means no execution. Approval responses MUST be bound to the request identifier and, on reply/link channels, to a single-use expiring token, or an attacker or a careless approver can authorize the wrong request; unauthenticated channels (for example plain SMS) MUST be limited to non-critical actions. The human approval is one input to a machine-enforced cryptographic process, not a substitute for it.¶
A future revision will request registries for autonomy modes (autonomous, supervised, denied) and for the bound-claim names used in intent-scoped credentials, under a Specification Required policy [RFC8126], and will register any new JWT claims via the established JWT claim registry. No IANA action is requested by this skeleton revision.¶