| Internet-Draft | Adaptive Authorization for Agentic AI | September 2026 |
| Das | Expires 27 March 2027 | [Page] |
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.¶
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.¶
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 (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.¶
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.¶
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.¶
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.¶
| Mechanism | What it establishes | What it leaves open |
|---|---|---|
| Authentication, MFA, step-up | who the actor is, freshly | which act; whether the act changed before commit |
| Conditional access, Zero Trust session policy | whether a session or request may continue | per-act consequence; binding to the actual effect |
| OAuth scopes, Rich Authorization Requests [RFC9396] | the class or description of a permitted action | commit-time currentness, single use, path completeness |
| Policy decision and enforcement points | a decision for a presented request | that the enforced effect equals the decided request |
| Risk scoring, adaptive authorization | an ESCALATE or RESTRICT label | encoding the implied conditions into executable authority |
| Remote attestation [RFC9334] | the platform state of a component | the act that component processes |
| Payment transaction signing with dynamic linking | amount and payee bound to one consent | other sink types; graduated classes; revocation generations |
| Maker-checker, four-eyes approval | a second human agreed | binding of approval to exact act digest, sink, and freshness |
| Two-phase commit, sagas | atomic commit or compensation | whether the committed act was authorized; authority consumption |
| Rate limits, quotas | volume ceilings | exact-act binding for each individual effect |
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:¶
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.¶
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.¶
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:¶
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.¶
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:¶
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:¶
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.¶
This architecture is primarily intended for high-criticality systems and high-consequence operations. Examples include:¶
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.¶
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 --------------+
| |
+---- 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
¶
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.¶
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.¶
Non-effective does not mean nonexistent. The operation may be fully formed. The defining property is that it still cannot produce the protected effect.¶
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.¶
The Result-Consequence Acceptance Envelope (RCAE) describes the permitted consequence boundary. It may constrain the following properties:¶
The RCAE thereby converts permission into a technically bounded consequence envelope.¶
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.¶
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 completion material. In its advanced form, the Handle carries narrowly bounded authority rather than a general-purpose execution credential.¶
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:¶
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.¶
A dynamic trust API might consider:¶
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?¶
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?¶
An escalated-but-allowable act follows a stronger execution path. The Candidate Act MUST remain non-effective throughout escalation.¶
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.¶
Depending on consequence class, an escalated profile may require stronger controls. These may include:¶
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:¶
amount = INR 110,000 recipient = Account-B expiry = 10 minutes human approval = absent¶
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.¶
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.¶
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:¶
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.¶
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.¶
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.¶
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
¶
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.¶
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.¶
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.¶
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.¶
+-- Finality Sink -- Database
AI Agent ----------+
+------------------- Database
bypass
¶
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]).¶
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:¶
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.¶
The Finality Sink enforces escalation; it does not by itself supply the entire escalation architecture.¶
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.¶
A system might place a policy service immediately before execution and call it the Finality Sink:¶
request | v risk score | v ALLOW | v executor¶
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.¶
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
|
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 Finality Sink is therefore necessary but not independently sufficient.¶
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.¶
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.¶
But merely moving an existing authorization check closer to execution does not establish:¶
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.¶
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.¶
Location: the Protected Enforcement Domain and the Finality Sink together.¶
Location: the Finality Sink and two or more distinct protected components.¶
Location: the Protected Enforcement Domain and the Finality Sink, for high-latency or delayed effectuation (Section 30).¶
Location: the Protected Enforcement Domain and a protected escrow outside the agent execution path.¶
Location: a temporary execution environment acting as the Finality Sink.¶
Location: a protected proxy placed immediately before an existing effectuation interface (Section 33.1).¶
Location: the Protected Enforcement Domain and its escalation modules, for escalated-but-allowable acts (Section 8).¶
Location: the Protected Enforcement Domain's receipt store and the Finality Sink.¶
Location: the Protected Enforcement Domain, which selects the profile, and the Finality Sink, which applies it (Section 32).¶
Location: an escalation module within EP-7.¶
Location: every Protected Enforcement Domain in an agent chain (Section 22, Section 40).¶
Location: the Finality Sink, or a module adjacent to it, implemented in protected hardware.¶
Location: the boundary between the AI agent and the Protected Enforcement Domain.¶
Location: the Finality Sink's locked execution primitive (EP-1, EP-12).¶
Location: the receipt store and authority release mechanism (EP-8).¶
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:¶
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.¶
Location: wherever the first usable release boundary actually lies (Section 11.7, Section 25).¶
Location: the Protected Enforcement Domain and the Finality Sink (Section 23.1, Section 40).¶
Location: every path able to reach a Finality Sink or produce the consequence (Section 42, Section 23.7).¶
| EP | Enforcement point | Primary location | Related section |
|---|---|---|---|
| EP-1 | Cryptographic execution dependency | PED and Finality Sink | Architectural Invariant |
| EP-2 | Threshold-shared execution material | Sink and share holders | Security Model |
| EP-3 | Commitment-release temporal escrow | PED and sink | High-Latency Effectuation |
| EP-4 | Paired forward and rollback authority | PED and protected escrow | Operational Monitoring |
| EP-5 | Ephemeral Finality Sink | Single-use sink | Replay |
| EP-6 | Proxy enforcement for legacy interfaces | Sink-adjacent proxy | Legacy-System Deployment |
| EP-7 | Modular escalation enforcement | PED escalation modules | Escalation Workflow |
| EP-8 | Receipt as release predicate | Receipt store and sink | Receipts and Evidence |
| EP-9 | Assurance profile anti-downgrade | PED and sink | Latency Proportional |
| EP-10 | Adversarial perturbation gate | Escalation module | Escalation Controls |
| EP-11 | Inheritance ceiling | PEDs in agent chain | Escalation Laundering |
| EP-12 | Protected hardware sink | Hardware sink | Finality Sink Compromise |
| EP-13 | Enforcement-domain isolation | Agent/PED boundary | Security Model |
| EP-14 | Structural incompleteness | Locked primitive | Finality Sink |
| EP-15 | Receipt-bound release, not logging | Receipt and release | Atomicity |
| EP-16 | Act authority, not permission check | Finality Sink | Conventional Solutions |
| EP-17 | First usable release boundary | Actual release point | Finality-Sink Bypass |
| EP-18 | Fragmented and delegated equivalence | PED and sink | Escalation-Specific Attacks |
| EP-19 | Emergency and fallback path closure | All consequence paths | Fail-Closed Behavior |
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.¶
The primary protected asset is the integrity of the final consequence. Associated assets include:¶
Relevant adversaries include:¶
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.¶
This section states the assumptions under which the properties in Section 44 are claimed, and what the model deliberately excludes.¶
The adversary may do the following:¶
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).¶
A conforming deployment maintains the following invariants:¶
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¶
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.¶
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.¶
| Threat | Example | Required architectural response |
|---|---|---|
| Parameter substitution | beneficiary changed after approval | exact-act binding |
| Destination substitution | approved SEND redirected elsewhere | destination binding |
| Replay | valid Execution Handle reused | nonce and single-use consumption |
| Stale authority | policy revoked after approval | generation/epoch revalidation |
| TOCTOU | state changes after validation | check-and-commit coupling |
| Escalation laundering | restricted authority becomes ordinary downstream | escalation inheritance |
| Alternate-path bypass | direct database/API route avoids Finality Sink | consequence-path completeness |
| Sink substitution | Handle moved to another executor | sink identity binding |
| Snapshot rollback | old replay/revocation state restored | monotonic/rollback-resistant state |
| Canonicalization ambiguity | signer and executor interpret fields differently | deterministic representation |
| Approval replay | old human approval reused | act-specific protected approval |
| Counter regression | restored counter makes stale Handle valid | monotonic protected counters |
| Capability theft | attacker copies authority object | non-bearer/sink-bound authority |
| Verification exhaustion | flood expensive crypto path | admission control and rate limits |
| Sink compromise | Finality Sink modified | TCB minimization, attestation, isolation |
| Crash ambiguity | unknown whether external act completed | durable state and reconciliation |
| Threshold fragmentation | large act split into sub-threshold acts | aggregate ceilings |
| Classification fail-open | risk-engine timeout treated as ordinary | fail to stricter class |
| Resubmission until favorable | retry until classifier says ordinary | sticky per-intent classification |
| Reviewer exhaustion | flood of escalations to human approvers | escalation budgets, no batch approval |
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.¶
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.¶
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.¶
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.¶
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
¶
This avoids relying solely on the expiration time of an old token.¶
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.¶
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.¶
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.¶
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).¶
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.¶
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.¶
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.¶
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.¶
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).¶
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.¶
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].¶
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:¶
Attestation does not itself establish execution finality. It may provide evidence that the component expected to enforce finality is in an approved state.¶
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.¶
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.¶
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.¶
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:¶
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.¶
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.¶
Operations that are reusable or time-tolerant SHOULD occur outside the per-act execution path:¶
model/workflow approval policy compilation source registration sink registration RCAE templates EASO templates cryptographic provisioning attestation baselines escalation profile compilation¶
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¶
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.¶
The per-act latency can be decomposed as:¶
T_act = T_warm + T_approval + T_hot¶
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.¶
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.¶
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.¶
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.¶
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.¶
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).¶
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.¶
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.¶
Immediate replacement of existing enterprise, financial, telecommunications, cloud, industrial, and operating-system infrastructure would be unrealistic. Execution finality therefore needs to support incremental deployment.¶
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.¶
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.¶
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.¶
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.¶
Each layer answers a different question:¶
These systems therefore complement rather than necessarily replace one another.¶
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.¶
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.¶
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?¶
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:¶
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¶
Candidate-Act Finality defines the object being controlled; this document defines the graduated release logic applied to that object.¶
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.¶
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.¶
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:¶
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.¶
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.¶
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. 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.¶
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.¶
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.¶
Escalated Conditional Finality
|
v
determines permitted consequence
and required controls
Composite Execution Finality
|
v
preserves those properties across
multiple execution components
¶
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.¶
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.¶
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.¶
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¶
Escalation is not merely a different decision result. It changes the executable authority and the conditions under which effectuation becomes technically possible.¶
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.¶
This document defines a graduated execution-finality state machine in which:¶
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.¶
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.¶
A receipt does not itself prevent an unauthorized consequence. Its value depends on the integrity and placement of the enforcing transition that generated it.¶
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).¶
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.¶
For many high-criticality consequences, uncertain authorization means no ordinary effectuation.¶
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.¶
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.¶
A conforming high-assurance deployment should be able to demonstrate the following properties:¶
Different domains may select different assurance profiles:¶
A future interoperable profile would need to specify at least:¶
The architecture should avoid defining one universal action schema if doing so would erase application-specific consequence semantics.¶
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.¶
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.¶
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¶
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.¶
The following problems are not solved by this document. They are listed so that reviewers can judge the claims in proportion.¶
This document invites technical discussion of the following questions:¶
A useful implementation test suite should include:¶
A system should not claim high-assurance execution finality solely because the happy-path request succeeds.¶
The following runnable reference implementations are informative. They are not normative parts of this document.¶
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].¶
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:¶
Computation is not authority. Authorization is not consequence. Historical approval is not current execution authority.¶
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?¶
The expected result for the claimed protected path is: no unauthorized protected effect.¶
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.¶
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.¶
This appendix is informative. It lists alternative descriptive titles under which the architecture in this document may be referenced or discovered:¶