Adaptive Authorization for Agentic AI: Graduated and Escalated Execution Control for Critical Infrastructure

Balasore Odisha India info@sangamdas.com

Security Network Working Group AI agent security agentic AI adaptive authorization runtime authorization continuous authorization critical infrastructure execution control execution finality 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.

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 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: 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.

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.

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	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	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:

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.

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 when, and only when, they appear in all capitals, as shown here.

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;
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. 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: In the architecture described here, escalation continues into the execution-control path: 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;
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.

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.

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.

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.

Terminology

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.

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. Non-effective does not mean nonexistent. The operation may be fully formed. The defining property is that it still cannot produce the protected effect.

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.

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.

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.

Execution Handle An Execution Handle is an act-bound, sink-bound, scope-bound authority object used by the Finality Sink during effectuation . 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.

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.

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.

Dynamic Trust Evaluation Is Not Execution Finality A dynamic trust API might consider: 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: The final operation may nevertheless drift: 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?

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: Graduated finality therefore changes the question from "Allow or deny?" to:

Under what bounded technical conditions may this consequence become effective?

Escalated Conditional Finality Workflow An escalated-but-allowable act follows a stronger execution path. The Candidate Act MUST remain non-effective throughout escalation. 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.

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: The Finality Sink MUST NOT accept the following, even if the originating agent remains fully trusted:

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. The Finality Sink SHOULD verify current-state congruence: If any mandatory component has changed, the result is NO EFFECT.

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. 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:

What exact act was proposed?
What exact consequence was authorized?
Under what scope was that consequence permitted?
What evidence supported that authorization?
Is the authorization still current?
Has the authority been revoked, consumed, replayed, or superseded?
Is this the intended recipient, resource, destination, jurisdiction, amount, tool, or actuator?
Were additional escalation conditions required?
Is the operation reaching the same trusted sink for which authority was issued?
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.

A Sink Without a Candidate Act Has Nothing Stable to Compare Consider a Finality Sink receiving the command: 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: 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. 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 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: 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.

A Sink Without Bound Authority Cannot Know What Was Permitted Suppose a sink receives a valid identity credential stating: 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.

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 (). A Finality Sink operating only on the presented request, without authoritative protected state, cannot reliably determine this.

A Sink Without Replay State Cannot Enforce Single-Use Authority An otherwise valid Execution Handle can become dangerous if it can be used repeatedly: 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.

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 (). The sink MUST reconstruct the operation using the parameters that will actually be consumed by the protected resource.

A Sink Without Consequence-Path Completeness Can Simply Be Bypassed 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 (; see also ).

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: The sink must verify these conditions. But those conditions first have to be:

identified;
derived from policy and consequence analysis;
converted into a narrower RCAE;
represented in an EASO or equivalent execution scope;
bound into the Execution Handle;
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.

The Finality Sink enforces escalation; it does not by itself supply the entire escalation architecture.

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: 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 (). 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 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: 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.

Finality Is a System Property, Not a Box The architecture should not be represented as: That diagram is too simple. It risks creating the impression that execution finality is merely another gateway. The fuller architecture is: 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.
Complete mediation prevents another route from bypassing the architecture.

The Finality Sink is therefore necessary but not independently sufficient.

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: 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.

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. 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.

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.

Terms Used in This Section

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.

EP-1: Cryptographic Execution Dependency Location: the Protected Enforcement Domain and the Finality Sink together.

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.
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.
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.
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.
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.
The Finality Sink holds a locked execution primitive that cannot complete the Candidate Act without completion material derived from the scoped execution authority.
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.

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.

EP-3: Commitment-Release Temporal Escrow Location: the Protected Enforcement Domain and the Finality Sink, for high-latency or delayed effectuation ().

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.

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 ().
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.

EP-5: Ephemeral Finality Sink Location: a temporary execution environment acting as the Finality Sink.

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.

EP-6: Proxy Enforcement for Legacy Interfaces Location: a protected proxy placed immediately before an existing effectuation interface ().

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.

EP-7: Modular Escalation Enforcement Location: the Protected Enforcement Domain and its escalation modules, for escalated-but-allowable acts ().

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.
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.

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 ().

EP-9: Assurance Profile with Anti-Downgrade Binding Location: the Protected Enforcement Domain, which selects the profile, and the Finality Sink, which applies it ().

The Protected Enforcement Domain selects one of at least three assurance profiles.
Low assurance: digest matching, nonce, scope, and epoch checks.
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.

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.

EP-11: Consequence-Class Inheritance Ceiling Location: every Protected Enforcement Domain in an agent chain (, ).

A Consequence-Class Inheritance Tag is bound into the released authority. It carries the maximum consequence class authorized at the originating decision.
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).

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.

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.
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.

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.

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.
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.

EP-16: Candidate-Act Authority versus Ordinary Permission Checks Location: the Finality Sink (, ). 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.

