| Internet-Draft | EAGF Delegation Semantics | October 2026 |
| Luna | Expires 22 April 2027 | [Page] |
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.¶
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.¶
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.¶
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.¶
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.¶
This document is complementary to, and does not replace:¶
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.¶
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.¶
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.¶
The following terms are used as in the EAGF specification overview. They are organizational semantics, not protocol identifiers.¶
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.¶
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.¶
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.¶
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).¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
This document has no IANA actions.¶
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.¶
| Requirement | EAGF conformance rules |
|---|---|
| REQ-1 Bounded Authority Scope | ECA-CONF-MUL-001, ECA-CONF-AGT-002, 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 Preservation | ECA-CONF-CTX-001, ECA-CONF-CTX-002, 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 or Confidence Transfer | ECA-CONF-MUL-003, ECA-CONF-MUL-004, ECA-CONF-TRU-002, ECA-CONF-ASM-006 |
| REQ-8 Historical Integrity | ECA-CONF-HIS-002, ECA-CONF-LRN-001, ECA-CONF-TRU-004, ECA-CONF-ASM-004 |
| Unauthorized Action recorded (HV-11) | ECA-CONF-DEC-004 |
This document draws on the EAGF architecture developed under Alygn (Intention Alliance Inc.). Operational contact for the project: tania@alygn.us.¶