Network Working Group M. K. Yossif Internet-Draft Yuthent Intended status: Informational 22 July 2026 Expires: 23 January 2027 Problem Statement: Verifiable Human Mandates for Autonomous Agent Actions draft-yossif-agent-mandate-problem-00 Abstract 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. Note to Readers 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. 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/. Yossif Expires 23 January 2027 [Page 1] Internet-Draft Agent Mandate Problem Statement July 2026 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. The Uncovered Gap . . . . . . . . . . . . . . . . . . . . . . 5 5. Why Existing Mechanisms Do Not Cover the Gap . . . . . . . . 5 5.1. OAuth Scopes and Static Grants . . . . . . . . . . . . . 5 5.2. Audit Logs . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Payment-Scoped Mandates . . . . . . . . . . . . . . . . . 6 6. Requirements for Any Solution . . . . . . . . . . . . . . . . 6 7. Relationship to draft-yossif-psea . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. No Mechanism Defined . . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Yossif Expires 23 January 2027 [Page 2] Internet-Draft Agent Mandate Problem Statement July 2026 1. 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 Section 9. 2. 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 [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 Yossif Expires 23 January 2027 [Page 3] Internet-Draft Agent Mandate Problem Statement July 2026 itself specifies no protocol behavior. 3. 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 [I-D.yossif-psea]; this document treats it as the T1 counterpart to the T0 mandate and does not re-specify it (Section 7). 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 Yossif Expires 23 January 2027 [Page 4] Internet-Draft Agent Mandate Problem Statement July 2026 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 (Section 9). 4. 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 (Section 5) and what a mechanism that did would have to satisfy (Section 6). 5. Why Existing Mechanisms Do Not Cover the Gap 5.1. OAuth Scopes and Static Grants 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 Yossif Expires 23 January 2027 [Page 5] Internet-Draft Agent Mandate Problem Statement July 2026 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. 5.2. 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. 5.3. Payment-Scoped Mandates 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. 6. Requirements for Any Solution 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. Yossif Expires 23 January 2027 [Page 6] Internet-Draft Agent Mandate Problem Statement July 2026 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. Yossif Expires 23 January 2027 [Page 7] Internet-Draft Agent Mandate Problem Statement July 2026 7. Relationship to draft-yossif-psea 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. 8. 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 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 Yossif Expires 23 January 2027 [Page 8] Internet-Draft Agent Mandate Problem Statement July 2026 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]. 9. 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 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. 10. IANA Considerations This document has no IANA actions. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . 11.2. Informative References [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012, . [I-D.yossif-psea] Yossif, M. K., "PSEA Token Profile: An EAT Profile for Action-Bound, User-Verification-Gated Transaction- Confirmation Evidence", Work in Progress, Internet-Draft, draft-yossif-psea-02, June 2026, . Yossif Expires 23 January 2027 [Page 9] Internet-Draft Agent Mandate Problem Statement July 2026 [I-D.yossif-enrollment-problem] Yossif, M. K., "Problem Statement: Enrollment and Key- Binding Assumptions in Execution Authority Evidence", Work in Progress, Internet-Draft, draft-yossif-enrollment- problem-00, July 2026, . [AP2] Google, "Agent Payments Protocol (AP2)", 2025, . Author's Address Mohamad Khalil Yossif Yuthent Email: mohamad@yuthent.com Yossif Expires 23 January 2027 [Page 10]