Network Working Group T. Sato Internet-Draft MyAuberge K.K. Intended status: Standards Track 10 May 2026 Expires: 11 November 2026 The Intent Declaration Primitive (IDP) for Agentic AI Systems draft-sato-soos-idp-00 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 OS kernel 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. 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 11 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 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. Kernel Receipt and Validation 5.3. Event Log Commitment 5.4. IDP in Cedar Policy Evaluation 6. Enriched DENY Response 6.1. Structure 6.2. Field Definitions 6.3. HEM Routing from DENY 7. IDP Thin Profile 8. Security Considerations 9. Privacy Considerations 10. EU AI Act Applicability 11. IANA Considerations 12. References 12.1. Normative References 12.2. Informative References Acknowledgments Author's Address 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 three 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. This document defines the Intent Declaration Primitive (IDP): a structured JSON object submitted by an AI agent to a governing runtime kernel 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 kernel 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 kernel 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. 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 Kernel: A runtime component that enforces authorization policy, records agent actions to a tamper-evident Event Log, and mediates agent access to governed objects. The Sovereign Object OS (SOOS) [SOOS] is the reference kernel specification for this document. Governed Object: A typed, stateful entity that the kernel governs. An agent operates on governed objects; the kernel 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 governing kernel to evaluate authorization decisions. Cedar evaluates before any state transition executes. HEM: Human Escalation Mechanism. A kernel-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. 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 four 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. 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 kernel, 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. 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. "metadata": object, ; OPTIONAL. Implementation-defined. "timestamp": string ; REQUIRED. ISO 8601 UTC. } 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 [SOOS], 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 kernel 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 kernel 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. 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 kernel. 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. metadata: An OPTIONAL implementation-defined JSON object. The kernel 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 kernel MUST record both this timestamp and the kernel receipt timestamp in the Event Log entry. 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 (DISCOVERY to EXECUTION, EXECUTION to RELEASE) [SOOS]. 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. Implementations MAY define additional type values. Such values MUST be registered in the SOOS IDP Reasoning Basis Type 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 kernel 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 kernel uses this value as one input to HEM trigger determination. NONE: The agent assesses that no human judgment is needed for this action. The kernel proceeds with normal Cedar evaluation. RECOMMENDED: The agent assesses that human judgment would be beneficial but does not consider it required. The kernel SHOULD record this value but is not required to initiate HEM. Kernel 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 kernel 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 kernel 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 kernel MUST accept both profiles. The kernel 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 kernel 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) Kernel 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 kernel.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 kernel.transition() call. A kernel.transition() call without an IDP MUST be rejected by a conforming kernel implementation. 5.2. Kernel Receipt and Validation Upon receiving a kernel.transition() call, the kernel 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 REJECT with error code IDP_MISSION_REF_MISMATCH. Kernel validation of the IDP precedes Cedar evaluation. A valid IDP is required for Cedar evaluation to proceed. 5.3. Event Log Commitment A conforming kernel 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 kernel receipt timestamp (distinct from the agent timestamp). * The mandate_id. * The session_id. * The kernel signature over the event (REQUIRED per INV-9 of [SOOS]). 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) No STATE_TRANSITIONED event may appear in the Event Log without a preceding IDP_SUBMITTED event for the same step_sequence. 5.4. IDP in Cedar Policy Evaluation The kernel 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) 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 }; 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. 6. Enriched DENY Response 6.1. Structure When Cedar evaluation results in DENY, a conforming kernel 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. "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; pending resolution of [I-D.soos-oq-s-41]. MISSION_INVALID The governing MissionDeclaration is in a terminal phase (SUSPENDED, FAILED, or ABANDONED). No transitions are permitted until the mission state is resolved. 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 kernel. 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 kernel guides agents away from prohibited actions toward permitted ones. 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. 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 kernel 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. 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; kernel synthesizes stub) * reasoning_basis (OPTIONAL in IDP_THIN; kernel records "UNSPECIFIED") * confidence_level (OPTIONAL in IDP_THIN; kernel records 0.5 default) * hem_urgency (OPTIONAL in IDP_THIN; kernel defaults to "NONE") * mission_ref (OPTIONAL in IDP_THIN; kernel records null) The kernel MUST record the IDP_THIN profile in the IDP_SUBMITTED event. The kernel 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 kernel receiving an IDP_THIN submission for a prohibited transition MUST return REJECT with error code IDP_THIN_NOT_ACCEPTED. Note: This specification identifies thin profile kernel compensation as an area for future work. Mechanisms by which the kernel 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. 8.2. Tamper Evidence The IDP_SUBMITTED Event Log entry MUST be kernel-signed before Cedar evaluation executes. This prevents retroactive modification of the intent record. Implementations MUST use an asymmetric signing key held by the kernel 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. 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 kernel 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. 9. 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 kernel 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. 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 document does not resolve this tension; it is addressed in the governing kernel specification [SOOS] through the Zone A personal data prohibition (INV-13) and cryptographic erasure provisions. 10. 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 kernel-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]. This document does not constitute legal advice and makes no representation that conforming implementations satisfy any regulatory requirement. 11. IANA Considerations This document requests the creation of the following IANA registry: Registry Name: SOOS IDP Reasoning Basis Types Registration Procedure: Specification Required [RFC8126] Initial Values: +--------------------+--------------------------------------------+ | Type Value | Description | +--------------------+--------------------------------------------+ | RULE_BASED | Action selected by applying a defined rule | | INFERENCE | Action inferred from contextual reasoning | | INSTRUCTION | Action executing an explicit instruction | | UNCERTAINTY_ | Action taken to reduce uncertainty before | | REDUCTION | selecting a goal-advancing action | | MISSION_STAGE | Action advancing the governing | | | MissionDeclaration to the next stage | | | (DISCOVERY/EXECUTION/RELEASE); mission_ref | | | MUST be present | +--------------------+--------------------------------------------+ This document also requests the creation of the following IANA registry: Registry Name: SOOS 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_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_MISSION_REF_MISMATCH | IDP mission_ref / JWT mismatch | | IDP_THIN_NOT_ACCEPTED | IDP_THIN not accepted here | +-------------------------------+---------------------------------+ 12. References 12.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., "Human Escalation Mechanism (HEM) for Agentic AI Systems", Work in Progress, Internet-Draft, draft-sato-soos-hem-00, May 2026, . 12.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, . [SOOS] Sato, T., "Sovereign Object OS -- Kernel Specification", Work in Progress, Version 2, May 2026, . [Williams-IBA] Williams, J., "Intent Bound Authorization", GB2603013.0, PCT pending, 2025. [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, . Acknowledgments The IDP design draws on the Windley Loop context injection model [Windley] and the Cedar policy evaluation architecture [Cedar]. The EU AI Act Article 12 analysis was developed in the context of the Sovereign Object OS specification [SOOS]. 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]. Author's Address Tom Sato MyAuberge K.K. Chino, Nagano, Japan Email: [tomsato@myauberge.jp] URI: https://activitytravel.pro/