Internet Engineering Task Force T.P. Paxton Internet-Draft Apollo Deploy Intended status: Standards Track 2 September 2026 Expires: 6 March 2027 Agent Infrastructure Control Protocol draft-paxton-aicp-00 Abstract Autonomous software agents increasingly inspect and modify infrastructure through provider-specific APIs and generic tool protocols. Those interfaces expose operations, but they do not provide a common semantic contract for obtaining bounded situational context, expressing an intended outcome under constraints, reviewing the exact material effects, binding authorization to those effects, observing durable execution, and determining whether the intended outcome was achieved. This document specifies the Agent Infrastructure Control Protocol (AICP). AICP is a transport-independent object and lifecycle model for capability discovery, situations, intents, plans, authorization decisions, asynchronous operations, verified outcomes, machine- actionable problems, and reconciliation. It also specifies an HTTP binding and describes mappings to existing agent protocols. AICP does not replace cloud resource APIs, orchestration languages, agent- to-agent protocols, authentication systems, or provider policy engines. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 March 2027. Paxton Expires 6 March 2027 [Page 1] Internet-Draft AICP September 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope of the Contribution . . . . . . . . . . . . . . . . 5 1.2. Layering . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 3. Design Goals and Non-Goals . . . . . . . . . . . . . . . . . 8 3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Linked Control Objects . . . . . . . . . . . . . . . . . 9 4.2. Separation of Responsibilities . . . . . . . . . . . . . 10 4.3. Bindings and Profiles . . . . . . . . . . . . . . . . . . 10 4.4. Preview and Execute-if-Ready . . . . . . . . . . . . . . 10 5. Common Data Model . . . . . . . . . . . . . . . . . . . . . . 10 5.1. JSON Encoding . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Common Members . . . . . . . . . . . . . . . . . . . . . 11 5.3. Resource References . . . . . . . . . . . . . . . . . . . 12 5.4. Extension Processing . . . . . . . . . . . . . . . . . . 13 5.5. Structured Semantics and Prose . . . . . . . . . . . . . 13 6. Discovery and Capabilities . . . . . . . . . . . . . . . . . 13 6.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 13 6.2. Capability Document . . . . . . . . . . . . . . . . . . . 14 6.3. Principal Scoping and Freshness . . . . . . . . . . . . . 14 7. Situation Acquisition . . . . . . . . . . . . . . . . . . . . 15 7.1. Situation Request . . . . . . . . . . . . . . . . . . . . 15 7.2. Situation Representation . . . . . . . . . . . . . . . . 15 7.3. Consistency and Use . . . . . . . . . . . . . . . . . . . 16 8. Intent Requests . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Required Semantics . . . . . . . . . . . . . . . . . . . 16 8.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 17 8.3. Success Criteria . . . . . . . . . . . . . . . . . . . . 17 8.4. Intent Example . . . . . . . . . . . . . . . . . . . . . 17 9. Plans and Authorization . . . . . . . . . . . . . . . . . . . 18 Paxton Expires 6 March 2027 [Page 2] Internet-Draft AICP September 2026 9.1. Plan Purpose and Immutability . . . . . . . . . . . . . . 18 9.2. Basis, Changes, and Steps . . . . . . . . . . . . . . . . 19 9.3. Feasibility, Authorization, and Readiness . . . . . . . . 19 9.4. Approval Binding . . . . . . . . . . . . . . . . . . . . 20 9.5. Risk and Blast Radius . . . . . . . . . . . . . . . . . . 20 9.6. Preconditions, Assumptions, and Unknowns . . . . . . . . 21 9.7. Structured Next Actions . . . . . . . . . . . . . . . . . 21 10. Execution and Operation Lifecycle . . . . . . . . . . . . . . 21 10.1. Execution Request . . . . . . . . . . . . . . . . . . . 21 10.2. Operation Resource . . . . . . . . . . . . . . . . . . . 22 10.3. Phases . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.4. Effect State . . . . . . . . . . . . . . . . . . . . . . 23 10.5. Progress . . . . . . . . . . . . . . . . . . . . . . . . 24 10.6. Cancellation, Pause, and Resume . . . . . . . . . . . . 24 10.7. Events . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. Outcomes, Verification, and Evidence . . . . . . . . . . . . 24 11.1. Outcome Resource . . . . . . . . . . . . . . . . . . . . 24 11.2. Criterion Results . . . . . . . . . . . . . . . . . . . 25 11.3. Evidence References . . . . . . . . . . . . . . . . . . 25 11.4. Compensation . . . . . . . . . . . . . . . . . . . . . . 25 12. Problems and Recovery Semantics . . . . . . . . . . . . . . . 25 12.1. Problem Representation . . . . . . . . . . . . . . . . . 26 12.2. Core Problem Codes . . . . . . . . . . . . . . . . . . . 26 12.3. Recovery Actions . . . . . . . . . . . . . . . . . . . . 28 13. Idempotency, Concurrency, and Reconciliation . . . . . . . . 28 13.1. Request Deduplication . . . . . . . . . . . . . . . . . 28 13.2. Optimistic Concurrency . . . . . . . . . . . . . . . . . 28 13.3. No Exactly-Once Assumption . . . . . . . . . . . . . . . 29 13.4. Reconciliation Procedure . . . . . . . . . . . . . . . . 29 14. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . 29 14.1. General Requirements . . . . . . . . . . . . . . . . . . 29 14.2. Well-Known Discovery . . . . . . . . . . . . . . . . . . 30 14.3. Resource Interaction Pattern . . . . . . . . . . . . . . 30 14.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . 31 14.5. Entity Tags and Conditional Execution . . . . . . . . . 32 14.6. Asynchronous Preference and Waiting . . . . . . . . . . 32 14.7. Caching and Bounded Transfer . . . . . . . . . . . . . . 32 14.8. Correlation and Telemetry . . . . . . . . . . . . . . . 33 15. Relationship to Agent Protocols . . . . . . . . . . . . . . . 33 15.1. Model Context Protocol . . . . . . . . . . . . . . . . . 33 15.2. Agent2Agent Protocol . . . . . . . . . . . . . . . . . . 34 15.3. Agent Execution Protocol . . . . . . . . . . . . . . . . 34 16. Agent Ergonomics and Resource Efficiency . . . . . . . . . . 34 16.1. Progressive Disclosure . . . . . . . . . . . . . . . . . 34 16.2. Stable Machine Semantics . . . . . . . . . . . . . . . . 34 16.3. Accretive Context . . . . . . . . . . . . . . . . . . . 35 16.4. Least-Call Behavior . . . . . . . . . . . . . . . . . . 35 16.5. Decision Quality Without Private Reasoning . . . . . . . 35 Paxton Expires 6 March 2027 [Page 3] Internet-Draft AICP September 2026 17. Profiles, Versioning, and Extensibility . . . . . . . . . . . 35 17.1. Profile Requirements . . . . . . . . . . . . . . . . . . 35 17.2. Core Version Negotiation . . . . . . . . . . . . . . . . 36 17.3. Schema Evolution . . . . . . . . . . . . . . . . . . . . 36 18. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 36 18.1. Core Provider . . . . . . . . . . . . . . . . . . . . . 36 18.2. Core Client . . . . . . . . . . . . . . . . . . . . . . 36 18.3. Profile Conformance . . . . . . . . . . . . . . . . . . 37 18.4. Minimum Test Cases . . . . . . . . . . . . . . . . . . . 37 19. Operational Considerations . . . . . . . . . . . . . . . . . 37 19.1. Retention and Resumption . . . . . . . . . . . . . . . . 37 19.2. Backpressure and Resource Exhaustion . . . . . . . . . . 38 19.3. Revocation and Emergency Stop . . . . . . . . . . . . . 38 19.4. Clock and Expiry . . . . . . . . . . . . . . . . . . . . 38 20. Security Considerations . . . . . . . . . . . . . . . . . . . 38 20.1. Confused Deputy and Cross-Tenant Access . . . . . . . . 38 20.2. Stale Plan and Time-of-Check/Time-of-Use . . . . . . . . 38 20.3. Approval Substitution and Phishing . . . . . . . . . . . 39 20.4. Prompt Injection, Schema Poisoning, and Tool Shadowing . . . . . . . . . . . . . . . . . . . . . . . 39 20.5. Replay, Duplicate Effects, and Retry Storms . . . . . . 39 20.6. Provider and Adapter Compromise . . . . . . . . . . . . 39 20.7. Secrets and Sensitive Data . . . . . . . . . . . . . . . 40 20.8. Autonomy and Blast Radius . . . . . . . . . . . . . . . 40 20.9. Audit Integrity . . . . . . . . . . . . . . . . . . . . 40 21. Privacy Considerations . . . . . . . . . . . . . . . . . . . 40 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 22.1. Media Type Registration . . . . . . . . . . . . . . . . 41 22.2. Well-Known URI Registration . . . . . . . . . . . . . . 42 22.3. AICP Problem Code Registry . . . . . . . . . . . . . . . 42 23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 24. Normative References . . . . . . . . . . . . . . . . . . . . 43 25. Informative References . . . . . . . . . . . . . . . . . . . 44 Appendix A. Worked HTTP Control Loop . . . . . . . . . . . . . . 46 Appendix B. Protocol Invariants . . . . . . . . . . . . . . . . 47 Appendix C. Open Issues for Subsequent Revisions . . . . . . . . 48 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 48 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48 1. Introduction Infrastructure control interfaces are commonly designed for human operators, provider SDKs, or declarative reconcilers. An autonomous caller can use those interfaces, but must often reconstruct essential control semantics from many provider-specific reads, natural-language descriptions, asynchronous job APIs, and unstructured error messages. The caller may be unable to determine whether a request was authorized, whether a preview is still valid, whether an interrupted Paxton Expires 6 March 2027 [Page 4] Internet-Draft AICP September 2026 mutation took effect, whether retry is safe, what side effects occurred, or which recovery action is permitted. Generic agent protocols improve invocation and interoperability, but an invocation envelope does not define the meaning of infrastructure control. Two providers can expose tools through the same protocol while using incompatible action names, state models, error semantics, and safety behavior. Conversely, existing infrastructure standards define valuable resource and orchestration models, but generally do not define a complete control contract optimized for an autonomous principal. AICP defines that contract as a linked control loop: 1. discover the capabilities available to the authenticated principal; 2. obtain a bounded, freshness-labelled situation; 3. state an intent, hard constraints, and success criteria; 4. receive a concrete, expiring plan with material changes, assumptions, unknowns, risk, feasibility, and authorization state; 5. bind approval and execution to that exact plan revision; 6. observe a durable asynchronous operation; 7. verify the actual outcome and side effects; and 8. reconcile or compensate when effects are uncertain or unacceptable. The protocol is designed so that each object supplies the decision inputs for the next stage and remains linked to its causes. This permits a different process, agent, or human operator to resume control without relying on a lossy transcript or private model state. 1.1. Scope of the Contribution Cloud Infrastructure Management Interface (CIMI) [CIMI], Cloud Application Management for Platforms (CAMP) [CAMP], Topology and Orchestration Specification for Cloud Applications (TOSCA) [TOSCA], Kubernetes [KUBERNETES], and related systems already define infrastructure resources and operations. Model Context Protocol (MCP) [MCP] and Agent2Agent Protocol (A2A) [A2A] already define agent integration mechanisms. OAuth, workload identity, and provider Paxton Expires 6 March 2027 [Page 5] Internet-Draft AICP September 2026 policy systems already address identity and authority. AICP therefore does not claim to be the first infrastructure API or the first agent protocol. Its contribution is the interoperable semantic boundary between an autonomous principal and an infrastructure control plane: the representation and lifecycle of situation, intent, exact plan, authority, execution, effect certainty, verified outcome, and recovery. 1.2. Layering AICP follows the architectural preference to profile and extend existing Internet protocols rather than define a monolithic agent protocol [AI-ARCH]. It defines a core model and an HTTP binding. Infrastructure vocabularies are supplied by profiles. MCP can expose AICP through a small set of tools, A2A can carry or delegate AICP objects, and provider adapters can map AICP profiles to native APIs. All bindings are expected to invoke the same provider planning, policy, execution, journaling, and verification services. AICP objects can reference existing resource representations rather than copying them. For example, a profile can use Kubernetes objects, a TOSCA service template, or a provider resource identifier as the target or arguments of an AICP action. 2. Conventions and Terminology 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 or semi-autonomous software system acting for a principal. A conforming client need not use artificial intelligence. Principal The authenticated security principal to which permissions, delegation, quotas, and audit records apply. It can represent an agent, workload, user, or service. Control plane A service that reads or changes infrastructure state, directly or through provider adapters. Paxton Expires 6 March 2027 [Page 6] Internet-Draft AICP September 2026 Resource An infrastructure object identified by a profile-defined type, provider-stable identifier, and optional scope and revision. Action A stable, profile-defined operation or outcome class advertised as a capability. Situation A bounded observation of resources, relationships, health, active operations, applicable constraints, and available actions, including freshness and coverage metadata. Intent A requested outcome expressed as an action, target, arguments, constraints, and success criteria. An intent is not an instruction to bypass planning or policy. Plan A provider-generated, revisioned, and expiring proposal for satisfying an intent, including exact material changes and decision metadata. Consequential action An action that can modify infrastructure state, incur cost, expose data, affect availability, alter authority, or produce another externally visible effect. Operation A durable representation of an execution attempt and its evolving control and effect state. Outcome A durable comparison between intended, expected, and observed effects after an operation reaches a terminal state. Effect state The provider's degree of certainty about external effects: none, possible, partial, complete, reversed, or unknown. Reconciliation An observation-oriented action used to determine actual infrastructure state when an operation's effects are uncertain. Compensation A new consequential action intended to counter some effects of an earlier action. Compensation is not assumed to restore identical prior state. Paxton Expires 6 March 2027 [Page 7] Internet-Draft AICP September 2026 Profile An independently versioned specification that defines resource types, actions, schemas, constraints, observations, and additional conformance requirements for an infrastructure domain. 3. Design Goals and Non-Goals 3.1. Goals * *Legibility:* facts that affect a control decision are represented as typed fields rather than only as prose. * *Bounded context:* the provider can return a compact decision view with explicit freshness, coverage, truncation, and omissions. * *Outcome orientation:* the caller states the desired result and constraints separately from the provider's mechanism. * *Preview fidelity:* a consequential execution is bound to an exact, expiring plan revision and is rejected if that plan is stale. * *Authority clarity:* feasibility, authorization, approval, and readiness are separate states derived from authenticated context. * *Failure legibility:* problems disclose retry safety, effect certainty, alternatives, and remediation actions in machine- actionable fields. * *Durability:* plans, operations, outcomes, and events can outlive a client session and support resumption. * *Composability:* profiles and bindings reuse existing resource models, authentication, event, telemetry, and evidence mechanisms. * *Resource efficiency:* clients can cache capabilities, request bounded views, follow deltas, and use structured next actions instead of repeating open-ended discovery. * *Binding parity:* no transport or agent adapter creates a privileged path around planning, policy, or audit. 3.2. Non-Goals This document does not: * define model prompts, private reasoning, chain-of-thought, or agent planning algorithms; Paxton Expires 6 March 2027 [Page 8] Internet-Draft AICP September 2026 * define agent-to-agent conversation or task delegation; * define a global directory of agents or infrastructure providers; * define a universal representation for every cloud or infrastructure resource; * replace provider-native APIs, Kubernetes reconciliation, CIMI, CAMP, TOSCA, OAM, or infrastructure-as-code systems; * define a new authentication, credential, payment, telemetry, signature, or approval protocol; * guarantee exactly-once execution or perfect rollback; * permit a client to self-assert permissions, risk acceptance, or approval; or * require providers to disclose sensitive topology, capacity, policy, or tenant information. 4. Architecture 4.1. Linked Control Objects The AICP control loop consists of seven durable object classes: Capability Document, Situation, Intent Request, Plan, Operation, Outcome, and Problem. An Operation Event is an incremental delivery form for Operation changes. Each object MUST identify or link to the immediately preceding control objects where applicable. A Plan identifies its Intent Request and the Situation on which it was based. An Operation identifies the exact Plan revision. An Outcome identifies the Operation and preserves the expected and observed effects. These links form an audit and resumption graph; they do not expose model reasoning. A provider MAY retain objects for different periods, but it MUST advertise relevant retention limits and MUST NOT discard an active Operation before reaching a terminal phase. Paxton Expires 6 March 2027 [Page 9] Internet-Draft AICP September 2026 4.2. Separation of Responsibilities Consistent with intent-based networking concepts [RFC9315], the client states a desired outcome separately from the provider's implementation mechanism. The client selects an advertised action, identifies targets, supplies arguments, states constraints and success criteria, and chooses preview or execute-if-ready mode. The provider observes native state, proposes mechanisms, evaluates policy, executes through native systems, journals effects, verifies outcomes, and reports uncertainty. The provider MUST derive identity, delegation, permissions, and approval validity from authenticated server-side context. It MUST NOT grant authority because a request body claims that authority. A purpose string or delegation reference is input to policy evaluation, not proof of permission. 4.3. Bindings and Profiles The core object model is independent of transport. This document's HTTP binding defines interoperable retrieval and mutation semantics. Other bindings MUST preserve object identity, request deduplication, plan-revision binding, operation durability, error semantics, and authorization parity. A profile defines domain vocabulary. Action and type identifiers MUST be absolute URIs controlled by the profile publisher. A profile MUST publish machine-readable input and output schemas and MUST define the semantics that affect interoperability, including effect class, idempotency, reversibility, preconditions, success criteria, and observation types. 4.4. Preview and Execute-if-Ready Consequential intents default to preview. To avoid an unnecessary round trip for routine, low-risk work, a client can request execute- if-ready. The provider still creates an internal plan, evaluates current policy, binds execution to that plan, and returns the resulting Plan or Operation. It MUST NOT execute when feasibility is not feasible, authorization is not allowed, a required approval is absent, a hard constraint is unsatisfied, or policy requires explicit preview. The execute-if-ready mode is permission to use the safe fast path, not an instruction to weaken policy. 5. Common Data Model Paxton Expires 6 March 2027 [Page 10] Internet-Draft AICP September 2026 5.1. JSON Encoding AICP JSON objects MUST be valid JSON as defined by [RFC8259] and MUST satisfy the Internet JSON (I-JSON) constraints in [RFC7493]. Object member names are case-sensitive. A producer MUST NOT emit duplicate member names. Time values MUST use the Internet date-time format in [RFC3339] and SHOULD use UTC. When a profile needs an integer outside the exact interoperable range of IEEE 754 binary64, it MUST encode that value as a string and define the lexical form. Monetary values SHOULD use decimal strings in profiles that require exact accounting; the numeric cost examples in this document are illustrative. 5.2. Common Members Except for Problem Details objects, AICP objects contain these common members: Paxton Expires 6 March 2027 [Page 11] Internet-Draft AICP September 2026 +====================+=============+===============================+ | Member | Requirement | Meaning | +====================+=============+===============================+ | aicpVersion | Required | The major.minor core version. | | | | This document defines 0.1. | +--------------------+-------------+-------------------------------+ | kind | Required | The object class. | +--------------------+-------------+-------------------------------+ | id | Response | A provider-stable opaque | | | objects | identifier. | +--------------------+-------------+-------------------------------+ | revision | Mutable | An opaque value that changes | | | durable | on every semantically | | | objects | observable revision. | +--------------------+-------------+-------------------------------+ | createdAt | Durable | Creation time. | | | response | | | | objects | | +--------------------+-------------+-------------------------------+ | updatedAt | Optional | Time of the represented | | | | revision. | +--------------------+-------------+-------------------------------+ | links | As | A map from registered-by- | | | specified | this-document relation names | | | | to URI references. | +--------------------+-------------+-------------------------------+ | extensions | Optional | A map whose keys are absolute | | | | extension URIs. | +--------------------+-------------+-------------------------------+ | criticalExtensions | Optional | Extension URIs that must be | | | | understood for safe | | | | processing. | +--------------------+-------------+-------------------------------+ Table 1: Common AICP Members Identifiers are opaque. Clients MUST NOT infer type, ordering, time, tenancy, or authority from their syntax. Providers SHOULD generate identifiers with enough entropy to prevent enumeration. 5.3. Resource References A Resource Reference contains an absolute profile-defined type URI and provider-stable id. It can also contain scope, opaque revision, and non-authoritative displayName. Paxton Expires 6 March 2027 [Page 12] Internet-Draft AICP September 2026 The scope object narrows resolution with provider-defined string members such as account, project, tenant, region, namespace, or cluster. A provider MUST use the authenticated principal and scope together when resolving a reference and MUST NOT allow a display name to override the identifier. 5.4. Extension Processing Extension keys MUST be absolute URIs. A recipient MAY ignore an unrecognized extension unless its URI occurs in criticalExtensions. If a critical extension is unrecognized or unsupported, the recipient MUST reject the object with code unsupported-extension before causing a consequential effect. A provider MUST NOT change core semantics through a non-critical extension. An intermediary that preserves an object SHOULD preserve unrecognized extensions byte-for-byte where its representation permits. 5.5. Structured Semantics and Prose Human-readable titles, summaries, descriptions, and details are supplemental. A client MUST NOT treat prose as authorization, executable instructions, a replacement for a stable code, or a reason to violate a structured constraint. Providers MUST represent safety- relevant state in normative structured members. Neither clients nor providers are required to expose private chain- of-thought. Concise rationale, assumptions, evidence references, and policy reason codes are sufficient. 6. Discovery and Capabilities 6.1. Service Discovery An AICP HTTP provider MUST publish a Discovery object at /.well- known/aicp, as specified in Section 14. It lists supported core versions, profile URIs, authentication metadata, and links to the capability and request endpoints. Discovery only identifies a service and protocol surfaces. It is not a global provider directory and does not imply that every advertised profile or endpoint is authorized for the current principal. Paxton Expires 6 March 2027 [Page 13] Internet-Draft AICP September 2026 6.2. Capability Document A Capability Document MUST contain a revision, supported profiles, an action list, and relevant protocol limits. Each Action Descriptor MUST contain: * a stable absolute action URI, title, and concise description; * one or more target type URIs; * an input schema URI and, when applicable, an output schema URI; * an effect class of read-only or consequential; * whether planning is unsupported, optional, or required; * whether idempotency is unsupported, request-id based, or inherent; * whether reversibility is always, conditional, never, or unknown; * a default risk level; * permissions names sufficient for user explanation but not usable as proof of authority; * observation types usable to verify the action; and * applicable size, rate, retention, cost, or execution limits. The schemas MUST be retrievable by an authorized client and SHOULD use JSON Schema 2020-12 [JSON-SCHEMA]. The profile specification remains authoritative when schema validation alone cannot express a semantic requirement. A consequential action MUST advertise planning as required. A read- only action can advertise planning as optional or unsupported. Submitting preview for an action whose planning is unsupported fails with planning-unsupported; submitting it in execute-if-ready mode can create a read-only Operation. 6.3. Principal Scoping and Freshness A capability response MAY be scoped to the authenticated principal. If so, principalScoped is true, HTTP caching is private, and the provider MUST ensure that a response for one principal cannot be reused for another. A capability listing indicates discoverability, not a durable authorization grant; policy is evaluated again when planning and immediately before execution. Paxton Expires 6 March 2027 [Page 14] Internet-Draft AICP September 2026 Capability documents MUST have an opaque revision. Providers SHOULD support conditional retrieval so that clients can cache schemas and avoid repeated context transfer. 7. Situation Acquisition 7.1. Situation Request A Situation Request identifies one or more targets, a purpose, a view, optional categories to include, freshness requirements, and response budgets. The defined views are: decision The smallest representation the provider considers sufficient for choosing or evaluating an action for the stated purpose. summary A compact operational representation including principal resources, health, relationships, constraints, and active operations. full The most complete representation the provider is willing and authorized to disclose, still subject to explicit budgets and pagination. A client SHOULD request decision first and expand selectively. A provider MAY return less detail for policy, privacy, size, or availability reasons, but it MUST disclose omissions in coverage metadata unless disclosing the existence of omitted data would itself violate policy. The optional budget can bound bytes and items. A provider MUST NOT exceed a hard client budget merely to make the response appear complete. It instead returns a cursor, truncation flag, and omissions. 7.2. Situation Representation A Situation contains a provider-stable identifier and revision, observation and freshness times, coverage, resources, relationships, active Operations, applicable constraints, and available action URIs. Every resource observation MUST identify its observation time and health as healthy, degraded, unhealthy, or unknown. Profile-defined state can be included inline or by link. Secrets and credential values MUST NOT be included; references and redaction metadata are used instead. Paxton Expires 6 March 2027 [Page 15] Internet-Draft AICP September 2026 Coverage contains the delivered view, complete, truncated, explicit omissions, and an optional next cursor. The absence of a resource from an incomplete or truncated Situation MUST NOT be interpreted as proof that the resource does not exist. 7.3. Consistency and Use A Situation is an observation, not a transaction snapshot unless a profile explicitly guarantees that property. Different resource observations can have different timestamps. Providers SHOULD minimize skew and disclose material skew as an omission or unknown. When an Intent Request cites a Situation identifier and revision, the provider MUST disclose in the Plan whether it reused, refreshed, or could not validate that Situation. Execution still requires current precondition evaluation. 8. Intent Requests 8.1. Required Semantics An Intent Request contains: * a caller-generated requestId used for deduplication; * an advertised action URI; * one or more Resource References; * arguments that validate against the action's input schema; * hard constraints; * success criteria; * an optional cited Situation identifier and revision; * a mode of preview or execute-if-ready; * an optional human-readable purpose; and * an optional reference to externally verified delegation. The provider MUST validate the action, targets, arguments, constraints, and profile before planning. Unknown, ambiguous, or contradictory requirements produce a Problem or a Plan whose feasibility is conditional, infeasible, or unknown. The provider MUST NOT silently relax a hard constraint. Paxton Expires 6 March 2027 [Page 16] Internet-Draft AICP September 2026 8.2. Constraints Core constraints can restrict allowed scopes, time, cost, impact, and applicable policy references. Impact can include maximum changed resources, maximum unavailable resources, and prohibitions on data loss or downtime. Profiles can add a profile constraint object with semantics defined by the profile. A plan MUST echo the effective hard constraints. If policy adds a more restrictive constraint, the Plan includes it and explains its origin. If a requested constraint cannot be measured or enforced, feasibility is unknown or infeasible; it is not assumed satisfied. 8.3. Success Criteria A success criterion has an identifier, profile-defined type URI, optional subject, required flag, parameters, and optional observation window. The profile defines how it is measured and the evidence needed to evaluate it. Required criteria that cannot be evaluated cause the final Outcome to be failed or indeterminate as defined by the profile. An operation is not successful merely because provider API calls returned success; the required outcome criteria must be evaluated. 8.4. Intent Example Paxton Expires 6 March 2027 [Page 17] Internet-Draft AICP September 2026 { "aicpVersion": "0.1", "kind": "IntentRequest", "requestId": "req-7f2c", "action": "https://example.com/aicp/actions/workload.deploy", "targets": [{ "type": "https://example.com/aicp/types/workload", "id": "signal", "scope": {"project": "production", "region": "jnb1"} }], "arguments": {"release": "sha256:9c9f0d4a", "replicas": 3}, "constraints": { "impact": {"maxUnavailable": 1, "forbidDataLoss": true}, "cost": {"currency": "USD", "maxIncrement": 15} }, "successCriteria": [{ "id": "health", "type": "https://example.com/aicp/criteria/healthy-replicas", "required": true, "parameters": {"operator": "equals", "value": 3}, "windowSeconds": 300 }], "mode": "preview" } 9. Plans and Authorization 9.1. Plan Purpose and Immutability A Plan is the reviewable boundary between desired outcome and infrastructure mutation. It describes what the provider proposes to do, the state on which that proposal depends, and whether the proposal is feasible and authorized. Each Plan has an opaque revision and expiresAt. A provider MUST change the revision whenever any execution-relevant member changes, including changes, steps, constraints, preconditions, risk, authorization, approval requirements, assumptions, unknowns, estimates, or success criteria. A Plan revision is immutable once referenced by an execution attempt or approval. Later evaluation creates a new revision and preserves the older audit record. Paxton Expires 6 March 2027 [Page 18] Internet-Draft AICP September 2026 9.2. Basis, Changes, and Steps The basedOn object records the Situation identifier and revision when one was used, plus the observation time of the state used for planning. A Plan MUST include all known material changes in changes. A change identifies the operation, resource, optional before and after representations, optional JSON Patch [RFC6902], a materiality flag, and a concise effect. The steps array describes execution order and dependencies. Steps are operationally informative; the complete material effect remains authoritative in changes. A provider MUST NOT omit a material effect merely because it occurs in an internal or provider-native sub- operation. If a precise effect cannot be known before execution, the provider includes an unknown and a worst-case risk factor. Providers SHOULD minimize incidental implementation detail. The Plan should be sufficiently precise to support authorization, comparison, and recovery without requiring the client to understand every provider-internal call. 9.3. Feasibility, Authorization, and Readiness Feasibility and authorization are independent: +===============+=========================+=========================+ | Dimension | States | Meaning | +===============+=========================+=========================+ | Feasibility | feasible, conditional, | Whether the provider | | | infeasible, unknown | can satisfy the | | | | intent and hard | | | | constraints. | +---------------+-------------------------+-------------------------+ | Authorization | allowed, denied, | Whether the | | | approval-required, | authenticated | | | clarification-required, | principal can | | | unknown | execute this exact | | | | plan revision now. | +---------------+-------------------------+-------------------------+ | Readiness | ready, blocked, | The provider's | | | expired, unknown | combined answer | | | | about whether | | | | execution can safely | | | | be requested now. | +---------------+-------------------------+-------------------------+ Table 2: Plan Decision States Paxton Expires 6 March 2027 [Page 19] Internet-Draft AICP September 2026 The Plan's readiness object contains its state, evaluation time, and structured reasons. A Plan is ready only while unexpired, feasible, authorized as allowed, free of unmet approval requirements, and valid against all checked preconditions. The explicit value prevents each client from reconstructing a subtly different answer. Readiness is a point-in-time advisory and MUST be re-evaluated immediately before the first consequential effect. Authorization contains an evaluation time, structured reasons, approval requirements, and explanatory permission names. Explanatory permission names are not bearer capabilities and MUST NOT be accepted as proof of authority. 9.4. Approval Binding An Approval Requirement identifies a requirement type, audience, concise summary of the material action, expiry, and optional approval endpoint. The external approval mechanism is out of scope. An accepted approval MUST be cryptographically or transactionally bound by the provider to the Plan identifier and exact revision, approving principal, intended action, material changes, and expiry. If any of those change, the approval MUST NOT authorize the new revision. Approval of prose alone is insufficient. Providers SHOULD present the approver with the same material change, risk, blast radius, constraints, assumptions, unknowns, and expiry visible to the executing client. Approval interfaces MUST defend against substitution and approval-phishing attacks discussed in Section 20. 9.5. Risk and Blast Radius Risk has a level of none, low, medium, high, critical, or unknown; structured factors; and an estimated blast radius. Blast radius can count affected resources, tenants, and regions and includes a concise worst-case description. Risk is a provider and policy assessment, not a universal numerical truth. A provider MUST return unknown when it lacks sufficient information. A client MUST NOT treat a low value from an untrusted provider as authorization. Profiles SHOULD define minimum factors and consistent level guidance for comparable actions. Paxton Expires 6 March 2027 [Page 20] Internet-Draft AICP September 2026 9.6. Preconditions, Assumptions, and Unknowns Preconditions are facts that must hold for safe execution. Assumptions are facts the provider currently relies on but cannot guarantee. Unknowns are relevant decision inputs that the provider could not determine. Each is a structured Reason with a stable code and summary and can carry details and evidence links. A provider MUST verify enforceable preconditions immediately before execution. A material assumption becoming false or an unknown becoming unsafe causes the Operation to pause, fail, or enter compensation according to policy. The provider MUST NOT silently proceed by weakening a hard constraint. 9.7. Structured Next Actions A Plan includes nextActions selected from execute, wait, replan, approve, clarify, escalate, inspect, or stop, each with a reason, a safety indication, optional endpoint, and parameters. These are recommendations under current state, not new authority. The client still applies its policy and the provider re-evaluates authorization. 10. Execution and Operation Lifecycle 10.1. Execution Request An Execution Request contains a caller-generated request identifier, Plan identifier, exact Plan revision, and zero or more external approval references. The provider MUST reject execution when the Plan is missing, expired, stale, infeasible, denied, or outside a hard constraint. When a valid Plan lacks a required approval, the provider MUST NOT begin a consequential effect. It MAY create an Operation in awaiting-approval if its approval mechanism supports durable pending requests; otherwise it rejects the request with approval-required. Execution is a new authorization decision. A previously allowed Plan does not override revocation, changed principal status, emergency stop, quota, or policy changes. When rejection follows a material plan change, the provider returns or links a new Plan rather than silently executing it. Paxton Expires 6 March 2027 [Page 21] Internet-Draft AICP September 2026 10.2. Operation Resource A provider MUST create or return a durable Operation before or atomically with accepting a consequential execution. The Operation identifies the Execution Request, Plan identifier and revision, current phase, effect state, monotonic sequence, progress, reasons, retry guidance, and structured next actions. The operation representation is the source of truth. Event delivery can be delayed, duplicated, or interrupted; a client can always retrieve the latest authorized representation while it is retained. 10.3. Phases +===================+==========+================================+ | Phase | Terminal | Meaning | +===================+==========+================================+ | queued | No | Accepted but no consequential | | | | step is known to have started. | +-------------------+----------+--------------------------------+ | awaiting-approval | No | Execution is blocked on a | | | | bound approval. | +-------------------+----------+--------------------------------+ | executing | No | One or more planned steps can | | | | be producing effects. | +-------------------+----------+--------------------------------+ | verifying | No | Planned mutation steps ended | | | | and success criteria are being | | | | evaluated. | +-------------------+----------+--------------------------------+ | paused | No | Progress stopped for a stated, | | | | recoverable reason. | +-------------------+----------+--------------------------------+ | succeeded | Yes | Required criteria were | | | | satisfied and effects are | | | | sufficiently determined. | +-------------------+----------+--------------------------------+ | failed | Yes | The operation did not satisfy | | | | required criteria and effect | | | | state is sufficiently known. | +-------------------+----------+--------------------------------+ | cancelled | Yes | Cancellation completed; the | | | | effect state states what | | | | remains. | +-------------------+----------+--------------------------------+ | indeterminate | Yes | The provider cannot safely | | | | determine whether or to what | | | | extent effects occurred. | Paxton Expires 6 March 2027 [Page 22] Internet-Draft AICP September 2026 +-------------------+----------+--------------------------------+ Table 3: Operation Phases A provider can omit an intermediate phase but MUST NOT imply a phase that did not occur. Before a confirmed effect, queued, awaiting- approval, and paused can transition among policy-permitted non- terminal states or a terminal state. After effect begins, executing and verifying can alternate only when the exact Plan already authorizes the additional execution. A terminal phase MUST NOT be changed in place. Later discoveries are recorded in a new reconciliation Operation and a new Outcome revision linked to the original record. 10.4. Effect State +==========+==============================+=====================+ | State | Meaning | Blind retry | +==========+==============================+=====================+ | none | No externally consequential | Permitted only when | | | effect occurred. | retry guidance also | | | | says safe. | +----------+------------------------------+---------------------+ | possible | An effect may have begun, | Forbidden. | | | but none is confirmed. | | +----------+------------------------------+---------------------+ | partial | Some effects are confirmed | Forbidden. | | | and the full plan is | | | | incomplete. | | +----------+------------------------------+---------------------+ | complete | All planned material effects | Normally | | | are confirmed; success | unnecessary and | | | criteria can still fail. | forbidden. | +----------+------------------------------+---------------------+ | reversed | Defined compensating effects | Forbidden unless a | | | are confirmed; exact prior | new plan says | | | state is not implied. | otherwise. | +----------+------------------------------+---------------------+ | unknown | The provider cannot bound or | Forbidden. | | | classify the actual effect. | | +----------+------------------------------+---------------------+ Table 4: Effect States Phase and effect state are independent. A failed or cancelled operation can have partial effects. A successful operation has complete planned effects but can also report side effects. Providers MUST update effect state conservatively. Paxton Expires 6 March 2027 [Page 23] Internet-Draft AICP September 2026 10.5. Progress Progress identifies completed steps, active steps, total steps, and optionally a percentage. Step sets are authoritative; percentage is advisory and MUST NOT be interpreted as a probability of success or a safe cancellation boundary. 10.6. Cancellation, Pause, and Resume Available controls are advertised through links and structured next actions. Cancellation is best effort. A cancellation request MUST be represented as its own idempotent control request. The provider MUST report the resulting terminal phase and effect state; it MUST NOT claim cancelled means that no effect occurred. A control request racing with completion returns the current Operation. Pause and resume semantics are profile-defined. Resumption MUST re-evaluate authority, constraints, and preconditions. 10.7. Events Operation Events carry an event identifier, operation identifier, monotonically increasing per-operation sequence, event type, creation time, and event data. Delivery is at least once unless a binding or profile states stronger behavior. Clients MUST deduplicate by event identifier and sequence and MUST retrieve the current Operation after a detected sequence gap. Core event types are operation.phase-changed, operation.progress, operation.effect-changed, operation.problem, and operation.outcome. Profile-specific event types MUST be absolute URIs. Event data is a notification and MUST NOT cause a client to skip retrieval of an authorization- or safety-relevant current representation. A provider MAY encode events using CloudEvents [CLOUDEVENTS]. Such an encoding preserves the AICP operation identifier, sequence, and event type. 11. Outcomes, Verification, and Evidence 11.1. Outcome Resource Every terminal Operation MUST link to an Outcome. The Outcome contains the terminal status and effect state, expected changes from the Plan, observed changes, side effects, per-criterion results, evidence references, and structured next actions. Paxton Expires 6 March 2027 [Page 24] Internet-Draft AICP September 2026 The provider MUST distinguish an expected change from an observed change. It MUST NOT copy the Plan into observedChanges without observation. A side effect is any material observed effect not represented in the Plan's expected changes, including unexpected cost, exposure, dependency, or availability effects. 11.2. Criterion Results Each requested success criterion receives a result of satisfied, unsatisfied, unknown, or not-evaluated, together with an observation time when applicable, actual value, structured reasons, and evidence references. A required criterion that is unsatisfied causes status failed. Any compensation is a separate action. A required criterion whose state is unknown after the provider's defined verification period causes indeterminate unless the profile explicitly defines a safe, known failed state. 11.3. Evidence References An Evidence Reference identifies an evidence type URI and contains one or more of an authorized URI, digest, or concise summary. It can include subject, observation time, and freshness limit. Evidence can point to logs, metrics, traces, signed observations, attestations, policy decisions, or provider-native audit records. AICP does not define a signature or evidence verification protocol. Profiles SHOULD reuse applicable evidence work such as VIRP [VIRP] and EMILIA [EMILIA] and telemetry standards such as OpenTelemetry [OTEL]. Access to evidence MUST be independently authorized and MUST NOT be granted merely because a client can read an Outcome. 11.4. Compensation A compensating action is a new Intent, Plan, authorization decision, Operation, and Outcome. It links to the original Operation and describes which effects it intends to counter. A provider MUST NOT mutate the original history to make compensation appear to be an atomic rollback. The original action's reversibility descriptor is only a planning hint. Current state, authorization, and risk are evaluated again. If full restoration is impossible, the compensation Plan declares residual effects and unknowns. 12. Problems and Recovery Semantics Paxton Expires 6 March 2027 [Page 25] Internet-Draft AICP September 2026 12.1. Problem Representation HTTP errors use Problem Details for HTTP APIs [RFC9457] with media type application/problem+json. An AICP Problem adds: * aicpVersion and a stable code; * the relevant requestId and optional Operation link; * effectState; * retry.safe, optional delay, and requiresReconciliation; * structured constraint or field violations; * safe alternatives and remediations; and * links to current Plans, Operations, Situations, or capability documents. The human-readable detail member is not authoritative. A client bases retry and recovery decisions on stable code, effect state, retry fields, and current operation state. 12.2. Core Problem Codes +===========================+=========+============================+ | Code | Typical | Required behavior | | | HTTP | | | | status | | +===========================+=========+============================+ | invalid-request | 400 | Return field or semantic | | | | violations; no effect. | +---------------------------+---------+----------------------------+ | unsupported-version | 400 | Link supported versions; | | | | no effect. | +---------------------------+---------+----------------------------+ | unsupported-profile | 400 | Link supported profiles; | | | | no effect. | +---------------------------+---------+----------------------------+ | unsupported-action | 400 or | Disclose alternatives only | | | 404 | when authorized. | +---------------------------+---------+----------------------------+ | unsupported-extension | 400 | Identify unsupported | | | | critical URIs; no effect. | +---------------------------+---------+----------------------------+ | planning-unsupported | 409 | Use an allowed direct mode | | | | or another advertised | Paxton Expires 6 March 2027 [Page 26] Internet-Draft AICP September 2026 | | | action; no effect. | +---------------------------+---------+----------------------------+ | authorization-denied | 403 | Do not disclose protected | | | | policy or target | | | | existence. | +---------------------------+---------+----------------------------+ | approval-required | 403 or | Link exact Plan and | | | 409 | requirements; no effect. | +---------------------------+---------+----------------------------+ | plan-stale | 412 | Do not execute; link or | | | | create a new Plan. | +---------------------------+---------+----------------------------+ | plan-expired | 409 | Do not execute; replan. | +---------------------------+---------+----------------------------+ | precondition-failed | 412 | Do not begin new effect; | | | | disclose failed | | | | preconditions. | +---------------------------+---------+----------------------------+ | constraint-unsatisfied | 409 or | Do not silently relax; | | | 422 | offer authorized | | | | alternatives. | +---------------------------+---------+----------------------------+ | capacity-unavailable | 409 or | Return delay and | | | 503 | alternatives when known. | +---------------------------+---------+----------------------------+ | request-id-reuse | 409 | Same request identifier | | | | was used with different | | | | semantics. | +---------------------------+---------+----------------------------+ | rate-limited | 429 | Return retry delay and | | | | preserve accepted | | | | operation state. | +---------------------------+---------+----------------------------+ | operation-not-cancellable | 409 | Return current operation | | | | and effect state. | +---------------------------+---------+----------------------------+ | effect-indeterminate | 500 or | Blind retry is unsafe; | | | 503 | link reconciliation. | +---------------------------+---------+----------------------------+ | reconciliation-required | 409 | Caller must observe actual | | | | state before another | | | | mutation. | +---------------------------+---------+----------------------------+ Table 5: Initial AICP Problem Codes Paxton Expires 6 March 2027 [Page 27] Internet-Draft AICP September 2026 HTTP status codes remain transport-level classifications; the AICP code supplies stable domain behavior. Providers MAY define profile- specific codes using absolute problem type URIs and names that do not collide with core codes. 12.3. Recovery Actions Next actions and remediations use the controlled action values execute, wait, replan, approve, clarify, cancel, reconcile, compensate, escalate, stop, and inspect. Each item states whether following the recommendation is non-consequential under current state. A safe value does not grant permission and can become stale. When retry is unsafe, retry.safe is false. If reconciliation is required, the provider MUST link or describe a reconciliation action and MUST NOT recommend a repeat of the original consequential request until actual effect state is sufficiently known. 13. Idempotency, Concurrency, and Reconciliation 13.1. Request Deduplication Every mutation request contains a caller-generated requestId. During its advertised retention interval, a provider scopes this identifier to the authenticated principal, service, request kind, and action. Repeating the identifier with semantically identical input MUST return the same Plan, Operation, control result, or terminal record rather than start another consequential effect. Reusing the identifier with semantically different input MUST fail with request-id-reuse. Providers MUST compare a normalized internal representation sufficient to detect a material difference; this document does not standardize a cross-provider canonical JSON digest. The capability document MUST advertise request identifier retention. A client MUST NOT assume deduplication after that interval and SHOULD retrieve the prior Operation before taking another consequential action. 13.2. Optimistic Concurrency Plans bind to observed resource revisions and preconditions. HTTP representations use entity tags and conditional requests as specified in Section 14. A provider MUST reject execution if a material target revision or precondition changed unless the Plan explicitly described and authorized that variance. Paxton Expires 6 March 2027 [Page 28] Internet-Draft AICP September 2026 A provider MUST NOT recompute a stale Plan and execute the new result under the old approval. It can return a new Plan for review. 13.3. No Exactly-Once Assumption AICP does not guarantee exactly-once external effects. Native provider calls, network failures, failover, and partial execution can make an accepted request's effects uncertain. Idempotency prevents many duplicates but does not prove that an external effect did or did not occur. If the provider cannot safely determine the effect, the Operation reaches indeterminate with effect state possible, partial, or unknown. The client MUST NOT blindly retry and MUST use the advertised reconciliation path or escalate. 13.4. Reconciliation Procedure A reconciliation action observes authoritative native state and compares it to the Plan's expected changes and the latest known effects. It produces a new Operation and Outcome linked to the indeterminate Operation. It can classify effects as none, partial, complete, reversed, or still unknown and can propose a new completion or compensation Plan. Reconciliation is observation-oriented. If it must mutate state, that mutation is represented as a separate consequential Plan and Operation. 14. HTTP Binding 14.1. General Requirements The AICP HTTP binding uses HTTP semantics from [RFC9110], encrypted transport, JSON representations, conditional requests, and link- driven endpoints. An implementation MUST support HTTP/1.1 or later and MUST use TLS 1.2 or later; TLS 1.3 [RFC8446] is RECOMMENDED. AICP success representations use media type application/aicp+json. Problems use application/problem+json. Clients send Accept and Content-Type accordingly. Servers MUST reject an unsupported content type without interpreting it as an AICP mutation. Paxton Expires 6 March 2027 [Page 29] Internet-Draft AICP September 2026 Authentication and token acquisition are outside scope. HTTP providers SHOULD publish OAuth 2.0 Protected Resource Metadata [RFC9728] when OAuth is used. Authorization requests can use Rich Authorization Requests [RFC9396] or another policy mechanism. Bearer and proof-of-possession credentials MUST NOT appear inside AICP JSON objects. 14.2. Well-Known Discovery The path /.well-known/aicp is formed according to [RFC8615]. A successful GET returns a Discovery object. The object contains at least: { "aicpVersion": "0.1", "kind": "Discovery", "service": "Example Infrastructure Control", "versions": ["0.1"], "profiles": ["https://example.com/aicp/profiles/workload/0.1"], "auth": { "protectedResourceMetadata": "https://c.example/.well-known/oauth-protected-resource" }, "links": { "capabilities": "https://control.example.com/aicp/capabilities", "situations": "https://control.example.com/aicp/situations", "intents": "https://control.example.com/aicp/intents" } } The origin of an absolute link is authoritative for that endpoint. A client MUST NOT forward credentials to a different origin unless its authentication policy explicitly authorizes that origin. Redirect handling follows the credential and redirection security requirements of HTTP and the authentication scheme. 14.3. Resource Interaction Pattern Endpoint paths other than the well-known URI are discovered from links; their literal spelling is not normative. The following interaction pattern is normative: Paxton Expires 6 March 2027 [Page 30] Internet-Draft AICP September 2026 +==============+========+==========================+============+ | Interaction | Method | Request | Response | +==============+========+==========================+============+ | Discover | GET | None | Discovery | | service | | | | +--------------+--------+--------------------------+------------+ | List | GET | Conditional headers | Capability | | capabilities | | optional | Document | +--------------+--------+--------------------------+------------+ | Acquire | POST | Situation Request | Situation | | situation | | | | +--------------+--------+--------------------------+------------+ | Submit | POST | Intent Request | Plan or | | intent | | | Operation | +--------------+--------+--------------------------+------------+ | Retrieve | GET | Conditional headers | Plan | | plan | | optional | | +--------------+--------+--------------------------+------------+ | Execute plan | POST | Execution Request and | Operation | | | | If-Match | | +--------------+--------+--------------------------+------------+ | Retrieve | GET | Conditional headers or | Operation | | operation | | wait preference optional | | +--------------+--------+--------------------------+------------+ | Control | POST | Profile-defined control | Operation | | operation | | request with request ID | | +--------------+--------+--------------------------+------------+ | Retrieve | GET | Cursor and wait | Event | | events | | preference optional | collection | | | | | or stream | +--------------+--------+--------------------------+------------+ | Retrieve | GET | Conditional headers | Outcome | | outcome | | optional | | +--------------+--------+--------------------------+------------+ Table 6: HTTP Interaction Pattern A created Plan or Operation is returned with Location pointing to its durable resource. A provider MUST return the same resource location for a deduplicated request. 14.4. Status Codes A synchronous retrieval or completed non-mutating request normally returns 200. Creation of a durable Plan can return 200 or 201. Acceptance of asynchronous execution returns 202 with an Operation and Location. A provider MUST NOT use 202 without a retrievable operation status. Paxton Expires 6 March 2027 [Page 31] Internet-Draft AICP September 2026 Conditional failure uses 304 for retrieval, 409 for domain conflict or expired state, and 412 for a failed HTTP or plan precondition. Authentication uses 401; authorization denial uses 403; disclosure- sensitive implementations can use 404 where required to conceal target existence. A missing required condition uses 428 and rate limiting uses 429 as defined by [RFC6585]. Service unavailability uses 503 with appropriate retry metadata. Semantic errors include a Problem object even when the HTTP status is sufficient for a generic client. 14.5. Entity Tags and Conditional Execution Providers MUST return a strong entity tag for each Plan revision and SHOULD return entity tags for Discovery, Capability Document, Situation, Operation, and Outcome representations. The opaque AICP revision and HTTP ETag can have different syntax but identify the same semantically observable revision. An explicit Plan execution request MUST contain planRevision and MUST use If-Match with the Plan's current strong entity tag. A missing If-Match returns 428 when the server requires a condition; a mismatch returns 412 with code plan-stale. A provider MUST NOT execute a newer Plan under an older entity tag or approval. 14.6. Asynchronous Preference and Waiting Clients can use the Prefer header from [RFC7240]. respond-async asks the server not to wait for completion. wait=N on an Operation or event retrieval asks the server to wait up to N seconds for a newer revision. The server can decline either preference and reports applied preferences with Preference-Applied. Long polling and streaming are optional. A provider supporting event streaming MUST also support ordinary retrieval of the current Operation. Cursors are opaque, scoped to the principal and collection, and MUST NOT be treated as credentials. 14.7. Caching and Bounded Transfer Discovery, public profile schemas, and non-sensitive capabilities SHOULD use explicit cache controls. Principal-scoped representations use Cache-Control: private or no-store as appropriate and ensure authorization state is not shared across principals. A Situation response respects the caller's item and byte budgets. HTTP compression SHOULD be supported. Providers SHOULD offer conditional retrieval and event deltas so that a client does not repeatedly transfer unchanged full state. Paxton Expires 6 March 2027 [Page 32] Internet-Draft AICP September 2026 14.8. Correlation and Telemetry A provider SHOULD accept standard trace-context propagation and link authorized trace, metric, log, and audit evidence from the resulting Operation. AICP request identifiers are for deduplication and audit correlation; they are not a substitute for distributed tracing identifiers. 15. Relationship to Agent Protocols 15.1. Model Context Protocol MCP [MCP] standardizes how an AI application discovers and invokes tools and accesses resources. An MCP server can expose AICP without defining one tool for every provider action. A recommended minimal tool surface is: * aicp.discover - retrieve Discovery and principal-scoped capabilities; * aicp.situation - submit a Situation Request; * aicp.plan - submit an Intent Request in preview or execute-if- ready mode; * aicp.execute - execute an exact Plan revision; * aicp.observe - retrieve an Operation, Outcome, or events; and * aicp.control - request cancellation, pause, resume, reconciliation, or another advertised control. Action URIs and profile schemas travel as data. This fixed surface reduces tool-list size, selection ambiguity, and adapter churn. An implementation can expose more specialized tools, but they MUST preserve the same Plan, policy, Operation, error, and audit semantics to claim AICP conformance. An MCP adapter MUST NOT bypass the authorization path used by the HTTP binding. MCP task facilities can represent long-running delivery, but the AICP Operation remains the authoritative infrastructure effect record. Paxton Expires 6 March 2027 [Page 33] Internet-Draft AICP September 2026 15.2. Agent2Agent Protocol A2A [A2A] can delegate infrastructure work to another agent or carry AICP objects as artifacts. An A2A task describes inter-agent work and conversation; an AICP Operation describes infrastructure execution and effects. Implementations SHOULD link the two identifiers without collapsing their state machines. 15.3. Agent Execution Protocol The Agent Execution Protocol (AEP) [AEP] describes a governed reasoning-loop boundary. An AEP ACT transition can invoke an AICP request, and an AICP Situation, Operation, or Outcome can be an input to SENSE or OBSERVE. AICP does not standardize the internal reasoning loop or replace its governing enforcement component. 16. Agent Ergonomics and Resource Efficiency 16.1. Progressive Disclosure Clients SHOULD begin with cached capabilities and a decision Situation. Providers SHOULD order decision views by operational relevance rather than provider database layout. A caller can then request summary or full views, specific include categories, evidence, or a continuation cursor only where uncertainty remains. Every truncated or policy-limited response identifies coverage and omissions. This allows an agent to reason about what it does not know without paying to retrieve irrelevant state. 16.2. Stable Machine Semantics Stable action URIs, schemas, codes, enumerated states, and structured reasons SHOULD be favored over parsing provider prose. A profile SHOULD use intent-aligned action identifiers such as deploy, resize, expose, rotate, or reconcile rather than method names derived from one implementation. Descriptions are untrusted explanatory data. Clients SHOULD select actions by authenticated capability identity, schema, effect class, policy, and target compatibility, not by semantic similarity to a natural-language description alone. Paxton Expires 6 March 2027 [Page 34] Internet-Draft AICP September 2026 16.3. Accretive Context AICP objects form a durable graph. A resumed client can retrieve the current Operation and follow links to the exact Plan, originating intent, observed Situation, Outcome, and evidence. It need not reconstruct authority or effects from a chat transcript. Providers SHOULD retain concise object summaries even when bulky evidence has moved to archival storage. 16.4. Least-Call Behavior The protocol permits but does not require a single request to plan and execute through execute-if-ready. Providers still enforce planning internally. Clients use conditional retrieval, wait preferences, and event cursors to avoid hot polling. Problems carry recovery choices so the next call is deliberate rather than exploratory. 16.5. Decision Quality Without Private Reasoning Providers report relevant evidence, assumptions, unknowns, and concise reason codes. They MUST NOT require a model's hidden reasoning trace as a condition of interoperability. Clients can supply a short purpose and success criteria without disclosing private chain-of-thought or unrelated context. 17. Profiles, Versioning, and Extensibility 17.1. Profile Requirements A conforming profile specification defines: * a stable profile URI and versioning policy; * resource type and relationship URIs; * action descriptors and input/output schemas; * constraint and success-criterion semantics; * observation and evidence types; * materiality, effect class, idempotency, reversibility, and risk guidance; * native-state mapping and loss of fidelity; * additional Problem codes and recovery behavior; and Paxton Expires 6 March 2027 [Page 35] Internet-Draft AICP September 2026 * conformance examples and tests. A profile SHOULD reference an existing resource or orchestration model where one is fit for purpose. It MUST disclose mapping loss rather than imply semantic equivalence. 17.2. Core Version Negotiation The Discovery object lists supported major.minor versions. A client selects a mutually supported version by sending the corresponding media type and object value. This document defines 0.1; pre-1.0 versions can make incompatible changes. After a 1.0 specification, a minor version will add only backward- compatible optional semantics, while a major version can make incompatible changes. A recipient MUST reject an unsupported version before a consequential effect. 17.3. Schema Evolution New optional fields are introduced through a negotiated core version, profile version, or extension URI. Unknown top-level members are not a substitute for extensions and MAY be rejected. Critical behavior always appears in criticalExtensions or a negotiated profile. 18. Conformance 18.1. Core Provider An AICP Core Provider implements Discovery, Capability Documents, Situation Requests, Intent Requests, Plans, authorization state, Operations, Outcomes, Problems, request deduplication, plan-revision binding, and reconciliation semantics in at least one binding. An AICP HTTP Provider additionally implements Section 14. 18.2. Core Client An AICP Core Client validates versions and critical extensions, treats prose as non-authoritative, honors hard constraints, executes only exact Plan revisions, deduplicates events, does not blindly retry uncertain effects, and follows binding-specific credential rules. Paxton Expires 6 March 2027 [Page 36] Internet-Draft AICP September 2026 18.3. Profile Conformance A provider or client claiming profile conformance implements all profile requirements identified as mandatory and publishes the supported profile URI in Discovery. Core conformance alone does not imply semantic interoperability for an unshared profile. 18.4. Minimum Test Cases A conformance suite MUST test at least: 1. same request identifier and same semantics return the same result; 2. same request identifier and different semantics return request- id-reuse; 3. a stale, expired, or mismatched Plan is not executed; 4. approval for one revision cannot authorize another; 5. denied work cannot bypass policy through another binding; 6. truncation and omissions are explicit; 7. a partial or uncertain effect reaches an appropriate effect and retry state; 8. an event gap is recoverable from the Operation resource; 9. cancellation races report remaining effects; 10. compensation is a separate authorized action; 11. unsupported critical extensions are rejected before effect; and 12. malicious descriptions cannot supply authority or executable instructions. 19. Operational Considerations 19.1. Retention and Resumption Providers advertise request-deduplication, Plan, Operation, Outcome, and event retention. Active Operations are durable across service restarts. If detailed events expire before the Outcome, the provider preserves a terminal summary, effect state, Plan link, and evidence index sufficient for audit and safe recovery. Paxton Expires 6 March 2027 [Page 37] Internet-Draft AICP September 2026 19.2. Backpressure and Resource Exhaustion Providers enforce authenticated quotas for Situation size, concurrent plans, active Operations, event subscriptions, and expensive verification. Rate limiting does not discard an accepted Operation. Problems distinguish rejection before acceptance from throttling of observation after an effect may have begun. 19.3. Revocation and Emergency Stop Providers MUST support operational revocation of credentials and SHOULD support policy-defined emergency stop. Revocation prevents new effects but does not erase or hide active operations. The provider attempts safe pause, cancellation, or containment and reports actual effect state. 19.4. Clock and Expiry Plan and approval expiry is evaluated by the provider's clock. Providers maintain time synchronization appropriate to their maximum expiry granularity. Clients treat expiry as an upper bound and allow for network delay; they do not assume execution is valid merely because their local clock precedes expiresAt. 20. Security Considerations AICP enables consequential control and therefore exposes the security impact of infrastructure APIs to autonomous and high-rate callers. Authentication alone is insufficient. Implementations require least privilege, policy evaluation, exact-plan binding, durable audit, rate control, and conservative uncertainty handling. 20.1. Confused Deputy and Cross-Tenant Access A provider resolves every Resource Reference in the authenticated principal's context, validates delegation and audience, and applies tenant boundaries at every linked resource. It does not trust scope, display name, purpose, requested permission, or delegation URI from the body as proof. Links and cursors are not bearer authorization unless explicitly specified by the authentication system. 20.2. Stale Plan and Time-of-Check/Time-of-Use An attacker or concurrent actor can change infrastructure after preview. Strong entity tags, opaque revisions, expiry, native resource preconditions, and immediate authorization re-evaluation reduce this risk. Providers do not execute a recomputed plan under old approval and do not silently widen a constraint. Paxton Expires 6 March 2027 [Page 38] Internet-Draft AICP September 2026 20.3. Approval Substitution and Phishing An approval is bound to exact Plan identity, revision, action, material changes, principal, and expiry. Approval interfaces clearly identify the provider origin and material effect. They avoid approving a generic phrase that could be replayed against another target. High-risk plans should require phishing-resistant authentication and independent confirmation appropriate to organizational policy. 20.4. Prompt Injection, Schema Poisoning, and Tool Shadowing Descriptions, resource labels, log content, telemetry annotations, and problem detail can contain attacker-controlled text. Clients treat such text as data, never as protocol instructions or authority. Action selection uses authenticated service identity, stable URI, schema, target type, and policy. Clients do not accept a newly advertised action that shadows a trusted action by title alone. Schema and profile documents require integrity and origin validation. Clients cache them by origin, URI, and revision and apply size and complexity limits to avoid parser and validation denial of service. A provider does not allow resource content to inject critical extensions or alter core fields. 20.5. Replay, Duplicate Effects, and Retry Storms Unpredictable request identifiers, principal scoping, bounded retention, and semantic mismatch detection reduce replay. A provider rate-limits repeated retrieval without losing the durable Operation. A client backs off according to Problem metadata and never repeats a consequential request when effect state is possible, partial, or unknown. 20.6. Provider and Adapter Compromise A compromised adapter can misstate a plan, hide effects, or forge observations. Deployments should isolate provider adapters, constrain their native credentials, compare requested and native audit records, and use independent evidence for high-risk actions. AICP evidence links can support verification but do not make an untrusted provider trustworthy by themselves. Paxton Expires 6 March 2027 [Page 39] Internet-Draft AICP September 2026 20.7. Secrets and Sensitive Data Secret values, bearer credentials, private keys, and unrestricted signed URLs do not appear in AICP objects. Profiles use opaque secret references resolved inside the authorized control plane. Logs, errors, plans, and evidence summaries are redacted before return and before inclusion in model context. 20.8. Autonomy and Blast Radius Autonomous clients can generate valid but harmful high-rate actions. Providers enforce independent limits on scope, spend, concurrent changes, unavailable resources, data destruction, region count, and approval threshold. A client's stated risk tolerance never overrides provider policy. The execute-if-ready fast path is disabled when policy requires explicit review. 20.9. Audit Integrity Audit records link authenticated principal, delegated subject when known, request identifier, Situation, Plan revision, approval decisions, native operation identifiers, Operation events, Outcome, and evidence. Providers protect audit data from modification and unauthorized disclosure. Private model reasoning is neither necessary nor sufficient as an audit record. 21. Privacy Considerations Situation and capability discovery can reveal topology, resource names, tenant existence, policy, capacity, cost, operational incidents, and organizational relationships. Providers return only the minimum information authorized for the principal and purpose. They can conceal target existence with an appropriate generic response where disclosure would create risk. Decision views and explicit include categories support data minimization. A provider can state an omission without disclosing protected details, for example by using a generic policy-limited reason. Clients avoid sending unrelated conversation history, personal data, or private reasoning in purpose, arguments, or extensions. Durable linked records increase accountability but also correlation risk. Retention is limited to operational, legal, and audit need. Identifiers use sufficient entropy and do not encode user identity. Evidence access is separately authorized, and telemetry links avoid embedding credentials. Cross-origin links are not automatically followed with credentials. Paxton Expires 6 March 2027 [Page 40] Internet-Draft AICP September 2026 Capability documents scoped to a principal can reveal permissions. They are privately cached or not stored, are not shared across principals, and can omit denied actions rather than exposing a permission map. 22. IANA Considerations 22.1. Media Type Registration This document requests registration of application/aicp+json in the Media Types registry according to [RFC6838] using the following template: Type name application Subtype name aicp+json Required parameters None Optional parameters None Encoding considerations binary; the content is UTF-8 JSON Security considerations See Section 20 of this document. Interoperability considerations Recipients use the aicpVersion member and negotiated profiles. Unknown critical extensions are rejected. Published specification This document. Applications that use this media type Infrastructure control planes, autonomous agents, orchestration gateways, and management clients. Fragment identifier considerations None are defined by this specification. A profile can define fragment semantics, including JSON Pointer, for its own representations. Paxton Expires 6 March 2027 [Page 41] Internet-Draft AICP September 2026 Additional information Magic number(s): none; file extension(s): none; Macintosh file type code(s): none. Person and email address to contact for further information Tihan-Nico Paxton, tihan-nico@apollodeploy.com Intended usage COMMON Restrictions on usage None Author Tihan-Nico Paxton Change controller IETF 22.2. Well-Known URI Registration This document requests registration of aicp in the Well-Known URIs registry: URI suffix aicp Change controller IETF Specification document This document, Section 14.2. Related information The resource returns an AICP Discovery object and does not itself authorize infrastructure operations. 22.3. AICP Problem Code Registry This document requests creation of the "AICP Problem Codes" registry under an "Agent Infrastructure Control Protocol" group. Initial entries are the codes in Table 5. Future registrations require Specification Required as defined by [RFC8126]. Paxton Expires 6 March 2027 [Page 42] Internet-Draft AICP September 2026 A registration contains code, problem type URI, intended HTTP status or range, effect-state requirements, retry requirements, and a specification reference. Designated Experts should reject names that are ambiguous, disclose credentials, redefine an existing code incompatibly, or omit safe behavior for uncertain effects. 23. Acknowledgements This initial draft was informed by the design vocabulary and operational lessons of HTTP, intent-based networking, MCP, A2A, AEP, VIRP, EMILIA, CIMI, CAMP, TOSCA, Kubernetes, CloudEvents, and OpenTelemetry. Their mention does not imply review or endorsement of this document by their authors or communities. 24. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC6902] Bryan, P. and M. Nottingham, "JavaScript Object Notation (JSON) Patch", RFC 6902, DOI 10.17487/RFC6902, April 2013, . [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, DOI 10.17487/RFC7240, June 2014, . [RFC7493] Bray, T., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, . Paxton Expires 6 March 2027 [Page 43] Internet-Draft AICP September 2026 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC9110] Fielding, R., Nottingham, M., and J. Reschke, "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, . [RFC9728] IETF, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, . 25. Informative References [A2A] Linux Foundation, "Agent2Agent Protocol Specification, Version 1.0", 2026, . Paxton Expires 6 March 2027 [Page 44] Internet-Draft AICP September 2026 [AEP] Sato, T., "The Agent Execution Protocol (AEP) for Agentic AI Systems", Work in Progress, Internet-Draft, draft-sato- soos-aep-02, 30 June 2026, . [AI-ARCH] Park, S. D. and I. Siddique, "Architectural Requirements for Supporting AI Agents on the Internet", Work in Progress, Internet-Draft, draft-daniel-ai-agent-internet- architecture-03, 28 August 2026, . [CAMP] OASIS, "Cloud Application Management for Platforms Version 1.2", December 2020, . [CIMI] DMTF, "Cloud Infrastructure Management Interface (CIMI) Model and REST Interface over HTTP", DMTF DSP0263 2.0.0, June 2016, . [CLOUDEVENTS] Cloud Native Computing Foundation, "CloudEvents Specification, Version 1.0.2", 2022, . [EMILIA] Schrock, I., "The EMILIA Protocol: An Evidence Architecture for Consequential Agent Actions", Work in Progress, Internet-Draft, draft-schrock-ep-architecture- 02, 21 July 2026, . [JSON-SCHEMA] Wright, A., Andrews, H., Hutton, B., and G. Dennis, "JSON Schema: A Media Type for Describing JSON Documents, Draft 2020-12", June 2022, . [KUBERNETES] Kubernetes Authors, "Kubernetes API Concepts", 2026, . [MCP] Model Context Protocol Project, "Model Context Protocol Specification, 2026-07-28", July 2026, . Paxton Expires 6 March 2027 [Page 45] Internet-Draft AICP September 2026 [OTEL] Cloud Native Computing Foundation, "OpenTelemetry Specification", 2026, . [RFC9315] Clemm, A., Ciavaglia, L., Granville, L., and J. Tantsura, "Intent-Based Networking - Concepts and Definitions", RFC 9315, DOI 10.17487/RFC9315, October 2022, . [TOSCA] OASIS, "TOSCA Version 2.0", 2025, . [VIRP] Howard, N., "VIRP: Verified Infrastructure Response Protocol", Work in Progress, Internet-Draft, draft-howard- virp-06, 1 August 2026, . Appendix A. Worked HTTP Control Loop This appendix is non-normative. 1. The client retrieves /.well-known/aicp and a principal-scoped Capability Document. It selects a workload deployment action using the action URI, target type, effect class, and schemas. 2. The client requests a decision Situation for the production workload with a freshness limit and a 32 KiB budget. The Situation reports workload revision 42, three healthy replicas, one active read-only inspection, applicable production policy, complete decision coverage, and the deployment action. 3. The client posts an Intent Request with a unique request identifier, target release digest, maximum one unavailable replica, no downtime, no data loss, cost limit, and health/error- rate criteria. It requests preview. 4. The provider returns a Plan with revision 3, a five-minute expiry, exact release change, two ordered steps, resource- revision and capacity preconditions, medium risk, and one release-owner approval requirement. The HTTP response contains a strong entity tag. 5. The approver sees and approves Plan revision 3. The approval record binds the target, release digest, material change, risk, and expiry. Paxton Expires 6 March 2027 [Page 46] Internet-Draft AICP September 2026 6. The client posts an Execution Request naming Plan revision 3 and uses If-Match with the Plan entity tag. The provider re- evaluates current policy and preconditions, then returns 202, an Operation, and its Location. 7. The client waits on the Operation resource. Events show staging, health verification, promotion, and final verification. A temporary event delivery gap causes the client to retrieve the current Operation rather than infer state. 8. The Operation reaches succeeded with complete effects. Its Outcome shows the expected release change, the observed release change, no side effects, satisfied health and error-rate criteria, and evidence links. If the native provider timed out after accepting the promotion and could not determine its effect, step 7 would instead produce indeterminate, unsafe retry guidance, and a reconciliation action. Reconciliation would inspect native state before any completion or compensation Plan. Appendix B. Protocol Invariants This appendix summarizes safety invariants. The normative text in the body controls. 1. No consequential effect occurs from a preview request. 2. No client-supplied claim creates authority. 3. An approval authorizes only one exact Plan revision and context. 4. A stale Plan is rejected, not silently recomputed and executed. 5. A hard constraint is satisfied, rejected, or reported unknown; it is not silently relaxed. 6. A durable Operation exists for every accepted consequential execution. 7. Success is determined by required outcome criteria, not only API-call completion. 8. Phase and effect certainty are represented separately. 9. Possible, partial, or unknown effects are never blindly retried. Paxton Expires 6 March 2027 [Page 47] Internet-Draft AICP September 2026 10. Compensation is a new consequential action with new authorization. 11. Every truncated context states its coverage and omissions. 12. Every binding reaches the same policy and audit boundary. 13. Prose and private reasoning are not protocol authority. Appendix C. Open Issues for Subsequent Revisions This appendix records issues on which implementation experience is requested: * whether the core should standardize canonical JSON comparison and an exact decimal convention; * whether event delivery should select a required streaming format; * whether approval exchange belongs in the core or a separate profile; * which common vocabularies and evidence architecture belong in the first workload lifecycle profile; and * whether batch and multi-resource atomicity require a transaction profile. Appendix D. Change Log This section is to be removed before RFC publication. draft-paxton-aicp-00 Initial individual draft defining the core object model, control lifecycle, HTTP binding, agent-protocol relationships, reliability behavior, security, privacy, and IANA requests. Author's Address Tihan-Nico Paxton Apollo Deploy Email: tihan-nico@apollodeploy.com Paxton Expires 6 March 2027 [Page 48]