EP-17: First Usable Release Boundary Location: wherever the first usable release boundary actually lies (, ).

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.

EP-18: Fragmented, Transformed, and Delegated Act Equivalence Location: the Protected Enforcement Domain and the Finality Sink (, ).

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.
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.

EP-19: Emergency, Maintenance, and Fallback Path Closure Location: every path able to reach a Finality Sink or produce the consequence (, ).

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.

Enforcement-Point Summary

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

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.

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.

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.

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.

Security Model This section states the assumptions under which the properties in are claimed, and what the model deliberately excludes.

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 ().
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.
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.

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 ().

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.
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.

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:

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 . It is informal and is not a proof.

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 , , and .

Principal Threats

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

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.

Canonicalization Ambiguity Canonicalization is a security boundary. Suppose: 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: Ambiguous representations SHOULD fail closed.

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.

Revocation and Generation Fencing Revocation must remain effective at the execution boundary . 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: This avoids relying solely on the expiration time of an old token.

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.

Escalation Laundering Escalated authority must not become broader as it passes through an agent chain: 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.

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.

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 ().

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.

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.

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.

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.

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.

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 ().

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: Approval of INR 10,000 -> A MUST NOT authorize INR 100,000 -> B.

Finality-Sink Bypass Complete mediation is essential. Suppose the protected path is: 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 .

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;
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.

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.

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: An indeterminate high-impact consequence MUST NOT automatically be retried where retry could duplicate the effect. Durable receipts and transaction identifiers can assist recovery.

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: Receipt generation, nonce/counter updates, policy/revocation checking, and Execution Handle release may likewise participate in a protected atomic finality transaction.

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: The commitment object reserves state. It does not itself authorize the external consequence.

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.

Cold Preparation Path Operations that are reusable or time-tolerant SHOULD occur outside the per-act execution path:

Warm / Nearline Path Once a Candidate Act exists, act-specific work can begin before final effectuation:

Hot Finality Path The Finality Sink SHOULD perform only the checks that must be current at effectuation time: The architecture therefore does not require running full AI reasoning, full consequence simulation, or complete provenance analysis inside the critical sink path.

Latency Budget Model The per-act latency can be decomposed as:

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.

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.

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 (), 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.

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 .

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.

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 ().

Latency Proportional to Consequence Profiles may define different assurance classes: 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.

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.

Sink-Adjacent Proxy A legacy system may continue receiving conventional requests through a protected proxy: 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.

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.

Progressive Migration The architecture can therefore support stronger assurance over time without requiring immediate stack replacement.

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.

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.

Relationship to OAuth OAuth and fine-grained authorization, including Rich Authorization Requests , 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.

Relationship to Attestation Attestation 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.

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?

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:

derives a stricter consequence boundary;
selects additional controls;
binds those controls into execution authority;
requires the Finality Sink to verify the resulting escalated conditions before effectuation.

Difference from Candidate-Act Finality The Candidate-Act Finality draft 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 defines the object being controlled; this document defines the graduated release logic applied to that object.

Difference from the Agentic Effectuation Boundary The effectuation-boundary draft 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.

Difference from the AI Boundary Draft The AI boundary draft 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.

Difference from the Execution Handle Draft The Execution Handle draft 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: may become:

The Execution Handle draft defines how bounded authority is carried; this document defines how elevated risk changes that bounded authority.

Difference from Finality-Bound Revocation The finality-bound revocation draft 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.

Difference from State and Policy Continuity The state and policy continuity draft 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 (), 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.

Difference from Consequence-Path Completeness The consequence-path completeness draft 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 ( and ). 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.

Difference from Composite Execution Finality The composite execution finality draft 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.

Difference from Enforcement Profiles Enforcement-profile work 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: 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.

Difference from the Deployment Architecture The deployment draft 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:

The deployment draft explains how execution finality is deployed; this document defines how execution authority is dynamically strengthened or narrowed according to consequence risk.

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:

Escalation is not merely a different decision result. It changes the executable authority and the conditions under which effectuation becomes technically possible.

Architectural Position Within the Draft Family Each work item addresses a different layer rather than simply renaming the same control.

Specific Contribution of This Document This document defines a graduated execution-finality state machine in which:

a Candidate Act remains non-effective;
the act is classified according to consequence and risk;
an act may receive an outcome other than ordinary allow or deny;
an elevated-but-permissible act enters Escalated Conditional Finality;
the permitted consequence boundary is narrowed;
additional machine-verifiable controls are selected;
those controls are incorporated into the authority structure;
the resulting authority is bound to the Candidate Act and intended Finality Sink;
the Finality Sink independently verifies the escalated conditions against current protected state; and
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.

Receipts and Evidence A Finality Receipt can bind evidence to the resulting transition. A receipt may include: 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.

Multi-Agent Systems Authority becomes more difficult to track when one agent delegates to another: 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 ().

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.

