Adaptive Authorization for Agentic AI: Graduated and Escalated Execution Control for Critical Infrastructure
draft-das-agentic-adaptive-authorization-00
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 | Sangam Das | ||
| Last updated | 2026-09-22 | ||
| 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-das-agentic-adaptive-authorization-00
Network Working Group S. Das
Internet-Draft 23 September 2026
Intended status: Informational
Expires: 27 March 2027
Adaptive Authorization for Agentic AI: Graduated and Escalated Execution
Control for Critical Infrastructure
draft-das-agentic-adaptive-authorization-00
Abstract
AI agents are beginning to move money, release confidential data,
change cloud privileges, and command industrial and other critical-
infrastructure equipment. Existing controls answer whether an actor
or request may proceed. These include authentication, OAuth scopes,
conditional access, risk engines, and attestation. None of them,
alone, guarantees three things about the consequence that finally
occurs: that it is the exact act that was evaluated, that it is still
permitted under current state, and that it cannot be replayed,
substituted, or routed around the check. Risk engines that return
ESCALATE widen this gap. The escalation is a label, and nothing
forces the stricter conditions it implies to reach the point where
the effect actually happens.
This document defines Graduated and Escalated Conditional Execution
Finality. Every AI-generated operation is held as a non-effective
Candidate Act. It is classified into a graduated release class rather
than a binary allow/deny: ordinary, reduced, escalated, canary,
sandbox, review, quarantine, or deny. For an elevated-risk act, the
system first derives a narrower consequence boundary. It then binds
the required controls into an act-bound, sink-bound Execution Handle;
examples include a lower value, one named recipient, protected
approval, short validity, fresh attestation, and single use. The
Finality Sink at the last preventable boundary re-verifies those
controls against current protected state, atomically with
effectuation.
Das Expires 27 March 2027 [Page 1]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
The contribution is threefold. First, escalation changes executable
authority, not merely a decision record. Second, escalation is
monotonic: it cannot be laundered, fragmented, downgraded, or
resubmitted away on its path to the sink. Third, the Finality Sink
is shown to be necessary but not sufficient, so finality is an end-
to-end property rather than a gateway. The document specifies
nineteen testable enforcement points, from the base execution-
dependency mechanism to proxy, hardware, escrow, rollback,
inheritance, and path-closure requirements. It also provides a
comparison with conventional mechanisms, a security model with
explicit assumptions and invariants, a latency model, escalation-
specific attacks, and the problems it leaves open.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 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.
Das Expires 27 March 2027 [Page 2]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. How This Differs from Conventional Solutions . . . . . . 7
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 9
2. Industry-Standard Terminology and Functional Equivalence . . 9
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Architectural Invariant . . . . . . . . . . . . . . . . . . . 14
5. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Candidate Act . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Non-Effective State . . . . . . . . . . . . . . . . . . . 15
5.3. Protected Enforcement Domain . . . . . . . . . . . . . . 16
5.4. Result-Consequence Acceptance Envelope . . . . . . . . . 16
5.5. Execution Authorization Scope Object . . . . . . . . . . 16
5.6. Execution Handle . . . . . . . . . . . . . . . . . . . . 16
5.7. Finality Sink . . . . . . . . . . . . . . . . . . . . . . 17
5.8. Escalated Conditional Finality . . . . . . . . . . . . . 17
6. Dynamic Trust Evaluation Is Not Execution Finality . . . . . 17
7. Graduated Finality . . . . . . . . . . . . . . . . . . . . . 19
8. Escalated Conditional Finality Workflow . . . . . . . . . . . 19
9. Escalation Controls . . . . . . . . . . . . . . . . . . . . . 21
10. Current-State Execution Congruence . . . . . . . . . . . . . 22
11. Why the Finality Sink Alone Is Not Sufficient . . . . . . . . 22
11.1. A Sink Without a Candidate Act Has Nothing Stable to
Compare . . . . . . . . . . . . . . . . . . . . . . . . 23
11.2. A Sink Without Non-Effective State May Verify Too
Late . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.3. A Sink Without Bound Authority Cannot Know What Was
Permitted . . . . . . . . . . . . . . . . . . . . . . . 25
11.4. A Sink Without Protected Current State Cannot Detect
Temporal Drift . . . . . . . . . . . . . . . . . . . . 25
11.5. A Sink Without Replay State Cannot Enforce Single-Use
Authority . . . . . . . . . . . . . . . . . . . . . . . 26
11.6. A Sink Without Exact-Act Representation Can Be Defeated by
Semantic Differences . . . . . . . . . . . . . . . . . 26
11.7. A Sink Without Consequence-Path Completeness Can Simply Be
Bypassed . . . . . . . . . . . . . . . . . . . . . . . 26
11.8. A Sink Cannot Independently Decide Escalation
Semantics . . . . . . . . . . . . . . . . . . . . . . . 27
11.9. A Sink Without Atomicity Can Reintroduce TOCTOU . . . . 28
11.10. A Finality Sink Without Protected Upstream Evidence
Becomes Another Policy Engine . . . . . . . . . . . . . 28
12. Finality Is a System Property, Not a Box . . . . . . . . . . 29
12.1. Functional Equivalence of Consolidated
Implementations . . . . . . . . . . . . . . . . . . . . 31
12.2. Why This Distinction Matters . . . . . . . . . . . . . . 31
13. Enforcement Points . . . . . . . . . . . . . . . . . . . . . 32
13.1. Terms Used in This Section . . . . . . . . . . . . . . . 32
Das Expires 27 March 2027 [Page 3]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
13.2. EP-1: Cryptographic Execution Dependency . . . . . . . . 33
13.3. EP-2: Threshold-Shared Execution Material . . . . . . . 34
13.4. EP-3: Commitment-Release Temporal Escrow . . . . . . . . 34
13.5. EP-4: Paired Forward and Rollback Authority . . . . . . 35
13.6. EP-5: Ephemeral Finality Sink . . . . . . . . . . . . . 35
13.7. EP-6: Proxy Enforcement for Legacy Interfaces . . . . . 36
13.8. EP-7: Modular Escalation Enforcement . . . . . . . . . . 36
13.9. EP-8: Receipt as a Release Predicate . . . . . . . . . . 37
13.10. EP-9: Assurance Profile with Anti-Downgrade Binding . . 37
13.11. EP-10: Adversarial Perturbation Gate . . . . . . . . . . 38
13.12. EP-11: Consequence-Class Inheritance Ceiling . . . . . . 38
13.13. EP-12: Protected Hardware Finality Sink . . . . . . . . 39
13.14. EP-13: Isolation of the Enforcement Domain from the
Agent . . . . . . . . . . . . . . . . . . . . . . . . . 39
13.15. EP-14: Structural Incompleteness versus Software
Tokens . . . . . . . . . . . . . . . . . . . . . . . . 40
13.16. EP-15: Receipt-Bound Release versus Post-Effectuation
Logging . . . . . . . . . . . . . . . . . . . . . . . . 40
13.17. EP-16: Candidate-Act Authority versus Ordinary Permission
Checks . . . . . . . . . . . . . . . . . . . . . . . . 41
13.18. EP-17: First Usable Release Boundary . . . . . . . . . . 42
13.19. EP-18: Fragmented, Transformed, and Delegated Act
Equivalence . . . . . . . . . . . . . . . . . . . . . . 42
13.20. EP-19: Emergency, Maintenance, and Fallback Path
Closure . . . . . . . . . . . . . . . . . . . . . . . . 43
13.21. Enforcement-Point Summary . . . . . . . . . . . . . . . 43
14. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 45
14.1. Protected Assets . . . . . . . . . . . . . . . . . . . . 45
14.2. Potential Adversaries . . . . . . . . . . . . . . . . . 46
14.3. Security Objective . . . . . . . . . . . . . . . . . . . 46
15. Security Model . . . . . . . . . . . . . . . . . . . . . . . 46
15.1. Trust Assumptions . . . . . . . . . . . . . . . . . . . 46
15.2. Adversary Capabilities . . . . . . . . . . . . . . . . . 47
15.3. Invariants . . . . . . . . . . . . . . . . . . . . . . . 47
15.4. Informal Bound . . . . . . . . . . . . . . . . . . . . . 48
15.5. Outside the Model . . . . . . . . . . . . . . . . . . . 48
16. Principal Threats . . . . . . . . . . . . . . . . . . . . . . 48
17. Exact-Act Substitution . . . . . . . . . . . . . . . . . . . 50
18. Canonicalization Ambiguity . . . . . . . . . . . . . . . . . 50
19. Replay and Single-Use Authority . . . . . . . . . . . . . . . 51
20. Revocation and Generation Fencing . . . . . . . . . . . . . . 51
21. Snapshot Rollback . . . . . . . . . . . . . . . . . . . . . . 52
22. Escalation Laundering . . . . . . . . . . . . . . . . . . . . 52
23. Escalation-Specific Attacks . . . . . . . . . . . . . . . . . 52
23.1. Threshold Fragmentation . . . . . . . . . . . . . . . . 53
23.2. Classification Downgrade and Fail-Open . . . . . . . . . 53
23.3. Resubmission Until Favorable . . . . . . . . . . . . . . 53
23.4. Parallel Authority for the Same Act . . . . . . . . . . 53
Das Expires 27 March 2027 [Page 4]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
23.5. Classifier Probing . . . . . . . . . . . . . . . . . . . 54
23.6. Approval Fatigue and Reviewer Exhaustion . . . . . . . . 54
23.7. Emergency-Override Abuse . . . . . . . . . . . . . . . . 54
24. Human-Approval Bypass . . . . . . . . . . . . . . . . . . . . 54
25. Finality-Sink Bypass . . . . . . . . . . . . . . . . . . . . 55
26. Finality Sink Compromise . . . . . . . . . . . . . . . . . . 55
27. Verification Exhaustion and Denial of Service . . . . . . . . 56
28. Crash Consistency and Ambiguous Outcomes . . . . . . . . . . 56
29. Atomicity . . . . . . . . . . . . . . . . . . . . . . . . . . 57
30. High-Latency Effectuation . . . . . . . . . . . . . . . . . . 57
31. Latency Considerations . . . . . . . . . . . . . . . . . . . 58
31.1. Cold Preparation Path . . . . . . . . . . . . . . . . . 58
31.2. Warm / Nearline Path . . . . . . . . . . . . . . . . . . 59
31.3. Hot Finality Path . . . . . . . . . . . . . . . . . . . 59
31.4. Latency Budget Model . . . . . . . . . . . . . . . . . . 60
31.5. Freshness, Staleness Windows, and Clocks . . . . . . . . 60
31.6. Approval Windows . . . . . . . . . . . . . . . . . . . . 60
31.7. Timeouts and Retry Hazards . . . . . . . . . . . . . . . 61
31.8. Speculative Preparation . . . . . . . . . . . . . . . . 61
31.9. Performance Isolation . . . . . . . . . . . . . . . . . 61
32. Latency Proportional to Consequence . . . . . . . . . . . . . 61
33. Legacy-System Deployment . . . . . . . . . . . . . . . . . . 62
33.1. Sink-Adjacent Proxy . . . . . . . . . . . . . . . . . . 62
33.2. Existing Choke Points . . . . . . . . . . . . . . . . . 62
33.3. Progressive Migration . . . . . . . . . . . . . . . . . 63
34. Native Versus Non-Native Finality . . . . . . . . . . . . . . 63
35. Relationship to Authentication and Authorization . . . . . . 63
36. Relationship to OAuth . . . . . . . . . . . . . . . . . . . . 64
37. Relationship to Attestation . . . . . . . . . . . . . . . . . 64
38. Relationship to Other Execution-Finality Drafts . . . . . . . 64
38.1. Difference from Candidate-Act Finality . . . . . . . . . 65
38.2. Difference from the Agentic Effectuation Boundary . . . 66
38.3. Difference from the AI Boundary Draft . . . . . . . . . 66
38.4. Difference from the Execution Handle Draft . . . . . . . 66
38.5. Difference from Finality-Bound Revocation . . . . . . . 67
38.6. Difference from State and Policy Continuity . . . . . . 67
38.7. Difference from Consequence-Path Completeness . . . . . 68
38.8. Difference from Composite Execution Finality . . . . . . 68
38.9. Difference from Enforcement Profiles . . . . . . . . . . 69
38.10. Difference from the Deployment Architecture . . . . . . 69
38.11. Difference from Dynamic-Trust or Risk-Scoring Systems . 70
38.12. Architectural Position Within the Draft Family . . . . . 71
38.13. Specific Contribution of This Document . . . . . . . . . 71
39. Receipts and Evidence . . . . . . . . . . . . . . . . . . . . 72
40. Multi-Agent Systems . . . . . . . . . . . . . . . . . . . . . 73
41. Operational Monitoring . . . . . . . . . . . . . . . . . . . 73
42. Fail-Closed and Safe-Degraded Behavior . . . . . . . . . . . 73
43. Residual Risk . . . . . . . . . . . . . . . . . . . . . . . . 74
Das Expires 27 March 2027 [Page 5]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
44. Security Properties . . . . . . . . . . . . . . . . . . . . . 74
45. Deployment Profiles . . . . . . . . . . . . . . . . . . . . . 75
46. Interoperability Requirements . . . . . . . . . . . . . . . . 75
47. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 76
47.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . 76
47.2. SEND . . . . . . . . . . . . . . . . . . . . . . . . . . 76
47.3. Cloud Administration . . . . . . . . . . . . . . . . . . 77
48. What This Architecture Does Not Claim . . . . . . . . . . . . 78
49. Open Problems . . . . . . . . . . . . . . . . . . . . . . . . 78
50. IETF-Relevant Questions . . . . . . . . . . . . . . . . . . . 79
51. Implementation and Testing Considerations . . . . . . . . . . 80
52. Implementation and Related Resources . . . . . . . . . . . . 81
53. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 82
54. Security Considerations . . . . . . . . . . . . . . . . . . . 83
55. Privacy Considerations . . . . . . . . . . . . . . . . . . . 84
56. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84
57. References . . . . . . . . . . . . . . . . . . . . . . . . . 84
57.1. Normative References . . . . . . . . . . . . . . . . . . 84
57.2. Informative References . . . . . . . . . . . . . . . . . 84
Appendix A. Alternative Titles . . . . . . . . . . . . . . . . . 87
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 87
1. Introduction
Modern autonomous systems increasingly go beyond generating
recommendations. An AI agent may initiate a payment, SEND a
confidential document, modify cloud infrastructure, update a
database, deploy software, reconfigure a network, alter an industrial
controller, transmit a communication, invoke another agent, or cause
physical actuation.
The security problem therefore changes. It is no longer sufficient
to ask "Is this agent authenticated?" It is also not sufficient to
ask "Does this agent currently appear trustworthy?" or even "Was this
request authorized?"
The additional question is:
| *Is the exact consequence that is now about to become effective
| still the consequence that was permitted, under the current
| protected state, at the intended execution boundary?*
The broader execution-finality architecture
[I-D.das-execution-finality-deployment] distinguishes approval of an
agent or workflow from approval of the particular consequence. An
authenticated and behaviorally normal system may still produce a
Candidate Act that is stale, unsupported, unsafe, jurisdictionally
improper, or otherwise unsuitable for effectuation.
Das Expires 27 March 2027 [Page 6]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
This distinction becomes particularly important for systems that
already perform continuous trust evaluation. A dynamic trust system
may produce the following outcomes, based on identity, authorization
scope, device attestation, behavioral confidence, provenance, or
other signals:
ALLOW
RESTRICT
ESCALATE
DENY
Such a system may be valuable. However, an ESCALATE outcome does not
by itself establish Escalated Conditional Finality. A trust engine
generally determines whether an agent or request deserves additional
scrutiny. Execution finality determines whether the *exact resulting
consequence* can become real.
1.1. How This Differs from Conventional Solutions
Each conventional mechanism answers a real question, but none of
them, on its own, binds the exact consequence to current authority at
the point where the effect occurs.
Das Expires 27 March 2027 [Page 7]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
+=====================+===================+========================+
| Mechanism | What it | What it leaves open |
| | establishes | |
+=====================+===================+========================+
| Authentication, | who the actor is, | which act; whether the |
| MFA, step-up | freshly | act changed before |
| | | commit |
+---------------------+-------------------+------------------------+
| Conditional access, | whether a session | per-act consequence; |
| Zero Trust session | or request may | binding to the actual |
| policy | continue | effect |
+---------------------+-------------------+------------------------+
| OAuth scopes, Rich | the class or | commit-time |
| Authorization | description of a | currentness, single |
| Requests [RFC9396] | permitted action | use, path completeness |
+---------------------+-------------------+------------------------+
| Policy decision and | a decision for a | that the enforced |
| enforcement points | presented request | effect equals the |
| | | decided request |
+---------------------+-------------------+------------------------+
| Risk scoring, | an ESCALATE or | encoding the implied |
| adaptive | RESTRICT label | conditions into |
| authorization | | executable authority |
+---------------------+-------------------+------------------------+
| Remote attestation | the platform | the act that component |
| [RFC9334] | state of a | processes |
| | component | |
+---------------------+-------------------+------------------------+
| Payment transaction | amount and payee | other sink types; |
| signing with | bound to one | graduated classes; |
| dynamic linking | consent | revocation generations |
+---------------------+-------------------+------------------------+
| Maker-checker, | a second human | binding of approval to |
| four-eyes approval | agreed | exact act digest, |
| | | sink, and freshness |
+---------------------+-------------------+------------------------+
| Two-phase commit, | atomic commit or | whether the committed |
| sagas | compensation | act was authorized; |
| | | authority consumption |
+---------------------+-------------------+------------------------+
| Rate limits, quotas | volume ceilings | exact-act binding for |
| | | each individual effect |
+---------------------+-------------------+------------------------+
Table 1
Das Expires 27 March 2027 [Page 8]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
The closest existing analogue is dynamic linking in payment strong
customer authentication, which binds amount and payee to an
authentication code. This document generalizes that idea in four
directions:
* from payments to any consequence-bearing sink;
* from one consent step to graduated release classes;
* from a static binding to one re-verified against current policy
and revocation generations;
* from a single channel to authority that is consumed once and
enforced on every consequence path.
The contribution is therefore not a new trust signal. It is the
composition that carries a risk decision, as enforceable and current
authority, into the component that can still prevent the effect.
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Industry-Standard Terminology and Functional Equivalence
This document uses the terms Candidate Act, Non-Effective State,
Escalated Conditional Finality, Execution Handle, and Finality Sink
to describe specific architectural functions. These terms are not
intended to require new terminology where an implementation already
provides functionally equivalent mechanisms.
Established security, cloud, distributed-systems, authorization,
control-system, and safety fields already name mechanisms that
overlap with these functions or can implement them:
* runtime authorization and continuous authorization;
* adaptive authorization, risk-based authorization, conditional
access, and step-up authorization;
* policy decision points, policy enforcement points, and reference
monitors;
Das Expires 27 March 2027 [Page 9]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
* bounded capabilities and transaction-specific or transactional
authorization;
* command gates, commit gates, safety interlocks, and actuation
interlocks;
* secure execution boundaries and privileged-action controls;
* workload identity and trusted execution;
* fail-safe enforcement.
The architectural distinction in this document is therefore
functional rather than terminological.
A *Candidate Act* is an operation that has been generated but has not
yet been permitted to create the protected external consequence. It
corresponds to a fully parameterized proposed transaction, pending
command, staged operation, tool invocation, privileged action, data
release, payment instruction, or actuation request.
A *Non-Effective State* is a state in which an operation may be
evaluated, simulated, reviewed, narrowed, redacted, delayed,
escalated, or rejected without yet producing the protected
consequence. It corresponds to a staged, prepared, pending,
escrowed, pre-commit, sandboxed, or otherwise non-effectuating state.
A *Finality Sink* is any component that retains the technical ability
to prevent the protected consequence. It corresponds functionally to
a non-bypassable policy enforcement point, reference monitor,
transaction commit gate, command gate, egress enforcement point,
safety interlock, actuation interlock, or secure execution boundary.
An *Execution Handle* binds execution authority to a defined act,
scope, destination, freshness condition, and effectuation boundary.
It corresponds functionally to a bounded capability, transaction-
specific authorization object, one-time execution permit, sender-
constrained or non-bearer authority object, protected command
envelope, or equivalent mechanism.
Das Expires 27 March 2027 [Page 10]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
*Escalated Conditional Finality* corresponds to an execution-time
form of adaptive or risk-based authorization in which an elevated-
risk Candidate Act does not receive ordinary execution authority.
Instead, the act remains non-effective while one or more stricter
controls are applied. These may include reduced scope, shorter
validity, protected human approval, multi-party approval, fresh
attestation, redaction, limited financial value, recipient
restriction, sandbox-first execution, canary execution, reversible
execution, delayed release, enhanced monitoring, or other
consequence-specific restrictions.
The important distinction is that an escalation result is not merely
a label returned by a trust or policy engine. The additional
conditions are carried into the authority governing effectuation and
remain enforceable at the Finality Sink.
For example, a conventional adaptive-authorization system may
determine:
identity valid
behavior elevated-risk
device attested
risk threshold exceeded
|
v
ESCALATE
In the architecture described here, escalation continues into the
execution-control path:
Das Expires 27 March 2027 [Page 11]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
Candidate Act
|
v
elevated-risk classification
|
v
Candidate Act remains non-effective
|
v
derive narrower permitted consequence
|
v
apply additional authorization controls
|
v
bind controls into execution authority
|
v
Finality Sink verifies current conditions
|
+------ valid ------> bounded effectuation
|
+------ invalid ----> no effectuation
Accordingly, this document does not define another general-purpose
trust score, identity system, authentication protocol, or policy
language. Identity, workload identity, authorization, behavioral
trust, attestation, Zero Trust controls, and risk engines can provide
inputs to the finality decision. The additional property addressed
here is control of the transition from an authorized or conditionally
authorized operation to the exact externally effective consequence.
A conventional mechanism is functionally equivalent only to the
extent that it provides the same required properties. Depending on
the selected assurance profile, these can include:
* maintenance of the proposed operation in a non-effective state
until required conditions are satisfied;
* deterministic representation of all consequence-relevant fields;
* binding of authority to the exact Candidate Act;
* binding to the intended resource, recipient, destination,
actuator, or Finality Sink;
* current-state verification of policy, revocation, generation,
freshness, and other required protected state;
Das Expires 27 March 2027 [Page 12]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
* replay-resistant or single-use authority where required;
* preservation of escalation restrictions through downstream
execution;
* complete mediation of all paths capable of producing the protected
consequence;
* coupling of verification, authority consumption, and effectuation
so that a time-of-check-to-time-of-use substitution cannot
silently occur; and
* safe failure and recovery behavior.
This document uses established terminology throughout so that the
architecture is recognizable to implementers in AI agent security and
agentic AI; Zero Trust, continuous authorization, and workload
identity; cloud and API security; payment and transaction security;
critical infrastructure and industrial control; and autonomous and
safety-critical execution systems.
The document does not claim that existing mechanisms using these
terms automatically provide execution finality. Rather, it
identifies the additional composition, placement, binding, current-
state, and effectuation properties required for functional
equivalence.
3. Scope
This architecture is primarily intended for *high-criticality systems
and high-consequence operations*. Examples include:
* financial transfers;
* confidential data egress;
* privileged cloud administration;
* critical telecommunications changes;
* industrial commands and infrastructure control;
* safety-critical autonomous systems;
* high-impact database mutations;
* model deployment and similar operations.
Das Expires 27 March 2027 [Page 13]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
The architecture does not require every CPU instruction, memory
access, model token, ordinary API read, or low-risk internal
computation to pass through maximum-assurance finality verification.
Assurance SHOULD be proportionate to consequence.
For high-criticality operations, a bounded increase in latency can be
an acceptable engineering trade-off where it materially reduces the
possibility of catastrophic or irreversible consequences.
| *For high-criticality systems, bounded verification latency may be
| acceptable; catastrophic unauthorized consequence is not.*
4. Architectural Invariant
| *A Candidate Act remains non-effective until the conditions
| governing its authorized consequence are satisfied and the
| applicable Finality Sink verifies that the exact operation
| presented for effectuation remains within those conditions.*
The broader architecture describes the same separation: AI output is
converted into a Candidate Act and remains non-effective until
finality predicates are satisfied and sink-verifiable authority is
produced.
AI / AGENT
|
| proposes operation
v
CANDIDATE ACT
|
| still non-effective
v
PROTECTED ENFORCEMENT DOMAIN
|
| evidence, provenance, authorization,
| behavioral state, consequence analysis,
| current policy, risk classification
v
FINALITY CLASSIFICATION
|
+---- ordinary ----------------------+
| |
+---- reduced scope -----------------+
| |
+---- escalated conditional ---------+
| |
+---- sandbox / canary --------------+
| |
Das Expires 27 March 2027 [Page 14]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
+---- quarantine / deny |
|
v
EXECUTION AUTHORITY
/ EXECUTION HANDLE
|
v
============== EFFECTUATION BOUNDARY ==============
|
v
FINALITY SINK
|
reconstruct actual consequence
verify current protected state
verify exact-act binding
verify escalation conditions
verify freshness/revocation
verify replay/consumption
|
+--------------+-------------+
| |
ALLOW DENY
| |
v v
EFFECTIVE CONSEQUENCE NO EFFECT
5. Terminology
5.1. Candidate Act
A *Candidate Act* is the fully parameterized operation proposed for
effectuation but not yet permitted to create the protected external
consequence. It may represent a payment, SEND operation, database
mutation, API invocation, cloud-control operation, software
deployment, model update, network command, physical actuation, or
equivalent effect-capable operation.
Candidate Acts are generated but not yet externally effective. A
Candidate Act may carry output, recipient, tool, Finality Sink,
purpose, jurisdiction, risk class, model identifier, workflow
identifier, and similar context.
5.2. Non-Effective State
A *Non-Effective State* is a state in which an operation may exist,
be staged, queued, simulated, reviewed, redacted, sandboxed,
escalated, or prepared without yet producing the protected
consequence.
Das Expires 27 March 2027 [Page 15]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
Non-effective does not mean nonexistent. The operation may be fully
formed. The defining property is that it still cannot produce the
protected effect.
5.3. Protected Enforcement Domain
The *Protected Enforcement Domain (PED)* performs or coordinates
protected validation before effectuation. Depending on the profile,
this may include policy evaluation, provenance validation, behavioral
evidence, consequence simulation, scope derivation, risk
classification, escalation processing, receipt generation, and
Execution Handle issuance.
5.4. Result-Consequence Acceptance Envelope
The *Result-Consequence Acceptance Envelope (RCAE)* describes the
permitted consequence boundary. It may constrain the following
properties:
* recipient, amount, resource, and purpose;
* jurisdiction and data classification;
* operation type, permitted tool, and permitted Finality Sink;
* time window, risk class, and reversibility;
* policy generation and revocation generation.
The RCAE thereby converts permission into a technically bounded
consequence envelope.
5.5. Execution Authorization Scope Object
The *Execution Authorization Scope Object (EASO)* translates the
permitted consequence boundary into an execution-enforceable scope.
The RCAE describes what consequence is permissible; the EASO binds
that permissible consequence into enforceable execution parameters.
5.6. Execution Handle
An *Execution Handle* is an act-bound, sink-bound, scope-bound
authority object used by the Finality Sink during effectuation
[I-D.das-execution-handle].
Depending on the deployment profile, the Handle may merely prove
narrowly scoped execution authority. It may also participate in
reconstruction, activation, combination, unsealing, or release of
Das Expires 27 March 2027 [Page 16]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
completion material. In its advanced form, the Handle carries
narrowly bounded authority rather than a general-purpose execution
credential.
5.7. Finality Sink
The *Finality Sink* is the component controlling the point where the
Candidate Act can become the protected consequence. It may be
implemented as any component capable of withholding the final
consequence, for example:
* a payment connector;
* a database commit controller or storage controller;
* an egress gateway or secure proxy;
* a network command gate;
* a cloud-control enforcement component;
* an industrial actuator controller;
* a firmware boundary;
* an HSM, TEE, SmartNIC, or DPU.
5.8. Escalated Conditional Finality
*Escalated Conditional Finality* applies when an act is not suitable
for ordinary release but may still become effective under stricter
controls. The critical property is:
| *The Candidate Act remains non-effective while the stricter
| controls are assembled.*
Controls applicable in this state include protected approval, multi-
party approval, fresh attestation, shortened validity, reduced value,
redaction, stronger authorization scope, monitoring, sandboxing,
canary execution, and rollback capability.
6. Dynamic Trust Evaluation Is Not Execution Finality
A dynamic trust API might consider:
Das Expires 27 March 2027 [Page 17]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
identity confidence
authorization scope
behavioral consistency
device attestation
risk telemetry
and produce ALLOW, RESTRICT, ESCALATE, or DENY.
This architecture does not reject such mechanisms. They can provide
important inputs. However:
| *Trust evaluates the requester or request context. Finality
| controls the consequence.*
Consider:
Agent: agent-47
Identity: verified
Authority: write:refunds
Device: attested
Behavior: normal
Trust score: 94
Decision: ALLOW
The final operation may nevertheless drift:
Authorized Candidate Act
refund:
amount = 100
recipient = Customer-A
Actual operation at commit
refund:
amount = 1000
recipient = Account-B
The agent's identity has not changed. The trust score may not have
changed. The authorization endpoint may not have changed. But the
consequence has changed. The Finality Sink therefore asks something
different:
| *What is actually about to happen?*
Das Expires 27 March 2027 [Page 18]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
7. Graduated Finality
Binary ALLOW/DENY can be unnecessarily coarse for autonomous critical
systems.
The architecture recognizes a structured spectrum of outcomes:
ordinary release, reduced-scope release, redaction, delayed release,
reversible release, canary release, sandbox-first execution, escrow,
protected review, quarantine, and denial.
This matters because some Candidate Acts are not safe enough for
ordinary execution, yet not dangerous enough to require permanent
denial. For example:
Requested:
Transfer INR 5,000,000
Policy:
Automatic AI transfers permitted only to INR 500,000
Possible outcomes:
DENY entire request
or
ESCALATED CONDITIONAL FINALITY:
reduce amount
obtain protected approval
require fresh sink attestation
shorten expiry
enable enhanced receipt
Graduated finality therefore changes the question from "Allow or
deny?" to:
| *Under what bounded technical conditions may this consequence
| become effective?*
8. Escalated Conditional Finality Workflow
An escalated-but-allowable act follows a stronger execution path.
The Candidate Act MUST remain non-effective throughout escalation.
Das Expires 27 March 2027 [Page 19]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
AI output
|
v
Candidate Act
|
v
baseline validation
|
v
ordinary release threshold not satisfied
|
v
but act remains within potentially permissible region
|
v
ESCALATED classification
|
v
derive narrower RCAE
|
v
select mandatory escalation controls
|
v
construct stricter EASO
|
v
collect required evidence / approvals
|
v
generate residual-risk evidence
|
v
mint escalated Execution Handle
|
v
Finality Sink independently verifies
|
v
current-state congruence?
|
+-- YES --> bounded effectuation
|
+-- NO --> Candidate Act remains non-effective
The escalated path is therefore not equivalent to attaching the label
ESCALATE to an authorization decision. It changes the authority that
is eventually capable of reaching the effectuation boundary.
Das Expires 27 March 2027 [Page 20]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
9. Escalation Controls
Depending on consequence class, an escalated profile may require
stronger controls. These may include:
* protected human approval or quorum approval;
* narrower financial value;
* recipient restriction or jurisdiction restriction;
* data-field redaction;
* shortened expiry;
* fresh sink attestation;
* sandbox, canary, or reversible execution;
* temporal escrow;
* additional provenance checks, stricter consequence simulation, or
additional evidence;
* post-effectuation monitoring or rollback authority.
The critical requirement is:
| *The selected escalation controls MUST be represented in the
| authority that reaches the Finality Sink.*
They cannot exist only as notes in an upstream policy engine. For
example:
Escalation requires:
maximum amount = INR 100,000
recipient = Account-A
expiry = 30 seconds
human approval = required
fresh sink attestation = required
jurisdiction = IN
replay count = 1
The Finality Sink MUST NOT accept the following, even if the
originating agent remains fully trusted:
Das Expires 27 March 2027 [Page 21]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
amount = INR 110,000
recipient = Account-B
expiry = 10 minutes
human approval = absent
10. Current-State Execution Congruence
One of the most important execution-finality properties is that
earlier approval is not sufficient. State can change between
validation and effectuation.
Examples of mutable state include policy, revocation, recipient
status, jurisdiction, model approval, data classification, human
approval, risk classification, and Finality Sink trust.
validated at T1
!=
automatically executable at T2
The Finality Sink SHOULD verify current-state congruence:
Candidate Act hash
RCAE
EASO
Execution Handle
policy generation
revocation generation
nonce
receipt
sink identity
sink attestation
|
v
must simultaneously correspond
|
v
at effectuation time
If any mandatory component has changed, the result is NO EFFECT.
11. Why the Finality Sink Alone Is Not Sufficient
The Finality Sink is the decisive enforcement component in an
execution-finality architecture, because it controls, or is
positioned at, the last boundary where the protected consequence can
still be prevented. However, the existence of a Finality Sink by
itself does not establish execution finality.
Das Expires 27 March 2027 [Page 22]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
A sink cannot determine that an operation is legitimate merely
because it is located close to the point of execution. For
meaningful finality, the sink must receive or reconstruct enough
protected information to answer several distinct questions:
1. What exact act was proposed?
2. What exact consequence was authorized?
3. Under what scope was that consequence permitted?
4. What evidence supported that authorization?
5. Is the authorization still current?
6. Has the authority been revoked, consumed, replayed, or
superseded?
7. Is this the intended recipient, resource, destination,
jurisdiction, amount, tool, or actuator?
8. Were additional escalation conditions required?
9. Is the operation reaching the same trusted sink for which
authority was issued?
10. Can the verified decision be coupled to effectuation without a
substitution or TOCTOU gap?
The Finality Sink therefore performs the *last enforcement decision*,
but the information required for that decision is produced and
protected by the wider finality architecture.
11.1. A Sink Without a Candidate Act Has Nothing Stable to Compare
Consider a Finality Sink receiving the command:
TRANSFER 10,000
TO Account-B
The sink can evaluate that command against general policy. But
without a previously formed and bound Candidate Act, the sink cannot
necessarily determine that the operation originally authorized was:
TRANSFER 10,000
TO Account-A
and was subsequently changed.
Das Expires 27 March 2027 [Page 23]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
The Candidate Act provides the stable representation of the proposed
consequence. The architecture treats AI-generated output as a
Candidate Act and keeps it non-effective before finality validation.
The Finality Sink then verifies authority associated with that
specific Candidate Act rather than merely evaluating an unbound
operation arriving at an endpoint.
Candidate Act
=
what was proposed and bound
Actual Sink-Side Act
=
what is actually about to happen
Finality Sink
=
component that verifies that the two remain congruent
Without this separation, the same component may effectively define
both what was intended and what will occur, reducing the strength of
exact-act comparison.
11.2. A Sink Without Non-Effective State May Verify Too Late
A Finality Sink can only prevent an unauthorized consequence if the
Candidate Act remains technically non-effective until verification
completes.
Suppose the operation can already transmit bytes, commit a database
mutation, release money, change network state, actuate hardware, or
expose confidential information before the sink finishes
verification. In that case, the enforcement point is not actually
controlling final effectuation.
The non-effective state provides a temporal and architectural
separation:
COMPUTATION
|
v
PROPOSED ACT
|
v
FINALITY DECISION
|
v
CONSEQUENCE
Das Expires 27 March 2027 [Page 24]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
A Candidate Act may be staged, buffered, reviewed, simulated,
redacted, delayed, sandboxed, escalated, or quarantined while
remaining non-effective. The Finality Sink alone cannot create this
guarantee if upstream or parallel paths can already cause the
consequence.
11.3. A Sink Without Bound Authority Cannot Know What Was Permitted
Suppose a sink receives a valid identity credential stating:
Agent-47
Scope: write:refunds
That tells the sink that Agent-47 may belong to a class of actors
allowed to issue refund requests. It does not necessarily establish
the exact amount, beneficiary, source account, purpose, jurisdiction,
permitted time, sink, or consequence.
Execution finality therefore requires an act-specific or consequence-
specific authority object. This may be implemented as a scoped non-
bearer capability, EASO, Execution Handle, protected command
envelope, or equivalent bounded authorization.
Such authority is bound to parameters including the Candidate Act,
sink, purpose, recipient, jurisdiction, data class, time window,
policy epoch, revocation epoch, permitted consequence, nonce, and
validation evidence.
The Finality Sink verifies that bounded authority. The sink does not
create its meaning after the fact.
11.4. A Sink Without Protected Current State Cannot Detect Temporal
Drift
Authorization can be correct at time T1 and incorrect at time T2.
Between validation and execution, policy may change, revocation may
occur, recipient status may change, sink trust may change, approval
may expire, jurisdiction may change, and resource state may change.
Finality therefore requires current-state verification. Historical
validation is insufficient; current-state congruence is required at
effectuation time across the Candidate Act, policy epoch, revocation
epoch, nonce, receipt, sink state, and related protected parameters
(Section 10).
A Finality Sink operating only on the presented request, without
authoritative protected state, cannot reliably determine this.
Das Expires 27 March 2027 [Page 25]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
11.5. A Sink Without Replay State Cannot Enforce Single-Use Authority
An otherwise valid Execution Handle can become dangerous if it can be
used repeatedly:
Authorized:
Transfer INR 10,000 once
Replay:
Transfer INR 10,000
Transfer INR 10,000
Transfer INR 10,000
Every individual request might contain perfectly valid cryptographic
material. The problem is not authenticity; it is *consumption
state*. The Finality Sink therefore needs protected knowledge of
nonce use, counter state, execution identifier, allowed-use count,
generation, and prior consumption.
A stateless sink cannot establish strong single-use finality merely
by validating signatures.
11.6. A Sink Without Exact-Act Representation Can Be Defeated by
Semantic Differences
Cryptographic verification protects bytes. Execution finality must
protect *meaning*.
Suppose the authority system signs one representation while the
downstream executor interprets another. This can happen because of
Unicode normalization, duplicate JSON members, aliases, redirects,
default values, path normalization, amount formatting, timezone
interpretation, recipient canonicalization, or hidden
transformations. The sink may then successfully verify a signature
while still authorizing a different semantic consequence.
The architecture therefore requires deterministic representation of
consequence-relevant fields (Section 18). The sink MUST reconstruct
the operation using the parameters that will actually be consumed by
the protected resource.
11.7. A Sink Without Consequence-Path Completeness Can Simply Be
Bypassed
+-- Finality Sink -- Database
AI Agent ----------+
+------------------- Database
bypass
Das Expires 27 March 2027 [Page 26]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
The first path may be perfectly secure. The architecture still
fails.
Any route capable of producing the same protected consequence MUST
traverse the Finality Sink, be disabled, or implement equivalent
finality enforcement. Such routes include privileged administrative
interfaces and maintenance APIs; retry workers, batch jobs, and
queues; direct database access; emergency interfaces and recovery
tools; alternate network egress; and debugging paths.
Placement of one Finality Sink does not establish finality unless
consequence-path completeness is also established (Section 25; see
also [I-D.das-consequence-path-completeness]).
11.8. A Sink Cannot Independently Decide Escalation Semantics
Escalated Conditional Finality illustrates particularly clearly why
the Finality Sink cannot stand alone. Suppose an elevated-risk
Candidate Act requires:
amount reduced to INR 100,000
specific recipient only
fresh human approval
fresh sink attestation
30-second expiration
single use
mandatory monitoring
The sink must verify these conditions. But those conditions first
have to be:
1. identified;
2. derived from policy and consequence analysis;
3. converted into a narrower RCAE;
4. represented in an EASO or equivalent execution scope;
5. bound into the Execution Handle;
6. protected against removal or expansion.
The Finality Sink's responsibility is then to refuse effectuation
unless the escalated authority matches those requirements. Escalated
finality is a technical finality mode in which stricter RCAE/EASO
scope and additional controls remain bound to the authority reaching
the Finality Sink.
Das Expires 27 March 2027 [Page 27]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
| *The Finality Sink enforces escalation; it does not by itself
| supply the entire escalation architecture.*
11.9. A Sink Without Atomicity Can Reintroduce TOCTOU
Even if every verification succeeds, the architecture can still fail
if there is an exploitable gap between the check passing and the
effect being committed:
verify beneficiary A
|
v
verification succeeds
|
v
downstream state changes
|
v
commit beneficiary B
Execution finality therefore requires the allow decision, the replay-
sensitive authority consumption, and the effectuation to be coupled
atomically or in an equivalently crash-consistent way (Section 29).
The Finality Sink MUST NOT merely return ALLOW to another untrusted
component and assume that the component performs the same act. The
sink must control, or cryptographically bind, the transition that
follows.
11.10. A Finality Sink Without Protected Upstream Evidence Becomes
Another Policy Engine
A system might place a policy service immediately before execution
and call it the Finality Sink:
request
|
v
risk score
|
v
ALLOW
|
v
executor
Das Expires 27 March 2027 [Page 28]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
That is not automatically execution finality. Ordinary policy
engines differ from sink-bound finality because a policy decision may
be ignored, become stale, be bypassed, or be separated from the
actual effectuation interface.
The distinction therefore does not depend on the name assigned to the
component. A component is functionally a Finality Sink only if it
actually controls the consequence and satisfies the required finality
properties.
12. Finality Is a System Property, Not a Box
The architecture should not be represented as:
AI
|
v
FINALITY SINK
|
v
EFFECT
That diagram is too simple. It risks creating the impression that
execution finality is merely another gateway. The fuller
architecture is:
AI / AGENT
|
v
CANDIDATE ACT
|
v
NON-EFFECTIVE STATE
|
v
PROTECTED VALIDATION
|
v
PROVENANCE / POLICY / TRUST / CONSEQUENCE ANALYSIS
|
v
RCAE
|
v
ORDINARY OR ESCALATED FINALITY DECISION
|
v
EASO / BOUNDED EXECUTION AUTHORITY
Das Expires 27 March 2027 [Page 29]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
|
v
EXECUTION HANDLE
|
v
===============================
LAST PREVENTABLE CONSEQUENCE BOUNDARY
===============================
|
v
FINALITY SINK
- reconstruct actual act
- exact-act comparison
- current-state verification
- revocation/generation check
- nonce/replay check
- sink/destination binding
- escalation-condition verification
- atomic consumption and effectuation
|
+------------------+
| |
ALLOW DENY
| |
v v
EFFECT NO EFFECT
Each part closes a different failure mode:
* The Candidate Act gives the system something stable to bind.
* The Non-Effective State prevents premature consequence.
* The RCAE defines the permitted consequence.
* The EASO converts that boundary into execution scope.
* The Execution Handle carries or enables narrowly bounded
authority.
* Protected state determines whether that authority remains valid.
* The Finality Sink independently verifies the act that is actually
about to occur.
* Atomic effectuation prevents the verified act from changing after
the check.
Das Expires 27 March 2027 [Page 30]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
* Complete mediation prevents another route from bypassing the
architecture.
The Finality Sink is therefore *necessary but not independently
sufficient*.
12.1. Functional Equivalence of Consolidated Implementations
This distinction should not be interpreted as requiring every
implementation to contain physically separate components.
A sophisticated transaction processor, secure gateway, HSM, database
commit controller, or hardware execution boundary might implement
several or all of these functions internally. For example, a single
protected component could:
construct/reconstruct Candidate Act
maintain non-effective state
hold protected policy state
verify revocation
maintain replay state
derive consequence scope
verify bounded authority
commit atomically
Such a component may be functionally equivalent to the broader
architecture. In that case, however, the component is no longer
performing only the function of a simple final policy check. It is
internally implementing the execution-finality architecture.
The correct criterion is therefore not the number of boxes in a
deployment diagram. The criterion is whether all required
architectural properties exist.
| *One physical component may implement the whole finality pipeline,
| but one final allow/deny check alone does not.*
12.2. Why This Distinction Matters
Without this distinction, execution finality could be
mischaracterized as an API gateway, a policy enforcement point, a
trust-score engine, OAuth at the final endpoint, a hardware
interlock, a transaction validator, or an authorization middleware
component.
Any of those components may participate in execution finality. Some
deployments may even become functionally equivalent if they implement
all required properties.
Das Expires 27 March 2027 [Page 31]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
But merely moving an existing authorization check closer to execution
does not establish:
* exact-act binding;
* Candidate Act continuity;
* non-effective state;
* current-state congruence;
* single-use consumption;
* escalation preservation;
* consequence-path completeness;
* atomic effectuation;
* crash-safe outcome resolution.
Execution finality is therefore an *end-to-end consequence-control
property*. The Finality Sink is where that property is finally
enforced. It is not, by itself, the entire property.
13. Enforcement Points
This section specifies nineteen enforcement points. Each enforcement
point states what a specific component must verify, hold, bind, or
refuse for the architecture in this document to hold at that
location. The first enforcement point (EP-1) is the base mechanism.
The others refine it for particular deployment situations or rule out
implementations that look similar but do not provide the same
property.
The enforcement points are informative in this -00 revision. They
are written in requirement form so that implementers and reviewers
can test conformance against each one separately. Where an
enforcement point says an implementation "does not satisfy" it, that
statement identifies a common near-equivalent that fails to provide
the property.
In this section, "policy epoch" and "revocation epoch" have the same
meaning as policy generation and revocation generation elsewhere in
this document.
13.1. Terms Used in This Section
Das Expires 27 March 2027 [Page 32]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
* Hash-Linked Candidate Act Descriptor (HL-CAD): a digest-linked
representation of a Candidate Act and the validation evidence
produced for it.
* Scoped execution authority: a scoped non-bearer finality
capability, an Execution Handle, or both, released for one
Candidate Act.
* Locked execution primitive: an operation at the Finality Sink that
cannot complete the Candidate Act without completion material.
* Completion material: the value that unlocks the locked execution
primitive. Examples are a command signature, database commit
token, payment authorization share, data-export key, network-
control authorization code, storage-write token, actuator enable
value, or model-update unlock value.
* Validation receipt: a record, committed in protected state, of the
evidence on which authority was released.
* First usable release boundary: the earliest point in an execution
path at which the Candidate Act, or any act-equivalent
representation, becomes capable of producing an external
consequence.
13.2. EP-1: Cryptographic Execution Dependency
Location: the Protected Enforcement Domain and the Finality Sink
together.
1. The Protected Enforcement Domain receives a Candidate Act
generated by an AI agent and holds it in a non-effective state in
which it cannot produce any external consequence.
2. The Protected Enforcement Domain generates an HL-CAD. The HL-CAD
binds the Candidate Act to one or more of the following: an
algorithmic-logic fingerprint result, a runtime behavioral
descriptor, an output provenance record, a factual-support
verification result, a predicted consequence representation, the
policy epoch, the revocation epoch, and a nonce.
3. The Protected Enforcement Domain determines that the Candidate
Act lies within a permitted consequence envelope defined by a
scoped non-bearer finality capability or an EASO.
Das Expires 27 March 2027 [Page 33]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
4. The Protected Enforcement Domain commits a validation receipt
bound to the HL-CAD, the permitted consequence envelope, both
epochs, the nonce, and the Finality Sink identity. This happens
before, or atomically with, release of scoped execution
authority.
5. Scoped execution authority is released only after that receipt
exists in protected state. The authority is bound to the
Candidate Act, the Finality Sink identity, both epochs, and the
nonce.
6. The Finality Sink holds a locked execution primitive that cannot
complete the Candidate Act without completion material derived
from the scoped execution authority.
7. The Finality Sink releases completion material only after
verifying that the authority corresponds cryptographically to the
Candidate Act, its own identity, both current epochs, and the
nonce. The Candidate Act then becomes effective only within the
permitted consequence envelope.
13.3. EP-2: Threshold-Shared Execution Material
Location: the Finality Sink and two or more distinct protected
components.
* The execution material needed to complete the Candidate Act is
divided into cryptographic shares held by distinct protected
components.
* Each share is independently bound to the Candidate Act digest,
both epochs, the nonce, and the Finality Sink identity.
* The Finality Sink combines the material only after receiving a
threshold number of valid shares within a bounded time window.
Each share must match the scope, carry current epochs, and use a
fresh nonce.
* No single protected component, AI agent, or ordinary software
process ever holds complete execution authority.
13.4. EP-3: Commitment-Release Temporal Escrow
Location: the Protected Enforcement Domain and the Finality Sink, for
high-latency or delayed effectuation (Section 30).
Das Expires 27 March 2027 [Page 34]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
* A Commitment Token binds the Candidate Act to the Finality Sink
identity, the EASO, both epochs, the nonce, and the validation
receipt. It stages the act in a non-effective escrow state and
cannot cause effectuation without a matching Release Token.
* Any staged-status indicator sent upstream is explicitly non-final.
It does not constitute effectuation and does not satisfy any
downstream execution dependency.
* After a defined confirmation window, a current-state re-
verification takes place. It covers at least the policy epoch,
the revocation epoch, Finality Sink attestation, and the absence
of revocation.
* A Release Token bound to the Commitment Token is generated only if
every re-verification succeeds. If any check fails first, the
Commitment Token is destroyed and no Release Token is generated.
13.5. EP-4: Paired Forward and Rollback Authority
Location: the Protected Enforcement Domain and a protected escrow
outside the agent execution path.
* Atomically with the Commitment Token (EP-3), a paired authority
set is generated. The forward authority permits limited
effectuation within the permitted scope. The rollback authority
permits bounded reversal of that effectuation.
* Both authorities are bound to the same Candidate Act digest, EASO
digest, receipt identifier, Finality Sink identity, nonce, and
epochs.
* The rollback authority is held in protected escrow, outside the
ordinary agent execution path.
* A post-effectuation monitoring window evaluates conditions such as
source revocation, policy update, revocation-epoch advancement,
sink-trust degradation, canary failure, and contradiction evidence
(Section 41).
* If a monitored failure occurs within the window, the rollback
authority is released to the Finality Sink for bounded reversal.
Otherwise, it is destroyed or archived when the window expires.
13.6. EP-5: Ephemeral Finality Sink
Location: a temporary execution environment acting as the Finality
Sink.
Das Expires 27 March 2027 [Page 35]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
* The Finality Sink is provisioned as a single-use environment bound
to exactly one validated Candidate Act.
* It holds only the minimum credentials, permissions, policy state,
recipient scope, data scope, tool scope, time window, and
execution primitive that the act requires.
* After completion, refusal, rollback, timeout, or expiry, it
destroys itself. It deletes temporary credentials, clears nonce
state, invalidates session keys, and erases transient execution
material.
* A copied authority object therefore cannot be replayed anywhere,
because the original sink identity, nonce, and attested execution
context no longer exist.
13.7. EP-6: Proxy Enforcement for Legacy Interfaces
Location: a protected proxy placed immediately before an existing
effectuation interface (Section 33.1).
* The proxy intercepts Candidate Acts, tool calls, transaction
requests, database mutations, data-export requests, or command
messages directed at the interface.
* It verifies at least the following: the Candidate Act digest, the
scoped execution authority, the nonce, expiry, both epochs, EASO
scope, Finality Sink identity, and the validation receipt
reference.
* On success, it translates the verified act into a conventional
request that the existing interface accepts. On failure, it
forwards nothing.
* The existing interface therefore receives only enforced requests,
without needing to parse HL-CAD, EASO, or Execution Handle
formats.
13.8. EP-7: Modular Escalation Enforcement
Location: the Protected Enforcement Domain and its escalation
modules, for escalated-but-allowable acts (Section 8).
* A Candidate Act is classified as escalated-but-allowable when it
presents elevated risk that does not require denial and can be
reduced to a permitted scope by additional controls.
Das Expires 27 March 2027 [Page 36]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
* The act is routed to independent protected escalation modules.
Each module produces a machine-verifiable result bound to the
Candidate Act digest, the HL-CAD digest, both epochs, the nonce,
the module identity, and the Finality Sink identity.
* The EASO names which module results are mandatory.
* Escalated authority is released only when every mandatory result
is present, valid, non-stale, non-revoked, epoch-current, and
bound to the same act and current state.
* The selected controls are bound into the escalated authority. The
Finality Sink rejects the escalated Execution Handle if any
mandatory result is absent, stale, revoked, or epoch-mismatched.
13.9. EP-8: Receipt as a Release Predicate
Location: the Protected Enforcement Domain's receipt store and the
Finality Sink.
* Receipt state is committed to a protected receipt store before
authority is generated. Suitable stores include an append-only
log, a hash chain, a Merkle-committed structure, a hardware-
protected log, a signed receipt object, an HSM-backed counter, or
secure-enclave state.
* The Finality Sink treats the receipt identifier, receipt digest,
or state proof as a required verification input.
* The Finality Sink refuses effectuation if the receipt does not
correspond to the Candidate Act, the authority, the nonce, both
epochs, and its own identity.
* The receipt is therefore part of the release path, not a record
appended afterwards (Section 39).
13.10. EP-9: Assurance Profile with Anti-Downgrade Binding
Location: the Protected Enforcement Domain, which selects the
profile, and the Finality Sink, which applies it (Section 32).
* The Protected Enforcement Domain selects one of at least three
assurance profiles.
* Low assurance: digest matching, nonce, scope, and epoch checks.
Das Expires 27 March 2027 [Page 37]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
* Medium assurance: the low checks plus a receipt reference, a
protected approval reference, the consequence-envelope digest, and
sink attestation.
* High assurance: the medium checks plus one or more of Execution
Handle verification, state-proof verification, hardware identity
binding, locked-primitive completion, rollback escrow, or multi-
sink threshold verification.
* Selection depends on one or more of: risk class, consequence type,
data classification, jurisdiction, financial value, reversibility,
escalation score, and current sink trust state.
* The selected profile is bound into the released authority. The
Finality Sink cannot silently apply a lower verification level
than the one bound there.
13.11. EP-10: Adversarial Perturbation Gate
Location: an escalation module within EP-7.
* As a mandatory escalation result, the module runs a bounded set of
parameterized perturbations against the Candidate Act's
consequence model. These are small variations in recipient,
amount, jurisdiction, or data class.
* If any perturbation within the tested radius crosses into a
prohibited consequence class, the EASO is tightened to exclude
that neighborhood, or the act is reclassified for denial.
* The receipt records the perturbation-set identity, the tested
radius, and the distance to the nearest prohibited neighbor.
* Escalated authority is released only when no tested perturbation
reaches a prohibited class. The released authority is thus
bounded away from prohibited consequence space by an attested
margin.
13.12. EP-11: Consequence-Class Inheritance Ceiling
Location: every Protected Enforcement Domain in an agent chain
(Section 22, Section 40).
* A Consequence-Class Inheritance Tag is bound into the released
authority. It carries the maximum consequence class authorized at
the originating decision.
Das Expires 27 March 2027 [Page 38]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
* When a downstream agent produces a Candidate Act derived from the
output of the effectuated act, the tag is supplied to the
enforcement domain that evaluates the downstream act.
* The downstream act's permitted class never exceeds the inherited
ceiling, whatever broader envelope the downstream agent would
otherwise have. Authority for any downstream act predicted to
exceed the ceiling is refused.
* The ceiling narrows monotonically across hops (invariant I5).
13.13. EP-12: Protected Hardware Finality Sink
Location: the Finality Sink, or a module adjacent to it, implemented
in protected hardware.
* Suitable hardware includes an HSM, secure enclave, TEE, secure
element, SmartNIC, DPU, firmware-protected controller, database or
storage commit controller, network processor, payment-security
module, or protected microcontroller.
* The hardware verifies compact finality artifacts: the Candidate
Act digest, the scoped authority, the Execution Handle, the
receipt digest, the nonce, both epochs, the EASO digest, and the
sink identity.
* The hardware releases completion material only on successful
verification.
* Ordinary application software cannot extract the completion
material, or cause effectuation, without valid authority verified
by the hardware.
13.14. EP-13: Isolation of the Enforcement Domain from the Agent
Location: the boundary between the AI agent and the Protected
Enforcement Domain.
* The Protected Enforcement Domain runs in an isolated boundary,
separate from the agent's process, memory, container, virtual
machine, and software trust boundary.
* Through any instruction, system call, memory access, IPC, shared
memory, or network request available to it, the agent cannot read,
modify, suppress, bypass, forge, or replay any of the following:
validation logic, receipt state, nonce state, counters, epochs,
capability material, Handle material, or the release mechanism.
Das Expires 27 March 2027 [Page 39]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
* An enforcement domain that runs in the same process, memory space,
container, serverless invocation, or software trust boundary as
the agent does not satisfy this enforcement point.
* Isolation is evidenced by hardware, enclave, TEE, HSM, or
microcontroller attestation bound into the Execution Handle. The
Finality Sink refuses to assemble completion material if the
attested enforcement-domain identity differs from the identity
bound at minting.
13.15. EP-14: Structural Incompleteness versus Software Tokens
Location: the Finality Sink's locked execution primitive (EP-1, EP-
12).
* Completion material is derived, held, or released only inside a
protected boundary. It cannot be extracted by software
instruction, operating-system call, hypervisor operation, cloud
management interface, key-management API, or any privileged
process, whatever that process's privilege level.
* Does not satisfy: a primitive whose completion material sits in a
key-management service, secrets store, cloud-managed key,
software-accessible memory, or any location reachable by a
sufficiently privileged process. Such material can be assembled
without satisfying the finality predicates.
* Assembly succeeds only as a direct result of authority from a
protected finality transaction with matching act digest, epochs,
nonce, and sink identity. It fails for a copied software token, a
replayed encrypted payload, a cloud-managed decryption artifact,
or any other artifact.
13.16. EP-15: Receipt-Bound Release versus Post-Effectuation Logging
Location: the receipt store and authority release mechanism (EP-8).
* Any required record is committed in protected state before, or
within the same hardware-enforced atomic operation as, authority
release. Such records include a validation receipt, residual-risk
receipt, state proof, escalation record, rollback record, sink-
verification record, or effectuation record.
* Neither receipt commitment nor authority release can be completed,
reversed, suppressed, or extracted independently of the other by
any software process.
Das Expires 27 March 2027 [Page 40]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
* Does not satisfy: a receipt written in an ordinary database
transaction, message queue, software log, cloud audit service,
observability pipeline, or compliance record. Each of these can
be aborted, rolled back, suppressed, or written after release.
* Does not satisfy: a system that releases authority first and then
logs the release. This remains an audit artifact, however tamper-
evident the log is.
* Satisfied only when the Finality Sink can confirm, at presentation
time, that a receipt with the bound identifier exists in protected
state and matches the presented authority. The match covers the
act digest, EASO digest, RCAE digest, nonce, epochs, and sink
identity. Authority without a committed receipt fails, and so
does a receipt whose parameters diverged after minting.
13.17. EP-16: Candidate-Act Authority versus Ordinary Permission Checks
Location: the Finality Sink (Section 6, Section 1.1).
The scoped execution authority differs from access-control decisions,
bearer tokens, OAuth-style grants, API-key checks, RBAC or ABAC
decisions, policy-engine approvals, guardrail or moderation results,
trust or risk scores, and workflow approvals. It is distinguished by
four requirements:
* It is bound, through the HL-CAD, to the specific AI-generated
output that was evaluated. It is invalid for any other output,
even one from the same model, workflow, or authorized agent.
* It is bound to the specific sink and attested sink hardware, and
to the epochs and nonce current at the finality transaction. It
is invalid at any other sink, under earlier epochs, or after nonce
expiry.
* It is generated only after machine-verifiable predicates are
satisfied. These include logic-state validation, consequence
simulation within the envelope, and receipt commitment.
* It is verified by the Finality Sink as a condition of completion-
material assembly.
Does not satisfy: a system that verifies only that the requester may
invoke an interface. Such a system answers whether the requester may
act, not whether this specific Candidate Act may become this specific
consequence at this sink under current state.
Das Expires 27 March 2027 [Page 41]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
13.18. EP-17: First Usable Release Boundary
Location: wherever the first usable release boundary actually lies
(Section 11.7, Section 25).
* The boundary is identified by a component's functional capability
to convert the Candidate Act into an external consequence. Its
name, label, vendor classification, or technology is irrelevant.
* The requirements of EP-1 apply at that boundary, whatever form it
takes. It may be a proxy, API gateway, service-mesh sidecar,
broker interceptor, database proxy, workflow controller, tool
dispatcher, payment adapter, storage gateway, network-control
proxy, orchestrator, plugin manager, agent runtime, serverless
function, or container sidecar.
* A component cannot opt out by describing itself as pass-through,
transparent, routing, load balancing, protocol translation, or
middleware, if it can produce the consequence through any path
available to it.
* Upstream components that only validate, score, classify, moderate,
log, monitor, or route do not satisfy this enforcement point.
Several partial upstream checks in sequence also do not satisfy
it, because an act-equivalent representation may reach the
effectuation interface by a path that skips some of them. The
authority must be verified at the first usable release boundary
itself.
13.19. EP-18: Fragmented, Transformed, and Delegated Act Equivalence
Location: the Protected Enforcement Domain and the Finality Sink
(Section 23.1, Section 40).
* Any representation of an AI-generated output that can produce the
same or substantially similar consequence is treated as a
Candidate Act. This includes fragmented, delegated, serialized,
batched, scheduled, compressed, encrypted, translated, summarized,
paraphrased, or split forms, wherever and whenever the
transformation occurs.
* Splitting an act into smaller acts that each fall below a
threshold does not remove it from scope. The Protected
Enforcement Domain evaluates the cumulative consequence of related
acts. Acts are related if they share HL-CAD references,
recipients, purposes, sinks, policy contexts, or temporal
proximity.
Das Expires 27 March 2027 [Page 42]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
* Delegating execution to another agent, tool, plugin, workflow,
scheduled job, or service does not remove it from scope. The
Inheritance Tag (EP-11) propagates to the delegated act.
* Changing format, encoding, protocol, transport, or data structure
between the Protected Enforcement Domain and the Finality Sink
does not remove it from scope. Scope follows the consequence-
producing capability at the sink.
13.20. EP-19: Emergency, Maintenance, and Fallback Path Closure
Location: every path able to reach a Finality Sink or produce the
consequence (Section 42, Section 23.7).
* EP-1 applies on every such path. This includes emergency,
maintenance, break-glass, fallback, disaster-recovery, degraded-
mode, retry, debugging, management-plane, administrative-override,
and privileged-access paths.
* Does not satisfy: enforcing finality on ordinary paths while any
such path can produce the consequence without verified authority.
* A degraded, emergency, or maintenance mode that permits
consequences satisfies this enforcement point only if it is
governed by its own protected finality workflow. That workflow
must produce mode-specific authority bound to the act, the mode,
the sink, both current epochs, and a fresh nonce, verified by the
sink.
* Fail-open behavior does not satisfy this enforcement point. Fail-
open means allowing effectuation because evidence, authority,
Handle, receipt, epoch currency, nonce freshness, sink
attestation, or completion material is absent, unavailable, stale,
invalid, or mismatched. The correct responses are non-
effectuation, reduced-scope effectuation under a fail-limited
mode, or protected review.
13.21. Enforcement-Point Summary
+=======+====================+===============+=====================+
| EP | Enforcement point | Primary | Related section |
| | | location | |
+=======+====================+===============+=====================+
| EP-1 | Cryptographic | PED and | Architectural |
| | execution | Finality Sink | Invariant |
| | dependency | | |
+-------+--------------------+---------------+---------------------+
| EP-2 | Threshold-shared | Sink and | Security Model |
Das Expires 27 March 2027 [Page 43]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
| | execution material | share holders | |
+-------+--------------------+---------------+---------------------+
| EP-3 | Commitment-release | PED and sink | High-Latency |
| | temporal escrow | | Effectuation |
+-------+--------------------+---------------+---------------------+
| EP-4 | Paired forward and | PED and | Operational |
| | rollback authority | protected | Monitoring |
| | | escrow | |
+-------+--------------------+---------------+---------------------+
| EP-5 | Ephemeral Finality | Single-use | Replay |
| | Sink | sink | |
+-------+--------------------+---------------+---------------------+
| EP-6 | Proxy enforcement | Sink-adjacent | Legacy-System |
| | for legacy | proxy | Deployment |
| | interfaces | | |
+-------+--------------------+---------------+---------------------+
| EP-7 | Modular escalation | PED | Escalation Workflow |
| | enforcement | escalation | |
| | | modules | |
+-------+--------------------+---------------+---------------------+
| EP-8 | Receipt as release | Receipt store | Receipts and |
| | predicate | and sink | Evidence |
+-------+--------------------+---------------+---------------------+
| EP-9 | Assurance profile | PED and sink | Latency |
| | anti-downgrade | | Proportional |
+-------+--------------------+---------------+---------------------+
| EP-10 | Adversarial | Escalation | Escalation Controls |
| | perturbation gate | module | |
+-------+--------------------+---------------+---------------------+
| EP-11 | Inheritance | PEDs in agent | Escalation |
| | ceiling | chain | Laundering |
+-------+--------------------+---------------+---------------------+
| EP-12 | Protected hardware | Hardware sink | Finality Sink |
| | sink | | Compromise |
+-------+--------------------+---------------+---------------------+
| EP-13 | Enforcement-domain | Agent/PED | Security Model |
| | isolation | boundary | |
+-------+--------------------+---------------+---------------------+
| EP-14 | Structural | Locked | Finality Sink |
| | incompleteness | primitive | |
+-------+--------------------+---------------+---------------------+
| EP-15 | Receipt-bound | Receipt and | Atomicity |
| | release, not | release | |
| | logging | | |
+-------+--------------------+---------------+---------------------+
| EP-16 | Act authority, not | Finality Sink | Conventional |
| | permission check | | Solutions |
+-------+--------------------+---------------+---------------------+
Das Expires 27 March 2027 [Page 44]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
| EP-17 | First usable | Actual | Finality-Sink |
| | release boundary | release point | Bypass |
+-------+--------------------+---------------+---------------------+
| EP-18 | Fragmented and | PED and sink | Escalation-Specific |
| | delegated | | Attacks |
| | equivalence | | |
+-------+--------------------+---------------+---------------------+
| EP-19 | Emergency and | All | Fail-Closed |
| | fallback path | consequence | Behavior |
| | closure | paths | |
+-------+--------------------+---------------+---------------------+
Table 2
14. Threat Model
The architecture assumes that the AI agent, upstream application,
workflow, network path, queue, intermediary service, or other non-
protected component may be mistaken, compromised, malicious, stale,
or inconsistent.
The Finality Sink and protected finality state are security-critical
components. The threat model therefore does not assume that a valid
identity implies a valid consequence.
14.1. Protected Assets
The primary protected asset is the integrity of the final
consequence. Associated assets include:
* Candidate Act integrity;
* protected authorization state and revocation state;
* policy generations;
* nonce and replay state;
* Finality Sink identity and sink attestation state;
* protected approval evidence;
* receipt state and completion material;
* private keys and MAC keys.
Das Expires 27 March 2027 [Page 45]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
14.2. Potential Adversaries
Relevant adversaries include:
* a compromised AI agent;
* malicious tool code or a malicious plugin;
* compromised application middleware;
* an attacker possessing stolen credentials;
* a compromised queue worker;
* a privileged insider;
* a network attacker;
* a compromised downstream service;
* an attacker controlling stale backups;
* an attacker attempting to bypass the Finality Sink;
* an attacker attempting denial of service against verification.
14.3. Security Objective
| *No attacker should be able to convert possession, upstream
| approval, stale authority, alternate routing, representation
| ambiguity, or software compromise into an unauthorized protected
| consequence without satisfying the required finality conditions at
| an equivalent effectuation boundary.*
15. Security Model
This section states the assumptions under which the properties in
Section 44 are claimed, and what the model deliberately excludes.
15.1. Trust Assumptions
* A1 (Protected state): generations, consume records, approval
records, and aggregate counters in protected state have integrity
and are monotonic; they cannot be rolled back (Section 21).
* A2 (Sink): the Finality Sink correctly implements verification.
It, or a functionally equivalent enforcement point, is the only
component able to produce the protected consequence.
Das Expires 27 March 2027 [Page 46]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
* A3 (Cryptography): digests are collision resistant, and signatures
or MACs are existentially unforgeable.
* A4 (Paths): consequence-path completeness holds for the protected
consequence class.
* A5 (Time): the clock skew between issuer and sink is bounded by a
stated value d.
* A6 (Policy): the escalation policy selects appropriate controls
for each class. This architecture enforces A6; it does not verify
it.
15.2. Adversary Capabilities
The adversary may do the following:
* control the agent, tool code, and untrusted middleware;
* read, modify, drop, delay, reorder, and replay network messages;
* submit arbitrary Candidate Acts and observe decisions;
* obtain valid Execution Handles issued to other principals.
The adversary cannot forge Protected Enforcement Domain keys, roll
back protected monotonic state, or modify the sink's trusted
computing base. Sink compromise is treated separately (Section 26).
15.3. Invariants
A conforming deployment maintains the following invariants:
* I1 (Non-effectiveness): no protected effect occurs for act a
unless the sink recorded ALLOW for a.
* I2 (Exact act): ALLOW under Handle h requires that the digest of
the sink-reconstructed act equals the act digest bound in h.
* I3 (Currentness): ALLOW requires that the policy and revocation
generations bound in h equal those in protected state, read inside
the atomic commit section.
* I4 (Consumption): the number of effects produced under h never
exceeds the permitted-use count of h.
Das Expires 27 March 2027 [Page 47]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
* I5 (Escalation monotonicity): derived or delegated authority is
never less strict than its parent. Its scope is a subset of the
parent's scope, and its class is at least as strict.
* I6 (Fail-safe classification): if classification is unavailable,
times out, or is indeterminate, the act receives an escalated or
deny class, never the ordinary class.
* I7 (Aggregate bound): the total effect produced over a window W
for a given principal, recipient, or purpose never exceeds the
ceiling defined for that class.
15.4. Informal Bound
Under A1-A5, the probability that an unauthorized protected effect
occurs on a covered path is bounded by the sum of four terms:
Pr[unauthorized effect] <= e_hash + e_sig + e_store + e_path
* e_hash: collision probability of the act digest.
* e_sig: forgery probability of the authority object.
* e_store: probability of a protected-state integrity failure.
* e_path: probability that an uncovered consequence path exists.
This bound is consistent with the one given for Execution Handles in
[I-D.das-execution-handle]. It is informal and is not a proof.
15.5. Outside the Model
The model does not cover the correctness of the escalation policy
(A6), compromise of the Finality Sink or hardware trust roots, side
channels, or availability guarantees. These are discussed in
Section 26, Section 42, and Section 49.
16. Principal Threats
+==================+======================+========================+
| Threat | Example | Required architectural |
| | | response |
+==================+======================+========================+
| Parameter | beneficiary changed | exact-act binding |
| substitution | after approval | |
+------------------+----------------------+------------------------+
| Destination | approved SEND | destination binding |
| substitution | redirected elsewhere | |
Das Expires 27 March 2027 [Page 48]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
+------------------+----------------------+------------------------+
| Replay | valid Execution | nonce and single-use |
| | Handle reused | consumption |
+------------------+----------------------+------------------------+
| Stale authority | policy revoked after | generation/epoch |
| | approval | revalidation |
+------------------+----------------------+------------------------+
| TOCTOU | state changes after | check-and-commit |
| | validation | coupling |
+------------------+----------------------+------------------------+
| Escalation | restricted authority | escalation inheritance |
| laundering | becomes ordinary | |
| | downstream | |
+------------------+----------------------+------------------------+
| Alternate-path | direct database/API | consequence-path |
| bypass | route avoids | completeness |
| | Finality Sink | |
+------------------+----------------------+------------------------+
| Sink | Handle moved to | sink identity binding |
| substitution | another executor | |
+------------------+----------------------+------------------------+
| Snapshot | old replay/ | monotonic/rollback- |
| rollback | revocation state | resistant state |
| | restored | |
+------------------+----------------------+------------------------+
| Canonicalization | signer and executor | deterministic |
| ambiguity | interpret fields | representation |
| | differently | |
+------------------+----------------------+------------------------+
| Approval replay | old human approval | act-specific protected |
| | reused | approval |
+------------------+----------------------+------------------------+
| Counter | restored counter | monotonic protected |
| regression | makes stale Handle | counters |
| | valid | |
+------------------+----------------------+------------------------+
| Capability theft | attacker copies | non-bearer/sink-bound |
| | authority object | authority |
+------------------+----------------------+------------------------+
| Verification | flood expensive | admission control and |
| exhaustion | crypto path | rate limits |
+------------------+----------------------+------------------------+
| Sink compromise | Finality Sink | TCB minimization, |
| | modified | attestation, isolation |
+------------------+----------------------+------------------------+
| Crash ambiguity | unknown whether | durable state and |
| | external act | reconciliation |
| | completed | |
Das Expires 27 March 2027 [Page 49]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
+------------------+----------------------+------------------------+
| Threshold | large act split into | aggregate ceilings |
| fragmentation | sub-threshold acts | |
+------------------+----------------------+------------------------+
| Classification | risk-engine timeout | fail to stricter class |
| fail-open | treated as ordinary | |
+------------------+----------------------+------------------------+
| Resubmission | retry until | sticky per-intent |
| until favorable | classifier says | classification |
| | ordinary | |
+------------------+----------------------+------------------------+
| Reviewer | flood of escalations | escalation budgets, no |
| exhaustion | to human approvers | batch approval |
+------------------+----------------------+------------------------+
Table 3
17. Exact-Act Substitution
An attacker may alter one or more consequence-relevant fields after
authorization. Examples include amount, recipient, account, object,
resource, destination, tool, operation, content, jurisdiction,
purpose, visibility, permission, and actuator target.
The binding representation MUST therefore cover every field capable
of materially affecting consequence.
A Finality Sink SHOULD reconstruct the actual operation using the
values that will actually reach the protected resource. It MUST NOT
rely solely on an upstream serialized representation if the
downstream execution semantics can differ.
18. Canonicalization Ambiguity
Canonicalization is a security boundary. Suppose:
Verifier interprets:
"user": "admin "
Executor interprets:
"user": "admin"
Two implementations may also disagree about Unicode normalization,
duplicate JSON keys, number encodings, case folding, URL
normalization, path aliases, redirects, default values, CBOR map
ordering, unknown fields, or time zones.
Das Expires 27 March 2027 [Page 50]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
A signature can be cryptographically valid while the signer and
executor interpret different semantic acts. An interoperable
finality profile therefore needs to define:
deterministic representation
mandatory covered fields
duplicate-field behavior
unknown-field behavior
normalization rules
numeric representation
time representation
semantic version
Ambiguous representations SHOULD fail closed.
19. Replay and Single-Use Authority
A legitimate Execution Handle may itself become an attack artifact if
it can be replayed. High-impact authority SHOULD therefore be
bounded using some combination of a nonce, unique execution
identifier, expiration, sink identity, generation, counter,
permitted-use count, and Candidate Act digest.
For single-use operations, authority consumption MUST be concurrency
safe. Two simultaneous presentations of the same authority MUST NOT
result in two consequences.
20. Revocation and Generation Fencing
Revocation must remain effective at the execution boundary
[I-D.das-finality-bound-revocation]. Suppose a system revokes
authority centrally but permits a Finality Sink to keep operating
from indefinitely stale cached state. That system does not provide
strong current-state execution finality.
A practical mechanism is generation fencing:
Execution Handle:
policy_generation = 44
revocation_generation = 91
Current protected state:
policy_generation = 45
revocation_generation = 92
Result:
DENY
Das Expires 27 March 2027 [Page 51]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
This avoids relying solely on the expiration time of an old token.
21. Snapshot Rollback
Protected storage can itself become stale. Suppose a valid Handle
was consumed and the system recorded consumed = TRUE. An attacker
then restores an older snapshot containing consumed = FALSE. The
authority has effectively been resurrected.
The architecture therefore needs to consider rollback-resistant
mechanisms such as monotonic counters, generation fencing, hardware-
backed monotonic state, externally anchored state, append-only
protected journals, rollback detection, and replicated generation
authorities.
Backup restoration MUST NOT silently restore authorization validity.
22. Escalation Laundering
Escalated authority must not become broader as it passes through an
agent chain:
Agent A:
allowed only to SEND redacted document
|
v
Agent B receives result
|
v
Agent B attempts:
SEND full document
The original restricted authority MUST NOT be interpreted as generic
approval. This document uses consequence-class inheritance in
downstream chains, so that escalation can narrow downstream authority
but never silently expand it.
A later component may impose stricter controls, smaller scope, more
approval, or a lower consequence class, but MUST NOT silently
increase the permitted consequence.
23. Escalation-Specific Attacks
Graduated release creates attacks that do not exist in a binary
allow/deny system, because the attacker's goal becomes landing in a
less strict class.
Das Expires 27 March 2027 [Page 52]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
23.1. Threshold Fragmentation
An attacker may split one escalated act into several ordinary ones.
For example, INR 5,000,000 can become eleven transfers of INR
490,000, each below the ordinary threshold.
Classification SHOULD therefore consider aggregate exposure, not only
the single act. Aggregate ceilings per principal, recipient,
purpose, and time window (invariant I7) SHOULD be kept in protected
state and checked inside the atomic commit section. Decomposition
across multiple principals or purposes remains open (Section 49).
23.2. Classification Downgrade and Fail-Open
A classic failure is to treat a risk-engine timeout or error as
ordinary release. Classification MUST fail to a stricter class
(invariant I6).
An attacker may also relabel classification inputs, such as purpose,
recipient category, or data class, to reach a lower class. Every
input that influenced the classification SHOULD be part of the
Candidate Act digest, so that a relabel invalidates the authority.
23.3. Resubmission Until Favorable
Where the classifier is non-deterministic (for example, model-based),
an attacker may resubmit an escalated or denied act until it is
classified as ordinary.
Decisions SHOULD therefore be sticky per intent identifier for a
defined window. A later submission of the same or an equivalent
intent MUST NOT receive a less strict class than an earlier one in
that window.
23.4. Parallel Authority for the Same Act
An attacker may obtain an escalated Handle and, through another path
or with slightly altered parameters, an ordinary Handle for the same
intent.
At most one live authority SHOULD exist per intent identifier.
Issuing escalated authority supersedes any ordinary authority for the
same intent.
Das Expires 27 March 2027 [Page 53]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
23.5. Classifier Probing
Observable decisions let an attacker map classification thresholds.
External error responses SHOULD be coarse, and probing SHOULD be rate
limited. Derived ceilings SHOULD NOT be disclosed to the requester
beyond what execution requires.
23.6. Approval Fatigue and Reviewer Exhaustion
Flooding a system with escalations can exhaust human reviewers. This
can lead either to rubber-stamp approval or to denial of service for
legitimate escalations.
Profiles SHOULD define per-principal escalation budgets. Approval
interfaces SHOULD present the sink-reconstructed act rather than an
agent-supplied preview. High-consequence classes SHOULD NOT permit
batch approval.
23.7. Emergency-Override Abuse
Break-glass authority is itself an escalation path. It SHOULD be
bounded in scope, time, and use count, require dual control, always
produce a receipt, and trigger mandatory post-event review
(Section 42).
24. Human-Approval Bypass
Ordinary human approval can be vulnerable to stale approval, approval
of the wrong object, clickjacking or UI substitution, replayed
workflow events, synthetic button presses, and approval of a preview
different from the final effect.
Where protected approval is required, it SHOULD be bound to the
relevant Candidate Act and consequence:
approved act digest
approved recipient
approved amount
approver identity/role
approval timestamp
policy generation
revocation generation
Finality Sink
expiry
Approval of INR 10,000 -> A MUST NOT authorize INR 100,000 -> B.
Das Expires 27 March 2027 [Page 54]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
25. Finality-Sink Bypass
Complete mediation is essential. Suppose the protected path is:
AI
|
v
Finality Sink
|
v
Database
but the AI can also reach the database through a direct connection.
Then the claimed finality property does not hold.
Every path capable of generating an act-equivalent protected
consequence MUST be disabled, pass through the Finality Sink, or
enforce functionally equivalent verification. This includes
administrative APIs and maintenance interfaces; batch jobs, retry
workers, and queues; direct storage access; fallback paths and debug
interfaces; alternate network egress; and recovery tools.
Alternate paths capable of completing the same consequence are
treated as equivalent effectuation boundaries requiring the same
protection [I-D.das-consequence-path-completeness].
26. Finality Sink Compromise
The Finality Sink is a high-value security target. Compromise could
permit an attacker to forge successful verification, ignore
revocation, accept replay, substitute a destination, issue misleading
receipts, expose completion material, or bypass escalation controls.
Deployments SHOULD minimize the trusted computing base surrounding
the sink. Possible hardening mechanisms include:
* hardware isolation and TEE execution;
* HSM-assisted key handling;
* secure boot and measured boot;
* remote attestation;
* protected state;
* separate administrative authority;
Das Expires 27 March 2027 [Page 55]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
* tamper-evident logs;
* version rollback protection;
* limited management interfaces.
Attestation does not itself establish execution finality. It may
provide evidence that the component expected to enforce finality is
in an approved state.
27. Verification Exhaustion and Denial of Service
Finality verification can require expensive operations. An attacker
might intentionally submit invalid Candidate Acts requiring signature
verification, attestation processing, state lookups, simulation,
receipt validation, or cryptographic reconstruction.
If all work is performed before admission controls, the Finality Sink
itself can become a denial-of-service target. Implementations SHOULD
therefore place inexpensive defenses before expensive verification,
such as rate limiting, admission control, per-principal quotas,
request-shape validation, cheap syntax rejection, proof-of-work where
appropriate, resource budgets, queue isolation, priority classes, and
circuit breaking.
However:
| *Early filtering MUST NOT replace the final protected
| verification.*
28. Crash Consistency and Ambiguous Outcomes
An external consequence may not be naturally transactional. A
payment instruction, SEND operation, network command, or physical
actuation may cross a boundary after which rollback is impossible.
The architecture needs to distinguish outcomes such as:
NOT COMMITTED
COMMITTED
DENIED
INDETERMINATE
An indeterminate high-impact consequence MUST NOT automatically be
retried where retry could duplicate the effect. Durable receipts and
transaction identifiers can assist recovery.
Das Expires 27 March 2027 [Page 56]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
29. Atomicity
The strongest local form of execution finality couples current-state
validation, authority consumption, and effectuation into an atomic or
equivalent crash-consistent transition.
Where true atomicity is impossible, the deployment needs an explicit
state machine with unambiguous recovery semantics:
PREPARED
|
v
AUTHORITY RESERVED
|
v
COMMIT REQUESTED
|
v
COMMITTED
Receipt generation, nonce/counter updates, policy/revocation
checking, and Execution Handle release may likewise participate in a
protected atomic finality transaction.
30. High-Latency Effectuation
Some Finality Sinks inherently operate with substantial delay.
Examples include cross-border settlement, remote infrastructure,
satellite systems, industrial scheduling, batch processing, and
multi-party approval.
In these cases, authorization at T1 SHOULD NOT automatically cause
effectuation at T2. A commitment/release model can be used:
Das Expires 27 March 2027 [Page 57]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
ESCALATION VALIDATION
|
v
COMMITMENT TOKEN
|
v
Candidate Act reserved but NON-EFFECTIVE
|
v
waiting interval
|
v
current-state revalidation
|
v
RELEASE TOKEN
|
v
Finality Sink
|
v
EFFECT
The commitment object reserves state. It does not itself authorize
the external consequence.
31. Latency Considerations
Execution-finality architecture adds work. The correct engineering
comparison, however, is not "execution finality versus zero latency".
It is:
| *Bounded verification cost versus the cost of an unauthorized
| high-consequence effect.*
The architecture uses a latency-aware decomposition into cold,
nearline/warm, and hot finality paths. Heavy simulation and
validation do not all need to occur at sink-side effectuation time.
31.1. Cold Preparation Path
Operations that are reusable or time-tolerant SHOULD occur outside
the per-act execution path:
Das Expires 27 March 2027 [Page 58]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
model/workflow approval
policy compilation
source registration
sink registration
RCAE templates
EASO templates
cryptographic provisioning
attestation baselines
escalation profile compilation
31.2. Warm / Nearline Path
Once a Candidate Act exists, act-specific work can begin before final
effectuation:
Candidate Act formation
provenance construction
behavioral evidence evaluation
factual verification
consequence simulation
RCAE selection
escalation classification
protected approval
receipt preparation
Execution Handle preparation
31.3. Hot Finality Path
The Finality Sink SHOULD perform only the checks that must be current
at effectuation time:
Candidate Act digest
Execution Handle authenticity
sink identity
expiration
nonce
revocation generation
policy generation
current attestation
replay state
scope
recipient/destination
atomic authority consumption
The architecture therefore does not require running full AI
reasoning, full consequence simulation, or complete provenance
analysis inside the critical sink path.
Das Expires 27 March 2027 [Page 59]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
31.4. Latency Budget Model
The per-act latency can be decomposed as:
T_act = T_warm + T_approval + T_hot
* Cold-path cost is amortized across many acts.
* T_hot is approximately constant. It consists of one digest over
the Candidate Act, one signature or MAC verification, a small
number of protected-state reads, and one compare-and-swap
consumption.
* For ordinary acts, T_approval is zero.
* For escalated acts, T_approval is normally dominated by human or
multi-party approval, measured in seconds to minutes, not by
cryptography.
Escalation latency is therefore primarily an organizational cost.
Profiles SHOULD state which consequence classes permit a human in the
loop and what approval latency is acceptable.
31.5. Freshness, Staleness Windows, and Clocks
A sink may cache generation state with a maximum staleness D. After
a revocation, the window of exposure is then bounded by approximately
D + d + T_hot, where d is the clock-skew bound (A5).
High-consequence profiles SHOULD set D to zero by reading generations
inside the atomic commit section. Lower-consequence profiles MUST
declare D. Where possible, generations and counters SHOULD be
preferred over wall-clock comparison.
31.6. Approval Windows
An escalated Handle's validity must exceed the expected approval
latency, or acts expire unexecuted. Long validity, however, widens
exposure.
A two-phase approach resolves this tension. A commitment reserves
state during approval (Section 30), and a short-lived release token
is minted only after approval. Because approval is bound to the act
digest, a late approval of a changed act fails.
Das Expires 27 March 2027 [Page 60]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
31.7. Timeouts and Retry Hazards
Client timeouts are often shorter than escalation paths. A timeout
MUST NOT cause a new Candidate Act with fresh authority to be created
for the same intent, since this can produce a duplicate effect.
An intent identifier or idempotency key SHOULD be bound into the
Candidate Act, and the sink SHOULD refuse a second consumption for
the same intent. Indeterminate outcomes follow Section 28.
31.8. Speculative Preparation
The warm path may pre-compute Handles before they are needed. Pre-
minted Handles MUST NOT survive a generation change, and currentness
is always re-checked at commit.
31.9. Performance Isolation
Escalated traffic SHOULD be queued separately from ordinary traffic.
This prevents a burst of escalations from delaying the ordinary hot
path, and ordinary load from starving escalations. It also limits
the effect of verification exhaustion (Section 27).
32. Latency Proportional to Consequence
Profiles may define different assurance classes:
LOW CONSEQUENCE
cached policy + local verification
MEDIUM CONSEQUENCE
fresh state + exact-act binding + replay protection
HIGH CONSEQUENCE
fresh attestation + stronger provenance
+ escalation + protected approval
CATASTROPHIC CONSEQUENCE
hardware-rooted enforcement
+ multi-party authority
+ non-completability
Optimization MUST NOT remove protections required by the selected
consequence profile.
Das Expires 27 March 2027 [Page 61]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
A high-frequency low-risk operation should not automatically inherit
the latency profile of a power-grid actuation command. Conversely, a
safety-critical command should not be weakened merely to achieve
ordinary web-request latency.
33. Legacy-System Deployment
Immediate replacement of existing enterprise, financial,
telecommunications, cloud, industrial, and operating-system
infrastructure would be unrealistic. Execution finality therefore
needs to support incremental deployment.
33.1. Sink-Adjacent Proxy
A legacy system may continue receiving conventional requests through
a protected proxy:
AI / legacy application
|
v
Candidate Act
|
v
protected finality proxy
|
v
verify finality authority
|
v
construct conventional legacy request
|
v
legacy API / database / payment system
If the proxy is genuinely the last boundary where the consequence can
still be prevented, the proxy may function as the Finality Sink. If
downstream bypass paths remain, it cannot provide a complete finality
guarantee.
33.2. Existing Choke Points
Initial enforcement can potentially be integrated into existing API
gateways, service meshes, payment connectors, database commit paths,
storage controllers, egress gateways, cloud control planes,
hypervisors, HSMs, TEEs, network controllers, industrial gateways,
and telecom control points.
Das Expires 27 March 2027 [Page 62]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
33.3. Progressive Migration
STAGE 1
sink-adjacent gateway/proxy
|
v
STAGE 2
native service or transaction integration
|
v
STAGE 3
hardware / firmware / commit-path enforcement
The architecture can therefore support stronger assurance over time
without requiring immediate stack replacement.
34. Native Versus Non-Native Finality
A native system may directly understand Candidate Acts, RCAEs, EASOs,
Execution Handles, and Finality Receipts. A non-native system may
understand none of them.
The architecture therefore distinguishes *semantic finality* from a
particular wire format. A proxy can translate validated finality
state into the conventional interface required by a legacy sink.
Functional equivalence depends on whether the protected consequence
remains completely mediated, not on whether the downstream platform
uses execution-finality terminology.
35. Relationship to Authentication and Authorization
Each layer answers a different question:
* Authentication answers: Who are you?
* Authorization answers: What class of action are you permitted to
request?
* Dynamic trust may answer: Given current evidence, how much
confidence should be placed in this actor or request?
* Execution finality answers: May this exact consequence become
effective now?
These systems therefore complement rather than necessarily replace
one another.
Das Expires 27 March 2027 [Page 63]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
36. Relationship to OAuth
OAuth [RFC6749] and fine-grained authorization, including Rich
Authorization Requests [RFC9396], can provide important authority
inputs.
A resource server could be functionally equivalent to the Finality
Sink for a defined operation if it reconstructs the exact
consequence, checks all consequence-relevant fields, verifies current
state, enforces replay resistance, atomically consumes authority, and
controls every consequence path.
The distinction is functional rather than terminological. Merely
checking a valid token at a final API endpoint is not enough if later
components can change, replay, redirect, or duplicate the effect.
37. Relationship to Attestation
Attestation [RFC9334] can establish evidence about software,
firmware, platform identity, configuration, or security state. It
can help answer whether a Finality Sink is running an approved
implementation.
It does not by itself answer whether this exact Candidate Act was
checked against current authority and atomically coupled to this
particular consequence.
Attestation is therefore an input to finality, not a replacement for
it.
38. Relationship to Other Execution-Finality Drafts
This document is part of a broader family of execution-finality work,
but it addresses a distinct architectural problem.
The broader drafts define what a Candidate Act is, where the
effectuation boundary exists, how bounded execution authority is
represented, how revocation and state continuity reach the final
boundary, how alternate consequence paths are closed, and how
execution-finality architecture can be deployed in existing systems.
This document addresses a narrower question:
| *What should happen when a Candidate Act is too risky for ordinary
| release, but remains technically permissible if stronger,
| narrower, and machine-verifiable execution conditions are
| imposed?*
Das Expires 27 March 2027 [Page 64]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
Its primary contribution is therefore *Graduated and Escalated
Conditional Finality*. It defines a state machine in which an
elevated-risk Candidate Act remains non-effective while the system:
1. derives a stricter consequence boundary;
2. selects additional controls;
3. binds those controls into execution authority;
4. requires the Finality Sink to verify the resulting escalated
conditions before effectuation.
38.1. Difference from Candidate-Act Finality
The Candidate-Act Finality draft
[I-D.das-protocols-candidate-act-finality] focuses principally on the
Candidate Act abstraction: converting a computationally generated
operation into a structured, non-effective proposed act before it is
allowed to produce an external consequence.
The present document assumes that a Candidate Act already exists.
Its concern begins at the next question: which finality path should
that Candidate Act receive?
Candidate-Act Finality draft:
AI output
|
v
Candidate Act
|
v
Non-Effective State
This document:
Candidate Act
|
v
risk / consequence classification
|
v
ordinary / reduced / escalated / sandbox /
canary / review / quarantine / denial
|
v
corresponding execution authority
Das Expires 27 March 2027 [Page 65]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
Candidate-Act Finality defines the *object being controlled*; this
document defines the *graduated release logic applied to that
object*.
38.2. Difference from the Agentic Effectuation Boundary
The effectuation-boundary draft
[I-D.das-agentic-effectuation-boundary] focuses on identifying the
boundary where an agent-generated instruction becomes an externally
effective consequence, and therefore where mandatory enforcement
should occur. Its central question is where enforcement must exist.
The present document asks what form of execution authority should
reach that boundary when the Candidate Act presents elevated but
manageable risk. The effectuation-boundary draft defines
*placement*; this document defines *conditional release semantics*.
38.3. Difference from the AI Boundary Draft
The AI boundary draft [I-D.das-execution-finality-ai-boundary]
addresses the general separation between AI computation and external
effectuation. It establishes that an AI-generated output, even when
authenticated or authorized, should not automatically become an
external consequence.
The present document operates inside that broader architecture. It
defines what happens when the system determines that the act is not
safe enough for ordinary release but not prohibited enough for
unconditional denial. The resulting contribution is a structured
middle state, in which additional controls materially change the
authority eventually presented to the Finality Sink.
38.4. Difference from the Execution Handle Draft
The Execution Handle draft [I-D.das-execution-handle] focuses on the
artifact used to carry narrowly scoped execution authority. It
addresses exact-act binding, sink binding, freshness and expiration,
replay resistance and one-time consumption, and bounded execution
scope.
The present document does not principally define the Execution
Handle. Instead, it defines *why and when a different, stricter form
of execution authority must be generated*. For example:
Das Expires 27 March 2027 [Page 66]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
Ordinary Handle
amount <= 500,000
recipient = approved class
expiry = 10 minutes
may become:
Escalated Handle
amount <= 100,000
recipient = Beneficiary-A only
expiry = 30 seconds
fresh protected approval required
fresh sink attestation required
single use
mandatory monitoring
| *The Execution Handle draft defines how bounded authority is
| carried; this document defines how elevated risk changes that
| bounded authority.*
38.5. Difference from Finality-Bound Revocation
The finality-bound revocation draft
[I-D.das-finality-bound-revocation] focuses specifically on ensuring
that revocation remains effective at or before final effectuation.
Revocation is only one input to Escalated Conditional Finality. This
document may require current revocation state as part of an escalated
decision, but it also considers consequence severity and boundary
proximity, financial value, data and recipient sensitivity,
jurisdiction, reversibility, sink trust, provenance confidence,
protected approval, and fresh attestation.
Revocation is therefore a *predicate* within the present architecture
rather than its primary subject.
38.6. Difference from State and Policy Continuity
The state and policy continuity draft
[I-D.das-state-policy-continuity-finality] addresses the problem of
state changing between authorization and effectuation. Its central
property is continuity of relevant protected state across time.
The present document incorporates that property as Current-State
Execution Congruence (Section 10), because an escalated act must not
execute merely because it satisfied escalation requirements earlier.
Das Expires 27 March 2027 [Page 67]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
However, state continuity is not the central purpose of this
document. This document additionally defines graduated
classification, the escalated-but-allowable state, narrower RCAE
derivation, additional escalation controls, escalated EASO formation,
escalated Execution Handle generation, and post-effectuation
obligations.
| *State continuity answers whether previously valid authority
| remains valid; escalated finality determines what stronger
| authority is required in the first place.*
38.7. Difference from Consequence-Path Completeness
The consequence-path completeness draft
[I-D.das-consequence-path-completeness] addresses the structural
requirement that no alternate path may produce the same protected
consequence while bypassing finality enforcement.
That property is required by the present architecture (Section 11.7
and Section 25). However, this document does not primarily attempt
to enumerate every bypass path. It assumes that an escalated
decision must remain enforceable through all relevant consequence
paths.
| *Consequence-path completeness protects the enforcement topology;
| this document defines the conditional authority being enforced
| through that topology.*
38.8. Difference from Composite Execution Finality
The composite execution finality draft
[I-D.das-composite-execution-finality] addresses execution finality
where a consequence spans multiple components, services, or
independently controlled systems. Its primary problem is
*composition*.
The present document addresses *classification and conditional
release*. An escalated Candidate Act may traverse a composite system,
but the defining question remains whether the act should receive
ordinary authority, narrower authority, additional controls, or no
authority.
Das Expires 27 March 2027 [Page 68]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
Escalated Conditional Finality
|
v
determines permitted consequence
and required controls
Composite Execution Finality
|
v
preserves those properties across
multiple execution components
38.9. Difference from Enforcement Profiles
Enforcement-profile work
[I-D.das-execution-finality-enforcement-profiles] describes how
execution-finality properties may be instantiated for different
environments, assurance levels, or application domains.
The present document defines a reusable decision and authority-
transition mechanism that such profiles may invoke. For example, a
payment profile and a cloud-administration profile may have
completely different consequence semantics while both supporting:
ORDINARY
REDUCED
ESCALATED
CANARY
SANDBOX
REVIEW
DENY
The enforcement-profile draft answers how finality is implemented in
a given environment. This document answers which finality mode a
specific Candidate Act should enter.
38.10. Difference from the Deployment Architecture
The deployment draft [I-D.das-execution-finality-deployment] provides
the broad deployment architecture. It considers placement of the
Finality Sink, exact-act representation, protected state, atomicity,
replay, crash recovery, availability, latency, legacy-system
integration, and native and proxy enforcement.
The present document uses those mechanisms but gives them a narrower
purpose. It defines the *graduated decision layer* between Candidate
Act formation and final effectuation.
Das Expires 27 March 2027 [Page 69]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
For example, the deployment document may explain how a Finality Sink
can be placed inside a payment gateway. This document determines
that a particular payment cannot receive ordinary release, but may
receive the following before reaching that same Finality Sink:
reduced amount
+ specific beneficiary
+ fresh approval
+ shorter expiry
+ single-use authority
+ fresh sink attestation
| *The deployment draft explains how execution finality is deployed;
| this document defines how execution authority is dynamically
| strengthened or narrowed according to consequence risk.*
38.11. Difference from Dynamic-Trust or Risk-Scoring Systems
A dynamic trust system may return ALLOW, RESTRICT, ESCALATE, or DENY.
The present architecture may consume such signals, but it does not
treat the classification itself as final authority. In Escalated
Conditional Finality:
ESCALATE
|
v
Candidate Act remains non-effective
|
v
narrower consequence boundary derived
|
v
additional mandatory controls selected
|
v
controls cryptographically bound
|
v
new restricted execution authority generated
|
v
Finality Sink independently verifies
|
v
bounded consequence only
Das Expires 27 March 2027 [Page 70]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
| *Escalation is not merely a different decision result. It changes
| the executable authority and the conditions under which
| effectuation becomes technically possible.*
38.12. Architectural Position Within the Draft Family
Candidate-Act Finality
"What exact proposed act is being held non-effective?"
|
v
Graduated / Escalated Conditional Finality
"What release class and additional controls does this act
require?"
|
v
Execution Handle
"What bounded authority represents that decision?"
|
v
State / Revocation / Policy Continuity
"Does that authority remain current?"
|
v
Effectuation Boundary
"Where can the consequence still be prevented?"
|
v
Finality Sink
"Does the exact act satisfy all current conditions?"
|
v
Composite / Consequence-Path Finality
"Can those guarantees survive distributed and alternate
paths?"
|
v
EFFECT
Each work item addresses a different layer rather than simply
renaming the same control.
38.13. Specific Contribution of This Document
This document defines a graduated execution-finality state machine in
which:
1. a Candidate Act remains non-effective;
Das Expires 27 March 2027 [Page 71]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
2. the act is classified according to consequence and risk;
3. an act may receive an outcome other than ordinary allow or deny;
4. an elevated-but-permissible act enters Escalated Conditional
Finality;
5. the permitted consequence boundary is narrowed;
6. additional machine-verifiable controls are selected;
7. those controls are incorporated into the authority structure;
8. the resulting authority is bound to the Candidate Act and
intended Finality Sink;
9. the Finality Sink independently verifies the escalated
conditions against current protected state; and
10. only the consequence permitted by that escalated authority may
become effective.
| *This document does not merely decide that elevated-risk acts
| require additional review. It defines how elevated risk causes a
| narrower and stronger execution authority to be constructed,
| carried to the effectuation boundary, revalidated against current
| protected state, and enforced by the Finality Sink before the
| Candidate Act can leave the non-effective state.*
39. Receipts and Evidence
A Finality Receipt can bind evidence to the resulting transition. A
receipt may include:
Candidate Act digest
RCAE identifier/hash
EASO identifier/hash
Execution Handle identifier
Finality Sink identity
policy generation
revocation generation
nonce
decision
timestamp
resulting transaction/consequence identifier
Receipts can assist audit, cross-domain assurance, incident
investigation, recovery, regulatory evidence, and dispute resolution.
Das Expires 27 March 2027 [Page 72]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
A receipt does not itself prevent an unauthorized consequence. Its
value depends on the integrity and placement of the enforcing
transition that generated it.
40. Multi-Agent Systems
Authority becomes more difficult to track when one agent delegates to
another:
Agent A
|
v
Agent B
|
v
Tool C
|
v
Service D
|
v
Finality Sink
Every intermediate component may be individually authenticated, yet
the final consequence may drift.
Execution-finality state SHOULD therefore preserve relevant
consequence restrictions across delegation boundaries. An escalated
or reduced-scope act MUST NOT regain broader authority simply because
another agent re-encodes or republishes it (Section 22).
41. Operational Monitoring
Monitoring may continue after effectuation for reversible or
escalated acts. Possible monitoring signals include recipient
changes, source revocation, policy updates, sink trust degradation,
canary failure, unexpected downstream consequences, fraud signals,
and jurisdiction changes.
Where rollback is technically possible, protected rollback capability
may be activated. Where rollback is impossible, monitoring still
supports containment and future revocation.
42. Fail-Closed and Safe-Degraded Behavior
For many high-criticality consequences, uncertain authorization means
no ordinary effectuation.
Das Expires 27 March 2027 [Page 73]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
However, fail-closed behavior must not itself create an unsafe
condition. For example, an industrial controller may require a safe
physical fallback rather than simply doing nothing.
Profiles therefore need to define behavior for normal operation,
verification-service loss, clock loss, revocation-state loss,
attestation failure, protected-store failure, network partition,
emergency mode, and recovery mode.
Emergency authority MUST be separately bounded. Emergency mode MUST
NOT become a permanent bypass path.
43. Residual Risk
Execution finality does not guarantee that an AI output is
objectively true, universally lawful, or perfectly safe. The
architecture distinguishes machine-verifiable validation from
absolute correctness. An act may satisfy every defined predicate and
still produce an unforeseen consequence.
Execution finality therefore provides *bounded, verifiable control
over the authorization-to-consequence transition*, rather than
guaranteed correctness of artificial intelligence.
44. Security Properties
A conforming high-assurance deployment should be able to demonstrate
the following properties:
* *Complete mediation:* every protected consequence path passes
through equivalent finality enforcement.
* *Exact-act binding:* material consequence fields are
deterministically bound.
* *Current-state verification:* revocation and policy state are
current within the selected assurance profile.
* *Replay resistance:* authority cannot silently produce additional
consequences.
* *Destination binding:* authority cannot be repointed.
* *Sink binding:* authority intended for one Finality Sink cannot
silently operate elsewhere.
* *Escalation preservation:* escalated requirements cannot disappear
downstream.
Das Expires 27 March 2027 [Page 74]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
* *Atomicity:* verification and effectuation do not expose an
exploitable TOCTOU interval.
* *Rollback resistance:* restoration of old protected state does not
resurrect authority.
* *Crash recovery:* ambiguous effectuation states are safely
resolvable.
* *Fail-safe behavior:* verification failure does not silently
become authorization.
* *Evidence integrity:* receipts cannot claim an effect that the
enforcement transition did not produce.
45. Deployment Profiles
Different domains may select different assurance profiles:
* A *local low-latency profile* may use local protected state,
symmetric MACs, single-use nonces, and local atomic commits.
* A *distributed profile* may require fencing generations, durable
idempotency, transaction state machines, and cross-service
receipts.
* A *safety-critical profile* may require hardware mediation, an
attested Finality Sink, deterministic timing, bounded offline
authority, and fail-safe physical action.
* A *sovereign or cross-domain profile* may additionally require
independent attestation, jurisdiction-bound scope, externally
verifiable receipts, and separation of trust authorities.
46. Interoperability Requirements
A future interoperable profile would need to specify at least:
* a deterministic Candidate Act representation;
* covered consequence-relevant fields;
* algorithm identifiers;
* scope representation;
* sink identity format;
Das Expires 27 March 2027 [Page 75]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
* nonce, generation, and expiration semantics;
* receipt structure;
* unknown-field handling and canonicalization rules;
* error behavior;
* version negotiation;
* evidence references;
* privacy rules.
The architecture should avoid defining one universal action schema if
doing so would erase application-specific consequence semantics.
47. Examples
47.1. Payment
Candidate Act
operation: PAYMENT
source: Account-A
destination: Beneficiary-B
amount: 10000
currency: INR
purpose: invoice-891
expiry: T
sink: PaymentConnector-7
Suppose elevated value triggers escalation. The system may derive:
maximum allowed amount = 5000
human approval = required
validity = 60 seconds
recipient = Beneficiary-B only
single use = true
fresh sink attestation = required
The Finality Sink receives INR 5000 -> Beneficiary-B and verifies
current state. If it instead receives INR 6000 -> Beneficiary-B or
INR 5000 -> Beneficiary-C, the operation remains non-effective.
47.2. SEND
Das Expires 27 March 2027 [Page 76]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
Candidate Act
operation: SEND
content_digest: H(document)
recipient: user@example
purpose: customer-case-17
classification: confidential
sink: Corporate-Egress-3
Escalation might require:
redact fields A/B/C
single recipient
no forwarding
30-second expiry
protected human approval
Approval of a preview is insufficient if the final attachment or
destination can change. The Finality Sink MUST verify the content
and destination that will actually leave the system.
47.3. Cloud Administration
Candidate Act
operation: AttachPrivilegePolicy
target: ProductionRole-A
account: CloudAccount-X
requested_by: Agent-47
Dynamic trust may report:
identity = valid
device = attested
behavior = normal
trust score = high
That does not automatically mean the privilege modification should be
executed. Finality may additionally require:
exact policy digest
specific account
specific role
current security policy generation
change-ticket binding
fresh authorization
single use
atomic commit
Das Expires 27 March 2027 [Page 77]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
48. What This Architecture Does Not Claim
This architecture does not by itself solve model alignment, perfect
factual correctness, all cybersecurity compromise, malicious
hardware, insider threats with control of every trust anchor,
geopolitical risk, universal legal compliance, or perfect physical
safety.
It also does not imply that every system requires hardware-enforced
non-completability. Different consequence profiles can select
different assurance levels.
49. Open Problems
The following problems are not solved by this document. They are
listed so that reviewers can judge the claims in proportion.
* Classification correctness. The architecture faithfully enforces
whatever controls the classification selects (A6). A wrong
classification produces a wrongly authorized but still bounded
act.
* Cross-principal decomposition. Aggregate ceilings (Section 23.1)
cover a single principal, recipient, or purpose. Coordinated
agents that split a prohibited objective into individually
permissible acts across principals, sessions, or purposes are not
addressed.
* Semantic completeness of the Candidate Act. There is no general
method to prove that a Candidate Act representation covers every
consequence-relevant field of an arbitrary API, including implicit
defaults and side effects.
* Proof of path completeness. In large systems, consequence-path
completeness is currently established by audit, not by a general
verification method.
* Non-preparable sinks. For email, many tool calls, and physical
actuation there is no prepare phase, so atomicity reduces to
mitigation.
* Currentness versus availability. Strict currentness sacrifices
availability under network partition. Bounded offline authority
is only a partial answer.
* Approval quality. Binding proves what was approved, not that the
approver understood it.
Das Expires 27 March 2027 [Page 78]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
* Trust roots. Compromise of the Finality Sink or its hardware
trust roots defeats the architecture (Section 26).
* Interoperable encoding. There is no agreed wire format yet for
Candidate Acts, escalation classes, Handles, or receipts
(Section 46).
* Real-time control loops. Hot-path verification inside sub-
millisecond control loops is only partly addressed by envelope-
style authority.
* Conflicting requirements. Escalation requirements from different
jurisdictions or authorities may conflict, and no resolution rule
is defined here.
* Privacy-preserving evidence. Receipts that prove enforcement
without revealing act contents are not specified (Section 55).
* Evaluation. There is no standard benchmark for comparing latency
and assurance across implementations.
50. IETF-Relevant Questions
This document invites technical discussion of the following
questions:
1. Which parts are generic Internet architecture, and which must
remain application-specific?
2. Can a common Candidate Act / Finality Receipt information model
be useful without defining universal action semantics?
3. Can OAuth authorization details [RFC9396] carry sufficient
exact-act inputs for selected profiles?
4. Can RATS evidence [RFC9334] describe trustworthy properties of
Finality Sinks?
5. Can COSE [RFC9052] provide interoperable protection for
Candidate Acts, Handles, and receipts?
6. How should workload identity from WIMSE bind into act-level
consequence authority?
7. How should semantic canonicalization profiles be negotiated?
8. How can implementations prove consequence-path completeness?
Das Expires 27 March 2027 [Page 79]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
9. How should latency and assurance profiles be benchmarked?
10. How should distributed systems represent indeterminate external
effects?
11. How can privacy-preserving receipts prove enforcement without
revealing sensitive act contents?
51. Implementation and Testing Considerations
A useful implementation test suite should include:
* positive authorized effectuation;
* incorrect recipient, incorrect amount, changed destination, and
changed content;
* stale policy generation and advanced revocation generation;
* expired Handle;
* replayed nonce and concurrent Handle use;
* wrong Finality Sink and wrong hardware identity;
* missing escalation control;
* stale human approval;
* snapshot rollback;
* canonicalization disagreement, unknown fields, and duplicate
fields;
* crash before effect and crash after effect;
* retry after indeterminate outcome;
* proxy bypass and alternate egress;
* a sink presented with a well-formed request but no bound Candidate
Act or Execution Handle (expected result: no effect; see
Section 11);
* fragmentation of an escalated act into sub-threshold acts;
* classifier unavailable or timing out (expected: stricter class,
never ordinary);
Das Expires 27 March 2027 [Page 80]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
* resubmission of an escalated intent seeking a lower class;
* concurrent ordinary and escalated authority for the same intent;
* approval granted on a preview that differs from the sink-
reconstructed act;
* revocation during a declared staleness window;
* client timeout followed by retry of the same intent;
* verification-exhaustion load.
A system should not claim high-assurance execution finality solely
because the happy-path request succeeds.
52. Implementation and Related Resources
The following runnable reference implementations are informative.
They are not normative parts of this document.
* Execution Handle -- Exact-Act Binding, Sink Verification, Atomic
Consumption and Adversarial Test Harness:
https://github.com/sangmdas/Execution-Handle-Exact-Act-Binding-
Sink-Verification-Atomic-Consumption-Adversarial-Test-Harness.
Covers exact-act binding, sink verification, replay/single-use
behavior, canonicalization, concurrency, atomic consumption, and
negative-control testing.
* Composite Execution Finality Reference:
https://github.com/sangmdas/Composite-Execution-Finality-
Reference. Composes execution-finality properties across
distributed or multi-stage execution paths.
* Preventing AI Hallucinations and Unauthorized Actions -- Runnable
Reference Implementation: https://github.com/sangmdas/Preventing-
AI-Hallucinations-and-Unauthorized-Actions-Runnable-Reference-
Implementation. Demonstrates Candidate Act formation, non-
effective state, validation evidence, scoped execution authority,
and sink-side control of AI-generated actions.
* Payment Execution Finality for Agentic API and Automated Payments
-- Runnable Reference Implementation: https://github.com/sangmdas/
Payment-Execution-Finality-for-Agentic-API-and-Automated-Payments-
Runnable-Reference-Implementation. Shows why identity and
authorization alone are insufficient without exact beneficiary,
amount, freshness, replay, and final execution controls.
Das Expires 27 March 2027 [Page 81]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
Closely related Internet-Drafts are listed in the Informative
References, in particular [I-D.das-execution-finality-deployment],
[I-D.das-agentic-effectuation-boundary], [I-D.das-execution-handle],
and [I-D.das-composite-execution-finality].
53. Conclusion
Dynamic trust, continuous authorization, attestation, policy engines,
and human approval are all useful, and identity is necessary. None
of them should be confused with the final consequence boundary merely
because they produce an ALLOW, DENY, RESTRICT, or ESCALATE decision.
Nor should a Finality Sink be confused with the whole architecture
merely because it sits at that boundary.
The architecture described here adds a different invariant:
| *The proposed act remains non-effective until the exact
| consequence about to occur is independently bound to current
| authority and accepted by the component that still has the
| technical ability to prevent that consequence.*
Escalation therefore does not simply mean "trust is lower; review
this request." It means:
| *Ordinary execution authority is insufficient. Keep the Candidate
| Act non-effective, derive a narrower consequence boundary, apply
| additional controls, encode those controls into the execution
| authority, and require the Finality Sink to verify them again
| against current state before anything becomes real.*
That is the distinction between *trust escalation* and *Escalated
Conditional Execution Finality*.
In concise architectural terms:
| *The Candidate Act identifies and freezes the proposed
| consequence. The protected finality pipeline determines the
| permitted consequence boundary. The Execution Handle represents
| bounded authority to cross that boundary. The Finality Sink
| independently verifies that the actual operation remains congruent
| with that authority and current protected state, and only then
| permits effectuation. Remove any one of these required functions,
| and the remaining Finality Sink may become only a final policy
| check rather than an execution-finality architecture.*
The final principle remains:
Das Expires 27 March 2027 [Page 82]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
| *Computation is not authority. Authorization is not consequence.
| Historical approval is not current execution authority.*
54. Security Considerations
Execution finality should be treated as a security boundary rather
than an advisory policy service. Failure to completely mediate
consequence paths can invalidate the finality guarantee.
A Finality Sink deployed without the supporting architecture
described in Section 11 and Section 12 should not be represented as
providing execution finality. Without a bound Candidate Act, non-
effective state, bound authority, protected current state, replay
state, deterministic representation, path completeness, upstream-
derived escalation semantics, and atomic effectuation, it provides
only a final policy check.
Implementations need to specifically consider parameter substitution
and semantic ambiguity (Section 17, Section 18); stale policy and
revocation (Section 20); replay and concurrent authority use
(Section 19); snapshot rollback (Section 21); sink substitution;
agent-chain escalation laundering (Section 22); human-approval replay
(Section 24); proxy bypass and administrative bypass (Section 25);
sink compromise (Section 26); verification exhaustion (Section 27);
crash ambiguity (Section 28); side channels; receipt forgery; and
recovery behavior.
The assumptions, adversary capabilities, and invariants under which
the properties are claimed are stated in Section 15. Graduated
release introduces attacks aimed at reaching a less strict class,
namely fragmentation, fail-open classification, resubmission,
parallel authority, probing, reviewer exhaustion, and break-glass
abuse; these are covered in Section 23. Conformance can be assessed
per enforcement point (Section 13); EP-13 through EP-17 in particular
identify near-equivalent implementations that do not provide the
property. Latency optimizations are safe only within the staleness
and approval-window limits in Section 31.5 and Section 31.6. Limits
that remain unsolved are listed in Section 49.
Security evaluation should include adversarial and negative tests,
not only successful execution tests (Section 51). A useful
validation question is:
| *Can a protected consequence be produced when the required
| finality evidence is absent, stale, mismatched, replayed, revoked,
| malformed, redirected, or unavailable?*
Das Expires 27 March 2027 [Page 83]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
The expected result for the claimed protected path is: no
unauthorized protected effect.
55. Privacy Considerations
Execution-finality artifacts may expose sensitive information, for
example recipient and financial amount, data classification and
purpose, jurisdiction, resource identity, agent identity, and
internal policy state.
Finality systems can accumulate highly sensitive evidence.
Implementations should avoid turning the execution-control
architecture into a general surveillance mechanism. Receipts should
contain only the information needed for the selected assurance
purpose.
Profiles should minimize disclosure. Potential techniques include
keyed digests and domain-separated hashes; encrypted receipts and
encrypted references; commitments and selective disclosure; short
retention; pseudonymous identifiers; and proofs over protected state
rather than disclosure of raw state.
Auditability must not automatically imply unrestricted observability.
56. IANA Considerations
This document has no IANA actions.
If later protocol work introduces registered identifiers, appropriate
IANA registries may be considered separately. Such identifiers could
include finality profiles, receipt claims, Candidate Act semantic
profiles, assurance classes, Finality Sink types, algorithm suites,
and error codes.
57. References
57.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
57.2. Informative References
Das Expires 27 March 2027 [Page 84]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
[I-D.das-agentic-effectuation-boundary]
Das, S., "When AI Agents Hold the Keys: Threat Model and
Execution-Finality Requirements for Autonomous High-
Consequence Systems", Work in Progress, Internet-Draft,
draft-das-agentic-effectuation-boundary, September 2026,
<https://datatracker.ietf.org/doc/draft-das-agentic-
effectuation-boundary/>.
[I-D.das-composite-execution-finality]
Das, S., "Partial Commit Is Not Finality: Composite
Execution Finality", Work in Progress, Internet-Draft,
draft-das-composite-execution-finality, September 2026,
<https://datatracker.ietf.org/doc/draft-das-composite-
execution-finality/>.
[I-D.das-consequence-path-completeness]
Das, S., "When the Gate Can Be Bypassed: Consequence-Path
Completeness for Execution Finality", Work in Progress,
Internet-Draft, draft-das-consequence-path-completeness,
September 2026, <https://datatracker.ietf.org/doc/draft-
das-consequence-path-completeness/>.
[I-D.das-execution-finality-ai-boundary]
Das, S., "An Execution Interlock at the AI Model-to-
External-Effect Boundary", Work in Progress, Internet-
Draft, draft-das-execution-finality-ai-boundary, 2026,
<https://datatracker.ietf.org/doc/draft-das-execution-
finality-ai-boundary/>.
[I-D.das-execution-finality-deployment]
Das, S., "Execution-Finality Architecture for AI and
Autonomous Critical Systems", Work in Progress, Internet-
Draft, draft-das-execution-finality-deployment, 2026,
<https://datatracker.ietf.org/doc/draft-das-execution-
finality-deployment/>.
[I-D.das-execution-finality-enforcement-profiles]
Das, S., "Execution-Finality Enforcement Profiles", Work
in Progress, Internet-Draft, draft-das-execution-finality-
enforcement-profiles, 2026,
<https://datatracker.ietf.org/doc/draft-das-execution-
finality-enforcement-profiles/>.
Das Expires 27 March 2027 [Page 85]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
[I-D.das-execution-handle]
Das, S., "Possession Is Not Authority: Execution Handles
for Exact-Act, Sink-Bound Execution Authority", Work in
Progress, Internet-Draft, draft-das-execution-handle,
September 2026, <https://datatracker.ietf.org/doc/draft-
das-execution-handle/>.
[I-D.das-finality-bound-revocation]
Das, S., "Revoked but Still Executable: Closing the
Authorization-to-Effect Gap with Finality-Bound
Revocation", Work in Progress, Internet-Draft, draft-das-
finality-bound-revocation, September 2026,
<https://datatracker.ietf.org/doc/draft-das-finality-
bound-revocation/>.
[I-D.das-protocols-candidate-act-finality]
Das, S., "Candidate-Act Execution Finality", Work in
Progress, Internet-Draft, draft-das-protocols-candidate-
act-finality, 2026, <https://datatracker.ietf.org/doc/
draft-das-protocols-candidate-act-finality/>.
[I-D.das-state-policy-continuity-finality]
Das, S., "When Valid Authorization Becomes Stale: State
and Policy Continuity at the Execution-Finality Boundary",
Work in Progress, Internet-Draft, draft-das-state-policy-
continuity-finality, September 2026,
<https://datatracker.ietf.org/doc/draft-das-state-policy-
continuity-finality/>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/info/rfc9396>.
Das Expires 27 March 2027 [Page 86]
Internet-Draft Adaptive Authorization for Agentic AI September 2026
Appendix A. Alternative Titles
This appendix is informative. It lists alternative descriptive
titles under which the architecture in this document may be
referenced or discovered:
1. Graduated and Escalated Conditional Execution Finality for AI
Agents and Autonomous Systems
2. Graduated Runtime Authorization for AI Agents and Autonomous
Systems: Escalated Conditional Execution Finality for Elevated-
Risk Actions
3. Runtime Authorization and Execution Control for AI Agents and
Autonomous Systems
4. Continuous Authorization and Execution Finality for High-Risk AI
Agent Actions
5. AI Agent Security: Runtime Authorization and Final Execution
Control for High-Consequence Actions
6. Graduated Authorization for AI Agents: Conditional Execution
Control at the Effectuation Boundary
7. Risk-Based Authorization and Execution Finality for Autonomous
AI Systems
8. Zero-Trust Execution Control for AI Agents and High-Risk
Autonomous Actions
9. Execution-Time Policy Enforcement for AI Agents and Autonomous
Systems
10. Conditional Authorization and Final Effectuation Control for
Agentic AI
11. High-Assurance Runtime Authorization for AI Agents, Autonomous
Systems, and Critical Infrastructure
Author's Address
Sangam Das
Balasore
Odisha
India
Email: info@sangamdas.com
Das Expires 27 March 2027 [Page 87]