Network Working Group D. Luna Internet-Draft Alygn (Intention Alliance Inc.) Intended status: Informational 19 October 2026 Expires: 22 April 2027 Semantic Governance Requirements for AI Agent Delegation and Handoff draft-luna-eagf-agent-delegation-semantics-00 Abstract AI agents increasingly decide and act on behalf of organizations and delegate work to other agents. Identity, authentication, authorization and runtime control mechanisms establish who is acting and what is permitted, but they do not by themselves preserve the organizational meaning of a delegation: the bounded authority, purpose, material context, and the distinction between a recommendation, a decision, an action and its outcome. This document states requirements, derived from the Enterprise Agent Governance Framework (EAGF), that such semantics be preserved across tool calls, delegations and agent-to-agent handoffs. It defines no new protocol. About This Document This note is to be removed before publishing as an RFC. Project site: https://alygn.us. Contact: tania@alygn.us. Public source repository: https://github.com/taniaalygn/eagf. Copyright in the underlying EAGF architecture is held by Alygn (Intention Alliance Inc.); this Internet-Draft is contributed under BCP 78 / BCP 79. 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 22 April 2027. Luna Expires 22 April 2027 [Page 1] Internet-Draft EAGF Delegation Semantics October 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Relationship to Related Work . . . . . . . . . . . . . . 3 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Invariants . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Requirements for Delegation and Handoff . . . . . . . . . . . 7 5.1. REQ-1: Bounded Authority Scope . . . . . . . . . . . . . 7 5.2. REQ-2: Decision Reference . . . . . . . . . . . . . . . . 7 5.3. REQ-3: Material Context Preservation . . . . . . . . . . 7 5.4. REQ-4: Outcome Reference . . . . . . . . . . . . . . . . 7 5.5. REQ-5: Evidence Kind . . . . . . . . . . . . . . . . . . 8 5.6. REQ-6: Accountable Owner . . . . . . . . . . . . . . . . 8 5.7. REQ-7: No Automatic Trust or Confidence Transfer . . . . 8 5.8. REQ-8: Historical Integrity . . . . . . . . . . . . . . . 8 5.9. Informative Mapping to Control Planes . . . . . . . . . . 8 6. Conformance Considerations . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Mapping to EAGF Conformance Rules (Informative) . . 11 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Luna Expires 22 April 2027 [Page 2] Internet-Draft EAGF Delegation Semantics October 2026 1. Introduction Organizations are moving from using AI as a content-generation tool to delegating work to systems that can plan, call tools, query internal systems, coordinate with other agents and produce effects on business state. Controls that operate only at identity, authentication, authorization or runtime-policy layers leave a semantic gap: they can establish which credential is in use and which permission was granted, but they do not necessarily preserve who the agent is for the organization, who is accountable for it, under what purpose-bounded Authority it acts, whether a Recommendation was adopted as an organizational Decision, whether an Action actually occurred, or what Outcome followed. That gap appears in practice when infrastructure permissions become implicit business authority; when an AI recommendation is treated as a Decision without an adoption rule; when tool invocation, Action and Outcome are collapsed; when Trust or Authority is propagated between agents without contextual justification; when constraints and purpose are lost during agent-to-agent handoffs; or when an agent's self- report is treated as proof that an Action occurred. The Enterprise Agent Governance Framework (EAGF) [EAGF-SPEC] is a vendor-, model-, protocol- and runtime-independent semantic architecture for governed organizational autonomy. It separates concepts that systems often collapse (Claim, Evidence, Assessment, Authority, Decision, Action, Outcome, Trust, Confidence) and states invariants that MUST NOT be collapsed. This document extracts the subset of those requirements that apply specifically to tool calls, delegations and agent-to-agent handoffs, so that protocol and control-plane designers can preserve organizational meaning across boundaries. 1.1. Relationship to Related Work This document is complementary to, and does not replace: * Identity and workload credential work such as [I-D.ietf-wimse-aims], OAuth and related authorization frameworks, which establish who is acting and what is permitted; * Agent communication and tool protocols such as Agent-to-Agent (A2A) and the Model Context Protocol (MCP), which carry messages and tool calls; * Runtime control planes such as the OWASP Agent Control Standard (ACS), which intercept agent decision points; Luna Expires 22 April 2027 [Page 3] Internet-Draft EAGF Delegation Semantics October 2026 * Certification and verifiability work such as [I-D.levi-agent-certification] (AACP) and Proof-of-Control, which bind evaluation results or cryptographic evidence to agent behavior; * Delegation and receipt mechanisms such as [I-D.nelson-agent-delegation-receipts] and [I-D.asor-wimse-agent-delegation-chain], which sign or attenuate what a principal authorized, and action-time envelopes such as [I-D.watts-high-assurance-agent-control-envelope], which bind an exact action to authorization, evidence and oversight state; * Audit models such as [I-D.sergeev-audit-task-requirements], which separate verification of evidence from evaluation of an audit question. Those mechanisms can carry or check the semantics below: a delegation receipt or attenuated token can carry the bounded Authority scope of REQ-1, an action-time envelope can carry the Decision reference of REQ-2, and an audit task model can consume the Evidence kinds of REQ- 5. None of them, by itself, establishes that an organizational Decision existed or that an Action produced a given Outcome. EAGF supplies organizational semantics those mechanisms can carry. It defines no wire format, no credential type and no Guardian verdict. 1.2. Non-Goals This document does not: define a new agent protocol; replace IAM, PAM, SIEM, policy engines or runtime security; replace the EU AI Act, ISO/IEC 42001 or NIST AI RMF; define a maturity score or universal trust score; or claim that EAGF is an international standard. EAGF is an open candidate specification with an explicit external- validation program. 2. Conventions and Definitions 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. 3. Terminology The following terms are used as in the EAGF specification overview. They are organizational semantics, not protocol identifiers. Luna Expires 22 April 2027 [Page 4] Internet-Draft EAGF Delegation Semantics October 2026 Agent: A digital participant that can observe, generate Claims, consume Evidence, reason, produce Assessments, operate under Authority, take or support Decisions, execute Actions and produce Outcomes. Subject: The human, agent or organizational unit whose identity, authority and accountability are governed. Authority: The bounded, purpose-scoped right to decide or act on behalf of the organization. Distinct from Trust and from infrastructure permission. Delegation (DELEGATES_TO): A relationship that passes a bounded subset of Authority, purpose and constraints to another Subject. It does not imply unlimited Authority transfer. Recommendation: An agent output that proposes a course of action. It is not an organizational Decision. Decision: An organizational commitment adopted by an authorized Subject under an adoption rule. Action: An intervention that actually occurred. Its occurrence and its legitimacy (authorization) are separate facts. An unauthorized Action is still an Action and MUST be recorded as such. Outcome: A change in reality and its consequences. Distinct from Action and from Observation. Evidence: Contextual, traceable material that supports or challenges a Claim or Judgment. Supporting Evidence does not make a Claim true. Context Qualification: The rules deciding which context is material and MUST survive a handoff when its loss would change interpretation, authorization or risk. Operational Evidence: Authentic evidence produced by a real system in operation (as opposed to design-time artefacts alone). Luna Expires 22 April 2027 [Page 5] Internet-Draft EAGF Delegation Semantics October 2026 Trust: A contextual justification of what the organization can rely on. Trust is not transitive and is not Authority. Confidence: A qualified statement about a Judgment. It is not a probability by default and is not Trust. 4. Invariants The following high-value invariants are restated from EAGF for the delegation and handoff setting. Implementations that claim alignment with this document MUST NOT collapse these distinctions. Identifiers in parentheses refer to the high-value invariant list in the EAGF specification overview [EAGF-SPEC]; the corresponding normative conformance rules are listed in Appendix A. * DELEGATES_TO MUST NOT be treated as unlimited Authority transfer (HV-21). * Trust is contextual and MUST NOT be treated as transitive across a Delegation or handoff (HV-07). * Trust MUST NOT be treated as Authority (HV-06). * An Agent output MUST NOT be treated as an organizational Decision without an adoption rule (HV-18). * Decision MUST NOT be collapsed with Recommendation (HV-08) or with Action (HV-09). * Authority MUST NOT be treated as proof that an Action occurred (HV-10). * An unauthorized Action MUST still be recorded as an Action (HV- 11). * Action MUST NOT be collapsed with Outcome (HV-12). Precedence MUST NOT be treated as causation (HV-13). * An Agent self-report MUST NOT be treated as proof of Action (HV- 20). * A Record MUST NOT be treated as Reality (HV-17). * Context transfer is not automatic (HV-24). Luna Expires 22 April 2027 [Page 6] Internet-Draft EAGF Delegation Semantics October 2026 * Learning MUST NOT rewrite historical cognition: new Evidence MUST NOT rewrite what was known at Decision time (HV-26). * ACCOUNTABLE_FOR MUST NOT be collapsed with CAUSES (HV-22); RESPONSIBLE_FOR MUST NOT be collapsed with PERFORMS (HV-23). 5. Requirements for Delegation and Handoff The following requirements apply whenever an Agent issues a tool call, delegates work to another Subject, or performs an agent-to- agent handoff. They are semantic obligations; they MAY be carried as attributes on existing protocol messages, traces or control-plane hooks. Exact field names are out of scope. 5.1. REQ-1: Bounded Authority Scope A Delegation or handoff MUST carry (or unambiguously reference) a bounded Authority scope that is a subset of the delegator's Authority and Purpose. The scope MUST include at least: purpose, limits (what is excluded), and the identity of the delegator. Unlimited or implicit Authority transfer MUST NOT occur as a side effect of a Delegation. 5.2. REQ-2: Decision Reference Where an Action is taken on behalf of the organization, the Action MUST reference the organizational Decision that authorized it, or an explicit rule that no Decision was required. An Agent Recommendation alone MUST NOT satisfy this requirement. 5.3. REQ-3: Material Context Preservation Material Context (Context whose loss would change interpretation, authorization or risk) MUST survive a Delegation or handoff under Context Qualification rules. Context transfer MUST NOT be assumed automatic. Non-material Context SHOULD be minimized for privacy (see Section 8). 5.4. REQ-4: Outcome Reference Records of Action SHOULD allow later linkage to observed Outcomes without collapsing Action and Outcome into one record. Systems MUST NOT treat successful tool invocation as proof of the business Outcome. Luna Expires 22 April 2027 [Page 7] Internet-Draft EAGF Delegation Semantics October 2026 5.5. REQ-5: Evidence Kind Evidence cited to support Claims about Delegation, Decision, Action or Outcome MUST distinguish at least: Agent self-report, platform/ runtime record, and externally verifiable evidence. Self-report MUST NOT be treated as sufficient proof of Action for high-risk settings. 5.6. REQ-6: Accountable Owner Every Agent Subject that receives Authority through Delegation MUST have an identifiable accountable owner for the organization. Accountability relationships MUST NOT be inferred solely from causality or from who performed the Action. 5.7. REQ-7: No Automatic Trust or Confidence Transfer Trust and Confidence MUST NOT be transferred automatically across a Delegation or handoff. Any reliance on another Subject's Trust or Confidence MUST be re-justified in the receiving context. 5.8. REQ-8: Historical Integrity New Evidence that appears after a Decision MUST NOT rewrite the historical record of what Evidence and Context were available at Decision time. Learning updates future cognition; it does not alter the audit trail of past Decisions. 5.9. Informative Mapping to Control Planes Implementers of ACS-style hooks MAY attach optional semantic fields corresponding to REQ-1 through REQ-4 (for example authority_scope, decision_ref, outcome_ref, evidence.kind). AACP Agent Certification Credentials and Proof-of-Control verifiable evidence MAY be treated as Evidence under REQ-5; they are not Authority under REQ-1. Exact schema is left to those projects. 6. Conformance Considerations EAGF distinguishes Design Conformance (architecture and artefacts show the required distinctions) from Operational Conformance (a real system produces authentic Operational Evidence). These are evidence scopes, not maturity levels. Conformance results are evidence-based Judgments (PASS / FAIL / NOT DEMONSTRATED / NOT APPLICABLE), not percentage scores. An Operational Conformance claim SHOULD be assessed by an assessor independent of the implementer. An implementer MUST NOT assess its own customers and present the result as independent. Luna Expires 22 April 2027 [Page 8] Internet-Draft EAGF Delegation Semantics October 2026 The normative rule catalogue (68 rules across 16 domains and 7 profiles) and the assessment instrument (68 items) are maintained in the EAGF conformance work products (WO-013, WO-014). This Internet- Draft states only the delegation and handoff requirements above; it does not reproduce the full catalogue. Appendix A maps each requirement in this document to the conformance rules that test it. 7. Security Considerations Authority escalation through Delegation chains: if REQ-1 is not enforced, a chain of Delegations can accumulate into broader Authority than any single delegator intended. Implementations SHOULD bound chain depth and re-validate scope at each hop. Context stripping: if REQ-3 is not enforced, a handoff can drop purpose, limits or risk signals and produce Actions that look authorized under the remaining credentials. Material Context MUST be treated as security-relevant. Forged or unverified self-reports: if REQ-5 is not enforced, an Agent can assert that an Action occurred or was authorized. Self-report MUST be distinguishable from platform and external Evidence. Replay of Decision references: Decision references used for REQ-2 MUST be bound to scope and time so that a past Decision cannot authorize a later, different Action. Collapsing Recommendation into Decision (HV-18) creates unauthorized organizational commitments. Adoption rules are a security control, not only a governance nicety. 8. Privacy Considerations Material Context under REQ-3 SHOULD be minimized to what is necessary for interpretation, authorization and risk. Evidence cited under REQ-5 may contain personal or confidential data; Evidence handling MUST respect applicable confidentiality and retention rules. Publishing Operational Evidence packages for assessment SHOULD use redaction or scoped disclosure rather than wholesale log dumps. 9. IANA Considerations This document has no IANA actions. 10. References Luna Expires 22 April 2027 [Page 9] Internet-Draft EAGF Delegation Semantics October 2026 10.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, . 10.2. Informative References [EAGF-SPEC] Alygn (Intention Alliance Inc.), "Enterprise Agent Governance Framework (EAGF), Specification Overview v0.9", October 2026, . [I-D.asor-wimse-agent-delegation-chain] "Verifiable Attenuated Delegation for AI Agent Chains", Work in Progress, Internet-Draft, draft-asor-wimse-agent- delegation-chain-02, October 2026, . [I-D.ietf-wimse-aims] Kasselman, P., "AI Identity Management System", Work in Progress, Internet-Draft, draft-ietf-wimse-aims-00, September 2026, . [I-D.levi-agent-certification] Levi, N. and O. Yeger, "Autonomous Agent Certification Protocol (AACP)", Work in Progress, Internet-Draft, draft- levi-agent-certification-00, October 2026, . [I-D.nelson-agent-delegation-receipts] "Agent Delegation Receipts", Work in Progress, Internet- Draft, draft-nelson-agent-delegation-receipts-14, October 2026, . Luna Expires 22 April 2027 [Page 10] Internet-Draft EAGF Delegation Semantics October 2026 [I-D.sergeev-audit-task-requirements] "Task-Relative Evidence Requirements for Agent Auditing", Work in Progress, Internet-Draft, draft-sergeev-audit- task-requirements-00, October 2026, . [I-D.watts-high-assurance-agent-control-envelope] "High-Assurance Agent Control Envelope", Work in Progress, Internet-Draft, draft-watts-high-assurance-agent-control- envelope-00, October 2026, . Appendix A. Mapping to EAGF Conformance Rules (Informative) This appendix maps the requirements of this document to rule identifiers in the EAGF conformance model (WO-013: 68 rules in 16 domains). The rule text is maintained with the EAGF specification [EAGF-SPEC]; it is not reproduced here. Luna Expires 22 April 2027 [Page 11] Internet-Draft EAGF Delegation Semantics October 2026 +==========================+=====================================+ | Requirement | EAGF conformance rules | +==========================+=====================================+ | REQ-1 Bounded Authority | ECA-CONF-MUL-001, ECA-CONF-AGT-002, | | Scope | ECA-CONF-TRU-001, ECA-CONF-CTX-004 | +--------------------------+-------------------------------------+ | REQ-2 Decision Reference | ECA-CONF-DEC-002, ECA-CONF-DEC-003, | | | ECA-CONF-AGT-001, ECA-CONF-RSN-004 | +--------------------------+-------------------------------------+ | REQ-3 Material Context | ECA-CONF-CTX-001, ECA-CONF-CTX-002, | | Preservation | ECA-CONF-MUL-002 | +--------------------------+-------------------------------------+ | REQ-4 Outcome Reference | ECA-CONF-DEC-001, ECA-CONF-DEC-005, | | | ECA-CONF-AGT-003, ECA-CONF-REA-001 | +--------------------------+-------------------------------------+ | REQ-5 Evidence Kind | ECA-CONF-EVD-004, ECA-CONF-AGT-003, | | | ECA-CONF-EVD-002 | +--------------------------+-------------------------------------+ | REQ-6 Accountable Owner | ECA-CONF-MUL-005, ECA-CONF-AGT-004 | +--------------------------+-------------------------------------+ | REQ-7 No Automatic Trust | ECA-CONF-MUL-003, ECA-CONF-MUL-004, | | or Confidence Transfer | ECA-CONF-TRU-002, ECA-CONF-ASM-006 | +--------------------------+-------------------------------------+ | REQ-8 Historical | ECA-CONF-HIS-002, ECA-CONF-LRN-001, | | Integrity | ECA-CONF-TRU-004, ECA-CONF-ASM-004 | +--------------------------+-------------------------------------+ | Unauthorized Action | ECA-CONF-DEC-004 | | recorded (HV-11) | | +--------------------------+-------------------------------------+ Table 1 Appendix B. Acknowledgments This document draws on the EAGF architecture developed under Alygn (Intention Alliance Inc.). Operational contact for the project: tania@alygn.us. Author's Address David Luna Alygn (Intention Alliance Inc.) Austin, TX United States of America Email: tania@alygn.us URI: https://alygn.us Luna Expires 22 April 2027 [Page 12]