Network Working Group S. Saha Internet-Draft Independent Intended status: Standards Track 17 August 2026 Expires: 18 February 2027 The Agent Action Decision Protocol (AADP): Per-Action Authorization for AI Agents draft-saha-aadp-00 Abstract Existing agent-security work concentrates on identity: who an agent is, what credentials it holds, and which tools it may reach. This document addresses the complementary question: whether a specific proposed action, with specific argument values, may be performed now, and under what conditions. It defines the Agent Action Decision Protocol (AADP), a two-phase wire contract between a Policy Decision Point (PDP) that authorizes agent actions and the Policy Enforcement Points (PEPs) that perform them. AADP specifies verdicts with machine-readable reasons, obligations that fail closed, budget reservation semantics, approval and idempotency behavior, evidence requirements, and a set of evaluation invariants that 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." This Internet-Draft will expire on 18 February 2027. Saha Expires 18 February 2027 [Page 1] Internet-Draft AADP August 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Autonomy Tiers . . . . . . . . . . . . . . . . . . . . . 5 3.2. Verdicts . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Reason Codes . . . . . . . . . . . . . . . . . . . . . . 6 4. The Two-Phase Exchange . . . . . . . . . . . . . . . . . . . 7 5. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Decide Request . . . . . . . . . . . . . . . . . . . . . 8 5.2. Decide Response . . . . . . . . . . . . . . . . . . . . . 9 5.3. Report Request and Response . . . . . . . . . . . . . . . 10 6. Obligations . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Idempotency and Replay . . . . . . . . . . . . . . . . . . . 11 8. Approvals . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Evaluation Invariants . . . . . . . . . . . . . . . . . . . . 12 10. Evidence . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. Failure Semantics . . . . . . . . . . . . . . . . . . . . . . 14 12. Transport Bindings . . . . . . . . . . . . . . . . . . . . . 15 12.1. HTTP/JSON Binding . . . . . . . . . . . . . . . . . . . 15 12.2. Local Socket Binding . . . . . . . . . . . . . . . . . . 16 13. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 16 14. Versioning . . . . . . . . . . . . . . . . . . . . . . . . . 16 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 15.1. AADP Verdicts Registry . . . . . . . . . . . . . . . . . 17 15.2. AADP Reason Codes Registry . . . . . . . . . . . . . . . 17 15.3. AADP Obligation Types Registry . . . . . . . . . . . . . 17 16. Security Considerations . . . . . . . . . . . . . . . . . . . 18 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 17.1. Normative References . . . . . . . . . . . . . . . . . . 18 17.2. Informative References . . . . . . . . . . . . . . . . . 19 Saha Expires 18 February 2027 [Page 2] Internet-Draft AADP August 2026 Appendix A. Worked Exchange (Tier 3) . . . . . . . . . . . . . . 20 Appendix B. Implementation Status . . . . . . . . . . . . . . . 20 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 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 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 Saha Expires 18 February 2027 [Page 3] Internet-Draft AADP August 2026 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. 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 transport. Policy composition -- tiers, effect labels, budgets, parameter bounds -- is internal to the decision point. Only the verdict and its reason cross the wire. 1.2. 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. 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 Saha Expires 18 February 2027 [Page 4] Internet-Draft AADP August 2026 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. 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 | Saha Expires 18 February 2027 [Page 5] Internet-Draft AADP August 2026 +---------+----------------------------+---------------------------+ 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). +=========================+=======================================+ | 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 | +-------------------------+---------------------------------------+ | cap_daily_rate | a rate budget is exhausted | +-------------------------+---------------------------------------+ | cap_eur_day | a daily value budget is exhausted | +-------------------------+---------------------------------------+ | cap_eur_month | a monthly value budget is exhausted | +-------------------------+---------------------------------------+ | 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 18 February 2027 [Page 6] Internet-Draft AADP August 2026 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 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. Saha Expires 18 February 2027 [Page 7] Internet-Draft AADP August 2026 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" 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. A conformant PDP MUST NOT let it change the verdict: governance binds to the action, not to who proposed it. 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. A single reserved sentinel value denoting "no valid identifier was supplied" is not an invented identifier and MAY be used for this purpose. Saha Expires 18 February 2027 [Page 8] Internet-Draft AADP August 2026 The same totality applies to a quantity a check requires. A budget or cap that cannot be evaluated because the request resolves no amount where one is required -- absent, unparseable, or non-finite -- MUST deny with the reason of the check that required it, and MUST NOT proceed against an assumed zero. An amount the PDP cannot determine is not a zero amount; treating it as one silently disables the control. This requirement governs a request that reached the decision function: one the PDP received and attempted to evaluate. A "deny" verdict with reason "malformed" is an evaluation outcome, and is honored as any other verdict is, independent of the enforcement point's failure-mode configuration (Section 11). A request that fails before the decision function -- rejected by the transport or by intermediary infrastructure the PDP does not control, such as a body that is not well-formed for the binding in use -- is a protocol failure rather than a verdict; its transport- level treatment is described in Section 12.1, and it is subject to Section 11 with the constraint stated there. 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 { "protocol": "aadp/0.1", "request_id": "0a5f2c3e-1b7e-4f2a-9c1d-6b0f9e2a77c1", "verdict": "permit", "reason": "passed", "detail": "", "nominal_tier": 1, "effective_tier": 1, "permit_id": "pmt-h8Qk2mAoT7xY", "obligations": [ { "type": "report_result", "required": true }, { "type": "undo_available_until", "value": "2026-08-17T09:29:02Z" } ], "approval_id": null, "evidence_id": "aud-88213" } Saha Expires 18 February 2027 [Page 9] Internet-Draft AADP August 2026 "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. Where no policy resolved -- a request denied with reason "malformed", or an unknown action denied with reason "default_deny" -- no policy assigned a tier. The tier fields MUST then carry the most restrictive tier ("confirm"), and the reason code, not the tier, is authoritative for such a verdict. A recipient MUST NOT infer that an action was contemplated from a tier that no policy assigned. 5.3. Report Request and Response { "protocol": "aadp/0.1", "permit_id": "pmt-h8Qk2mAoT7xY", "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 18 February 2027 [Page 10] Internet-Draft AADP August 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 and Replay "request_id" is the idempotency key. 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" and an "approval_id" are capability identifiers: possession of one is sufficient to report an outcome for a permit, or to resume an approved action. They MUST therefore be unpredictable -- infeasible to guess from other issued identifiers -- so that a party holding only a decide credential cannot forge a result, or a resumption, for an exchange it did not conduct. A sequential or Saha Expires 18 February 2027 [Page 11] Internet-Draft AADP August 2026 otherwise enumerable identifier does not satisfy this requirement. Single-use bounds replay of a known identifier; unpredictability bounds forging of an unknown one. Where a deployment cannot guarantee unpredictable identifiers, the report and resume channels MUST instead bind each identifier to the authenticated identity that received it, and reject any report or resumption presented under a different identity. 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. 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. Two conformant PDPs with the same policy MUST reach the same verdict for the same request. Implementations MAY optimize freely -- caching, compiling, reordering pure checks -- provided these observable orderings hold. Saha Expires 18 February 2027 [Page 12] Internet-Draft AADP August 2026 1. The kill switch is evaluated first, before policy lookup. An engaged kill switch MUST NOT be overridable by a policy entry. 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. The durability an intent must have before its permit is returned (invariant 9) means, at minimum, survival of the failure of the PDP process: a permit that was returned MUST be recoverable after the deciding process restarts. Whether the record also survives the Saha Expires 18 February 2027 [Page 13] Internet-Draft AADP August 2026 failure of the host -- power loss, operating-system crash -- is a deployment property a PDP MUST document, since it determines whether an intent can be lost in a window the enforcement point cannot observe. Returning a permit whose intent is not durable to the documented level is non-conformant. 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. 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. Saha Expires 18 February 2027 [Page 14] Internet-Draft AADP August 2026 These modes govern a PDP that could not be reached. A failure that indicates the request itself was not well-formed -- a transport or parse failure of the kind described in Section 5.1 and Section 12.1 -- MUST be treated as fail_closed regardless of the configured mode: such a request MUST NOT be performed under fail_open or fail_static. A malformed request must not become a permitted action by way of a failure policy, just as it must not by way of the decision function. 12. Transport Bindings The core protocol is transport-agnostic. Two bindings are defined. 12.1. 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 | +----------------+----------------------------------+ | kill switch | POST /v1/killswitch | +----------------+----------------------------------+ | health | GET /v1/health | +----------------+----------------------------------+ Table 5: HTTP/JSON Operations Authentication 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]. HTTP status is 200 for any evaluated verdict, including "deny", and including a "deny" with reason "malformed" that the PDP produced from a request it received and evaluated (Section 5.1): a denial is a successful evaluation, not an error, and the verdict is carried in the response body. 4xx and 5xx are reserved for requests that failed before evaluation -- a body that did not parse for this binding, an unsupported content type, a rejected credential -- and for infrastructure failures. A PEP MUST treat a 4xx or 5xx under Saha Expires 18 February 2027 [Page 15] Internet-Draft AADP August 2026 Section 11, under which a failure denoting a malformed request is not eligible for fail_open. A PDP that has begun evaluating a request MUST NOT report the outcome as a bare 4xx or 5xx with no verdict body; the distinction is whether the decision function was reached. 12.2. 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". 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 Saha Expires 18 February 2027 [Page 16] Internet-Draft AADP August 2026 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 thirteen reason codes defined in Section 3.3: "passed", "kill_switch", "default_deny", "bounds", "cap_daily_rate", "cap_eur_day", "cap_eur_month", "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. 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. Saha Expires 18 February 2027 [Page 17] Internet-Draft AADP August 2026 16. 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. 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 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". 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. 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. 17. References 17.1. Normative References Saha Expires 18 February 2027 [Page 18] Internet-Draft AADP August 2026 [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, . 17.2. Informative References [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, . [MCP] MCP Project, "Model Context Protocol Specification", 2026, . Saha Expires 18 February 2027 [Page 19] Internet-Draft AADP August 2026 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, February 2016, . [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-9Xt4Bs7Q" } [ human approves apr-77 ] -> decide { request_id: B, ..., approval_ref: "apr-9Xt4Bs7Q" } <- permit { permit_id: "pmt-Rc8Hn2Vw5Lp3", obligations: [ {type:"report_result"}, {type:"execute_within", value:"2026-08-17T09:20:00Z"} ] } [ PEP performs the transfer ] -> report { permit_id: "pmt-Rc8Hn2Vw5Lp3", 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. onedoor (Apache-2.0, Python, version 0.3.4 on PyPI at the time of writing) is the reference implementation of the PDP, with a test suite covering the invariants of Section 9 and running on Linux and Windows. Its decision service exposes the HTTP operations of Section 12.1. Saha Expires 18 February 2027 [Page 20] Internet-Draft AADP August 2026 Four enforcement points have been written against it, at differing levels of maturity. Two are packaged with the implementation: an in- process library binding, and a Model Context Protocol stdio proxy. 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 does not yet implement the explicit reservation reclamation required by Section 4: a permit that is never reported holds its budget until the accounting window rolls over. The requirement was added after probing the implementation, and the implementation has not caught up. Two further requirements of this revision are not yet met by the reference implementation, and are recorded here rather than hidden. Its permit identifiers are sequential rather than unpredictable (Section 7); a deployment relying on it therefore requires the identity-binding alternative that section permits. Its evidence is durable to process-crash but not to host-failure level (Section 10), which it documents rather than strengthens. A conformant unpredictable-identifier scheme and a host-durable evidence mode are planned but unshipped. Saha Expires 18 February 2027 [Page 21] Internet-Draft AADP August 2026 onedoor implements PDP-driven resumption (Section 8): its approve operation re-evaluates the recorded request under a fresh request identifier and returns a decide response. It does not currently accept "approval_ref" on a decide request; PEP-driven resumption is therefore specified but not yet exercised by an implementation. Appendix C. 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. Author's Address Shamik Saha Independent Amsterdam Netherlands Email: shamik.saha.rcciit@gmail.com Saha Expires 18 February 2027 [Page 22]