Network Working Group I. Vandoulas Internet-Draft Mechapiens Intended status: Informational 20 July 2026 Expires: 20 January 2027 Agent Interaction & Delegation Protocol (AIDP) draft-vandoulas-aidp-03 Abstract This document specifies the Agent Interaction & Delegation Protocol (AIDP), a control-plane protocol for secure, auditable, and interoperable software agents. AIDP defines standardized mechanisms for expressing intent, enforcing authority, delegating capabilities, executing actions, and binding execution results to agent reasoning across heterogeneous systems and administrative domains. This version introduces a normative Intent Lifecycle Model, including Human Approval Gates and support for long-running agent executions, defines version negotiation and capability discovery, clarifies the relationship of AIDP to the Model Context Protocol (MCP) and the Agent2Agent (A2A) protocol, and establishes extensibility registries. Non-normative deployment material has been moved to informative appendices. 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." License Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Vandoulas Expires 15 January 2027 [Page 1] Internet-Draft AIDP July 2026 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. Vandoulas Expires 15 January 2027 [Page 2] Internet-Draft AIDP July 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Why AIDP Exists . . . . . . . . . . . . . . . . . . . . 4 1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 6 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 7 4. Relation to Existing Work . . . . . . . . . . . . . . . . . . 8 4.1. GNAP . . . . . . . . . . . . . . . . . . . . . . . . . 2 4.2. OAuth 2.0 Rich Authorization Requests . . . . . . . . . 2 4.3. Capability-Based Authorization (ZCAPs and UCAN) . . . . 2 4.4. Identity Management and SCIM . . . . . . . . . . . . . 2 4.5. Relationship to the Model Context Protocol (MCP) . . . 2 4.6. Relationship to the Agent2Agent Protocol (A2A) . . . . 2 4.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . 2 5. Agent Identity Model . . . . . . . . . . . . . . . . . . . . 11 6. Authority & Capability Model . . . . . . . . . . . . . . . . 12 7. Intent Envelope . . . . . . . . . . . . . . . . . . . . . . . 13 8. Intent Lifecycle Model . . . . . . . . . . . . . . . . . . . 14 8.1. Lifecycle States . . . . . . . . . . . . . . . . . . . 15 8.2. State Transition Rules . . . . . . . . . . . . . . . . 15 8.3. Human Approval Gates . . . . . . . . . . . . . . . . . 16 8.4. Long-Running and Multi-Step Execution . . . . . . . . 18 8.5. Lifecycle Observations . . . . . . . . . . . . . . . . 19 9. Execution Model . . . . . . . . . . . . . . . . . . . . . . . 19 10. Observation & Feedback Binding . . . . . . . . . . . . . . . 20 11. Multi-Agent Interaction . . . . . . . . . . . . . . . . . . 21 12. Version Negotiation . . . . . . . . . . . . . . . . . . . . 22 13. Capability Discovery . . . . . . . . . . . . . . . . . . . . 23 14. Wire Format . . . . . . . . . . . . . . . . . . . . . . . . 23 15. Message Schemas . . . . . . . . . . . . . . . . . . . . . . 25 16. HTTP Transport Binding (AIDP-HTTP) . . . . . . . . . . . . . 29 17. Security Considerations . . . . . . . . . . . . . . . . . . 41 18. Governance & Compliance Considerations . . . . . . . . . . . 48 19. Extensibility Model . . . . . . . . . . . . . . . . . . . . 48 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . 49 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 Appendix A. Example Wire Messages (Informative) . . . . . . . . 52 Appendix B. Example Flows (Informative) . . . . . . . . . . . . 56 Appendix C. End-to-End Agentic Use Case (Informative) . . . . . 58 Appendix D. Reference Architecture (Informative) . . . . . . . . 60 Appendix E. Conformance Test Suite Outline (Informative) . . . . 63 Appendix F. Changes Since Previous Versions . . . . . . . . . . 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 Vandoulas Expires 15 January 2027 [Page 3] Internet-Draft AIDP July 2026 1. Introduction 1.1 Motivation Recent advances in Large Language Models (LLMs) have enabled the construction of software agents capable of complex reasoning, planning, and adaptive behavior. While such agents increasingly participate in real-world computational processes -- interacting with servers, services, and other agents -- there exists no standardized protocol governing how agents express intent, exercise authority, delegate capabilities, or bind execution outcomes to their internal reasoning. Current implementations rely on ad-hoc mechanisms that lack formal identity, revocation semantics, delegation safety, and cross-domain trust guarantees. This absence of standardization creates systemic risks, including privilege escalation, confused-deputy vulnerabilities, audit failures, and uncontrolled delegation chains. The Agent Interaction & Delegation Protocol (AIDP) defines a formal, interoperable framework for agent-based interaction, enabling secure, auditable, and revocable agency across heterogeneous systems and administrative domains. 1.2 Why AIDP Exists Existing protocols authenticate actors. Existing protocols authorize requests. Existing protocols connect agents to tools (MCP) and to each other (A2A). No existing protocol standardizes the complete lifecycle of autonomous agent execution: the causal, verifiable chain from a declared intent, through validated authority, to enforced execution, attested observation, and gated reasoning continuation. AIDP standardizes exactly this lifecycle: Intent | v Authority | v Execution | v Observation | v Reasoning Continuation Vandoulas Expires 15 January 2027 [Page 4] Internet-Draft AIDP July 2026 The protocol innovation of AIDP is that each arrow in this chain is a verifiable protocol step, not an implementation convention: - An Intent is a cryptographically attributable execution request (Section 7), not a natural-language message. - Authority is a first-class, delegatable, revocable object evaluated at an enforcement point outside the agent (Section 6). - Execution occurs only at an Execution Boundary after full validation (Section 9). - Observations are attested results bound to the originating intent, providing replay-safe outcome integrity (Section 10). - Reasoning continuation is gated on validated Observations, making agent control loops deterministic and auditable (Section 10.2). Everything else in this document -- identity, delegation, revocation, lifecycle states, transport bindings -- exists to make this chain enforceable across trust boundaries. 1.3 Goals AIDP defines a protocol that: - Enables agents to express verifiable intent toward external systems. - Provides formal identity and authority models for agents. - Supports constrained, revocable delegation across trust boundaries. - Binds execution results to originating intent. - Enables deterministic, auditable agent control loops. - Supports human approval as a first-class protocol state (Section 8.3). - Supports long-running, multi-step, and delegated executions (Section 8.4). - Remains transport-agnostic and model-agnostic. 1.4 Non-Goals AIDP does not specify: Vandoulas Expires 15 January 2027 [Page 5] Internet-Draft AIDP July 2026 - Specific cryptographic algorithms. - Concrete serialization formats beyond the profiles in Section 14. - Transport protocols beyond the binding in Section 16. - LLM architectures or prompting strategies. - Organizational approval policies (AIDP specifies the protocol states and messages that carry approval decisions, not who must approve what). These concerns are explicitly layered beneath or above the AIDP control plane. 2. Terminology and Conventions 2.1 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. Agent: An autonomous software entity capable of producing Intent Envelopes and processing Observations. Intent Envelope: A protocol message expressing a requested action, including its governance and security context. An Intent Envelope is not a natural-language request; it is a cryptographically attributable execution request (see Section 7.1). Authority: A verifiable capability granting an Agent permission to perform specific actions under defined constraints. Delegation: The controlled transfer of a subset of authority from one Agent to another. Execution Boundary: The component responsible for enforcing authorization, executing actions, and producing Observations. Observation: A protocol message binding the outcome (or lifecycle state) of execution to the originating Intent Envelope. Vandoulas Expires 15 January 2027 [Page 6] Internet-Draft AIDP July 2026 Trust Boundary: A boundary across which identity, authority, and delegation MUST be revalidated. Approval Authority: A human or policy component authorized to resolve an intent held in the pending_approval state (Section 8.3). Lifecycle State: A normative protocol state of an Intent Envelope, as defined in Section 8. 3. Architecture Overview 3.1 System Components An AIDP-compliant system consists of the following logical components: - Reasoning Engine: Produces Intent Envelopes and consumes Observations. - Agent Runtime: Hosts the Reasoning Engine and manages agent state. - Execution Boundary: Enforces authority, executes actions, and emits Observations. - Authority Service: Issues, validates, and revokes authority objects. - Observation Channel: Delivers bound execution outcomes to agents. These components MAY be co-located or distributed. An informative reference architecture is provided in Appendix D. 3.2 Layered Model AIDP defines a layered architecture: Layer Description ------------------ ----------------------------------- Agency Control Intent, Delegation, Authority Trust Identity, Validation, Revocation Execution Action dispatch and enforcement Transport Delivery mechanism (bindings, Section 16) Each layer MUST operate independently of specific transport or serialization technologies. Vandoulas Expires 15 January 2027 [Page 7] Internet-Draft AIDP July 2026 3.3 Control Loop The normative agent control loop is: A. Intent Envelope B. Authority Validation C. Execution (through its Lifecycle States, Section 8) D. Observation E. Reasoning F. Next Intent Envelope An Agent MAY have multiple outstanding Intent Envelopes at any given time. An Agent MUST NOT generate a new Intent Envelope whose semantics causally depend on the outcome of a prior outstanding Intent Envelope unless the corresponding Observation has been received and validated. This constraint applies only to causally dependent intents and does not prohibit parallel or independent intent dispatch. 4. Relation to Existing Work This section describes how AIDP relates to existing work in the areas of authorization, identity management, capability-based security, and agent interoperability. The intent is to clarify scope and positioning, and to avoid ambiguity regarding overlap with prior protocols. 4.1 Grant Negotiation and Authorization Protocol (GNAP) AIDP shares architectural similarities with GNAP [GNAP] in that both define a control-plane interaction model based on structured requests and policy evaluation, rather than static, scope-based authorization. GNAP focuses on negotiating authorization grants for access to protected resources among clients, authorization servers, and resource servers. AIDP, by contrast, addresses delegated agentic action, where autonomous or semi-autonomous agents express intent, exercise constrained authority, and receive execution-bound observations. Vandoulas Expires 15 January 2027 [Page 8] Internet-Draft AIDP July 2026 Execution semantics, post-execution observation, reasoning failure handling, and runtime accountability are explicitly within scope for AIDP and are outside the scope of GNAP. GNAP may therefore be used as an authorization mechanism within an AIDP-compliant system, but it does not define the full interaction lifecycle specified by AIDP. 4.2 OAuth 2.0 Rich Authorization Requests (RAR) OAuth 2.0 Rich Authorization Requests [RAR] define a mechanism for expressing fine-grained authorization requirements beyond simple scope strings. AIDP adopts a similar principle by supporting structured expressions of authority, but applies it in a broader context. In AIDP, such expressions are embedded within Intent Envelopes and are evaluated in conjunction with agent identity, delegation chains, and execution constraints. Unlike OAuth RAR, AIDP does not assume a client-resource server architecture and is not limited to access control semantics. 4.3 Capability-Based Authorization (ZCAPs and UCAN) AIDP is conceptually aligned with capability-based authorization systems such as ZCAPs [ZCAP] and UCAN [UCAN], particularly with respect to explicit capabilities and delegation chains. As in these systems, authority in AIDP is represented as a transferable object that can be delegated across multiple actors without reliance on a centralized authorization server. AIDP differs in that capability delegation is integrated into an agent interaction and execution lifecycle, where capabilities are evaluated as part of intent processing and execution rather than solely as access credentials. 4.4 Identity Management and SCIM AIDP assumes the existence of stable and verifiable agent identities and is compatible with identity provisioning and lifecycle management systems such as the System for Cross-domain Identity Management (SCIM) [SCIM]. SCIM defines mechanisms for identity representation, provisioning, and synchronization across administrative domains. AIDP builds upon such identity systems to specify how authority is delegated and exercised during agent interaction and execution. Vandoulas Expires 15 January 2027 [Page 9] Internet-Draft AIDP July 2026 4.5 Relationship to the Model Context Protocol (MCP) The Model Context Protocol (MCP) [MCP] standardizes how an agent or model host connects to tools, resources, and context providers. MCP answers the question: "How does an agent discover and invoke a tool?" AIDP answers a different question: "Under what authority is this invocation performed, who approved it, and how is its outcome verifiably bound back to the requesting agent?" The two protocols are complementary and operate at different layers: - MCP is a data-plane / tool-invocation protocol between an agent host and tool servers. - AIDP is a control-plane protocol governing identity, authority, delegation, lifecycle, and auditable outcome binding. In a combined deployment, an MCP tool invocation is one possible implementation of the action performed by an Execution Boundary (Section 9) after AIDP validation succeeds. The Execution Boundary MAY front one or more MCP servers: the validated intent_body is mapped to an MCP tool call, and the tool result is wrapped in an attested AIDP Observation. MCP itself does not provide delegation chains, revocation semantics, replay protection for intents, or attested observations; AIDP does not provide tool schema discovery or context provisioning. Neither protocol replaces the other. 4.6 Relationship to the Agent2Agent Protocol (A2A) The Agent2Agent (A2A) protocol [A2A] standardizes peer-to-peer task exchange between opaque agents, including agent cards for capability description, task lifecycle updates, and artifact exchange. A2A answers the question: "How do two agents talk to each other about a task?" AIDP is concerned with whether an agent is ALLOWED to cause an action, under which delegated and revocable authority, and how the result is cryptographically bound to the request across trust boundaries. The protocols compose as follows: Vandoulas Expires 15 January 2027 [Page 10] Internet-Draft AIDP July 2026 - An A2A task request MAY carry an AIDP Intent Envelope (or a reference to one) as its governed payload, so that the receiving agent's Execution Boundary can validate identity, capability, delegation chain, and revocation state before acting. - AIDP delegation (Section 6.2) provides the authority semantics that A2A does not define: when Agent A asks Agent B to act, AIDP specifies how A's authority is subsetted, transferred, proven, and revoked. - A2A task state updates and AIDP Lifecycle Observations (Section 8.5) are compatible notions; a gateway MAY map between them, provided AIDP attestation requirements are preserved. In short: A2A moves tasks between agents; MCP connects agents to tools; AIDP governs the authority, accountability, and lifecycle of the actions themselves. 4.7 Summary AIDP does not replace existing authorization, identity, or agent interoperability protocols. Instead, it composes concepts from prior work into a unified control-plane protocol for agent interaction, delegation, execution, and accountability. Existing mechanisms such as GNAP, OAuth 2.0 Rich Authorization Requests, capability-based authorization systems, SCIM, MCP, and A2A may be used as complementary components within an AIDP-compliant architecture. 5. Agent Identity Model 5.1 Identity Requirements Every Agent participating in AIDP MUST possess a verifiable identity. An Agent Identity MUST provide the following properties: - Uniqueness: A globally unique identifier. - Issuance: Identification of the issuing authority. - Lifetime: Explicit validity interval. - Revocability: Capability to be invalidated independently of expiration. - Referencability: Stable reference suitable for inclusion in protocol messages. An Agent Identity MUST NOT be implicitly inferred from transport, host, or network context. Vandoulas Expires 15 January 2027 [Page 11] Internet-Draft AIDP July 2026 5.2 Identity Resolution and Validation Identity references MUST be resolved and validated at every Trust Boundary crossing. For cross-domain interoperability, an identity reference MUST conform to one of the following profiles: (A) Dereferenceable Identity Profile: The identity_ref MUST be resolvable by the verifying domain via a deterministic and reachable resolution mechanism defined by the issuer. (B) Self-Contained Identity Profile: The identity_ref MUST be accompanied by cryptographically verifiable identity assertions sufficient to establish authenticity without issuer reachability. If neither profile can be satisfied, the receiving domain MUST reject the request or apply fail-closed behavior according to its risk policy. 6. Authority & Capability Model 6.1 Authority Objects Authority is represented as a first-class object, hereafter termed a Capability. A Capability MUST contain: - Subject: Agent Identity to which authority is granted. - Action: Permitted operation(s). - Resource: Target resource(s). - Constraints: Scope, quantity, temporal, and contextual limits. - Issuer: Authority that issued the capability. - Revocation Pointer: Mechanism for revocation verification. Capabilities MUST be evaluated independently of any agent claims. 6.2 Capability Delegation Agents MAY delegate authority only by issuing new Capabilities with strictly reduced scope. Delegation MUST satisfy: Vandoulas Expires 15 January 2027 [Page 12] Internet-Draft AIDP July 2026 - Subsetting Rule: Delegated authority MUST NOT exceed original authority. - Traceability: Each delegated capability MUST reference its parent. - Revocability: Revocation of a parent capability MUST invalidate all derived capabilities. Delegation chains MUST be preserved and transmitted with each Intent Envelope. 6.3 Revocation Semantics Revocation MUST be supported for: - Agent Identity - Capabilities - Delegation chains Revocation MUST take effect immediately upon verification and MUST NOT depend on token expiration alone. 7. Intent Envelope 7.1 Definition An Intent Envelope is NOT a natural-language request, a prompt, or a description of desired behavior. An Intent Envelope is a cryptographically attributable execution request: a structured protocol message that (a) identifies a verified actor, (b) references verifiable authority, (c) declares a bounded action with explicit constraints, and (d) is bound by identifier to exactly one execution lifecycle and its resulting Observations. Consequences of this definition (normative): - Free-text fields inside an Intent Envelope MUST NOT be used by an Execution Boundary as authorization input (see Section 17.6.1). - Two Intent Envelopes with identical canonical payloads are the same request for replay purposes (Section 17.6.3). - An Intent Envelope with no resolvable actor_ref or authority_ref is invalid regardless of its content. 7.2 Envelope Structure Vandoulas Expires 15 January 2027 [Page 13] Internet-Draft AIDP July 2026 An Intent Envelope is the fundamental protocol message produced by an Agent. Each Intent Envelope MUST contain: - envelope_id: Globally unique, non-reusable identifier. - timestamp: Time of issuance. - actor_ref: Reference to Agent Identity. - authority_ref: Reference to Capability. - intent_body: Declared action, target, and parameters. - constraints: Execution limitations. - delegation_chain: Ordered list of delegated Capabilities. - observability_hooks: Declaration of required observation behavior. 7.3 Envelope Validation Rules Upon receipt, the Execution Boundary MUST verify: 1. Actor identity validity. 2. Capability authenticity and scope. 3. Delegation chain integrity. 4. Revocation status for all identities and capabilities. 5. Constraint satisfaction. 6. Non-reuse of envelope_id (replay protection). Failure of any validation step MUST abort execution. 7.4 Authority Separation Principle Agents MUST NOT modify: - actor_ref - authority_ref - delegation_chain These elements are managed exclusively by the Authority Service and Execution Boundary. 8. Intent Lifecycle Model Previous versions of this specification implicitly assumed a short-lived request/execute/observe pattern. Contemporary agentic systems require intents that wait for human approval, run for extended periods, pause, resume, and delegate sub-work. This section defines a normative state model for the lifecycle of an Intent Envelope. It defines states and transition rules only; it does not mandate any particular scheduler, workflow engine, or implementation. Vandoulas Expires 15 January 2027 [Page 14] Internet-Draft AIDP July 2026 8.1 Lifecycle States Every Intent Envelope accepted by an Execution Boundary has exactly one Lifecycle State at any point in time. The normative states are: State Terminal Meaning ---------------- -------- ------------------------------------- submitted no IE received; validation in progress. pending_approval no Validation passed; execution is held awaiting an Approval Authority decision (Section 8.3). approved no Approval granted; awaiting scheduling. accepted no Authorized for execution (no approval gate, or approval already granted). running no Execution in progress. waiting no Execution blocked on an external event, resource, or input. delegated no Execution transferred (in whole or part) to another agent or domain via a delegated capability. paused no Execution intentionally suspended by policy, operator, or agent request. completed yes Execution finished successfully. partially_completed yes Execution finished with a subset of requested effects applied. failed yes Execution attempted and failed. cancelled yes Intent terminated before completion by agent, operator, policy, revocation, or approval denial/timeout. rejected yes Validation or authorization failed; nothing was executed. The values "executed" and "partially_executed" used by draft-vandoulas-aidp-02 are deprecated aliases of "completed" and "partially_completed" respectively. Implementations SHOULD emit the new values and MUST accept the deprecated aliases when processing messages declaring aidp_version "1.0-draft". 8.2 State Transition Rules The permitted transitions are: Vandoulas Expires 15 January 2027 [Page 15] Internet-Draft AIDP July 2026 submitted -> pending_approval | accepted | rejected pending_approval -> approved | cancelled approved -> accepted accepted -> running | cancelled running -> waiting | delegated | paused | completed | partially_completed | failed | cancelled waiting -> running | failed | cancelled delegated -> running | waiting | completed | partially_completed | failed | cancelled paused -> running | cancelled Normative rules: 1. Terminal states MUST NOT be exited. Any message implying a transition out of a terminal state MUST be rejected with Problem Details error_code LIFECYCLE_INVALID_TRANSITION. 2. The Execution Boundary is the sole authority for lifecycle transitions. Agents MAY request cancellation or pause; only the Execution Boundary transitions the state. 3. Every transition MUST be recorded in the audit trail with timestamp, prior state, new state, and cause. 4. Revocation of the governing capability or actor identity while an intent is in any non-terminal state MUST drive the intent to cancelled (if not yet running) or to the deployment's defined abort behavior (if running), and MUST be observable. 5. Constraint windows (not_before/not_after) apply to entry into the running state unless the capability explicitly scopes them otherwise. An intent whose not_after expires while in pending_approval, waiting, or paused MUST transition to cancelled. 8.3 Human Approval Gates Human oversight is a protocol state, not merely a governance recommendation. AIDP models human approval as a first-class gate in the intent lifecycle. 8.3.1 Triggering an Approval Gate An Execution Boundary MUST hold an intent in pending_approval when any of the following applies: Vandoulas Expires 15 January 2027 [Page 16] Internet-Draft AIDP July 2026 - The governing Capability carries a constraint requires_approval = true. - Local policy for the action class or risk_tier requires approval. - The delegation chain includes a link whose constraints require approval for downstream execution. The Execution Boundary MUST emit a Lifecycle Observation (Section 8.5) with status = pending_approval so that the requesting Agent knows the intent is held, not lost. 8.3.2 Approval Object An approval decision is represented by an approval object recorded by the Execution Boundary and reflected in subsequent Observations: - approval_id (string): unique identifier of the decision. - approver_ref (object): verifiable identity reference of the Approval Authority (human principal or policy engine). - decision (string: "approved" | "denied"). - timestamp (RFC3339). - expires_at (RFC3339, OPTIONAL): validity bound of the approval. - proof (object, RECOMMENDED): signature by the Approval Authority over the tuple (envelope_id, decision, timestamp). Normative rules: 1. An approval MUST be bound to exactly one envelope_id. Blanket approvals are expressed as Capabilities, not as approval objects. 2. approver_ref MUST NOT be the actor_ref of the intent, and MUST NOT be any agent identity appearing in the delegation chain (no self-approval). 3. A denied decision MUST transition the intent to cancelled and be reported with Problem Details error_code APPROVAL_DENIED. 4. If no decision is received within the deployment-defined or constraint-defined approval window, the intent MUST transition to cancelled with error_code APPROVAL_TIMEOUT. 5. Approval decisions MUST appear in the audit trail and SHOULD be independently verifiable via the approval proof. 6. An approval applies to the canonical payload of the approved envelope. Any modification of the intent after approval constitutes a new intent requiring a new approval. 8.3.3 Approval Flow (Normative) Vandoulas Expires 15 January 2027 [Page 17] Internet-Draft AIDP July 2026 submitted | v (validation passed; gate required) pending_approval ----------------------------+ | | | decision = approved | decision = denied, v | or timeout, approved | or revocation | v v cancelled accepted -> running -> completed | v Observation | v Reasoning Continuation This gate operates below agent reasoning: a compromised or misaligned agent cannot bypass it, because the state is enforced at the Execution Boundary (see Section 17.6.7). 8.4 Long-Running and Multi-Step Execution Agentic workloads commonly follow patterns such as: plan -> tool -> tool -> delegate -> tool -> sleep -> resume -> tool -> finish AIDP supports such workloads without prescribing an execution engine: 1. Waiting. An Execution Boundary MAY transition a running intent to waiting when execution blocks on an external event (human input, third-party callback, scheduled time). The wake condition SHOULD be recorded in the audit trail. 2. Pausing and resuming. Operators or policy MAY pause a running intent. Resumption MUST re-check revocation status and constraint windows before re-entering running (TOCTOU protection, Section 17.6.6). Vandoulas Expires 15 January 2027 [Page 18] Internet-Draft AIDP July 2026 3. Delegation as a lifecycle state. When part of the work is delegated to another agent under a subsetted capability (Section 6.2), the parent intent MAY be marked delegated. The parent intent's outcome MUST NOT be reported completed until Observations for the delegated work have been received and validated, or the delegated work has been incorporated into a partially_completed outcome. 4. Progress visibility. For intents expected to remain non-terminal beyond a deployment-defined interval, the Execution Boundary SHOULD emit periodic Lifecycle Observations (Section 8.5) so the Agent Runtime can distinguish "still running" from "lost". 5. Recovery. Because intents may be long-lived, Observation retention and pull-based retrieval (Section 16.7) are REQUIRED to survive Agent restarts. 8.5 Lifecycle Observations An Observation whose status is a non-terminal Lifecycle State is a Lifecycle Observation. Lifecycle Observations: - MUST carry the same envelope_id binding and attestation requirements as terminal Observations (Section 10). - MUST NOT be treated by the Agent Runtime as execution outcomes; they update lifecycle knowledge only. - MUST be idempotent per (envelope_id, execution_id, status, timestamp). - Do NOT release causal reasoning gates; only a validated terminal Observation does (Section 10.2). A terminal Observation for an envelope_id supersedes all Lifecycle Observations for that envelope_id. 9. Execution Model 9.1 Execution Boundary The Execution Boundary is the sole component authorized to perform actions on behalf of an Agent. The Execution Boundary MUST: Vandoulas Expires 15 January 2027 [Page 19] Internet-Draft AIDP July 2026 - Enforce identity and authority validation. - Apply constraint verification. - Enforce the Intent Lifecycle Model (Section 8), including approval gates. - Execute the requested action. - Emit bound Observations. The Execution Boundary MUST NOT accept any action request outside of a validated Intent Envelope. 9.2 Authorization & Enforcement Flow Normative execution flow: 1. Receive Intent Envelope. 2. Validate identity. 3. Validate authority and delegation chain. 4. Verify revocation status. 5. Enforce constraints. 6. Apply approval gate if required (Section 8.3). 7. Execute action (through lifecycle states as applicable). 8. Generate Observation(s). 9. Deliver Observation(s) via Observation Channel. Any failure in steps 2-6 MUST result in rejection or cancellation per Section 8.2. 10. Observation & Feedback Binding 10.1 Observation Structure Each Observation MUST contain: - envelope_id - execution_id - status (a Lifecycle State, Section 8.1) - result - side_effects - timestamp - attestation 10.2 Binding Requirements Reasoning progression within an Agent MUST be gated on validated terminal Observations for all intents upon which subsequent reasoning steps depend. Vandoulas Expires 15 January 2027 [Page 20] Internet-Draft AIDP July 2026 Independent intents MAY be issued and processed concurrently, provided that their resulting Observations are correctly bound to their respective envelope_id values. Lifecycle Observations (Section 8.5) inform scheduling and user experience but MUST NOT release causal reasoning gates. 10.3 Replay Protection & Determinism The tuple (envelope_id, execution_id, timestamp) MUST provide replay protection. Agent reasoning loops MUST be deterministic with respect to received terminal Observations. 11. Multi-Agent Interaction 11.1 Trust Boundaries At every Trust Boundary crossing, the receiving domain MUST independently validate: - Agent Identity - Capability authenticity - Delegation chain - Revocation status No implicit trust MAY cross a Trust Boundary. 11.2 Cross-Domain Delegation Delegation across domains MUST follow: - Capability subsetting rules - Explicit delegation chain construction - Independent revocation enforcement Shared secrets or inherited credentials MUST NOT be used as delegation mechanisms. 11.3 Agent-to-Agent Protocol Flow Normative multi-agent interaction: Agent A -> Intent Envelope -> Trust Boundary -> Agent B Agent B -> Execution Boundary -> Observation -> Agent A Vandoulas Expires 15 January 2027 [Page 21] Internet-Draft AIDP July 2026 Every stage MUST preserve auditability and authority constraints. An informative end-to-end multi-agent example, including delegation and lifecycle states, is provided in Appendix C. 12. Version Negotiation 12.1 Version Identifier Every AIDP message carries aidp_version (Section 14.5). Version identifiers use the form "MAJOR.MINOR" (e.g., "1.0", "1.2"). The value "1.0-draft" used by earlier versions of this document is treated as equivalent to "1.0". 12.2 Compatibility Rules 1. Different MAJOR versions are NOT interoperable. A receiver encountering an unsupported MAJOR version MUST reject the message with error_code UNSUPPORTED_VERSION. 2. Within a MAJOR version, MINOR versions are backward-compatible extensions. A receiver supporting 1.x receiving a 1.y message with y > x MUST process the message according to 1.x semantics and MUST apply the extension rules of Section 19 to unknown elements: unknown fields in security-critical objects cause rejection; unknown fields elsewhere are ignored. 3. A sender MUST NOT mark a message with a version whose mandatory semantics the message does not satisfy. 12.3 Version Advertisement and Selection A Problem Details message with error_code UNSUPPORTED_VERSION SHOULD include in details: - supported_versions (array of strings) Upon receipt, the sender MAY re-issue the intent as a NEW Intent Envelope (new envelope_id) using a mutually supported version. Implementations MUST NOT resubmit the same envelope_id under a different version, as the canonical payload differs. Where Capability Discovery (Section 13) is deployed, supported versions SHOULD be advertised there, avoiding a rejection round trip. 12.4 Downgrade Protection Vandoulas Expires 15 January 2027 [Page 22] Internet-Draft AIDP July 2026 Because aidp_version is part of the signed canonical payload, an on-path attacker cannot alter it without invalidating the proof. Receivers MUST verify that the version used for canonicalization and validation is the version carried in the message. 13. Capability Discovery Capability Discovery is an OPTIONAL extension point. It is advisory metadata, not authorization. 13.1 Discovery Data An Execution Boundary MAY publish a discovery document describing: - supported aidp_version values - supported serialization families (Section 14.1) - supported message types (including registered extensions) - supported attestation profiles - action classes / targets it can execute - whether approval gates apply to given action classes - observation delivery modes (push/pull) 13.2 Normative Rules 1. Discovery data MUST NOT be treated as a grant of authority. Execution requires a valid Capability regardless of what discovery advertises. 2. Discovery responses SHOULD be signed by the Execution Boundary so agents can detect tampering. 3. Agents MUST tolerate discovery data being stale; authoritative validation always occurs at intent submission. 4. Absence of a discovery endpoint MUST NOT be treated as an error; discovery is OPTIONAL. The HTTP binding for discovery is defined in Section 16.12. Capability Negotiation (an agent proposing constraints and receiving counter-proposals) is out of scope for this document and is an anticipated extension (Section 19). 14. Wire Format 14.1 Serialization Families AIDP messages MUST be representable in at least one of the following serialization families: Vandoulas Expires 15 January 2027 [Page 23] Internet-Draft AIDP July 2026 - AIDP-JS (JSON): Human-readable encoding for debugging, documentation, and early adoption. - AIDP-CB (CBOR): Binary encoding for production deployments with strict canonicalization. An implementation MAY support additional encodings, provided that: 1. The semantic model is preserved exactly, and 2. A deterministic canonical signing input (Section 14.3) is defined. 14.2 Message Types AIDP defines three primary wire messages: - Intent Envelope (IE): request to execute a governed action. - Observation (OB): bound result or lifecycle state of an execution. - Problem Details (PD): structured rejection / error. Additional message types may be registered per Section 20. Each message MUST carry: - aidp_version - msg_type - payload 14.3 Canonical Signing Input To prevent canonicalization attacks, AIDP requires an unambiguous signing input. Canonical AIDP-JS encoding requires: - UTF-8 encoding - Deterministic lexicographic ordering of object members - No duplicate object member names - Deterministic number and string representations JSON messages containing duplicate object member names MUST be rejected. This rejection MUST occur during parsing, prior to schema validation or canonicalization. For AIDP-CB, the signing input MUST use CBOR canonical (deterministic) encoding. Vandoulas Expires 15 January 2027 [Page 24] Internet-Draft AIDP July 2026 The signing input MUST be computed over the payload object only (not transport metadata). The exact canonicalization profile MUST be declared as canon. 14.4 Attestations and Proofs AIDP supports two proof-bearing fields: - proof: signature or MAC over canonical signing input - proof_chain: optional chain of proofs for delegation links Intent Envelopes SHOULD be signed by the Agent Runtime when any non-trivial authority is exercised. Observations MUST be attested by the Execution Boundary. 14.5 Common Header All AIDP wire messages MUST include: - aidp_version (string, Section 12.1) - msg_type (string: "IE" | "OB" | "PD", or a registered extension) - canon (string: canonicalization profile identifier) - payload (object) - proof (object, OPTIONAL unless required by local policy) 15. Message Schemas Below are normative field sets. Implementations MUST reject unknown fields in security-critical sub-objects unless explicitly permitted by the Extensibility Model (Section 19). 15.1 Intent Envelope Payload (IE) Required: - envelope_id (string/UUID) - timestamp (RFC3339 string) - actor_ref (object) - authority_ref (object) - intent_body (object) - constraints (object) - delegation_chain (array, MAY be empty) - observability_hooks (object) 15.1.1 actor_ref Vandoulas Expires 15 January 2027 [Page 25] Internet-Draft AIDP July 2026 - agent_id (string) - issuer (string) - identity_ref (string) -- dereferenceable URI/URN-like reference (transport-agnostic) 15.1.2 authority_ref - cap_id (string) - issuer (string) - cap_ref (string) -- dereferenceable reference - rev_ref (string) -- revocation pointer reference 15.1.3 intent_body - action (string) - target (object) - parameters (object) target MUST include at least: - resource (string) - domain (string) -- security domain identifier 15.1.4 constraints Constraints SHOULD include (as applicable): - not_before / not_after (RFC3339) - max_cost (number) - max_uses (integer) - risk_tier (string: "low"|"med"|"high", OPTIONAL but RECOMMENDED) - requires_approval (boolean, OPTIONAL; triggers the Human Approval Gate, Section 8.3) - approval_window_sec (integer, OPTIONAL; maximum time an intent may remain in pending_approval) - idempotency_key (string, OPTIONAL) The idempotency_key is OPTIONAL and is intended for application-level idempotency across transport retries or envelope re-issuance scenarios. Protocol-level replay protection and execution idempotency are primarily enforced via the envelope_id. Implementations MUST NOT require the presence of idempotency_key to provide replay safety or result recovery. Additional constraint types may be registered per Section 20. Vandoulas Expires 15 January 2027 [Page 26] Internet-Draft AIDP July 2026 15.1.5 delegation_chain Each element MUST include: - cap_id - issuer - cap_ref - parent_cap_id (string) - rev_ref - link_proof (object) -- proof binding child to parent 15.1.6 observability_hooks The return_to field specifies the destination for Observation delivery. The specified endpoint MUST be pre-registered, pre-approved, or otherwise explicitly authorized for the identity identified by actor_ref. Execution Boundaries MUST NOT deliver Observations to arbitrary or unverified endpoints supplied dynamically by an Agent. The OPTIONAL field lifecycle_updates (boolean) requests delivery of Lifecycle Observations (Section 8.5) in addition to terminal Observations. 15.2 Observation Payload (OB) Required: - envelope_id - execution_id (string) - timestamp (RFC3339) - status (string: a Lifecycle State per Section 8.1; the values "executed" and "partially_executed" are deprecated aliases, see Section 8.1) - result (object, MAY be empty) - side_effects (array, MAY be empty) - attestation (object) Optional: Vandoulas Expires 15 January 2027 [Page 27] Internet-Draft AIDP July 2026 - approval (object, per Section 8.3.2; REQUIRED in the first Observation following an approval decision) - lifecycle (object, OPTIONAL for Lifecycle Observations): - prior_status (string) - cause (string) - expected_next_update_sec (integer, OPTIONAL) 15.2.1 attestation - boundary_id (string) - issuer (string) - attest_profile (string) - decision (string: authorized|not_authorized| constraint_violation|invalid_chain|revoked|replay| pending_approval|approval_denied) - policy_digest (string) -- hash/reference to policy version used - evidence (object, OPTIONAL) -- minimal additional evidence (non-sensitive by default) Observations MUST be signed/attested by the Execution Boundary (i.e., proof REQUIRED for OB by default). 15.2.2 execution_advice (OPTIONAL) The execution_advice object provides non-binding guidance to the Agent Runtime regarding retry, backoff, or revision expectations following an Observation that does not represent successful execution. The execution_advice object MAY include: - retriable (boolean): Indicates whether retrying the same intent MAY succeed. - retry_after_sec (integer): Suggested minimum delay before attempting a retry. - reason_code (string): Machine-readable classification of the failure condition (e.g., CONSTRAINT_VIOLATION, BUDGET_EXCEEDED, RATE_LIMITED, POLICY_REFUSED, NOT_AUTHORIZED). 15.3 Problem Details Payload (PD) Required: Vandoulas Expires 15 January 2027 [Page 28] Internet-Draft AIDP July 2026 - envelope_id (if applicable) - timestamp - error_code (string) - error_message (string) - details (object, OPTIONAL) Recommended error_code values (initial registry contents, Section 20.2): - INVALID_IDENTITY - UNTRUSTED_ISSUER - REVOKED - INVALID_CAPABILITY - INVALID_DELEGATION_CHAIN - CONSTRAINT_VIOLATION - REPLAY_DETECTED - MALFORMED_MESSAGE - UNSUPPORTED_VERSION - APPROVAL_DENIED - APPROVAL_TIMEOUT - LIFECYCLE_INVALID_TRANSITION Problem Details messages MAY include an execution_advice object with the same semantics as defined for Observation messages. When present, execution_advice applies to the failed Intent Envelope identified by envelope_id. 16. HTTP Transport Binding (AIDP-HTTP) 16.1 Overview This section specifies a concrete transport binding for AIDP using HTTP. It defines: - submission of Intent Envelopes (IE) to an Execution Boundary (EB), - delivery/retrieval of Observations (OB), - structured error reporting (PD), - discovery (OPTIONAL), - minimal requirements for replay safety and correlation. This binding is compatible with AIDP-JS (JSON) payloads as specified in Sections 14-15. AIDP-CB (CBOR) MAY be supported via content negotiation. 16.2 Resources and Roles Vandoulas Expires 15 January 2027 [Page 29] Internet-Draft AIDP July 2026 - Client: Agent Runtime (AR) or Agent-facing proxy. - Server: Execution Boundary (EB). - Observation Channel: either: - push: EB calls an AR webhook, or - pull: AR polls an EB-hosted inbox. 16.3 Media Types Implementations MUST support JSON. - IE: application/aidp+json; msg=IE - OB: application/aidp+json; msg=OB - PD: application/aidp+json; msg=PD Servers MAY additionally support CBOR: - application/aidp+cbor; msg=IE|OB|PD 16.4 Common HTTP Headers Clients and servers MUST use: - Content-Type: as above - Accept: one or more supported AIDP media types The following headers are RECOMMENDED: - Idempotency-Key: value of constraints.idempotency_key (when present) - X-AIDP-Envelope-ID: mirrors payload.envelope_id (for tracing; not authoritative) 16.5 Authorization at HTTP Layer AIDP authorization is enforced via authority_ref/capabilities at the AIDP layer. However, the HTTP channel itself MUST be authenticated to prevent anonymous flooding and to enable policy decisions. EB deployments MUST require at least one of: - mutual TLS (mTLS), or - OAuth 2.0 Bearer token, or - another mutually authenticated mechanism. Important: HTTP-layer auth MUST NOT be treated as sufficient authorization for actions. EB MUST still validate AIDP identity/capability/delegation/revocation per the core spec. Vandoulas Expires 15 January 2027 [Page 30] Internet-Draft AIDP July 2026 16.6 Endpoint: Submit Intent Envelope POST /v1/aidp/intents Request body: an IE message. Success responses: - 202 Accepted: intent accepted for processing; OB will be delivered via hooks (push) and/or made available for pull. This response is also used when the intent enters pending_approval (Section 8.3); the subsequent Lifecycle Observation carries the state. - 200 OK: intent executed synchronously and OB is returned in the response body (allowed for low latency operations). Failure responses: - 400 Bad Request: malformed AIDP message (PD returned) - 401 Unauthorized: HTTP-layer auth failure (PD OPTIONAL; may be plain HTTP) - 403 Forbidden: AIDP authorization failure, approval denial (PD returned) - 409 Conflict: replay detected / envelope_id reuse (PD returned) - 415 Unsupported Media Type: unsupported encoding - 429 Too Many Requests: rate limiting (PD OPTIONAL but RECOMMENDED) - 500/503: server failure / dependency failure (PD RECOMMENDED) Response body: - For 200: an OB - For 202: either empty or a minimal acknowledgment object (OPTIONAL). If included, it MUST NOT claim execution success. - For failures: a PD SHOULD be returned. 16.6.1 Correlation Rules - EB MUST treat payload.envelope_id as authoritative. - If X-AIDP-Envelope-ID is present and does not match the payload, EB MUST reject with MALFORMED_MESSAGE. 16.6.2 Synchronous vs Asynchronous Execution EB MAY execute synchronously (200) when: Vandoulas Expires 15 January 2027 [Page 31] Internet-Draft AIDP July 2026 - action is low-risk and low-latency, and - revocation checks can be performed inline, and - no approval gate applies. Otherwise EB SHOULD default to 202 + asynchronous OB. 16.7 Endpoint: Retrieve Observation (Pull Mode) GET /v1/aidp/observations/{envelope_id} Returns: - 200 OK + OB if available (the latest Observation by default; for long-running intents this may be a Lifecycle Observation) - 404 Not Found if unknown (or not yet available) - 410 Gone if envelope_id is known but observation expired/garbage-collected (PD RECOMMENDED) - 409 Conflict if multiple observations exist and client must page (see 16.7.1) EB SHOULD retain observations for a configurable retention window. Execution Boundaries MUST retain Observations for a deployment-defined retention period sufficient to allow Agents to recover results in the presence of delivery failure, Agent restarts, or network partition. For long-running intents (Section 8.4), the retention policy MUST cover at least the expected intent lifetime. If an Observation cannot be returned inline due to replay detection, the EB MUST expose a deterministic retrieval mechanism bound to the envelope_id. 16.7.1 Multiple Observations per Envelope Intents progressing through lifecycle states will yield multiple OBs (e.g., pending_approval, then running, then completed). If multiple are retained, EB MUST support: GET /v1/aidp/observations?envelope_id=...&after=...&limit=... Returning either: - a single latest OB (default), or - a list of OBs when mode=all. 16.8 Endpoint: Observation Inbox (Pull Mode, Queue Semantics) Vandoulas Expires 15 January 2027 [Page 32] Internet-Draft AIDP July 2026 GET /v1/aidp/inbox Query params: - cursor (opaque) - limit (1-100) Returns 200 OK with: - items: array of OB messages - next_cursor: cursor for pagination EB MUST only deliver observations intended for the authenticated caller per observability_hooks.return_to. 16.9 Observation Delivery (Push Mode) If observability_hooks.delivery_mode = "push", return_to MUST include a webhook URL reference or a resolvable endpoint reference. EB will deliver via: POST Body: an OB message. Expected responses by AR: - 200 OK: received and accepted - 409 Conflict: duplicate delivery (idempotent accept) - 410 Gone: endpoint deprecated (EB SHOULD fall back to pull if configured) EB MUST implement retries with backoff. Duplicate deliveries MUST be possible; AR MUST handle idempotently using (envelope_id, execution_id). Execution Boundaries MUST enforce SSRF protections when performing Observation delivery, including but not limited to: - Rejection of loopback, link-local, private, or non-globally routable addresses - Domain allowlisting or identity-bound endpoint registration - Protection against DNS rebinding If an endpoint cannot be validated or authorized, the EB MUST fall back to inbox-based or pull-based Observation retrieval. Vandoulas Expires 15 January 2027 [Page 33] Internet-Draft AIDP July 2026 16.10 Problem Details over HTTP PD is carried as the response body for AIDP-layer errors. Mapping guidance: - INVALID_IDENTITY, UNTRUSTED_ISSUER, REVOKED, INVALID_DELEGATION_CHAIN -> 403 - CONSTRAINT_VIOLATION -> 403 (or 409 if semantic conflict) - APPROVAL_DENIED, APPROVAL_TIMEOUT -> 403 - LIFECYCLE_INVALID_TRANSITION -> 409 - REPLAY_DETECTED -> 409 - MALFORMED_MESSAGE, UNSUPPORTED_VERSION -> 400 - UNSUPPORTED_MEDIA_TYPE -> 415 16.11 HTTP Caching, Integrity and Confidentiality Responses containing OB or PD MUST include headers preventing intermediary caching: - Cache-Control: no-store AIDP-HTTP MUST be carried over TLS. mTLS is RECOMMENDED for high-risk tiers. 16.12 Endpoint: Capability Discovery (OPTIONAL) GET /v1/aidp/discovery Returns 200 OK with a JSON object containing (all fields OPTIONAL): - aidp_versions (array of strings) - serializations (array: "AIDP-JS" | "AIDP-CB" | registered) - msg_types (array of strings) - attest_profiles (array of strings) - action_classes (array of objects: action, approval_required, risk_tier) - delivery_modes (array: "push" | "pull") The response SHOULD be signed (e.g., carried as a signed AIDP message or via detached signature). Discovery semantics and limits are defined in Section 13. 16.13 Webhook Verification Model (Push Observations) 16.13.1 Trust Anchors Vandoulas Expires 15 January 2027 [Page 34] Internet-Draft AIDP July 2026 Each Agent Runtime (AR) MUST maintain a set of trust anchors for validating incoming Observation deliveries. These trust anchors MUST include: - Approved issuers of Execution Boundary (EB) attestations - (OPTIONAL) Explicit allowlists of specific EB instances identified by boundary_id The AR MUST reject any webhook-delivered Observation if: - attestation.issuer is not included in the trust anchors, or - the public key referenced by proof.kid cannot be resolved for the declared issuer, or - the boundary_id is disallowed by local policy. 16.13.2 Required Verification Steps (AR-side) Upon receipt of an Observation via webhook, the Agent Runtime MUST perform the following steps, in order: 1. Parse and schema-validate the Observation message using strict validation rules. 2. Verify the attestation proof (proof) over the canonical signing input. 3. Validate issuer trust, ensuring attestation.issuer is trusted. 4. Bind the Observation to an outstanding Intent: payload.envelope_id MUST correspond to a currently pending Intent Envelope, otherwise the Observation MUST be rejected or quarantined according to policy. 5. Enforce replay protection: the tuple (envelope_id, execution_id) MUST be accepted at most once per status value for Lifecycle Observations, and at most once overall for terminal Observations. 6. OPTIONAL but RECOMMENDED: Verify attestation.policy_digest against a locally known policy registry when available. If any verification step fails, the AR MUST NOT accept the Observation and MUST respond with a non-2xx HTTP status code. 16.13.3 Delivery Idempotency Execution Boundaries MUST treat webhook delivery as retry-safe. Agent Runtimes MUST process webhook Observations idempotently, keyed by (envelope_id, execution_id). If a duplicate delivery is received, the AR MUST NOT re-apply any state transition and SHOULD return either: Vandoulas Expires 15 January 2027 [Page 35] Internet-Draft AIDP July 2026 - 409 Conflict (duplicate), or - 200 OK with a Problem Details payload indicating duplicate acceptance. 16.13.4 Webhook Channel Authentication In addition to cryptographic attestation inside the Observation itself, the webhook transport channel SHOULD be protected using: - Mutual TLS (mTLS), or - An HTTP authentication mechanism that cryptographically binds the EB identity to the TLS session. Channel-level authentication mitigates denial-of-service attacks and prevents unauthenticated injection of traffic toward the AR. 16.13.5 Anti-Substitution Rules The Agent Runtime MUST enforce the following anti-substitution rules: - The payload.envelope_id in the Observation MUST correspond exactly to the pending Intent Envelope. - If the AR maintains a local digest of the submitted Intent Envelope, it SHOULD ensure the received Observation corresponds to that digest entry. - All fields declared in observability_hooks.required_fields MUST be present before the Observation is accepted. Failure of any rule MUST cause the Observation to be rejected. 16.13.6 Error Responses from Webhook Endpoint The AR webhook endpoint MUST use the following status codes: HTTP Code Meaning --------- ------------------------------- 200 Observation accepted 409 Duplicate delivery 400 Malformed Observation 403 Untrusted issuer or invalid proof 410 Endpoint deprecated 429 Rate limited 16.13.7 Fallback to Pull Mode If repeated webhook deliveries fail, the Execution Boundary SHOULD: Vandoulas Expires 15 January 2027 [Page 36] Internet-Draft AIDP July 2026 - Retain the Observation for retrieval via GET /v1/aidp/observations/{envelope_id}, and - Optionally emit a Problem Details message indicating push delivery failure. 16.14 Reference Validation Pipeline This section defines the normative validation and execution pipeline that every AIDP-compliant Execution Boundary (EB) and Agent Runtime (AR) MUST implement. Any deviation from this sequence constitutes a protocol violation. 16.14.1 Execution Boundary Validation Pipeline Upon receipt of an Intent Envelope over HTTP, the EB MUST execute the following steps in order: 1. Transport Authentication 2. Message Parsing 3. Canonicalization 4. Proof Verification 5. Schema Validation 6. Version Check (Section 12) 7. Identity Validation 8. Capability Resolution 9. Delegation Chain Validation 10. Revocation Checks 11. Constraint Enforcement 12. Replay Protection 13. Approval Gate Evaluation (Section 8.3) 14. Authorization Decision 15. Execution (through lifecycle states) 16. Observation Construction 17. Attestation & Emission 18. Audit Recording 16.14.2 Detailed Step Semantics 1. Transport Authentication The EB MUST verify HTTP-layer authentication (mTLS, OAuth, etc.) and reject unauthenticated clients. Transport authentication does not grant execution authority. Vandoulas Expires 15 January 2027 [Page 37] Internet-Draft AIDP July 2026 2. Message Parsing The EB MUST parse the incoming message strictly. Malformed messages MUST be rejected with MALFORMED_MESSAGE. During message parsing, Execution Boundaries and Agent Runtimes MUST use a JSON parser configuration that detects and rejects duplicate object member names. Messages that contain duplicate keys MUST be rejected before any validation, canonicalization, or cryptographic verification is performed. 3. Canonicalization The EB MUST canonicalize the payload using the declared canon profile. Failure MUST abort processing. 4. Proof Verification If present, proof MUST be verified against the canonical payload. Failure MUST abort processing. 5. Schema Validation The EB MUST validate the payload against the AIDP schema for the declared message type. Unknown fields in security-critical objects MUST cause rejection. 6. Version Check The EB MUST apply the compatibility rules of Section 12. Unsupported MAJOR versions MUST be rejected with UNSUPPORTED_VERSION. 7. Identity Validation The EB MUST resolve and validate actor_ref.identity_ref and issuer trust. Failures MUST result in INVALID_IDENTITY or UNTRUSTED_ISSUER. 8. Capability Resolution The EB MUST resolve authority_ref.cap_ref, validate issuer trust, and load associated constraints. 9. Delegation Chain Validation If delegation_chain is present, the EB MUST: - Validate every link's proof - Enforce subsetting rules - Verify parent-child relationships - Reject any amplification of authority Failures MUST result in INVALID_DELEGATION_CHAIN. Vandoulas Expires 15 January 2027 [Page 38] Internet-Draft AIDP July 2026 10. Revocation Checks The EB MUST consult all rev_ref references (identity, capability, delegation parents). For high-risk actions, revocation checks MUST be performed immediately prior to execution, and upon resumption from waiting or paused states. 11. Constraint Enforcement All constraints MUST be enforced: - time windows - usage limits - resource scope - risk tier policies Failures MUST result in CONSTRAINT_VIOLATION. 12. Replay Protection The EB MUST verify that envelope_id has not been previously accepted. Replay MUST result in REPLAY_DETECTED. 13. Approval Gate Evaluation If an approval gate applies (Section 8.3.1), the EB MUST transition the intent to pending_approval, emit a Lifecycle Observation, and suspend the pipeline until a decision, timeout, or revocation occurs. 14. Authorization Decision If and only if all prior steps succeed (including approval where required), the EB MUST authorize the action. 15. Execution The EB executes the action on the target system, transitioning lifecycle states per Section 8.2 as applicable. Execution failures MUST still produce an Observation with status = failed. 16. Observation Construction The EB MUST construct Observation(s) bound to: - envelope_id - execution_id - decision - result - side effects - applied policy 17. Attestation & Emission The EB MUST: - attach an attestation - sign the Observation - deliver it via the configured Observation Channel Vandoulas Expires 15 January 2027 [Page 39] Internet-Draft AIDP July 2026 18. Audit Recording The EB MUST record: - envelope digest - decision (including approval decisions) - all lifecycle transitions - execution_id - final status - emitted Observation digest(s) 16.14.3 Agent Runtime Validation Pipeline (OB/PD) Upon receiving an Observation or Problem Details message, the AR MUST perform: 1. Parse & Schema Validate 2. Canonicalize 3. Verify Attestation Proof 4. Verify Issuer Trust 5. Bind to Outstanding Intent 6. Enforce Replay Protection 7. Classify: Lifecycle Observation vs Terminal Observation (Section 8.5) 8. Accept; release the intent's causal reasoning gate ONLY for validated terminal Observations 9. Failure Classification and Retry Suppression If an Observation or Problem Details message indicates a deterministic failure (including but not limited to CONSTRAINT_VIOLATION, NOT_AUTHORIZED, POLICY_REFUSED, APPROVAL_DENIED, or any non-retriable execution_advice), the Agent Runtime MUST NOT re-issue an Intent Envelope whose canonical payload is identical to the failed intent. The Agent Runtime MUST either: - revise the intent semantics (e.g., constraints or intent_body), or - abort the reasoning path, or - require explicit operator or policy override. To enforce retry suppression deterministically, the Agent Runtime SHOULD maintain a cache of recently failed intent digests, computed as a hash over the canonical signing input of the Intent Envelope payload. Vandoulas Expires 15 January 2027 [Page 40] Internet-Draft AIDP July 2026 Re-issuance of an Intent with an identical digest following a deterministic failure SHOULD be suppressed for a deployment-defined cooldown period. If any step fails, the Observation MUST be rejected and MUST NOT advance agent reasoning. Deterministic failures are failures for which re-execution of an identical intent is not expected to yield a different outcome, absent a change in constraints, authority, or policy state. Examples include constraint violations, authorization failures, approval denials, and explicit policy refusals. 16.14.4 Deterministic Agent Loop Guarantee An agent loop is compliant if and only if: No agent reasoning step that causally depends on an Intent Envelope occurs without a validated terminal Observation for that Intent. 16.14.5 Minimal Conformance Checklist An implementation claiming AIDP-HTTP compliance MUST implement: - full EB pipeline (including lifecycle and approval gates) - full AR pipeline - replay store - revocation resolver - attestation verification - audit logging 17. Security Considerations 17.1 Scope This section defines the threat model for AIDP systems, including attacker capabilities, assets, trust boundaries, and normative mitigations. Unless explicitly stated otherwise, all requirements in this section are normative. 17.2 Assets An AIDP deployment MUST treat the following as protected assets: Vandoulas Expires 15 January 2027 [Page 41] Internet-Draft AIDP July 2026 - AIDP Identity Material: Agent Identity objects and their validation artifacts. - Capabilities: Authority objects, including parent/derived relationships and constraint sets. - Delegation Chains: Ordered proof of authority derivation across one or more domains. - Intent Envelopes: Including envelope_id, actor_ref, authority_ref, constraints, and hooks. - Observations: Including attestation and bindings to prior intents. - Approval Decisions: Approval objects and their proofs (Section 8.3.2). - Audit Trail: Immutable records sufficient to reconstruct intent-execution-observation causality, including lifecycle transitions. - Execution Targets: External resources/services whose state can be modified by actions. 17.3 Trust Boundaries and Security Domains AIDP recognizes the following boundaries: - TB-1: Agent Runtime <-> Execution Boundary The Agent Runtime is untrusted for enforcement. The Execution Boundary is the policy enforcement point. - TB-2: Domain A <-> Domain B Cross-domain interactions MUST assume zero implicit trust. - TB-3: Authority Service <-> Verifiers Capability issuance and revocation status MUST be independently verifiable. - TB-4: Observation Channel <-> Agent Observation delivery MUST prevent substitution, replay, and confusion of results. - TB-5: Approval Authority <-> Execution Boundary Approval decisions MUST be attributable and MUST NOT be forgeable by agents or runtimes. Crossing any Trust Boundary MUST trigger independent identity, authority, chain, and revocation validation. 17.4 Attacker Model Attackers MAY possess one or more of the following capabilities: Vandoulas Expires 15 January 2027 [Page 42] Internet-Draft AIDP July 2026 - Network Adversary: Can observe, replay, delay, or reorder messages across a transport. - Malicious Agent: Can generate arbitrary Intent Envelopes and attempt to induce execution. - Compromised Agent Runtime: Can manipulate prompts, local state, tool outputs, and message ordering. - Compromised Execution Target: Can respond with misleading outputs or partial failures. - Insider: Possesses legitimate credentials or access in one domain. - Supply Chain/Implementation Bugs: Leverages parser ambiguities, canonicalization issues, and validation gaps. AIDP MUST remain secure against malicious agents and network adversaries. Compromise of the Execution Boundary is out of scope (if it fails, enforcement fails), but audit and containment SHOULD still limit blast radius. 17.5 Security Goals An AIDP system MUST provide: - G-1 Least Privilege: Capabilities constrain what may be executed. - G-2 Non-Repudiation of Control Flow: Audit can reconstruct who requested what, who approved it, and what executed. - G-3 Replay Resistance: Intents and observations cannot be reused to re-trigger actions. - G-4 Delegation Safety: Delegation cannot amplify privileges; revocation propagates. - G-5 Outcome Integrity: Observations are bound to the originating intent and execution. - G-6 Compromise Containment: A compromised agent cannot exceed granted authority or bypass approval gates. - G-7 Cross-Domain Robustness: No implicit trust crosses domain boundaries. - G-8 Oversight Integrity: Human approval gates cannot be bypassed, forged, or replayed. 17.6 Threats and Mitigations 17.6.1 Confused Deputy Threat: A less-privileged agent induces a more-privileged system/component to perform actions outside the attacker's authority. Mitigations (normative): Vandoulas Expires 15 January 2027 [Page 43] Internet-Draft AIDP July 2026 - The Execution Boundary MUST authorize based solely on validated authority_ref and delegation_chain, not on agent-provided explanations or natural-language intent. - The Execution Boundary MUST verify that the capability subject matches actor_ref (or matches a valid delegation subject in the chain). - Capabilities MUST encode the target resource(s) and permitted action(s) explicitly; wildcards SHOULD be avoided or constrained. 17.6.2 Privilege Escalation via Delegation Threat: An agent delegates authority beyond what it possesses (scope amplification), or a receiver misinterprets delegation semantics. Mitigations: - Delegated capabilities MUST be strict subsets of parent capabilities (Subsetting Rule). - Delegation chains MUST be validated end-to-end at execution time. - Receivers MUST reject any chain that contains an invalid or unverifiable link. - Revocation of a parent capability MUST invalidate all derived capabilities. 17.6.3 Replay of Intent Envelopes Threat: Reuse of an Intent Envelope to trigger repeated execution (financial transfers, destructive actions). Mitigations: - envelope_id MUST be globally unique and MUST NOT be accepted more than once per relevant replay window. - Execution Boundaries MUST maintain replay state appropriate to the risk profile of the action class. - Constraints SHOULD include explicit idempotency requirements for side-effectful actions. - When an Execution Boundary (EB) receives an Intent Envelope (IE) whose envelope_id has already been processed, the EB MUST treat the request as a replay and MUST NOT re-execute the intent. Vandoulas Expires 15 January 2027 [Page 44] Internet-Draft AIDP July 2026 If a corresponding Observation (OB) has already been produced and is still within the EB's observation retention window, the EB SHOULD return the previously generated Observation or provide a deterministic mechanism for the Agent to retrieve it (e.g., via an observation retrieval endpoint). A replayed envelope_id MUST NOT result in a new execution or a semantically distinct outcome. Whether a replayed Intent results in an inline Observation, a retrieval pointer, or a REPLAY_DETECTED Problem Details response is deployment- and transport-binding-specific. In all cases, the EB MUST NOT re-execute the intent. 17.6.4 Replay or Substitution of Observations Threat: An attacker replays a prior Observation or substitutes a different Observation to steer reasoning. Mitigations: - Observations MUST include envelope_id and execution_id. - Observations MUST carry an attestation from the Execution Boundary. - Agents MUST reject Observations that do not match an outstanding Intent Envelope. - Agents MUST NOT progress reasoning for an intent until a valid bound terminal Observation is received. 17.6.5 Parameter Confusion and Canonicalization Attacks Threat: Ambiguities in serialization or parsing allow an attacker to smuggle parameters or exploit differences between validators and executors. Mitigations: - Implementations MUST define a canonical representation for signing/verifying (even if encoding is out of scope, the "to-be-verified" form MUST be unambiguous). - Validators and executors MUST share identical parsing and validation logic. - Unknown fields in security-relevant sections MUST be rejected or handled by strict extension rules. 17.6.6 Time-of-Check / Time-of-Use (TOCTOU) on Revocation Vandoulas Expires 15 January 2027 [Page 45] Internet-Draft AIDP July 2026 Threat: A capability is valid at validation time but revoked before execution completes; or cache staleness causes use of revoked authority. Long-lived intents (pending_approval, waiting, paused) widen this window substantially. Mitigations: - Execution Boundaries MUST check revocation status at execution time, not solely at receipt time, for high-risk actions. - Execution Boundaries MUST re-check revocation status and constraint windows when an intent leaves pending_approval, waiting, or paused (Section 8.4). - Revocation mechanisms MUST support near-immediate effect. - Deployments SHOULD define risk tiers: low-risk actions MAY tolerate bounded staleness; high-risk actions MUST NOT. 17.6.7 Compromised Agent Runtime / Prompt Injection Threat: The agent runtime is manipulated so the reasoning engine emits malicious intents or misinterprets observations. Mitigations: - Enforcement MUST occur at the Execution Boundary, not in the agent. - Capabilities MUST be constrained such that unintended intents have limited impact. - Observation binding MUST prevent fabricated "success" states. - High-risk capabilities SHOULD require Human Approval Gates (Section 8.3), which operate outside agent reasoning and cannot be released by agent-generated messages. 17.6.8 Cross-Domain Identity and Issuer Spoofing Threat: An attacker forges identities/capabilities from an untrusted issuer or exploits issuer confusion. Mitigations: - Domains MUST maintain explicit trust anchors for issuers. - All identities and capabilities MUST include issuer identification. - If issuer validation fails, the intent MUST be rejected. 17.6.9 Forged or Coerced Approvals Vandoulas Expires 15 January 2027 [Page 46] Internet-Draft AIDP July 2026 Threat: An attacker forges an approval decision, replays a prior approval, or induces an Approval Authority to approve a different intent than the one displayed (approval confusion). Mitigations: - Approval objects MUST be bound to exactly one envelope_id and SHOULD carry a proof over (envelope_id, decision, timestamp) (Section 8.3.2). - Approval MUST apply to the canonical payload; post-approval modification voids the approval (Section 8.3.2, rule 6). - Approval Authorities SHOULD be shown, and SHOULD sign over, a digest of the canonical intent payload rather than a free-text summary alone. - Self-approval MUST be rejected (Section 8.3.2, rule 2). - Expired approvals (expires_at) MUST NOT authorize execution. 17.6.10 Audit Trail Gaps and Non-Attribution Threat: Missing logs prevent reconstruction of actions, enabling undetected abuse. Mitigations: - Execution Boundaries MUST log Intent Envelope receipt, authorization decision, approval decisions, lifecycle transitions, execution outcome, and Observation emission. - Audit records MUST include envelope_id, execution_id, actor_ref, authority_ref, and a digest of intent_body. 17.6.11 Denial of Service Threat: Flooding the Execution Boundary with envelopes or forcing expensive validation; parking large numbers of intents in pending_approval or waiting states to exhaust state storage. Mitigations: - Implementations SHOULD rate-limit by actor/issuer. - Validation SHOULD be staged (cheap rejection first). - Deployments MAY require preflight checks for costly operations. - Deployments SHOULD bound the number and lifetime of non-terminal intents per actor (approval_window_sec, not_after). 17.7 Residual Risk and Out-of-Scope Conditions Vandoulas Expires 15 January 2027 [Page 47] Internet-Draft AIDP July 2026 - If the Execution Boundary is fully compromised, authorization cannot be trusted. Deployments SHOULD still maintain independent audit and anomaly detection. - If the Execution Target returns misleading results, AIDP can ensure binding/attestation but cannot guarantee target truthfulness beyond attestation scope. - AIDP specifies the protocol states and messages for human approval; the selection, competence, and diligence of Approval Authorities are deployment concerns. 17.8 Security Requirements Summary Implementations claiming AIDP compliance MUST, at minimum: - Validate identity and issuer trust anchors at each Trust Boundary. - Enforce capabilities and delegation chain subsetting at execution time. - Support revocation with near-immediate effect for high-risk actions, including on resumption of long-lived intents. - Provide replay protection for intents and bound observations. - Enforce approval gates where required, with attributable, non-forgeable approval decisions. - Produce attestable observations linked to intents and executions. - Maintain auditable records sufficient for forensic reconstruction, including lifecycle transitions. 18. Governance & Compliance Considerations AIDP deployments SHOULD provide: - Comprehensive audit trails. - Policy-driven revocation procedures. - Capability lifecycle management. - Regulatory compliance support. Governance mechanisms MUST remain external to agent reasoning processes. The Human Approval Gate (Section 8.3) is the protocol surface through which governance policies act on individual intents; the policies themselves remain out of scope. 19. Extensibility Model 19.1 Principles Vandoulas Expires 15 January 2027 [Page 48] Internet-Draft AIDP July 2026 AIDP is intentionally extensible. Extensions MUST: - Preserve all normative validation requirements. - Avoid weakening identity, authority, or revocation semantics. - Declare compatibility with base AIDP semantics. 19.2 Extension Points The following protocol elements are extension points, each backed by a registry established in Section 20: - Message Types (msg_type): new message types beyond IE/OB/PD (e.g., capability negotiation messages). - Error Codes (error_code): new Problem Details classifications. - Lifecycle States (status): new non-terminal states within a MAJOR version; terminal states MUST NOT be redefined. - Constraint Types (constraints.*): new constraint fields with defined enforcement semantics. - Observation Types / Fields: new optional OB payload members. - Attestation Profiles (attest_profile): new attestation formats and evidence models. - Authority Profiles: new capability representation formats (e.g., UCAN-based, ZCAP-based profiles). - Canonicalization Profiles (canon): new canonical signing input definitions. 19.3 Extension Processing Rules 1. Unknown extension elements in security-critical objects (actor_ref, authority_ref, delegation_chain, attestation, proof) MUST cause rejection. 2. Unknown extension elements elsewhere MUST be ignored if the message version is within the receiver's supported MAJOR version (Section 12.2). 3. An extension that alters validation, authorization, lifecycle, or replay semantics MUST be negotiated explicitly (via Capability Discovery or prior configuration) and MUST NOT be assumed from message content alone. 4. Registered extensions MUST specify their interaction with the validation pipeline (Section 16.14). 20. IANA Considerations This document requests the creation of the following registries, grouped under an "Agent Interaction & Delegation Protocol (AIDP)" heading. For all registries, the registration policy is Specification Required (RFC 8126), with a designated expert review focused on security impact per Section 19. Vandoulas Expires 15 January 2027 [Page 49] Internet-Draft AIDP July 2026 [NOTE TO RFC EDITOR / IANA: registry creation is contingent on adoption; initial contents below.] 20.1 AIDP Message Types Registry Initial contents: Value Description Reference ----- ------------------------- -------------- IE Intent Envelope This document OB Observation This document PD Problem Details This document 20.2 AIDP Error Codes Registry Initial contents: INVALID_IDENTITY, UNTRUSTED_ISSUER, REVOKED, INVALID_CAPABILITY, INVALID_DELEGATION_CHAIN, CONSTRAINT_VIOLATION, REPLAY_DETECTED, MALFORMED_MESSAGE, UNSUPPORTED_VERSION, APPROVAL_DENIED, APPROVAL_TIMEOUT, LIFECYCLE_INVALID_TRANSITION (all: This document). 20.3 AIDP Lifecycle States Registry Initial contents: submitted, pending_approval, approved, accepted, running, waiting, delegated, paused, completed, partially_completed, failed, cancelled, rejected (all: This document; terminal flags per Section 8.1). The deprecated aliases "executed" and "partially_executed" are recorded for historical compatibility. 20.4 AIDP Constraint Types Registry Initial contents: not_before, not_after, max_cost, max_uses, risk_tier, requires_approval, approval_window_sec, idempotency_key (all: This document). 20.5 AIDP Attestation Profiles Registry Initial contents: Value Description Reference ---------------- ------------------------------- -------------- AIDP-OB-Attest1 Baseline EB attestation profile This document 20.6 AIDP Authority Profiles Registry Initial contents: Vandoulas Expires 15 January 2027 [Page 50] Internet-Draft AIDP July 2026 Value Description Reference ---------------- ------------------------------- -------------- AIDP-Cap-Base1 Baseline capability profile This document (Section 6.1 field model) 20.7 AIDP Canonicalization Profiles Registry Initial contents: Value Description Reference ---------------- ------------------------------- -------------- AIDP-JS-Canon1 Canonical JSON per Section 14.3 This document AIDP-CB-Canon1 Canonical CBOR per Section 14.3 This document 20.8 Media Types This document requests registration of the media types application/aidp+json and application/aidp+cbor with the optional "msg" parameter (Section 16.3), following the procedures of RFC 6838. 21. Acknowledgements The authors acknowledge the emerging agent systems community whose practical challenges motivated the creation of this protocol, and the participants of the IETF 125 discussion whose feedback shaped the scope clarification, lifecycle model, and oversight mechanisms introduced in this version. 22. References 22.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017. 22.2. Informative References Vandoulas Expires 15 January 2027 [Page 51] Internet-Draft AIDP July 2026 [GNAP] Richer, J. and F. Imbault, "Grant Negotiation and Authorization Protocol", RFC 9635, October 2024. [RAR] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, May 2023. [ZCAP] Sporny, M., Longley, D., and D. Chadwick, "Authorization Capabilities for Linked Data", W3C Community Group Draft Report, https://w3c-ccg.github.io/zcap-spec/. [UCAN] Fission Codes, "User Controlled Authorization Networks (UCAN)", https://ucan.xyz/. [SCIM] Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C. Mortimore, "System for Cross-domain Identity Management: Core Schema", RFC 7643, September 2015. [MCP] Anthropic, "Model Context Protocol", https://modelcontextprotocol.io/. [A2A] A2A Project (Linux Foundation), "Agent2Agent (A2A) Protocol", https://a2a-protocol.org/. [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013. Appendix A. Example Wire Messages (Informative) This appendix is informative. Examples use AIDP-JS. A.1 Intent Envelope (single-agent -> server) Vandoulas Expires 15 January 2027 [Page 52] Internet-Draft AIDP July 2026 { "aidp_version": "1.0", "msg_type": "IE", "canon": "AIDP-JS-Canon1", "payload": { "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10", "timestamp": "2026-07-14T09:14:00+02:00", "actor_ref": { "agent_id": "agent:alpha", "issuer": "did:example:issuerA", "identity_ref": "urn:aidp:id:issuerA:agent-alpha" }, "authority_ref": { "cap_id": "cap:alpha:pay-v1", "issuer": "did:example:authA", "cap_ref": "urn:aidp:cap:authA:cap-alpha-pay-v1", "rev_ref": "urn:aidp:rev:authA:list-01" }, "intent_body": { "action": "payment.create", "target": { "domain": "svc:payments", "resource": "acct:merchant-123" }, "parameters": { "amount": 50, "currency": "EUR", "memo": "invoice-8841" } }, "constraints": { "not_before": "2026-07-14T09:14:00+02:00", "not_after": "2026-07-14T09:19:00+02:00", "max_uses": 1, "risk_tier": "high", "requires_approval": true, "approval_window_sec": 3600, "idempotency_key": "idem-3d7f0d" }, "delegation_chain": [], "observability_hooks": { "delivery_mode": "push", "return_to": { "type": "inbox", "ref": "urn:aidp:inbox:agent:alpha" }, "required_fields": ["envelope_id", "execution_id", "status", "attestation"], "lifecycle_updates": true, "timeout_sec": 30 } }, "proof": { "alg": "ed25519", "kid": "key:agent-alpha-1", "sig": "BASE64URL(...)" } Vandoulas Expires 15 January 2027 [Page 53] Internet-Draft AIDP July 2026 } A.2 Lifecycle Observation: pending_approval { "aidp_version": "1.0", "msg_type": "OB", "canon": "AIDP-JS-Canon1", "payload": { "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10", "execution_id": "exec-9c2d1a", "timestamp": "2026-07-14T09:14:01+02:00", "status": "pending_approval", "result": {}, "side_effects": [], "lifecycle": { "prior_status": "submitted", "cause": "constraints.requires_approval", "expected_next_update_sec": 600 }, "attestation": { "boundary_id": "boundary:payments-gw-1", "issuer": "did:example:paymentsDomain", "attest_profile": "AIDP-OB-Attest1", "decision": "pending_approval", "policy_digest": "sha256:5d3a...e91" } }, "proof": { "alg": "ed25519", "kid": "key:boundary-payments-1", "sig": "BASE64URL(...)" } } A.3 Terminal Observation: completed (after approval) { "aidp_version": "1.0", "msg_type": "OB", "canon": "AIDP-JS-Canon1", "payload": { "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10", "execution_id": "exec-9c2d1a", "timestamp": "2026-07-14T09:22:02+02:00", "status": "completed", "result": { "payment_id": "pay_7712", "state": "captured" }, "side_effects": [ { "resource": "acct:merchant-123", "delta": { "captured_eur": 50 } } ], Vandoulas Expires 15 January 2027 [Page 54] Internet-Draft AIDP July 2026 "approval": { "approval_id": "appr-51ce", "approver_ref": { "principal": "user:cfo@example", "issuer": "did:example:corpIdP" }, "decision": "approved", "timestamp": "2026-07-14T09:21:40+02:00", "proof": { "alg": "ed25519", "kid": "key:cfo-1", "sig": "BASE64URL(...)" } }, "attestation": { "boundary_id": "boundary:payments-gw-1", "issuer": "did:example:paymentsDomain", "attest_profile": "AIDP-OB-Attest1", "decision": "authorized", "policy_digest": "sha256:5d3a...e91" } }, "proof": { "alg": "ed25519", "kid": "key:boundary-payments-1", "sig": "BASE64URL(...)" } } A.4 Problem Details (rejection example) { "aidp_version": "1.0", "msg_type": "PD", "canon": "AIDP-JS-Canon1", "payload": { "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10", "timestamp": "2026-07-14T09:14:01+02:00", "error_code": "REVOKED", "error_message": "Capability or identity has been revoked.", "details": { "rev_ref": "urn:aidp:rev:authA:list-01", "cap_id": "cap:alpha:pay-v1" } }, "proof": { "alg": "ed25519", "kid": "key:boundary-payments-1", "sig": "BASE64URL(...)" } } A.5 Problem Details (approval timeout) Vandoulas Expires 15 January 2027 [Page 55] Internet-Draft AIDP July 2026 { "aidp_version": "1.0", "msg_type": "PD", "canon": "AIDP-JS-Canon1", "payload": { "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10", "timestamp": "2026-07-14T10:14:01+02:00", "error_code": "APPROVAL_TIMEOUT", "error_message": "No approval decision within window.", "details": { "approval_window_sec": 3600, "final_status": "cancelled" }, "execution_advice": { "retriable": true, "retry_after_sec": 0, "reason_code": "APPROVAL_TIMEOUT" } }, "proof": { "alg": "ed25519", "kid": "key:boundary-payments-1", "sig": "BASE64URL(...)" } } Appendix B. Example Flows (Informative) B.1 Flow 1 -- Single-Agent Action (Agent <-> Server) Goal: Agent requests a state-changing action on an external service with bounded authority. Steps: 1. Agent Runtime obtains/holds a capability authority_ref. 2. Agent produces an Intent Envelope (IE) referencing actor_ref and authority_ref. 3. Execution Boundary validates: identity, issuer trust anchors, capability scope, revocation, constraints, replay. 4. Execution Boundary executes the action on the target service. 5. Execution Boundary emits an Observation (OB) bound to envelope_id and execution_id. 6. Agent MUST NOT proceed for that intent until OB is received and validated. Key security properties: - Enforcement at Execution Boundary, not the LLM - Replay resistance via envelope_id - Outcome integrity via OB attestation B.2 Flow 2 -- Delegation (Agent A -> Agent B -> Execution) Vandoulas Expires 15 January 2027 [Page 56] Internet-Draft AIDP July 2026 Goal: Agent A delegates limited authority to Agent B to perform a specific action. Steps: 1. Agent A possesses parent capability cap:A0. 2. Authority Service issues delegated capability cap:B1 with: - parent_cap_id = cap:A0 - scope subset (e.g., only resource=X, only max_uses=1, only within 2 minutes) 3. Agent A sends IE to Agent B with delegation_chain = [cap:B1 link proof ...] 4. Agent B either: - accepts responsibility and forwards IE to its Execution Boundary, or - rejects (policy/local risk) 5. Execution Boundary validates entire chain end-to-end (including parent/child linkage proofs). 6. Execution produces OB, returned to the return_to hook (Agent A and/or B depending on hook policy). Key security properties: - No credential sharing - Subsetting rule enforced at execution - Revocation propagates along chain B.3 Flow 3 -- Revocation Mid-Flight (TOCTOU) Goal: Capability revoked after IE issuance but before execution finalization. Steps: 1. IE is received and preliminarily validated. 2. Before executing high-risk action, Execution Boundary re-checks revocation status (per risk tier/policy). 3. If revoked, execution aborts and PD returned with REVOKED. 4. Audit record notes decision and revocation evidence used. B.4 Flow 4 -- Observation Substitution Attempt Goal: Network attacker tries to replay an old OB to trick the agent. Steps: Vandoulas Expires 15 January 2027 [Page 57] Internet-Draft AIDP July 2026 1. Attacker replays OB with mismatched or already-settled envelope_id. 2. Agent validates OB proof and checks if envelope_id is outstanding. 3. Agent rejects OB if: - envelope_id not outstanding, or - OB proof invalid, or - attestation issuer untrusted 4. Agent continues waiting or initiates recovery. B.5 Flow 5 -- Multi-Domain Boundary Crossing Goal: Agent in Domain A requests execution in Domain B. Steps: 1. Domain B applies TB rules: zero implicit trust. 2. Domain B validates issuer trust anchors for identities and capabilities. 3. Domain B validates revocation pointers accessible/acceptable under its policy. 4. If any issuer untrusted, reject with UNTRUSTED_ISSUER. B.6 Flow 6 -- Human Approval Gate Goal: High-risk intent held for human approval before execution. Steps: 1. IE with constraints.requires_approval = true passes full validation. 2. EB transitions intent to pending_approval; emits Lifecycle Observation (A.2). 3. Approval Authority reviews the canonical intent digest and signs a decision. 4. On "approved": intent transitions approved -> accepted -> running; EB re-checks revocation before execution. 5. On "denied" or timeout: intent transitions to cancelled; PD with APPROVAL_DENIED / APPROVAL_TIMEOUT. 6. Terminal OB includes the approval object (A.3). Appendix C. End-to-End Agentic Use Case (Informative) This appendix illustrates the full protocol across a realistic multi-agent, cross-domain, long-running scenario: a procurement agent delegating stock replenishment to a supplier-facing agent that executes against an ERP system. Vandoulas Expires 15 January 2027 [Page 58] Internet-Draft AIDP July 2026 C.1 Scenario - Agent A ("procurement-agent", Domain: corp.example) plans inventory replenishment. - Agent B ("supplier-agent", Domain: suppliers.example) negotiates and places orders. - ERP (Domain: erp.example) executes purchase orders behind its own Execution Boundary. - Corporate policy: purchase orders above EUR 10,000 require human approval by a procurement officer. Flow shape: Agent A | delegated IE (cap subset: supplier=S1, max EUR 12,000, | valid 24h, requires_approval above 10,000) v Agent B | IE (delegation_chain: [cap:B7 <- cap:A3]) v ERP Execution Boundary | lifecycle: submitted -> pending_approval -> approved | -> accepted -> running -> completed v Observation (attested, approval object included) | v Agent B (validates OB; releases its causal gate) | v Agent A (validates OB chain; reasoning continues) C.2 Step-by-Step 1. Delegation. The Authority Service of corp.example issues cap:B7 to Agent B with parent_cap_id = cap:A3. Scope is a strict subset: only action "po.create", only supplier S1, max_cost 12000, not_after +24h, requires_approval when parameters.total > 10000. 2. Intent. Agent B constructs an IE for "po.create" with parameters.total = 11500 and delegation_chain = [cap:B7 (link_proof to cap:A3)], observability_hooks with lifecycle_updates = true, and submits it to the ERP EB (cross-domain: TB-2 applies). Vandoulas Expires 15 January 2027 [Page 59] Internet-Draft AIDP July 2026 3. Validation. The ERP EB independently validates: Agent B's identity (issuer trust anchors of erp.example), cap:B7 authenticity, the delegation link to cap:A3, revocation status of both capabilities and both identities, constraints, and replay state (Section 16.14.1, steps 1-12). 4. Approval gate. Since total > 10000, the EB holds the intent in pending_approval and emits a Lifecycle Observation to both return_to hooks. Agent B's runtime does NOT advance its causal reasoning; it schedules a wake-up. Agent A's runtime records the pending state for its parent intent, which is in state delegated. 5. Human decision. A procurement officer (Approval Authority, identity from corp.example's IdP, satisfying the no-self-approval rule) reviews the canonical intent digest and signs "approved". 6. Execution. The EB re-checks revocation (TOCTOU rule for resumption), transitions approved -> accepted -> running, creates the purchase order in the ERP, and emits a terminal Observation with status = completed, the approval object, and an attestation signed by boundary:erp-gw-1. 7. Propagation. Agent B validates the OB (proof, issuer trust, binding, replay), releases its causal gate, and reports completion to Agent A -- either by forwarding the attested OB or via its own OB referencing it. Agent A validates in turn, transitions its parent intent delegated -> completed, and its reasoning continues with a verified, auditable outcome. C.3 Properties Demonstrated - Delegation with subsetting and end-to-end chain validation across three administrative domains. - Human approval as protocol state, invisible to and unbypassable by agent reasoning. - Long-running lifecycle (pending_approval, delegated) with Lifecycle Observations preventing "lost intent" ambiguity. - Attested outcome propagating back through the delegation chain, keeping both agents' control loops deterministic. - Full audit reconstruction: who intended, who delegated, who approved, what executed, what resulted. Appendix D. Reference Architecture (Informative) Vandoulas Expires 15 January 2027 [Page 60] Internet-Draft AIDP July 2026 This appendix describes a reference architecture for AIDP deployments. It is informative; the normative component obligations appear in Sections 3, 9, and 16. D.1 Logical Components 1. Reasoning Engine (RE): Produces Intent Envelopes and consumes Observations. (Often an LLM, but not required.) 2. Agent Runtime (AR): Hosts the RE; manages local state, memory, and tool mediation. The AR is not a policy enforcement point. 3. Execution Boundary (EB): Policy enforcement and action execution component. 4. Authority Service (AS): Issues Capabilities, manages lifecycle, and provides revocation status via rev_ref. 5. Identity Provider / Issuer (IdP): Issues Agent Identity artifacts referenced by actor_ref. 6. Observation Channel (OC): Delivers Observations via push and/or pull. 7. Audit Log (AL): Append-only event record. 8. Execution Targets (ET): External systems acted upon. 9. Approval Service (AP): Presents held intents to Approval Authorities and returns signed decisions to the EB (Section 8.3). D.2 Reference Diagram +--------------------- Domain A ----------------------+ | | | +------------+ +----------------------------+ | | | Reasoning | | Agent Runtime (AR) | | | | Engine (RE)|<---->| - builds IE payload | | | +------------+ | - validates OB proofs | | | ^ | - manages local state | | | | +--------------+-------------+ | | | | IE (AIDP) | | | v | | +-----+------+ TB-AR/EB +---------------+ | | | Observation|<------------------ | Execution | | | | Channel(OC)| OB (AIDP) | Boundary (EB) | | | +-----------++ | - validates IE| | | | | - lifecycle | | | | | - approval | | | | | gate | | | | | - replay store| | | | | - executes | | | | | - attests OB | | | | +--+---------+--+ | | | | | | | | +---v--+ +---v---+| | | | Audit| | Auth || Vandoulas Expires 15 January 2027 [Page 61] Internet-Draft AIDP July 2026 | | | Log | | Svc || | | +------+ +---+---+| | | ^ | | | +-----------+ | | | | | Approval |---------->| | | | | Service | decisions | | | +-----------+ | | | +-----------+ | | | | Identity | | | | | Issuer | | | | +-----------+ | | | actions | | v | | +----------------+ | | | Execution | | | | Targets (ET) | | | +----------------+ | +------------------------------------------------------+ D.3 Data Flow (Single Domain) RE -> AR: propose action AR -> EB: IE(envelope_id, actor_ref, authority_ref, constraints, hooks) EB -> AS/IdP: validate capability + identity + revocation EB -> AP: (if gated) request approval decision EB -> ET: execute action EB -> AL: write audit events (incl. lifecycle transitions) EB -> OC: emit OB(attested) OC -> AR: deliver OB AR -> RE: provide validated OB for next-step reasoning D.4 Deployment Profiles Minimal Profile (Single Domain): Required: RE, AR, EB, AS (or embedded capability verifier), OC, AL. Optional: external IdP, AP (only if approval gates used). Multi-Domain Profile: Required: EB and trust anchor policy per domain, cross-domain issuer validation, revocation accessibility policy, OC bridging rules. D.5 Failure Modes Vandoulas Expires 15 January 2027 [Page 62] Internet-Draft AIDP July 2026 - If AS/IdP is unreachable for a high-risk action, EB fails closed (reject) unless local policy explicitly permits bounded staleness. - If OB delivery fails, EB supports pull-based retrieval via OC to avoid "lost observations". - If replay is detected, EB rejects with REPLAY_DETECTED and logs the attempt. - If the Approval Service is unreachable, gated intents remain in pending_approval until approval_window_sec expires, then cancel. Appendix E. Conformance Test Suite Outline (Informative) E.1 Purpose This appendix outlines a test framework for validating whether an implementation is compliant with the AIDP specification. It enables certification of implementations, interoperability between vendors, and objective security verification. E.2 Certification Levels Level 1 -- AIDP-Core: Minimal functional compliance. Level 2 -- AIDP-Secure: Includes full security & revocation semantics. Level 3 -- AIDP-Enterprise: Includes auditability, cross-domain, governance & recovery. E.3 Core Test Categories Identity & Trust: - T-ID-01: Reject invalid issuer - T-ID-02: Reject expired identity - T-ID-03: Enforce trust anchors - T-ID-04: Revalidate across trust boundary Capability & Authority: - T-AUTH-01: Enforce action scope - T-AUTH-02: Enforce resource scope - T-AUTH-03: Enforce constraints - T-AUTH-04: Reject capability amplification Delegation: - T-DEL-01: Validate delegation chain - T-DEL-02: Reject broken chain - T-DEL-03: Enforce subsetting rule - T-DEL-04: Revoke parent invalidates children Vandoulas Expires 15 January 2027 [Page 63] Internet-Draft AIDP July 2026 Revocation: - T-REV-01: Immediate revocation enforcement - T-REV-02: Revocation after acceptance but before execution - T-REV-03: Revocation during execution (high risk path) - T-REV-04: Revocation while pending_approval / waiting / paused Intent Envelope: - T-IE-01: Canonicalization correctness - T-IE-02: Proof verification - T-IE-03: Reject malformed envelope - T-IE-04: Enforce required fields Lifecycle: - T-LC-01: Enforce permitted transitions only - T-LC-02: Terminal states are final - T-LC-03: Constraint expiry cancels held intents - T-LC-04: Lifecycle Observations do not release causal gates Approval Gates: - T-AP-01: Gate triggers per constraint/policy - T-AP-02: Reject self-approval - T-AP-03: Denial produces APPROVAL_DENIED and cancels - T-AP-04: Timeout produces APPROVAL_TIMEOUT and cancels - T-AP-05: Post-approval mutation voids approval - T-AP-06: Approval proof verification Execution & Enforcement: - T-EX-01: Reject without valid authority - T-EX-02: Enforce constraints before execution - T-EX-03: Execute only after full validation - T-EX-04: Reject on replay Observation & Feedback Binding: - T-OB-01: Bind OB to correct envelope_id - T-OB-02: Reject mismatched OB - T-OB-03: Enforce deterministic agent loop - T-OB-04: Reject unsigned OB Replay & Ordering: - T-RPL-01: Detect duplicate envelope_id - T-RPL-02: Reject reused execution_id - T-RPL-03: Maintain replay window Version & Extensibility: - T-VER-01: Reject unsupported MAJOR with supported_versions - T-VER-02: Ignore unknown non-critical fields within MAJOR - T-VER-03: Reject unknown fields in security-critical objects Vandoulas Expires 15 January 2027 [Page 64] Internet-Draft AIDP July 2026 Audit & Compliance: - T-AUD-01: Record full action trace - T-AUD-02: Reconstruct causal chain (incl. approvals) - T-AUD-03: Verify non-repudiation Cross-Domain & Federation: - T-XD-01: Enforce trust boundary - T-XD-02: Reject untrusted issuer - T-XD-03: Preserve delegation semantics across domains E.4 Failure Injection Tests - Network failure mid-execution - Revocation during processing - Observation delivery failure - Duplicate webhook delivery - Corrupted attestation - Malicious agent input - Approval service outage during pending_approval E.5 Compliance Declaration An implementation MAY claim "AIDP-Compliant: Level X" only after passing all tests for that certification level. Appendix F. Changes Since Previous Versions F.1 Changes Since draft-vandoulas-aidp-02 Restructuring (protocol-first): - Moved non-normative material (example messages, example flows, reference architecture, conformance test outline) from the main body to informative Appendices A-E. Normative content (wire format, schemas, HTTP binding, validation pipeline) remains in the main body. Scope clarification: - Added Section 1.2 "Why AIDP Exists", stating the protocol innovation explicitly: standardization of the complete Intent -> Authority -> Execution -> Observation -> Reasoning Continuation lifecycle. - Sharpened the definition of the Intent Envelope as a cryptographically attributable execution request, with normative consequences (Section 7.1). New protocol machinery: Vandoulas Expires 15 January 2027 [Page 65] Internet-Draft AIDP July 2026 - Added the Intent Lifecycle Model (Section 8): normative states (submitted, pending_approval, approved, accepted, running, waiting, delegated, paused, completed, partially_completed, failed, cancelled, rejected), transition rules, and audit requirements. Deprecated OB status values "executed" / "partially_executed" in favor of "completed" / "partially_completed" (with alias compatibility). - Added Human Approval Gates (Section 8.3): pending_approval as a protocol state enforced at the Execution Boundary, approval objects with attributable proofs, no-self-approval rule, approval windows, and the APPROVAL_DENIED / APPROVAL_TIMEOUT error codes. - Added support for long-running and multi-step executions (Section 8.4): waiting/paused/delegated semantics, resumption revocation re-checks, progress visibility via Lifecycle Observations (Section 8.5). - Added Version Negotiation (Section 12): MAJOR.MINOR semantics, compatibility rules, supported_versions advertisement, and downgrade protection. - Added Capability Discovery (Section 13) as an OPTIONAL, advisory extension point, with an HTTP binding (Section 16.12). Positioning: - Added explicit relationship sections for the Model Context Protocol (Section 4.5) and the Agent2Agent protocol (Section 4.6), describing layering and composition rather than competition. Extensibility and IANA: - Expanded the Extensibility Model (Section 19) with named extension points and processing rules. - Populated IANA Considerations (Section 20) with requested registries: message types, error codes, lifecycle states, constraint types, attestation profiles, authority profiles, canonicalization profiles, and media type registrations. Security: - Added TB-5 (Approval Authority boundary), security goal G-8 (Oversight Integrity), and a new threat section on forged or coerced approvals (Section 17.6.9). - Extended TOCTOU mitigations to long-lived intents and resumption paths (Section 17.6.6); extended DoS considerations to state-parking attacks (Section 17.6.11). Examples: Vandoulas Expires 15 January 2027 [Page 66] Internet-Draft AIDP July 2026 - Added an end-to-end agentic use case (Appendix C): cross-domain, delegated ERP procurement with a human approval gate and lifecycle observations. - Updated wire examples to include approval and lifecycle messages (Appendix A). F.2 Changes Since draft-vandoulas-aidp-00 (historical) - Clarified replay semantics to explicitly distinguish replay detection from re-execution, and to require deterministic result recovery without side effects. - Introduced explicit Observation retention and pull-based recovery requirements. - Refined agent control loop semantics to permit parallel, causally-independent intents. - Hardened canonicalization and parsing requirements (duplicate JSON member rejection). - Added explicit identity resolution profiles (dereferenceable and self-contained). - Strengthened observability hook security (pre-authorized endpoints, SSRF protections). - Introduced execution_advice and deterministic retry suppression. Authors' Addresses Ioannis Vandoulas Mechapiens Email: contact@mechapiens.com Vandoulas Expires 15 January 2027 [Page 67]