NHE Backchannel Authorization: Graduated Autonomy and Intent-Scoped Credentials for Autonomous Agent Actions
draft-ruvalcaba-nhe-authz-00

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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

   [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>.

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785, June 2020,
              <https://www.rfc-editor.org/info/rfc8785>.

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,
              <https://datatracker.ietf.org/doc/html/draft-ruvalcaba-
              nhe-arch-00>.

   [I-D.ruvalcaba-nhe-audit]
              Ruvalcaba, C.X., "NHE Reasoning-Audit Log", Work in
              Progress, Internet-Draft, draft-ruvalcaba-nhe-audit-00,
              August 2026, <https://datatracker.ietf.org/doc/html/draft-
              ruvalcaba-nhe-audit-00>.

   [I-D.ruvalcaba-nhe-bootstrap]
              Ruvalcaba, C.X., "NHE Constrained Bootstrap", Work in
              Progress, Internet-Draft, draft-ruvalcaba-nhe-bootstrap-
              00, August 2026, <https://datatracker.ietf.org/doc/html/
              draft-ruvalcaba-nhe-bootstrap-00>.

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, <https://datatracker.ietf.org/doc/html/draft-
              ruvalcaba-nhe-identity-00>.

   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework",
              RFC 6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC9396]  Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
              Rich Authorization Requests", RFC 9396, May 2023,
              <https://www.rfc-editor.org/info/rfc9396>.

Author's Address

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

Ruvalcaba               Expires 12 February 2027                [Page 7]