Network Working Group T. Sato
Internet-Draft MyAuberge K.K.
Intended status: Standards Track 30 June 2026
Expires: 30 December 2026
The Intent Declaration Primitive (IDP) for Agentic AI Systems
draft-sato-soos-idp-05
Abstract
Every action an AI agent takes is a decision. Right now, none of
those decisions are signed.
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.
Version -05 adds: the intake_endorsement operation (Section 4.6)
through which the GEC endorses a submitted EOD before the first
SENSE delivery, making the EOD a GEC-signed artifact and preventing
unendorsed IDPs from proceeding; the PD-EOD (Prompt-Derived EOD)
branch (Section 4.7) for IDPs derived from natural-language prompts
rather than structured input, with scope-bounding rules and HEM
notification requirements; the mandate_reference field (Section 4.1)
linking each IDP to an SPO URI for structural validation; confidence_
level calibration guidance (Section 7) including the CONFIDENCE_
MISCALIBRATION_WARNING trigger; RETRY_CONTINUATION normative
strengthening with backward reference to AEP-02's what_changed
requirement; and four new Security Considerations addressing prompt
injection at intake, EOD scope manipulation, confidence_level
inflation attacks, and COMMITMENT_GAP exploitation.
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 30 December 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.3.1. Reasoning Mode Values
4.4. HEM Urgency Values
4.5. IDP Profiles
4.6. Intake Endorsement Operation [NEW in -05]
4.6.1. Endorsement Request
4.6.2. Endorsed EOD Response
4.6.3. Intake Endorsement Validation Errors
4.7. PD-EOD: Prompt-Derived EOD Branch [NEW in -05]
4.7.1. PD-EOD Schema
4.7.2. PD-EOD Scope-Bounding Rule
4.7.3. PD-EOD HEM Notification Requirement
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
5.5. IDP Commitment Verification
5.5.1. IDP Commitment Verification Record Schema
5.5.2. Event Log Entries
5.5.3. Commitment Verification Scope
5.5.4. Relationship to GAR
5.6. Outcome Event Log Entries
5.6.1. STATE_TRANSITIONED
5.6.2. CEDAR_DENY_RECORDED
5.6.3. ACTION_RESULT_RECORDED
5.6.4. Complete Audit Trail Example
6. Enriched DENY Response
6.1. Structure
6.2. Field Definitions
6.3. HEM Routing from DENY
7. Confidence Level Calibration Guidance [NEW in -05]
7.1. Calibration Obligations
7.2. CONFIDENCE_MISCALIBRATION_WARNING Trigger
7.3. Correction Mechanism
8. IDP Thin Profile
9. Security Considerations
9.1. IDP as Declaration, Not Proof
9.2. Tamper Evidence
9.3. Inference from Denials
9.4. Replay Prevention
9.5. Delegation Chain Integrity
9.6. Thin Profile Risk
9.7. Commitment Verification Integrity
9.8. Retry Loop Exhaustion Attacks
9.9. Cross-Context Replay
9.10. Agent Session Revocation
9.11. Prompt Injection at Intake [NEW in -05]
9.12. EOD Scope Manipulation [NEW in -05]
9.13. Confidence Level Inflation Attack [NEW in -05]
9.14. COMMITMENT_GAP Exploitation [NEW in -05]
10. Conformance Levels
10.1. Overview
10.2. Level 1 -- Application Profile
10.3. Level 2 -- Isolated Profile
10.4. Level 3 -- Kernel Profile
10.5. Regulatory Applicability
10.6. Conformance Level Signalling
11. Privacy Considerations
12. EU AI Act Applicability
13. IANA Considerations
14. References
14.1. Normative References
14.2. Informative References
1. Introduction
When an AI agent takes an action in a production system -- approving
a transaction, modifying a record, sending a message -- there is
currently no standard mechanism for that agent to declare, before
the action executes, what goal the action serves, what reasoning led
to it, and how confident the agent is that it is appropriate. If
the action produces a bad outcome, there is no signed record of what
the agent was thinking. If the agent acted contrary to its
instructions, there is no tamper-evident evidence of the
discrepancy. If a regulator asks why the AI system made a specific
decision, the answer is reconstructed from action logs that record
what happened, not why.
If you are building an agentic AI system today, the absence of a
per-transition intent record means that when an agent takes a wrong
action, you cannot prove what the agent believed it was doing at
the moment it acted -- only what it did. IDP closes this gap by
requiring the agent to declare its goal, reasoning basis, and
confidence level to the GEC before each action executes, committed
to a tamper-evident Event Log. Without it, post-hoc review,
regulatory audit, and automatic anomaly detection are all working
from an incomplete record.
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 the Enriched DENY Response
(Section 6), the RETRY_CONTINUATION reasoning basis type (Section
4.3), and the AEP-02 what_changed requirement [I-D.sato-soos-aep]
Section 10.4, which together make failure history a first-class input
to both Cedar policy evaluation and human principal review.
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
guarantee: ex-post fabrication of intent is structurally impossible
in a conforming SOOS deployment because the IDP is GEC-signed before
Cedar evaluation executes.
Version -05 introduces the intake_endorsement operation (Section
4.6), which provides a GEC-signed Endorsed EOD before the first
SENSE delivery. The intake_endorsement output is a prerequisite
for the AEP session to begin for Class 2 and Class 3 agents: an
IDP submitted in a session without an Endorsed EOD MUST be rejected
unless the session is Class 1. Version -05 also defines the PD-EOD
branch (Section 4.7) for IDPs derived from natural-language prompts,
with normative scope-bounding rules and HEM notification requirements
for external-system touch. Confidence level calibration guidance
(Section 7) and four new Security Considerations complete the -05
additions.
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.
Endorsed EOD:
An Expected Outcome Declaration [I-D.sato-soos-aep] Section 6
that has been processed by the GEC intake_endorsement operation
(Section 4.6) and returned with a GEC signature. An Endorsed EOD
is a prerequisite for an IDP-bearing session to begin for Class 2
and Class 3 agents.
PD-EOD (Prompt-Derived EOD):
An EOD derived by the GEC from a natural-language prompt submitted
by the agent or operator, rather than from a structured EOD
submission. A PD-EOD carries a derived: true flag and is subject
to additional scope-bounding and HEM notification requirements
(Section 4.7).
SPO URI:
A Sovereign Protocol Object URI identifying the mandate or SO
Type that governs this IDP session. Used in the mandate_reference
field (Section 4.1) for structural validation.
CONFIDENCE_MISCALIBRATION_WARNING:
A GEC-generated Event Log entry emitted when the agent's declared
confidence_level is systematically inconsistent with the observed
outcome pattern for the same action class. See Section 7.2.
All other terms are as defined in [I-D.sato-soos-aep] and
[I-D.sato-soos-idp] (prior versions).
3. Problem Statement
3.1. The Intent Gap in Agentic Authorization
Access control systems have advanced from identity-based (who is
this agent?) to role-based (what is this agent's role?) to
attribute-based (what attributes does this context have?). None of
these systems capture intent: what does this agent declare it is
trying to accomplish with this specific action in this specific
context?
The intent gap has three concrete consequences:
(a) Post-hoc reconstruction of reasoning. After an agent takes a
harmful action, the audit record shows what it did. The
reasoning that led to it is reconstructed -- from logs, from
LLM traces, from system state -- not retrieved from a signed
pre-action commitment. Reconstructed intent is rebuttable.
Committed intent is not.
(b) Undifferentiated retry semantics. When an action is denied,
the standard response is a 403 or equivalent. The agent knows
the action was denied; it does not know why in a structured,
machine-processable form. Without structured denial reason and
declared-what-changed semantics, the agent's retry is
informationally equivalent to its first attempt.
(c) Intent-blind authorization. Cedar policies and ABAC rules
evaluate the action, the resource, and the context. None of
these systems evaluate the declared purpose of the action. Two
agents requesting the same action on the same resource with the
same attributes but different declared purposes are
indistinguishable to the authorization engine.
IDP closes all three gaps.
3.2. Relationship to EU AI Act Article 12
EU AI Act Article 12 requires high-risk AI systems to maintain logs
sufficient for post-market monitoring and post-hoc review of system
decisions. The IDP is the technical mechanism that satisfies this
requirement at the action level.
For each governed action: the IDP provides the declared intent
(before), the Cedar evaluation result (during), and the outcome
Event Log entries (after). The pre-action/post-action pair is the
Article 12 record. The GEC-signed IDP_SUBMITTED Event Log entry is
the proof that the record cannot be fabricated post-hoc.
3.3. Relationship to Williams Intent Bound Authorization
The Williams Intent Bound Authorization framework articulates the
principle that authorization decisions should evaluate declared intent
alongside action and resource. IDP is the IETF standards-track
specification of this principle: it defines the wire format,
commitment semantics, and Cedar integration for intent-bound
authorization.
3.4. Relationship to Mission Bound Authorization
The McGuinness Mission Bound Authorization framework
[I-D.mcguinness-oauth-mission-bound-authorization] defines how
agent missions are declared and bounded. IDP's mission_ref field
(Section 4.1) links the per-transition intent declaration to the
governing MissionDeclaration. IDP's mandate_reference field
[NEW in -05] provides the SPO URI of the governing mandate, enabling
structural validation of IDP scope against the governing mission
structure.
3.5. Event Log as Operational Intelligence
The IDP Event Log is not merely an audit artifact. It is a
structured record of agent reasoning over time -- what actions agents
declared they were taking, why, at what confidence, in what reasoning
mode. Aggregated across sessions, the IDP record is operational
intelligence about agent behaviour patterns. The data_residency
field (Section 4.1) governs which records are eligible for Tier 2
and Tier 3 analytics aggregation under the FAIP specification.
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.
"mandate_reference": string, ; OPTIONAL. [NEW in -05] SPO URI
; of the governing mandate or SO
; Type. See Section 4.2.
"mission_ref": string, ; OPTIONAL. MissionDeclaration UUID.
"endorsed_eod_id": string, ; OPTIONAL [Class 2: RECOMMENDED,
; Class 3: REQUIRED]. [NEW in -05]
; UUID of the Endorsed EOD produced
; by the intake_endorsement operation
; (Section 4.6). When absent for a
; Class 2 or Class 3 session, the
; GEC MUST log EOD_ABSENT and MAY
; apply Cedar policy restrictions.
"eod_id": string, ; OPTIONAL. UUID of the original
; (unendorsed) EOD from which
; endorsed_eod_id was produced.
"plan_b_ref": string, ; OPTIONAL. plan_b_id from the EOD
; when the session is in
; PLAN_B_ACTIVE state [AEP-02].
; REQUIRED when session_state is
; PLAN_B_ACTIVE.
"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.
},
"reasoning_basis": { ; REQUIRED.
"type": string, ; REQUIRED. See Section 4.3.
"description": string ; REQUIRED. Human-readable. Max 1000.
},
"confidence_level": number, ; REQUIRED. Float, 0.0 to 1.0.
"hem_urgency": string, ; REQUIRED. See Section 4.4.
"context_refs": [string], ; OPTIONAL. UUIDs of relevant prior.
"audit_accessible": boolean, ; OPTIONAL. Default: true.
"metadata": object, ; OPTIONAL. Implementation-defined.
"timestamp": string, ; REQUIRED. ISO 8601 UTC.
"gec_instance_id": string, ; RECOMMENDED (L2/L3: REQUIRED).
; GEC instance attestation ID.
"data_residency": { ; OPTIONAL. Analytics eligibility.
"jurisdiction": string,
"tier2_eligible": boolean,
"tier3_eligible": boolean,
"retention_days": integer,
"anonymization_delay_days": integer
},
"reasoning_mode": string ; OPTIONAL. See Section 4.3.1.
}
4.2. Field Definitions
idp_id:
A UUID v4 [RFC9562] 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.
mandate_reference: [NEW in -05]
OPTIONAL SPO URI identifying the governing mandate or SO Type for
this IDP session. SPO URI format: a URI string that resolves to
the SO Type definition or mandate document that governs this
session's scope.
When present, the GEC MUST perform structural validation of the
IDP's requested_action against the SPO identified by
mandate_reference before Cedar evaluation:
(a) The GEC MUST verify that the SPO URI is resolvable and that
the resolved document is not expired. An IDP with an SPO URI
that resolves to an expired document MUST be rejected with
deny code IDP_SPO_EXPIRED.
(b) The GEC MUST verify that the requested_action is within the
action space defined by the resolved SPO. An action not
within the SPO action space MUST be rejected with deny code
IDP_ACTION_OUTSIDE_SPO.
(c) A mandate_reference that resolves to a document that does
not define the session's so_id SO Type MUST be rejected with
deny code IDP_SPO_TYPE_MISMATCH.
When mandate_reference is absent, the GEC proceeds with normal
Cedar evaluation without SPO structural validation.
endorsed_eod_id: [NEW in -05]
OPTIONAL UUID of the Endorsed EOD produced by the
intake_endorsement operation (Section 4.6) before this session
began. For Class 2 agents, RECOMMENDED. For Class 3 agents,
REQUIRED.
When endorsed_eod_id is present, the GEC MUST verify that the
referenced Endorsed EOD exists in the Event Log, that it has not
been revoked, and that it covers the so_id and mandate_id of this
IDP. An endorsed_eod_id that does not match an Event Log
ENDORSED_EOD entry MUST result in deny code IDP_ENDORSED_EOD_INVALID.
When endorsed_eod_id is absent for a Class 3 agent, the GEC MUST
reject the IDP with deny code IDP_ENDORSED_EOD_REQUIRED.
When endorsed_eod_id is absent for a Class 2 agent, the GEC MUST
log EOD_ABSENT in the Event Log. Cedar policies MAY require
endorsed_eod_id as a permit condition for Class 2 agents on high-
risk SO Types.
eod_id:
OPTIONAL UUID of the original (unendorsed) EOD from which the
Endorsed EOD was produced. When endorsed_eod_id is present,
eod_id SHOULD also be present for full audit chain traceability.
plan_b_ref:
OPTIONAL string. The plan_b_id from the EOD (Section 6.4 of
[I-D.sato-soos-aep]) when the AEP session is in PLAN_B_ACTIVE
state. REQUIRED when the AEP session_state is PLAN_B_ACTIVE.
A Transition Request submitted in PLAN_B_ACTIVE state without
plan_b_ref MUST be rejected by the GEC per CONF-AEP-14
[I-D.sato-soos-aep].
mission_ref:
OPTIONAL. The UUID of the MissionDeclaration governing the
session. When present, MUST match the mission_ref claim in the
mandate_jwt if that claim is present.
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. When mandate_reference is present, MUST be
within the SPO action space per Section 4.2.
declared_goal:
A structured declaration of the goal the agent believes this
action serves.
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. 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 (the what_changed content required by
[I-D.sato-soos-aep] Section 10.4 MUST be reflected here), 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. This
value is self-reported. See Section 7 for calibration guidance
and the CONFIDENCE_MISCALIBRATION_WARNING trigger.
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 relevant to
reasoning. When retrying after denial, SHOULD include the
idp_ids of prior IDP_SUBMITTED events for the same action.
gec_instance_id:
The attestation identity of the receiving GEC instance per
[I-D.sato-soos-kia]. RECOMMENDED for L2/L3 implementations;
OPTIONAL for L1. When present, the GEC MUST verify this field
matches its own attested instance identifier.
reasoning_mode:
OPTIONAL string. The reasoning mode classification (Section
4.3.1). When absent, the GEC treats the IDP as ROUTINE.
data_residency:
OPTIONAL. Analytics tier eligibility per FAIP specification.
When absent, SO Type default policy applies.
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.
INFERENCE:
The agent inferred that this action is appropriate based on
contextual reasoning.
INSTRUCTION:
The agent is executing an explicit instruction from a human
principal or from a higher-authority agent in the delegation
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.
MISSION_STAGE:
The agent is executing an action to advance the governing
MissionDeclaration from one stage to the next. The mission_ref
field MUST be present when this type is used.
RETRY_CONTINUATION: [REVISED in -05]
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 -- this MUST reference specific fields identified in the
DENY enrichment response or an observable Context Package change
since the denial, consistent with the AEP-02 what_changed
requirement [I-D.sato-soos-aep] Section 10.4, and (c) why the
agent believes the revised approach will succeed.
A RETRY_CONTINUATION IDP whose description does not reference a
specific enrichment field or observable Context Package change
MUST be treated as a WHAT_CHANGED_ABSENT declaration. The GEC
MUST log a WARNING (RETRY_WHAT_CHANGED_WEAK) in the Event Log.
Cedar policies MAY apply additional restrictions to
WHAT_CHANGED_ABSENT declarations. The deny code
RETRY_WHAT_CHANGED_INVALID from AEP-02 Section 10.4 applies
when the AEP layer rejects the ACT before the IDP is committed;
RETRY_WHAT_CHANGED_WEAK is the IDP-layer signal when the ACT
is accepted but the description does not meet specificity
requirements.
The prior_denial_count Cedar context attribute (Section 5.4) is
GEC-derived; it MUST NOT be accepted as an agent-supplied field.
Implementations MAY define additional type values per IANA
registration or URI-prefixed extension.
The reasoning_basis.type field describes the epistemic basis for
action selection. The reasoning_mode field (Section 4.3.1)
describes the operational context. The two fields are orthogonal
and complement each other.
4.3.1. Reasoning Mode Values
The following values are defined for the reasoning_mode field.
ROUTINE:
The agent is executing a planned transition on a known path to
the declared goal state. SHOULD be omitted unless explicit
declaration is required; absent field is treated as ROUTINE.
PREDICTIVE:
The agent has inferred a future state from SENSE signals and is
taking preemptive action. Confidence SHOULD be in STANDARD
range (0.60--0.79) or lower; VERIFIED confidence with PREDICTIVE
MUST be flagged in uncertainty_flags.
DIAGNOSTIC:
The agent has detected an anomalous SO Instance state and is
investigating cause before selecting an action.
CHANNEL_DEGRADED:
The agent has detected reduced Context Package fidelity. Agents
declaring CHANNEL_DEGRADED MUST declare confidence_level in the
UNCERTAIN range (0.0--0.59).
META:
The agent is reasoning about its own execution process. Agents
declaring META MUST set hem_urgency to RECOMMENDED or REQUIRED.
COMPENSATING:
The agent is selecting an alternate action path following a DENY
in the prior OBSERVE step. reasoning_basis MUST use
RETRY_CONTINUATION type.
DELEGATION_AWARE:
The agent is replanning because a DELEGATION_EVENT or
CLUSTER_STATUS_CHANGE trigger changed goal achievability.
HEM_INFORMED:
The agent is re-entering REASON following an HEM_RESOLUTION
trigger. The reasoning_basis.description MUST reference the
HEM decision identifier (hem_context.decision_id).
Implementations MAY define additional values per IANA registration.
4.4. HEM Urgency Values
The hem_urgency field declares the agent's assessment of whether
human judgment should be sought.
NONE:
No human judgment needed. GEC proceeds with normal evaluation.
RECOMMENDED:
Human judgment would be beneficial but is not required.
REQUIRED:
The agent requires human judgment before this action executes.
The GEC MUST initiate HEM_PENDING for this session regardless
of Cedar evaluation outcome.
A hem_urgency of REQUIRED does not override Cedar evaluation; Cedar
still executes. However, even a Cedar PERMIT MUST NOT cause the
action to execute; the session enters HEM_PENDING.
4.5. IDP Profiles
IDP_STANDARD:
All REQUIRED fields present. confidence_level is agent-assessed.
reasoning_basis.type is one of the defined values.
IDP_THIN:
A reduced profile for agents with limited reasoning capability.
See Section 8.
The GEC MUST accept both profiles. The GEC MUST record the profile
type in the IDP Event Log entry.
4.6. Intake Endorsement Operation [NEW in -05]
The intake_endorsement operation is a GEC service that processes
a submitted EOD before session initiation, validates it against the
governing mandate and SO Type, and returns a GEC-signed Endorsed
EOD. The Endorsed EOD is the GEC's pre-session attestation that
the EOD is structurally valid, within mandate scope, and bound to
the specific SO Instance for which the session will be established.
The intake_endorsement operation is a read-write GEC interaction
that occurs between GNAP grant issuance and the first AEP SENSE
delivery. It is the bridge between the EOD submitted by the agent
and the endorsed_eod_id required in IDPs for Class 2 and Class 3
sessions.
4.6.1. Endorsement Request
The intake_endorsement request MUST include:
{
"eod": object, ; REQUIRED. Full EOD per AEP-02 S.6.2.
"mandate_jwt": string, ; REQUIRED. Root Mandate JWT for the
; session for which the EOD applies.
"principal_credential": string, ; REQUIRED. Credential of the human
; principal or operator authorizing
; the EOD. MUST be a credential
; recognized by the GEC's KIA
; configuration.
"requested_at": string, ; REQUIRED. ISO 8601 UTC.
"request_id": string ; REQUIRED. UUID v4. For idempotency.
}
The principal_credential MUST be a verifiable credential or signed
token issued by a principal recognized by the GEC's Party Registry
[I-D.sato-soos-kia]. An intake_endorsement request without a
valid principal_credential MUST be rejected with error code
INTAKE_PRINCIPAL_UNRECOGNIZED.
4.6.2. Endorsed EOD Response
On successful validation, the GEC returns an Endorsed EOD:
{
"endorsed_eod_id": string, ; REQUIRED. UUID v4. Unique
; identifier for this Endorsed EOD.
"eod_id": string, ; REQUIRED. UUID of the input EOD.
"eod_hash": string, ; REQUIRED. SHA-256 of the input EOD.
"mandate_jwt_id": string, ; REQUIRED. jti of the Mandate JWT.
"so_id_bound": string, ; REQUIRED. SO Instance UUID to which
; this Endorsed EOD is bound.
"primary_outcome_validated": boolean, ; REQUIRED. true if primary
; outcome.target_state exists in the
; SO Type state machine.
"plan_b_validated": boolean, ; REQUIRED. true if plan_b is present
; and plan_b.plan_b_target_state
; exists in SO Type state machine.
"scope_status": string, ; REQUIRED. IN_SCOPE | OUT_OF_SCOPE |
; PARTIAL_SCOPE.
"scope_detail": string, ; OPTIONAL. Human-readable detail
; when scope_status is not IN_SCOPE.
"endorsed_at": string, ; REQUIRED. ISO 8601 UTC.
"gec_signature": string ; REQUIRED. GEC Ed25519 signature
; over canonical JSON of this object.
}
When scope_status is OUT_OF_SCOPE, the GEC MUST return the Endorsed
EOD with scope_status: OUT_OF_SCOPE rather than rejecting the
request. The agent or operator MAY revise the EOD and resubmit.
A session MUST NOT begin with an Endorsed EOD whose scope_status is
OUT_OF_SCOPE.
The GEC MUST commit an ENDORSED_EOD Event Log entry upon issuing
the Endorsed EOD, before returning it to the requester. The
ENDORSED_EOD entry carries the endorsed_eod_id, eod_hash,
mandate_jwt_id, so_id_bound, and gec_signature. This entry is the
source of truth that the GEC checks when validating endorsed_eod_id
in subsequent IDPs.
4.6.3. Intake Endorsement Validation Errors
The following error codes apply to intake_endorsement operations:
INTAKE_PRINCIPAL_UNRECOGNIZED:
The principal_credential is not recognized by the GEC's Party
Registry.
INTAKE_EOD_MALFORMED:
The EOD does not conform to the AEP-02 EOD schema.
INTAKE_MANDATE_INVALID:
The mandate_jwt fails MJWT verification.
INTAKE_PRIMARY_OUTCOME_INVALID:
The EOD primary_outcome.target_state does not exist in the SO
Type's state machine.
INTAKE_PLAN_B_INVALID:
The EOD plan_b.plan_b_target_state does not exist in the SO
Type's state machine.
INTAKE_SPO_EXPIRED:
The mandate_reference SPO URI in the EOD resolves to an expired
document.
INTAKE_DUPLICATE:
A duplicate request_id is detected (idempotency signal: the
prior Endorsed EOD is returned).
4.7. PD-EOD: Prompt-Derived EOD Branch [NEW in -05]
A Prompt-Derived EOD (PD-EOD) is an EOD produced by the GEC from
a natural-language prompt submitted by the agent or operator, rather
than from a structured EOD. PD-EODs are intended for deployments
where the agent or operator cannot or does not supply a structured
EOD but where the human principal's natural-language instruction
provides sufficient information for the GEC to derive one.
PD-EODs carry a derived: true flag in the EOD structure
(Section 6.2 of [I-D.sato-soos-aep]). This flag signals to auditors
and governance reviewers that the EOD was machine-derived from a
prompt, not human-structured.
4.7.1. PD-EOD Schema
A PD-EOD is an EOD (per AEP-02 Section 6.2) with the following
additional fields:
"derived": boolean, ; REQUIRED. MUST be true for PD-EOD.
"source_prompt": string, ; REQUIRED. The natural-language
; prompt from which the EOD was
; derived. Max 2000 chars.
"derivation_model": string, ; REQUIRED. Identifier of the model
; or procedure used to derive the
; EOD from the prompt.
"derivation_confidence": number, ; REQUIRED. Float 0.0-1.0. GEC's
; confidence that the derived EOD
; accurately reflects the prompt's
; intent.
"derivation_warnings": [string] ; OPTIONAL. GEC-generated warnings
; about ambiguity, out-of-scope
; content, or unsupported claims
; in the source prompt.
4.7.2. PD-EOD Scope-Bounding Rule
A PD-EOD MUST NOT declare a primary_outcome.target_state or
plan_b.plan_b_target_state outside the action space of the SO Type
bound to the session's Mandate JWT. This constraint is normative
regardless of what the source_prompt contains.
The GEC MUST enforce the scope-bounding rule before returning a
PD-EOD. A prompt that implies an out-of-scope target state MUST
produce a PD-EOD whose scope_status is OUT_OF_SCOPE, not one that
silently clips the target to the nearest in-scope state. Silent
scope reduction changes the agent's declared intent in an
unacknowledged way; this is a governance failure.
If the GEC produces a PD-EOD with a constrained target state (i.e.,
a target that differs from what the prompt implied), the PD-EOD MUST
carry this constraint in derivation_warnings. The human principal
MUST acknowledge the constraint before the session begins.
4.7.3. PD-EOD HEM Notification Requirement
When a PD-EOD session involves touch of an external system not
referenced in the source_prompt or the SO Type's declared
interaction surface, the GEC MUST notify the human principal via
HEM [I-D.sato-soos-hem] before the first Transition Request
targeting that external system is executed.
"External system touch" for this purpose means: any Cedar action
that modifies state in a system whose identifier does not appear in
the SO Type's state machine or in the source_prompt. The threshold
is intended to catch scope expansion that was neither declared in
the prompt nor supported by the SO Type definition.
The HEM notification MUST carry:
- The PD-EOD (endorsed_eod_id reference).
- The Cedar action that would trigger external system touch.
- The external system identifier.
- A human-readable explanation of why this constitutes unplanned
external system access.
The human principal's response MUST be one of: APPROVE (session
continues, external system touch is permitted), REDIRECT_GOAL (new
goal state that does not require external system touch), or TERMINATE.
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 AEP-02 execution loop [I-D.sato-soos-aep]:
0. (PRE-SESSION) Agent submits EOD to intake_endorsement operation;
receives Endorsed EOD with endorsed_eod_id.
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 carries endorsed_eod_id from step 0.
5. (OBSERVE) Agent receives PERMIT, enriched DENY, HEM_PENDING,
or STALLED response.
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 against mandate_jwt.
(h) If mandate_reference is present, perform SPO structural
validation per Section 4.2. [NEW in -05]
(i) If endorsed_eod_id is present, validate against the
ENDORSED_EOD Event Log entry per Section 4.2. [NEW in -05]
If endorsed_eod_id is absent and agent_class is CLASS_3,
return REJECT with error code IDP_ENDORSED_EOD_REQUIRED.
(j) If session_state is PLAN_B_ACTIVE and plan_b_ref is absent,
return REJECT with error code IDP_PLAN_B_REF_REQUIRED.
[NEW in -05]
(k) If reasoning_basis.type is RETRY_CONTINUATION, validate
what_changed specificity per Section 4.3. Log
RETRY_WHAT_CHANGED_WEAK if description lacks specificity.
(l) If reasoning_basis.type is RETRY_CONTINUATION and context_refs
contains no reference to a prior IDP_SUBMITTED event for the
same requested_action, log WARNING (RETRY_WITHOUT_PRIOR_REF).
GEC validation of the IDP precedes Cedar evaluation.
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.
* The mandate_id and session_id.
* The audit_accessible value (defaults to true if absent).
* The GEC-derived prior_denial_count for the requested_action.
* The endorsed_eod_id if present. [NEW in -05]
* The GEC signature over the event.
The Event Log ordering guarantee:
IDP_SUBMITTED < Cedar evaluation < STATE_TRANSITIONED
(or CEDAR_DENY_RECORDED) < ACTION_RESULT_RECORDED
< IDP_COMMITMENT_VERIFIED (or IDP_COMMITMENT_GAP)
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 GEC MUST make the following IDP fields available as Cedar
context attributes during policy evaluation:
* idp.reasoning_basis.type -- string
* idp.confidence_level -- number
* idp.hem_urgency -- string
* idp.reasoning_mode -- string (ROUTINE when absent)
* idp.prior_denial_count -- integer (GEC-derived from Event Log)
* idp.has_endorsed_eod -- boolean [NEW in -05]
* idp.eod_scope_status -- string (IN_SCOPE/OUT_OF_SCOPE/
PARTIAL_SCOPE from Endorsed EOD)
[NEW in -05]
* idp.plan_b_active -- boolean [NEW in -05]
* idp.mandate_reference_valid -- boolean (true if SPO validation
passed, false or absent if not
evaluated) [NEW in -05]
* idp.miscalibration_score -- number (Section 7.2) [NEW in -05]
Cedar policies MAY gate on any of these attributes.
5.5. IDP Commitment Verification
Following every STATE_TRANSITIONED event, the GEC MUST generate
an IDP_COMMITMENT_VERIFIED or IDP_COMMITMENT_GAP event per the
IDP Commitment Verification mechanism. This mechanism verifies
that the agent's actual action matches its declared intent.
5.5.1. IDP Commitment Verification Record Schema
{
"verification_id": string, ; UUID v4.
"idp_id": string, ; idp_id of the verified IDP.
"transition_event": string, ; event_id of STATE_TRANSITIONED.
"match_result": string, ; MATCH | MISMATCH | PARTIAL_MATCH.
"verified_at": string, ; ISO 8601 UTC.
"gec_signature": string ; GEC signature.
}
5.5.2. Event Log Entries
IDP_COMMITMENT_VERIFIED:
Emitted when the committed action matches the declared intent.
Carries verification_id and match_result: MATCH.
IDP_COMMITMENT_GAP:
Emitted when the committed action does not match the declared
intent. Carries verification_id and match_result: MISMATCH
or PARTIAL_MATCH. The GEC MUST generate a WARNING Audit
Alert for MISMATCH. PARTIAL_MATCH is informational only.
5.5.3. Commitment Verification Scope
Commitment verification compares:
- The requested_action in the committed IDP_SUBMITTED event.
- The action field in the subsequent STATE_TRANSITIONED event.
A match is exact string equality. Partial match is where the
two actions are in the same Cedar namespace but differ in
specificity (e.g., "atp:booking:*" vs "atp:booking:confirm").
5.5.4. Relationship to GAR
IDP_COMMITMENT_VERIFIED and IDP_COMMITMENT_GAP events are recorded
in the SO Instance Event Stream [I-D.sato-soos-gar]. GAR includes
the commitment verification result in the Session Audit Record.
5.6. Outcome Event Log Entries
After the GEC processes a Transition Request and returns a result,
three outcome Event Log entries MUST be generated in order.
5.6.1. STATE_TRANSITIONED
Emitted when a transition is permitted and executed.
{
"event_type": "STATE_TRANSITIONED",
"event_id": string, ; UUID v4.
"idp_id": string, ; idp_id of the corresponding IDP.
"from_state": string, ; SO state before transition.
"to_state": string, ; SO state after transition.
"cedar_action": string, ; Cedar action executed.
"transition_at": string, ; ISO 8601 UTC.
"gec_signature": string
}
5.6.2. CEDAR_DENY_RECORDED
Emitted when Cedar evaluation returns DENY.
{
"event_type": "CEDAR_DENY_RECORDED",
"event_id": string,
"idp_id": string,
"deny_code": string,
"deny_reason": string,
"denied_at": string,
"prior_denial_count": integer,
"gec_signature": string
}
5.6.3. ACTION_RESULT_RECORDED
Emitted after STATE_TRANSITIONED (or CEDAR_DENY_RECORDED) as
the operational outcome record.
{
"event_type": "ACTION_RESULT_RECORDED",
"event_id": string,
"idp_id": string,
"result": string, ; PERMIT | DENY | HEM_PENDING | STALLED.
"result_detail": string,
"recorded_at": string,
"gec_signature": string
}
5.6.4. Complete Audit Trail Example
For a PERMIT transition:
1. IDP_SUBMITTED (idp_id: IDP-001, step_sequence: 1)
2. STATE_TRANSITIONED (from: CONFIRMED, to: PRE_ACTIVITY)
3. ACTION_RESULT_RECORDED (result: PERMIT)
4. IDP_COMMITMENT_VERIFIED (match_result: MATCH)
For a DENY:
1. IDP_SUBMITTED (idp_id: IDP-002, step_sequence: 2)
2. CEDAR_DENY_RECORDED (deny_code: POLICY_DENY, prior_denial_count: 1)
3. ACTION_RESULT_RECORDED (result: DENY)
6. Enriched DENY Response
6.1. Structure
When Cedar evaluation results in DENY, the GEC MUST return an
Enriched DENY Response to the agent.
{
"deny_code": string, ; REQUIRED. See Section 13 registry.
"deny_reason": string, ; REQUIRED. Human-readable.
"idp_echo": object, ; REQUIRED. The submitted IDP.
"available_actions": [string], ; RECOMMENDED. Cedar actions
; available in current SO state.
"suggested_paths": [object], ; OPTIONAL. Alternate action paths.
"enrichment": object, ; REQUIRED. IDP fields that, if
; changed, would produce PERMIT.
"prior_denial_count": integer, ; REQUIRED. [REVISED in -05]
; Total denials for this action
; in this session. Also exposed
; as Cedar context attribute.
"last_deny_code": string, ; RECOMMENDED. [NEW in -05]
"what_changed_guidance": string ; RECOMMENDED. [NEW in -05]
; Human-readable guidance on what
; must change for the next
; RETRY_CONTINUATION to be specific
; enough. References enrichment
; fields by name.
}
6.2. Field Definitions
deny_code:
One of the IDP Deny Codes registered in Section 13.
deny_reason:
A human-readable explanation of why the action was denied.
MUST be informative without revealing exploitable policy
structure (Section 9.3).
idp_echo:
The full submitted IDP. Enables the agent to see exactly what
was committed before constructing its next IDP.
available_actions:
RECOMMENDED array of Cedar action strings available in the
current SO state. This is the primary mechanism by which the
GEC guides the agent's next REASON step away from the denied
action and toward viable alternatives.
enrichment:
REQUIRED object carrying the specific IDP fields whose values,
if changed, would produce a PERMIT at the same Cedar policy set.
This is the structured basis for the RETRY_CONTINUATION
reasoning_basis.description requirement in Section 4.3.
prior_denial_count:
REQUIRED. The total count of DENY responses for this
cedar_action in this session. Also exposed as Cedar context
attribute idp.prior_denial_count at subsequent ACT steps.
what_changed_guidance: [NEW in -05]
RECOMMENDED. GEC-generated guidance on what must be different
in the next RETRY_CONTINUATION IDP for it to meet the
specificity requirement of Section 4.3. MUST reference specific
enrichment field names. Example: "The next retry must change
reasoning_basis.description to reference enrichment.confidence_
level_required: 0.75 or above."
6.3. HEM Routing from DENY
When the deny_code is RETRY_LIMIT_EXCEEDED (prior_denial_count at
the Cedar policy threshold), the GEC MUST initiate HEM_PENDING.
The HEM escalation carries the full Enriched DENY Response as the
trigger context.
7. Confidence Level Calibration Guidance [NEW in -05]
7.1. Calibration Obligations
The confidence_level field is self-reported by the agent. The GEC
cannot verify it at submission time. However, over a session or
across sessions, the GEC CAN detect systematic miscalibration: an
agent that consistently declares VERIFIED confidence (0.90--1.00)
but receives DENY or HEM_PENDING on a significant fraction of its
IDPs is systematically overconfident. An agent that consistently
declares UNCERTAIN confidence (0.0--0.59) on routine transitions is
systematically underconfident.
Both patterns are governance signals. Overconfidence may indicate
an agent attempting to bypass Cedar policies that gate on confidence
level. Underconfidence may indicate an agent gaming the HEM
escalation trigger to force human review on every transition.
Agents SHOULD calibrate confidence_level to reflect actual
outcome distribution over their operating history. The
Progressive Trust model [I-D.sato-soos-pt] uses the relationship
between declared confidence and actual outcomes as a behavioral
dimension (the Precision Score).
7.2. CONFIDENCE_MISCALIBRATION_WARNING Trigger
The GEC MUST emit a CONFIDENCE_MISCALIBRATION_WARNING Event Log
entry when the following condition is met:
Within any window of 10 or more IDPs from the same session or
agent (computed across sessions when cross-session analytics are
enabled), the ratio of IDPs declaring confidence_level >= 0.80
(HIGH or VERIFIED) to IDPs that received DENY or HEM_PENDING is
greater than a configurable threshold (default: 0.40).
Interpretation: more than 40% of the agent's high-confidence
declarations resulted in DENY or HEM_PENDING. This is a systematic
miscalibration signal.
The CONFIDENCE_MISCALIBRATION_WARNING entry:
{
"event_type": "CONFIDENCE_MISCALIBRATION_WARNING",
"event_id": string,
"agent_id": string,
"session_id": string, ; or null for cross-session.
"window_size": integer, ; IDP count in the window.
"high_conf_count": integer, ; IDPs with confidence >= 0.80.
"deny_hem_count": integer, ; DENYs + HEM_PENDINGs in window.
"ratio": number, ; deny_hem_count / high_conf_count.
"threshold": number, ; Configured threshold.
"occurred_at": string, ; ISO 8601 UTC.
"gec_signature": string
}
CONFIDENCE_MISCALIBRATION_WARNING MUST be made available as a Cedar
context attribute:
context.agent_miscalibration_active: boolean (true when the most
recent window produced a CONFIDENCE_MISCALIBRATION_WARNING)
Cedar policies MAY gate on agent_miscalibration_active to apply
additional scrutiny or mandatory HEM escalation.
7.3. Correction Mechanism
When a CONFIDENCE_MISCALIBRATION_WARNING is emitted, the GEC SHOULD:
(a) Notify the human principal via HEM with urgency ADVISORY.
The HEM notification MUST include the miscalibration ratio and
the window period.
(b) Make the CONFIDENCE_MISCALIBRATION_WARNING available as a
session annotation visible in the GEC administrative interface.
(c) If configured, apply a Cedar policy adjustment that increases
the hem_urgency threshold for this agent's sessions until the
miscalibration window clears.
The correction mechanism MUST NOT automatically reduce the agent's
confidence_level declarations. The confidence_level field is
the agent's self-report; the GEC records and detects miscalibration
but does not alter the agent's declared values.
8. IDP Thin Profile
The IDP_THIN profile is a reduced profile for agents with limited
reasoning capability. IDP_THIN submissions provide reduced
accountability because the reasoning record is minimal.
IDP_THIN MUST include:
- idp_id, session_id, so_id, mandate_id, step_sequence,
requested_action, hem_urgency, timestamp.
IDP_THIN MUST NOT include:
- reasoning_basis.type: RETRY_CONTINUATION.
High-value or high-risk transitions SHOULD require IDP_STANDARD
submissions. SO Type designers SHOULD use the IDP_THIN_NOT_ACCEPTED
mechanism for transitions where reasoning accountability is critical.
The endorsed_eod_id and plan_b_ref fields are not required in
IDP_THIN. However, if a PD-EOD was used to initiate the session,
the endorsed_eod_id SHOULD be included in IDP_THIN submissions.
9. Security Considerations
9.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 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.
9.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.
9.3. Inference from Denials
The Enriched DENY Response reveals information about permitted
actions and authorization policy structure. The what_changed_
guidance field [NEW in -05] carries specific enrichment field names;
implementations MUST ensure that what_changed_guidance does not
reveal policy thresholds or conditions that would enable adversarial
policy reverse-engineering. Guidance MUST be specific enough to
enable genuine retry without exposing Cedar policy internals.
9.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, rebuilt from the Event Log
on GEC restart.
9.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 per [I-D.mcguinness-oauth-actor-profile].
9.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. IDP_THIN MUST NOT carry
RETRY_CONTINUATION reasoning basis type (Section 8).
9.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.
9.8. Retry Loop Exhaustion Attacks
An adversarial agent may attempt to exhaust system resources by
submitting continuous RETRY_CONTINUATION IDPs against a denied
action. 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. The AEP-02
STALLED state (Section 5.4 of [I-D.sato-soos-aep]) provides an
additional bound: the STALL_DENY_THRESHOLD terminates the retry
sequence before budget exhaustion.
9.9. Cross-Context Replay
A valid IDP from session S1 may be replayed in session S2 if the
IDP does not include session-binding claims sufficient to bind the
declaration to a specific execution context. Mitigation: IDP MUST
include session_id, which the GEC MUST verify matches the active
session. IDPs with mismatched session_id MUST be rejected with
error code IDP_SESSION_MISMATCH. For L2/L3 implementations,
gec_instance_id provides an additional binding.
Reference: OpenID Foundation, "Responsible Disclosure Notice on
Security Vulnerability for private_key_jwt", January 2025
[OIDF-2025-01].
9.10. Agent Session Revocation
When an agent session is revoked, this document's protocol
obligations are superseded by the MAD session revocation procedure
[I-D.sato-soos-mad] Section 3.6. IDPs submitted after session
revocation MUST be rejected with IDP_SESSION_REVOKED. All in-
flight Commitment Verification records at revocation MUST be
finalized with completion_state PARTIAL or CLEAN.
9.11. Prompt Injection at Intake [NEW in -05]
The intake_endorsement operation (Section 4.6) processes a
natural-language source_prompt to derive PD-EODs (Section 4.7).
An adversary who can influence the content of the source_prompt
may attempt to inject instructions that cause the GEC to endorse
an EOD with a broader scope or more permissive outcome than the
human principal intended.
Attack vectors:
(a) Scope expansion injection. The source_prompt contains embedded
instructions (e.g., "also authorize access to [system]") that
are processed as PD-EOD scope declarations rather than as
natural-language content to be bounded. The PD-EOD produced
includes the injected scope claim.
(b) Confidence manipulation. The source_prompt includes language
asserting high certainty ("I am authorized to...") that
influences the derivation_confidence assigned to the PD-EOD,
causing the GEC to produce an Endorsed EOD with higher
derivation_confidence than the prompt's substantive content
warrants.
(c) Plan B poisoning. The source_prompt includes embedded plan B
instructions that declare a fallback to a broader-scope action
than the primary outcome, causing the endorsed Plan B to have
a wider blast radius than the primary path.
Mitigations:
(i) The scope-bounding rule (Section 4.7.2) is the primary
mitigation: the PD-EOD MUST NOT declare a target state outside
the SO Type's state machine, regardless of what the prompt
contains. Scope injection that targets states outside the
SO Type is structurally non-exploitable.
(ii) The GEC MUST treat the source_prompt as untrusted natural-
language input. Implementations MUST NOT evaluate source_prompt
content as policy instructions. The derivation process MUST
extract goal-relevant information from the prompt using a model
or procedure that is separate from the GEC's Cedar evaluation
engine.
(iii) derivation_warnings (Section 4.7.1) MUST flag any prompt
content that was excluded from the PD-EOD because it was
outside the SO Type's action space or outside the mandate's
Cedar scope. The human principal review of derivation_warnings
is the human-in-the-loop check on prompt injection attempts.
(iv) The human principal's acknowledgment of the PD-EOD
(required before session begins) is the final gate.
9.12. EOD Scope Manipulation [NEW in -05]
The Endorsed EOD (Section 4.6) commits the agent's expected
outcome before the first SENSE delivery. An adversary who can
modify the EOD between the intake_endorsement operation and the
session start (or who can cause the GEC to endorse a manipulated
EOD) gains the ability to mismatch the governing pre-commitment
from the agent's actual declared intent.
Attack vectors:
(a) EOD substitution. An adversary with network access to the
intake_endorsement response modifies the Endorsed EOD in transit,
changing the primary_outcome.target_state to a more permissive
state before the session receives it.
(b) endorsed_eod_id forgery. An adversary supplies a fabricated
endorsed_eod_id in the IDP, referencing an Endorsed EOD that
was never actually produced by the GEC.
Mitigations:
(i) The Endorsed EOD is GEC-signed (gec_signature in Section 4.6.2).
An adversary who modifies the Endorsed EOD in transit invalidates
the GEC signature. IDP validation at step (i) of Section 5.2
verifies the Endorsed EOD exists in the Event Log, not merely
in the agent-supplied IDP field.
(ii) The ENDORSED_EOD Event Log entry (Section 4.6.2) is the source
of truth. endorsed_eod_id validation checks the Event Log;
a fabricated endorsed_eod_id that does not match an Event Log
entry MUST result in IDP_ENDORSED_EOD_INVALID.
(iii) Transport of the Endorsed EOD from GEC to agent MUST use
GEC-authenticated TLS. Implementations MUST NOT transmit
Endorsed EODs over unauthenticated channels.
9.13. Confidence Level Inflation Attack [NEW in -05]
A malicious agent may systematically declare VERIFIED confidence
(0.90--1.00) to exploit Cedar policies that grant elevated
permissions to high-confidence IDPs. By inflating its declared
confidence, the agent attempts to bypass Cedar policy restrictions
that would apply at lower confidence levels.
Mitigation:
(a) The CONFIDENCE_MISCALIBRATION_WARNING trigger (Section 7.2) is
the primary detection mechanism. Systematic high-confidence
declarations followed by DENYs or HEM_PENDINGs are detectable
within a 10-IDP window.
(b) The idp.miscalibration_score Cedar context attribute (Section
5.4) enables Cedar policies to reduce the governance weight of
declared confidence_level when systematic miscalibration is
detected. Cedar policies SHOULD apply elevated scrutiny to
agents whose agent_miscalibration_active is true.
(c) The Progressive Trust model [I-D.sato-soos-pt] uses the
relationship between declared confidence and outcomes as a
Precision Score behavioral dimension. Sustained inflation
degrades the agent's PT score over time, reducing its
autonomous authority.
Implementations MUST NOT use the declared confidence_level as the
sole basis for elevated-privilege Cedar permits. Cedar policies
SHOULD combine confidence_level with PT score, prior_denial_count,
and agent_miscalibration_active to make autonomous-privilege
decisions robust to inflation.
9.14. COMMITMENT_GAP Exploitation [NEW in -05]
An IDP_COMMITMENT_GAP event (Section 5.5.2) indicates that the
agent's executed action did not match its declared intent. A
sophisticated adversary may attempt to exploit the COMMITMENT_GAP
mechanism as a confusion vector: by deliberately submitting IDPs
whose requested_action is close-but-not-equal to the action the
agent intends to execute, the adversary creates a pattern of
PARTIAL_MATCH events that obscures intentional mismatch within
noise.
Attack vectors:
(a) PARTIAL_MATCH flooding. An agent submits IDPs with
requested_action values in the same Cedar namespace as the
actual actions (e.g., "atp:booking:*" while executing
"atp:booking:cancel") to produce a consistent PARTIAL_MATCH
pattern that suppresses MISMATCH detection.
(b) Timing exploitation. In high-throughput deployments, the
adversary exploits the gap between IDP_SUBMITTED and
IDP_COMMITMENT_VERIFIED to execute an action inconsistent with
the IDP before the verification event is committed.
Mitigations:
(i) The IDP Commitment Verification Record (Section 5.5.1) is
GEC-generated and GEC-signed at transition time. The comparison
uses exact string equality for MATCH; namespace-only overlap
produces PARTIAL_MATCH, which carries a WARNING distinct from
MISMATCH. PARTIAL_MATCH patterns above a frequency threshold
MUST generate a KERNEL_AUDIT_ANOMALY alert.
(ii) Implementations MUST use requested_action as an exact Cedar
action string in the IDP. Wildcard requested_action values
(e.g., "atp:booking:*") MUST be rejected with IDP_MALFORMED,
as they are not valid Cedar action strings.
(iii) The timing gap mitigation is ACT atomicity (Section 9.2 of
[I-D.sato-soos-aep]): the GEC execution sequence does not
return a result to the agent until IDP_SUBMITTED and
STATE_TRANSITIONED (or CEDAR_DENY_RECORDED) are both committed.
An action cannot succeed without the corresponding commitment.
10. Conformance Levels
10.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 GEC and in the resulting non-suppressibility guarantee.
Level 1 -- Application Profile:
GEC as library or middleware. Non-suppressibility is
probabilistic. Compensated by SCITT corroboration.
Level 2 -- Isolated Profile:
GEC as separate process or sidecar. Signing key inaccessible
to agent process. Non-suppressibility is architectural.
Level 3 -- Kernel Profile:
GEC in a RATS-attested TEE. Signing key bound to TEE via RATS.
Non-suppressibility is hardware-enforced.
10.2. Level 1 -- Application Profile
The Application Profile is the entry-level conformance tier. 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 before the governed action
executes.
(b) Return an Enriched DENY Response for all DENY outcomes.
(c) Implement the IDP Commitment Verification mechanism
(Section 5.5).
(d) Support the intake_endorsement operation (Section 4.6) for
Class 2 and Class 3 sessions. [NEW in -05]
Level 1 implementations SHOULD:
(e) Submit IDP records to a SCITT transparency log.
(f) Emit CONFIDENCE_MISCALIBRATION_WARNING events (Section 7.2)
based on in-session window analysis. [NEW in -05]
10.3. Level 2 -- Isolated Profile
Level 2 adds architectural non-suppressibility. The GEC signing
key is inaccessible to the agent process.
Level 2 GEC implementations MUST meet all Level 1 requirements plus:
(a) Implement the GEC as a separate process or container with
software-enforced isolation from the agent process.
(b) Include gec_instance_id in all IDP records.
(c) Validate gec_instance_id in incoming IDPs.
(d) Emit CONFIDENCE_MISCALIBRATION_WARNING events across sessions
within the GEC's configured analytics window. [NEW in -05]
10.4. Level 3 -- Kernel Profile
Level 3 provides hardware-enforced non-suppressibility.
Level 3 GEC implementations MUST meet all Level 2 requirements plus:
(a) Run in a RATS-attested hardware execution environment
[I-D.ietf-rats-architecture].
(b) Bind the GEC signing key to the TEE via RATS attestation.
(c) Emit CONFIDENCE_MISCALIBRATION_WARNING events with cross-
session analytics when the GEC's attestation boundary covers
multiple sessions. [NEW in -05]
10.5. Regulatory Applicability
The three conformance levels map to EU AI Act Article 9 risk
classifications:
- Level 1: Appropriate for limited-risk AI systems.
- Level 2: Appropriate for high-risk AI systems under Article 9
where hardware attestation is not operationally feasible.
- Level 3: Required for high-risk AI systems under Article 9
where hardware attestation is available.
Level 3 + endorsed_eod_id [NEW in -05]: For Class 3 agents
operating at Level 3 conformance with an Endorsed EOD, the
combination of pre-session commitment (Endorsed EOD), per-transition
commitment (IDP), hardware non-suppressibility (Level 3), and
commitment verification (Section 5.5) constitutes a complete EU AI
Act Article 9 technical risk management record.
10.6. Conformance Level Signalling
The GEC MUST signal its conformance level in the GEC Manifest
[I-D.sato-soos-kia]. Agents MAY query the GEC Manifest to
determine the conformance level before session initiation.
SO Type definitions MAY declare a minimum GEC conformance level
required for sessions on that SO Type. A session initiated by a
GEC whose conformance level is below the SO Type minimum MUST be
rejected with deny code GEC_LEVEL_INSUFFICIENT.
11. Privacy Considerations
The IDP contains the agent's declared goal description (Section 4.1,
declared_goal.description). Implementations MUST ensure that
declared_goal.description does not contain personally identifiable
information. The GEC SHOULD validate this field against a PII
detection policy before committing the IDP_SUBMITTED entry.
The source_prompt in a PD-EOD (Section 4.7) may contain personal
information included by the operator or human principal in the
natural-language prompt. GEC implementations MUST apply the same
PII constraints to source_prompt as to declared_goal.description.
The derivation process MUST NOT propagate PII from source_prompt
into derived PD-EOD fields. [NEW in -05]
The data_residency field (Section 4.1) governs which IDP records
are eligible for Tier 2 and Tier 3 analytics aggregation. When
data_residency is absent, the GEC MUST apply the SO Type's default
residency policy.
The Endorsed EOD (Section 4.6) contains the primary_outcome and
plan_b fields from the EOD. These fields reveal the human
principal's intentions for the SO Instance. Access to Endorsed EOD
records MUST be controlled by Cedar policy and MUST be subject to
the same access controls as the IDP records for the session.
[NEW in -05]
12. EU AI Act Applicability
The IDP is the Article 12 audit artifact at the action level. For
each governed action: the Endorsed EOD provides pre-session
commitment (new in -05), the IDP provides the per-transition intent
declaration (pre-action), the Cedar evaluation result and
Commitment Verification provide the governance decision, and the
Outcome Event Log entries provide the post-action record.
The full audit chain -- Endorsed EOD -> IDP_SUBMITTED -> Cedar result
-> STATE_TRANSITIONED or CEDAR_DENY_RECORDED -> IDP_COMMITMENT_VERIFIED
-- is the Article 12 record for a single governed transition. The
pre-action/post-action pair is GEC-signed and non-suppressible at
the conformance level appropriate to the Article 9 risk class.
The CONFIDENCE_MISCALIBRATION_WARNING (Section 7.2) provides the
Article 9 "monitoring throughout the lifecycle" signal for confidence
calibration drift. [NEW in -05]
13. IANA Considerations
This document requests the creation of the following IANA registries
(extending the IDP-04 registries with new entries).
IDP Reasoning Basis Types Registry:
Initial values: as in IDP-04.
New entry in -05:
No new reasoning basis types are added in -05. The RETRY_
CONTINUATION type is revised (normative requirement for
what_changed specificity; cross-reference to AEP-02 Section 10.4).
The revision does not add a new registry entry; it narrows the
existing entry's normative requirements.
IDP Deny Codes Registry:
Initial values: as in IDP-04, plus the following additions in -05:
+--------------------------------+--------------------------------+
| Deny Code | Description |
+--------------------------------+--------------------------------+
| IDP_ENDORSED_EOD_REQUIRED | Class 3 agent submitted IDP |
| | without endorsed_eod_id; |
| | Endorsed EOD is required |
| IDP_ENDORSED_EOD_INVALID | endorsed_eod_id not found in |
| | Event Log or GEC signature |
| | invalid |
| IDP_PLAN_B_REF_REQUIRED | Session in PLAN_B_ACTIVE state |
| | but plan_b_ref absent |
| IDP_SPO_EXPIRED | mandate_reference SPO URI |
| | resolves to expired document |
| IDP_ACTION_OUTSIDE_SPO | requested_action not in SPO |
| | action space |
| IDP_SPO_TYPE_MISMATCH | mandate_reference SPO does |
| | not cover session so_id type |
| INTAKE_PRINCIPAL_UNRECOGNIZED | intake_endorsement principal |
| | credential not recognized |
| INTAKE_EOD_MALFORMED | EOD does not conform to schema |
| INTAKE_MANDATE_INVALID | Mandate JWT fails verification |
| INTAKE_PRIMARY_OUTCOME_INVALID | primary_outcome.target_state |
| | not in SO Type state machine |
| INTAKE_PLAN_B_INVALID | plan_b.plan_b_target_state |
| | not in SO Type state machine |
| INTAKE_SPO_EXPIRED | mandate_reference in EOD |
| | resolves to expired SPO |
| INTAKE_DUPLICATE | Duplicate request_id; |
| | prior Endorsed EOD returned |
| RETRY_WHAT_CHANGED_WEAK | RETRY_CONTINUATION description |
| | lacks specificity (IDP-layer |
| | signal; warning, not reject) |
+--------------------------------+--------------------------------+
IDP Reasoning Mode Values Registry:
Initial values: as in IDP-04. No new reasoning mode values in -05.
IDP Operation Code Registry: [NEW in -05]
Registry name: IDP Operation Codes
Registration procedure: Specification Required [RFC8126]
Initial registrations:
+----------------------+------------------------------------------+
| Operation Code | Description |
+----------------------+------------------------------------------+
| intake_endorsement | GEC operation to endorse a submitted EOD |
| | before session initiation. Input: |
| | EOD + principal_credential. Output: |
| | Endorsed EOD with gec_signature and |
| | endorsed_eod_id. See Section 4.6. |
+----------------------+------------------------------------------+
PD-EOD Derivation Flag Registry: [NEW in -05]
Registry name: IDP PD-EOD Derivation Flags
Registration procedure: Specification Required [RFC8126]
Initial registrations:
+------------------------+----------------------------------------+
| Flag | Description |
+------------------------+----------------------------------------+
| derived | boolean. When true, EOD was derived |
| | from a natural-language prompt. See |
| | Section 4.7. |
+------------------------+----------------------------------------+
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC9562] Davis, B., Peabody, C., and P. Leach, "Universally
Unique IDentifiers (UUIDs)", RFC 9562, May 2024.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Token (JWT)", RFC 7519, May 2015.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, June 2017.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
[Cedar] Amazon Web Services, "Cedar Policy Language",
<https://www.cedarpolicy.com/>.
[I-D.sato-soos-aep]
Sato, T., "The Agent Execution Protocol (AEP) for
Agentic AI Systems", draft-sato-soos-aep-02, July 2026.
[I-D.sato-soos-hem]
Sato, T., "The Human Escalation Mechanism (HEM) for
Agentic AI Systems", draft-sato-soos-hem-05, July 2026.
[I-D.sato-soos-kia]
Sato, T., "Kernel Identity Architecture (KIA) for
Agentic AI Systems", draft-sato-soos-kia-03, July 2026.
[OIDF-2025-01]
OpenID Foundation, "Responsible Disclosure Notice on
Security Vulnerability for private_key_jwt", January 2025.
14.2. Informative References
[EUAIA] European Union, "Regulation (EU) 2024/1689 of the
European Parliament and of the Council (Artificial
Intelligence Act)", 12 July 2024.
[I-D.ietf-wimse-arch]
Salowey, J., et al., "WIMSE Architecture",
draft-ietf-wimse-arch, work in progress.
[I-D.ietf-oauth-v2-1]
Hardt, D., Parecki, A., and T. Lodderstedt, "OAuth
2.1 Authorization Framework", work in progress.
[I-D.rosenberg-oauth-aauth]
Rosenberg, J., "Agent Authentication (AAuth)",
work in progress.
[I-D.klrc-aiagent-auth]
Kasselman, P., et al., "AI Agent Authentication and
Authorization", draft-klrc-aiagent-auth-01, 2026.
[I-D.rosenberg-aiproto-cheq]
Rosenberg, J., White, P., and C. Jennings, "CHEQ",
draft-rosenberg-aiproto-cheq-00, 2025.
[I-D.sato-soos-gar]
Sato, T., "The Governance Audit Record (GAR) for
Agentic AI Systems", draft-sato-soos-gar-03, July 2026.
[I-D.sato-soos-pt]
Sato, T., "Progressive Trust (PT) for Agentic AI
Systems", draft-sato-soos-pt-02, May 2026.
[I-D.sato-soos-mad]
Sato, T., "Multi-Agent Delegation (MAD) for Agentic
AI Systems", draft-sato-soos-mad-03, June 2026.
[I-D.mcguinness-oauth-actor-profile]
McGuinness, K., "OAuth Actor Profile for AI Agents",
draft-mcguinness-oauth-actor-profile-00, 2026.
[I-D.mcguinness-oauth-mission-bound-authorization]
McGuinness, K., "Mission Bound Authorization",
draft-mcguinness-oauth-mission-bound-authorization-00,
2026.
[I-D.ietf-rats-architecture]
Birkholz, H., et al., "Remote ATtestation procedureS
(RATS) Architecture", RFC 9334, January 2023.
Author's Address
Tom Sato
MyAuberge K.K.
Chino, Nagano, Japan
Email: tomsato@myauberge.jp
URI: https://soosproject.ai/drafts/idp