A New IETF Draft Wants Every Agent Action Against Infrastructure to Carry Its Own Receipt Before It Runs

Draft paxton aicp 00, titled Agent Infrastructure Control Protocol, was published 2 September 2026 by Tihan-Nico Paxton of Apollo Deploy as an individual Internet Draft, intended status Standards Track, expiring 6 March 2027. The document header names no working group; the Workgroup field reads only "Internet Engineering Task Force," the placeholder every individual submission carries in the absence of one. This record verifies the draft's own text directly, section by section, and separates what its normative language actually requires from what the draft itself declines to define.

An unusually complete first submission

Where many revision 00 individual drafts sketch an architecture and leave large sections as placeholders, this one specifies a full object model, an HTTP binding, IANA registration requests for a media type and a well known URI, and a twelve item minimum conformance test list, in one 39 page submission. The draft's own Appendix C lists five open issues it defers to later revisions, among them whether the core should standardize canonical JSON comparison, whether event delivery needs a required streaming format, and whether the approval exchange mechanism itself belongs in the core specification or a separate profile. That is a candid list from the author, not a gap this record found independently, and this record treats the specification's breadth and its self stated incompleteness as two separate facts rather than letting the first obscure the second.

The eight step control loop

Section 1 states the draft's contribution as a linked control loop, and the draft's own numbered list is worth reproducing exactly because the properties it names are the ones this record verifies below:

• discover the capabilities available to the authenticated principal;
• obtain a bounded, freshness labelled situation;
• state an intent, hard constraints, and success criteria;
• receive a concrete, expiring plan with material changes, assumptions, unknowns, risk, feasibility, and authorization state;
• bind approval and execution to that exact plan revision;
• observe a durable asynchronous operation;
• verify the actual outcome and side effects; and
• reconcile or compensate when effects are uncertain or unacceptable.

Section 4.1 grounds that loop in seven durable object classes: Capability Document, Situation, Intent Request, Plan, Operation, Outcome, and Problem, plus an Operation Event as the incremental delivery form for a changing Operation. Each object must identify or link to the object before it: a Plan identifies its Intent Request and the Situation it was based on, an Operation identifies the exact Plan revision it executes, an Outcome identifies the Operation and preserves both the expected and the observed effects. The draft describes this graph as an audit and resumption chain, built so a different process, agent or human operator can pick up where another left off without relying on a lossy transcript or private model state, a design goal Section 16.3 names Accretive Context.

Discovery is explicitly not a grant

Section 6.3 states this in one sentence the rest of the specification is built around: "A capability listing indicates discoverability, not a durable authorization grant; policy is evaluated again when planning and immediately before execution." A Capability Document can be scoped to the authenticated principal, and where it is, the draft requires private HTTP caching and forbids reusing one principal's response for another, but the document itself is read only metadata: what actions exist, what they require, what effect class and risk level they default to. Section 6.2 requires every Action Descriptor to carry an effect class of read only or consequential, whether planning is required, optional or unsupported, and explanatory permission names the draft states plainly "are not bearer capabilities and MUST NOT be accepted as proof of authority." Section 4.2 states the same boundary as a provider obligation rather than a client courtesy: "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 a delegation reference is an input to policy evaluation, the draft says, not proof of permission.

Feasibility, authorization and readiness, kept apart on purpose

Section 9.3 defines three independent dimensions a Plan carries. Feasibility, feasible, conditional, infeasible or unknown, answers whether the provider can satisfy the intent and its hard constraints at all. Authorization, allowed, denied, approval required, clarification required or unknown, answers whether the authenticated principal can execute this exact plan revision right now. Readiness, ready, blocked, expired or unknown, is the provider's combined answer about whether execution can safely be requested at all, and the draft is explicit that readiness is "a point-in-time advisory" that "MUST be re-evaluated immediately before the first consequential effect," not a value a client can cache and reuse. A Plan is ready only while it is unexpired, feasible, authorized as allowed, free of unmet approval requirements, and valid against every checked precondition. Collapsing any of those three into the others is exactly the failure this record's own registry already tracks under other evidence: an objective the agent was authorized to pursue is not the same fact as authorization for the specific action it attempts, and a capability existing is not the same fact as a capability being currently permitted.

