Network Working Group T. Sato Internet-Draft MyAuberge K.K. Intended status: Standards Track 24 May 2026 Expires: 24 November 2026 The Intent Declaration Primitive (IDP) for Agentic AI Systems draft-sato-soos-idp-03 Abstract AI agents operating in automated workflows take actions without any normative mechanism for expressing why those actions are being taken. Access tokens declare what an agent is permitted to do; no existing standard declares what the agent believes it is doing, on what reasoning basis, and with what level of confidence, at the moment of action. This document defines the Intent Declaration Primitive (IDP): a structured per-transition declaration submitted by an AI agent to the Governing Enforcement Component (GEC) at each action step of an execution loop. The IDP is committed to a tamper-evident Event Log before the action executes, enabling post-hoc review of agent reasoning, richer authorization policy evaluation, and enriched denial responses that guide agent behaviour. The IDP also provides the technical basis for compliance with EU AI Act Article 12 logging requirements for high-risk AI systems. This document adds the IDP Commitment Verification mechanism, by which the GEC verifies at each state transition that the agent's actual action matches its declared intent. This document also adds the RETRY_CONTINUATION reasoning basis type and the prior_denial_count Cedar context attribute, which together address computational inefficiency arising from uninformed agent retry loops. This document further defines, in Section 5.6, the schemas of the outcome Event Log entries (STATE_TRANSITIONED, CEDAR_DENY_RECORDED, and ACTION_RESULT_RECORDED) that record the result of each governed transition, completing the pre-action/post- action audit pair that gives the IDP its full auditability property. This document renames the Governing Kernel role to Governing Enforcement Component (GEC) to accommodate application-layer, isolated-process, and kernel-level implementations under a common conformance model. A Conformance Levels section (Section 9) defines three implementation profiles (Application, Isolated, and Kernel) with graduated non-suppressibility guarantees. A data_residency field is added to the IDP structure (Section 4.1) governing analytics tier eligibility. Section 3.5 states the Event Log as Operational Intelligence design intent. 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 23 November 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. Table of Contents 1. Introduction 2. Conventions and Definitions 3. Problem Statement 3.1. The Intent Gap in Agentic Authorization 3.2. Relationship to EU AI Act Article 12 3.3. Relationship to Williams Intent Bound Authorization 3.4. Relationship to Mission Bound Authorization 3.5. Event Log as Operational Intelligence 4. The Intent Declaration Primitive 4.1. IDP Structure 4.2. Field Definitions 4.3. Reasoning Basis Types 4.4. HEM Urgency Values 4.5. IDP Profiles 5. Submission Protocol 5.1. When the IDP Is Submitted 5.2. GEC Receipt and Validation 5.3. Event Log Commitment 5.4. IDP in Cedar Policy Evaluation 1. Introduction The Internet Engineering Task Force and related standards bodies have made significant progress in specifying how AI agents authenticate (WIMSE [I-D.ietf-wimse-arch]) and how they obtain authorization tokens for API invocation (OAuth 2.1 [I-D.ietf-oauth-v2-1], AAuth [I-D.rosenberg-oauth-aauth]). These specifications answer the question: is this agent permitted to perform this action? No existing specification answers the companion question: why does this agent believe it should perform this action at this moment? This distinction matters for four reasons. First, post-hoc review of AI agent behaviour requires not only a record of what actions were taken but a record of the reasoning that led to them. Access token issuance records do not provide this. Second, authorization policy evaluation can be made significantly more precise when the agent's declared intent is available as a policy context attribute; a Cedar [Cedar] policy that evaluates both the action requested and the reasoning basis for that action is a more powerful governance tool than one that evaluates the action alone. Third, EU AI Act Article 12 requires that high-risk AI systems maintain logs sufficient for post-hoc human review of system decisions [EUAIA]; per-transition intent declaration is the technical specification that satisfies this requirement. Fourth, uninformed retry loops represent a significant and measurable source of computational waste in deployed agentic systems. When an agent's action is denied and the agent receives no structured information about what alternative actions are available or what reasoning adjustments are warranted, the agent re-enters its reasoning loop without a revised basis for action. This produces semantically redundant computation: token expenditure and inference cost that generate no new information and advance no declared goal. The IDP addresses this through two mechanisms: the Enriched DENY Response (Section 6), which provides available_actions and suggested_paths to guide the agent's next reasoning step; and the context_refs field (Section 4.1), which enables agents to explicitly reference prior failed attempts in subsequent declarations, making failure history a first-class input to both Cedar policy evaluation and human principal review. At the scale of large agentic deployments -- where LLM instances operate concurrently across millions of users -- elimination of uninformed retry loops through structured intent declaration represents substantial aggregate reduction in computational cost. This document defines the Intent Declaration Primitive (IDP): a structured JSON object submitted by an AI agent to a governing runtime component at each action step of an agent execution loop, prior to the execution of the action. The IDP is recorded in a tamper- evident append-only Event Log before the action is executed. When authorization is denied, the GEC returns an Enriched DENY Response that includes the denial reason, available alternative actions, and the echo of the received IDP -- enabling the agent to reason about what it may do next. The IDP is a GEC primitive, not an application-layer logging construct. It is submitted as part of the action invocation call, not after it. This is the property that gives the IDP its audit integrity: the reasoning declaration precedes the action record, making ex-post fabrication of intent structurally impossible within a conforming implementation. This document also specifies IDP Commitment Verification (Section 5.5): a GEC mechanism that verifies, after every governed state transition, that the agent's actual action matches its declared IDP commitment. When a mismatch is detected -- the agent declared one intent and took a different action -- the GEC generates an IDP_COMMITMENT_GAP audit finding and automatically triggers Human Escalation Mechanism Class 2 (HEM_AGENT_ESCALATED). o Section 5.6: Outcome Event Log Entries added (new section). Defines schemas for STATE_TRANSITIONED, CEDAR_DENY_RECORDED, and ACTION_RESULT_RECORDED Event Log entries. These entries record the result of each governed transition and complete the pre- action/post-action audit pair. A worked example (Section 5.6.4) shows the complete eight-entry Event Log for a denied-then- approved payment transition. Changes from draft-sato-soos-idp-02: o Throughout: "Governing Enforcement Component (GEC)" renamed to "Governing Enforcement Component (GEC)". The term "kernel" is retained only in the JSON field name kernel_signature (preserved for wire-format compatibility) and in section names that already existed in -02. All normative MUST/SHOULD/MAY requirements previously scoped to "the GEC" are now scoped to "the GEC", making them conformant for application-layer, isolated-process, and hardware-kernel implementations. o Section 2: Governing Enforcement Component (GEC) definition replaced by Governing Enforcement Component (GEC) with three-level description. New terms added: GEC-signed, Transition Request, GEC Query Interface. o Section 3.5: Event Log as Operational Intelligence added. States the analytics design intent and three-tier usage model (session-local, organization-internal, cross-domain). References forthcoming FAIP specification for Tier 3. o Section 4.1: data_residency field added to IDP structure. Controls analytics tier eligibility per IDP record. o Section 4.2: data_residency field definitions added. o Section 9: Conformance Levels added (new section). Defines Level 1 (Application Profile), Level 2 (Isolated Profile), and Level 3 (Kernel Profile) with graduated non-suppressibility guarantees, signing key requirements, and regulatory applicability. Existing Sections 9-12 renumbered to 10-13. o Section 5.1: GEC.transition() replaced by Transition Request abstraction. o Section 5.2 heading: "Kernel Receipt and Validation" renamed to "GEC Receipt and Validation". o Abstract line 19: "governing OS kernel" replaced with "Governing Enforcement Component (GEC)". Changes from draft-sato-soos-idp-01: o Section 1: Fourth motivation added -- computational efficiency through elimination of uninformed retry loops. o Section 3.1: Problem (e) added -- computational inefficiency arising from uninformed retry loops and its aggregate cost at deployment scale. o Section 4.2: context_refs field definition augmented to specify that prior denial references SHOULD be included on retry, and to define the prior_denial_count Cedar context attribute. o Section 4.3: RETRY_CONTINUATION reasoning basis type added. Defines mandatory context_refs linkage to prior IDP_SUBMITTED events, required description of changed reasoning basis, and WARNING logging behaviour for retries without declared prior context. o Section 5.4: prior_denial_count Cedar context attribute added to the set of IDP fields made available during policy evaluation. o Section 11: RETRY_CONTINUATION added to IDP Reasoning Basis Types registry initial values. Changes from draft-sato-soos-idp-00: o Section 4.1: audit_accessible field added to IDP Core Record. o Section 5.5: IDP Commitment Verification added (new section). Defines IDP Commitment Verification Record schema, IDP_COMMITMENT_VERIFIED and IDP_COMMITMENT_GAP Event Log entries, and IDP_COMMITMENT_GAP response protocol. o Section 11: IANA registry names corrected (removed implementation-specific prefix). 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. This document uses the following terms: Agent: A software system that uses AI, including large language models, to reason about and take actions in pursuit of goals. An agent may be human-supervised, semi-autonomous, or fully autonomous. Governing Enforcement Component (GEC): A runtime component that enforces authorization policy, records agent actions to a tamper-evident Event Log, and mediates agent access to governed objects. [I-D.sato-soos-hem] specifies the Human Escalation Mechanism that the GEC implements for human oversight of agent sessions. The GEC may be implemented as an application-layer library (Level 1), an isolated process or sidecar (Level 2), or an attested hardware execution environment (Level 3). See Section 9 for conformance level definitions. GEC-signed: A record signed by the Governing Enforcement Component using the signing key appropriate to its conformance level. At Level 1, an application-managed key. At Level 2, a key held by the isolated GEC process, inaccessible to agent code. At Level 3, a key bound to a RATS-attested execution environment. The JSON field name kernel_signature is preserved across all levels for wire-format compatibility; the label field within the signature MUST indicate the conformance level (L1, L2, or L3). Transition Request: The abstract operation by which an agent submits a cedar_action, mandate_jwt, and IDP to the GEC requesting a governed state transition. Protocol binding is implementation-defined; REST, gRPC, in-process function call, and message queue are all conforming transport mechanisms. GEC Query Interface: The abstract interface by which authorized principals query Event Log entries. Protocol binding is implementation-defined. Governed Object: A typed, stateful entity that the GEC governs. An agent operates on governed objects; the GEC enforces what transitions are permitted. Mandate JWT: A JSON Web Token [RFC7519] that binds an agent's authorization to a specific governed object instance. The mandate JWT is the authorization credential presented alongside an IDP. Event Log: An append-only, causally ordered, tamper-evident log of all transitions executed against governed objects. The Event Log is the ground truth of system behaviour. Cedar: A policy language and evaluation engine [Cedar] used by the GEC to evaluate authorization decisions. Cedar evaluates before any state transition executes. HEM: Human Escalation Mechanism. A GEC-enforced session state in which no transitions may execute until a designated human principal provides a decision. See [I-D.sato-soos-hem]. IDP: Intent Declaration Primitive. The structured per-transition reasoning declaration defined in this document. IDP_THIN: A reduced IDP profile for agents with limited reasoning capability. See Section 7. IDP Commitment Verification Record: A GEC-generated record produced after every governed state transition, recording whether the agent's actual action matched its IDP commitment. See Section 5.5. IDP_COMMITMENT_GAP: A condition in which the GEC determines that the agent's actual state transition does not match the agent's declared IDP commitment. A critical audit finding. See Section 5.5. Prior Denial: A GEC DENY response to a previous Transition Request within the same session. An IDP_SUBMITTED event with reasoning_basis.type RETRY_CONTINUATION MUST reference at least one prior denial via context_refs. 3. Problem Statement 3.1. The Intent Gap in Agentic Authorization Current agentic authorization frameworks model agent behaviour as a set of permitted actions, expressed as OAuth scopes, Cedar action sets, or similar constructs. This model captures what an agent may do. It does not capture, at the moment of action: * what goal the agent believes the action serves, * what reasoning led the agent to select this action over alternatives, * how confident the agent is that this action is appropriate, or * whether the agent believes human judgment should be sought before proceeding. The absence of per-transition intent records creates five concrete problems: (a) Audit incompleteness. Post-hoc review of AI agent behaviour requires reconstruction of agent reasoning from action records alone. This is insufficient for high-stakes environments where understanding why an action was taken is as important as knowing what action was taken. (b) Policy imprecision. Authorization policy evaluated solely against action type and agent identity cannot distinguish between an agent acting on a direct human instruction and an agent acting on an autonomous inference. These may warrant different authorization treatment. (c) Opaque denials. When an agent's action is denied, the agent receives no structured information about what alternative actions are available or what reasoning adjustments might lead to a permitted action. This forces agents into uninformed retry loops. (d) Regulatory non-compliance. EU AI Act Article 12 requires logs sufficient for human review of AI system decisions for high-risk systems. Access token issuance records do not satisfy this requirement. (e) Computational inefficiency. An agent that receives a denial and no structured guidance re-enters its reasoning loop without a revised basis for action, producing redundant computation: token expenditure and inference cost that generate no new information and advance no declared goal. An agent that retries a previously failed action without explicitly articulating what has changed in its reasoning basis is structurally likely to fail again for the same reason. This inefficiency compounds across the delegation chain: a sub-agent that silently retries propagates wasted computation upward to orchestrator agents that must await a result. Across large-scale agentic deployments operating concurrently for millions of users, uninformed retry loops represent a measurable aggregate waste of computational resources. The IDP Enriched DENY Response (Section 6) and the RETRY_CONTINUATION reasoning basis type with context_refs linkage (Section 4.3) address this directly. 3.2. Relationship to EU AI Act Article 12 EU AI Act Article 12 requires that high-risk AI systems maintain automatic logging sufficient to enable post-deployment monitoring, human review of decisions, and identification of risks. The logs must cover, at minimum, the operation of the system with reference to the relevant time period, the objects processed, and the data used. The IDP, committed to the Event Log before each action, provides the per-decision record that Article 12 contemplates. An Event Log containing IDP entries for every agent transition produces a complete record of: what action was taken (the transition), by whom (the mandate JWT), against what (the governed object), and why (the IDP declared_goal and reasoning_basis). This document is informative with respect to regulatory compliance and does not constitute legal advice. 3.3. Relationship to Williams Intent Bound Authorization Williams Intent Bound Authorization (IBA) [Williams-IBA] defines a human-signed authorization envelope issued before an agent session begins. The IBA envelope travels from human to agent; it constrains what the agent may do in the session. The IDP is directionally distinct: it travels from agent to governing GEC, at each individual action step within the session. IBA expresses what the authorizing human intends the agent to do. IDP expresses what the agent declares it is doing and why. The two primitives compose without conflict. An IBA-constrained agent session produces IDP entries at each transition; the IDP records the agent's reasoning within the IBA-defined scope. Neither primitive replaces the other. 3.4. Relationship to Mission Bound Authorization McGuinness Mission Bound Authorization [I-D.mcguinness-oauth-mission- bound-authorization] addresses how authorization tokens can be scoped to a declared mission, ensuring that token authority is contingent on mission validity. The IDP is directionally complementary: mission-bound authorization constrains what the agent is permitted to do within a mission; the IDP records what the agent declares it is doing and why at each individual transition within that mission. The two primitives compose without conflict. A system implementing mission-bound authorization produces IDP entries at each transition; the IDP's mission_ref field (Section 4.1) links per-transition declarations to the governing MissionDeclaration evaluated by the mission-bound authorization framework. Neither primitive replaces the other. 3.5. Event Log as Operational Intelligence The IDP Event Log is designed as a governance record: tamper-evident, GEC-signed, and non-suppressible. A consequence of the pre-action commitment plus post-action outcome pair (IDP_SUBMITTED and ACTION_RESULT_RECORDED) is that the Event Log is simultaneously the most structured dataset that will exist about how agentic AI systems behave in production. This section states the operational intelligence design intent that this structure enables. Protocol specifications for Tier 2 and Tier 3 analytics are defined in [I-D.sato-soos-gar] and the forthcoming Federated Agent Intelligence Protocol (FAIP) specification respectively. Three tiers of Event Log usage are defined: Tier 1 -- Session-Local. Within a single session, the GEC consults its own Event Log to derive the prior_denial_count attribute (Section 5.4), to detect GOAL_INCOMPLETE conditions (Section 5.6), and to detect CONFIDENCE_MISCALIBRATION patterns. No data leaves the session trust boundary. All Tier 1 analytics are specified in this document and require no additional protocol. Tier 2 -- Organization-Internal. Across sessions within the same organizational trust domain, anonymized and aggregated Event Log patterns enable action success rate analysis, retry pattern libraries (which RETRY_CONTINUATION reasoning adjustments historically lead to PERMITTED outcomes after specific deny_codes), and goal completion profiling. Tier 2 analytics are subject to k-anonymity enforcement (minimum session count per query result) and data_residency constraints (Section 4.2). The Analytics Principal role and GEC query interface for Tier 2 are specified in [I-D.sato-soos-gar]. Tier 3 -- Cross-Domain Federated. Across organizational boundaries, privacy-preserving aggregation enables cross-industry pattern transfer: planning priors derived from billions of governed agent sessions spanning multiple SO Types and industries. Tier 3 analytics require that participating organizations file a signed Participation Declaration specifying contribution scope, privacy model (federated learning or differential privacy), and data residency constraints. The Tier 3 protocol, trust registry model, and Participation Declaration schema are specified in the Federated Agent Intelligence Protocol (FAIP), a forthcoming companion specification. Tier 3 eligibility for individual IDP records is controlled by the tier3_eligible field in data_residency (Section 4.2). The computational efficiency motivation for the IDP (Section 1, fourth motivation; Section 3.1(e)) extends across tiers. Tier 1 analytics eliminate uninformed retry loops within a session. Tier 2 analytics eliminate category-level retry failure patterns across an organization's sessions: an agent encountering a POLICY_DENY on Action::"ProcessPayment" can consult the organization's Tier 2 RETRY_PATTERN_LIBRARY to learn which reasoning adjustments historically succeeded. Tier 3 analytics extend this across industries, enabling cross-domain transfer of validated planning trajectories. The data_residency field (Section 4.2) is the per-record control mechanism by which operators govern which tiers a given IDP record contributes to. Organizations operating under GDPR or other data residency requirements MUST set jurisdiction and tier eligibility fields appropriately for all sessions within the regulated scope. 3.5. Event Log as Operational Intelligence The IDP Event Log is specified as a governance record: GEC-signed, append-only, and tamper-evident. A consequence of the pre-action commitment plus post-action outcome pair defined in this document is that the Event Log is simultaneously the most richly structured behavioral dataset that will exist for deployed agentic AI systems. This section states the operational intelligence design intent that this structure enables. Analytics protocol specifications are defined in [I-D.sato-soos-gar] (Tier 2) and the forthcoming Federated Agent Intelligence Protocol (FAIP) specification (Tier 3). Three tiers of Event Log usage are defined: Tier 1 -- Session-Local. The GEC consults its own Event Log within a single session to derive prior_denial_count (Section 5.4), detect GOAL_INCOMPLETE conditions, and detect CONFIDENCE_MISCALIBRATION patterns. No data leaves the session trust boundary. All Tier 1 analytics are specified in this document. Tier 2 -- Organization-Internal. Anonymized and aggregated Event Log patterns across sessions within the same organizational trust domain enable: action success rate analysis by reasoning_basis type; RETRY_PATTERN libraries (which RETRY_CONTINUATION reasoning adjustments historically led to PERMITTED outcomes after specific deny_codes); and goal completion profiling. Tier 2 analytics are subject to k-anonymity enforcement and data_residency constraints (Section 4.2). The Analytics Principal role and GEC query interface for Tier 2 are specified in [I-D.sato-soos-gar]. Tier 3 -- Cross-Domain Federated. Privacy-preserving aggregation across organizational boundaries enables cross-industry pattern transfer and planning priors derived from large populations of governed agent sessions. Tier 3 requires that organizations file a Participation Declaration specifying contribution scope and privacy model. The Tier 3 protocol, trust registry, and Participation Declaration schema are specified in the forthcoming FAIP specification. Tier 3 eligibility per IDP record is controlled by the tier3_eligible field in data_residency (Section 4.2). The computational efficiency motivation (Section 1, fourth; Section 3.1(e)) extends across tiers: Tier 1 eliminates uninformed retry loops within a session; Tier 2 eliminates category-level retry failure patterns across an organization's sessions; Tier 3 enables cross-domain transfer of validated planning trajectories. 4. The Intent Declaration Primitive 4.1. IDP Structure The IDP is a JSON object with the following structure: { "idp_id": string, ; REQUIRED. UUID v4. "session_id": string, ; REQUIRED. Agent session identifier. "so_id": string, ; REQUIRED. Governed object UUID. "mandate_id": string, ; REQUIRED. Mandate JWT jti claim. "mission_ref": string, ; OPTIONAL. MissionDeclaration UUID. ; Links this per-transition declaration ; to the governing MissionDeclaration. ; MUST match the mission_ref in the ; mandate JWT if that field is present. "step_sequence": integer, ; REQUIRED. ACT step number, 1-based. "requested_action": string, ; REQUIRED. Cedar action string. "declared_goal": { ; REQUIRED. "goal_id": string, ; REQUIRED. UUID v4. "description": string ; REQUIRED. Human-readable. Max 500 chars. }, "reasoning_basis": { ; REQUIRED. "type": string, ; REQUIRED. See Section 4.3. "description": string ; REQUIRED. Human-readable. Max 1000 chars. }, "confidence_level": number, ; REQUIRED. Float, 0.0 to 1.0 inclusive. "hem_urgency": string, ; REQUIRED. See Section 4.4. "context_refs": [string], ; OPTIONAL. UUIDs of relevant prior events. ; See Section 4.2 for retry requirements. "audit_accessible": boolean, ; OPTIONAL. Default: true. When false, ; IDP is not accessible to Audit ; Principals via GEC query interfaces. "metadata": object, ; OPTIONAL. Implementation-defined. "timestamp": string, ; REQUIRED. ISO 8601 UTC. "data_residency": { ; OPTIONAL. Analytics eligibility. "jurisdiction": string, ; REQUIRED if field present. ; ISO 3166-1 alpha-2, "EU", "EEA", ; or "GLOBAL". "tier2_eligible": boolean, ; REQUIRED if field present. ; May contribute to organization- ; internal analytics aggregation. "tier3_eligible": boolean, ; REQUIRED if field present. ; May contribute to cross-domain ; federated analytics aggregation. "retention_days": integer, ; OPTIONAL. Retention override. "anonymization_delay_days": integer ; OPTIONAL. Days after ; session close before eligible ; for analytics. Default: 0. } } 4.2. Field Definitions idp_id: A UUID v4 [RFC4122] assigned by the agent. Uniquely identifies this IDP within the Event Log. MUST be unique across all IDPs for the lifetime of a governed object instance. session_id: The identifier of the agent session within which this action is taken. MUST match the session_id established at session creation. so_id: The UUID v4 of the governed object being operated on. MUST match the UUID bound to the mandate_id. mandate_id: The jti claim of the mandate JWT presented with this IDP. Links the intent declaration to the authorization credential under which the action is requested. mission_ref: OPTIONAL. The UUID of the MissionDeclaration governing the session in which this IDP is submitted. When present, this field links the per-transition intent declaration to the overarching mission under which the agent is operating. If the mandate JWT carries a mission_ref claim, the IDP mission_ref MUST match that claim. Absent if the session does not operate under a declared MissionDeclaration. step_sequence: A positive integer indicating the ordinal position of this ACT step within the current session. Starts at 1. MUST be monotonically increasing within a session. The GEC SHOULD reject an IDP with a step_sequence equal to or less than the last committed step_sequence for this session. requested_action: The Cedar action string identifying the action the agent requests. MUST be the same Cedar action string submitted to the GEC for policy evaluation. declared_goal: A structured declaration of the goal the agent believes this action serves. goal_id: A UUID v4 assigned by the agent. MAY be shared across multiple IDPs within a session if those IDPs are understood to serve the same goal. description: A human-readable description of the goal. MUST NOT contain personally identifiable information. Maximum 500 characters. reasoning_basis: A structured declaration of the reasoning that led the agent to request this action. type: One of the reasoning basis types defined in Section 4.3. description: A human-readable description of the specific reasoning. MUST NOT contain personally identifiable information. Maximum 1000 characters. When reasoning_basis.type is RETRY_CONTINUATION, this field MUST identify: (a) what action was previously denied or failed, (b) what has changed in the agent's understanding or approach since the prior attempt, and (c) why the agent believes the revised approach will succeed. confidence_level: A floating-point number in [0.0, 1.0] expressing the agent's self-assessed confidence that this action is appropriate. 1.0 indicates full confidence; 0.0 indicates no confidence. This value is self-reported by the agent and is not independently verified by the GEC. Implementers SHOULD treat this value as a declaration, not a guarantee. hem_urgency: A declaration of the agent's assessment of whether human judgment should be sought. See Section 4.4. context_refs: An OPTIONAL array of Event Log entry UUIDs that the agent considers relevant to its reasoning. Allows tracing of how prior events informed the current action. When the agent is retrying an action following a prior denial within the current session, context_refs SHOULD include the idp_ids of IDP_SUBMITTED events from prior attempts at the same requested_action. This enables the GEC to compute the prior_denial_count Cedar context attribute (Section 5.4) and enables audit tools to reconstruct the full failure-and-retry reasoning chain for post-hoc review. The GEC SHOULD make the count of prior denials for the same requested_action available as a Cedar context attribute (idp.prior_denial_count), enabling Cedar policies that apply progressive restriction or mandatory HEM escalation to repeatedly denied actions. The prior_denial_count value is derived by the GEC from the Event Log; it is not supplied by the agent and MUST NOT be accepted as an agent-supplied field. The presence of prior denial references in context_refs, combined with a RETRY_CONTINUATION reasoning basis type (Section 4.3), enables Cedar policies to distinguish between a first-attempt action and a revised retry, and to apply different authorization treatment accordingly. audit_accessible: OPTIONAL. Boolean. Default: true. When true, this IDP record is accessible to Audit Principals via GEC query interfaces (GEC query interface (GEC.query_event_log())) and is included in Session Audit Records and Audit Packages. When false, the IDP is accessible only to the GEC's internal audit functions and to Verified External Auditors; it is not returned in response to Audit Principal queries. Operators who require restricted IDP access for confidentiality reasons MAY set this field to false; such restrictions MUST be documented in the Session Audit Record. metadata: An OPTIONAL implementation-defined JSON object. The GEC MUST record this field in the Event Log without interpretation. Domain-specific IDP extensions SHOULD use this field. timestamp: The time at which the agent generated the IDP, in ISO 8601 format with UTC timezone. The GEC MUST record both this timestamp and the GEC receipt timestamp in the Event Log entry. data_residency: OPTIONAL. A structured declaration governing the eligibility of this IDP record for analytics aggregation beyond the session-local tier. When absent, the SO Type's default data residency policy applies. jurisdiction: REQUIRED when data_residency is present. The geographic or regulatory jurisdiction of the data subject or governed object. Expressed as an ISO 3166-1 alpha-2 country code (e.g., "JP", "DE", "US"), or one of the multi-country values "EU" (European Union), "EEA" (European Economic Area), or "GLOBAL" (no geographic restriction). The GEC MUST NOT route analytics contributions from this IDP record to aggregation services outside the declared jurisdiction without explicit operator policy authorization. tier2_eligible: REQUIRED when data_residency is present. Boolean. When true, this IDP record MAY contribute to organization-internal analytics aggregation (Tier 2, as defined in the forthcoming FAIP specification). When false, this record MUST NOT appear in any Tier 2 aggregate query result, even if other records from the same session are tier2_eligible. Default when data_residency is absent: operator-configurable, RECOMMENDED default true. tier3_eligible: REQUIRED when data_residency is present. Boolean. When true, this IDP record MAY contribute to cross-domain federated analytics aggregation (Tier 3) subject to the Participation Declaration filed by the operator under the FAIP specification. When false, this record MUST NOT contribute to any Tier 3 aggregate. Default when data_residency is absent: operator- configurable, RECOMMENDED default false (opt-in for Tier 3). retention_days: OPTIONAL. Integer. Overrides the default Event Log retention policy for this record. MUST NOT exceed the maximum retention period specified by the governing SO Type. MUST NOT exceed any applicable regulatory maximum retention period. anonymization_delay_days: OPTIONAL. Integer. The number of days after session close before this record becomes eligible for analytics aggregation. Allows a cooling-off period during which the record is accessible for operational review but not yet contributed to analytics aggregates. Default: 0 (eligible immediately after session close). 4.3. Reasoning Basis Types The reasoning_basis.type field MUST be one of the following values: RULE_BASED: The agent is executing a predetermined rule or procedure. The action was selected by applying a defined decision rule to the current state, not by open-ended inference. Example: "Booking confirmation is required when payment is received; payment has been received." INFERENCE: The agent inferred that this action is appropriate based on contextual reasoning. The action was not explicitly prescribed by a rule; the agent applied judgment to conclude it is correct. Example: "Based on the stated guest preferences and current availability, this room assignment appears optimal." INSTRUCTION: The agent is executing an explicit instruction from a human principal or from a higher-authority agent in the delegation chain. Where the mandate JWT carries a delegation_chain claim [I-D.mcguinness-oauth-actor-profile], the source of the instruction is traceable through the full actor chain. The reasoning_basis.description MUST identify the source of the instruction by mandate_id or session_id. UNCERTAINTY_REDUCTION: The agent is taking this action to reduce uncertainty, not to directly advance the declared goal. Used when an agent performs a read or query action to gather information before determining the appropriate forward action. MISSION_STAGE: The agent is executing an action whose primary purpose is to advance the governing MissionDeclaration from one stage to the next. This type is used when the mission stage transition, not the domain goal itself, is the proximate reason for the action. The mission_ref field MUST be present when this type is used. RETRY_CONTINUATION: The agent is retrying an action following a prior denial or failure within the current session. The idp_id of the prior attempt's IDP_SUBMITTED Event Log entry MUST be included in context_refs. The reasoning_basis.description MUST identify: (a) what action was previously denied or failed, (b) what has changed in the agent's understanding or approach since the prior attempt, and (c) why the agent believes the revised approach will succeed. A RETRY_CONTINUATION IDP with no context_refs referencing a prior IDP_SUBMITTED event MUST be logged as a WARNING in the Event Log without rejection; the GEC SHOULD make the retry_without_prior_ref flag available as a Cedar context attribute. Cedar policies MAY use this flag to apply additional scrutiny or mandatory HEM escalation to agents that repeatedly retry without declared learning. The cognitive discipline of explicitly articulating what has changed since a prior failure -- required by this type -- is the primary mechanism by which the IDP reduces uninformed retry loops (Section 3.1(e)). An agent that cannot articulate what has changed since its prior failure has not revised its reasoning basis and is structurally likely to produce the same outcome. Cedar policies SHOULD enforce a maximum retry count for RETRY_CONTINUATION IDPs against the same requested_action before mandatory HEM escalation, using the GEC-derived idp.prior_denial_count attribute. Implementations MAY define additional type values. Such values MUST be registered in the IDP Reasoning Basis Types registry (see Section 11) or prefixed with a URI identifying the defining organization. Unrecognized type values MUST be recorded in the Event Log and MUST NOT cause the GEC to reject the IDP. 4.4. HEM Urgency Values The hem_urgency field is a declaration by the agent of its assessment of whether human judgment should be sought before this action executes. The GEC uses this value as one input to HEM trigger determination. NONE: The agent assesses that no human judgment is needed for this action. The GEC proceeds with normal Cedar evaluation. RECOMMENDED: The agent assesses that human judgment would be beneficial but does not consider it required. The GEC SHOULD record this value but is not required to initiate HEM. GEC implementations MAY use this value to trigger HEM based on local policy. REQUIRED: The agent declares that it requires human judgment before this action executes. The GEC MUST initiate HEM_PENDING for this session upon receipt of an IDP with hem_urgency: REQUIRED, regardless of Cedar policy evaluation outcome. This corresponds to the HEM_AGENT_ESCALATED trigger class defined in [I-D.sato-soos-hem]. Note: A hem_urgency value of REQUIRED from the agent does not override GEC Cedar evaluation. Cedar evaluation still executes. However, even a Cedar PERMIT result MUST NOT cause the action to execute; the session enters HEM_PENDING, and the action awaits human decision. 4.5. IDP Profiles This document defines two IDP profiles: IDP_STANDARD: All REQUIRED fields present. confidence_level is agent-assessed. reasoning_basis.type is one of the defined values. This is the normative profile for agents with sufficient reasoning capability to self-assess. IDP_THIN: A reduced profile for agents with limited reasoning capability. See Section 7. The GEC MUST accept both profiles. The GEC MUST record the profile type in the IDP Event Log entry. 5. Submission Protocol 5.1. When the IDP Is Submitted The IDP MUST be submitted by the agent as part of the same GEC call that requests the state transition. The IDP MUST NOT be submitted after the action has executed. In a conforming agentic execution loop, the sequence is: 1. (SENSE) GEC delivers context to agent. 2. (REASON) Agent reasons about next action. 3. (PLAN) Agent consults Transition Graph API for available actions. 4. (ACT) Agent submits GEC.transition(mandate_jwt, cedar_action, idp) -- the IDP is part of this call. 5. (OBSERVE) Agent receives result: success, enriched DENY, or SESSION_HEM_PENDING. 6. (LOOP) Agent processes result before next ACT. The IDP MUST be present in the Transition Request. A Transition Request without an IDP MUST be rejected by a conforming GEC implementation. 5.2. GEC Receipt and Validation Upon receiving a Transition Request, the GEC MUST: (a) Validate that an IDP is present. If absent, return REJECT with error code IDP_MISSING. (b) Validate that the IDP fields conform to this specification. If malformed, return REJECT with error code IDP_MALFORMED. (c) Validate that the idp_id is unique for this governed object. If a duplicate idp_id is detected, return REJECT with error code IDP_DUPLICATE. (d) Validate that the IDP so_id matches the governed object UUID bound to the mandate_jwt. If mismatched, return REJECT with error code IDP_SO_MISMATCH. (e) Validate that the IDP mandate_id matches the jti claim of the presented mandate_jwt. If mismatched, return REJECT with error code IDP_MANDATE_MISMATCH. (f) Validate that step_sequence is strictly greater than the last committed step_sequence for this session. (g) If mission_ref is present, validate that it matches the mission_ref claim in the mandate_jwt (if that claim is present). If mismatched, return Enriched DENY with deny_code IDP_MISSION_REF_MISMATCH and a structured mismatch_detail block containing the expected and submitted mission_ref values. The GEC MUST log IDP_MISSION_REF_MISMATCH_REJECTED in the Event Log. If mission_ref mismatches exceed a configurable threshold within a session, the GEC SHOULD automatically trigger HEM_AGENT_ESCALATED (Class 2). (h) If reasoning_basis.type is RETRY_CONTINUATION and context_refs contains no reference to a prior IDP_SUBMITTED event for the same requested_action in this session, the GEC MUST log a WARNING entry (RETRY_WITHOUT_PRIOR_REF) in the Event Log and MUST make the retry_without_prior_ref flag available as a Cedar context attribute for the current evaluation. The GEC MUST NOT reject the IDP solely on this basis. GEC validation of the IDP precedes Cedar evaluation. A valid IDP is required for Cedar evaluation to proceed. 5.3. Event Log Commitment A conforming GEC implementation MUST commit an IDP_SUBMITTED event to the Event Log upon successful validation of the IDP, BEFORE Cedar evaluation executes. The IDP_SUBMITTED event MUST contain: * The full IDP object as submitted. * The GEC receipt timestamp (distinct from the agent timestamp). * The mandate_id. * The session_id. * The audit_accessible value (defaults to true if absent). * The GEC-derived prior_denial_count for the requested_action within the current session. * The GEC signature over the event. The IDP_SUBMITTED event is committed regardless of the subsequent Cedar evaluation outcome. If Cedar evaluation results in DENY, the IDP_SUBMITTED event remains in the Event Log as a permanent record of the agent's declared intent. The Event Log ordering guarantee is: IDP_SUBMITTED < Cedar evaluation < STATE_TRANSITIONED (or CEDAR_DENY_RECORDED) < ACTION_RESULT_RECORDED < IDP_COMMITMENT_VERIFIED (or IDP_COMMITMENT_GAP) (or CEDAR_DENY_RECORDED) The complete Event Log entry schemas are defined in Section 5.6. No STATE_TRANSITIONED event may appear in the Event Log without a preceding IDP_SUBMITTED event for the same step_sequence. Following every STATE_TRANSITIONED event, the GEC MUST generate an IDP_COMMITMENT_VERIFIED or IDP_COMMITMENT_GAP event as specified in Section 5.5. 5.4. IDP in Cedar Policy Evaluation The GEC MUST make the following IDP fields available as Cedar context attributes during policy evaluation: * idp.reasoning_basis.type -- string * idp.confidence_level -- decimal * idp.hem_urgency -- string * idp.goal_id -- string * idp.mission_ref -- string (null if absent) * idp.prior_denial_count -- integer (GEC-derived; count of prior DENY responses for the same requested_action in this session) * idp.retry_without_prior_ref -- boolean (true when reasoning_basis.type is RETRY_CONTINUATION and context_refs contains no prior IDP reference; false otherwise) Cedar policies MAY use these attributes in condition expressions. Example policies: // Require INSTRUCTION basis for high-value transitions permit(principal, action == Action::"ProcessPayment", resource) when { context.idp.reasoning_basis.type == "INSTRUCTION" }; // Require confidence >= 0.8 for autonomous state closure permit(principal, action == Action::"CloseBooking", resource) when { context.idp.confidence_level >= decimal("0.8") }; // Require mission_ref for MISSION_STAGE transitions permit(principal, action == Action::"AdvanceMissionStage", resource) when { context.idp.reasoning_basis.type == "MISSION_STAGE" && context.idp.mission_ref != null }; // Escalate to HEM after three denials for the same action forbid(principal, action, resource) when { context.idp.prior_denial_count >= 3 }; // Escalate to HEM when agent retries without declared learning forbid(principal, action, resource) when { context.idp.retry_without_prior_ref == true && context.idp.prior_denial_count >= 1 }; Cedar policies that reference IDP attributes but receive an IDP_THIN submission (Section 7) where the relevant attribute is absent MUST treat the absent attribute as if it had a value that causes the condition to evaluate to false, resulting in DENY. This ensures that thin-profile agents cannot satisfy policies written for standard-profile agents by omission. 5.5. IDP Commitment Verification After every successful governed state transition (STATE_TRANSITIONED Event Log entry), the GEC MUST generate an IDP Commitment Verification Record and commit it to the Event Log. The purpose of Commitment Verification is to detect IDP_COMMITMENT_GAP conditions: cases where the agent's actual state transition does not match the action declared in its preceding IDP. This mechanism enforces the non-suppressibility property: the GEC cannot conceal the fact that an agent's actual behaviour diverged from its declared intent. 5.5.1. IDP Commitment Verification Record Schema The IDP Commitment Verification Record MUST contain the following fields: idp_id: The idp_id of the IDP submitted for this transition. Links the verification record to the specific intent declaration. state_transition_id: The Event Log identifier of the STATE_TRANSITIONED entry being verified against. verified_at: ISO 8601 UTC timestamp of verification. Generated by the GEC. match_result: One of: MATCHED: The Cedar action string in the IDP's requested_action field matches the action that was executed in the state transition. The agent acted in accordance with its declaration. IDP_COMMITMENT_GAP: The Cedar action string in the IDP's requested_action field does not match the action that was executed. This is a critical audit finding. kernel_signature: Ed25519 signature over the canonical serialization of all fields except kernel_signature. 5.5.2. Event Log Entries IDP_COMMITMENT_VERIFIED: Committed when match_result is MATCHED. Contains the full IDP Commitment Verification Record. IDP_COMMITMENT_GAP: Committed when match_result is IDP_COMMITMENT_GAP. Contains the full IDP Commitment Verification Record. This entry MUST be treated as a critical audit finding. The GEC MUST immediately: (a) Generate a CRITICAL Audit Alert (alert_trigger: IDP_COMMITMENT_GAP). (b) Fire HEM_AGENT_ESCALATED (Class 2 per [I-D.sato-soos-hem] Section 5.2) for the active session. The HEM Escalation Request MUST include the IDP Commitment Verification Record in the idp_summary, with match_result: IDP_COMMITMENT_GAP clearly surfaced to the resolving principal. The GEC MUST NOT allow the agent session to continue after an IDP_COMMITMENT_GAP without HEM resolution. The session enters HEM_PENDING immediately. 5.5.3. Commitment Verification Scope The GEC compares the requested_action field of the IDP against the Cedar action string of the executed transition. The comparison is string-exact. A mismatch on any character MUST be recorded as IDP_COMMITMENT_GAP. IDP_COMMITMENT_GAP does not distinguish between: o An agent that declared one action and executed a different one due to an implementation error. o An agent that was coerced or compromised after IDP submission. o An agent that exploited a race condition between IDP submission and transition execution. All three produce the same audit finding. The distinction is a matter for human principal investigation following HEM resolution. 5.5.4. Relationship to GAR The IDP Commitment Verification Record and its Event Log entries are specified in this document. Their inclusion in Session Audit Records and Audit Packages is governed by [I-D.sato-soos-gar]. The IDP_COMMITMENT_GAP Audit Alert trigger is registered in the GAR Audit Alert Triggers registry. 5.5. IDP Commitment Verification 5.6. Outcome Event Log Entries 5.6. Outcome Event Log Entries The IDP_SUBMITTED entry (Section 5.3) records the agent's declared intent before the action executes. This section defines the complementary outcome entries that the GEC MUST commit after the action executes or is denied, completing the pre-action/post-action audit pair. Note: The authoritative definition of these entries will be provided by the Agent Execution Protocol (AEP) specification [I-D.sato-soos-aep] (forthcoming). The schemas defined here are a self-contained subset profile sufficient for conforming implementation of IDP-based audit without requiring AEP. Where AEP and this document define overlapping fields, AEP is normative. The complete Event Log ordering for a single governed transition is: IDP_SUBMITTED < Cedar evaluation < STATE_TRANSITIONED (PERMIT) or CEDAR_DENY_RECORDED (DENY) < ACTION_RESULT_RECORDED < IDP_COMMITMENT_VERIFIED or IDP_COMMITMENT_GAP (PERMIT only) 5.6.1. STATE_TRANSITIONED Committed by the GEC after a governed state transition executes successfully following a Cedar PERMIT. Records the result of the transition. { "event_type": "STATE_TRANSITIONED", ; REQUIRED. "event_id": string, ; REQUIRED. UUID v4. GEC-assigned. "session_id": string, ; REQUIRED. "so_id": string, ; REQUIRED. Governed object UUID. "mandate_id": string, ; REQUIRED. Mandate JWT jti claim. "step_sequence": integer, ; REQUIRED. Matches IDP step_sequence. "idp_id": string, ; REQUIRED. idp_id of preceding IDP. "cedar_action": string, ; REQUIRED. Cedar action string ; executed. "from_state": string, ; REQUIRED. SO state before transition. "to_state": string, ; REQUIRED. SO state after transition. "transition_inputs": object, ; OPTIONAL. Implementation-defined. ; MUST NOT contain PII. "transition_outputs": object, ; OPTIONAL. Implementation-defined. ; MUST NOT contain PII. "executed_at": string, ; REQUIRED. ISO 8601 UTC. "kernel_signature": string ; REQUIRED. Ed25519 signature. } 5.6.2. CEDAR_DENY_RECORDED Committed by the GEC when Cedar evaluation returns DENY. This entry is the permanent, GEC-signed Event Log record of the denial. It is produced independently of the Enriched DENY Response (Section 6) returned to the agent; both are produced for every denial. { "event_type": "CEDAR_DENY_RECORDED", ; REQUIRED. "event_id": string, ; REQUIRED. UUID v4. GEC-assigned. "session_id": string, ; REQUIRED. "so_id": string, ; REQUIRED. "mandate_id": string, ; REQUIRED. "step_sequence": integer, ; REQUIRED. Matches IDP step_sequence. "idp_id": string, ; REQUIRED. idp_id of preceding IDP. "cedar_action": string, ; REQUIRED. Cedar action string denied. "deny_code": string, ; REQUIRED. See Section 6.2. "deny_reason": string, ; REQUIRED. Human-readable. MUST NOT ; expose exploitable policy structure. "so_state_at_deny": string, ; REQUIRED. SO state at denial. "prior_denial_count": integer, ; REQUIRED. GEC-derived count of ; prior denials for this cedar_action ; in this session. "denied_at": string, ; REQUIRED. ISO 8601 UTC. "kernel_signature": string ; REQUIRED. Ed25519 signature. } Each denial produces a separate CEDAR_DENY_RECORDED entry. The sequence of CEDAR_DENY_RECORDED entries for the same cedar_action within a session constitutes the retry history surfaced to human principals when RETRY_LIMIT_EXCEEDED triggers HEM escalation (Section 6.3). 5.6.3. ACTION_RESULT_RECORDED Committed by the GEC after every governed transition, whether PERMIT or DENY, as a unified summary record linking the IDP to its outcome. This entry is the single join point between the pre-action IDP record and the post-action outcome, enabling audit tools to reconstruct the complete intent-to-outcome chain for any step_sequence without traversing multiple event types. { "event_type": "ACTION_RESULT_RECORDED", ; REQUIRED. "event_id": string, ; REQUIRED. UUID v4. GEC-assigned "session_id": string, ; REQUIRED. "so_id": string, ; REQUIRED. "step_sequence": integer, ; REQUIRED. "idp_id": string, ; REQUIRED. Links to IDP_SUBMITTED. "outcome": string, ; REQUIRED. One of: "PERMITTED", ; "DENIED", "HEM_PENDING". "outcome_event_id": string, ; REQUIRED. event_id of: ; STATE_TRANSITIONED (if PERMITTED), ; CEDAR_DENY_RECORDED (if DENIED), or ; HEM session event (if HEM_PENDING). "reasoning_basis_type": string, ; REQUIRED. Echo of IDP ; reasoning_basis.type. "confidence_level": number, ; REQUIRED. Echo of IDP ; confidence_level. "hem_urgency": string, ; REQUIRED. Echo of IDP hem_urgency. "recorded_at": string, ; REQUIRED. ISO 8601 UTC. "kernel_signature": string ; REQUIRED. Ed25519 signature. } The outcome field MUST be one of: PERMITTED: Cedar returned PERMIT and STATE_TRANSITIONED was committed. outcome_event_id references the STATE_TRANSITIONED entry. DENIED: Cedar returned DENY. outcome_event_id references the CEDAR_DENY_RECORDED entry. HEM_PENDING: The transition triggered HEM escalation (via hem_urgency: REQUIRED in the IDP, via RETRY_LIMIT_EXCEEDED, or via IDP_COMMITMENT_GAP). The action did not execute. outcome_event_id references the HEM session event. 5.6.4. Complete Audit Trail Example The following example shows the complete Event Log for an agent that attempts Action::"ProcessPayment", receives POLICY_DENY, submits a RETRY_CONTINUATION IDP with HEM escalation, and executes after human approval. Step 1 -- First attempt: IDP_SUBMITTED (step_sequence: 1, reasoning_basis.type: INFERENCE, hem_urgency: NONE) CEDAR_DENY_RECORDED (deny_code: POLICY_DENY, prior_denial_count: 0) ACTION_RESULT_RECORDED (outcome: "DENIED", step_sequence: 1, outcome_event_id: [CEDAR_DENY event_id]) Step 2 -- Retry with HEM escalation: IDP_SUBMITTED (step_sequence: 2, reasoning_basis.type: RETRY_CONTINUATION, context_refs: [idp_id from step 1], hem_urgency: REQUIRED, description: "Prior denial: POLICY_DENY. Payment amount exceeds autonomous threshold. Requesting human principal approval.") [CEDAR_DENY_RECORDED not committed -- HEM_PENDING triggered before Cedar evaluation by hem_urgency: REQUIRED] [HEM escalation and human principal DRR] ACTION_RESULT_RECORDED (outcome: "HEM_PENDING", step_sequence: 2, outcome_event_id: [HEM session event_id]) Step 3 -- Post-HEM execution: IDP_SUBMITTED (step_sequence: 3, reasoning_basis.type: INSTRUCTION, description: "Human principal approved via HEM DRR [drr_id]. Executing under instruction.") STATE_TRANSITIONED (from_state: PAYMENT_PENDING, to_state: PAYMENT_PROCESSED) ACTION_RESULT_RECORDED (outcome: "PERMITTED", step_sequence: 3, outcome_event_id: [STATE_TRANS event_id]) IDP_COMMITMENT_VERIFIED (match_result: MATCHED) This sequence produces nine Event Log entries across three ACT steps, providing a complete, GEC-signed, tamper-evident record of the agent's declared intent at each step, the authorization outcome at each step, the retry reasoning articulation, the HEM escalation and resolution, and the post-HEM execution. 6. Enriched DENY Response 6.1. Structure 6.2. Field Definitions 6.3. HEM Routing from DENY 7. IDP Thin Profile 8. Security Considerations 8.1. IDP as Declaration, Not Proof 8.2. Tamper Evidence 8.3. Inference from Denials 8.4. Replay Prevention 8.5. Delegation Chain Integrity 8.6. Thin Profile Risk 8.7. Commitment Verification Integrity 8.8. Retry Loop Exhaustion Attacks 9. Conformance Levels 9.1. Overview 9.2. Level 1 -- Application Profile 9.3. Level 2 -- Isolated Profile 9.4. Level 3 -- Kernel Profile 9.5. Regulatory Applicability 9.6. Conformance Level Signalling 10. Privacy Considerations 11. EU AI Act Applicability 12. IANA Considerations 13. References 13.1. Normative References 13.2. Informative References Acknowledgments Author's Address 6. Enriched DENY Response 6.1. Structure When Cedar evaluation results in DENY, a conforming GEC implementation MUST return an Enriched DENY Response rather than a bare authorization failure. The Enriched DENY Response is a JSON object: { "result": "DENY", ; REQUIRED. "deny_code": string, ; REQUIRED. See Section 6.2. "deny_reason": string, ; REQUIRED. Human-readable. "idp_received": object, ; REQUIRED. Echo of submitted IDP. "available_actions": [string], ; REQUIRED. Cedar actions currently ; permitted for this agent and SO. "suggested_paths": [object], ; OPTIONAL. See Section 6.2. "hem_available": boolean, ; REQUIRED. "prior_denial_count": integer, ; REQUIRED. GEC-derived count of ; prior denials for this ; requested_action in this session. "mismatch_detail": object, ; CONDITIONAL. Present when deny_code ; is IDP_MISSION_REF_MISMATCH. "timestamp": string ; REQUIRED. ISO 8601 UTC. } 6.2. Field Definitions deny_code: A machine-readable denial code. The following codes are defined: POLICY_DENY Cedar policy denied the action. MANDATE_SCOPE Action is outside the mandate's Cedar scope. SO_STATE_INVALID Action is not valid in the current SO state. HEM_PENDING Session is in HEM_PENDING; no transitions permitted until HEM is resolved. MANDATE_REVOKED Mandate JWT has been revoked. CROSS_PRINCIPAL_UNRESOLVED Cross-principal coordination required. MISSION_INVALID The governing MissionDeclaration is in a terminal phase (SUSPENDED, FAILED, or ABANDONED). No transitions are permitted until the mission state is resolved. IDP_MISSION_REF_MISMATCH IDP mission_ref does not match the active session MissionDeclaration. See mismatch_detail. RETRY_LIMIT_EXCEEDED The prior_denial_count for this requested_action has reached the Cedar policy threshold. HEM escalation is required before further retries. deny_reason: A human-readable explanation of why the action was denied. SHOULD be specific enough to guide the agent's next reasoning step. MUST NOT expose internal policy structure that would enable policy circumvention. idp_received: The complete IDP object as received and validated by the GEC. Allows the agent to verify that its declaration was received accurately. available_actions: An array of Cedar action strings that the agent's current mandate permits in the current SO state. MAY be empty if no actions are currently available. This is the primary mechanism by which the primary mechanism by which the GEC guides agents away from prohibited actions toward permitted ones, eliminating the need for uninformed retry against denied actions. suggested_paths: An OPTIONAL array of path objects, each representing a sequence of actions that would lead the agent to a state where the denied action becomes available. Each path object contains: { "path_id": string, ; UUID. "steps": [string], ; Ordered Cedar action strings. "requires_elevation": boolean } hem_available: A boolean indicating whether the agent may trigger HEM by resubmitting with hem_urgency: REQUIRED. False if the session is already in HEM_PENDING or if HEM is not configured for this SO Type. prior_denial_count: The GEC-derived count of prior DENY responses for the same requested_action within the current session. Included in the Enriched DENY Response to enable the agent to assess whether further retry is likely to be productive and to decide whether to submit a RETRY_CONTINUATION IDP or to escalate via HEM. When prior_denial_count reaches a Cedar policy threshold, the deny_code RETRY_LIMIT_EXCEEDED is returned and HEM escalation is required. mismatch_detail: CONDITIONAL. Present when deny_code is IDP_MISSION_REF_MISMATCH. Contains: { "expected_mission_ref": string, ; mission_ref from mandate JWT. "submitted_mission_ref": string ; mission_ref from IDP. } Enables the submitting agent to diagnose and correct the mismatch without ambiguity. 6.3. HEM Routing from DENY A Cedar DENY result with deny_code POLICY_DENY does not automatically trigger HEM. However, the agent MAY respond to a DENY by resubmitting the same action with hem_urgency: REQUIRED. If hem_available is true in the Enriched DENY Response, the GEC MUST accept the resubmission and enter HEM_PENDING, routing the decision to a designated human principal. This provides a normative escalation path for situations where the agent's Cedar-authorized scope does not include the needed action but the agent has grounds to believe that human judgment may permit it. When deny_code is RETRY_LIMIT_EXCEEDED, the GEC MUST automatically enter HEM_PENDING for the session. The agent MUST NOT submit further retries for the denied action until HEM is resolved. The HEM Escalation Request MUST include the prior_denial_count and the sequence of IDP_SUBMITTED events for the denied action, enabling the human principal to review the full retry history. 7. IDP Thin Profile Some agents -- particularly narrow executors operating on simple tasks -- may have limited capability to produce full IDP_STANDARD declarations. The IDP_THIN profile accommodates these agents while maintaining the core audit property of the IDP. An IDP_THIN submission MUST contain: * idp_id (REQUIRED) * session_id (REQUIRED) * so_id (REQUIRED) * mandate_id (REQUIRED) * step_sequence (REQUIRED) * requested_action (REQUIRED) * profile: "IDP_THIN" (REQUIRED; absent in IDP_STANDARD) * timestamp (REQUIRED) An IDP_THIN submission MUST omit: * declared_goal (OPTIONAL in IDP_THIN; GEC synthesizes stub) * reasoning_basis (OPTIONAL in IDP_THIN; GEC records "UNSPECIFIED") * confidence_level (OPTIONAL in IDP_THIN; GEC records 0.5 default) * hem_urgency (OPTIONAL in IDP_THIN; GEC defaults to "NONE") * mission_ref (OPTIONAL in IDP_THIN; GEC records null) The audit_accessible field is OPTIONAL in IDP_THIN; GEC defaults to true if absent. The GEC MUST record the IDP_THIN profile in the IDP_SUBMITTED event. The GEC SHOULD synthesize stub values for absent fields to maintain Event Log schema consistency. A conforming SO Type MAY declare that IDP_THIN submissions are not accepted for transitions of a given type. In this case, a GEC receiving an IDP_THIN submission for a prohibited transition MUST return REJECT with error code IDP_THIN_NOT_ACCEPTED. IDP_THIN submissions are subject to IDP Commitment Verification (Section 5.5). The requested_action field is present in IDP_THIN and is the basis for the commitment comparison. IDP_THIN submissions MUST NOT use reasoning_basis.type RETRY_CONTINUATION. A conforming GEC MUST return REJECT with error code IDP_THIN_NOT_ACCEPTED if an IDP_THIN submission includes reasoning_basis.type RETRY_CONTINUATION. Retry semantics require the full reasoning articulation of IDP_STANDARD. Note: This specification identifies thin profile GEC compensation as an area for future work. Mechanisms by which the GEC may synthesize richer IDP content from contextual signals for thin- profile agents are outside the scope of this document. 8. Security Considerations 8.1. IDP as Declaration, Not Proof The IDP records the agent's declared intent; it does not verify it. A compromised or adversarial agent may submit an IDP that does not accurately represent its actual reasoning. The security value of the IDP lies not in proof of intent but in the permanent, pre-action record that creates accountability: an agent that acts contrary to its declared intent produces an auditable inconsistency between the IDP record and the observed action sequence. The IDP Commitment Verification mechanism (Section 5.5) detects this inconsistency automatically. 8.2. Tamper Evidence The IDP_SUBMITTED Event Log entry MUST be GEC-signed before Cedar evaluation executes. This prevents retroactive modification of the intent record. Implementations MUST use an asymmetric signing key held by the GEC attestation component and MUST NOT permit agents to write directly to the Event Log. 8.3. Inference from Denials The Enriched DENY Response reveals information about permitted actions and authorization policy structure. Implementations MUST ensure that available_actions and suggested_paths do not reveal policy conditions that would enable adversarial agents to reverse- engineer policy bypass strategies. The deny_reason field MUST be informative without being exploitable. The prior_denial_count field in the Enriched DENY Response does not reveal policy structure; it reveals only how many times the same action has been denied in this session. This value is safe to expose to the agent. 8.4. Replay Prevention The idp_id uniqueness requirement (Section 5.2(c)) prevents replay of previously committed IDP objects. Implementations MUST maintain an in-memory index of committed idp_ids for the lifetime of each governed object, rebuilt from the Event Log on GEC restart. 8.5. Delegation Chain Integrity The IDP's mandate_id field links the intent declaration to the authorization credential. In multi-hop delegation chains, the mandate_id identifies the specific delegation under which the action is requested. This enables audit tracing of intent across delegation trees. In systems implementing the actor chain model [I-D.mcguinness-oauth-actor-profile], the mandate JWT carries a delegation_chain claim identifying each principal in the issuance chain. The IDP's mandate_id field, which references the jti of the presented mandate JWT, therefore provides a complete traceability link from the per-transition intent declaration to the full delegation chain. Audit tools reconstructing agent reasoning SHOULD traverse the delegation_chain of the referenced mandate JWT to identify all principals in the chain of authority. 8.6. Thin Profile Risk IDP_THIN submissions provide reduced accountability because the reasoning record is minimal. High-value or high-risk transitions SHOULD require IDP_STANDARD submissions. SO Type designers SHOULD use the IDP_THIN_NOT_ACCEPTED mechanism (Section 7) for transitions where reasoning accountability is critical. IDP_THIN submissions MUST NOT carry RETRY_CONTINUATION reasoning basis type (Section 7). 8.7. Commitment Verification Integrity The IDP Commitment Verification Record (Section 5.5) is GEC- generated and GEC-signed. Agents MUST NOT be able to influence the match_result field. Implementations MUST ensure that the comparison between requested_action and the executed transition action string occurs entirely within the GEC, with no agent- accessible interface to the comparison logic or its result. 8.8. Retry Loop Exhaustion Attacks An adversarial agent may attempt to exhaust system resources by submitting continuous RETRY_CONTINUATION IDPs against a denied action, generating Event Log entries without advancing a legitimate goal. Implementations MUST enforce the Cedar policy threshold for prior_denial_count (Section 5.4) and MUST enter HEM_PENDING automatically when RETRY_LIMIT_EXCEEDED is triggered (Section 6.3). The HEM escalation requirement ensures that human review interrupts pathological retry behaviour. 9. Conformance Levels 9.1. Overview IDP conformance is defined at three levels. All three levels share the same IDP wire format (Section 4.1), the same pre-action submission requirement (Section 5.1), and the same Enriched DENY Response structure (Section 6). They differ in the implementation form of the Governing Enforcement Component (GEC) and in the resulting non-suppressibility guarantee of the Event Log. The three levels allow application developers to implement Level 1 today using standard SDK libraries, enterprise operators to implement Level 2 using container or sidecar deployment, and regulated high- risk AI system operators to implement Level 3 using hardware attestation infrastructure. All three levels are IDP-conformant. Level 1 -- Application Profile: GEC implemented as a library or middleware component within the agent execution environment. Non-suppressibility is probabilistic. Compensated by SCITT corroboration. Level 2 -- Isolated Profile: GEC implemented as a separate process or sidecar with software- enforced isolation. Signing key inaccessible to agent process. Non-suppressibility is architectural. Level 3 -- Kernel Profile: GEC runs in a RATS-attested hardware execution environment. Signing key bound to TEE via RATS attestation. Non-suppressibility is hardware-enforced. 9.2. Level 1 -- Application Profile The Application Profile is the entry-level conformance tier for developers implementing IDP within an existing application stack without deploying new infrastructure. SDK libraries, middleware interceptors, in-process enforcement modules, and agent framework plugins are all conforming Level 1 GEC implementations. Level 1 GEC implementations MUST: (a) Accept the IDP as part of the Transition Request (Section 5.1) and commit an IDP_SUBMITTED entry to the Event Log before the governed action executes. The calling convention MUST ensure that the action is not invoked if the GEC call fails or if IDP validation fails (Section 5.2). (b) Return an Enriched DENY Response (Section 6) for every denied action, including the available_actions, prior_denial_count, and idp_received fields. (c) Commit STATE_TRANSITIONED, CEDAR_DENY_RECORDED, and ACTION_RESULT_RECORDED entries (Section 5.6) for every transition. (d) Sign all Event Log entries. At Level 1, the signing key MAY be application-managed. The kernel_signature field MUST be present. The signature MUST include a label sub-field with value "L1-app-signed". (e) Enforce RETRY_CONTINUATION requirements (Section 4.3) and maintain the GEC-derived prior_denial_count attribute (Section 5.4) across Transition Requests within a session. (f) Enforce data_residency constraints (Section 4.2) in all Event Log queries and analytics contributions. Level 1 GEC implementations SHOULD: (g) Register Session Audit Records as SCITT Signed Statements. SCITT corroboration is the primary mechanism by which Level 1 achieves externally-verifiable non-suppressibility without process isolation. (h) Implement IDP Commitment Verification (Section 5.5). Commitment Verification is RECOMMENDED at Level 1. Non-suppressibility: PROBABILISTIC. SCITT corroboration converts to externally-verifiable detection of suppression. Signature label: "L1-app-signed". Tier 2 analytics default: operator-configurable. Tier 3 analytics default: opt-in only (tier3_eligible: false). 9.3. Level 2 -- Isolated Profile The Isolated Profile requires that the GEC run as a separate process from the agent with OS-enforced memory isolation between GEC and agent. The signing key MUST be held by the GEC process and MUST NOT be accessible to the agent process by any interface. Level 2 GEC implementations MUST: (a) All Level 1 MUST requirements. (b) Run as a process separate from the agent with OS-level memory isolation. In containerized deployments, a dedicated GEC container with no shared memory with the agent container is conforming. A sidecar with mTLS to the agent is conforming. (c) Hold the signing key in a memory space inaccessible to the agent process. The agent MUST NOT be able to read, modify, or delete Event Log entries directly; all interaction MUST be mediated by the GEC Transition Request interface. (d) Implement IDP Commitment Verification (Section 5.5). At Level 2, Commitment Verification is REQUIRED. (e) Register Session Audit Records in a SCITT Transparency Service. Non-suppressibility: ARCHITECTURAL. Requires independently compromising the GEC process. Signature label: "L2-isolated-signed". 9.4. Level 3 -- Kernel Profile The Kernel Profile is the reference implementation level and the normative compliance baseline for regulated high-risk AI systems. The GEC runs in a RATS-attested Trusted Execution Environment (TEE). Level 3 GEC implementations MUST: (a) All Level 2 MUST requirements. (b) Run the GEC within a hardware-attested TEE. Conforming technologies include Intel TDX, AMD SEV-SNP, ARM TrustZone, and equivalent hardware isolation technologies. (c) Attest the GEC execution environment using RATS [I-D.ietf-rats-architecture]. Attestation results MUST conform to [I-D.ietf-rats-ar4si]. The attestation result reference MUST be included in the Session Audit Record. (d) Bind the signing key to the TEE attestation environment such that the key MUST NOT be usable outside the verified TEE context. (e) Register Session Audit Records in a SCITT Transparency Service backed by a CCF-profile implementation or equivalent attested execution environment. Non-suppressibility: HARDWARE-ENFORCED. Signature label: "L3-kernel-signed". 9.5. Regulatory Applicability This section is informative and does not constitute legal advice. EU AI Act Article 12 (logging requirements for high-risk AI systems): Level 1 without SCITT: INSUFFICIENT for Article 12 for high-risk systems. Level 1 with SCITT: MAY satisfy Article 12 for lower-risk categories of high-risk systems. Operators SHOULD obtain a legal opinion before relying on Level 1 for Article 12 compliance. Level 2: SHOULD satisfy Article 12 for most high-risk AI system categories. Level 3: RECOMMENDED for Article 12 compliance for the highest-risk categories including autonomous systems, critical infrastructure, and financial decision AI. EU AI Act Article 14 (human oversight): HEM escalation requirements (Section 6.3) are equally mandatory at all three conformance levels. NIST AI RMF GOVERN 1.5, MANAGE 2.2: All three levels satisfy the GOVERN 1.5 and MANAGE 2.2 mappings. Level 3 is RECOMMENDED for MANAGE 4.1 (monitoring of deployed systems) in high-stakes contexts. 9.6. Conformance Level Signalling (a) Every Event Log entry's kernel_signature field MUST include a label sub-field with value "L1-app-signed", "L2-isolated-signed", or "L3-kernel-signed" as appropriate. (b) A governed SO Type MAY declare a minimum required conformance level. A GEC that receives a Transition Request for an SO Type requiring a higher conformance level MUST return REJECT with error code GEC_LEVEL_INSUFFICIENT. (c) The GEC SHOULD expose its declared conformance level via the GEC Query Interface. Audit Principals SHOULD verify declared level against signature labels in sampled Event Log entries. The deny code GEC_LEVEL_INSUFFICIENT is added to the IDP Deny Codes IANA registry (Section 12). 10. Privacy Considerations The IDP contains agent-generated text in the declared_goal. description and reasoning_basis.description fields. These fields MUST NOT contain personally identifiable information. The GEC SHOULD validate that these fields do not contain obvious PII markers (email addresses, phone numbers, names), but CANNOT guarantee the absence of PII through syntactic validation alone. Implementers MUST ensure that Event Log access controls prevent unauthorized parties from reading IDP records. The audit_accessible field (Section 4.1) provides a mechanism for restricting Audit Principal access to individual IDP records. IDP records are governance data, not publicly accessible telemetry. IDP records associated with governed objects that are subject to data protection erasure requests present a tension with the Event Log's append-only property. This tension is addressed through the Zone A personal data prohibition and cryptographic erasure provisions specified in the GEC implementation. The reasoning_basis.description field in RETRY_CONTINUATION IDPs MAY contain references to prior failed actions that themselves contain contextual information. Implementers SHOULD treat RETRY_CONTINUATION reasoning descriptions with the same PII sensitivity as primary IDP descriptions. 11. EU AI Act Applicability This section is informative. EU AI Act Article 12 requires that high-risk AI systems maintain automatic logging sufficient for post-deployment monitoring and human review of AI decisions. The IDP, committed to a GEC-signed Event Log before each agent action, provides the per-decision record that Article 12 contemplates. EU AI Act Article 14 requires human oversight measures enabling intervention in the operation of high-risk AI systems. The HEM escalation path triggered by hem_urgency: REQUIRED, and the HEM routing from Cedar DENY responses (Section 6.3), provide the normative intervention mechanism that Article 14 requires. The HEM protocol is fully specified in [I-D.sato-soos-hem]. The IDP Commitment Verification mechanism (Section 5.5) contributes to Article 14(4)(c) compliance: automatic detection of anomalous situations (commitment gaps between declared intent and actual action) with mandatory human escalation. The RETRY_CONTINUATION reasoning basis type and the prior_denial_count threshold mechanism provide an additional contribution to Article 14 compliance: automatic detection of pathological agent retry behaviour with mandatory human escalation after a configurable threshold, ensuring that humans can intervene before agents exhaust their retry budget against a denied action class. This document does not constitute legal advice and makes no representation that conforming implementations satisfy any regulatory requirement. 12. IANA Considerations This document requests the creation of the following IANA registry: Registry Name: IDP Reasoning Basis Types Registration Procedure: Specification Required [RFC8126] Initial Values: +----------------------+------------------------------------------+ | Type Value | Description | +----------------------+------------------------------------------+ | RULE_BASED | Action selected by applying a defined | | | rule to the current state | | INFERENCE | Action inferred from contextual reasoning| | INSTRUCTION | Action executing an explicit instruction | | | from a human principal or higher- | | | authority agent | | UNCERTAINTY_ | Action taken to reduce uncertainty before| | REDUCTION | selecting a goal-advancing action | | MISSION_STAGE | Action advancing the governing | | | MissionDeclaration to the next stage; | | | mission_ref MUST be present | | RETRY_CONTINUATION | Agent retrying an action following a | | | prior denial or failure; context_refs | | | MUST reference prior IDP_SUBMITTED event;| | | reasoning_basis.description MUST | | | articulate what has changed since the | | | prior attempt; NOT permitted in IDP_THIN | +----------------------+------------------------------------------+ Table 1: Initial IDP Reasoning Basis Types Registry Values This document also requests the creation of the following IANA registry: Registry Name: IDP Deny Codes Registration Procedure: Specification Required [RFC8126] Initial Values: +--------------------------------+--------------------------------+ | Deny Code | Description | +--------------------------------+--------------------------------+ | POLICY_DENY | Cedar policy denied the action | | MANDATE_SCOPE | Outside mandate Cedar scope | | SO_STATE_INVALID | Invalid in current SO state | | HEM_PENDING | Session in HEM_PENDING state | | MANDATE_REVOKED | Mandate JWT revoked | | CROSS_PRINCIPAL_UNRESOLVED | Cross-principal pending | | MISSION_INVALID | MissionDeclaration in terminal | | | phase; no transitions permitted| | IDP_MISSION_REF_MISMATCH | IDP mission_ref mismatch; | | | see mismatch_detail | | IDP_MISSING | IDP absent from call | | IDP_MALFORMED | IDP failed schema validation | | IDP_DUPLICATE | Duplicate idp_id detected | | IDP_SO_MISMATCH | IDP so_id / mandate mismatch | | IDP_MANDATE_MISMATCH | IDP mandate_id / JWT mismatch | | IDP_THIN_NOT_ACCEPTED | IDP_THIN not accepted here | | RETRY_LIMIT_EXCEEDED | prior_denial_count at Cedar | | | policy threshold; HEM required | | GEC_LEVEL_INSUFFICIENT | SO Type requires higher GEC | | | conformance level than provided| +--------------------------------+--------------------------------+ Table 2: Initial IDP Deny Codes Registry Values 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [Cedar] Amazon Web Services, "Cedar Policy Language", . [I-D.sato-soos-hem] Sato, T., "The Human Escalation Mechanism (HEM) for Agentic AI Systems", Work in Progress, Internet-Draft, draft-sato-soos-hem-01, May 2026, . 13.2. Informative References [EUAIA] European Union, "Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)", Official Journal of the European Union, 12 July 2024, . [I-D.ietf-wimse-arch] Salowey, J., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft-ietf-wimse-arch-07, March 2026, . [I-D.ietf-oauth-v2-1] Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1 Authorization Framework", Work in Progress, Internet-Draft, draft-ietf-oauth-v2-1, 2026, . [I-D.klrc-aiagent-auth] Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., and N. Steele, "AI Agent Authentication and Authorization", Work in Progress, Internet-Draft, draft-klrc-aiagent-auth-01, March 2026, . [I-D.rosenberg-aiproto-cheq] Rosenberg, J., White, P., and C. Jennings, "CHEQ: A Protocol for Confirmation AI Agent Decisions with Human in the Loop (HITL)", Work in Progress, Internet-Draft, draft-rosenberg-aiproto-cheq-00, October 2025, . [I-D.sato-soos-gar] Sato, T., "The Governance Audit Record (GAR) for Agentic AI Systems", Work in Progress, Internet-Draft, draft-sato-soos-gar-00, May 2026, . [I-D.sato-soos-transition-graph] Sato, T., "Transition Graph API for Agentic AI Systems", Work in Progress, Internet-Draft, draft-sato-soos-transition-graph-00, 2026 (forthcoming). [I-D.mcguinness-oauth-actor-profile] McGuinness, K., "OAuth Actor Profile for AI Agents", Work in Progress, Internet-Draft, draft-mcguinness-oauth-actor-profile-00, 2026, . [I-D.mcguinness-oauth-mission-bound-authorization] McGuinness, K., "Mission Bound Authorization", Work in Progress, Internet-Draft, draft-mcguinness-oauth-mission-bound-authorization-00, 2026, . [Williams-IBA] Williams, J., "Intent Bound Authorization", GB2603013.0, PCT pending, 2025. Acknowledgments The IDP design draws on the Windley Loop context injection model and the Cedar policy evaluation architecture [Cedar]. The directional distinction from Williams IBA was identified through review of [Williams-IBA]. The mission_ref field and MISSION_STAGE reasoning type were added following review of the McGuinness Mission Bound Authorization framework [I-D.mcguinness-oauth-mission-bound- authorization] and the actor chain model [I-D.mcguinness-oauth-actor-profile]. The IDP Commitment Verification mechanism was developed in conjunction with the Governance Audit Record specification [I-D.sato-soos-gar]. The RETRY_CONTINUATION reasoning basis type and the computational efficiency motivation in Section 1 and Section 3.1(e) were developed through operational analysis of LLM agent execution patterns, specifically the observation that agents lacking a pre-action commitment discipline for retry reasoning exhibit structurally redundant computation at scale. Author's Address Tom Sato MyAuberge K.K. Chino, Nagano Japan Email: tomsato@myauberge.jp URI: https://activitytravel.pro/