Saluca LLC

cristian@saluca.com

Security Individual Submission authorization autonomous agent human-in-the-loop OAuth least privilege 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.

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.

Relationship to the NHE Architecture This document specifies part of the Governance interface of 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 , 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 , and the authorization flow SHOULD be recorded in the audit chain .

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

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.

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 ), 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.

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 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 ().

Intent-Scoped Credential On authorization (autonomous, or supervised-and-approved), the runtime issues a short-lived credential --- for example a JWT --- 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 , hashed with a named function), in the spirit of rich, fine-grained authorization . 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.

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

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.

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 () is the anti-confused-deputy control and MUST be preserved end to end: the canonicalization 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 (); 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.

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 , and will register any new JWT claims via the established JWT claim registry. No IANA action is requested by this skeleton revision.

Normative References Informative References