Approval binds to one exact plan revision, not to prose

Section 9.1 makes a Plan revision immutable the moment it is referenced by an execution attempt or an approval: "Later evaluation creates a new revision and preserves the older audit record." Section 9.4 then states the binding requirement directly: "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." Section 10.1 closes the loop on the execution side: "The provider MUST reject execution when the Plan is missing, expired, stale, infeasible, denied, or outside a hard constraint," and "A provider MUST NOT recompute a stale Plan and execute the new result under the old approval." The HTTP binding in Section 14.5 gives this a concrete mechanism: an execution request must carry the Plan's exact revision and use an HTTP If-Match conditional header against the Plan's current strong entity tag, and a mismatch returns a dedicated problem code, plan-stale, rather than falling through to execution.

Execution is its own authorization decision

Section 10.1 states this as its own sentence, separate from the plan staleness language above: "Execution is a new authorization decision. A previously allowed Plan does not override revocation, changed principal status, emergency stop, quota, or policy changes." That single line is the draft's answer to a failure this record's own registry already names elsewhere: a plan being feasible and approved at one moment does not certify that the same action remains authorized once execution is actually requested, because the state an authorization decision depends on, principal status, quota, an emergency stop, upstream policy, can move in between. Section 19.3 extends the same discipline to revocation specifically: "Revocation prevents new effects but does not erase or hide active operations," and the provider is required to attempt safe pause, cancellation or containment and to report the actual resulting effect state, not to claim an operation simply stopped.

A durable Operation for every consequential execution, and effect state kept apart from phase

Section 10.2 requires a provider to create or return a durable Operation "before or atomically with accepting a consequential execution," identifying the Execution Request, the exact Plan identifier and revision, current phase, effect state, a monotonic sequence, progress, reasons, retry guidance and structured next actions. The draft is explicit that this Operation, not an event stream, is the source of truth: event delivery "can be delayed, duplicated, or interrupted," and a client can always retrieve the latest authorized representation while it is retained.

Section 10.3 defines nine phases, queued, awaiting approval, executing, verifying, paused, succeeded, failed, cancelled and indeterminate, six of them non terminal. Section 10.4 defines effect state as a fully separate axis: none, possible, partial, complete, reversed or unknown. The draft states the independence directly: "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." This is the same distinction, phase describing the provider's process and effect state describing the provider's certainty about the external world, that this record's registry already tracks as a recurring gap: a workflow reaching a terminal status is routinely mistaken for proof that its real world effect is fully known, when the two are separate facts a provider can and does get wrong independently.

Possible, partial and unknown effects can never be blindly retried

The same Section 10.4 table states, effect state by effect state, whether a blind retry is permitted. For none, retry is permitted only when retry guidance also says it is safe. For possible, partial and unknown, retry is stated as simply "Forbidden." For complete, retry is described as "Normally unnecessary and forbidden." For reversed, retry is "Forbidden unless a new plan says otherwise." Section 13.3 states the underlying reason: "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." When the provider cannot safely determine the effect, the Operation reaches a phase called indeterminate, and the draft's instruction to the client is unambiguous: "The client MUST NOT blindly retry and MUST use the advertised reconciliation path or escalate." Section 13.4 defines that reconciliation path as its own observation oriented action, one that inspects authoritative native state and compares it against the Plan's expected changes before proposing any new completion or compensation plan, and if reconciliation itself needs to mutate anything, that mutation is required to be represented as its own separate, newly authorized Plan and Operation rather than folded into the observation step.

Compensation is a new authorized action, never an implied rollback

Section 11.4 defines compensation precisely: "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 same section states that an action's reversibility descriptor, set when the original Plan was made, "is only a planning hint," and that current state, authorization and risk are evaluated again from scratch rather than assumed from the original plan's estimate; where full restoration is not possible, the compensation Plan is required to declare its own residual effects and unknowns rather than imply full reversal. Section 3.2 lists this as an explicit non goal of the specification as a whole: AICP does not "guarantee exactly-once execution or perfect rollback." That is the draft naming its own limit rather than a gap this record found by omission, and it is consistent with the rest of the document's discipline of stating uncertainty as a structured field rather than smoothing over it.

