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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/rfc/rfc4122>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[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,
<https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
[Cedar] Amazon Web Services, "Cedar Policy Language",
<https://www.cedarpolicy.com/>.
[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,
<https://datatracker.ietf.org/doc/draft-sato-soos-hem/>.
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,
<https://eur-lex.europa.eu/legal-content/EN/TXT/
?uri=OJ:L_202401689>.
[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,
<https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/>.
[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,
<https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/>.
[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,
<https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/>.
[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,
<https://datatracker.ietf.org/doc/
draft-rosenberg-aiproto-cheq/>.
[SOOS] Sato, T., "Sovereign Object OS -- Kernel Specification",
Work in Progress, Version 2, May 2026,
<https://activitytravel.pro/>.
[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,
<https://datatracker.ietf.org/doc/
draft-mcguinness-oauth-actor-profile/>.
[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,
<https://datatracker.ietf.org/doc/
draft-mcguinness-oauth-mission-bound-authorization/>.
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/