Fail-Closed and Safe-Degraded Behavior 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.

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.

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.
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.

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.

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;
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.

Examples

Payment Suppose elevated value triggers escalation. The system may derive: 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.

SEND Escalation might require: 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.

Cloud Administration Dynamic trust may report: That does not automatically mean the privilege modification should be executed. Finality may additionally require:

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.

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 () 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.
Trust roots. Compromise of the Finality Sink or its hardware trust roots defeats the architecture ().
Interoperable encoding. There is no agreed wire format yet for Candidate Acts, escalation classes, Handles, or receipts ().
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 ().
Evaluation. There is no standard benchmark for comparing latency and assurance across implementations.

IETF-Relevant Questions This document invites technical discussion of the following questions:

Which parts are generic Internet architecture, and which must remain application-specific?
Can a common Candidate Act / Finality Receipt information model be useful without defining universal action semantics?
Can OAuth authorization details carry sufficient exact-act inputs for selected profiles?
Can RATS evidence describe trustworthy properties of Finality Sinks?
Can COSE provide interoperable protection for Candidate Acts, Handles, and receipts?
How should workload identity from WIMSE bind into act-level consequence authority?
How should semantic canonicalization profiles be negotiated?
How can implementations prove consequence-path completeness?
How should latency and assurance profiles be benchmarked?
How should distributed systems represent indeterminate external effects?
How can privacy-preserving receipts prove enforcement without revealing sensitive act contents?

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 );
fragmentation of an escalated act into sub-threshold acts;
classifier unavailable or timing out (expected: stricter class, never ordinary);
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.

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: . Covers exact-act binding, sink verification, replay/single-use behavior, canonicalization, concurrency, atomic consumption, and negative-control testing.
Composite Execution Finality Reference: . Composes execution-finality properties across distributed or multi-stage execution paths.
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: . Shows why identity and authorization alone are insufficient without exact beneficiary, amount, freshness, replay, and final execution controls.

Closely related Internet-Drafts are listed in the Informative References, in particular , , , and .

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:

Computation is not authority. Authorization is not consequence. Historical approval is not current execution authority.

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 and 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 (, ); stale policy and revocation (); replay and concurrent authority use (); snapshot rollback (); sink substitution; agent-chain escalation laundering (); human-approval replay (); proxy bypass and administrative bypass (); sink compromise (); verification exhaustion (); crash ambiguity (); side channels; receipt forgery; and recovery behavior. The assumptions, adversary capabilities, and invariants under which the properties are claimed are stated in . 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 . Conformance can be assessed per enforcement point (); 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 and . Limits that remain unsolved are listed in . Security evaluation should include adversarial and negative tests, not only successful execution tests (). 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.

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.

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.

References Normative References Key words for use in RFCs to Indicate Requirement Levels Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words Informative References The OAuth 2.0 Authorization Framework OAuth 2.0 Rich Authorization Requests Remote ATtestation procedureS (RATS) Architecture CBOR Object Signing and Encryption (COSE): Structures and Process Execution-Finality Architecture for AI and Autonomous Critical Systems When AI Agents Hold the Keys: Threat Model and Execution-Finality Requirements for Autonomous High-Consequence Systems Possession Is Not Authority: Execution Handles for Exact-Act, Sink-Bound Execution Authority Partial Commit Is Not Finality: Composite Execution Finality Candidate-Act Execution Finality An Execution Interlock at the AI Model-to-External-Effect Boundary Revoked but Still Executable: Closing the Authorization-to-Effect Gap with Finality-Bound Revocation When Valid Authorization Becomes Stale: State and Policy Continuity at the Execution-Finality Boundary When the Gate Can Be Bypassed: Consequence-Path Completeness for Execution Finality Execution-Finality Enforcement Profiles

Alternative Titles This appendix is informative. It lists alternative descriptive titles under which the architecture in this document may be referenced or discovered:

Graduated and Escalated Conditional Execution Finality for AI Agents and Autonomous Systems
Graduated Runtime Authorization for AI Agents and Autonomous Systems: Escalated Conditional Execution Finality for Elevated-Risk Actions
Runtime Authorization and Execution Control for AI Agents and Autonomous Systems
Continuous Authorization and Execution Finality for High-Risk AI Agent Actions
AI Agent Security: Runtime Authorization and Final Execution Control for High-Consequence Actions
Graduated Authorization for AI Agents: Conditional Execution Control at the Effectuation Boundary
Risk-Based Authorization and Execution Finality for Autonomous AI Systems
Zero-Trust Execution Control for AI Agents and High-Risk Autonomous Actions
Execution-Time Policy Enforcement for AI Agents and Autonomous Systems
Conditional Authorization and Final Effectuation Control for Agentic AI
High-Assurance Runtime Authorization for AI Agents, Autonomous Systems, and Critical Infrastructure