Network Working Group S. Saha Internet-Draft Independent Intended status: Standards Track September 2026 Expires: 5 March 2027 The Agent Action Decision Protocol (AADP): Per-Action Authorization for AI Agents draft-saha-aadp-02 Abstract The Agent Action Decision Protocol (AADP) separates per-action authorization from an agent's identity and its standing capabilities, and gives that authorization semantics that a stateless tool permission or access grant cannot express: whether a specific proposed action, with specific argument values, may be performed now, given mutable state such as cumulative budgets, live reservations, approval lifecycle, and a kill switch. Existing agent-security work concentrates on identity -- who an agent is, what credentials it holds, and which tools it may reach; AADP addresses the complementary decision, and composes with that work rather than replacing it. This document defines a two-phase wire contract between a Policy Decision Point (PDP) that authorizes agent actions and the Policy Enforcement Points (PEPs) that perform them: verdicts with machine-readable reasons, obligations that fail closed, atomic budget reservation, an approval lifecycle, idempotency behavior, evidence sufficient to re- derive every verdict, and a set of evaluation invariants any conformant decision point must observe -- including the rule that an irreversible action is never executed autonomously. The protocol is transport-agnostic and is designed so that decision points and enforcement points can be implemented independently, in different languages, by different parties. 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." Saha Expires 5 March 2027 [Page 1] Internet-Draft AADP September 2026 This Internet-Draft will expire on 5 March 2027. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Autonomy Tiers . . . . . . . . . . . . . . . . . . . . . 6 3.2. Verdicts . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Reason Codes . . . . . . . . . . . . . . . . . . . . . . 7 4. The Two-Phase Exchange . . . . . . . . . . . . . . . . . . . 9 5. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Decide Request . . . . . . . . . . . . . . . . . . . . . 10 5.2. Decide Response . . . . . . . . . . . . . . . . . . . . . 11 5.3. Report Request and Response . . . . . . . . . . . . . . . 12 6. Obligations . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Idempotency, Replay, and Exactly-Once Semantics . . . . . . . 13 8. Approvals . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Evaluation Invariants . . . . . . . . . . . . . . . . . . . . 15 10. Evidence . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Failure Semantics . . . . . . . . . . . . . . . . . . . . . . 18 12. Transport Bindings . . . . . . . . . . . . . . . . . . . . . 18 12.1. Transport Security . . . . . . . . . . . . . . . . . . . 19 12.2. HTTP/JSON Binding . . . . . . . . . . . . . . . . . . . 19 12.3. Local Socket Binding . . . . . . . . . . . . . . . . . . 20 13. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 20 14. Versioning . . . . . . . . . . . . . . . . . . . . . . . . . 21 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 15.1. AADP Verdicts Registry . . . . . . . . . . . . . . . . . 21 15.2. AADP Reason Codes Registry . . . . . . . . . . . . . . . 21 15.3. AADP Obligation Types Registry . . . . . . . . . . . . . 22 Saha Expires 5 March 2027 [Page 2] Internet-Draft AADP September 2026 16. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 22 17. Security Considerations . . . . . . . . . . . . . . . . . . . 23 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 18.1. Normative References . . . . . . . . . . . . . . . . . . 25 18.2. Informative References . . . . . . . . . . . . . . . . . 25 Appendix A. Worked Exchange (Tier 3) . . . . . . . . . . . . . . 27 Appendix B. Implementation Status . . . . . . . . . . . . . . . 27 Appendix C. Changes from draft-saha-aadp-01 . . . . . . . . . . 30 Appendix D. Changes from draft-saha-aadp-00 . . . . . . . . . . 31 Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction AI agents increasingly perform consequential actions: moving money, modifying data, sending communications, executing code, and provisioning infrastructure. The frameworks that host these agents typically decide what an agent can do by controlling which tools are exposed to it. Recent analysis has shown that this conflates two distinct questions: capability (whether an agent can invoke a tool) and authorization (whether this call, with these argument values, should be performed now) [SCOPEGATE]. A tool that is legitimately exposed for one purpose can be invoked for another; an agent authorized to make one payment can attempt a second; and a generic capability such as an HTTP client can reach effects its name does not declare. Parallel work standardizes agent identity and credential flows [I-D.klrc-aiagent-auth] [I-D.ni-wimse-ai-agent-identity] and hardens the authorization of protocol connections [MCP]. That work answers who the agent is and what it may reach; the WIMSE applicability work states explicitly that whether an agent inherits its user's permissions is out of its scope. It deliberately leaves per-action concerns -- budget enforcement, obligation tracking, approval lifecycle -- as deployment-specific. AADP specifies exactly that remainder: a small, implementable contract for per-action authorization decisions, designed to compose with identity-layer standards rather than replace them. Closer to this document, [I-D.liu-agent-operation-authorization] authorizes individual operations delegated from a human principal, carrying policy as Rego, signed confirmation evidence, and a delegation chain across multiple agents. It addresses a different remainder: consent and delegation lineage. It does not constrain cumulative spend, and the approval it records is a binary confirmation rather than a lifecycle with expiry and re-evaluation. AADP is complementary to it: the state that must persist between calls -- budgets shared across differently-named tools, reservations Saha Expires 5 March 2027 [Page 3] Internet-Draft AADP September 2026 that outlive a decision, approvals that can expire -- is what this document specifies, and it cannot be expressed by evaluating one call at a time however the policy is written. The Policy Decision Point / Policy Enforcement Point split, and the concept of obligations attached to a permission, originate in XACML [XACML]. AADP inherits that vocabulary deliberately and differs in what it standardizes: agent-action semantics that stateless policy evaluation cannot express -- stateful budget reservation shared across differently-named tools, autonomy tiers with reversibility as a precondition, a two-phase exchange separated by a durability boundary, and typed evidence sufficient to re-derive every verdict. The distinction from OAuth-style authorization [RFC6749] is the same one, stated in the vocabulary a reviewer is most likely to reach for. An access grant or a bearer or sender-constrained access token answers a standing question: may this principal access this resource under this scope. It is issued ahead of use, is coarse relative to a single call, and carries no notion of how much of a budget the principal has already spent this window or whether a human approval it once relied on has since expired. AADP answers a per-invocation question over the concrete action and its argument values, and the answer is a function of mutable authorization state -- cumulative spend, live reservations, approval lifecycle, kill switch, and prior executions -- that a grant or token does not carry and cannot be made to carry without becoming a decision point itself. AADP is therefore best deployed beneath an identity and token layer, not in place of one: the token establishes who is acting and what they may reach; AADP decides whether this action proceeds now. 1.1. Scope AADP specifies: the request an enforcement point sends to ask permission; the answers a decision point may return; the obligation that accompanies a permission; the report that must follow an attempted action; the ordered evaluation invariants a conformant decision point must observe; and idempotency, approval, and failure semantics. AADP does not specify a policy language, a storage engine, an approval user interface, or a particular transport. It does specify the security properties the transport must provide (Section 12.1) and the trust boundary within which its guarantees hold (Section 1.2). Policy composition -- tiers, effect labels, budgets, parameter bounds -- is internal to the decision point. Only the verdict and its reason cross the wire. Saha Expires 5 March 2027 [Page 4] Internet-Draft AADP September 2026 1.2. Trust Model AADP's guarantees hold within a single governed domain in which the PDP and its PEPs trust one another and communicate over a secured channel (Section 12.1). The PEP is the point at which an action actually happens; within the domain it is trusted to submit the action it intends to perform and to perform the action it was permitted. AADP does not, in this revision, defend against a compromised or malicious PEP that submits one action and performs another: such a PEP already possesses the ability to act, and no message from the PDP can constrain code that has decided to ignore it. What AADP does require is that no _unsupervised_ path to a governed capability exists (Section 17); a capability reachable without a PEP is outside the protocol's view. Two deployment shapes fall outside this trusted-domain model and are addressed as future work rather than by this revision. The first is an intermediary that terminates the secured channel -- a gateway, a service mesh sidecar, or a proxy that sees cleartext -- which is a credentialed party in the path rather than a passive relay. The second is a permit that must be honoured across a trust boundary, stored, or forwarded, rather than consumed on the same secured channel that issued it. Both require a permit that is a verifiable, action-bound capability in its own right: signed by the PDP, carrying a digest of the exact authorized action and its parameters, an expiry, and a binding to the PEP entitled to use it, so that an intermediary or holder can neither substitute the action nor transfer the permit. Such a permit is a compatible extension of the decide response and is a planned addition; deployments requiring it today MUST NOT assume the bearer permit of this revision provides it. 1.3. Requirements Language 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. 2. Roles Policy Decision Point (PDP): Evaluates a proposed action and returns a verdict. Owns policy, budget state, approval state, and the evidence record. There is exactly one logical PDP per governed domain. A logical PDP MAY be realized by several replicas, provided they present linearizable semantics for every piece of authorization state that can affect a verdict -- budgets, reservations, approval state, and the kill switch. A replication Saha Expires 5 March 2027 [Page 5] Internet-Draft AADP September 2026 scheme under which two replicas can independently reserve the same budget, or under which a kill switch engaged at one replica is not observed at another before it decides, is not conformant: it breaks the atomic-reservation invariant of Section 9. Policy Enforcement Point (PEP): Sits wherever actions actually happen -- an agent-framework tool wrapper, a protocol proxy, an API gateway filter, a container or micro-VM supervisor, a workflow engine. A PEP MUST NOT perform a governed action without a permit, and MUST report the outcome of every permit it receives. A deployment MAY have many PEPs consulting one PDP. Every PEP is bound by the same contract. 3. Protocol Model 3.1. Autonomy Tiers Tiers are ordered integers; higher means less autonomy. +======+=============+===============================+ | Tier | Name | Meaning | +======+=============+===============================+ | 0 | observe | read-only; no external effect | +------+-------------+-------------------------------+ | 1 | auto | may execute automatically; | | | | MUST be reversible | +------+-------------+-------------------------------+ | 2 | auto_capped | may execute automatically | | | | within budgets | +------+-------------+-------------------------------+ | 3 | confirm | requires human approval | | | | before execution | +------+-------------+-------------------------------+ Table 1: Autonomy Tiers A verdict carries both the nominal tier (configured for the action) and the effective tier (after escalation). When they differ, the action was escalated, and the reason code states why. PDPs MUST report both. Saha Expires 5 March 2027 [Page 6] Internet-Draft AADP September 2026 3.2. Verdicts +=========+============================+===========================+ | Verdict | Meaning | PEP obligation | +=========+============================+===========================+ | permit | the action may proceed now | execute, then report | | | | exactly once | +---------+----------------------------+---------------------------+ | deny | the action must not | do not act; no report | | | proceed | | +---------+----------------------------+---------------------------+ | propose | a human must approve first | do not act; surface the | | | | approval id | +---------+----------------------------+---------------------------+ | dry_run | rehearsal only; no real | do not act; MAY simulate | | | effect | | +---------+----------------------------+---------------------------+ | observe | read classified as no- | act freely; no report | | | effect | required | +---------+----------------------------+---------------------------+ | replay | this request id was | honour the original | | | already decided | verdict; do not act again | +---------+----------------------------+---------------------------+ Table 2: Verdicts and PEP Obligations 3.3. Reason Codes Every verdict MUST carry exactly one machine-readable reason. Conformant PDPs MUST use the identifiers in Table 3 where they apply, and MAY define additional codes under a vendor prefix ("x-" followed by a vendor token and a dot). Saha Expires 5 March 2027 [Page 7] Internet-Draft AADP September 2026 +=========================+=========================================+ | Code | Meaning | +=========================+=========================================+ | passed | all checks satisfied | +-------------------------+-----------------------------------------+ | kill_switch | the global stop is engaged | +-------------------------+-----------------------------------------+ | default_deny | no policy exists for this | | | action type | +-------------------------+-----------------------------------------+ | bounds | a parameter violated its | | | declared bounds | +-------------------------+-----------------------------------------+ | budget_exhausted | a value or quantity budget | | | is exhausted (detail in the | | | "budget" object) | +-------------------------+-----------------------------------------+ | rate_exhausted | a rate budget (events per | | | window) is exhausted (detail | | | in the "budget" object) | +-------------------------+-----------------------------------------+ | dry_run | the action is in rehearsal | | | mode | +-------------------------+-----------------------------------------+ | tier_confirm | policy requires human | | | approval | +-------------------------+-----------------------------------------+ | effect_floor | an effect class imposes a | | | stricter tier than the | | | action's own | +-------------------------+-----------------------------------------+ | no_compensating_command | the action is irreversible | | | and cannot auto-execute | +-------------------------+-----------------------------------------+ | observe | the action is a governed | | | read | +-------------------------+-----------------------------------------+ | malformed | the request could not be | | | parsed or validated | +-------------------------+-----------------------------------------+ Table 3: Reason Codes Saha Expires 5 March 2027 [Page 8] Internet-Draft AADP September 2026 The budget reason codes are deliberately currency- and unit-neutral: a budget may be denominated in a currency, in tokens, in API calls, or in any other countable dimension, and the protocol does not privilege one. A verdict carrying "budget_exhausted" or "rate_exhausted" SHOULD include a "budget" object naming the exhausted budget and the dimension it counts: "budget": { "name": "payments.daily", "dimension": "EUR", "limit": "10000.00", "remaining": "0.00", "window": "24h" } "dimension" is an opaque unit label ("EUR", "tokens", "calls"). Values counted in a currency or other divisible quantity are decimal strings, as elsewhere in this document. A recipient that does not recognize the dimension still learns that a budget was the cause and can surface the object verbatim. 4. The Two-Phase Exchange AADP is a two-phase protocol. The phases are separated by a durability boundary because the act between them may be slow, remote, or fatal. PEP PDP | decide(request) | |------------------------------->| evaluate, reserve budget, | | record intent, COMMIT |<-------------------------------| | permit(permit_id, obligations)| | | [ PEP performs the action ] | | | | report(permit_id, outcome) | |------------------------------->| record linked result, COMMIT |<-------------------------------| A PEP that receives a permit MUST send exactly one report, whatever happened -- success, failure, timeout, or refusal to act. A PDP MUST treat a permit with no report as an unresolved intent and MUST NOT release its budget reservation implicitly. An unresolved intent therefore holds budget that no action ever spent, and a caller that requests permits and never reports can exhaust a budget at the cost of one decide call per permit, leaving Saha Expires 5 March 2027 [Page 9] Internet-Draft AADP September 2026 no effect at the sink to detect. Reservations MUST therefore be reclaimable explicitly rather than only implicitly: a PDP that issues a permit carrying "execute_within" (Section 6) MUST, once that deadline has passed with no report, append an expiry entry to the evidence record and release that permit's reservation. The release is an audited event, not a silent timeout, and the permit is void from that point. A PDP SHOULD attach "execute_within" to every permit that reserves budget; one that does not MUST document how reservations are otherwise reclaimed. Combining the two phases into a single call is not conformant: a decision point that waits for the act holds state across an operation it does not control. 5. Messages All messages are JSON objects [RFC8259]. Timestamps are [RFC3339] in UTC. Monetary values are decimal strings (for example, "12.50"), never floating-point numbers. This rule applies wherever a monetary value appears, including inside "params": the example in Section 5.1 carries "amount_eur" as "40.00", and a PDP that evaluates numeric bounds or caps over such a parameter MUST accept the decimal-string form, evaluated exactly, and MUST NOT require the caller to supply a binary floating-point number instead. (Recorded here in this revision because a conforming-looking implementation got it wrong; see Appendix B.) 5.1. Decide Request { "protocol": "aadp/0.1", "request_id": "0a5f2c3e-1b7e-4f2a-9c1d-6b0f9e2a77c1", "action_type": "payments.transfer", "params": { "payee": "acme-gmbh", "amount_eur": "40.00" }, "source": "llm", "rationale": "user asked to settle invoice 8841", "session_id": "sess-91f3", "cost_eur": "40.00", "created_at": "2026-08-17T09:14:02Z", "parent_id": null } Field requirements: "protocol", "request_id" (a UUID; the idempotency key, see Section 7), "action_type" (an opaque identifier; the PDP's policy key), "params" (a JSON object, possibly empty, treated as untrusted input), "source" (one of "scheduler", "rule", "llm", "ui", "undo", "system"), "rationale" (human-readable justification, recorded as evidence), and "created_at" are REQUIRED. "session_id" Saha Expires 5 March 2027 [Page 10] Internet-Draft AADP September 2026 and "cost_eur" are RECOMMENDED; "cost_eur" is REQUIRED when value budgets apply. "parent_id" identifies the permit being reversed when "source" is "undo". "approval_ref" carries the "approval_id" of a granted approval when a PEP itself resumes a previously proposed action (Section 8); it is REQUIRED in that case and MUST be absent otherwise. A PDP MUST verify that an "approval_ref" refers to an approval that is granted, unexpired, unconsumed, and raised for an action equivalent to the one now requested; if it does not, the request is evaluated as though no approval had been supplied. "source" is informational and self-asserted. A conformant PDP MUST NOT treat "source" as an authenticated authority assertion, and MUST NOT let its self-declared value change the verdict: an action's governance binds to the action, not to a claim about who proposed it, and a caller that could set "source" to escalate its own privilege would make the field an attack surface. Where provenance is genuinely authorization-relevant -- for example, distinguishing a trusted scheduler from an untrusted model -- it MUST be established by an authenticated channel or credential (Section 12.1) and represented as authorization context the policy evaluates, not read from this field. Evaluation is total with respect to its input. A PDP that receives a request it cannot parse or validate -- a missing required field, a value of the wrong type, a malformed identifier, an unparseable body -- MUST return a "deny" verdict with reason "malformed", and MUST NOT signal the failure only as a transport-level or runtime error. Fail- closed behavior is a property of the decision point; a PDP that raises instead of deciding delegates that property to each enforcement point, where it holds only by convention. Where the supplied "request_id" is itself well-formed the response SHOULD echo it; where it is not, the response MUST NOT invent one. This requirement covers invalid input, not internal failure. A PDP that cannot evaluate because its own policy store, evidence record or budget ledger is unavailable SHOULD NOT report that condition as a routine denial, since that makes a defect indistinguishable from a policy outcome; such a PDP is unreachable for this request, and Section 11 governs what the enforcement point does next. 5.2. Decide Response Saha Expires 5 March 2027 [Page 11] Internet-Draft AADP September 2026 { "protocol": "aadp/0.1", "request_id": "0a5f2c3e-1b7e-4f2a-9c1d-6b0f9e2a77c1", "verdict": "permit", "reason": "passed", "detail": "", "nominal_tier": 1, "effective_tier": 1, "permit_id": "int-88213", "obligations": [ { "type": "report_result", "required": true }, { "type": "undo_available_until", "value": "2026-08-17T09:29:02Z" } ], "approval_id": null, "evidence_id": "aud-88213" } "permit_id" is present if and only if the verdict is "permit". "approval_id" is present if and only if the verdict is "propose". "evidence_id" references the entry in the PDP's evidence record and SHOULD be present for every verdict. 5.3. Report Request and Response { "protocol": "aadp/0.1", "permit_id": "int-88213", "outcome": "success", "payload": { "confirmation": "TX-77120" }, "error": null, "completed_at": "2026-08-17T09:14:03Z" } "outcome" MUST be one of "success", "failure", "timeout", or "not_attempted". "not_attempted" is the correct value when a PEP declines to act, for example because it cannot satisfy an obligation (Section 6). { "protocol": "aadp/0.1", "accepted": true, "evidence_id": "aud-88214" } 6. Obligations An obligation is a condition attached to a permit that the PEP MUST satisfy for the permission to be valid. Obligations are typed and extensible; they are the protocol's extension point for enforcement capabilities the PDP itself cannot provide. Saha Expires 5 March 2027 [Page 12] Internet-Draft AADP September 2026 +======================+===================================+ | Type | Meaning | +======================+===================================+ | report_result | the PEP MUST send exactly one | | | report (always implied) | +----------------------+-----------------------------------+ | undo_available_until | a reversal window; the PEP SHOULD | | | retain what is needed to reverse | +----------------------+-----------------------------------+ | execute_within | a deadline after which the permit | | | is void | +----------------------+-----------------------------------+ | isolate | the action MUST be performed | | | inside an isolation boundary | | | meeting the stated profile | +----------------------+-----------------------------------+ Table 4: Obligation Types Unknown obligations fail closed. A PEP that receives an obligation whose type it does not recognize MUST NOT perform the action, and MUST report "not_attempted" with an error naming the unsupported type. A PEP MUST NOT silently ignore an obligation: a policy author has to be able to assume that an issued obligation was either honoured or visibly refused. Where an obligation admits evidence of its discharge (for example, the identity of the isolation boundary used), the PEP SHOULD include that evidence in its report payload, so that the discharge is recorded alongside the decision. Vendor-specific obligations MUST use a vendor prefix as in Section 3.3. 7. Idempotency, Replay, and Exactly-Once Semantics "request_id" is the idempotency key for the decision. A PDP that receives a decide request for a request_id it has already decided MUST return the original verdict with "verdict" and "reason" unchanged, and MUST NOT re-reserve any budget. Implementations MAY additionally set "replayed": true. A "permit_id" is single-use. A second report for the same permit_id MUST be rejected with "accepted": false. Resuming an approved action (Section 8) is a new decision with a new request_id; reusing the proposed request's id would return the "propose" verdict forever. Saha Expires 5 March 2027 [Page 13] Internet-Draft AADP September 2026 Three distinct "exactly once" properties must be kept apart, because AADP provides two of them and cannot provide the third alone: At-most-once permit consumption: a permit authorizes one attempt. The single-use rules above guarantee it. Exactly-once decision and report state: each request reaches exactly one recorded verdict, and each permit exactly one recorded resolution. The idempotency key and the durable evidence record (Section 10, Section 9) guarantee it. Exactly-once external effect: the governed action takes effect on the target resource at most once. AADP cannot guarantee this on its own, because the effect happens at the target, outside the protocol. The gap is the interval in which a PEP has issued the action to the target but has not recorded its outcome. If the PEP fails there and recovers, it holds a permit whose effect is unknown: the transfer may or may not have completed. A PEP MUST NOT re-issue the action -- under this permit, a replayed decision, or a fresh one -- unless it can positively establish that the action did not take effect. Where it cannot, it MUST report the outcome as "timeout" (the honest value for "attempted, result unknown") and leave reconciliation to the target system or an operator, rather than risk a duplicate effect. Blind retry of an uncertain action is the most likely way a governed system performs a consequential action twice. To narrow the gap, a PEP SHOULD, where the target resource accepts an idempotency or client-reference key, derive that key deterministically from the permit (for example, from "permit_id") and pass it to the target, so that a retried or duplicated downstream call collapses to a single effect at the target. AADP standardizes the authorization exchange; exactly-once effect is achieved only when the target participates, and this is the mechanism by which it does. The derived key is not the permit. "permit_id" is the identity of AADP's decision and report lifecycle and nothing else: the PDP mints it, exactly one report resolves it, and no party outside the governed domain is ever asked to honour it. An adapter that needs a provider idempotency key derives one at its own boundary, under the target's rules, as above; the protocol itself propagates nothing downstream. Implementations MUST NOT present "permit_id" to a target resource as a credential or as a key carrying meaning there: that would give the permit a second identity in a namespace this document does not govern, and couple the authorization lifecycle to every downstream system's key semantics. Saha Expires 5 March 2027 [Page 14] Internet-Draft AADP September 2026 8. Approvals When the verdict is "propose", the PDP creates an approval record with a deadline and returns "approval_id". Approval state transitions are pending to approved, denied, or expired. A conformant PDP MUST: transition pending to approved atomically, rejecting a second approval and any approval after the deadline; record who approved and when; and re-evaluate the action on resumption. An approval authorizes the action, not the outcome: a kill switch engaged between approval and resumption MUST still deny. A granted approval is single-use: the PDP MUST mark it consumed when a resumed request is decided against it, so that one human decision cannot authorize repeated actions. Resumption may be driven from either side, and both forms are conformant provided the guarantees above hold. In PEP-driven resumption, the PEP issues a fresh decide request carrying "approval_ref". In PDP-driven resumption, granting the approval is itself the resumption: the PDP re-evaluates the recorded request under a fresh request_id and returns a decide response. A PDP MUST document which form it implements, and MUST NOT let either form bypass re-evaluation. Approval transport -- who is notified, and how -- is out of scope. 9. Evaluation Invariants This section is the normative core. AADP is a stateful protocol: a verdict depends not only on the request and the policy but on authorization state -- cumulative budgets, live reservations, approval records, and the kill switch -- that changes over time. The determinism the protocol requires is therefore determinism over the full evaluation input. Two conformant PDPs evaluating the same request against the same policy and the same authorization state, at the same evaluation time, MUST reach the same verdict; equally, the same request may be permitted at one moment and denied moments later once a budget is spent or a kill switch is engaged, with no inconsistency. The evidence record (Section 10) preserves the policy and the request; a record intended to re-derive a past verdict MUST also capture the authorization state the verdict was evaluated against, since without it the verdict is not reproducible. Implementations MAY optimize freely -- caching, compiling, reordering pure checks -- provided these observable orderings hold. 1. The kill switch is evaluated first, before policy lookup. An engaged kill switch MUST NOT be overridable by a policy entry. Saha Expires 5 March 2027 [Page 15] Internet-Draft AADP September 2026 2. Unknown actions are denied. Absence of policy is a denial with reason "default_deny", never a permission. 3. Irreversibility escalates. An action at tier "auto" with no registered means of reversal MUST NOT auto-execute; it escalates to "confirm" with reason "no_compensating_command". 4. Bounds are validated before proposal. A human MUST NOT be asked to approve an action whose parameters already violate policy. 5. Rehearsals do not spend. If an action is in dry-run, the PDP MUST NOT reserve any budget. 6. Budget reservation is atomic and all-or-nothing. Where an action draws on several budgets, all MUST be checked before any is reserved, and a failure on any MUST leave every counter untouched. Concurrent requests MUST NOT be able to over-reserve a budget. 7. Escalation is recorded, not hidden. When effective tier exceeds nominal tier, the reason MUST identify the escalating check. 8. Reversal is governed. An undo is itself an action subject to the full pipeline. There is no privileged path. 9. Intent precedes action. The evidence record of a permit MUST be durable before the permit is returned. A crash between phases MUST leave a recoverable, detectable state: an intent with no result. 10. Evidence A conformant PDP MUST maintain an append-only record in which each entry carries at minimum: the request, the verdict, the reason code, both tiers, a timestamp, and -- for results -- a link to the intent it resolves. Entries MUST NOT be updated or deleted. Corrections are appended, never applied in place. Implementations SHOULD enforce this structurally (storage-level constraints), not only by convention. Saha Expires 5 March 2027 [Page 16] Internet-Draft AADP September 2026 The record MUST be sufficient to re-derive every verdict it contains, given the policy version in force at the time. A PDP MUST therefore identify, on every entry, the policy that produced it, and MUST retain that policy for as long as the entries referring to it are retained. Identifying the policy by a content digest of its normative content is RECOMMENDED, so that an unchanged policy keeps one identity and a reverted change is recognisable as a return to an earlier one rather than as a third state. This requirement exists because policy is usually stored mutably. A decision point that overwrites policy in place, and records only the verdict, has an evidence record that cannot be checked: it cannot show that a permit issued last week was correct under last week's rules, and an operator who loosens policy, acts, and restores it leaves nothing behind. Retaining superseded policy is what makes the rest of this section meaningful. Re-derivability constrains what an entry preserves about its input. The verdict is a function of the request, the policy, the authorization state, and the evaluation time (Section 9); an entry is sufficient only if that evaluation input is reconstructible from it. In particular, where provenance is authorization-relevant (Section 5.1), the entry MUST preserve the provenance of every authorization-relevant value: a value established through authenticated authorization context and a byte-identical value asserted by the caller are different evaluation inputs, and a record format that stores only the value collapses two different decisions into one indistinguishable entry. When a decision turns on referenced evidence (Section 17), the entry MUST additionally preserve, for each reference consulted, its verification outcome in three states, never two: verified; verified and contradicting the condition it was offered for; and could not be dereferenced. Collapsing "could not be dereferenced" into failure points a later reviewer at the wrong remedy -- an unreachable verifier is an availability fact, a contradicting artifact a substantive one -- and the record MUST keep them apart. Where the verdict is a denial or an escalation because a condition went unsatisfied, the entry MUST identify that condition structurally -- the policy rule and the condition within it -- rather than in prose alone: a sentence is rationale again, human-authored this time, and still text nobody can hold against the policy version in force. The entry MUST also record the instrument of verification: the policy version is required above, and the method by which each reference was checked belongs beside it, since a reviewer re-checking the same references later otherwise runs a different instrument without knowing it. Saha Expires 5 March 2027 [Page 17] Internet-Draft AADP September 2026 The record establishes what the PDP was able to verify and evaluate at decision time; it does not overstate that as a claim about the underlying truth. An entry recording that a reference could not be dereferenced says exactly that -- not that the fact it was offered to establish is false. An entry MAY carry an external authorization reference, recording that an approval artifact from an external authorization profile was verified for this action: the identifier of the external profile, the digest of the artifact verified, the verification outcome in the three states above, and a digest computed over the action as this entry records it (the entry's action type and parameters). The reference is evidence, never input: its presence does not change a verdict, and what the policy evaluates over is the authorization state its verification establishes. The action digest is this record's own; an external profile's action identity is not substituted for it, and "permit_id" acquires no external meaning from the reference's presence. This gives an implementer a portable answer to "which approval artifact was verified for this action?" without turning "permit_id" into a credential or bringing approval transport into scope. One worked composition exercising this shape against an external evidence profile exists (Section 16). 11. Failure Semantics If a PEP cannot reach the PDP, its behavior is a deployment policy that MUST be configured explicitly, not defaulted silently: fail_closed (RECOMMENDED): perform no governed action. fail_static: permit only actions on a locally cached list of statically decidable, unbudgeted, tier-0/1 permissions, and queue evidence for later delivery. fail_open: perform the action. Conformant implementations MUST NOT make this the default and SHOULD require it to be named in configuration. A PEP operating under fail_static MUST deliver queued evidence when the PDP becomes reachable, and MUST NOT locally permit any action that would require a budget, an approval, or an obligation. 12. Transport Bindings The core protocol is transport-agnostic. This section states the security properties every binding MUST provide, then defines two concrete bindings. Saha Expires 5 March 2027 [Page 18] Internet-Draft AADP September 2026 12.1. Transport Security The channel between a PEP and a PDP carries requests whose integrity determines a verdict, verdicts a PEP acts on, and permits that are bearer capabilities: possession of a permit is, in this revision, sufficient to act. The channel MUST therefore provide confidentiality, integrity, and mutual authentication of both endpoints. Mutually-authenticated TLS following the recommendations of [RFC9325] satisfies this requirement and is RECOMMENDED; the local socket binding (Section 12.3) satisfies it by operating-system peer authentication on a single host. A permit or a role credential MUST NOT be transmitted over a channel that does not meet this requirement. This closes the man-in-the-middle exposure that the protocol otherwise carries. Without endpoint authentication and integrity, an attacker on the path can rewrite a decide request before the PDP evaluates it (so that a valid permit is issued for an action the agent never proposed), flip a "deny" into a "permit" on the return path, or capture a bearer permit and replay it. None of these is addressed by any property of the permit itself; all are addressed by securing the channel, which is why this requirement is normative rather than left to deployment. Because the permit is a bearer capability, an implementation SHOULD make it sender-constrained: bound to the authenticated identity or key of the PEP to which it was issued -- for example by the certificate-bound-token mechanism of [RFC8705] or the proof-of- possession mechanism of [RFC9449] -- so that a permit captured or leaked from one PEP cannot be used by another party. Sender- constraint reduces the protocol's reliance on channel confidentiality alone and is the recommended defence against permit theft; the action-bound signed permit of Section 1.2 is the stronger measure for deployments that must also survive a terminating intermediary. 12.2. HTTP/JSON Binding +================+==================================+ | Operation | Method and path | +================+==================================+ | decide | POST /v1/decide | +----------------+----------------------------------+ | report | POST /v1/report | +----------------+----------------------------------+ | list approvals | GET /v1/approvals | +----------------+----------------------------------+ | approve / deny | POST /v1/approvals/{id}/approve, | | | POST /v1/approvals/{id}/deny | Saha Expires 5 March 2027 [Page 19] Internet-Draft AADP September 2026 +----------------+----------------------------------+ | kill switch | POST /v1/killswitch | +----------------+----------------------------------+ | health | GET /v1/health | +----------------+----------------------------------+ Table 5: HTTP/JSON Operations The HTTP binding MUST run over a channel meeting Section 12.1. Caller authorization is bearer-token by default, with at minimum two roles: a decide role (decide, report) and an admin role (approve, deny, kill switch, policy reload). Separation of duties is a governance property and MUST NOT be collapsed into a single credential. Deployments MAY substitute identity-layer mechanisms such as those of [I-D.klrc-aiagent-auth], and SHOULD prefer sender- constrained credentials and permits (Section 12.1) over plain bearer tokens. HTTP status is 200 for any evaluated verdict, including "deny": a denial is a successful evaluation, not an error. 4xx and 5xx are reserved for protocol and infrastructure failures, which a PEP MUST treat under Section 11. 12.3. Local Socket Binding Implementations SHOULD offer a Unix domain socket binding carrying the same messages, for enforcement points on the same host. Peer credentials MAY be used in place of bearer tokens. 13. Conformance A conformant PDP returns a verdict for every request it accepts, including one it cannot parse (Section 5.1). It implements the messages of Section 5, the invariants of Section 9, the idempotency rules of Section 7, the approval semantics of Section 8, and the evidence requirements of Section 10. A conformant PEP never performs a governed action without a permit; sends exactly one report per permit; fails closed on unknown obligations; and has an explicitly configured unreachability behavior. A minimal PEP MAY implement only decide and report and refuse any verdict other than "permit" and "deny". It MUST then treat "propose" and "dry_run" as refusals to act and report "not_attempted". Saha Expires 5 March 2027 [Page 20] Internet-Draft AADP September 2026 14. Versioning The "protocol" field carries "aadp/MAJOR.MINOR". Minor versions add optional fields, reason codes, and obligation types; a recipient MUST ignore unknown fields. Unknown obligations and unknown verdicts are the exception: both MUST fail closed. Major versions may change required semantics. 15. IANA Considerations This document requests the creation of an "Agent Action Decision Protocol (AADP)" registry group with three registries, each operating under the Specification Required policy [RFC8126]. Names beginning with "x-" are reserved for vendor use and are not registered. Registration requests for all three registries use the same template: Name (the wire identifier), Description (one sentence), Change Controller, and Reference (the specification defining the semantics). For the Obligation Types registry, two further fields are required: Value Syntax, and Discharge Evidence (what a PEP MUST supply in a report to demonstrate the obligation was met). The designated expert should confirm that the semantics are implementable by a PEP without access to PDP-internal state, and that no existing entry already expresses them. 15.1. AADP Verdicts Registry Initial contents are the six verdicts defined in Section 3.2: "permit", "deny", "propose", "dry_run", "observe", and "replay". For each, the Reference is this document, the Change Controller is the IETF, and the Description is the corresponding "Meaning" cell of Table 2. A new verdict changes what a conformant PEP must do on receipt. The designated expert MUST NOT approve a registration whose PEP obligation is not stated, and SHOULD reject a verdict whose behavior an existing verdict plus a reason code already expresses. 15.2. AADP Reason Codes Registry Initial contents are the twelve reason codes defined in Section 3.3: "passed", "kill_switch", "default_deny", "bounds", "budget_exhausted", "rate_exhausted", "dry_run", "tier_confirm", "effect_floor", "no_compensating_command", "observe", and "malformed". For each, the Reference is this document, the Change Controller is the IETF, and the Description is the corresponding "Meaning" cell of Table 3. Saha Expires 5 March 2027 [Page 21] Internet-Draft AADP September 2026 Reason codes are the audit vocabulary: a registration SHOULD state which verdicts it may accompany. 15.3. AADP Obligation Types Registry Initial contents are the four obligation types defined in Section 6: "report_result", "undo_available_until", "execute_within", and "isolate". For each, the Reference is this document and the Change Controller is the IETF. Because an unrecognized obligation type causes a conformant PEP to decline the action (Section 6), registration in this registry is the only way an obligation becomes usable across independent implementations. The designated expert MUST verify that the Discharge Evidence field describes something a PEP can actually produce and a PDP can actually check. 16. Related Work The identity-layer, delegation, and connection-authorization work this document composes with is discussed in Section 1. Beyond it, adjacent work concentrates in two groups, and AADP's boundary against both is one sentence: AADP standardizes a decision and report lifecycle over mutable authorization state; it is not an evidence artifact format, a token format, or a workload identity system. Approval-evidence formats define verifiable artifacts recording that an authorization was granted -- signed receipts and capsules, and the countersigned transparency work of SCITT [RFC9943] for long-lived, cross-party verifiability of such artifacts. [I-D.schrock-ep-authorization-receipts] is the nearest of these, and its own survey of the surrounding landscape is more complete than would be useful to repeat here. These are complementary to this document by construction: an evidence artifact can prove that an approval happened; it cannot decide whether this action, with these argument values, may proceed now against a budget that has been draining all morning. The external authorization reference of Section 10 is the composition point this document offers such profiles: the layers compose by digest reference, and neither inherits the other's trust model. A worked composition profile against [I-D.schrock-ep-authorization-receipts], with a running implementation on the evidence side, exists outside this document. Transaction-scoped token work such as [I-D.ietf-oauth-transaction-tokens] narrows a credential to a single workflow invocation, carrying the context of one transaction across the services that serve it. It moves authorization closer to the action and remains an issuance-time construct: the verdict-relevant Saha Expires 5 March 2027 [Page 22] Internet-Draft AADP September 2026 state this document names -- cumulative budgets, live reservations, an approval lifecycle, a kill switch -- is read at decision time and changes between issuances, which is why AADP is a decision protocol rather than a token profile. The two compose as tokens and AADP compose in Section 1: the token establishes context and reach; the decision point answers whether this action proceeds now. 17. Security Considerations Parameters are untrusted input, commonly authored by a language model that may itself be under prompt-injection influence. PDPs MUST validate parameters against declared bounds and SHOULD reject unknown parameters rather than pass them through. The "rationale" field is model-authored text in the common case; it is evidence, never input to the decision. The same boundary governs evidence offered with a request. Evidence sufficiency -- what a policy demands before an action may proceed -- is policy, internal to the PDP. Where a deployment admits externally supplied evidence at all, the protocol admits authenticated evidence references -- opaque, digest-bound, profile-identified values that the PDP dereferences and verifies itself, under trust inputs the relying party selects -- and never evidence claims as decision input. A claim arriving in the request body shares the request's provenance and can only restate the requester's own assertion, exactly as "rationale" does; a reference names something the PDP can check without taking the requester's word for it, and what the policy then evaluates over is the outcome of that verification, never the reference's mere presence. The design rule is the one that already governs "source" and "rationale": the initiator must gain nothing by saying the right words. AADP mitigates a class of confused-deputy failures [SCOPEGATE] by evaluating argument values per call rather than gating tool exposure. It does not defend against a PEP that can act without consulting the PDP: a capability reachable outside the governed perimeter is outside this protocol's ability to detect. Deployments SHOULD verify that no unsupervised path to a governed capability exists. The boundary within which AADP's guarantees hold, and the compromised-PEP and terminating-intermediary cases they do not cover, are stated in Section 1.2. Saha Expires 5 March 2027 [Page 23] Internet-Draft AADP September 2026 The PDP-PEP channel is the protocol's principal network attack surface. An attacker able to read, alter, or inject on it can rewrite a request before evaluation, forge or flip a verdict, or replay a captured bearer permit; Section 12.1 makes confidentiality, integrity, mutual authentication, and (recommended) sender- constrained permits normative precisely to close this, and its requirements are load-bearing for every guarantee in this document. The interval between a permit and its execution is a time-of-check/ time-of-use window. The "execute_within" obligation bounds it; deployments with strict requirements SHOULD issue it. A revoked or expired permit discovered at execution time is reported "not_attempted". Budget state cannot drift within this window, because reservation is taken at decision time (Section 9), not at execution; and an approval cannot outlive a kill switch, because a resumed action is re-evaluated (Section 8). The residual window is the effect gap of Section 7, governed there. Reversibility, in this protocol, is an operational property, not a guarantee about the world. An action counts as reversible when a compensating path is registered and is itself governed (Section 9, invariant 3); it does not follow that the external effect can always be undone. A compensating transfer may arrive after a counterparty has moved the funds, a correcting message cannot unsend the first, and a rollback cannot recall data already read. Compensation is therefore best-effort recovery, and the "irreversible action is never executed autonomously" rule exists precisely because the alternative -- trusting that an undo will restore the prior state -- is not sound for consequential effects. Policy authors SHOULD NOT classify an action as reversible on the strength of a compensating command whose success depends on a party the deployment does not control. The approval queue is a denial-of-service surface: an agent that can flood proposals can bury a human approver. Rate caps on proposal- generating action types, and approval TTLs, bound the queue. Budget reservation is a second denial-of-service surface, and a quieter one. A caller that requests permits and never reports consumes the reserved budget without performing any action, so nothing appears at the sink and nothing fails; legitimate work is simply denied for the rest of the window. The explicit reclamation required in Section 4 bounds the exposure to the "execute_within" deadline, which is why that obligation is RECOMMENDED on every budgeted permit rather than reserved for time-critical actions. Saha Expires 5 March 2027 [Page 24] Internet-Draft AADP September 2026 The evidence record may contain sensitive parameter values. Implementations SHOULD support field-level redaction at write time and MUST NOT achieve redaction by mutating existing entries. Access to the evidence record SHOULD be governed no less strictly than the actions it records. Monetary values as decimal strings avoid floating-point rounding as an attack surface on budget arithmetic. 18. References 18.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017, . [RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, November 2022, . 18.2. Informative References [I-D.ietf-oauth-transaction-tokens] IETF OAuth Working Group, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction- tokens-11, July 2026, . Saha Expires 5 March 2027 [Page 25] Internet-Draft AADP September 2026 [I-D.klrc-aiagent-auth] IETF Individual Submission, "AI Agent Authentication and Authorization", Work in Progress, Internet-Draft, draft- klrc-aiagent-auth-03, 2026, . [I-D.liu-agent-operation-authorization] IETF Individual Submission, "Agent Operation Authorization", Work in Progress, Internet-Draft, draft- liu-agent-operation-authorization-02, March 2026, . [I-D.ni-wimse-ai-agent-identity] IETF Individual Submission, "WIMSE Applicability for AI Agents", Work in Progress, Internet-Draft, draft-ni-wimse- ai-agent-identity-02, February 2026, . [I-D.schrock-ep-authorization-receipts] Schrock, I., "Authorization Receipts for High-Risk Agent Actions", Work in Progress, Internet-Draft, draft-schrock- ep-authorization-receipts-12, August 2026, . [MCP] MCP Project, "Model Context Protocol Specification", 2026, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, February 2016, . [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, February 2020, . Saha Expires 5 March 2027 [Page 26] Internet-Draft AADP September 2026 [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, September 2023, . [RFC9943] IETF, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, June 2026, . [SCOPEGATE] Mellafe Zuvic, D., "Capability Gates Are Not Authorization: Confused-Deputy Failures in LLM Agent Frameworks", arXiv 2606.28679, June 2026, . [XACML] OASIS, "eXtensible Access Control Markup Language (XACML) Version 3.0", January 2013, . Appendix A. Worked Exchange (Tier 3) -> decide { request_id: A, action_type: "payments.transfer", cost_eur: "4000.00" } <- propose { reason: "effect_floor", nominal_tier: 2, effective_tier: 3, approval_id: "apr-77" } [ human approves apr-77 ] -> decide { request_id: B, ..., approval_ref: "apr-77" } <- permit { permit_id: "int-88220", obligations: [ {type:"report_result"}, {type:"execute_within", value:"2026-08-17T09:20:00Z"} ] } [ PEP performs the transfer ] -> report { permit_id: "int-88220", outcome: "success" } <- accepted { evidence_id: "aud-88221" } Appendix B. Implementation Status This section records the status of known implementations, per the practice described in [RFC7942]; it is to be removed before publication as an RFC. Saha Expires 5 March 2027 [Page 27] Internet-Draft AADP September 2026 onedoor (Apache-2.0, Python, version 0.6.1 on PyPI at the time of writing) is the reference implementation of the PDP, with a test suite covering the invariants of Section 9. Its decision service exposes the HTTP operations of Section 12.2. Five enforcement points have been written against it, at differing levels of maturity. Three are packaged with the implementation: an in-process library binding, a Model Context Protocol stdio proxy, and a LangChain agent middleware that governs every tool an agent holds through the framework's wrap_tool_call hook, verified by a test suite that runs a real agent loop including graph-interrupt approval and the asynchronous path. Two are experimental examples rather than supported adapters: a LiteLLM gateway guardrail and a LangGraph tool wrapper with interrupt-based approval flow. The LiteLLM example is known to deviate from Section 4 in that it reports on issue of the permit rather than after the act; it is therefore not conformant as written, and is included here as evidence that the gateway hook point is viable, not as a conformant PEP. onedoor records policy provenance as required by Section 10: the policy set is content-hashed, retained in an append-only table, and the hash is stamped on every evidence entry. This was added after the requirement was written. Its cost, from interleaved A/B runs on one host, is roughly 4 per cent of a decide-and-report cycle -- around 0.02 ms on a cycle of about 0.49 ms. Single-run figures at this scale are not distinguishable from run-to-run variation, which is itself of that order, so the figure is offered as an order of magnitude and not as a benchmark. Its evidence writes are split along the durability boundary this document draws: the intent row is always written synchronously before the permit is returned, while result rows may optionally be batched. Batching results costs nothing this document requires -- a lost result leaves an intent with no result, which is the recoverable state Section 9 already mandates -- and on one host it raised throughput from roughly 1,940 to 2,840 decide-and-report cycles per second, saturating at a batch of about 16. Exactly-once reporting is preserved by checking the pending batch as well as the record. onedoor now implements the explicit reservation reclamation required by Section 4. A permit that reserves budget records the exact counter deltas and a deadline; once the deadline passes with no report, the reserved budget is subtracted back out and a "reservation_expired" row is appended to the audit log, voiding the permit. Reclamation runs lazily on each decide (the open-reservation lookup is indexed and normally empty) and is also exposed as an explicit call for a maintenance loop. The reference implementation carries a test suite for it: an unreported permit holds its budget, Saha Expires 5 March 2027 [Page 28] Internet-Draft AADP September 2026 the reclaimer releases it as an audited event once the deadline passes, a reported permit is never reclaimed, and a double sweep cannot drive a counter negative. In an earlier revision of this document this requirement was listed as unimplemented; it is now satisfied. onedoor implements both resumption forms of Section 8. PDP-driven: its approve operation re-evaluates the recorded request under a fresh request identifier and returns a decide response. PEP-driven: a decide request may carry "approval_ref", exercised for single use, exactly one execution under simultaneous resumption, and kill-switch precedence over a valid reference. Its packaged HTTP decide operation does not yet expose the field, so the mechanism is exercised by the library binding and not by the packaged HTTP enforcement point. In an earlier revision PEP-driven resumption was recorded as unexercised by any implementation; the engine now exercises it, and the remaining gap belongs to the served surface, stated as such. onedoor emits the structured "budget" object of Section 3.3 on cap denials and persists it with the audit entry; its reason codes are unit-neutral, the currency carried in the object's "unit" field rather than in a code name. In an earlier revision this was recorded as unimplemented; it is now satisfied. Sender-constrained permits and the transport-security profile of Section 12.1 remain unconfigured by the packaged enforcement points. The implementation reserves a "sender_mismatch" reason code without emitting it, and a test holds it unemitted -- the vocabulary complete, the mechanism absent, the absence declared. The downstream idempotency-key propagation discussed in Section 7 is no longer recorded as an implementation gap but as a boundary: this revision states that the protocol propagates nothing downstream, so a derived provider key is an adapter concern at the adapter's own boundary, outside this register's scope. One divergence in the opposite direction is open at the time of writing: the reference implementation's numeric bounds refuse the decimal-string form inside "params" -- including the exact example of Section 5.1 -- while accepting it for "cost_eur". The failing direction is documented as a known limitation, and the correction (accepting decimal strings, evaluated exactly) is scheduled as the first change after the implementation's current release freeze, because it flips a refusal into a permission and therefore rides no hotfix. The clarifying sentence in Section 5 exists because of this divergence. Saha Expires 5 March 2027 [Page 29] Internet-Draft AADP September 2026 Independently of the reference implementation, a third-party interoperability fixture maps the decision-input provenance requirements of Section 10 onto CycloneDX 2.0 records, holding the tool digest, policy digest, verdict, and projection constant while varying only the provenance of one authorization-relevant field. It is, to the author's knowledge, the first independent use of this document as a test profile. The fixture, updated to state that this document, rather than -01, carries the per-field provenance requirement its case exercises, is published at https://github.com/Silentpartnercoding/agent-trust- benchmark/blob/82b497e0c642ab1460b2f904c08768e2f263a30f/docs/CDX- AADP-INPUT-PROVENANCE-001.md (immutable commit). Appendix C. Changes from draft-saha-aadp-01 This section is to be removed before publication as an RFC. * Stated that "permit_id" is the identity of the decision and report lifecycle and is not a provider idempotency key or a downstream credential; an adapter derives a downstream key at its own boundary, and the protocol propagates nothing (Section 7). * Distinguished evidence references from evidence claims: the PDP admits authenticated, digest-bound, profile-identified references it dereferences and verifies itself, and never claims as decision input (Section 17). * Extended the evidence requirements (Section 10): entries preserve the provenance of every authorization-relevant value; decisions turning on referenced evidence record a three-state per-reference verification outcome, the unmet condition as a structured identifier, and the instrument of verification; and the record's limit is stated -- it establishes what the PDP verified and evaluated at decision time, not the underlying truth. * Added an optional, profile-neutral external authorization reference to the evidence entry (Section 10), composing with external approval-evidence profiles by digest while keeping both layers' trust models independent. * Added a Related Work section (Section 16) drawing the boundary against approval-evidence formats and transaction-scoped tokens. * Made explicit that the decimal-string rule for monetary values applies inside "params", and that numeric bounds evaluated over such parameters accept the decimal-string form (Section 5) -- prompted by a reference implementation divergence recorded in Appendix B. Saha Expires 5 March 2027 [Page 30] Internet-Draft AADP September 2026 * Updated the Implementation Status section. Appendix D. Changes from draft-saha-aadp-00 This section is to be removed before publication as an RFC. * Added a Trust Model section (Section 1.2) stating the trusted PDP- PEP domain within which the protocol's guarantees hold, and naming the compromised-PEP, terminating-intermediary, and cross-boundary- permit cases as out of scope for this revision, with an action- bound signed permit identified as the planned extension for them. * Added a normative Transport Security section (Section 12.1): the PDP-PEP channel MUST provide confidentiality, integrity, and mutual authentication; permits and role credentials MUST NOT cross an unsecured channel; permits SHOULD be sender-constrained. This closes the man-in-the-middle exposure of the -00 bearer model. * Separated three "exactly once" properties in Section 7 (permit consumption, decision/report state, external effect), forbade blind re-execution of an uncertain-outcome action, and added downstream idempotency-key propagation as the mechanism for exactly-once effect. * Qualified the determinism invariant (Section 9) to hold over the full evaluation input -- policy, request, authorization state, and evaluation time -- rather than policy and request alone. * Generalized the currency-specific budget reason codes ("cap_eur_day", "cap_eur_month", "cap_daily_rate") to unit-neutral "budget_exhausted" and "rate_exhausted" with a structured "budget" detail object (Section 3.3), and updated the IANA registry contents accordingly. * Refined the "source" field (Section 5.1): a PDP MUST NOT treat it as an authenticated authority assertion; authorization-relevant provenance must be authenticated and carried as authorization context. * Required linearizable authorization state across PDP replicas (Section 2). * Foregrounded the stateful-authorization thesis in the abstract and added an explicit distinction from OAuth-style grant authorization (Section 1). Saha Expires 5 March 2027 [Page 31] Internet-Draft AADP September 2026 * Expanded Security Considerations: channel as principal attack surface, and reversibility as best-effort operational recovery rather than a guarantee about external state. Appendix E. Acknowledgments The PDP/PEP decomposition and the obligation concept derive from XACML. The capability-versus-authorization framing was independently articulated by David Mellafe Zuvic in the analysis cited as [SCOPEGATE], whose limitations section names stateful side channels as future work; this document treats that remainder as part of its scope. Mehmet Ayaz (Portotify) identified that -01 established evidence sufficiency as policy without specifying what the durable record must preserve when a decision turns on referenced evidence; the evidence requirements added in this revision, including the statement of the record's limit, follow from that exchange, and their closing formulation borrows his phrasing. Iman Schrock (EMILIA Protocol, Inc.) surfaced that -01 left the split between "permit_id" and provider idempotency keys implicit, and proposed the optional external authorization reference that Section 10 now carries. James Siyuan He contributed the independent CDX-AADP-INPUT- PROVENANCE-001 interoperability fixture and its technical review; the per-field provenance clause of Section 10 responds to his fixture's reading of the record requirements. Author's Address Shamik Saha Independent Amsterdam Netherlands Email: shamik.saha.rcciit@gmail.com Saha Expires 5 March 2027 [Page 32]