Problem Statement: Verifiable Human Mandates for Autonomous Agent Actions

Introduction Delegated authority for autonomous agents is granted and exercised at two separated moments. At an earlier moment, call it T0, a human expresses an intent and authorizes an agent to act on that intent -- for example, to arrange travel within a budget, to reconcile a set of invoices, or to negotiate and place orders within stated limits. At a later moment, call it T1, the agent executes one or more concrete actions. The temporal separation between T0 and T1 is the defining characteristic of agent delegation: the human is, by design, not present at T1. An agent that reaches T1 carrying valid credentials and a valid session demonstrates that an agent is authorized to act. It does not demonstrate that this action is authorized. Session validity answers "does the caller hold authority granted at some point in the past?"; it does not answer "does the specific action now being executed, with its specific parameters, fall within the constraints the human signed at T0?". Nothing in the credential or the session carries the human's T0 constraints forward and binds them to the T1 action. This is a confused-deputy condition: the agent wields the human's authority over actions the human never individually bounded. Human review does not naturally cover the gap, because throughput scales the gap. A human can meaningfully bound a handful of actions per interaction; an autonomous agent can execute thousands. The larger the ratio of executed actions to human authorization events, the larger the population of actions that no human individually constrained. A mechanism that requires a human decision per action defeats the purpose of delegation, and a mechanism that requires no per-action human constraint leaves every action after T0 unbounded. The problem is to make the human's T0 constraints verifiable at T1 without requiring the human to be present at T1. This document states that problem and the requirements a solution must meet. It deliberately describes no design. Where the text uses the word "requirement", it denotes a property any solution would have to exhibit, not a specification of how to achieve it. An explicit non-goal statement appears in .

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. In this document they are used to state requirements on any solution to the stated problem; this document itself specifies no protocol behavior.

Terminology This document uses the following terms.

Principal: The natural person whose authority the agent exercises. The Principal is present at T0 and, by assumption, absent at T1.
Agent: The autonomous software entity that executes actions at T1 under authority the Principal granted at T0.
T0 / authorization moment: The moment at which the Principal expresses an intent and authorizes the Agent to act, producing the mandate.
T1 / execution moment: The moment at which the Agent executes a concrete action. One authorization at T0 may govern many executions at T1.
Mandate: The set of constraints the Principal authorizes at T0, expressed as data the Principal signs. A mandate bounds the actions the Agent may execute on the Principal's behalf -- for example by naming permitted operations, permitted counterparties, value ceilings, or a validity window. This document treats the mandate as a signed constraint set; it does not define its encoding, its constraint vocabulary, or how it is evaluated.
Action parameters: The concrete attributes of an action executed at T1 (for example the operation name, the counterparty, and the value) that a mandate's constraints range over.
Execution evidence: The verifiable artifact produced at T1 attesting that a specific action was executed under stated authority. Producing such evidence is the subject of ; this document treats it as the T1 counterpart to the T0 mandate and does not re-specify it ().
Hard constraint (class): A constraint class whose violation is not permitted under any circumstance: crossing the boundary means the action is outside the mandate. A value ceiling that may never be exceeded, or a counterparty set outside of which no action may be directed, are hard constraints. This document defines the class conceptually only; it specifies no means of evaluating or enforcing it.
Escalating constraint (class): A constraint class whose crossing does not by itself place the action outside the mandate but instead removes the action from the Agent's autonomous authority and returns the decision to the Principal for fresh authorization. An escalating constraint demotes autonomy back to a human decision rather than failing the action outright. This document defines the class conceptually only; it specifies no means of evaluating it, no threshold semantics, and no interaction with the Principal.

The distinction between the two constraint classes is conceptual and is stated here only to make the problem precise: a mandate's constraints differ in what a solution must do when the boundary is approached or crossed. Defining an evaluation mechanism for either class is out of scope ().

The Uncovered Gap The gap is the absence of any binding between the action executed at T1 and the constraint set the Principal signed at T0. Concretely:

The Principal signs a constraint set at T0, but that signature travels no further than T0 unless something carries it to T1.
The Agent arrives at T1 with credentials and a session that prove authority in general, but carry no bound copy of the Principal's constraints and no way for a verifying party to test the T1 action against them.
The party that executes or authorizes the action at T1 therefore verifies that an authorized agent asked, not that the Principal authorized this action.

Because the two moments are separated and the Principal is absent at T1, the gap cannot be closed by asking the Principal again without defeating delegation. It can only be closed by making the T0 constraints verifiable at T1. The remainder of this document examines why deployed mechanisms do not do so () and what a mechanism that did would have to satisfy ().

Why Existing Mechanisms Do Not Cover the Gap

OAuth Scopes and Static Grants Delegated-authorization scopes (as in OAuth 2.0 access tokens) describe, at grant time, the categories of resource or operation a token may reach. A scope is static with respect to the individual action: it states that the bearer may perform operations of a class, not that a specific action instance -- this counterparty, this value, this moment -- falls within constraints a Principal signed. A scope carries no per-action parameter binding and no representation of a value ceiling, a permitted-counterparty set, or an escalation boundary tied to the individual action. Two actions of the same class but with very different parameters are indistinguishable to the scope. Scopes are necessary infrastructure for expressing that an agent may act; they do not express that the specific action is within the Principal's mandate.

