Alygn (Intention Alliance Inc.)

AustinTXUnited States of America tania@alygn.us https://alygn.us

Security AI agentsdelegationauthorityevidence 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 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.

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) 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.

Relationship to Related Work This document is complementary to, and does not replace:

• Identity and workload credential work such as , 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;
• Certification and verifiability work such as (AACP) and Proof-of-Control, which bind evaluation results or cryptographic evidence to agent behavior;
• Delegation and receipt mechanisms such as and , which sign or attenuate what a principal authorized, and action-time envelopes such as , which bind an exact action to authorization, evidence and oversight state;
• Audit models such as , 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.

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.

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 when, and only when, they appear in all capitals, as shown here.

Terminology The following terms are used as in the EAGF specification overview. They are organizational semantics, not protocol identifiers.

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).

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.

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 ; the corresponding normative conformance rules are listed in .

• 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).
• 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).

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.

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.

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.

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 ).

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.

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.

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.

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.

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.

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.

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. 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. maps each requirement in this document to the conformance rules that test it.

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.

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.

IANA Considerations This document has no IANA actions.

References Normative References Informative References Alygn (Intention Alliance Inc.)

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 ; 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

Acknowledgments This document draws on the EAGF architecture developed under Alygn (Intention Alliance Inc.). Operational contact for the project: tania@alygn.us.