Execution-Finality Architecture for AI and Autonomous Critical Systems
draft-das-execution-finality-deployment-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Sangam Das | ||
| Last updated | 2026-09-22 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Android and Apple/Siri: A Simple Explanation of How Phones Could Let AI Assistants Work Together Safely — European AI Alliance / Futurium
The Internet Solved Communication. It Never Solved Authority — Zenodo |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-das-execution-finality-deployment-01
Network Working Group S. K. Das
Internet-Draft Independent Researcher
Intended status: Informational 22 September 2026
Expires: 26 March 2027
Execution-Finality Architecture for AI and Autonomous Critical Systems
draft-das-execution-finality-deployment-01
Abstract
AI models, agents, and autonomous services increasingly initiate
payments, communications, data releases, infrastructure changes, and
physical actions in critical systems. Authentication, authorization,
human approval, proof of possession, attestation, policy evaluation,
and audit are important, but none of them alone establishes that the
exact operation becoming externally effective is the operation that
was authorized and remains permitted under current protected state.
This document defines an execution-finality architecture in which a
proposed operation remains non-effective until a mandatory
enforcement function controlling the effectuation boundary
reconstructs the actual operation, verifies exact-act binding and
current protected state, prevents replay or stale authority, and
couples the decision to the resulting consequence through an atomic
or equivalently crash-consistent transition. The document explains
why latency is only one engineering consideration and is often not
the dominant problem. Consequence-path completeness, deterministic
act representation, protected state, atomicity, crash recovery, safe
degraded operation, and legacy-system integration are usually harder
requirements.
A detailed FAQ addresses whether placing OAuth at the last
irreversible execution boundary is the same architecture. It is not
automatically equivalent merely because a token, scope, or sender-
constrained proof is checked at that location. An OAuth-protected
implementation is functionally equivalent only when it also
exclusively mediates every consequence path, reconstructs and binds
all consequence-relevant fields, revalidates authoritative current
state, enforces replay and generation controls, atomically couples
authorization consumption to the exact effect, and provides safe
failure and recovery semantics. In that case, the implementation is
functioning as the Finality Sink, regardless of terminology. The
document also identifies the division of responsibility and possible
relevance of OAuth, RATS, WIMSE, Web Bot Auth, other IETF
communities, and longer-term IRTF research. This document is
architectural and informational; it does not define a wire protocol.
Das Expires 26 March 2027 [Page 1]
Internet-Draft Execution-Finality Architecture September 2026
Discussion Venue
Discussion of this document is intended to determine whether further
work belongs in an existing security, authorization, attestation,
workload-identity, or application-area venue, or requires cross-area
dispatch. Repository and issue-tracker information may be added in a
later revision.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Problem, Existing Mechanisms, Residual Gap, and Delta . . 4
1.2. Industry-Standard Terminology and Functional
Equivalence . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Clear Differentiation from Traditional Systems and Their
Combination . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 9
Das Expires 26 March 2027 [Page 2]
Internet-Draft Execution-Finality Architecture September 2026
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Architectural Model . . . . . . . . . . . . . . . . . . . . . 10
4. Deployment Requirements . . . . . . . . . . . . . . . . . . . 11
4.1. Consequence-Path Completeness . . . . . . . . . . . . . . 11
4.2. Deterministic Exact-Act Representation . . . . . . . . . 11
4.3. Protected Current State . . . . . . . . . . . . . . . . . 12
4.4. Atomic Check, Consumption, and Effectuation . . . . . . . 12
4.5. Freshness, Replay, and Generation Control . . . . . . . . 12
4.6. Crash Consistency and Outcome Recovery . . . . . . . . . 13
4.7. Availability and Safe Degraded Operation . . . . . . . . 13
5. Latency Analysis . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Measurement Requirements . . . . . . . . . . . . . . . . 14
6. Addressing Practical Deployment Concerns . . . . . . . . . . 14
6.1. Latency Cost in High-Criticality Systems . . . . . . . . 14
6.2. Legacy Architecture and Deployment Complexity . . . . . . 15
7. Problems That Are Often Harder Than Latency . . . . . . . . . 17
8. Relationship to Existing IETF Mechanisms and Communities . . 17
8.1. FAQ: If OAuth Is Enforced at the Final Effectuation
Boundary, Is That the Same Architecture? . . . . . . . . 18
8.2. OAuth and Fine-Grained Authorization . . . . . . . . . . 19
8.3. HTTP Preconditions . . . . . . . . . . . . . . . . . . . 19
8.4. Remote Attestation . . . . . . . . . . . . . . . . . . . 20
8.5. COSE and Protected Objects . . . . . . . . . . . . . . . 20
8.6. WIMSE and Workload-to-Workload Paths . . . . . . . . . . 20
8.7. Web Bot Auth and Automated Web Clients . . . . . . . . . 21
8.8. IRTF and the Internet Research Community . . . . . . . . 21
8.9. Cross-Area Dispatch and Possible Work Products . . . . . 22
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Automated Payment . . . . . . . . . . . . . . . . . . . . 23
9.2. Message or File SEND . . . . . . . . . . . . . . . . . . 23
9.3. Physical or Infrastructure Actuation . . . . . . . . . . 23
10. Illustrative Deployment Profiles . . . . . . . . . . . . . . 23
11. Reference Implementation and Adversarial Validation . . . . . 24
12. Illustrative Binding Representation Profiles . . . . . . . . 25
12.1. Illustrative Financial Command in JSON . . . . . . . . . 25
12.2. Illustrative Cloud Privileged Command in JSON . . . . . 26
12.3. Illustrative CBOR/CDDL Shape . . . . . . . . . . . . . . 26
13. Open Questions for IETF Discussion . . . . . . . . . . . . . 27
14. Possible Next Research Directions . . . . . . . . . . . . . . 28
15. Security Considerations . . . . . . . . . . . . . . . . . . . 29
15.1. Specific Sink Attack and Failure Modes . . . . . . . . . 29
16. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
18. Additional Disclosures and Implementation Resources . . . . . 30
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 31
Normative References . . . . . . . . . . . . . . . . . . . . . . 31
Informative References . . . . . . . . . . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32
Das Expires 26 March 2027 [Page 3]
Internet-Draft Execution-Finality Architecture September 2026
1. Introduction
Networked systems are good at transporting requests and establishing
authenticated channels. Authorization systems can express what a
principal may request. Proof-of-possession mechanisms can bind use
of a credential to a key. Attestation can provide evidence about the
operating state of a component. Conditional requests and concurrency
controls can prevent some stale updates. These mechanisms remain
necessary.
However, an authorized request is not necessarily identical to the
consequence that is finally produced. Between authorization and
effectuation, parameters can be substituted, state can change,
authority can be revoked, a request can be replayed, a downstream
component can reinterpret data, a crash can create an ambiguous
outcome, or an alternate path can bypass the intended enforcement
point.
This distinction becomes more important when an AI agent, workflow
engine, or autonomous service can cause high-impact consequences. A
well-authenticated and properly authorized agent can still be
mistaken, manipulated, compromised, stale, or operating on an
inaccurate representation of the intended act.
An execution-finality architecture therefore keeps a candidate
operation non-effective until the component controlling the
consequence independently determines that the exact operation about
to become effective remains permitted under current protected
authorization and system state. The determination is coupled to the
state transition so that the verified operation cannot be replaced or
replayed between check and commit.
1.1. Problem, Existing Mechanisms, Residual Gap, and Delta
Vulnerability:
An operation may be validly requested or authorized while the
final effect differs from, outlives, duplicates, or bypasses that
authority.
Existing mechanisms:
OAuth, fine-grained authorization, sender-constrained tokens,
workload identity, secure channels, remote attestation, policy
engines, reference monitors, safety interlocks, idempotency keys,
conditional requests, database transactions, and audit logs each
address important portions of the problem.
Das Expires 26 March 2027 [Page 4]
Internet-Draft Execution-Finality Architecture September 2026
Why the gap can remain:
These mechanisms do not, merely by being present, prove that one
non-bypassable component reconstructed the actual act, compared it
with current protected state, consumed replay-sensitive authority,
and committed the exact consequence as one crash-consistent
transition.
Architectural delta:
Place a mandatory enforcement function at the last component able
to prevent the consequence; bind authorization to a deterministic
representation of the exact act; revalidate current protected
state; and couple allow, consumption, effectuation, and evidence
generation.
1.2. Industry-Standard Terminology and Functional Equivalence
The term _Finality Sink_ denotes a function, not necessarily a new
appliance. Depending on the system, an equivalent implementation
might be called a policy enforcement point, reference monitor,
transaction coordinator, commit gate, command gate, actuation
interlock, egress guard, storage commit hook, kernel mediation point,
or hardware-enforced control point.
The defining property is placement and control: the function is on
every relevant consequence path and retains the ability to prevent
the effect. A policy engine that advises another component is not
functionally equivalent unless its decision cannot be ignored or
replaced before effectuation.
An _execution handle_ can be implemented as a bounded capability,
transaction authorization object, signed or MAC-protected command
envelope, one-time permit, or another non-bearer or sender-
constrained object. Its name and encoding are secondary to its
function: it binds authority to an exact act and to freshness,
destination, generation, and consumption constraints that the
enforcing sink can verify.
_Non-Effective State_ means that preparation, computation,
simulation, staging, or preview has not yet produced the protected
external consequence. An operation can exist in queues, memory, or a
user interface while remaining non-effective if no bypass path can
publish, transmit, commit, transfer, actuate, or render it as the
protected effect.
_Exact-act binding_ corresponds to cryptographic parameter binding
over a deterministic representation of all consequence-relevant
fields. _Current-state revalidation_ corresponds to checking
protected policy, authorization generation, revocation, quota,
Das Expires 26 March 2027 [Page 5]
Internet-Draft Execution-Finality Architecture September 2026
resource version, and replay state immediately within the protected
commit procedure. _Atomic effectuation_ corresponds to a TOCTOU-
resistant check-and-commit transition or an equivalent protocol whose
failure modes do not create an unverified effect.
1.3. Clear Differentiation from Traditional Systems and Their
Combination
Execution finality does not depend on inventing a new name for every
underlying mechanism. An implementation may reuse identity systems,
OAuth, policy engines, capabilities, remote attestation, reference
monitors, database transactions, idempotency controls, trusted
hardware, safety interlocks, and audit logs. The architectural
distinction is the required relationship among those components at
the consequence boundary.
Das Expires 26 March 2027 [Page 6]
Internet-Draft Execution-Finality Architecture September 2026
TRADITIONAL ASSURANCE INPUTS
+----------+ +-------------+ +------+ +-------------+
| Identity | | OAuth / RAR | | RATS | | Web Bot Auth|
| / WIMSE | | / DPoP | | | | |
+----------+ +-------------+ +------+ +-------------+
\ | | /
\ | | /
+-----------+------------+-----------+
|
+------v-------+
| Candidate Act| NON-EFFECTIVE
| + evidence | STATE
+------+-------+
|
v
=========== LAST PREVENTABLE / EFFECTUATION BOUNDARY ==========
|
+--------------v--------------------------------+
| FINALITY SINK |
| |
| 1. Reconstruct the actual semantic act |
| 2. Verify exact-act binding |
| 3. Check current protected state |
| 4. Check revocation, generation, and replay |
| 5. Atomically consume authority and commit |
| 6. Record a crash-resolvable outcome |
+--------------+--------------------------------+
|
ALLOW ----+---- DENY / SAFE FAILURE
|
v
+----------------------------------+
| EXTERNALLY EFFECTIVE CONSEQUENCE |
| Payment / SEND / Write / Actuate |
+----------------------------------+
Identity, authorization, attestation, and bot authentication
inform the decision. They do not replace boundary enforcement.
Figure 1: Traditional assurance inputs and the execution-finality
boundary
Das Expires 26 March 2027 [Page 7]
Internet-Draft Execution-Finality Architecture September 2026
+================+====================+============================+
| Traditional | What it normally | What still has to be |
| component or | establishes | established |
| combination | | |
+================+====================+============================+
| Authentication | Who or which | Whether the exact act |
| or workload | workload is making | becoming effective is |
| identity | a request | currently permitted |
+----------------+--------------------+----------------------------+
| OAuth token, | Delegated | Exact consequence |
| scope, RAR, or | authority, | reconstruction, current- |
| sender | authorization | state revalidation, one- |
| constraint | details, or | time consumption, and |
| | possession by the | atomic effectuation |
| | intended presenter | |
+----------------+--------------------+----------------------------+
| API gateway or | Policy enforcement | Whether downstream |
| policy | at an ingress or | transformation, queues, |
| enforcement | service boundary | retries, storage, |
| point | | alternate egress, and |
| | | administrative paths |
| | | remain completely mediated |
+----------------+--------------------+----------------------------+
| Remote | Evidence that a | Evidence that this exact |
| attestation or | component is in an | act was checked against |
| trusted | appraised | current authority and |
| execution | operating state | coupled to its consequence |
| evidence | | |
+----------------+--------------------+----------------------------+
| Database | Atomicity and | Whether the transaction |
| transaction or | durability for | includes authorization |
| atomic commit | participating | consumption and the actual |
| | state changes | external consequence, with |
| | | no unmediated side effect |
+----------------+--------------------+----------------------------+
| Idempotency or | Repeated requests | Whether the key is bound |
| duplicate | with a recognized | to the authorized exact |
| suppression | key do not create | act and cannot be |
| | repeated | substituted, reset, or |
| | processing | bypassed |
+----------------+--------------------+----------------------------+
| Audit log, | Detection, | Prevention of an |
| SIEM, or post- | investigation, or | unauthorized effect and |
| event | accountability | unambiguous crash-time |
| monitoring | after processing | outcome recovery |
+----------------+--------------------+----------------------------+
| Safety | Mandatory | Whether its scope covers |
| interlock or | mediation within | every consequence path and |
Das Expires 26 March 2027 [Page 8]
Internet-Draft Execution-Finality Architecture September 2026
| reference | its defined scope | whether it binds current |
| monitor | | authority to the exact |
| | | semantic act |
+----------------+--------------------+----------------------------+
Table 1: Traditional guarantees and the residual execution-
finality question
Combining traditional components does not automatically close these
gaps. Security properties are not necessarily compositional: a valid
token can be checked by a correctly attested gateway, followed by a
valid database transaction, while a downstream worker changes the
destination, retries after revocation, or produces an external side
effect outside that transaction. Every component can work as
designed while the end-to-end consequence remains insufficiently
controlled.
The differentiating invariant is:
| No protected consequence may become effective unless one non-
| bypassable enforcement procedure reconstructs the actual semantic
| act, verifies its exact binding to current protected authority and
| state, consumes replay-sensitive authority, and commits that exact
| consequence with defined crash semantics.
A traditional implementation or combination of traditional components
that satisfies this invariant is functionally equivalent to the
architecture described here. The difference is not branding or
component novelty; it is whether the complete end-to-end property is
specified, testable, and, where required across a trust boundary,
externally supportable by evidence.
1.4. Scope and Non-Goals
This document does not claim that OAuth, remote attestation, proof of
possession, conditional requests, database transactions, or existing
safety controls are defective. It identifies the additional
composition and placement properties required when those mechanisms
are used to control an externally meaningful consequence.
This document does not define a universal canonicalization format,
authorization language, ledger, consensus algorithm, trusted
execution environment, or wire protocol. It also does not assert
that every operation requires identical assurance or latency.
Deployments are expected to select profiles proportional to
consequence and threat.
Das Expires 26 March 2027 [Page 9]
Internet-Draft Execution-Finality Architecture September 2026
2. Terminology
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this
document are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown
here.
Candidate Act:
A fully parameterized operation proposed for effectuation but not
yet accepted as the protected external consequence.
Effectuation Boundary:
The last system boundary at which the protected consequence can
still be prevented.
Finality Sink (FS):
The mandatory function controlling the Effectuation Boundary and
deciding whether the Candidate Act may become effective.
Binding Representation:
A deterministic representation of all consequence-relevant fields
used to bind authority to the Candidate Act.
Protected State:
Authorization, revocation, generation, quota, replay, resource-
version, and policy state that an untrusted proposer cannot
undetectably modify.
Finality Receipt:
Evidence identifying the verified act, decision context, relevant
state version, outcome, and, where appropriate, the resulting
state transition.
3. Architectural Model
A proposer constructs a Candidate Act. Authorization services,
policy engines, human approvals, and attestation services may
contribute evidence. The Candidate Act remains non-effective until
the Finality Sink reconstructs the act from the parameters actually
presented to the protected resource or actuator.
Das Expires 26 March 2027 [Page 10]
Internet-Draft Execution-Finality Architecture September 2026
Proposer / Agent
|
| Candidate Act + authority + evidence
v
Preparation / Queue / Preview (non-effective)
|
v
+-----------------------------------------------+
| Finality Sink at Effectuation Boundary |
| reconstruct -> bind -> check current state |
| -> consume authority -> commit -> receipt |
+-----------------------------------------------+
|
v
Payment / SEND / Write / Actuation / Publication
(externally effective)
Figure 2: Abstract effectuation flow
The Finality Sink need not repeat every upstream policy computation.
It needs sufficient trusted inputs and protected state to determine
that the actual act is within the current authorization. It also
needs exclusive or complete mediation over the protected consequence
path.
4. Deployment Requirements
4.1. Consequence-Path Completeness
Every path capable of producing the protected consequence MUST pass
through an equivalent enforcement decision. This includes
administrative interfaces, retry workers, batch jobs, direct database
access, fallback transports, local IPC, alternate network egress,
maintenance modes, and recovery procedures.
A deployment SHOULD maintain a consequence-path inventory and test
negative controls that attempt effectuation without required
evidence. The expected result is denial without a protected external
effect.
4.2. Deterministic Exact-Act Representation
The Binding Representation MUST cover every field that can materially
change the consequence. Examples include operation type, resource,
destination, amount or quantity, content digest, purpose, tenant,
jurisdiction, expiry, permitted transformation, and relevant resource
version.
Das Expires 26 March 2027 [Page 11]
Internet-Draft Execution-Finality Architecture September 2026
Canonicalization rules MUST be deterministic across participating
implementations. Deployments MUST NOT treat unknown fields as absent
when an unknown field can affect interpretation. Aliases, redirects,
Unicode normalization, number formats, time zones, content
transformations, and downstream default values require explicit
treatment.
4.3. Protected Current State
The sink MUST evaluate the act against an authoritative state that
the proposer cannot forge. At minimum, the state needed for the
selected profile can include authorization generation, revocation,
expiry, replay or consumption status, quota, resource version, policy
version, and operational mode.
Cached state MAY be used where bounded staleness is explicitly
accepted. The profile MUST define the maximum permitted staleness
and the consequence of uncertainty. Missing state is not equivalent
to an empty or permissive state.
4.4. Atomic Check, Consumption, and Effectuation
The authorization decision, replay-sensitive consumption, and
effectuation MUST be coupled so that a concurrent update or crash
cannot substitute an unchecked act or create multiple effects. A
local database transaction, compare-and-swap, transactional outbox,
hardware state transition, consensus transaction, or application-
specific commit protocol may provide this property.
Where the consequence cannot participate in the same atomic
transaction, the deployment MUST specify an equivalent state machine,
idempotency rule, reconciliation procedure, and durable outcome
classification. Merely writing an audit record before or after an
unrelated side effect is insufficient.
4.5. Freshness, Replay, and Generation Control
A high-impact execution authorization SHOULD be bounded by expiry,
nonce or unique identifier, authorization generation, destination,
and permitted use count. Single-use authority MUST be consumed in a
concurrency-safe manner.
Proof of possession, such as DPoP [RFC9449], reduces the usefulness
of stolen tokens but does not by itself establish that the key holder
is executing the exact currently permitted consequence. Sender
constraint and exact-act finality are complementary properties.
Das Expires 26 March 2027 [Page 12]
Internet-Draft Execution-Finality Architecture September 2026
4.6. Crash Consistency and Outcome Recovery
After restart, the system MUST distinguish at least: not committed,
committed exactly once, denied, and indeterminate. An indeterminate
outcome MUST NOT be automatically retried when retry could duplicate
an irreversible consequence.
Receipts and recovery records SHOULD bind the Candidate Act digest,
decision, protected-state generation, consumption record, sink
identity where relevant, and resulting transaction or consequence
identifier.
4.7. Availability and Safe Degraded Operation
Fail-closed behavior prevents uncertain authority from becoming an
effect, but it can reduce availability. A deployment MUST define
behavior for loss of policy service, clock, revocation feed,
attestation service, protected storage, or network connectivity.
Emergency or degraded modes MUST NOT silently become bypass modes.
They require separately bounded authority, narrowed operations, short
lifetimes, durable evidence, and explicit recovery semantics.
Safety-critical systems may define a domain-specific fail-safe action
that differs from simply doing nothing.
5. Latency Analysis
Verification adds work to the critical path, but raw cryptographic
verification is only one component. A useful latency budget is:
T(finality) = T(parse/canonicalize) + T(cryptographic verification) +
T(state lookup) + T(policy check) + T(contention) + T(commit) +
T(evidence)
In many deployments, remote state lookup, lock contention, durable
storage, consensus, and downstream commit dominate signature or MAC
verification. Therefore, reporting only cryptographic operations per
second is not sufficient.
Implementations can reduce latency through sink-local protected
state, prevalidated policy snapshots, bounded capabilities, hardware
acceleration, batching where semantics permit, sharding replay state,
and avoiding synchronous remote calls. Precomputation MUST NOT
freeze a decision that depends on mutable state unless the accepted
staleness is explicit.
Das Expires 26 March 2027 [Page 13]
Internet-Draft Execution-Finality Architecture September 2026
Latency optimization cannot remove a required field from exact-act
binding, weaken freshness below the selected profile, or separate
verification from commit in a way that reintroduces a time-of-check/
time-of-use gap.
5.1. Measurement Requirements
Evaluation SHOULD report median and tail latency, throughput,
contention level, protected-state locality, durability mode, failure
rate, recovery time, and the number of consequence paths tested.
Benchmarks SHOULD include replay, revocation races, concurrent use,
crash injection, stale state, malformed representations, and
attempted bypass.
A fast implementation that does not completely mediate the
consequence path is not an execution-finality implementation for that
consequence.
6. Addressing Practical Deployment Concerns
6.1. Latency Cost in High-Criticality Systems
Introducing cryptographic verification, freshness checks, replay
protection, protected-state lookup, and exact-act validation at an
execution boundary can add processing overhead.
Execution-finality architecture is primarily intended for high-
criticality systems and high-consequence operations, where some
bounded additional latency may be acceptable if it materially reduces
the risk of catastrophic, irreversible, or safety-critical
consequences.
In such environments, the relevant engineering trade-off is not
simply maximum speed. It is whether a small and bounded verification
delay is preferable to an unauthorized action that could cause
financial loss, infrastructure disruption, data exfiltration, unsafe
physical actuation, or other catastrophic consequences.
For example, an additional verification step may be acceptable
before:
* transferring a large financial value;
* sending highly sensitive data to an external destination;
* changing a power-grid configuration;
* issuing an industrial-control command;
Das Expires 26 March 2027 [Page 14]
Internet-Draft Execution-Finality Architecture September 2026
* modifying critical telecommunications routing;
* committing a privileged cloud action; or
* releasing a safety-critical autonomous-system command.
The architecture does not assume that every operation requires the
same verification depth, nor that every check must use expensive
public-key cryptography. The relevant engineering question is
therefore not whether execution finality has zero latency, but
whether the added latency is proportionate to the consequence being
protected.
Deployments can reduce overhead through mechanisms such as hardware-
assisted verification, symmetric MACs where appropriate, cached or
prevalidated policy state, compact bounded execution capabilities,
monotonic counters, generation epochs, local protected-state
verification, precomputation, batching, and selective enforcement
based on consequence sensitivity.
The architecture therefore does not require placing an expensive
cryptographic transaction in the critical path of every CPU
instruction or memory access. The Finality Sink should be positioned
at the meaningful effectuation boundary where an operation acquires
external, persistent, privileged, safety-relevant, or otherwise
material consequence.
This distinction is important. A system may perform millions of
speculative or internal computations without finality checks, while
requiring final verification only when an operation crosses into a
protected consequence.
| For high-criticality systems, bounded latency is often an
| acceptable engineering cost; catastrophic consequence is not.
6.2. Legacy Architecture and Deployment Complexity
Retrofitting existing enterprise systems, operating systems,
telecommunications infrastructure, industrial systems, and hardware
platforms with mandatory execution-finality enforcement can be
difficult. A universal immediate redesign of existing infrastructure
would be unrealistic.
Execution finality should therefore be understood as a deployable
architectural pattern rather than a requirement for simultaneous
replacement of entire technology stacks.
Das Expires 26 March 2027 [Page 15]
Internet-Draft Execution-Finality Architecture September 2026
In many environments, the enforcement point can initially be
introduced at existing choke points, including API gateways, service
meshes, database commit paths, payment gateways, secure proxies,
storage controllers, egress gateways, network control interfaces,
hypervisors, privileged system services, hardware security modules,
trusted execution environments, industrial control gateways, and
telecom policy or signaling enforcement points.
This allows incremental deployment. A legacy application may
continue generating requests in its existing form while a new
enforcement component verifies whether the exact requested
consequence remains authorized before the irreversible operation is
committed.
Legacy application / AI agent
|
| existing request
v
Compatibility / enforcement gateway
|
v
Execution-finality verification
|
+-----+-----+
| |
ALLOW DENY
| |
v v
Existing No protected
backend effectuation
Figure 3: Incremental enforcement for a legacy deployment
This permits deployment without requiring every upstream component to
be rewritten immediately.
Over time, tighter integration can move the enforcement point closer
to the true consequence boundary, for example, from an application
gateway to a storage controller, network interface, device firmware,
secure processor, or hardware execution boundary.
The practical migration path is gateway enforcement to native system
integration to hardware-assisted enforcement, where justified by the
risk and performance requirements.
Das Expires 26 March 2027 [Page 16]
Internet-Draft Execution-Finality Architecture September 2026
The presence of deployment difficulty does not remove the underlying
security problem. It instead means that execution-finality
mechanisms should support staged adoption, backward compatibility,
multiple enforcement profiles, and progressively stronger assurance
levels.
7. Problems That Are Often Harder Than Latency
Boundary identification:
The apparent API endpoint may not be the last preventable point.
Queues, proxies, schedulers, databases, device firmware, and
downstream providers can move the true boundary.
Legacy integration:
Existing systems may expose no transactional hook spanning
authorization consumption and the protected consequence.
Semantic agreement:
Different services may interpret the same field differently,
making a shared digest misleading unless the semantics are
versioned and testable.
Operational ownership:
No single operator may control the authorization service,
transport, final resource, and audit system. Cross-domain
assurance requires explicit trust and failure contracts.
Administrative bypass:
Privileged maintenance paths can invalidate complete mediation
unless they are included in the threat model and evidence model.
Availability policy:
Operators must decide which consequences stop, degrade, or enter a
separately authorized emergency mode when verification
dependencies fail.
Assurance evidence:
A relying party needs evidence of the sink's placement and
behavior, not merely evidence that an upstream service issued an
authorization.
8. Relationship to Existing IETF Mechanisms and Communities
Das Expires 26 March 2027 [Page 17]
Internet-Draft Execution-Finality Architecture September 2026
8.1. FAQ: If OAuth Is Enforced at the Final Effectuation Boundary, Is
That the Same Architecture?
*It can be functionally equivalent, but boundary placement alone does
not make it equivalent.* If an implementation merely validates an
OAuth access token, its scopes, or a sender-constrained proof at the
last API endpoint, it establishes that the requester is entitled to
make a class of requests. It does not necessarily establish that the
exact consequence about to occur is identical to what was authorized,
remains permitted under current protected state, has not already been
consumed, and will be committed without a substitution or time-of-
check/time-of-use gap.
An OAuth-protected resource server at the final boundary is
functionally equivalent to an execution-finality architecture for a
defined consequence if, and only if, it also:
* exclusively mediates every path capable of producing that
consequence;
* reconstructs the actual operation from the parameters that the
protected resource, ledger, egress mechanism, or actuator will
use;
* binds and compares all consequence-relevant fields, including
destination and permitted transformations, against the granted
authorization;
* checks authoritative current revocation, generation, expiry,
quota, resource-version, and replay state as required by the
selected profile;
* atomically couples the allow decision, any single-use consumption,
and the exact effectuation, or supplies an equivalent crash-
consistent transaction protocol; and
* fails safely and produces durable evidence sufficient to resolve
committed, denied, and indeterminate outcomes.
Das Expires 26 March 2027 [Page 18]
Internet-Draft Execution-Finality Architecture September 2026
When all of these properties are present, the difference is
terminological rather than functional: that OAuth deployment is
acting as the Finality Sink. OAuth supplies the authorization
framework and may carry fine-grained authorization data or proof-of-
possession evidence; the application-specific enforcement and
transaction design supplies the execution-finality semantics.
Conversely, describing atomicity, complete mediation, or fail-closed
behavior as an internal design choice does not make those properties
verifiable across a trust boundary. A relying party can claim
equivalence only to the extent that the deployment profile specifies
and, where required, evidences them.
8.2. OAuth and Fine-Grained Authorization
Rich Authorization Requests [RFC9396] can express fine-grained
authorization details. DPoP [RFC9449] can sender-constrain tokens.
These can supply authority and proof inputs to a Finality Sink.
They are not automatically execution finality because a deployment
still needs to define which exact fields are bound, how the sink
reconstructs the actual consequence, which protected state is
current, how single use is consumed, and how decision and
effectuation are coupled. If one resource server already performs
all these functions at the irreversible boundary, it may be
functionally equivalent regardless of terminology.
The relevance to the OAuth Working Group
(https://datatracker.ietf.org/wg/oauth/about/) is primarily at the
authorization interface: how transaction-specific details, resource
identity, sender constraint, freshness, and authorization-server
state are conveyed to a protected resource. Application-specific
canonicalization, physical actuation, database atomicity, and crash
recovery are not automatically OAuth protocol problems. A useful
OAuth-related output could therefore be a precise statement of which
execution-finality inputs an OAuth profile carries and which
guarantees remain the responsibility of the resource server and its
commit path.
8.3. HTTP Preconditions
The If-Match mechanism in [RFC9110] can prevent a method from being
applied when the current representation no longer matches a supplied
entity tag. This is a useful state-continuity primitive. It does
not by itself bind all authorization, destination, replay, and
downstream-effect semantics, but it may form part of a finality
profile.
Das Expires 26 March 2027 [Page 19]
Internet-Draft Execution-Finality Architecture September 2026
8.4. Remote Attestation
The RATS architecture [RFC9334] supports appraisal of evidence about
whether an attester is in an intended operating state. Such
Attestation Results can inform whether a sink or proposer is
acceptable. Attestation of software or platform state is not
identical to evidence that one exact act was checked against current
authority and atomically effected. A useful integration would bind
the sink's attested identity and security version to its Finality
Receipt.
The relevance to the RATS Working Group
(https://datatracker.ietf.org/wg/rats/about/) is whether Evidence,
Reference Values, Endorsements, or Attestation Results can describe
trustworthy properties of a Finality Sink, such as approved code
identity, protected-state support, rollback resistance, and
enforcement configuration. The architecture must keep two claims
distinct: attestation can support confidence that a sink has certain
properties, while a Finality Receipt concerns the sink's processing
of a particular act and consequence.
8.5. COSE and Protected Objects
COSE [RFC9052] can protect an execution authorization, Binding
Representation, or receipt. COSE supplies cryptographic containers
and algorithms; application profiles still need to specify semantics,
mandatory fields, canonicalization, critical parameters, freshness,
and consumption behavior.
8.6. WIMSE and Workload-to-Workload Paths
The Workload Identity in Multi-System Environments (WIMSE)
(https://datatracker.ietf.org/wg/wimse/about/) work addresses
identity and access-management problems for workloads at runtime
across service and cloud boundaries. WIMSE can help establish which
workload is calling, its execution context, how workload credentials
are presented, and how service-to-service trust is constructed.
Execution finality addresses the adjacent question of what exact
consequence that authenticated workload may cause now. A multi-
service path can preserve workload identity while still allowing
parameter drift, stale authorization, replay, a changed destination,
or a side effect outside the protected transaction. A useful
integration point is to bind WIMSE workload identity and relevant
execution-context claims into the exact-act authorization and receipt
while leaving application-specific consequence semantics to the final
resource or actuator.
Das Expires 26 March 2027 [Page 20]
Internet-Draft Execution-Finality Architecture September 2026
This document does not assert that general transaction or actuation
semantics fall within the WIMSE charter. The relevance is the
interface between trustworthy workload identity and enforcement of a
workload's exact externally effective act.
8.7. Web Bot Auth and Automated Web Clients
The Web Bot Authentication (webbotauth)
(https://datatracker.ietf.org/wg/webbotauth/about/) work focuses on
cryptographically authenticating automated clients and providing
additional information about their operators to Web sites. This is
directly useful for establishing bot identity, provenance,
accountability, and site policy inputs.
Bot authentication does not by itself determine whether a particular
purchase, publication, account modification, data export, message
SEND, or other irreversible Web action remains authorized in its
final form. A correctly authenticated bot can be compromised,
confused, stale, or acting outside a transaction-specific grant.
Execution finality can consume authenticated bot and operator
information as inputs, then bind them to the actual resource,
destination, content, action, current site state, and commit result.
The possible community contribution is not to expand Web Bot Auth
into a universal transaction protocol. It is to ensure that bot-
authentication outputs can be securely carried into resource-specific
enforcement and are not mistaken for proof that the final consequence
was authorized.
8.8. IRTF and the Internet Research Community
Some questions raised here are architectural or empirical rather than
ready for immediate protocol standardization. They include formal
models for exact-act equivalence, composition of independently
correct security controls, proof of consequence-path completeness,
latency and availability tradeoffs, crash-time ambiguity, cross-
operator verification, and privacy-preserving finality evidence.
The Internet Research Task Force (IRTF) (https://www.irtf.org/), its
open discussions, and the Applied Networking Research Workshop can
provide venues for research and measurements without prematurely
assigning a standards solution. Depending on the use case, more
focused discussion could also be relevant to:
* the Thing-to-Thing Research Group (T2TRG), where autonomous agents
interact with constrained devices and physical effects;
Das Expires 26 March 2027 [Page 21]
Internet-Draft Execution-Finality Architecture September 2026
* the Network Management Research Group (NMRG), where agentic
systems can change operational network state;
* the Privacy Enhancements and Assessments Research Group (PEARG),
for privacy leakage and minimization in receipts and protected
evidence;
* the Decentralization of the Internet Research Group (DINRG), where
authority and enforcement span independently controlled systems;
and
* the ACM/IRTF Applied Networking Research Workshop (ANRW), for
reproducible prototypes, benchmarks, failure injection, and
deployment measurements.
This list identifies research intersections, not endorsement, charter
acceptance, or a claim that any named research group is the correct
final home.
8.9. Cross-Area Dispatch and Possible Work Products
No single existing working group necessarily owns the entire problem.
Authorization syntax may relate to OAuth; attested enforcement
properties may relate to RATS; workload context may relate to WIMSE;
automated-client identity may relate to Web Bot Auth; protected
object formats may relate to COSE; and final consequence semantics
remain application-specific.
An initial cross-area dispatch discussion could separate possible
work products rather than proposing one universal protocol:
1. an informational problem statement and terminology;
2. a common claim or receipt information model;
3. application-specific exact-act and atomic-effectuation profiles;
4. attestation claims describing Finality Sink properties;
5. interoperability and adversarial test requirements; and
6. research questions that should remain in the IRTF until evidence
supports standardization.
Dispatch should test whether existing protocols already provide
functional equivalence in a given application before creating new
protocol machinery.
Das Expires 26 March 2027 [Page 22]
Internet-Draft Execution-Finality Architecture September 2026
9. Examples
9.1. Automated Payment
An agent is authorized to pay a named beneficiary up to a stated
amount before an expiry. The protected ledger or payment connector
reconstructs the actual debit account, beneficiary, amount, currency,
rail, fees, and execution time. It verifies the bound authorization
and current generation, checks revocation and balance policy,
atomically consumes the one-time handle, commits the transfer, and
records the resulting transaction identifier.
Checking the token only at an agent gateway is insufficient if a
downstream component can replace the beneficiary or retry the payment
after an ambiguous timeout.
9.2. Message or File SEND
An agent is authorized to send one identified document to one
recipient through an approved service. The egress sink reconstructs
the actual content digest, recipient, destination service,
visibility, permitted transformation, and policy generation. It
consumes the authority and releases the bytes as one controlled
transition.
Approval of a preview is insufficient if the attachment, recipient,
link target, or access-control setting can change after approval.
The sink must bind what the recipient can actually obtain, not merely
what the user interface displayed.
9.3. Physical or Infrastructure Actuation
An autonomous service proposes a configuration change or actuator
command. The command gate verifies the exact target, command
parameters, allowed operating envelope, current controller
generation, freshness, and safety state. It then commits the command
through the only actuation path. When immediate inaction is itself
unsafe, the profile defines an independently bounded fail-safe
action.
10. Illustrative Deployment Profiles
Local low-latency profile:
Sink-local keys and replay state; deterministic bounded act; local
atomic transaction; suitable for high-rate API, kernel,
accelerator, or device enforcement.
Das Expires 26 March 2027 [Page 23]
Internet-Draft Execution-Finality Architecture September 2026
Distributed transaction profile:
Authority and effect span services; uses a transaction state
machine, durable idempotency, fencing generations, and explicit
indeterminate-outcome handling.
Safety-critical profile:
Hardware or firmware mediation, attested sink state, bounded
offline authority, deterministic timing, and domain-specific fail-
safe behavior.
Audit-enhanced profile:
Externally verifiable receipts and append-only evidence supplement
prevention where independent assurance is required.
Profiles should specify which guarantees are local assertions and
which can be verified across an organizational boundary.
11. Reference Implementation and Adversarial Validation
The adversarial implementation referenced in the Additional
Disclosures section provides an executable way to test whether the
architectural invariants survive mutation, concurrency, stale
authority, replay, crash conditions, canonicalization differences,
unavailable consume state, and simulated bypass paths. The current
repository reports 36/36 adversarial and positive unit tests passed,
12/12 profile and variable-matrix cases passed, a deterministic
2,000-case mutation and canonicalization probe, cross-language digest
agreement across Python, Node.js, and Go, and single-use concurrency
races at 2, 8, 32, and 64 workers in which exactly one commit
succeeded.
The harness is particularly relevant to canonicalization ambiguity
because it includes deterministic canonicalization vectors, key-
reordering tests, mutation probes, Unicode and integer cases, and
cross-language digest comparison. It is also relevant to replay and
atomic-consumption claims because the strict path reconstructs the
live Candidate Act, rechecks sink, generation, revocation, act
digest, optional key binding, and reuse state, and serializes
verification, consumption, and the protected local commit.
The harness should not be treated as proof of production deployment
security. It does not by itself establish non-bypassability in a
commercial payment rail, cloud platform, industrial controller, or
hardware execution path. In particular, dedicated tests are still
needed for restored-snapshot rollback resistance, large-scale
verification-exhaustion and denial-of-service behavior, HSM or TEE
failure modes, distributed replicas, remote effect atomicity, and
site-specific alternate paths.
Das Expires 26 March 2027 [Page 24]
Internet-Draft Execution-Finality Architecture September 2026
Reference implementation: Execution Handle, Exact-Act Binding, Sink
Verification, Atomic Consumption, and Adversarial Test Harness
(https://github.com/sangmdas/Execution-Handle-Exact-Act-Binding-Sink-
Verification-Atomic-Consumption-Adversarial-Test-Harness).
12. Illustrative Binding Representation Profiles
The following examples are non-normative and are included to make the
Binding Representation concrete. They are not proposed wire formats
and do not imply adoption by any named payment, cloud, or
infrastructure provider. A real profile would need to define field
semantics, canonicalization, type limits, mandatory and optional
fields, unknown-field handling, protected-state sources, and the
exact consequence boundary.
12.1. Illustrative Financial Command in JSON
A high-impact payment profile could bind the exact amount, currency,
source resource, beneficiary, purpose, state generations, expiry,
unique nonce, and intended Finality Sink:
{
"profile": "ef-financial-01",
"act_type": "PAYMENT_POST",
"actor": "agent-7",
"resource": "acct:source-A",
"operation": "post_payment",
"arguments": {
"amount_minor": 12500,
"currency": "INR"
},
"destination": "acct:beneficiary-A",
"purpose": "invoice_settlement",
"jurisdiction": "IN",
"resource_version": "ledger:99182",
"policy_generation": 42,
"revocation_generation": 8,
"expires_at": 2000000060,
"nonce": "n-7f2c9a",
"finality_sink": "payment-post"
}
Figure 4
Das Expires 26 March 2027 [Page 25]
Internet-Draft Execution-Finality Architecture September 2026
The sink would reconstruct these fields from the operation actually
presented to the protected payment connector or ledger. A change in
beneficiary, amount, currency, source account, purpose, generation,
resource version, or other consequence-relevant field would therefore
produce a different Binding Representation and would not satisfy the
exact-act comparison.
12.2. Illustrative Cloud Privileged Command in JSON
A cloud-control profile could similarly bind a privileged action to
the exact account, role, policy object, target, purpose, tenant, and
current authorization state:
{
"profile": "ef-cloud-admin-01",
"act_type": "CLOUD_PRIVILEGED_CHANGE",
"actor": "workload:ops-agent-3",
"resource": "iam:role/ProductionDeployer",
"operation": "attach_policy",
"arguments": {
"policy_digest": "sha256:EXAMPLE",
"target_role": "ProductionDeployer"
},
"destination": "cloud-account:123456789012",
"tenant": "example-enterprise",
"purpose": "approved_deployment",
"jurisdiction": "EU",
"resource_version": "iam-state:8841",
"policy_generation": 77,
"revocation_generation": 19,
"expires_at": 2000000030,
"nonce": "n-cloud-19a2",
"finality_sink": "cloud-privileged-commit"
}
Figure 5
The same structure can be used for other cloud providers or private
infrastructure by substituting provider-specific resource identifiers
and semantics. The important property is not the field names but
deterministic binding of every field that can materially change the
protected consequence.
12.3. Illustrative CBOR/CDDL Shape
A compact CBOR profile could express the same information. The
following CDDL-like shape is illustrative only:
Das Expires 26 March 2027 [Page 26]
Internet-Draft Execution-Finality Architecture September 2026
binding-representation = {
"profile": tstr,
"act_type": tstr,
"actor": tstr,
"resource": tstr,
"operation": tstr,
"arguments": { * tstr => any },
"destination": tstr,
? "tenant": tstr,
? "purpose": tstr,
? "jurisdiction": tstr,
? "resource_version": tstr,
"policy_generation": uint,
"revocation_generation": uint,
"expires_at": uint,
"nonce": tstr,
"finality_sink": tstr
}
Figure 6
A CBOR profile intended for interoperable security use would
additionally need deterministic encoding requirements, duplicate-key
rejection, numeric and string normalization rules, treatment of tags
and unknown members, and an explicit rule that fields affecting
downstream interpretation cannot be silently omitted from the
protected representation.
13. Open Questions for IETF Discussion
1. Should a common information model identify the act digest,
semantic profile, sink, authorization generation, state
generation, consumption identifier, outcome, and receipt?
2. Which existing application protocols already provide functional
equivalence, and which need explicit effectuation-bound profiles?
3. How should canonicalization and semantic-version negotiation be
expressed without encouraging generic but ambiguous action
schemas?
4. Can RATS Evidence or Attestation Results establish properties of
an enforcement sink without confusing platform state with proof
of a particular effect?
5. Which guarantees require application-specific transaction
semantics rather than a general Internet protocol?
Das Expires 26 March 2027 [Page 27]
Internet-Draft Execution-Finality Architecture September 2026
6. How should latency, availability, and assurance levels be
reported so deployments can make comparable claims?
14. Possible Next Research Directions
Sector-specific architectural blueprints:
Develop concrete deployment models showing how a Finality Sink
could operate inside specific high-criticality environments, for
example at a SWIFT-connected payment execution gateway, a cloud
infrastructure control plane, or an AWS IAM-governed privileged-
action boundary. The objective would be to show exactly where
verification occurs, what protected state is consulted, and how an
unauthorized or substituted AI-generated action is prevented from
becoming effective.
Threat modeling of the Finality Sink:
Examine the Finality Sink itself as a security-critical component.
This should include bypass attempts, denial-of-service or flooding
attacks, replay, malformed or deceptive requests, compromised
upstream agents, state manipulation, privilege escalation, race
conditions, and attempts to separate verification from the final
state transition. The analysis should define how the enforcement
boundary remains fail-closed and resistant to circumvention.
Alignment with existing standards and frameworks:
Map execution-finality functions against established NIST, ISO/
IEC, cybersecurity, AI-risk, and critical-infrastructure
frameworks. The purpose would not be to claim that existing
standards already require execution finality, but to identify
where concepts such as access control, reference monitoring, least
privilege, auditability, resilience, secure execution, risk
management, and fail-safe operation could provide an integration
path for execution-finality mechanisms.
Adversarial harness expansion:
Extend the existing adversarial test harness with dedicated
restored-snapshot rollback tests, high-rate verification-
exhaustion tests, resource-budget measurements, distributed
consume-state failure cases, and provider-specific bypass-path
experiments. The objective is to distinguish properties already
demonstrated by the reference implementation from properties that
require stronger deployment-specific evidence.
Binding Representation profile prototyping:
Develop interoperable experimental JSON and deterministic CBOR
profiles for selected high-impact domains, beginning with payment
execution and privileged cloud-control actions. Each profile
should identify all consequence-relevant fields, define
Das Expires 26 March 2027 [Page 28]
Internet-Draft Execution-Finality Architecture September 2026
canonicalization and unknown-field behavior, specify protected-
state generations and freshness, and include positive and
adversarial test vectors.
These directions are intended as research and deployment questions
rather than claims of adoption, endorsement, or existing requirements
by SWIFT, AWS, NIST, ISO/IEC, or any other named organization.
15. Security Considerations
The Finality Sink is a high-value target. Compromise can authorize
effects, suppress denials, falsify state, or issue misleading
receipts. Implementations should minimize the trusted computing
base, separate duties where appropriate, protect keys and state,
authenticate updates, and support secure recovery and rotation.
Replay protection must remain correct under concurrency, partition,
restore, and rollback. Generation and rollback protections need to
remain valid across crash recovery, backup restoration, migration,
and replicated-state repair.
Receipts do not prevent a consequence by themselves. A receipt is
useful only when it is bound to an enforcement transition whose
placement and integrity are within the relying party's threat model.
Fail-open fallbacks, diagnostic endpoints, privileged repair paths,
direct storage access, and alternate egress routes can defeat the
architecture. They must be removed, equivalently mediated, or
explicitly excluded from the claimed guarantee.
15.1. Specific Sink Attack and Failure Modes
* *Snapshot Rollbacks:* Restoring old snapshots of protected storage
can resurrect already-consumed or revoked authority. Deployments
therefore need rollback-resistant protected storage, monotonic
counters, generation fencing, or an equivalent mechanism that
prevents restored state from silently reviving stale authority.
* *Canonicalization Ambiguity:* If the Finality Sink interprets a
consequence-relevant field differently from the downstream
executor, an attacker may exploit the semantic difference even
when the same bytes appear to have been validated. Profiles
therefore need deterministic encodings, covered-field rules,
semantic versions, and explicit rejection behavior for unknown,
duplicate, aliased, normalized, or ambiguously transformed values.
Das Expires 26 March 2027 [Page 29]
Internet-Draft Execution-Finality Architecture September 2026
* *Verification Exhaustion:* The Finality Sink is a high-value
availability target. An attacker may attempt to exhaust
cryptographic verification, protected-state lookup, replay-state,
or durable-commit resources. Deployments should use aggressive
admission control, rate limiting, request shaping, quotas, and
inexpensive pre-validation before expensive cryptographic or
transactional work. These early controls must not replace the
final protected execution decision.
16. Privacy Considerations
Binding Representations and receipts may reveal destinations,
amounts, recipients, content identifiers, purposes, or organizational
policy. Deployments should minimize exposed fields, use keyed or
domain-separated digests where appropriate, encrypt sensitive
evidence, limit retention, and prevent cross-context correlation.
Auditability does not require unrestricted observability. A verifier
may need proof that mandatory checks occurred without receiving the
underlying personal or confidential data.
17. IANA Considerations
This document has no IANA actions.
18. Additional Disclosures and Implementation Resources
*Related publications:*
* From AI Hotlines to Execution Boundaries: A Sovereignty-Preserving
Middle Ground for U.S.-China AI Safety (https://zenodo.org/
records/22897705). This publication discusses execution-finality
architecture as a possible sovereignty-preserving technical layer
for cross-jurisdictional AI safety and critical-system cooperation
without requiring mutual trust in model internals.
* The Internet Solved Communication. It Never Solved Authority.
(https://zenodo.org/records/22082995) This publication provides
the broader architectural disclosure separating computation,
communication, authorization, and the final authority to produce
an externally effective consequence.
*Selected implementation and validation resources:*
* Execution Handle, Exact-Act Binding, Sink Verification, Atomic
Consumption, and Adversarial Test Harness
(https://github.com/sangmdas/Execution-Handle-Exact-Act-Binding-
Sink-Verification-Atomic-Consumption-Adversarial-Test-Harness).
Das Expires 26 March 2027 [Page 30]
Internet-Draft Execution-Finality Architecture September 2026
This repository exercises exact-act binding, sink verification,
one-time consumption, canonicalization, replay, concurrency,
crash, and bypass-related properties.
* Preventing AI Hallucinations and Unauthorized Actions - Runnable
Reference Implementation (https://github.com/sangmdas/Preventing-
AI-Hallucinations-and-Unauthorized-Actions-Runnable-Reference-
Implementation). This repository demonstrates Candidate Act
handling, non-effective state, validation evidence, scoped
execution handles, and Finality Sink verification for AI-generated
actions.
* Payment Execution Finality for Agentic API and Automated Payments
- Runnable Reference Implementation (https://github.com/sangmdas/
Payment-Execution-Finality-for-Agentic-API-and-Automated-Payments-
Runnable-Reference-Implementation). This repository provides a
payment-domain example for exact beneficiary, amount,
authorization, freshness, replay, and final execution control.
* Execution Finality for GPU, AI Accelerators, and Confidential
Workloads (https://github.com/sangmdas/Execution-Finality-for-GPU-
AI-Accelerators-and-Confidential-Workloads). This repository
provides a hardware and accelerator-oriented deployment reference
for enforcing consequence control near compute, memory, egress,
and confidential-workload boundaries.
These references are supplied for transparency, reproducibility, and
architectural context. Their inclusion does not imply IETF
endorsement, standards-track adoption, production certification, or
independent validation. Their presence does not alter the IETF Trust
provisions applicable to this document and should not be interpreted
as a software or patent license beyond the terms explicitly stated at
each resource.
Acknowledgements
The author thanks reviewers who distinguished authorization of a
request from control of the final externally effective act, and who
emphasized the need to describe functional equivalence using
established security, transaction, and control-system terminology.
Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Das Expires 26 March 2027 [Page 31]
Internet-Draft Execution-Finality Architecture September 2026
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Informative References
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9110] Fielding, R., Nottingham, M., and J. Reschke, "HTTP
Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June
2022, <https://www.rfc-editor.org/info/rfc9110>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/info/rfc9396>.
[RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/info/rfc9449>.
Author's Address
Sangam Kumar Das
Independent Researcher
India
Email: info@sangamdas.com
Das Expires 26 March 2027 [Page 32]