Machine actionable problems, not prose an agent has to parse

Section 12 defines an AICP Problem, built on RFC 9457 Problem Details, carrying a stable code, the relevant effect state, a structured retry.safe flag with optional delay, and whether reconciliation is required, alongside links to the current Plan, Operation, Situation or capability document. Section 12.1 states plainly that "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." The core problem code table in Section 12.2 includes plan-stale, approval-required, request-id-reuse, effect-indeterminate and reconciliation-required, each with a required behavior column stating explicitly whether the code implies no effect occurred, whether execution must not begin, or whether the caller must observe actual state before another mutation. Section 5.5 extends the same discipline to every human readable field in the object model, not just problems: "A client MUST NOT treat prose as authorization, executable instructions, a replacement for a stable code, or a reason to violate a structured constraint."

Security considerations name the failure modes this corpus already tracks

Section 20 addresses nine named threats in turn. Section 20.1, Confused Deputy and Cross-Tenant Access, requires a provider to resolve every Resource Reference in the authenticated principal's own context and states directly that "Links and cursors are not bearer authorization unless explicitly specified by the authentication system." Section 20.2, Stale Plan and Time-of-Check/Time-of-Use, restates the entity tag and immediate re-evaluation requirements from Section 9 as the corrective for an attacker or a concurrent actor changing infrastructure state after a preview was issued but before it executes. Section 20.3, Approval Substitution and Phishing, requires an approval interface to bind to exact Plan identity, revision, action, material changes, principal and expiry, and states that high risk plans "should require phishing-resistant authentication and independent confirmation appropriate to organizational policy." Section 20.4, Prompt Injection, Schema Poisoning, and Tool Shadowing, states that descriptions, resource labels, log content and telemetry annotations "can contain attacker-controlled text," treated as data rather than protocol instruction, with action selection required to run on authenticated service identity, a stable URI, schema and policy rather than a title an attacker controlled string could shadow. Section 20.5 through 20.9 cover replay and retry storms, a compromised provider adapter, secrets handling, autonomy and blast radius limits independent of a client's own stated risk tolerance, and audit integrity, closing with a sentence this record reads as directly on point for a distinction it already keeps: "Private model reasoning is neither necessary nor sufficient as an audit record."

What the draft explicitly does not decide

Section 3.2 lists the specification's non goals directly, and two of them matter most for this record's own ledger. AICP does not "define a new authentication, credential, payment, telemetry, signature, or approval protocol," and it does not "permit a client to self-assert permissions, risk acceptance, or approval." Section 4.2 restates the first point operationally: authentication and token acquisition are outside the document's scope, and a provider is expected to publish OAuth 2.0 Protected Resource Metadata when OAuth is the mechanism in use, a choice the draft names rather than mandates. This record's own reading is precise about what that leaves open. AICP specifies, in exacting detail, how an authorization decision must be bound, re-evaluated and recorded once a policy engine has made it. It does not specify, and states directly that it does not attempt to specify, whether the authenticated principal that decision is made for actually held legitimate authority to request the action in the first place. That question, identical to the one this record's registry already tracks against every credential and delegation architecture it has evaluated, from a certificate authority's own issuance policy to a delegated grant's attenuation, is left entirely to "provider policy engines" the draft treats as an external, unspecified dependency. AICP is a grammar for expressing and binding an authorization decision once one exists. It is not a mechanism for establishing that the decision itself was correct.

Evidence status: a specification with no known implementation, one week old

At the time of this verification, the draft carries no reported working group adoption, no named reference implementation, and no adoption or interoperability report this session could find, consistent with a status-track individual submission seven days past its own publication date. This record's own reading of every normative requirement above is design evidence, drawn directly from the specification's own text, not demonstrated behavior from a running system, and this record grades it accordingly rather than treating a well specified document as proof that any provider has built it. The draft's own reference list places it deliberately alongside other work this corpus already tracks: EMILIA, the Evidence Architecture for Consequential Agent Actions already covered in this dataset as its own protocol record, appears as an informative reference for evidence and receipt handling, and the Agent Execution Protocol, a governed reasoning loop boundary this record has not yet independently evaluated, is named as the layer AICP expects to sit beneath its own object model rather than replace.