| Internet-Draft | Agent Mandate Problem Statement | July 2026 |
| Yossif | Expires 23 January 2027 | [Page] |
An autonomous software agent commonly acts under authority a human granted at an earlier moment: the human expresses and authorizes an intent at one time, and the agent executes one or more concrete actions at a later time. The credentials and session state the agent carries at execution time establish that some agent is authorized to act, but they do not establish that this specific action, with these specific parameters, falls within the constraints the human actually signed. As agent autonomy and action throughput grow, the population of executed actions that no human individually bounded grows with it. This document is a problem statement. It characterizes the gap between an authorized agent and an authorized action, explains why existing delegation, logging, and payment-mandate mechanisms do not close it, and states the requirements any solution would have to satisfy. It defines no protocol or mechanism.¶
This note is to be removed before publishing as an RFC.¶
This is an individual submission to the IETF. "Informational" above is the intended status; this document has not been adopted by any IETF working group and does not represent IETF consensus. The author intends to request dispatch of this work (for example through the SECDISPATCH working group) toward consideration by an appropriate working group. Review and comments are welcome.¶
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 23 January 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.¶
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 Section 9.¶
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 [RFC2119] [RFC8174] 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.¶
This document uses the following terms.¶
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 (Section 9).¶
The gap is the absence of any binding between the action executed at T1 and the constraint set the Principal signed at T0. Concretely:¶
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 (Section 5) and what a mechanism that did would have to satisfy (Section 6).¶
Delegated-authorization scopes (as in OAuth 2.0 [RFC6749] 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.¶
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.¶
Recent work defines signed mandates for agent-initiated payments. Specialized frameworks such as [AP2] 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.¶
A mechanism that closes the gap of Section 4 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 Section 3: 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 Section 1.¶
This section is informative. [I-D.yossif-psea] 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 Section 5. 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.¶
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 Section 1: 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 [I-D.yossif-enrollment-problem].¶
This document defines no protocol or mechanism. It states a problem and the requirements a solution must satisfy. The constraint classes of Section 3 are defined conceptually and carry no evaluation procedure; the requirements of Section 6 are properties, not designs. Any encoding, evaluation, binding construction, escalation procedure, or wire format is deliberately left to a separate solution document.¶
This document has no IANA actions.¶