Audit Logs An audit log records that an action occurred. It is written by the same system that executed the action, after the fact, and its entries are assertions by that system about its own behavior. A log is therefore an assertion, not evidence in the sense a third party can independently appraise: it can attest that the system believes an action was authorized, but it cannot, by itself, establish to an independent verifier that the action fell within a constraint set the Principal signed. A log also acts after execution: it is a record of what happened, not a gate that fails an action outside the mandate before it takes effect. Logging is essential for accountability but does not close a gap that must be closed at or before the moment of action.

Payment-Scoped Mandates Recent work defines signed mandates for agent-initiated payments. Specialized frameworks such as facilitate transaction-specific consent, letting a human authorize an agent to make payments within stated bounds and carrying that authorization to the payment execution. Such work is directly relevant, but it is scoped to payment authorization. Its constraint vocabulary and its binding are defined for the payment case -- amounts, payees, and payment instruments -- and it does not generalize to the arbitrary action parameters of non-payment operations (for example a data export, a configuration change, a clinical or administrative action, or a message dispatched on the Principal's behalf). The gap this document states is the general one: binding any action's parameters to a Principal-signed constraint set, of which payment mandates address one important but bounded case.

Requirements for Any Solution A mechanism that closes the gap of would have to satisfy the requirements in this section. These are properties of a solution, stated to scope the problem; this document does not describe a solution that meets them. REQ-1 (Action-to-mandate binding). A solution MUST cryptographically bind the parameters of the action executed at T1 to the constraint set the Principal signed at T0, such that the bound action cannot be altered relative to the constraints it was checked against without detection. A binding that covers only the operation class, or only some parameters, does not satisfy this requirement. REQ-2 (Deterministic server-side verifiability). A solution MUST allow a party other than the Agent to determine, deterministically and without consulting the Agent, whether a given T1 action lies within the Principal's T0 constraints. The determination MUST be reproducible: the same action and the same mandate MUST yield the same verdict at any verifier. REQ-3 (Fail-closed on violation). A solution MUST fail closed. When the action is outside the mandate's hard constraints, or the binding of REQ-1 cannot be verified, the action MUST NOT be treated as authorized. Absence of a positive, verifiable within-mandate result MUST be treated as outside the mandate, not as permission. REQ-4 (Independently verifiable evidence output). A solution MUST produce evidence of the within-mandate determination that an independent party can verify from the evidence and the mandate alone, without trusting the executing system's own assertion and without a shared secret with, or permission from, the executing system. REQ-5 (Transport and format neutrality). A solution MUST NOT depend on a particular transport, a particular agent framework, or a particular action-payload encoding. The binding and the verifiability requirements MUST hold regardless of how the action is conveyed, so that the mechanism applies across the range of operations an agent may execute rather than to a single vertical. REQ-6 (Escalation without re-centralizing every action). A solution SHOULD support the escalating-constraint class of : it SHOULD be able to return a specific action to the Principal for fresh authorization when an escalating boundary is crossed, without requiring the Principal to authorize every action individually. A solution that can only either allow all actions autonomously or require a human decision on each one does not meet the throughput reality described in .

Relationship to draft-yossif-psea This section is informative. defines a token profile for execution evidence: a signed, action-bound artifact that a specific action was executed under a stated, user-verification-gated authority at the moment of execution. In the terms of this document, that work addresses the T1 side -- producing verifiable evidence at the execution moment -- and it binds what is executed to what is signed at T1. It does not address the T0 side. It does not carry a Principal's earlier-signed constraint set forward and test the T1 action against it; the constraint set, its provenance, and the delegation relationship between a Principal at T0 and an Agent at T1 are outside its scope. The gap this document states -- the delegation-constraint layer that binds a T1 action to a T0 mandate -- is therefore uncovered by that work and by the deployed mechanisms of . A solution to the present problem would compose with, rather than replace, execution evidence: execution evidence attests that an action happened under some authority, and the missing layer attests that the authority was the Principal's mandate.

Security Considerations This document defines no mechanism, so it introduces no protocol-specific vulnerabilities; the considerations below are sketched to frame analysis of any future solution and are not exhaustive. The core hazard is the confused-deputy condition of : an Agent executing actions outside the Principal's intended constraints while every downstream artifact -- the session, the credential, the audit log -- still validates. A solution that fails REQ-1 (binding) or REQ-3 (fail-closed) leaves this hazard in place while appearing to address it, which is more dangerous than an acknowledged gap. Any solution moves the critical surface onto the mandate itself. A forged mandate, a mandate replayed to authorize an action the Principal has since had reason to disallow, a mandate substituted for the one the Principal signed, or a mandate whose constraints are widened after signing, would each let an action pass as within-mandate when it is not. The provenance and freshness of the Principal's signature at T0, and the integrity of the constraint set between T0 and T1, are therefore central to any analysis; a solution must specify them. The absence of the Principal at T1 means a solution cannot fall back on interactive human confirmation for every action; the escalating-constraint class (REQ-6) exists precisely so that returning to the Principal is reserved for boundary cases rather than being the only safe default. A poorly chosen escalation boundary can fail in either direction -- escalating so rarely that hard constraints are the only real protection, or so often that delegation collapses into per-action approval. The rooting of any such solution in an enrollment and key-binding assumption is itself a problem treated separately in .

No Mechanism Defined This document defines no protocol or mechanism. It states a problem and the requirements a solution must satisfy. The constraint classes of are defined conceptually and carry no evaluation procedure; the requirements of are properties, not designs. Any encoding, evaluation, binding construction, escalation procedure, or wire format is deliberately left to a separate solution document.

IANA Considerations This document has no IANA actions.