Individual Submission C.X. Ruvalcaba Internet-Draft Saluca LLC Intended status: Standards Track 11 August 2026 Expires: 12 February 2027 NHE Backchannel Authorization: Graduated Autonomy and Intent-Scoped Credentials for Autonomous Agent Actions draft-ruvalcaba-nhe-authz-00 Abstract 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. 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 Authz 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. Relationship to the NHE Architecture . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Graduated Autonomy . . . . . . . . . . . . . . . . . . . . . 3 5. Backchannel Approval Flow . . . . . . . . . . . . . . . . . . 4 6. Intent-Scoped Credential . . . . . . . . . . . . . . . . . . 4 7. Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 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. Ruvalcaba Expires 12 February 2027 [Page 2] Internet-Draft NHE Authz August 2026 2. Relationship to the NHE Architecture 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]. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119] [RFC8174]. Security runtime: The component that transparently intercepts an entity's outbound actions and drives authorization; the entity is unmodified and holds no standing target credentials. Autonomy mode: The decision for an action: autonomous, supervised, or denied. Intent-scoped credential: A short-lived credential cryptographic- ally bound to one specific approved action. Enforcement point: Where the credential is checked against the operation actually being forwarded. Binding message: The human-readable rendering of the operation shown to the approver. Approver: The human (or delegated authority) who grants or denies a supervised action. 4. Graduated Autonomy 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 Ruvalcaba Expires 12 February 2027 [Page 3] Internet-Draft NHE Authz August 2026 classification function. 5. Backchannel Approval Flow 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). 6. Intent-Scoped Credential 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. 7. Enforcement 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 Ruvalcaba Expires 12 February 2027 [Page 4] Internet-Draft NHE Authz August 2026 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. 8. Wire Format (to be specified in -01) 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. 9. Security Considerations 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. Ruvalcaba Expires 12 February 2027 [Page 5] Internet-Draft NHE Authz August 2026 10. IANA Considerations 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. 11. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, May 2015, . [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-audit] Ruvalcaba, C.X., "NHE Reasoning-Audit Log", Work in Progress, Internet-Draft, draft-ruvalcaba-nhe-audit-00, August 2026, . [I-D.ruvalcaba-nhe-bootstrap] Ruvalcaba, C.X., "NHE Constrained Bootstrap", Work in Progress, Internet-Draft, draft-ruvalcaba-nhe-bootstrap- 00, August 2026, . Ruvalcaba Expires 12 February 2027 [Page 6] Internet-Draft NHE Authz August 2026 [I-D.ruvalcaba-nhe-identity] Ruvalcaba, C.X., "NHE Identity", Work in Progress, Internet-Draft, draft-ruvalcaba-nhe-identity-00, August 2026, . [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, May 2023, . Author's Address Cristian Xavier Ruvalcaba Saluca LLC Email: cristian@saluca.com Ruvalcaba Expires 12 February 2027 [Page 7]