The Agent Action Decision Protocol (AADP): Per-Action Authorization for AI Agents
draft-saha-aadp-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Shamik Saha | ||
| Last updated | 2026-09-23 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-saha-aadp-03
Network Working Group S. Saha
Internet-Draft Independent
Intended status: Standards Track 23 September 2026
Expires: 27 March 2027
The Agent Action Decision Protocol (AADP): Per-Action Authorization for
AI Agents
draft-saha-aadp-03
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 27 March 2027 [Page 1]
Internet-Draft AADP September 2026
This Internet-Draft will expire on 27 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6
2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Autonomy Tiers . . . . . . . . . . . . . . . . . . . . . 6
3.2. Verdicts . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Reason Codes . . . . . . . . . . . . . . . . . . . . . . 8
4. The Two-Phase Exchange . . . . . . . . . . . . . . . . . . . 10
4.1. Resolving a Reservation . . . . . . . . . . . . . . . . . 11
5. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Decide Request . . . . . . . . . . . . . . . . . . . . . 12
5.2. Decide Response . . . . . . . . . . . . . . . . . . . . . 14
5.3. Report Request and Response . . . . . . . . . . . . . . . 14
6. Obligations . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Idempotency, Replay, and Exactly-Once Semantics . . . . . . . 16
8. Approvals . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Deferral at a Mandate Layer . . . . . . . . . . . . . . . 18
9. Evaluation Invariants . . . . . . . . . . . . . . . . . . . . 20
10. Evidence . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11. Failure Semantics . . . . . . . . . . . . . . . . . . . . . . 24
12. Transport Bindings . . . . . . . . . . . . . . . . . . . . . 24
12.1. Transport Security . . . . . . . . . . . . . . . . . . . 25
12.2. HTTP/JSON Binding . . . . . . . . . . . . . . . . . . . 25
12.3. Local Socket Binding . . . . . . . . . . . . . . . . . . 26
13. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 26
14. Versioning . . . . . . . . . . . . . . . . . . . . . . . . . 27
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
15.1. AADP Verdicts Registry . . . . . . . . . . . . . . . . . 27
Saha Expires 27 March 2027 [Page 2]
Internet-Draft AADP September 2026
15.2. AADP Reason Codes Registry . . . . . . . . . . . . . . . 28
15.3. AADP Obligation Types Registry . . . . . . . . . . . . . 28
16. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 28
17. Security Considerations . . . . . . . . . . . . . . . . . . . 30
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
18.1. Normative References . . . . . . . . . . . . . . . . . . 32
18.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Worked Exchange (Tier 3) . . . . . . . . . . . . . . 35
Appendix B. Implementation Status . . . . . . . . . . . . . . . 36
Appendix C. Changes from draft-saha-aadp-02 . . . . . . . . . . 38
Appendix D. Changes from draft-saha-aadp-01 . . . . . . . . . . 39
Appendix E. Changes from draft-saha-aadp-00 . . . . . . . . . . 40
Appendix F. Acknowledgments . . . . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42
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
Saha Expires 27 March 2027 [Page 3]
Internet-Draft AADP September 2026
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.
Two earlier pieces of work address per-action authorization at the
same layer as this document, and both predate its first revision.
The Open Agent Passport [OAP] names the pre-action authorization
problem: it intercepts a tool call synchronously before execution,
evaluates it against declarative policy, and produces a signed audit
record, and it reports measured decision latency and results from a
live adversarial testbed. The Agent Control Protocol [ACP] performs
admission control over agent actions with history-aware risk scoring,
and so already treats an authorization decision as a function of
state accumulated across requests. AADP differs from both in what it
standardizes rather than in the question it asks: a two-phase
exchange in which a report resolves every permit; budget reservation
that is atomic across differently-named actions and is committed or
released by that report; an approval lifecycle with expiry and re-
evaluation; obligations that fail closed; and an evidence record from
which a party holding the record and the retained policy can re-
derive each verdict.
A mandate layer such as [I-D.kroehl-agentic-trust-aae] establishes
under what grant an agent acts; this document answers whether this
action, with these values, proceeds now. The two meet at a deferred
decision (Section 8.1) and at the evidence record (Section 10), and
their relationship is drawn in Section 16.
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
Saha Expires 27 March 2027 [Page 4]
Internet-Draft AADP September 2026
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.
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
Saha Expires 27 March 2027 [Page 5]
Internet-Draft AADP September 2026
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
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.
Saha Expires 27 March 2027 [Page 6]
Internet-Draft AADP September 2026
+======+=============+===============================+
| 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 |
+---------+----------------------------+---------------------------+
Table 2: Verdicts and PEP Obligations
Saha Expires 27 March 2027 [Page 7]
Internet-Draft AADP September 2026
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 27 March 2027 [Page 8]
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 |
+-------------------------+--------------------------------------+
| external_authorization | an external authorization layer |
| | consumed as context denied the |
| | action, or deferred it to a decision |
| | by its own authority (Section 8.1) |
+-------------------------+--------------------------------------+
Table 3: Reason Codes
Saha Expires 27 March 2027 [Page 9]
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 27 March 2027 [Page 10]
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.
4.1. Resolving a Reservation
A report resolves the permit's budget reservation as well as the
permit. A budget is a ceiling on effect, so the rule is that a
reservation is released only when the action is known to have had no
effect, and is otherwise committed. On accepting a report, the PDP
MUST resolve the reservation as follows, and MUST record the
resolution in the same evidence entry that records the report:
+===================+=============+===========================+
| Outcome | Reservation | Why |
+===================+=============+===========================+
| success | committed | the action took effect |
+-------------------+-------------+---------------------------+
| not_attempted | released | the PEP did not act |
+-------------------+-------------+---------------------------+
| failure, with | released | the PEP established that |
| "no_effect": true | | the action took no effect |
+-------------------+-------------+---------------------------+
| failure, | committed | a failed action may still |
| otherwise | | have had partial effect |
+-------------------+-------------+---------------------------+
| timeout | committed | the effect is unknown |
| | | (Section 7) |
+-------------------+-------------+---------------------------+
Table 4: Reservation Resolution by Outcome
"no_effect" is an optional member of a "failure" report
(Section 5.3). A PEP MUST NOT set it unless it can positively
establish that the action took no effect at the target -- for
example, because the target refused the request before acting and
said so -- which is the same standard Section 7 sets for re-issuing
an action. A PDP MUST ignore "no_effect" on any other outcome.
Saha Expires 27 March 2027 [Page 11]
Internet-Draft AADP September 2026
A release returns exactly the amounts reserved for that permit to the
budgets they were reserved from. It is recorded, not silent; it is
idempotent, so that a report accepted once and an expiry sweep
running concurrently cannot release the same reservation twice; and
it MUST NOT drive a counter below the value it would have held had
the permit never been issued. Committing on uncertainty can only
make a budget stricter than the effects warrant; releasing on
uncertainty can let a budget be exceeded, which is the failure
budgets exist to prevent. Where a committed reservation is later
shown to have had no effect -- by reconciliation with the target, or
by an operator -- the PDP MAY release it by appending a correction
entry that references the report it corrects and the evidence
establishing that no effect occurred; it MUST NOT amend the report's
entry in place (Section 10).
A rate budget (events per window) bounds how often permits are issued
rather than how much effect they produce, and is not released by any
outcome: releasing it would let a caller cycle decide and
"not_attempted" without bound. The expiry release of Section 4 is
unchanged by this rule: it applies to a permit that received no
report at all.
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
Saha Expires 27 March 2027 [Page 12]
Internet-Draft AADP September 2026
{
"protocol": "aadp/0.2",
"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 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
Saha Expires 27 March 2027 [Page 13]
Internet-Draft AADP September 2026
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
{
"protocol": "aadp/0.2",
"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.2",
"permit_id": "int-88213",
"outcome": "success",
"payload": { "confirmation": "TX-77120" },
"error": null,
"completed_at": "2026-08-17T09:14:03Z"
}
Saha Expires 27 March 2027 [Page 14]
Internet-Draft AADP September 2026
"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). A "failure" report MAY carry "no_effect": true, under
the conditions of Section 4.1, which also states how each outcome
resolves the permit's budget reservation.
{ "protocol": "aadp/0.2", "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.
+======================+=====================================+
| 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 |
+----------------------+-------------------------------------+
| present_bound | the permit may be exercised only by |
| | presenting it, as an action-bound |
| | permit, to the named audience |
+----------------------+-------------------------------------+
Table 5: Obligation Types
"present_bound" is the hook for the action-bound permit that
Section 1.2 identifies as a planned extension. Its value is the
audience, an absolute URI naming the recipient that will perform the
action. It tells the PEP that this permit MUST NOT be exercised by
the PEP acting itself, and may be exercised only by presenting the
permit, in the action-bound form specified by a companion document,
to that audience. Its purpose in this revision is to make the
boundary visible before the form exists: a PEP that does not
Saha Expires 27 March 2027 [Page 15]
Internet-Draft AADP September 2026
implement action-bound presentation does not recognize the type, and
the fail-closed rule below makes it refuse and report "not_attempted"
rather than act on a permit that was issued to be carried elsewhere.
Its discharge evidence is the recipient's confirmation of the
presented permit, by digest, or the recipient's refusal reason.
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.
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
Saha Expires 27 March 2027 [Page 16]
Internet-Draft AADP September 2026
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.
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.
Saha Expires 27 March 2027 [Page 17]
Internet-Draft AADP September 2026
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.
8.1. Deferral at a Mandate Layer
A mandate layer can also defer an action to a later authority. In
[I-D.kroehl-agentic-trust-aae], a grant whose disposition is hold
yields the verdict PENDING, and a later ratification record, issued
by an authority that derives from the mandate -- its issuing
principal or a role it names, where a role is a label and not a
permission, from whose value a relying party derives no capability
(AAE Section 6.4) -- approves or disapproves the deferred action,
which is the one transaction the prior record names (AAE
Section 6.3). Where a PDP consumes such a verdict as authorization
context (Section 17), the two deferrals are distinct: they are
decided by different authorities, over different objects -- the
mandate layer over an action type and its grant, AADP over this
action instance and the authorization state -- and neither
substitutes for the other. The correspondence is as follows.
Saha Expires 27 March 2027 [Page 18]
Internet-Draft AADP September 2026
+======================+========================================+
| Mandate layer | AADP |
+======================+========================================+
| DENY | "deny" with reason |
| | "external_authorization" |
+----------------------+----------------------------------------+
| PENDING | "propose" with reason |
| | "external_authorization"; an approval |
| | record is created as for any "propose" |
+----------------------+----------------------------------------+
| ratification, | the approval transitions to approved; |
| approved | the resumed request is re-evaluated in |
| | full |
+----------------------+----------------------------------------+
| ratification, | the approval transitions to denied |
| disapproved | |
+----------------------+----------------------------------------+
| DENY, later ratified | no counterpart: an AADP "deny" is not |
| as approved (an | subject to approval |
| override) | |
+----------------------+----------------------------------------+
Table 6: Mandate-Layer Deferral and AADP
A PDP that consumes a mandate-layer verdict MUST NOT return "permit"
while that verdict denies or defers the action. Where it denies, the
PDP returns "deny" with reason "external_authorization". Where it
defers, the PDP returns "propose" with that reason, unless another
check denies the action, in which case the denial governs: on the
principle of invariant 4 (Section 9), no authority is asked to decide
an action the policy already refuses, and a mandate authority is no
exception.
An approval that waits on a mandate-layer deferral is resolved, as to
that deferral, by the mandate authority's ratification and by nothing
else; an approver of the AADP deployment cannot resolve it on the
mandate authority's behalf. The PDP treats a ratification record as
a referenced artifact (Section 17): it transitions the approval to
approved only when the ratification is verified, names the deferred
action, and approves it; to denied when it is verified and
disapproves; and it leaves the approval pending when the record
cannot be dereferenced, since an unreachable verifier is an
availability fact and not a decision. The approval's deadline
applies whether or not the mandate layer bounds its own deferral.
All of the rules above hold unchanged: resumption re-evaluates, a
kill switch engaged in the interval still denies, and the approval is
single-use. The evidence entry that records the transition carries
the ratification as an external authorization reference (Section 10).
Saha Expires 27 March 2027 [Page 19]
Internet-Draft AADP September 2026
A mandate layer may allow its authority to approve an action its own
evaluation denied. AADP has no counterpart and gives that override
no effect on a recorded AADP verdict: an AADP "deny" is final for its
request, and a denied request has no approval to resume. A verified
override is, like any verified artifact, authorization context that
the policy MAY evaluate on a later request; whether it can change
that request's verdict is policy, internal to the PDP, and is
recorded as such.
Where a mandate-layer deferral and an AADP escalation (for example,
"tier_confirm") apply to the same request, the verdict is one
"propose" carrying the escalating AADP check as its reason, and one
approval record that waits on both authorities: it is approved only
when each has approved, and denied when either has refused.
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.
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.
Saha Expires 27 March 2027 [Page 20]
Internet-Draft AADP September 2026
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 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.
Saha Expires 27 March 2027 [Page 21]
Internet-Draft AADP September 2026
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.
Every entry that records a verdict MUST carry an evaluation trace: an
ordered array with one element per check the PDP evaluated for that
request, in the order it evaluated them. A reason code names one
cause; the trace names every check, so that a denial or an escalation
identifies the condition that produced it whether or not the decision
turned on referenced evidence, and so that a verdict with several
unmet conditions does not read as though it had one. Each element
carries:
"check": the check evaluated, named from the reason-code vocabulary
of Section 3.3 ("kill_switch", "bounds", "budget_exhausted",
"external_authorization", and so on), or a vendor-prefixed name;
"rule": the identifier of the policy rule the check applied, where
it applied one;
"condition": the identifier of the condition within that rule;
Saha Expires 27 March 2027 [Page 22]
Internet-Draft AADP September 2026
"value" and "bound": the value the check read and the bound it
compared it with, where the check compares; for a stateful check,
"value" is the authorization state the check read -- for a budget,
the amount remaining before this request's reservation -- which is
how the entry captures the state that re-derivation requires
(Section 9);
"result": "pass", "fail", or "unresolved"; "unresolved" is used only
for a check over a referenced artifact that could not be
dereferenced, and keeps that state apart from failure exactly as
the three verification states above do.
"evaluation_trace": [
{ "check": "kill_switch", "result": "pass" },
{ "check": "default_deny", "rule": "payments.transfer",
"result": "pass" },
{ "check": "bounds", "rule": "payments.transfer",
"condition": "amount_eur.max", "value": "40.00",
"bound": "500.00", "result": "pass" },
{ "check": "budget_exhausted", "rule": "payments.daily",
"value": "9980.00", "bound": "40.00", "result": "pass" }
]
A check the PDP did not evaluate -- because an earlier check already
decided the verdict -- MUST NOT appear in the trace, and in
particular MUST NOT appear as "pass". The verdict's reason MUST be
"passed" when every element passed, and otherwise MUST name the check
of an element whose result is "fail" or "unresolved". A check fails
when it prevents an autonomous permit, whether by denying, by
escalating, or by redirecting the action as "dry_run" and "observe"
do; a verifier can therefore check an entry's reason against its own
trace without the policy. The trace is evidence of the evaluation
that was performed, and the invariants' permission to reorder pure
checks is unchanged: two conformant PDPs may record the same checks
in different orders. Trace values are parameter values and state,
and fall under the redaction rule of Section 17; a redacted value is
marked as redacted, never removed with its element, so that the trace
still shows that the check was made. A bare digest is not a
redaction of a low-entropy value such as an amount. The construction
follows the predicate trace of [I-D.kroehl-agentic-trust-aae] (its
Section 2.5.2), which records a recomputable evaluation (its
Section 2.5.3); here each element additionally records the
authorization state a stateful check read.
Saha Expires 27 March 2027 [Page 23]
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 27 March 2027 [Page 24]
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 27 March 2027 [Page 25]
Internet-Draft AADP September 2026
+----------------+----------------------------------+
| kill switch | POST /v1/killswitch |
+----------------+----------------------------------+
| health | GET /v1/health |
+----------------+----------------------------------+
Table 7: 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, the
reservation resolution of Section 4.1, and the evidence requirements
of Section 10, including the evaluation trace. A PDP that consumes
mandate-layer verdicts also implements Section 8.1.
A conformant PEP never performs a governed action without a permit;
sends exactly one report per permit; asserts "no_effect" only when it
can establish it; 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 27 March 2027 [Page 26]
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.
Messages conforming to this document carry "aadp/0.2". The
identifier "aadp/0.1" names the vocabulary of draft-saha-aadp-00 and
draft-saha-aadp-01, whose currency-specific budget reason codes
draft-saha-aadp-02 replaced with the unit-neutral codes of
Section 3.3. Because that replacement removed codes rather than
adding them, it is not a minor change within 0.1. A recipient that
receives "aadp/0.1" MUST NOT assume the reason codes of Section 3.3.
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.
Saha Expires 27 March 2027 [Page 27]
Internet-Draft AADP September 2026
15.2. AADP Reason Codes Registry
Initial contents are the thirteen 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", "malformed",
and "external_authorization". 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 five obligation types defined in Section 6:
"report_result", "undo_available_until", "execute_within", "isolate",
and "present_bound". For each, the Reference is this document and
the Change Controller is the IETF. For "present_bound", the Value
Syntax is an absolute URI naming the audience, and the Discharge
Evidence is the digest of the recipient's confirmation of the
presented permit, or the recipient's refusal reason.
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 four groups, and AADP's boundary
against all of them is one sentence: AADP standardizes a decision and
report lifecycle over mutable authorization state; it is not an
evidence artifact format, a mandate or credential format, a token
format, a hook interface, 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
Saha Expires 27 March 2027 [Page 28]
Internet-Draft AADP September 2026
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.
The Agent Authorization Envelope (AAE) [I-D.kroehl-agentic-trust-aae]
defines a signed mandate -- MANDATE, CONSTRAINTS and VALIDITY carried
as a verifiable credential -- under which an agent may act, with
delegation by strict subordination, an audience challenge, single-use
presentation, and revocation checking that fails closed. AAE and
this document meet at three places, and at each the boundary is drawn
by AAE's own text. First, an AAE grant binds an action type (AAE
Section 2.2.2): the values that separate one instance from another --
amounts, recipients, sequence numbers -- are kept out of the grant
and travel beside it. A binding to an action instance is outside
AAE's specification, which neither defines nor forbids it; the per-
action decision this document specifies is that construction, and a
signed, action-bound permit (Section 1.2) is its portable form.
Second, an AAE constraint bounds each transfer, never their sum (AAE
Section 7.1); the state that accumulates across actions -- budgets,
reservations, an approval lifecycle -- is the remainder AADP decides
over, and the two layers join there directly. Third, both record one
decision from different sides: AAE ratification records reference the
prior verdict record they ratify by its core digest (AAE
Section 6.2), a caller-held chain the specification does not require
to be stored or anchored; the evidence entry of Section 10 is re-
derivable by policy content digest, with three-state reference
verification. The external authorization reference of Section 10 is
the join offered here: an entry MAY reference the AAE ratification
record it consumed by digest, with its verification outcome in three
states, and an AAE record MAY in turn cite the entry's digest, so
that each record names the other without either format inheriting the
other's trust model. AAE posted before this document and is the
mandate and credential layer the per-action decision specified here
consumes.
Two further pieces of work sit beside AADP rather than beneath or
above it. The OWASP Agent Control Standard [ACS] specifies how agent
platforms expose declarative hooks through which runtime policy is
enforced and observed, portably across agent frameworks. A hook is a
natural home for an AADP enforcement point: ACS says where in a
framework a governed action can be intercepted; AADP says what the
decision point is asked there, what it may answer, and what record
the answer leaves. The OpenID Authorization API [AUTHZEN]
Saha Expires 27 March 2027 [Page 29]
Internet-Draft AADP September 2026
standardizes the exchange between an enforcement point and a decision
point in general form -- a subject, an action, a resource and a
context, answered with a boolean decision and optional context -- and
is the nearest standardized counterpart to AADP's decide call. The
two compose: AADP specifies, for agent actions, what a boolean
decision does not carry -- a third outcome that defers to an
authority, obligations that fail closed, budget reservation taken at
decision time, and the report that resolves every permit. A
deployment that carries AADP decisions over the Authorization API
MUST NOT render "propose" or "dry_run" as a positive decision, and
MUST carry "permit_id" and the obligations in the decision's context
whenever it renders "permit", since without them the report of
Section 4 cannot be sent.
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
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.
Saha Expires 27 March 2027 [Page 30]
Internet-Draft AADP September 2026
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.
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
Saha Expires 27 March 2027 [Page 31]
Internet-Draft AADP September 2026
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.
The "no_effect" member of a failure report releases budget on the
PEP's word (Section 4.1). Within the trust model of Section 1.2 the
PEP is trusted to report what happened, as it is trusted to perform
the action it was permitted; a PEP that asserts "no_effect" falsely
can spend beyond a budget, as a PEP that acts without a permit can.
The rule that uncertainty commits the reservation limits what an
honest PEP's error can cost: only a positive assertion releases
budget, and the evidence entry records who made it.
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,
<https://www.rfc-editor.org/info/rfc2119>.
Saha Expires 27 March 2027 [Page 32]
Internet-Draft AADP September 2026
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[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,
<https://www.rfc-editor.org/info/rfc9325>.
18.2. Informative References
[ACP] Fernandez, M., "Agent Control Protocol: Admission Control
for Agent Actions", arXiv 2603.18829, March 2026,
<https://arxiv.org/abs/2603.18829>.
[ACS] OWASP GenAI Security Project, "Agent Control Standard
(ACS)", Version 0.1, Public Preview, September 2026,
<https://github.com/GenAI-Security-Project/agent-control-
standard>.
[AUTHZEN] Gazitt, O., Ed., Brossard, D., Ed., and A. Tulshibagwale,
Ed., "Authorization API 1.0", OpenID Foundation Final
Specification, January 2026,
<https://openid.net/specs/authorization-api-1_0.html>.
[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, <https://datatracker.ietf.org/doc/
draft-ietf-oauth-transaction-tokens/>.
[I-D.klrc-aiagent-auth]
IETF Individual Submission, "AI Agent Authentication and
Authorization", Work in Progress, Internet-Draft, draft-
Saha Expires 27 March 2027 [Page 33]
Internet-Draft AADP September 2026
klrc-aiagent-auth-03, 2026,
<https://datatracker.ietf.org/doc/draft-klrc-aiagent-
auth/>.
[I-D.kroehl-agentic-trust-aae]
Kroehl, L. K., "Agent Authorization Envelope (AAE): A
Machine-Evaluable Authorization Structure for Autonomous
AI Agents", Work in Progress, Internet-Draft, draft-
kroehl-agentic-trust-aae-02, 6 September 2026,
<https://datatracker.ietf.org/doc/draft-kroehl-agentic-
trust-aae/>.
[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,
<https://datatracker.ietf.org/doc/draft-liu-agent-
operation-authorization/>.
[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,
<https://datatracker.ietf.org/doc/draft-ni-wimse-ai-agent-
identity/>.
[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,
<https://datatracker.ietf.org/doc/draft-schrock-ep-
authorization-receipts/>.
[MCP] MCP Project, "Model Context Protocol Specification", 2026,
<https://modelcontextprotocol.io/specification>.
[OAP] Uchibeke, U., "Before the Tool Call: Deterministic Pre-
Action Authorization for Autonomous AI Agents",
arXiv 2603.20953, March 2026,
<https://arxiv.org/abs/2603.20953>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
Saha Expires 27 March 2027 [Page 34]
Internet-Draft AADP September 2026
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, February 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[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, <https://www.rfc-editor.org/info/rfc8705>.
[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,
<https://www.rfc-editor.org/info/rfc9449>.
[RFC9943] IETF, "An Architecture for Trustworthy and Transparent
Digital Supply Chains", RFC 9943, June 2026,
<https://www.rfc-editor.org/info/rfc9943>.
[SCOPEGATE]
Mellafe Zuvic, D., "Capability Gates Are Not
Authorization: Confused-Deputy Failures in LLM Agent
Frameworks", arXiv 2606.28679, June 2026,
<https://arxiv.org/abs/2606.28679>.
[XACML] OASIS, "eXtensible Access Control Markup Language (XACML)
Version 3.0", January 2013, <https://docs.oasis-
open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html>.
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" }
Saha Expires 27 March 2027 [Page 35]
Internet-Draft AADP September 2026
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.7.0 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
Saha Expires 27 March 2027 [Page 36]
Internet-Draft AADP September 2026
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,
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 a structured budget object on cap denials and persists
it with the audit entry, and its reason codes are unit-neutral, but
it does so under its own names rather than those of Section 3.3: its
codes are "cap_value" and "cap_rate" where this document registers
"budget_exhausted" and "rate_exhausted", and its object carries the
unit in a "unit" field and the kind of budget ("value" or "rate") in
"dimension", where this document carries the unit in "dimension". An
earlier revision recorded this requirement as satisfied; the
mechanism is present, but the vocabulary does not yet match this
document, and aligning it is owed by the implementation.
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.
Saha Expires 27 March 2027 [Page 37]
Internet-Draft AADP September 2026
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. It remains open in version 0.7.0.
Reservation resolution by outcome (Section 4.1) is largely
implemented already: onedoor settles the reservation on "success",
"failure" and "timeout" and releases it on "not_attempted" as an
audited event, a rule it adopted before this document stated it.
What it lacks is the "no_effect" member, so it never releases on
"failure".
The other requirements added in this revision are not yet implemented
by the reference implementation, and are listed here so that the
absence is declared rather than discovered: the evaluation trace
(Section 10); the "external_authorization" reason and the mandate-
layer deferral of Section 8.1; and the "present_bound" obligation,
which the implementation, like any PEP that does not know it, refuses
as unknown.
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-02
This section is to be removed before publication as an RFC.
* Stated how a report resolves a budget reservation (Section 4.1):
committed on "success", "timeout", and a "failure" that may have
had effect; released, as a recorded and idempotent event, on
"not_attempted" and on a "failure" whose PEP establishes
"no_effect"; rate budgets never released; later release only by an
Saha Expires 27 March 2027 [Page 38]
Internet-Draft AADP September 2026
appended correction. -02 committed on report and released on
expiry but did not say what a failed or unattempted permit did to
its reservation.
* Added the optional "no_effect" member to the failure report
(Section 5.3).
* Required an evaluation trace on every verdict entry (Section 10):
one element per check evaluated, with rule, condition, the value
or state read, the bound, and a three-state result, the verdict's
reason checkable against the trace. -02 required the unmet
condition to be identified structurally only when a decision
turned on referenced evidence.
* Specified how a mandate-layer deferral maps onto the approval
lifecycle (Section 8.1), with the new reason code
"external_authorization"; a mandate-layer override of a denial has
no AADP counterpart.
* Added the "present_bound" obligation type (Section 6) as the fail-
closed hook for the action-bound permit of Section 1.2.
* Cited prior and adjacent work this document had not cited: [OAP]
and [ACP], which predate its first revision (Section 1);
[I-D.kroehl-agentic-trust-aae], with its relationship drawn in
Section 16; and [ACS] and [AUTHZEN], with the composition stated
and two rules for carrying AADP decisions over the Authorization
API.
* Declared the protocol identifier "aadp/0.2" (Section 14) and
updated every example. -02 replaced the budget reason codes while
its examples still carried "aadp/0.1"; the reference
implementation already stamped its evidence records "aadp/0.2",
and this revision makes the document say what the implementation
does.
* Updated the IANA registries' initial contents and the
Implementation Status section.
Appendix D. 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).
Saha Expires 27 March 2027 [Page 39]
Internet-Draft AADP September 2026
* 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.
* Updated the Implementation Status section.
Appendix E. 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.
Saha Expires 27 March 2027 [Page 40]
Internet-Draft AADP September 2026
* 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).
* Expanded Security Considerations: channel as principal attack
surface, and reversibility as best-effort operational recovery
rather than a guarantee about external state.
Appendix F. 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.
Saha Expires 27 March 2027 [Page 41]
Internet-Draft AADP September 2026
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 27 March 2027 [Page 42]