Secure AI Execution-Finality for iOS, Android, and Cross-Platform AI Agents, Part 4: Finality Sink Enforcement, Actual-Operation Reconstruction, and Anti-Bypass Security
draft-das-finality-sink-enforcement-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Sangam Das | ||
| Last updated | 2026-10-26 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Github - DAS Execution-Finality: Runnable Reference Model and 400 Executed Tests
iOS and Android Interoperability for Secure Third Party AI Tools - Cross-Platform Execution Finality, Hardware Security, and Interoperability (3,567-Page Specification |
||
| 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-finality-sink-enforcement-00
Independent Submission S. Das
Internet-Draft Independent Researcher
Intended status: Informational 26 October 2026
Expires: 29 April 2027
Secure AI Execution-Finality for iOS, Android, and Cross-Platform AI
Agents, Part 4: Finality Sink Enforcement, Actual-Operation
Reconstruction, and Anti-Bypass Security
draft-das-finality-sink-enforcement-00
Abstract
An AI action can be approved correctly and still go somewhere else.
Assistants such as Apple Siri acting through App Intents and Google
Gemini on Android, AI coding agents, browser and computer-use agents,
enterprise copilots, and third-party automation on iOS, iPadOS,
macOS, Android, Windows, Linux, and cloud platforms can reach the
same effect through another network route, file interface, privileged
inter-process service, direct API credential, hardware command queue,
or sandbox exit. Prompt injection, stale human approvals, a swapped
window or user-interface target, and forged observations can also
make the approved tool action differ from the payment, export,
publication, resource change, or device command that actually
happens.
This document, Part 4 of a twelve-part series, specifies the
enforcement point of execution finality: the Finality Sink. The sink
independently reconstructs the actual pending operation where the
effect occurs, rather than trusting the agent's description, and
either consumes operation-scoped authority once under protected state
or refuses. The document covers discovery of every effect-capable
path, the difference between observing an effect and blocking it,
runtime enforcement-coverage epochs, privilege transitions from
sandbox to real resource, authenticated computer-use and human-
approval state, and replay and snapshot-rollback resistance.
Reference algorithms, six threat models, and twenty reproducible
positive and negative tests, including an Android-to-iOS case, are
included. Part 1 of the series defines the shared terminology and
common workflows.
The document treats existing IETF mechanisms as qualified inputs to
sink-local decisions rather than final authority: OAuth 2.0 Rich
Authorization Requests and Demonstrating Proof of Possession (DPoP);
Workload Identity in Multi-System Environments (WIMSE); Remote
ATtestation procedureS (RATS); CBOR Object Signing and Encryption
(COSE); Authentication and Authorization for Constrained Environments
(ACE); Supply Chain Integrity, Transparency, and Trust (SCITT); and
Das Expires 29 April 2027 [Page 1]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
HTTP preconditions and redirect semantics. It identifies discussion
points for these groups and for Security Area dispatch, without
claiming working-group adoption or IETF consensus.
Industry alignment covers Apple iOS, iPadOS, and macOS with Siri, App
Intents, and desktop sandboxing; Google Android with Binder and
intents; Google Gemini and agent gateways; Samsung Bixby and
Microsoft Copilot; Microsoft Windows and Azure agent containers;
computer-use and coding agents from OpenAI, Anthropic, and Meta;
NVIDIA, Qualcomm, Arm, and Huawei hardware; banking and payments;
cloud API gateways and SaaS; and telecommunications, IoT, and
robotics. Product names are illustrative and imply no endorsement or
implementation by any vendor. For the EU Artificial Intelligence Act
(Regulation (EU) 2024/1689), sink-side enforcement that cannot be
bypassed through alternate paths can help providers and deployers
address robustness and cybersecurity, human-oversight, risk-
management, and record-keeping requirements where those obligations
apply; this is a technical mapping, not a conformity claim or legal
advice.
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 29 April 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.
Das Expires 29 April 2027 [Page 2]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Table of Contents
1. Introduction: Part 4 Security Problem Space and Twelve-Part
Publication Series . . . . . . . . . . . . . . . . . . . 7
1.1. Complete Twelve-Part Series: Titles, Scope and Planned
Identifiers . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.1. Part 1 of 12 — Foundational definitions, trust model
and CW-1/CW-2/CW-3 workflows . . . . . . . . . . . . 8
1.1.2. Part 2 of 12 — Secure Apple iOS, Android and
cross-platform third-party AI tool interoperability . 9
1.1.3. Part 3 of 12 — Protected authorization, validation
evidence and non-bearer finality . . . . . . . . . . 9
1.1.4. Part 4 of 12 — Finality Sink enforcement,
actual-operation reconstruction and prevention of
bypass . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.5. Part 5 of 12 — Multi-agent delegation, conflicts and
source-authority lineage . . . . . . . . . . . . . . 9
1.1.6. Part 6 of 12 — Qualified actual-effect receipts and
dependent workflow continuation . . . . . . . . . . . 9
1.1.7. Part 7 of 12 — AI tool security, dynamic tool semantics
and runtime integrity . . . . . . . . . . . . . . . . 9
1.1.8. Part 8 of 12 — Distributed effects, transaction
outcomes and protected recovery . . . . . . . . . . . 10
1.1.9. Part 9 of 12 — Credential custody, data disclosure and
privacy release . . . . . . . . . . . . . . . . . . . 10
1.1.10. Part 10 of 12 — Cross-device ownership, revocation
fences and offline execution . . . . . . . . . . . . 10
1.1.11. Part 11 of 12 — Kernel, sandbox, accelerator and
hardware boundary enforcement . . . . . . . . . . . . 10
1.1.12. Part 12 of 12 — Autonomous cloud, telecom and critical
infrastructure resource governance . . . . . . . . . 10
2. Source Publication, Patent-Pending Context, IETF IPR Process
and Forthcoming GitHub References . . . . . . . . . . . . 10
3. Keywords and Patent Examiner / Industry Technical Discovery
Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Relevant Common Terminology and Local Part 4 Definitions . . 12
4.1. Candidate Act (CA) . . . . . . . . . . . . . . . . . . . 12
4.2. Non-Effective State (NES) . . . . . . . . . . . . . . . . 12
4.3. Protected Enforcement Domain (PED) . . . . . . . . . . . 12
4.4. Finality Sink (FS) . . . . . . . . . . . . . . . . . . . 12
4.5. Actual Operation Descriptor . . . . . . . . . . . . . . . 12
4.6. Effectuation Path . . . . . . . . . . . . . . . . . . . . 13
4.7. Coverage Proof / Commitment . . . . . . . . . . . . . . . 13
4.8. Enforcement Coverage Epoch . . . . . . . . . . . . . . . 13
4.9. Observation versus Prevention . . . . . . . . . . . . . . 13
4.10. Computer-Use State Evidence . . . . . . . . . . . . . . . 13
4.11. Sandbox Escape Finality . . . . . . . . . . . . . . . . . 13
4.12. Scope Delta / Reauthorization . . . . . . . . . . . . . . 14
Das Expires 29 April 2027 [Page 3]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
4.13. Sink-Local Protected Consumption . . . . . . . . . . . . 14
5. Threat Boundary, Trust Model and Effect-Capable Surface
Inventory . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Adversarial agent or content . . . . . . . . . . . . . . 14
5.2. Compromised upstream approver or intermediary . . . . . . 14
5.3. Alternate channels and hidden effects . . . . . . . . . . 14
5.4. Topology and runtime mutation . . . . . . . . . . . . . . 14
5.5. Operating-system limits . . . . . . . . . . . . . . . . . 15
5.6. Actual effect and remote acceptance . . . . . . . . . . . 15
5.7. Denial-of-service and audit exposure . . . . . . . . . . 15
5.8. Non-goals . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Reference Sink-Control Architecture and Protected Enforcement
Relationships . . . . . . . . . . . . . . . . . . . . . . 15
7. Implementation Guidance for a Person Having Ordinary Skill in
the Art (PHOSITA) . . . . . . . . . . . . . . . . . . . . 17
7.1. Threat and Scope Discovery . . . . . . . . . . . . . . . 17
7.2. Software Architecture . . . . . . . . . . . . . . . . . . 17
7.3. Actual Operation Control . . . . . . . . . . . . . . . . 17
7.4. Coverage and Blockability Discovery . . . . . . . . . . . 17
7.5. Runtime Change Reattestation . . . . . . . . . . . . . . 17
7.6. Protected Authorization and Replay Resistance . . . . . . 18
7.7. Gateway Enforcement for Web APIs . . . . . . . . . . . . 18
7.8. Linux Containers and Host Connectors . . . . . . . . . . 18
7.9. Apple iOS and macOS Deployment . . . . . . . . . . . . . 18
7.10. Android Deployment . . . . . . . . . . . . . . . . . . . 18
7.11. UI and Accessibility Agents . . . . . . . . . . . . . . . 19
7.12. Sandbox Output Promotion . . . . . . . . . . . . . . . . 19
7.13. Device and Accelerator Surfaces . . . . . . . . . . . . . 19
7.14. Observability, Privacy and Recovery . . . . . . . . . . . 19
7.15. Testing and Reproducibility . . . . . . . . . . . . . . . 19
7.16. Independent Implementation Boundaries . . . . . . . . . . 19
8. Reference Interfaces, Data Structures, State Machines and
Non-Normative Algorithms . . . . . . . . . . . . . . . . 20
8.1. Candidate Act and Actual Effect Descriptor . . . . . . . 20
8.2. Coverage Graph and Assurance Levels . . . . . . . . . . . 20
8.3. Sink Local Finality Consumption Schema . . . . . . . . . 21
8.4. Discover and Qualify Enforceable Paths . . . . . . . . . 21
8.5. Construct Protected Actual Operation at the Sink . . . . 21
8.6. Independent Sink Verification and Atomic Consume . . . . 21
8.7. Human Approved Computer-Use Action . . . . . . . . . . . 22
8.8. Sandbox Privilege Transition and Output Promotion . . . . 22
8.9. Stale Topology and Failure Matrix . . . . . . . . . . . . 23
9. Detailed Source-Grounded Embodiment Disclosures: Page-Indexed
Primary Specification . . . . . . . . . . . . . . . . . . 23
9.1. Original Cross-Platform Consequence Control and
Non-Effectuation Foundation . . . . . . . . . . . . . . . 23
9.1.1. Protected Architecture and Trust-Boundary Diagram . . 23
9.1.2. Operational Decision and Fail-Closed Flowchart . . . 24
Das Expires 29 April 2027 [Page 4]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.1.3. Original Page-by-Page Technical Disclosure . . . . . 24
9.2. CW-1 Source: Protected Execution-Finality and Sink
Enforcement . . . . . . . . . . . . . . . . . . . . . . . 42
9.2.1. Protected Architecture and Trust-Boundary Diagram . . 42
9.2.2. Operational Decision and Fail-Closed Flowchart . . . 43
9.2.3. Original Page-by-Page Technical Disclosure . . . . . 43
9.3. Miscellaneous Embodiment M-1: Dynamic Effectuation Coverage
and Future-Adaptive Infrastructure . . . . . . . . . . . 105
9.3.1. Protected Architecture and Trust-Boundary Diagram . . 105
9.3.2. Operational Decision and Fail-Closed Flowchart . . . 106
9.3.3. Original Page-by-Page Technical Disclosure . . . . . 106
9.4. Embodiment 14: Protected Effectuation-Path Discovery,
Runtime Bypass Detection and Hardware Attribution . . . . 174
9.4.1. Protected Architecture and Trust-Boundary Diagram . . 174
9.4.2. Operational Decision and Fail-Closed Flowchart . . . 174
9.4.3. Original Page-by-Page Technical Disclosure . . . . . 175
9.5. Embodiment 19: Protected Computer-Use, Human Approval and
Actual UI Effect Correspondence . . . . . . . . . . . . . 269
9.5.1. Protected Architecture and Trust-Boundary Diagram . . 269
9.5.2. Operational Decision and Fail-Closed Flowchart . . . 269
9.5.3. Original Page-by-Page Technical Disclosure . . . . . 270
9.6. Miscellaneous Embodiment M-2: Existing Security Protocols
as Qualified Inputs to Sink-Local Finality . . . . . . . 339
9.6.1. Protected Architecture and Trust-Boundary Diagram . . 339
9.6.2. Operational Decision and Fail-Closed Flowchart . . . 339
9.6.3. Original Page-by-Page Technical Disclosure . . . . . 340
9.7. Embodiment 25: Sandboxed Tool Execution, Privilege
Transitions and Mandatory Escaping-Effect Control . . . . 407
9.7.1. Protected Architecture and Trust-Boundary Diagram . . 407
9.7.2. Operational Decision and Fail-Closed Flowchart . . . 407
9.7.3. Original Page-by-Page Technical Disclosure . . . . . 408
10. Six Formal Threat-Model Scenarios, Preconditions, Mitigations
and Residual Risks . . . . . . . . . . . . . . . . . . . 489
10.1. Threat 1: Prompt Injection to Alternate Tool/Resource
Path . . . . . . . . . . . . . . . . . . . . . . . . . . 489
10.2. Threat 2: Replay and Snapshot Rollback at Finality
Sink . . . . . . . . . . . . . . . . . . . . . . . . . . 489
10.3. Threat 3: Coverage Evasion and Privileged Connector
Bypass . . . . . . . . . . . . . . . . . . . . . . . . . 489
10.4. Threat 4: Forged Human Confirmation, GUI Race or UI
Overlay . . . . . . . . . . . . . . . . . . . . . . . . 490
10.5. Threat 5: Scope Escalation via Sandbox Exit and Dynamic
Tool Privileges . . . . . . . . . . . . . . . . . . . . 490
10.6. Threat 6: Compromised Security Infrastructure and
Verification Exhaustion . . . . . . . . . . . . . . . . 491
11. Reproducible Technical Validation Plan: Twenty Proposed
Negative and Positive Tests . . . . . . . . . . . . . . . 491
11.1. S01 — Baseline approved controlled effect . . . . . . . 491
Das Expires 29 April 2027 [Page 5]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
11.2. S02 — Prompt-injected alternate recipient . . . . . . . 492
11.3. S03 — Unauthorized raw socket bypass . . . . . . . . . . 492
11.4. S04 — Monitor-only interface mislabeled as
enforcement . . . . . . . . . . . . . . . . . . . . . . 493
11.5. S05 — Changed routing after approval . . . . . . . . . . 493
11.6. S06 — Changed hardware resource assignment . . . . . . . 493
11.7. S07 — Replayed non-bearer enablement . . . . . . . . . . 494
11.8. S08 — Restored snapshot of agent runtime . . . . . . . . 494
11.9. S09 — Redirected HTTP target . . . . . . . . . . . . . . 495
11.10. S10 — Changed request body at proxy . . . . . . . . . . 495
11.11. S11 — UI approval with window focus swap . . . . . . . . 495
11.12. S12 — UI screenshot / backend mismatch . . . . . . . . . 496
11.13. S13 — Permissioned sandbox output not published . . . . 496
11.14. S14 — Escaping sandbox via privileged host connector . . 497
11.15. S15 — Revocation between preparation and dispatch . . . 497
11.16. S16 — Concurrent requests race single-use consume . . . 497
11.17. S17 — Ambiguous canonicalization of URI/resource . . . . 498
11.18. S18 — Verification exhaustion / DoS . . . . . . . . . . 498
11.19. S19 — Remote outcome timeout . . . . . . . . . . . . . . 499
11.20. S20 — Android/iOS cross-platform receiving resource . . 499
12. Detailed Industry Relevance and Product Security Alignment . 499
12.1. Apple iOS and iPadOS Third-Party AI Tools . . . . . . . 500
12.2. Apple macOS, Desktop Sandboxing and Computer Use . . . . 500
12.3. Google Android, Binder IPC and Intent-Based Action . . . 500
12.4. Google Cloud, Gemini and Agent Gateways . . . . . . . . 501
12.5. Microsoft Windows, Azure and Agent Execution
Containers . . . . . . . . . . . . . . . . . . . . . . 501
12.6. OpenAI Agent APIs, Codex and Computer-Use Systems . . . 501
12.7. Anthropic Claude and Sandboxed Development Agents . . . 501
12.8. Meta Muse/Sentinel-like Isolated Agent Architectures . . 502
12.9. NVIDIA OpenShell / Sentry, BlueField and Accelerators . 502
12.10. Qualcomm Snapdragon, Arm and Embedded Hardware . . . . . 502
12.11. Huawei and Heterogeneous Device Platforms . . . . . . . 502
12.12. Banking, Payments and Enterprise Transactions . . . . . 503
12.13. Cloud API Gateways, Databases and SaaS . . . . . . . . . 503
12.14. Telecommunications, IoT and Robotics . . . . . . . . . . 503
12.15. Voice and System Assistants: Apple Siri, Google Gemini,
Samsung Bixby, Microsoft Copilot, and Amazon Alexa . . 504
13. Detailed IETF Working-Group Relevance, Existing RFCs and
Technical Integration Boundaries . . . . . . . . . . . . 504
13.1. OAuth WG: RFC 9396 Rich Authorization, RFC 9449 DPoP and
Transaction Context . . . . . . . . . . . . . . . . . . 504
13.2. WIMSE WG: Workload Identity and Multi-Hop
Authorization . . . . . . . . . . . . . . . . . . . . . 505
13.3. RATS WG: RFC 9334 Attestation of Protected Components . 505
13.4. COSE / CBOR: RFC 9052 and RFC 8949 for Protected
Evidence . . . . . . . . . . . . . . . . . . . . . . . . 505
13.5. ACE WG: RFC 9200 Constrained Authorization . . . . . . . 506
Das Expires 29 April 2027 [Page 6]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
13.6. SCITT WG: Signed Statements and Transparency Evidence . 506
13.7. HTTPBIS: RFC 9110 Resource Semantics, Preconditions and
Redirects . . . . . . . . . . . . . . . . . . . . . . . 507
13.8. SEC-DISPATCH and Security Area: Cross-Protocol Execution
Boundaries . . . . . . . . . . . . . . . . . . . . . . . 507
14. Relevance to the EU Artificial Intelligence Act . . . . . . . 507
15. Security, Privacy, Availability, Deployment and IANA
Considerations . . . . . . . . . . . . . . . . . . . . . 508
15.1. Coverage completeness . . . . . . . . . . . . . . . . . 508
15.2. Temporal consistency . . . . . . . . . . . . . . . . . . 509
15.3. Human approval integrity . . . . . . . . . . . . . . . . 509
15.4. Privilege separation and bypass . . . . . . . . . . . . 509
15.5. Replay and monotonic sink state . . . . . . . . . . . . 509
15.6. Canonical operation equivalence . . . . . . . . . . . . 509
15.7. Sensitive logs and privacy . . . . . . . . . . . . . . . 509
15.8. Verification exhaustion and loss of availability . . . . 509
15.9. Remote side effects . . . . . . . . . . . . . . . . . . 509
15.10. IANA and interop maturity . . . . . . . . . . . . . . . 510
16. Original Technical Source Cross-Index for Patent Examination
and Platform Security Review . . . . . . . . . . . . . . 510
17. Explicit Foundation and Companion Internet-Draft
Cross-References . . . . . . . . . . . . . . . . . . . . 511
18. Source Publication, IETF RFCs and Planned Companion
Documents . . . . . . . . . . . . . . . . . . . . . . . . 511
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 515
1. Introduction: Part 4 Security Problem Space and Twelve-Part
Publication Series
AI-agent execution systems can establish a correct model-level policy
and still allow an unauthorized external consequence. The problem is
not merely whether the agent planned a permitted action; it is
whether every operative route to the protected resource is
controlled, whether the exact action presented to that resource
corresponds to current source authority, and whether authorization is
consumed under a protected resource-local state transition. A
monitoring hook or an allowed tool name does not provide the same
guarantee as mandatory enforcement at the last preventable
consequence boundary.
A browser agent may display an approved recipient while the
actionable request targets another account; an operating-system
clipboard, accessibility, IPC, sharing or automation service may
promote an output beyond its approved disclosure scope; a sandboxed
coding agent may invoke a privileged host connector; a network proxy
can be circumvented by direct sockets; a device controller can
execute a queued operation after token revocation. These problems
are relevant to mobile interoperability, cloud access controls,
Das Expires 29 April 2027 [Page 7]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
computer-use agents, financial APIs, digital content publication,
device administration and accelerator-backed autonomous systems. The
examples describe security problem classes, not documented defects in
any named product.
The publication objective is detailed, discoverable technical
disclosure for engineers, independent security reviewers and patent
examiners. This author-submitted technical analysis does not
represent IETF consensus, a formally adopted working-group item, or
validated deployment across commercial platforms. Where a system
lacks authority to control an actual effect-capable interface, a
universal enforcement guarantee is not claimed. The exact security
scope must identify enforceable boundaries and unavoidable residual
bypass paths.
Part 1 provides the common definitions and CW-1/CW-2/CW-3 workflows.
Part 2 analyzes cross-platform adapters; Part 3 develops source
authority and protected evidence; this Part 4 concentrates on the
independently enforcing Finality Sink, accurate actual-operation
reconstruction, path-coverage commitments and practical resource
interfaces. Its source-grounded primary treatments are Embodiments
14, 19 and 25, supplemented by M-1, M-2 and CW-1. Part 7 contains
complementary tool lifecycle integrity and Part 11 covers kernel and
hardware enforcement more extensively.
1.1. Complete Twelve-Part Series: Titles, Scope and Planned Identifiers
The document names are project-planned individual submission
identifiers. Their Datatracker URL patterns become active only if
the corresponding document is submitted and accepted. A project
identifier must not be presented as an already published IETF draft.
1.1.1. Part 1 of 12 — Foundational definitions, trust model and CW-1/
CW-2/CW-3 workflows
Planned individual Internet-Draft: draft-das-interoperable-
consequence-authority. Planned URL:
https://datatracker.ietf.org/doc/draft-das-interoperable-consequence-
authority/ .
AUTHORITATIVE FOUNDATION: Candidate Act (CA), Non-Effective State
(NES), Protected Enforcement Domain (PED), Finality Sink (FS), scoped
non-bearer finality and CW-1, CW-2, CW-3 definitions.
Das Expires 29 April 2027 [Page 8]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
1.1.2. Part 2 of 12 — Secure Apple iOS, Android and cross-platform
third-party AI tool interoperability
Planned individual Internet-Draft: draft-das-cross-platform-ai-
interoperability. Planned URL: https://datatracker.ietf.org/doc/
draft-das-cross-platform-ai-interoperability/ .
1.1.3. Part 3 of 12 — Protected authorization, validation evidence and
non-bearer finality
Planned individual Internet-Draft: draft-das-protected-authority-
evidence. Planned URL: https://datatracker.ietf.org/doc/draft-das-
protected-authority-evidence/ .
1.1.4. Part 4 of 12 — Finality Sink enforcement, actual-operation
reconstruction and prevention of bypass
Planned individual Internet-Draft: draft-das-finality-sink-
enforcement. Planned URL: https://datatracker.ietf.org/doc/draft-
das-finality-sink-enforcement/ .
THIS PART: resource-side actual-operation reconstruction, enforced
coverage, alternate effect routes, computer-use approval
correspondence and sandbox escape finality.
1.1.5. Part 5 of 12 — Multi-agent delegation, conflicts and source-
authority lineage
Planned individual Internet-Draft: draft-das-multi-agent-authority-
control. Planned URL: https://datatracker.ietf.org/doc/draft-das-
multi-agent-authority-control/ .
1.1.6. Part 6 of 12 — Qualified actual-effect receipts and dependent
workflow continuation
Planned individual Internet-Draft: draft-das-causal-effect-receipts.
Planned URL: https://datatracker.ietf.org/doc/draft-das-causal-
effect-receipts/ .
1.1.7. Part 7 of 12 — AI tool security, dynamic tool semantics and
runtime integrity
Planned individual Internet-Draft: draft-das-agent-tool-integrity.
Planned URL: https://datatracker.ietf.org/doc/draft-das-agent-tool-
integrity/ .
Das Expires 29 April 2027 [Page 9]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
1.1.8. Part 8 of 12 — Distributed effects, transaction outcomes and
protected recovery
Planned individual Internet-Draft: draft-das-distributed-effect-
recovery. Planned URL: https://datatracker.ietf.org/doc/draft-das-
distributed-effect-recovery/ .
1.1.9. Part 9 of 12 — Credential custody, data disclosure and privacy
release
Planned individual Internet-Draft: draft-das-agent-credential-
privacy. Planned URL: https://datatracker.ietf.org/doc/draft-das-
agent-credential-privacy/ .
1.1.10. Part 10 of 12 — Cross-device ownership, revocation fences and
offline execution
Planned individual Internet-Draft: draft-das-cross-device-authority-
revocation. Planned URL: https://datatracker.ietf.org/doc/draft-das-
cross-device-authority-revocation/ .
1.1.11. Part 11 of 12 — Kernel, sandbox, accelerator and hardware
boundary enforcement
Planned individual Internet-Draft: draft-das-hardware-execution-
finality. Planned URL: https://datatracker.ietf.org/doc/draft-das-
hardware-execution-finality/ .
1.1.12. Part 12 of 12 — Autonomous cloud, telecom and critical
infrastructure resource governance
Planned individual Internet-Draft: draft-das-autonomous-
infrastructure-finality. Planned URL:
https://datatracker.ietf.org/doc/draft-das-autonomous-infrastructure-
finality/ .
2. Source Publication, Patent-Pending Context, IETF IPR Process and
Forthcoming GitHub References
This series is associated with the 3,567-page technical publication
entitled "iOS and Android Interoperability for Secure Third Party AI
Tools - Cross-Platform Execution Finality, Hardware Security, and
Interoperability (3,567-Page Specification)", available at
https://zenodo.org/records/23657985, DOI 10.5281/zenodo.23657985
[ZENODO]. The document provides original numbered embodiments and
technical variations; original source page references accompany the
detailed Part 4 transcripts below.
Das Expires 29 April 2027 [Page 10]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The principal earlier 8,598-page PCT disclosure associated with this
project is PCT/IB2026/055615, filed 4 June 2026 and published as WO
2026/150382 [PCT-055615]. Earlier PCT/IB2025/058316 is a separate
application and must not be equated with that 8,598-page filing. The
precise disclosure support, claimed priority, and relationship of
individual statements in this Part 4 to particular as-filed
applications must be checked against the original filed records; this
Internet-Draft does not retrospectively alter the priority date of
newly added diagrams, source-index commentary, test scenarios or
reference code.
The author intends to provide or update detailed relevant IETF IPR
disclosures through the separate official IETF disclosure process,
with verified application particulars and licensing statements as
appropriate. This informational publication note is not itself a BCP
79 disclosure; [RFC8179] requires disclosures to be made in a timely
manner when its conditions are met, and they should not be delayed
merely because further information is planned. IPR disclosures and
related licensing statements are handled by the IETF mechanism rather
than treated as normative technology provisions in this document.
A GitHub reference implementation, operation descriptors, test
drivers, sample gateway and sandbox policies, and reproducible logs
may be linked in a later revision. No GitHub repository URL or
completed test outcome is asserted here. Source-described mechanisms
are kept distinct from newly formulated implementation examples,
tests, threat tables and editorial diagrams.
3. Keywords and Patent Examiner / Industry Technical Discovery Terms
AI agent security; agent tool execution; Finality Sink; actual-
operation reconstruction; unauthorized AI actions; prompt injection;
agent sandbox bypass; non-bypassable enforcement; API gateway
security; privileged connector security; egress gateway; network
exfiltration prevention; network socket interception; eBPF; LSM;
kernel-mediated effect; iOS application security; macOS sandbox;
Android application sandbox; Android Binder IPC; Apple App Intents;
accessibility automation; computer-use agents; browser automation;
human-in-the-loop approval; action-bound human authorization; desktop
UI security; screen-state evidence; graphical user interface state
integrity; operating system privilege separation; credential
brokerage; endpoint authorization; RATS attestation; OAuth; DPoP;
resource server enforcement; COSE; CBOR; WIMSE; ACE; HTTP If-Match;
transaction version validation; API route re-binding; cloud workload
isolation; device controllers; GPU command egress; hardware resource
attribution; protected finality authority; sink-local state; anti-
replay; protected consumption; resource effect; cross-platform AI
interoperability; iOS Android third-party tools; threat model; test
Das Expires 29 April 2027 [Page 11]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
vectors; prior art technical disclosure.
4. Relevant Common Terminology and Local Part 4 Definitions
4.1. Candidate Act (CA)
A bounded description of a proposed consequential operation, held
non-effective until qualified effect-specific authority becomes
enforceable. Detailed foundational terminology is established by
Part 1; Part 4 uses these meanings without creating transferable
generic permissions.
4.2. Non-Effective State (NES)
A condition in which the proposed act has not yet crossed the
controlled release boundary or obtained authority capable of
producing the governed consequence. Detailed foundational
terminology is established by Part 1; Part 4 uses these meanings
without creating transferable generic permissions.
4.3. Protected Enforcement Domain (PED)
An authenticated, appropriately isolated domain that verifies source
permission or other qualified evidence without depending solely on
agent-controllable observations. Detailed foundational terminology
is established by Part 1; Part 4 uses these meanings without creating
transferable generic permissions.
4.4. Finality Sink (FS)
The protected component or effect-capable interface that can prevent
or permit the actual pending consequential operation after
reconstructing and verifying its material parameters and current
sink-local state. Detailed foundational terminology is established
by Part 1; Part 4 uses these meanings without creating transferable
generic permissions.
4.5. Actual Operation Descriptor
A protected representation derived from the operation as actually
presented for effectuation, including relevant destination, resource
identity, method, parameters, current version, or effect-specific
features. Detailed foundational terminology is established by Part
1; Part 4 uses these meanings without creating transferable generic
permissions.
Das Expires 29 April 2027 [Page 12]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
4.6. Effectuation Path
A software/hardware route capable of producing the governed
consequence, such as an application API, raw socket, file commit,
message publication, privileged IPC, accelerator queue or actuator
dispatch. Detailed foundational terminology is established by Part
1; Part 4 uses these meanings without creating transferable generic
permissions.
4.7. Coverage Proof / Commitment
Qualified protected evidence that mandatory enforcement applies to
the relevant effect-capable route(s) under a stated topology, scope,
identity and generation. Detailed foundational terminology is
established by Part 1; Part 4 uses these meanings without creating
transferable generic permissions.
4.8. Enforcement Coverage Epoch
A protected state generation invalidating coverage assumptions when
relevant runtime tools, routing, hardware assignments or privilege
transitions materially change. Detailed foundational terminology is
established by Part 1; Part 4 uses these meanings without creating
transferable generic permissions.
4.9. Observation versus Prevention
Telemetry, logging and detection can provide evidence of an operation
but cannot substitute for a blocking control that can refuse an
effect before it occurs. Detailed foundational terminology is
established by Part 1; Part 4 uses these meanings without creating
transferable generic permissions.
4.10. Computer-Use State Evidence
Qualified records concerning UI accessibility, visual representation,
DOM/application state, window focus, target identity and relevant
user-confirmation context. Detailed foundational terminology is
established by Part 1; Part 4 uses these meanings without creating
transferable generic permissions.
4.11. Sandbox Escape Finality
The separate source-authorized permission for a sandboxed process or
its output to cause an external effect through a privileged gateway,
host resource, publication operation or hardware interface. Detailed
foundational terminology is established by Part 1; Part 4 uses these
meanings without creating transferable generic permissions.
Das Expires 29 April 2027 [Page 13]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
4.12. Scope Delta / Reauthorization
A material difference between originally authorized effect and actual
pending consequence that requires withholding or a newly qualified
authorization under CW-3. Detailed foundational terminology is
established by Part 1; Part 4 uses these meanings without creating
transferable generic permissions.
4.13. Sink-Local Protected Consumption
Protected monotonic or otherwise replay-resistant authorization state
associated with the actual effectuation boundary and updated under a
defined atomicity/failure model. Detailed foundational terminology
is established by Part 1; Part 4 uses these meanings without creating
transferable generic permissions.
5. Threat Boundary, Trust Model and Effect-Capable Surface Inventory
5.1. Adversarial agent or content
An autonomous agent may receive untrusted instructions from a
retrieved page, repository, email, tool response or GUI element and
may seek to invoke a semantically different effect. The lower-trust
workload and its observations must not be the sole authority source.
5.2. Compromised upstream approver or intermediary
A policy decision can be genuine yet stale, incomplete, scoped
incorrectly or detached from the last resource operation. The last
enforceable boundary must obtain qualified actual-operation details
and current source authorization.
5.3. Alternate channels and hidden effects
Multiple paths can reach the same resource: file APIs, direct
sockets, device interfaces, out-of-band sync tools, browser IPC,
database connections or command queues. The covered set must be
discovered, classified and actively enforced, not merely observed.
5.4. Topology and runtime mutation
Tool installations, route changes, credential rotation, container
restarts, device assignment, changed privileged workers and network
interface updates can invalidate prior coverage assurances. Coverage
epochs must distinguish the current topology from stale measurements.
Das Expires 29 April 2027 [Page 14]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
5.5. Operating-system limits
Unprivileged mobile applications typically cannot interpose on every
platform-wide file, kernel or device effect. On Apple iOS and
Android, system-wide guarantees require suitable OS-provided
extension points, privileged management/control or receiver-side
enforcement, rather than invented private interface access.
5.6. Actual effect and remote acceptance
A local gate can prove it refused or dispatched a request under its
control. It cannot claim a remote payment, email or physical
actuation was atomically committed solely from a local state
transition. Remote evidence and reconciliation are separate topics
in Parts 6 and 8.
5.7. Denial-of-service and audit exposure
Scanning all effect paths or verifying high-cost evidence can be
expensive and may expose sensitive request metadata. Define bounded
verification, privacy redaction, quotas and explicit fail-closed
outcomes under resource exhaustion.
5.8. Non-goals
No assumption of universal kernel control, proof that named products
implement this invention, unconditional prevention of effects on
outside resources, exactly-once global remote transactions or that a
signed approval itself constitutes independently qualified finality.
6. Reference Sink-Control Architecture and Protected Enforcement
Relationships
Das Expires 29 April 2027 [Page 15]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
[User / original authority]
|
[Agent / tool / UI runtime]-----[Untrusted content]
|
[Candidate Act / NES]
|
[PED validation + evidence]
|
[Scoped non-bearer enablement]
|
+-------------------------------+
| COVERAGE CONTROLLER |
| discover routes / blockability|
| epoch + topology commitment |
+-------------------------------+
|
[Protected Finality Sink] <--- [Actual resource operation]
| <--- [Sink-local current state]
+--------+--------+
| |
[VALID: consume] [FAIL: withhold]
| |
[Controlled effect] [No effect]
Figure 1: Generic Protected Finality Sink and Anti-Bypass
Architecture
[Proposed consequential act]
|
[Hold in NES]
|
<All actual effect paths covered?> --NO--> [FENCE / REFUSE]
|YES
<Current topology / blocking valid?>--NO--> [INVALIDATE]
|YES
[Verify source grant / evidence]
|
<Valid scoped finality enablement?>--NO--> [REFUSE]
|YES
[Reconstruct actual pending effect]
|
<Actual resource + effect + scope match?>--NO--> [REFUSE]
|YES
<Current sink local state unconsumed?>--NO--> [REFUSE]
|YES
[Commit protected consumption]
|
[Permit only that effect]
Das Expires 29 April 2027 [Page 16]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Figure 2: End-to-End Effectuation Coverage and Sink Decision Sequence
7. Implementation Guidance for a Person Having Ordinary Skill in the
Art (PHOSITA)
7.1. Threat and Scope Discovery
Start with one governed effect class (e.g. outbound HTTPS send,
database mutation, secure file export, credentialed API dispatch).
Identify its effect-capable interfaces, administrator control,
affected users and security guarantees. List explicitly any
alternative routes that cannot be interposed. An agent-only tool
wrapper is not necessarily a non-bypassable gate.
7.2. Software Architecture
Separate lower-trust agent planning from an independently
administered validation service and from a receiving resource
gateway. A typical reference prototype can use isolated Linux
processes or containers, a restrictive network/firewall policy, a
prepared request queue and a protected transactional ledger. Keep
gate code and authority keys outside the agent runtime.
7.3. Actual Operation Control
At the controlled effect interface, parse the actual queued method,
resolved destination, resource identity, recipient and relevant
payload commitment from a protected request representation. Rebuild
the canonical descriptor there, not by trusting a displayed earlier
intent. Refuse undeclared request transformations and verify
protected resource versions.
7.4. Coverage and Blockability Discovery
Classify each known route as blocked-before-effect, conditionally
blockable, monitor-only, outside-control, or unknown. Store
discovered route identifiers, policy generation, enabled privileges,
assigned hardware devices and direct-access channels under
authenticated protected state. Treat monitor-only as insufficient
for mandatory blocking.
7.5. Runtime Change Reattestation
On tool update, privilege elevation, sandbox exit, new IPC target,
route change, device assignment, new kernel hook policy or credential
broker transition, update a protected coverage epoch and invalidate
stale enablements. Reconfirm the current set of effect-capable
routes before permitting new effects.
Das Expires 29 April 2027 [Page 17]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
7.6. Protected Authorization and Replay Resistance
Use scoped source grants, signed or otherwise authenticated evidence,
short-lived operation-specific references, nonce or version checks,
and durable sink-local consume-once state. In the reference
deployment use a transactional relational database with unique key on
logical operation id and sink id; hardware monotonic state is an
optional stronger substrate.
7.7. Gateway Enforcement for Web APIs
Use an HTTP/gRPC reverse proxy or trusted API handler at the actual
dispatch boundary. Constrain methods, request targets, content
hashes, redirects, audience and resource version. Distinguish TLS
client authentication or sender-constrained bearer token from source
approval for a specific operation. Require final receiver mediation
if a direct API route otherwise remains open.
7.8. Linux Containers and Host Connectors
Apply namespaces, seccomp or LSM/eBPF where authorized, restrictive
mount and network policies, and host-only connector credentials. A
connector must independently validate the actual pending request;
sandbox isolation without control of the host API is not sufficient.
7.9. Apple iOS and macOS Deployment
On iOS, build using supported App Intents, extensions, Keychain/
secure hardware APIs as available, managed enterprise authorization,
and server/resource-side gateways. Do not assume a third-party
application can intercept arbitrary other apps, kernel calls, private
APIs or physical I/O. On macOS, sandbox permissions and authorized
system extensions may support additional surfaces under applicable
entitlements.
7.10. Android Deployment
Use Android components and Binder IPC permission checks, app signing
and identity evidence, Keystore for protected key references, VPN/
service controls where permitted, and mandatory receiver-side
authorization for cross-app or remote effects. An ordinary app
cannot install universal kernel hooks or intercept inaccessible
system pathways without privileged support.
Das Expires 29 April 2027 [Page 18]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
7.11. UI and Accessibility Agents
Capture the current actionable UI/accessibility/DOM state in a
qualified observer, bind user confirmation to the exact semantic
operation and destination, and compare again at the protected
resource action. A screenshot alone is insufficient if the receiving
app mutates state between observation and effect.
7.12. Sandbox Output Promotion
Treat writing an internal draft and promoting it to a published
artifact as different consequences. Withhold output promotion,
public network dispatch, credential exercise and deployment until the
privileged host connector or receiving resource checks scope and
current enablement.
7.13. Device and Accelerator Surfaces
For effects traversing GPUs, DPUs, network controllers, storage
controllers or physical actuators, place a qualified gate at a point
that can actually stop the relevant command or output. Query/verify
current device ownership and outstanding command state before
changes. Uncontrolled peer-to-peer DMA or a bypassable driver
invalidates full-coverage claims.
7.14. Observability, Privacy and Recovery
Record protected rejection reason, source grant and evidence
references, actual descriptor commitment, coverage epoch and
consumption result without unnecessarily disclosing secret payloads.
On uncertain remote outcome, preserve local consumption and invoke
separately authorized reconciliation rather than blind replay.
7.15. Testing and Reproducibility
Publish exact build environments, cryptographic key fixtures, sink
policy, coverage graph, before-and-after protected state, reject
codes and logs. Version source schemas; include attack inputs and
negative cases. Do not claim passing results without execution
artifacts.
7.16. Independent Implementation Boundaries
Document trust assumptions: whether root/admin or device manufacturer
can bypass the gate, which routes are outside scope, how attacker
code can invoke protected components, and the compromise threshold of
validators. State where a trusted receiving resource, operating-
system cooperation or hardware control is required.
Das Expires 29 April 2027 [Page 19]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
8. Reference Interfaces, Data Structures, State Machines and Non-
Normative Algorithms
The example serializations and pseudocode are newly written technical
illustration for implementation review; they are not represented as
verbatim original patent text or as an IANA-registered wire format.
Their security-critical semantics must be reconciled with exact
original source embodiments before any standards proposal or
implementer claim.
8.1. Candidate Act and Actual Effect Descriptor
CandidateAct = {
version, ca_id, principal_id, workload_id,
source_grant, operation_class, intended_resource,
permitted_methods, exact_recipient_or_destination,
effect_parameters_commitment, policy_generation,
designated_sink, revocation_epoch, expiration
}
ActualEffect = {
observation_origin: receiving_sink,
resolved_resource_id, final_destination,
actual_method, actual_payload_commitment,
resource_version, runtime_generation,
effect_capable_interface, coverage_epoch
}
Figure 3: Candidate Act and Actual Effect Descriptor — proposed
reference algorithm or structure
8.2. Coverage Graph and Assurance Levels
EffectPath = {
id, source_workload, entry_point, transport,
reachable_resource, effect_class, privilege_level,
monitoring_capable, blocking_capable,
enforcement_component, owner, current_epoch
}
CoverageState = {
effect_class, identified_paths[], current_epoch,
mandatory_enforcement_routes[], uncovered_routes[],
change_attestation, qualification_timestamp
}
IMPORTANT: monitoring_capable != blocking_capable
Figure 4: Coverage Graph and Assurance Levels — proposed
reference algorithm or structure
Das Expires 29 April 2027 [Page 20]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
8.3. Sink Local Finality Consumption Schema
SinkState = {
sink_id, ca_id, effect_digest, grant_generation,
coverage_epoch, revocation_epoch, spent: boolean,
last_operation_version, outcome: enum {
PREPARED, WITHHELD, CONSUMED, DISPATCHED,
CONFIRMED, INDETERMINATE
}
}
UNIQUE(sink_id, ca_id, grant_generation)
Figure 5: Sink Local Finality Consumption Schema — proposed
reference algorithm or structure
8.4. Discover and Qualify Enforceable Paths
discover_coverage(effect_class, runtime):
routes = enumerate_effect_capable_paths(runtime, effect_class)
for route in routes:
property = protected_classify(route)
if property.effect_capable and not property.blocking_capable:
mark_uncovered(route)
commit_protected_coverage_epoch(routes, runtime.generation)
if any_required_route_uncovered: return INVALID
return QUALIFIED
ON topology_change: invalidate_related_enablings()
Figure 6: Discover and Qualify Enforceable Paths — proposed
reference algorithm or structure
8.5. Construct Protected Actual Operation at the Sink
reconstruct_pending_effect(prepared_request, sink):
fields = sink.read_effect_capable_request_fields()
resolved_target = sink.resolve_current_resource_identity(fields)
digest = canonicalize_and_commit(
method=fields.method, destination=resolved_target,
parameters=fields.effect_parameters,
content=fields.payload, resource_version=fields.version)
return ActualEffect(digest, sink.id, sink.coverage_epoch)
ON unknown_or_ambiguous_fields: return REFUSE
Figure 7: Construct Protected Actual Operation at the Sink —
proposed reference algorithm or structure
8.6. Independent Sink Verification and Atomic Consume
Das Expires 29 April 2027 [Page 21]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
effectuate(candidate, enabling, evidence, sink):
require sink.controls_exact_effect_interface()
require sink.coverage_epoch == current_coverage_epoch()
require current_source_grant(candidate)
require protected_evidence_matches(candidate, evidence)
actual = reconstruct_pending_effect(sink.pending_request, sink)
require actual within candidate.permitted_effect_envelope
require enabling.binds(actual, sink.id, candidate.ca_id)
require not sink.state.spent and not revoked(candidate)
atomic_sink_state_transition(spent=True, outcome=CONSUMED)
dispatch_only_verified_actual_operation()
on any failure: refuse and leave effect non-effective
Figure 8: Independent Sink Verification and Atomic Consume —
proposed reference algorithm or structure
8.7. Human Approved Computer-Use Action
qualify_ui_action(ui_state, confirmation, actual_action):
obs = independent_interface_state_observation(ui_state)
require qualified_observer_and_current_focus(obs)
require confirmation.binds_to(
obs.window, obs.target, obs.recipient, obs.effect,
obs.parameters, obs.state_generation)
require sink.observe_actual_effect() == confirmed_effect
require unchanged_relevant_state_or_revalidate()
return finality_sink_verify_and_consume(actual_action)
ON visual_or_semantic_ambiguity: withhold
Figure 9: Human Approved Computer-Use Action — proposed reference
algorithm or structure
8.8. Sandbox Privilege Transition and Output Promotion
promote_sandbox_operation(agent, prepared_output, sink):
ca = hold_non_effective(prepared_output)
require privilege_transition_source_grant(ca)
require prepared_output_classified_for_real_effect(ca)
require all_alternate_routes_covered(ca.effect_class)
require actual_effect_at_host_connector() == ca.authorized_effect
require credential_and_policy_current()
require one_use_sink_consumption()
perform_effect() # not before previous checks
Figure 10: Sandbox Privilege Transition and Output Promotion —
proposed reference algorithm or structure
Das Expires 29 April 2027 [Page 22]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
8.9. Stale Topology and Failure Matrix
IF path_unknown_or_monitor_only: WITHHOLD
IF coverage_epoch_stale: FENCE / REQUALIFY
IF prior_user_confirmation_not_bound_to_actual_act: WITHHOLD
IF resource_alias_or_redirect_changes_effect: WITHHOLD
IF sandbox gains uncontrolled host socket: INVALIDATE_COVERAGE
IF sink_local_authority_spent_or_replayed: REFUSE
IF remote_result_indeterminate: NO_BLIND_REPLAY
IF all mandatory actual effect predicates pass: CONSUME / RELEASE
Figure 11: Stale Topology and Failure Matrix — proposed reference
algorithm or structure
9. Detailed Source-Grounded Embodiment Disclosures: Page-Indexed
Primary Specification
The following sections preserve substantial text from the user-
supplied 3,567-page document, organized by original global page
number and subject. These are literal text extractions from the PDF,
not claims of independent third-party validation or guarantees of
earliest patent filing support. They are supplemented by separately
labeled implementation examples, tests and figures elsewhere in Part
4. Where a source range spans other workflows or cross-references,
consult the complete Zenodo specification for proper context.
9.1. Original Cross-Platform Consequence Control and Non-Effectuation
Foundation
Original technical source global pages 1-14; input volume TECHNICAL
SPECIFICATION -1-554.pdf. Primary Part 4 topic: Original Cross-
Platform Consequence Control and Non-Effectuation Foundation. The
patent specification may present optional embodiments, alternative
formulations and claim proposals; preserving its wording does not
convert each option into a requirement of a standard.
9.1.1. Protected Architecture and Trust-Boundary Diagram
[AI or app request]--->[Candidate Act / NES]
| |
[Qualified source grant] |
+-------->[PED / effect binding]
|
[Actual Finality Sink]
|
[Actual resource effect]
Das Expires 29 April 2027 [Page 23]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Figure 12: Original Cross-Platform Consequence Control and Non-
Effectuation Foundation — architecture
9.1.2. Operational Decision and Fail-Closed Flowchart
[Incoming effect request]
|
<Source and operation bounded?>--NO-->[Withhold]
|YES
[Translate effect across platform]
|
<Qualified current actual target?>--NO-->[Withhold]
|YES
[Sink enforce and consume]
Figure 13: Original Cross-Platform Consequence Control and Non-
Effectuation Foundation — operational flowchart
9.1.3. Original Page-by-Page Technical Disclosure
9.1.3.1. Source page 1 of the original specification
TITLE OF THE INVENTION
SYSTEMS AND METHODS FOR CROSS-PLATFORM INTEROPERABLE EXECUTION-
FINALITY CONTROL, PROTECTED AUTHORITY CONTINUITY, AND CONSEQUENCE
ENFORCEMENT ACROSS HETEROGENEOUS OPERATING SYSTEMS, DEVICES, AND
AUTONOMOUS COMPUTING ENVIRONMENTS
ABSTRACT
Disclosed are systems and methods for interoperable protected
execution-finality control across heterogeneous operating systems,
including Android, iOS, and other mobile, desktop, cloud, and
embedded environments. A proposed consequential operation is
represented as a Candidate Act and retained in a Non-Effective State.
Platform-specific adapters translate qualified authorization,
identity, application, device, and security evidence into a protected
canonical effect descriptor without converting upstream permission
into execution authority. A Protected Enforcement Domain verifies
originating and delegated authority, current revocation, operation
semantics, and enforcement-path coverage, and constitutes scoped non-
bearer finality enablement. A designated Finality Sink independently
obtains or reconstructs the actual pending operation, verifies its
correspondence with protected evidence and current sink-local state,
and controls authorization consumption before effectuation. Cross-
device transfer may employ authenticated ownership epochs and source
fencing. Unavailable mandatory enforcement causes withholding. The
Das Expires 29 April 2027 [Page 24]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
architecture preserves vendor-independent authority semantics while
accommodating distinct platform security mechanisms and covered
consequential interfaces.
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates generally to computer security,
operating-system interoperability, protected execution control,
autonomous artificial-intelligence systems, distributed
authorization, trusted computing, and the governance of consequential
operations across heterogeneous computing environments.
More particularly, the invention concerns systems, methods,
apparatus, machine-readable authorization structures, protected
execution components, and interoperable enforcement protocols for
preserving and verifying execution authority when applications,
autonomous agents, services, computational workloads, or device-
control functions operate across different operating systems,
hardware architectures, administrative domains, security substrates,
and communication environments.
The invention is applicable to mobile operating systems, including
Android, iOS, iPadOS, and other mobile platforms; desktop operating
systems, including macOS, Windows, Linux, and other computing
environments; and wearable devices, embedded controllers,
communication systems, cloud infrastructures, confidential-computing
environments, virtual machines, autonomous robots, vehicles, and
future computing platforms.
9.1.3.2. Source page 2 of the original specification
The named operating systems and commercial environments are
illustrative, non-limiting examples. The invention does not require
participation by any particular operating-system provider,
manufacturer, application ecosystem, or proprietary technology.
2. Increasing Fragmentation of Operating-System and Application
Security
Modern computing environments comprise multiple independently
administered operating systems, application ecosystems, device
manufacturers, identity providers, cloud services, and security
architectures.
Das Expires 29 April 2027 [Page 25]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Different platforms may implement substantially different mechanisms
for application isolation, permission enforcement, credential
storage, interprocess communication, secure execution, hardware-
backed cryptographic operations, network control, user approval, and
access to sensitive resources.
For example, one operating system may expose selected protected
application interfaces, permission services, secure hardware
functions, and controlled background-execution facilities, while
another operating system may provide different forms of application
sandboxing, entitlement verification, privileged-service mediation,
or device-security interfaces.
These mechanisms may individually provide useful technical security
properties, but their differences complicate the preservation of a
consistent and independently enforceable authorization relationship
when a computational task crosses platform boundaries.
A permission recognized by one operating system is not necessarily
semantically equivalent to an entitlement, authorization, credential,
or protected resource grant recognized by another.
Likewise, the ability of one application or service to request an
operation does not establish that a receiving application, operating
system, privileged controller, or remote resource is authorized to
produce the requested consequential effect.
Accordingly, interoperability between computing environments requires
more than the exchange of commands, files, credentials, permissions,
application messages, or authenticated identities.
3. Limitations of Conventional Cross-Platform Interoperability
Conventional interoperability systems commonly enable information
exchange, task synchronization, remote procedure invocation,
application linking, cross-device communication, identity federation,
and service-to-service authorization.
Such mechanisms may permit a task initiated in a first environment to
continue in a second environment.
However, technical interoperability does not necessarily establish
interoperable execution authority.
An application operating in an Android-based environment may generate
a request intended to produce an effect within an iOS-based
environment, or vice versa.
Das Expires 29 April 2027 [Page 26]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.1.3.3. Source page 3 of the original specification
The receiving environment may authenticate the sending application,
accept a structured request, recognize a permitted service identity,
or validate a delegated credential.
Nevertheless, the requested operation may differ materially from the
operation originally authorized by the relevant principal.
The difference may concern the actual resource, recipient, outgoing
information, operation parameters, current resource version,
delegated scope, original authorization conditions, or applicable
device-security state.
A successful communication handshake, authenticated application
request, or cross-platform permission translation therefore does not,
by itself, establish authority for the actual consequential
operation.
4. Absence of Uniform Execution-Finality Semantics
Existing operating systems and application frameworks frequently
distinguish among authenticated identities, permissions, application
capabilities, hardware entitlements, and resource-access policies.
However, those mechanisms do not necessarily implement the same
technical meaning of final authorization at the boundary where a
consequential operation becomes effective.
An approval generated in one domain may be consumed by an
intermediary service in another domain, while the ultimate resource
modification occurs through a different component.
A receiving component may interpret the approved operation
differently, apply a different authorization scope, or invoke an
additional privileged interface.
Consequently, upstream authorization may become detached from the
actual operation eventually executed.
This problem becomes particularly significant when the operation
concerns persistent data modification, confidential information
export, credential activation, financial instructions, network
transmission, device configuration, physical actuation, or another
consequential operation.
Das Expires 29 April 2027 [Page 27]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
There remains a technical need for a platform-independent
representation of protected consequential authority whose operative
meaning is verified at the actual effectuation boundary rather than
inferred solely from the success of an upstream permission mechanism.
5. Autonomous Artificial-Intelligence Agents and Cross-Platform
Execution
Autonomous AI agents and computational assistants increasingly
perform tasks involving multiple applications, devices, execution
environments, and remotely administered services.
An agent may receive an instruction on a mobile device, perform
planning using a remote computational service, delegate part of the
task to another agent, retrieve information from a third-party
application, and subsequently request a consequential operation
through a different platform.
9.1.3.4. Source page 4 of the original specification
The original task may pass through several computational
transformations, including model inference, tool selection, message
translation, task delegation, application-interface invocation, and
execution-context migration.
These transformations may alter the representation of the requested
operation without necessarily establishing renewed authority from the
originating principal.
Moreover, autonomous agents may encounter malicious instructions,
compromised external content, stale task context, incorrect resource
references, hallucinated operation parameters, or manipulated tool
responses.
A computational system may therefore generate a technically
executable command that exceeds the scope of the original
authorization.
Merely isolating the agent within a sandbox, authenticating its
identity, or restricting access to selected tools does not
necessarily prevent an unauthorized effect through another accessible
execution route.
The fundamental technical issue is the separation between
computational capability and independently established authority to
cause a real consequence.
6. Cross-Device Authority Duplication and Migration
Das Expires 29 April 2027 [Page 28]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Cross-device continuity presents additional security and consistency
problems.
When a task moves between devices, the transfer may include
application state, execution context, cached credentials, model
state, memory, instructions, command queues, or unfinished
operations.
However, transferring computational state does not automatically
transfer valid authority to perform consequential operations.
Similarly, transferring a task to a receiving device does not
automatically invalidate effectuation authority remaining on the
originating device.
For example, a user may initiate an autonomous workflow on one mobile
operating system and continue the workflow on another mobile or
desktop environment.
If both environments retain independently usable authority for the
same unfinished operation, duplicate or conflicting consequences may
occur.
A stale device may also resume after suspension, recover an outdated
application state, or attempt to exercise authority that has already
been transferred, revoked, consumed, or superseded.
Conventional data synchronization alone does not necessarily
establish exclusive execution ownership, protected authority epochs,
source-device fencing, or destination-local validation of the actual
consequential operation.
7. Inconsistent Enforcement Capabilities Across Platforms
Different operating systems and devices expose different levels of
control over applications, privileged services, network
communications, storage operations, hardware functions, and security-
sensitive interfaces.
9.1.3.5. Source page 5 of the original specification
Some environments permit enforcement through operating-system
security components or protected hardware controllers.
Other environments may permit only application-level mediation,
approved extension interfaces, managed-service gateways, server-side
authorization, or remote resource enforcement.
Das Expires 29 April 2027 [Page 29]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Certain security mechanisms provide blocking capability, while others
provide observation, logging, notification, policy advice, or post-
operation auditing.
A system that merely receives a security event cannot necessarily
prevent the corresponding effect.
Likewise, a system that controls one application interface may not
control an alternative interface capable of producing the same
consequence.
A generic interoperability layer that assumes identical operating-
system privileges or uniform enforcement interfaces may therefore
provide incomplete protection when deployed across heterogeneous
platforms.
A need exists to determine the actual enforcement capability of each
participating security mechanism and to qualify whether the relevant
effectuation path is subject to mandatory protected control.
8. Limitations of Credential-Based and Permission-Based Approaches
Conventional authorization systems may use access tokens,
cryptographic signatures, structured permission grants, proof-of-
possession protocols, mutual authentication, credential brokers,
hardware-backed keys, and delegated authorization.
These mechanisms provide valuable security functions.
However, successful authentication, credential validity, permission
possession, or cryptographic proof does not necessarily establish
that a particular resource-side consequential operation remains
authorized at execution time.
An access token may remain valid while the operation exceeds its
intended effect scope.
A cryptographic signature may authenticate an earlier approval while
the actual destination, resource identity, operation semantics, or
policy state has changed.
A credential broker may possess technical authority to perform a
broad range of operations even when the requesting agent is permitted
to initiate only one narrowly defined action.
Accordingly, the security problem is not resolved merely by
transferring, translating, exchanging, or validating credentials
between operating systems.
Das Expires 29 April 2027 [Page 30]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The actual consequential effect must remain independently bound to
current protected authority.
9. Revocation, Replay, and Distributed-State Problems
Cross-platform environments may maintain authorization and revocation
state in multiple administrative domains.
9.1.3.6. Source page 6 of the original specification
A source device may revoke authority while a destination device
remains disconnected.
A remote service may receive a revocation notification after a
previously authorized operation has already entered a queue.
A cached permission decision may remain locally available after the
underlying grant has expired or changed.
Similarly, a previously generated authorization artifact may be
copied, replayed, presented to another execution sink, or restored
through an outdated application or virtual-machine snapshot.
These conditions create technical risks involving stale authority,
duplicate effectuation, inconsistent consumption accounting, and
delayed enforcement of revocation.
Immediate revocation cannot be assumed in a disconnected receiving
domain without an appropriate supporting mechanism.
Interoperable execution control must therefore account for authority
generations, bounded validity, protected consumption state,
revocation dependencies, and conservative handling of uncertain
distributed conditions.
10. Technical Problem Addressed by the Invention
In view of the foregoing limitations, there exists a need for an
interoperable protected execution architecture capable of governing
consequential operations across heterogeneous operating systems,
devices, applications, and administrative domains without requiring
identical security implementations or transferring unrestricted
authority between them.
More particularly, the technical problem is how to:
(a) preserve the scope and identity of originating execution
authority across different platforms;
Das Expires 29 April 2027 [Page 31]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
(b) translate heterogeneous authorization and security evidence into
a machine-verifiable, operation-specific effect representation;
(c) prevent a computational request, authenticated identity,
credential, or platform permission from independently constituting
final authority;
(d) maintain proposed consequential operations in an enforceable non-
effective condition;
(e) establish protected finality enablement dependent upon current
authority, revocation, security context, and applicable enforcement
capability;
(f) independently verify the actual pending consequential operation
at the receiving resource or device boundary;
(g) prevent unauthorized replay, stale-owner execution, cross-
platform scope expansion, or duplicate effectuation;
(h) support bounded delegation and authenticated transfer of
execution authority between heterogeneous environments; and
9.1.3.7. Source page 7 of the original specification
(i) preserve the required security properties even when different
platforms employ different software, hardware, communication, and
authorization mechanisms.
The present invention addresses these technical problems through a
protected, operation-specific execution-finality architecture having
interoperable authority semantics and qualified platform-specific
enforcement implementations.
SUMMARY OF THE INVENTION
1. General Overview
The present invention provides systems, methods, apparatus, protected
execution components, interoperable authorization protocols, machine-
verifiable records, and computer-implemented procedures for governing
consequential computational operations across heterogeneous operating
systems and computing environments.
The disclosed architecture is applicable to Android, iOS, and other
mobile operating systems, together with desktop, cloud, edge,
embedded, industrial, network, robotic, and future autonomous
computing systems.
Das Expires 29 April 2027 [Page 32]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The invention does not require the participating environments to
implement identical operating-system kernels, security frameworks,
application permission models, hardware architectures, cryptographic
processors, or proprietary communication protocols.
Instead, the architecture establishes a common protected execution-
finality relationship in which a proposed operation remains non-
effective until the required operation-specific authority is
established and verified by a technical boundary capable of
withholding the governed consequence.
The foundational principle is that computation is not authority to
act.
The production, transmission, translation, delegation, or receipt of
a computational request does not automatically establish authority to
produce its external or persistent effect.
2. Platform-Independent Execution-Finality Framework
In one implementation, the system comprises a Requesting
Computational Entity, a Candidate Act construction component, a Non-
Effective Holding Mechanism, one or more Protected Enforcement
Domains, protected authorization and evidence adapters, an authority
preparation component, and at least one designated Finality Sink.
The requesting computational entity may operate within a mobile
application, autonomous assistant, operating-system service, cloud
agent, remote tool, embedded controller, or other computational
workload.
A proposed consequential operation is represented as a Candidate Act
containing or referencing the security-relevant identity, operation
class, resource, destination, parameters, originating authority, and
applicable execution context.
The proposed operation is maintained in a Non-Effective State by an
enforceable holding mechanism until the relevant protected conditions
are satisfied.
9.1.3.8. Source page 8 of the original specification
A protected authority controller verifies applicable evidence and
establishes scoped execution-finality enablement.
The actual Finality Sink obtains or reconstructs the pending
consequential operation and determines whether it corresponds to the
protected authorization before permitting the effect.
Das Expires 29 April 2027 [Page 33]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The number, placement, and physical implementation of the
participating components may vary according to the selected platform
and threat model.
3. Interoperability Between Android, iOS, and Other Operating
Systems
In a non-limiting embodiment, the invention provides interoperable
protected execution-finality control between computing environments
operating different mobile operating systems, including Android-based
and iOS-based devices.
A consequential operation initiated within a first platform may be
represented using a protected canonical effect descriptor and
communicated to an authorized receiving component operating within a
second platform.
The receiving component does not automatically treat the originating
platform's permission, application entitlement, authenticated
message, or credential as sufficient authority to cause the requested
effect.
Instead, the receiving platform applies its own qualified protected
verification and enforcement mechanisms while preserving the required
operation-specific authorization conditions.
For example, a task originating within an Android-based application
may be evaluated by a protected authorization service and
subsequently presented to a controlled application function, resource
gateway, or qualified effectuation component associated with an iOS-
based environment.
Conversely, a task originating in an iOS-based environment may be
submitted to a protected resource interface associated with an
Android-based environment.
In either direction, execution remains dependent upon independently
verified authority, current applicable state, and the actual
consequential operation.
The same technical relationship may apply to interoperability
involving iPadOS, macOS, Windows, Linux, other mobile or desktop
systems, cloud services, embedded platforms, and subsequently
developed operating systems.
The invention does not presume that any operating system exposes
unrestricted kernel, application, network, or hardware interception
facilities. Enforcement is implemented through qualified interfaces
Das Expires 29 April 2027 [Page 34]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
actually available and authorized within the relevant deployment,
including protected application dispatchers, privileged brokers,
managed resource controllers, remote enforcement gateways, and
destination-side Finality Sinks.
4. Protected Authorization-to-Effect Translation
9.1.3.9. Source page 9 of the original specification
In another aspect, the invention provides a protected translation
mechanism configured to obtain authorization and security information
from heterogeneous source systems and convert the relevant
information into a bounded consequential-operation representation.
The source information may comprise identity assertions, application
permissions, delegated authorization records, structured action
descriptions, protected device state, cryptographic authentication
evidence, resource-access restrictions, or other qualified security
information.
A protected translation controller determines the actual technical
meaning of the requested operation and produces or verifies a
canonical effect descriptor.
The descriptor may identify an originating principal, requesting
component, actual operation class, resource identity, effective
recipient, operation parameters, permitted effect envelope, relevant
policy state, and designated enforcement boundary.
Different platforms may employ different native permission names or
resource-interface structures while using equivalent protected effect
semantics for the specific governed operation.
A source permission is not silently expanded merely because the
receiving platform implements a broader technical operation.
Where the protected translation cannot establish the necessary
correspondence, the affected consequential operation remains
withheld.
5. Independent Protected Authority Across Platform Boundaries
The invention further provides a Protected Enforcement Domain
configured to evaluate applicable originating authority, delegated
scope, current resource conditions, relevant revocation dependencies,
security-substrate qualifications, and operation-specific validation
evidence.
Das Expires 29 April 2027 [Page 35]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The Protected Enforcement Domain may comprise a protected operating-
system component, independently secured service, secure processor,
trusted execution environment, hardware controller, remote protected
validator, or compatible combination thereof.
In implementations requiring separate collection-time and execution-
time validation, corresponding protected evidence instances may
independently evaluate the applicable Candidate Act and establish
authenticated evidence commitments.
A protected finality controller may subsequently create, activate,
derive, sign, or otherwise constitute scoped non-bearer execution
enablement.
Such enablement may be bound to the specific operation, permitted
effect, resource identity, designated sink, relevant authority
generation, current enforcement coverage, validity conditions, and
protected consumption state.
The enablement need not be provided to the requesting application as
a reusable transferable credential.
6. Independent Finality Sink Verification
9.1.3.10. Source page 10 of the original specification
A principal aspect of the invention is the independent verification
of the actual pending operation at its consequential enforcement
boundary.
The Finality Sink may comprise a protected application-function
dispatcher, network gateway, storage transaction controller,
credential-release interface, cloud API enforcement component, device
command controller, hardware interface, payment dispatcher, or other
qualified effectuation mechanism.
The Finality Sink obtains or reconstructs relevant actual operation
parameters from the controlled effectuation path.
The sink compares the pending operation against the authorized effect
descriptor, protected validation evidence, scoped finality
enablement, current authority state, and applicable sink-local
protected state.
A material mismatch, stale authorization, unqualified enforcement
path, revoked permission, unsupported resource identity, or invalid
authority-consumption condition prevents the governed operation from
becoming effective.
Das Expires 29 April 2027 [Page 36]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Where single-use or bounded-use authorization applies, the relevant
protected consumption transition is enforced before the corresponding
consequence is released.
7. Cross-Device Execution Authority Continuity and Migration
In another embodiment, the invention enables the controlled migration
or reestablishment of unfinished execution authority between
heterogeneous computing environments.
A computational workflow may move between smartphones, tablets,
desktop computers, cloud instances, edge devices, virtual machines,
hardware accelerators, or other computational systems.
The movement of computational state is distinguished from the
transfer of authority to produce consequential effects.
Where exclusive operation ownership is required, the system may
establish authenticated device identities, protected ownership
generations, monotonic authority epochs, source-device fencing, and
destination-specific finality enablement.
A previous execution environment is prevented, through the applicable
protected enforcement mechanisms, from exercising stale authority
after exclusive effectuation ownership has been transferred.
The destination Finality Sink independently verifies current
ownership, authorized effect scope, actual operation parameters, and
protected consumption state.
A copied task image, migrated process, restored snapshot, or
transferred credential reference does not independently create or
duplicate execution authority.
8. Cross-Provider and Cross-Agent Interoperability
9.1.3.11. Source page 11 of the original specification
The architecture may additionally support interoperability between
computational agents and application services administered by
different providers.
An originating principal may authorize a bounded task that is
subsequently delegated through one or more agents, services, devices,
or administrative domains.
Das Expires 29 April 2027 [Page 37]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Protected delegation records may preserve originating authority
references, delegated scope, relevant resource limits, current
revocation dependencies, and authenticated delegation relationships.
A receiving agent may perform authorized computation without
receiving unrestricted authority over the originating principal's
resources.
Where a consequential operation is delegated, the receiving Finality
Sink verifies the current authorized scope and the actual pending
effect.
The transfer of task information, agent messages, inference results,
or executable instructions does not itself enlarge the original
permitted authority.
9. Dynamic Platform-Security Qualification
In another aspect, the invention provides a mechanism for qualifying
heterogeneous security components according to the properties they
actually establish.
A protected controller may identify whether a selected security
mechanism provides authentication, observation, advisory policy
evaluation, isolation, revocation notification, resource control, or
mandatory blocking of a specified effect.
The controller may maintain protected enforcement-qualification
records identifying the current security component, controlled
resource, enforcement mode, operation-visibility capability,
applicable configuration generation, and unresolved bypass
conditions.
A component is not treated as equivalent to another merely because
both are described as security mechanisms.
A replacement operating-system interface, application gateway,
sandbox mechanism, cryptographic provider, or hardware controller
must provide the properties required for the corresponding protected
operation.
Material changes to enforcement capability or relevant execution
semantics may invalidate dependent finality authorization until
revalidation is completed.
10. Interoperability Through Existing and Future Technical
Mechanisms
Das Expires 29 April 2027 [Page 38]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The invention may employ existing authorization protocols,
authenticated communication mechanisms, structured operation
representations, interprocess communication, cryptographic
signatures, protected key storage, secure processors, transactional
state stores, and resource-side enforcement interfaces.
Such mechanisms are individually usable as established technical
implementation substrates.
9.1.3.12. Source page 12 of the original specification
In selected embodiments, typed JSON, CBOR, deterministic binary
encodings, or other canonical machine-readable representations may
communicate protected operation and evidence information.
Platform-specific adapters may translate native authorization or
application-operation representations into the required interoperable
protected structures.
The architecture is not restricted to one serialization format,
cryptographic algorithm, permission framework, application-
development environment, transport protocol, or processor instruction
set.
The operative requirements concern the preservation of protected
authority dependencies, correct actual-operation correspondence,
sufficient enforcement coverage, and verified finality control.
11. Revocation, Replay Prevention, and Protected State Continuity
The invention may maintain protected authorization generations,
revocation references, consumption records, device-ownership epochs,
current resource state, and relevant enforcement-coverage
information.
Before releasing an operation, the applicable Finality Sink verifies
the protected state required by the selected implementation.
Previously valid authorization may be rejected when the source
authority has been revoked, the relevant resource has materially
changed, or the permitted authority has already been consumed.
A replayed or misdirected finality reference does not automatically
authorize another operation or a different Finality Sink.
Disconnected environments may employ bounded offline authority,
protected counters, expiry constraints, or other conservative
validity mechanisms where technically supported.
Das Expires 29 April 2027 [Page 39]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Where current mandatory authorization cannot be established, the
corresponding governed consequence remains withheld rather than being
released on the assumption that earlier authorization remains valid.
12. Platform-Independent Security Without Mandatory Vendor
Dependence
The invention is not limited to a specific commercial operating
system, manufacturer, application store, cloud provider, hardware-
security product, AI model, or agent framework.
Its implementation may use different qualified security substrates
for different effect classes and deployment environments.
For example, one implementation may use a protected application
gateway, another may use a privileged operating-system resource
controller, and another may use a hardware-backed Finality Sink or
independently controlled remote service.
An implementation need not reproduce the internal architecture of
another operating system to establish a protected execution-finality
relationship over operations that it can actually govern.
9.1.3.13. Source page 13 of the original specification
Where a particular platform does not provide an authorized mechanism
capable of withholding a selected local operation, the architecture
does not assume that such an operation is protected by a merely
observational interface. Protection may instead be implemented at an
available qualified resource, service, gateway, or destination
boundary, subject to the corresponding enforcement coverage.
Accordingly, interoperability concerns equivalent protected
execution-authority semantics and enforceable consequence control
rather than mandatory uniformity of proprietary platform mechanisms.
13. Optional Specialized Technical Extensions
The disclosed architecture may be combined with compatible
specialized verification mechanisms described in the specification.
Such mechanisms may include protected cross-agent conflict
coordination, semantic correspondence between a user-selected object
and an actual operation target, cumulative privacy-exposure
constraints, delegated-authority conservation, operation-semantics
continuity, hardware command control, protected physical-state
validation, authenticated actual-effect evidence, and receipt-gated
causal continuation.
Das Expires 29 April 2027 [Page 40]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Where an operation requires one of these specialized conditions, the
applicable condition may become a mandatory predicate of that
operation's finality authorization.
However, the presence of an optional verification mechanism in one
embodiment does not make the mechanism universally necessary for
every implementation.
Each embodiment may select the components required for the particular
consequential effect and intended technical trust model.
14. Technical Advantages and Effects
The disclosed invention seeks to provide a common protected
execution-finality framework across heterogeneous operating systems
and computing environments while accommodating their different native
security implementations.
The architecture can provide operation-specific protection against
authorization-to-effect mismatches, stale permission use,
unauthorized scope expansion, duplicate effectuation, cross-device
authority conflicts, and selected enforcement-bypass conditions
within the coverage of the implementation.
It distinguishes the authority to compute, transmit, delegate,
authenticate, or access a tool from the protected authority required
to produce a particular real-world or persistent consequence.
The invention may further preserve authority continuity when a
workflow moves across Android, iOS, other operating systems,
independent applications, remote agents, and cloud or hardware
execution environments.
Unlike an architecture that relies solely upon uniform platform
permissions or transferable credentials, the disclosed relationship
conditions consequential effectuation upon independently verified
protected authority and actual-operation correspondence at a
qualified enforcement boundary.
9.1.3.14. Source page 14 of the original specification
The resulting framework enables heterogeneous platforms to contribute
different security mechanisms while retaining the required protected
relationships between original authority, consequential operation,
current state, and final effectuation.
15. Scope and Non-Limiting Character of the Disclosure
Das Expires 29 April 2027 [Page 41]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The foregoing summary describes representative implementations and is
not intended to restrict the invention to a particular arrangement,
operating system, software framework, network architecture, security
processor, cryptographic protocol, or commercial implementation.
Compatible features described in the specification may be employed
independently or in combination, subject to their applicable
technical requirements.
The disclosed algorithms, machine-readable records, state
transitions, reference implementations, examples, and experimental
procedures are illustrative and non-limiting aids to enable a person
having ordinary skill in the art to implement the corresponding
embodiments.
A component may perform multiple logical functions, and selected
functions may be distributed across independently protected domains,
provided that the technical properties expressly required by the
relevant implementation are preserved.
The invention encompasses present and future qualified
implementations of interoperable execution-finality control across
heterogeneous computing environments, within the scope supported by
the detailed disclosure and the appended claims.
9.2. CW-1 Source: Protected Execution-Finality and Sink Enforcement
Original technical source global pages 15-62; input volume TECHNICAL
SPECIFICATION -1-554.pdf. Primary Part 4 topic: CW-1 Source:
Protected Execution-Finality and Sink Enforcement. The patent
specification may present optional embodiments, alternative
formulations and claim proposals; preserving its wording does not
convert each option into a requirement of a standard.
9.2.1. Protected Architecture and Trust-Boundary Diagram
[Originating authority]---->[Candidate Act held NES]
|
[Independent protected checks]
|
[Scoped finality authority]
|
[Receiving actual-operation gate]
|
[Sink-local state / finality sink]
Figure 14: CW-1 Source: Protected Execution-Finality and Sink
Enforcement — architecture
Das Expires 29 April 2027 [Page 42]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.2.2. Operational Decision and Fail-Closed Flowchart
[Construct CA]
|
[Hold NES; validate]
|
<Coverage and current authority valid?>--NO-->[Hold]
|YES
[Sink observes actual effect]
|
<Evidence/enabling/effect equal?>--NO-->[Refuse]
|YES
[Consume under sink-local state]
|
[Controlled release]
Figure 15: CW-1 Source: Protected Execution-Finality and Sink
Enforcement — operational flowchart
9.2.3. Original Page-by-Page Technical Disclosure
9.2.3.1. Source page 15 of the original specification
COMMON MASTER WORKFLOW CW-1
MODULAR PROTECTED EXECUTION-FINALITY ARCHITECTURE WITH ACTUAL-
OPERATION RECONSTRUCTION, INDEPENDENT PROTECTED AUTHORITY, NON-
BYPASSABLE CONSEQUENCE ENFORCEMENT, CROSS-DOMAIN SECURITY, AND
OPTIONAL ADVANCED TECHNICAL MECHANISMS FOR PRESENT AND FUTURE
AUTONOMOUS COMPUTING SYSTEMS
CW-1.0 — PURPOSE, TECHNICAL FIELD, AND GENERAL DESCRIPTION
The present disclosure provides a Common Master Workflow, designated
CW-1, for governing consequential operations proposed, prepared,
scheduled, delegated, transmitted, or otherwise initiated by
autonomous computational entities.
Such entities may include artificial-intelligence agents, machine-
learning systems, autonomous assistants, multi-agent execution
frameworks, operating-system services, applications, device
controllers, distributed software services, embedded computing
systems, robotic controllers, programmable hardware, communication
infrastructure, and other computational entities capable of
initiating externally consequential operations.
CW-1 establishes a common technical foundation for the inventions and
embodiments described subsequently in this specification.
Das Expires 29 April 2027 [Page 43]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The workflow distinguishes the computational production of a proposed
operation from the protected technical authority required to cause
its consequential effect.
In a principal implementation, an operation proposed by a
computational entity is represented as a Candidate Act and is
maintained in a Non-Effective State until applicable authorization
conditions are satisfied.
A Protected Enforcement Domain evaluates the applicable evidence,
authorization, current technical conditions, and protected state.
The applicable protected authority produces, enables, or commits
scoped finality authorization.
A Finality Sink independently obtains or reconstructs the actual
pending operation and verifies the authority against the real
operation presented at the consequential boundary.
The Finality Sink permits the specified consequence only upon
successful verification of all mandatory conditions.
The authorization may be cryptographically represented, maintained as
protected state, implemented through secure hardware, or realized
through a combination of protected software and hardware mechanisms.
The system may operate across a single processor, multiple processes,
multiple devices, administrative domains, protected controllers, or
distributed infrastructure.
CW-1.0.1 — Fundamental Technical Principle
The foundational principle is:
9.2.3.2. Source page 16 of the original specification
Computation is not authority to act.
The production of a command, plan, model output, tool invocation,
workflow instruction, transaction proposal, or executable operation
does not itself confer final authority to cause the corresponding
consequential effect.
Similarly, an agent's successful authentication, possession of an API
credential, access to a software tool, or apparent satisfaction of an
application-level policy does not automatically establish the
complete protected authority required by a particular execution-
finality implementation.
Das Expires 29 April 2027 [Page 44]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The relevant authority must be verified according to the defined
protected trust model and at an enforcement boundary capable of
withholding the actual effect.
CW-1.0.2 — Common Architecture Rather Than One Mandatory Physical
Arrangement
CW-1 is not restricted to one hardware or software topology.
The protected validation function and Finality Sink may be separated
or integrated.
The protected authority may reside within a dedicated security
processor, secure microcontroller, isolated execution environment,
protected operating-system service, firmware controller, remote
protected authorization service, or another computing substrate
providing the required security properties.
A single protected component may implement multiple logical
functions.
Alternatively, each function may be distributed among independently
controlled devices.
The defining technical relationship is the controlled progression
from Candidate Act through protected authorization to independent
final effectuation verification.
The physical number of processors, devices, servers, or communication
links is not an essential limitation unless expressly required by a
particular embodiment.
CW-1.0.3 — General Proposed Inventive Direction
The candidate technical contribution of CW-1 concerns the combination
and enforcement relationships among operation-specific non-authority,
protected evidence evaluation, scoped execution enablement, actual
pending-operation reconstruction, sink-local protected state, and
effectuation-boundary control.
The proposed distinction is not that an AI agent uses a sandbox,
cryptographic key, access-control rule, approval screen, or security
gateway.
Those techniques are individually established.
Das Expires 29 April 2027 [Page 45]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The technical question is whether a particular implemented
combination makes independently verified, operation-specific
protected authority a necessary condition for the actual
consequential effect and prevents an untrusted computational entity
from bypassing that condition through an alternative route within the
claimed enforcement coverage.
CW-1.0.4 — Optional Technical Extensions
9.2.3.3. Source page 17 of the original specification
CW-1 supports additional mechanisms addressing concurrent agents,
conflicting effects, semantic target correspondence, delegated
authority, privacy constraints, resource allocation, protected state
continuity, remote execution, actual outcome witnessing, hardware
enforcement, user reauthorization, and causal continuation between
consequential phases.
Each extension may be applied individually or in compatible
combinations.
No optional mechanism is universally mandatory merely because it
appears in CW-1.
Where an embodiment expressly requires a particular technical
feature, omission of that feature is not treated as satisfying the
corresponding embodiment.
CW-1.0.5 — Scope of Present and Future Implementations
The common architecture is applicable to presently implementable
systems using protected software gateways, secure processors,
transaction controllers, cryptographic authorization, hardware
command gates, protected storage, and authenticated communication.
It also supports proposed advanced implementations involving cross-
provider autonomous agents, heterogeneous compute accelerators,
multi-device autonomy, safety-critical robotic systems, advanced
communication networks, confidential computing, distributed protected
validators, and future effect-capable hardware interfaces.
The advanced implementations are technical alternatives and
development directions, not assertions that such systems have already
been built or commercially deployed.
CW-1.1 — RELATIONSHIP TO INDIVIDUAL EMBODIMENTS
Das Expires 29 April 2027 [Page 46]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
CW-1 provides a reusable common protected execution framework for the
subsequent embodiments.
An individual embodiment may incorporate the baseline Candidate Act,
Non-Effective State, Protected Enforcement Domain, scoped authority,
and Finality Sink mechanisms without requiring every additional
verification module.
For example, a cross-agent conflict embodiment may require protected
conflict reservations.
A semantic correspondence embodiment may require evidence linking a
user-observed object to the actual operation target.
A privacy-composition embodiment may require protected cumulative
disclosure state.
A phased-effectuation embodiment may require an authenticated prior
real-effect receipt.
A protected device-migration embodiment may require exclusive
authority ownership and stale-owner fencing.
The relevant technical requirements are selected according to the
particular effect being governed.
CW-1.1.1 — Reference to CW-2
CW-2 provides an optional specialized mechanism for causally ordered
receipt-gated effectuation.
9.2.3.4. Source page 18 of the original specification
Where the principal inter-phase CW-2 implementation is selected, an
earlier bounded real effect produces qualified evidence accepted by
an authorized cryptographically identifiable Interim Effectuation
Validator.
The validator-accepted receipt is a necessary causal enabling factor
for the next consequential phase.
The next Finality Sink verifies the applicable authenticated receipt-
dependent condition before permitting the successor effect.
CW-1 does not require that every single-effect operation use such a
phased continuation mechanism.
CW-1.1.2 — Reference to CW-3
Das Expires 29 April 2027 [Page 47]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
CW-3 may provide optional protected anomaly-triggered human or
automated reauthorization.
Where an autonomous operation departs from its originally authorized
scope, a protected system may require renewed approval.
However, approval does not automatically satisfy unrelated mandatory
technical predicates, including current resource identity, finality
authority, physical safety constraints, or an applicable CW-2 causal
receipt.
CW-1.1.3 — Independent Inventive Contributions
Each subsequent embodiment may disclose additional technical
structures, state transitions, algorithms, threat models, actual
enforcement interfaces, and technical effects.
The general existence of CW-1 does not establish that every optional
embodiment is novel or inventive.
Individual technical contributions must be evaluated in relation to
their corresponding prior art.
CW-1.2 — TECHNICAL PROBLEMS AND LIMITATIONS OF CONVENTIONAL SYSTEMS
CW-1.2.1 — Conventional Permission Does Not Necessarily Govern Actual
Consequence
A conventional access-control system may determine whether a
requesting principal has permission to use a resource.
The permitted software may nevertheless construct different actual
command parameters after the authorization check.
For example, an agent may receive permission to send a selected
document to a designated destination.
After the initial permission is granted, the selected document,
destination, version, or transmission parameters may change.
9.2.3.5. Source page 19 of the original specification
A static permission does not necessarily establish that the actual
later transmission corresponds to the authorized operation.
CW-1 addresses this problem through operation-specific authority
binding and final enforcement against the actual pending effect.
Das Expires 29 April 2027 [Page 48]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
CW-1.2.2 — Conventional Authentication Does Not Establish Full
Execution Authority
Authentication establishes an identity under a particular trust
model.
It does not necessarily establish that every requested operation by
the authenticated entity is authorized.
For example, a validly authenticated autonomous process may attempt a
payment, file export, network transmission, or device operation
outside its permitted task scope.
CW-1 separates authenticated origin from finality authorization.
CW-1.2.3 — Conventional Sandboxing Does Not Necessarily Bind Each
Effect
A sandbox may restrict access to files, networks, processes, or
devices.
Such isolation is useful and may be an important implementation
component.
However, permission to access an interface does not necessarily
establish that every operation through the interface is specifically
authorized.
CW-1 may use a sandbox while additionally requiring operation-
specific protected evidence and sink-side authorization.
CW-1.2.4 — Conventional Approval May Be Temporally Detached
An approval may concern a proposed operation at an earlier time.
The actual operation may be executed later under changed resource,
runtime, policy, or destination conditions.
CW-1 may require revalidation at the effectuation boundary or binding
to protected current-state evidence.
CW-1.2.5 — Conventional Tool Gateways May Be Advisory or Incomplete
A tool gateway may inspect application requests.
However, an agent may possess access to another effect-capable
interface.
Das Expires 29 April 2027 [Page 49]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
An enforcement mechanism is non-bypassable only to the extent that
the relevant alternative effectuation routes are controlled.
CW-1 introduces explicit effectuation-path coverage as a technical
requirement where system-wide protection is asserted.
CW-1.2.6 — Conventional Agent Coordination May Lack Protected
Authority
9.2.3.6. Source page 20 of the original specification
A multi-agent orchestrator may assign tasks and request that agents
execute in a particular order.
An instruction to wait, avoid conflicts, or ask permission does not
necessarily prevent another agent from acting through an
independently available credential or tool.
The present architecture may incorporate protected conflict
governance and final sink enforcement.
CW-1.2.7 — Conventional Audit Logging Is Not Prevention
A log may establish that an operation was attempted or completed.
However, an audit entry made after an unauthorized effect does not
prevent the effect.
CW-1 may use protected evidence before release and final sink
verification before effectuation.
Optional post-effect evidence has a distinct function concerning
actual outcome and possible later causal continuation.
CW-1.2.8 — Conventional Remote Acknowledgements May Be Incomplete
A local network send confirmation may establish that a command was
transmitted.
It does not necessarily prove that the remote operation completed.
CW-1 distinguishes dispatch evidence, actual effect evidence, and
verified remote outcome.
CW-1.2.9 — Conventional Credential Possession May Create Broad
Authority
A reusable API credential may permit many operations.
Das Expires 29 April 2027 [Page 50]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
If a compromised agent can directly exercise the credential,
authorization may be broader than the specific approved task.
CW-1 may employ credential brokers, scoped finality capabilities,
protected command authentication, or sink-local authorization to
reduce the mismatch between credential possession and permitted
effect.
CW-1.2.10 — Proposed Objective Technical Problem
An illustrative objective technical problem is:
How to ensure that an operation generated or requested by an
autonomous computational entity cannot produce its governed
consequential effect unless a protected enforcement system verifies
operation-specific authority against the actual pending operation and
current applicable protected state at a technical boundary capable of
withholding the effect, while accommodating heterogeneous execution
interfaces, distributed authority, changing runtime conditions, and
optional specialized verification requirements.
CW-1.3 — COMMON PROTECTED SYSTEM ARCHITECTURE
CW-1.3.1 — Requesting Computational Entity
9.2.3.7. Source page 21 of the original specification
A Requesting Computational Entity, or RCE, may comprise an AI agent,
application, service, workflow orchestrator, autonomous controller,
delegated tool, operating-system process, remote execution system, or
another component capable of proposing or initiating a consequential
operation.
The RCE may perform inference, planning, task decomposition, data
processing, and operation preparation.
It does not automatically acquire final execution authority from
those functions.
CW-1.3.2 — Candidate Act Construction Component
The Candidate Act Construction Component identifies a proposed
consequential operation and constructs a machine-verifiable
representation.
A Candidate Act Descriptor may bind the actual action class,
resource, destination, requesting principal, permitted effect, parent
task, current scope, and relevant authority context.
Das Expires 29 April 2027 [Page 51]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The component may be located within a protected dispatcher,
application gateway, operating system, secure processor, or service
infrastructure.
CW-1.3.3 — Non-Effective Holding Mechanism
A Non-Effective Holding Mechanism maintains the proposed operation
before its governed consequence becomes effective.
The hold may be implemented through a protected command queue,
disabled network transmission, sealed operation buffer, uncommitted
storage transaction, blocked actuator command, withheld credential
release, or another actual enforcement structure.
A simulated hold that does not prevent effectuation through the
relevant controlled path does not satisfy the required property.
CW-1.3.4 — Protected Enforcement Domain
A Protected Enforcement Domain, or PED, evaluates evidence and
maintains protected authority state.
It may be realized through a secure processor, isolated execution
environment, hardware security component, protected operating-system
service, secure firmware, or remote protected authority.
The PED may maintain cryptographic keys, protected counters,
revocation state, permitted operation scopes, evidence commitments,
current policy versions, and capability-consumption state.
CW-1.3.5 — Extended Verification Module Interface
An Extended Verification Module Interface, or EVMI, permits
specialized verification functions to evaluate relevant aspects of a
Candidate Act.
The modules may verify semantic identity, resource constraints,
privacy exposure, cross-agent conflicts, runtime integrity, actual
outcome evidence, or other mandatory technical predicates.
9.2.3.8. Source page 22 of the original specification
The EVMI may be an internal protected function call, an authenticated
service interface, secure monitor operation, or distributed
validation protocol.
CW-1.3.6 — Protected Evidence Source
Das Expires 29 April 2027 [Page 52]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A Protected Evidence Source supplies information used to establish
authorization or actual operation correspondence.
Evidence may originate from protected application state, a trusted
controller, authenticated remote service, protected hardware
register, secure sensor, or another qualified technical source.
The trustworthiness of a source depends upon its actual observation
or control capabilities.
CW-1.3.7 — Protected Authority Preparation Component
A protected authority component constructs, derives, signs,
activates, or otherwise prepares the execution-enabling material
required for the specific authorized act.
The resulting authority may be represented as an Execution Handle,
App-Scoped Fractional Capability, protected command authorization,
scoped cryptographic capability, or equivalent finality enablement.
CW-1.3.8 — Finality Gate
A Finality Gate coordinates applicable authorization predicates and
determines whether finality authority may become usable.
The gate may be integrated with the PED or Finality Sink.
The gate is not assumed to provide complete protection unless the
actual effectuation boundary enforces its required decision.
CW-1.3.9 — Finality Sink
A Finality Sink, or FS, is the technical component or boundary at
which the governed operation can be permitted or refused before its
specified consequence occurs.
A sink may comprise a network egress controller, storage commit
controller, payment dispatcher, protected application-function
dispatcher, sensor-release interface, secure display controller,
hardware actuator interface, or another relevant effectuation
component.
The sink obtains or reconstructs the actual pending operation and
verifies the required protected authority before allowing it.
CW-1.3.10 — Protected State and Evidence Store
Das Expires 29 April 2027 [Page 53]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A Protected State and Evidence Store maintains relevant
authorization, validation, attempt, consumption, revocation,
continuation, and recovery state.
It may be local, replicated, or distributed.
Its consistency mechanism is selected according to the technical
guarantees required.
9.2.3.9. Source page 23 of the original specification
CW-1.3.11 — Protected Effect Observation Component
An optional Protected Effect Observation Component, or PEOC, obtains
evidence concerning an earlier actual consequential effect.
The component does not presume that sending a command proves
completion of the requested remote or physical result.
CW-1.3.12 — Interim Effectuation Validator
An optional Interim Effectuation Validator may provide independent
pre-effect operation validation or receipt-gated inter-phase
continuation.
Where a CW-2 receipt-gated phase is mandatory, the IEV has a
cryptographically verifiable identity, and its accepted prior-effect
receipt becomes a necessary causal factor for successor effectuation.
CW-1.3.13 — Effectuation-Path Coverage Controller
An optional Effectuation-Path Coverage Controller maintains evidence
concerning the interfaces through which a particular effect class may
be produced.
It may identify authorized gateways, system interfaces, hardware
access routes, privileged services, credential-release paths, and
application dispatchers.
Where required, the controller detects coverage changes and
invalidates assumptions that a protected sink remains mandatory.
CW-1.3.14 — Protected Authority and Validator Identity Registry
A protected registry may identify trusted PED instances, valid
Finality Sinks, authorized validation modules, permitted validator
identities, cryptographic credentials, and current revocation state.
Das Expires 29 April 2027 [Page 54]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The registry may support local and cross-domain trust establishment.
CW-1.4 — TRUST MODEL AND PROTECTED ASSUMPTIONS
The system distinguishes computational entities that request
operations from components authorized to permit the corresponding
consequences.
A requesting agent may be untrusted with respect to finality
authority.
An application may supply useful operation context without possessing
authority to mint protected execution capabilities.
An operating-system service may transport authority objects without
being entitled to expand their permitted scope.
A remote service may supply authenticated observations without being
treated as trustworthy for outcomes outside its technical visibility.
A cryptographically authenticated message proves provenance under the
applicable key assumptions, not the truth of every statement in that
message.
9.2.3.10. Source page 24 of the original specification
CW-1.4.1 — Protected Authority Boundary
The PED and applicable Finality Sink must maintain the authority
material and state necessary to prevent unauthorized release under
the claimed threat model.
CW-1.4.2 — Software-Only Trust Model
A protected software service may provide useful isolation from
ordinary agent processes.
However, a software-only implementation is not presumed secure
against a fully compromised privileged operating system unless
additional appropriate protection exists.
CW-1.4.3 — Hardware-Backed Trust Model
A hardware-backed implementation may use protected processors, secure
elements, hardware-controlled effectuation, isolated command buffers,
or cryptographic identity modules.
Das Expires 29 April 2027 [Page 55]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Hardware isolation does not eliminate the need to verify correct
policy, command binding, and actual effect coverage.
CW-1.4.4 — Remote Trust Model
A remote protected authority may communicate with a local Finality
Sink through authenticated messages.
The local sink independently verifies the authorization rather than
treating remote approval as unrestricted local execution permission.
CW-1.4.5 — Distributed Trust Model
Several domains may cooperate in validation and effectuation.
Each participating domain has an authenticated identity, permitted
role, and defined protected state responsibilities.
An implementation may employ consensus, quorum validation, fencing,
or other distributed coordination when necessary.
Such mechanisms are not automatically required for every local
single-sink operation.
CW-1.4.6 — Explicit Boundary Qualification
A claimed non-bypassability property applies to the effectuation
paths actually controlled by the implementation.
An architecture that does not mediate an alternative route capable of
producing the same governed consequence cannot automatically claim
protection against that route.
CW-1.5 — COMMON MACHINE-VERIFIABLE RECORDS
CW-1.5.1 — Candidate Act Descriptor
9.2.3.11. Source page 25 of the original specification
A Candidate Act Descriptor may contain the requesting entity
identity, original task reference, action class, permitted resource,
destination, operation arguments, designated Finality Sink, current
authority scope, protected context, and applicable module references.
The descriptor may also include actual observed resource state,
operation-semantics identity, permitted transformations, and
protected freshness values.
Das Expires 29 April 2027 [Page 56]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The specific fields are selected according to the operation.
CW-1.5.2 — Protected Validation Evidence Record
A Protected Validation Evidence Record, or PVER, binds a Candidate
Act to applicable protected validation results.
The record may comprise cryptographically authenticated data,
protected local state, a signed receipt, or an equivalent integrity-
protected representation.
It does not require a blockchain or ledger.
CW-1.5.3 — Extended Verification Evidence
Extended Verification Evidence, or EVE, represents a specialized
verification module's authenticated result.
The result may bind the Candidate Act, module identity, evaluated
predicate, evidence source, current state, and applicable
effectuation constraint.
CW-1.5.4 — Scoped Finality Authority
Scoped Finality Authority, or SFA, means an execution-enabling
authority object, protected state, or capability constrained to the
corresponding permitted effect.
It may bind operation parameters, resource, destination, designated
sink, validity period, protected evidence, and consumption
conditions.
An SFA need not be a freely transferable bearer token.
CW-1.5.5 — Protected Effect Receipt
A Protected Effect Receipt records or represents authenticated
evidence concerning an earlier actual effectuation attempt or
outcome.
Its validity depends upon the observation source and supported effect
predicate.
Where CW-2 receipt-gated continuation is required, the receipt
accepted by an authorized IEV becomes the necessary causal enabling
factor for the next protected phase.
CW-1.5.6 — Continuation Authority Record
Das Expires 29 April 2027 [Page 57]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A Continuation Authority Record represents successor-specific
authority associated with accepted prior-effect evidence or other
applicable continuation predicates.
9.2.3.12. Source page 26 of the original specification
Where CW-2 applies, a CAR may directly incorporate or be constituted
through the required validator-accepted receipt.
CW-1.5.7 — Protected Consumption Record
A Protected Consumption Record identifies whether a bounded
authorization has already been reserved, consumed, or invalidated.
It may include a protected counter, unique operation reference, state
version, or equivalent anti-replay mechanism.
CW-1.5.8 — Protected Effectuation Coverage Record
An optional Protected Effectuation Coverage Record identifies which
enforcement paths are expected to control a particular effect class.
It may record authorized interfaces, relevant security policy,
versioned controller identities, and measured coverage state.
CW-1.5.9 — Protected Semantic Correspondence Record
A Protected Semantic Correspondence Record may bind a user-visible or
application-visible referent to the actual operation target.
It may carry evidence concerning object identity, version,
presentation state, destination, or other applicable context.
CW-1.5.10 — Protected Authority Lineage Record
An optional Protected Authority Lineage Record may represent the
relationship among original authority, delegated authority, successor
operations, and applicable resource or effect constraints.
CW-1.5.11 — Deterministic Encoding and Canonicalization
Protected records may employ deterministic binary encoding, canonical
structured data, typed fields, or another unambiguous representation.
The protocol must specify how equivalent or distinct operations are
represented.
Das Expires 29 April 2027 [Page 58]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Differences in string normalization, resource aliases, numerical
representation, schema version, nested object ordering, and encoded
payload interpretation may affect actual-operation correspondence.
A cryptographic digest is only as meaningful as the canonical
representation from which it is derived.
CW-1.6 — DETAILED COMMON EXECUTION WORKFLOW
PHASE CW-1.6.0 — PROTECTED AUTHORITY INITIALIZATION
9.2.3.13. Source page 27 of the original specification
The system establishes protected trust anchors, authority state,
enrolled principals, valid sinks, current policy versions,
cryptographic verification material, applicable module identities,
and revocation state.
Where needed, the system also establishes validator identities and
effectuation-path coverage information.
Initialization may occur during device enrollment, protected service
startup, session initiation, application registration, or another
suitable event.
An earlier enrollment does not automatically authorize all later
consequential acts.
PHASE CW-1.6.1 — REQUEST RECEIPT AND ORIGIN AUTHENTICATION
A requesting computational entity submits a proposed operation.
The receiving component identifies the apparent requester and obtains
available authentication evidence.
The system distinguishes authenticated principal identity from a
model-generated declaration of authority.
An unverified claim that an agent is permitted to act is
insufficient.
PHASE CW-1.6.2 — CANDIDATE ACT CONSTRUCTION
The operation is converted into a Candidate Act Descriptor.
The descriptor identifies the consequential operation sufficiently to
distinguish it from materially different alternatives.
Das Expires 29 April 2027 [Page 59]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Where required, the descriptor binds the actual resource, recipient,
destination, payment amount, physical target, application function,
or other effect-specific parameters.
PHASE CW-1.6.3 — NON-EFFECTIVE HOLD
The system establishes an enforceable hold.
A network transmission may be withheld.
A storage transaction may remain uncommitted.
An actuator command may remain disabled.
A credential may remain inaccessible.
A protected operation may remain in a sealed command buffer.
The hold must be capable of preventing the governed consequence
through the designated protected path.
PHASE CW-1.6.4 — EVIDENCE COLLECTION
9.2.3.14. Source page 28 of the original specification
The system obtains relevant identity, authority, context, operation,
resource, destination, runtime, and policy evidence.
The evidence is classified by source and assurance.
An unsupported assertion is not silently promoted into protected
proof.
PHASE CW-1.6.5 — REQUIRED VERIFICATION MODULE SELECTION
The protected system determines which specialized verification
predicates apply.
Module selection may depend upon action class, resource class,
privacy sensitivity, cross-agent activity, semantic ambiguity,
physical actuation, runtime conditions, or prior-effect dependency.
An untrusted agent may propose a task classification but cannot
suppress a mandatory module merely by omitting its identifier.
PHASE CW-1.6.6 — BASELINE AUTHORIZATION
Das Expires 29 April 2027 [Page 60]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The PED verifies applicable requesting-principal authority, action
scope, resource permission, destination, current revocation state,
and policy requirements.
Failure of a mandatory predicate prevents release.
PHASE CW-1.6.7 — SPECIALIZED VERIFICATION
Selected modules verify additional predicates.
For example, a conflict module may verify compatibility with another
authorized operation.
A semantic module may verify the actual resource corresponding to a
user's selected object.
A privacy module may verify cumulative disclosure constraints.
A physical-scene module may verify the intended actuator target.
An optional outcome module may verify an earlier actual effect.
PHASE CW-1.6.8 — COMPOSITE PROTECTED DECISION
The PED or an authorized coordinator combines the applicable results.
A representative abstract condition is:
BASELINE_AUTHORITY_VALID
AND REQUIRED_MODULES_VALID
AND CURRENT_PROTECTED_STATE_VALID
AND REQUIRED_ENFORCEMENT_PATH_VALID The composition may be
implemented through one controller or multiple authenticated
protected domains.
9.2.3.15. Source page 29 of the original specification
Mandatory denials are not overridden by omission of the relevant
module.
PHASE CW-1.6.9 — PROTECTED STATE RESERVATION
Where required, the system atomically reserves operation-specific
state.
Das Expires 29 April 2027 [Page 61]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
It may allocate a consumption reference, reserve a resource,
establish a conflict fence, bind a semantic target, or record a
current authority epoch.
PHASE CW-1.6.10 — VALIDATION EVIDENCE COMMITMENT
The PED commits applicable protected validation evidence.
Where a particular implementation requires an authenticated receipt
before authority release, the receipt commitment must succeed.
An untrusted process log is not a substitute for required protected
evidence.
PHASE CW-1.6.11 — SCOPED AUTHORITY FORMATION
The protected system creates, activates, derives, signs, or otherwise
establishes the required finality authority.
The authority is bound to the specific permitted act or bounded class
of acts.
It may be represented as a sealed capability, execution handle,
protected command authorization, or sink-local enablement state.
PHASE CW-1.6.12 — AUTHORITY PRESENTATION
The resulting authority is supplied or made available to the
designated Finality Sink.
An untrusted process may transport a reference without obtaining
authority to alter it.
PHASE CW-1.6.13 — ACTUAL PENDING-OPERATION RECONSTRUCTION
The Finality Sink obtains or reconstructs the actual operation
presented for effectuation.
Where technically possible, the sink obtains relevant parameters from
the controlled dispatch or effectuation interface rather than relying
exclusively upon the original agent-declared intent.
The sink may verify the actual target, destination, resource version,
command parameters, operation semantics, and relevant current state.
PHASE CW-1.6.14 — SINK-TIME REVALIDATION
Das Expires 29 April 2027 [Page 62]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The Finality Sink compares the actual operation with the protected
authority.
Where a material parameter or applicable protected state has changed,
the sink may refuse effectuation or require renewed authorization.
The verification may include current revocation, ownership, resource
reservation, semantic correspondence, and mandatory module-specific
predicates.
9.2.3.16. Source page 30 of the original specification
PHASE CW-1.6.15 — PROTECTED CONSUMPTION
Where the operation requires single-use authority, the sink
atomically reserves or consumes the applicable authorization
reference.
The state transition prevents unauthorized duplicate effects under
the selected enforcement assumptions.
PHASE CW-1.6.16 — CONTROLLED EFFECTUATION
The sink permits the specified actual consequence.
The effect may comprise a network transmission, payment submission,
storage commit, application-function dispatch, physical command,
sensor disclosure, protected data release, or other consequential
operation.
PHASE CW-1.6.17 — EFFECT ATTEMPT RECORD
The system records or commits appropriate information concerning the
effectuation attempt.
The attempt record distinguishes authority consumption from verified
external completion.
PHASE CW-1.6.18 — ACTUAL OUTCOME CLASSIFICATION
Where required, a qualified observation component evaluates the
actual result.
The outcome may be confirmed successful, partially completed,
mismatched, confirmed absent, or unknown.
A timeout is not automatically treated as proof that the effect did
not occur.
Das Expires 29 April 2027 [Page 63]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
PHASE CW-1.6.19 — OPTIONAL CAUSAL CONTINUATION
Where CW-2 receipt-gated continuation applies, the accepted actual-
effect receipt is authenticated by a required IEV identity and
becomes a necessary enabling factor for the successor phase.
The successor Finality Sink independently verifies the receipt-
dependent condition before releasing the next consequential act.
Where CW-2 is not selected, the operation may terminate or proceed
according to another valid authorization protocol.
PHASE CW-1.6.20 — COMPLETION, RECOVERY, OR TERMINATION
The system records the appropriate completed, withheld, unresolved,
or recovery-required state.
A subsequent compensating operation requires its own applicable
authorization where it constitutes a new consequential act.
CW-1.7 — COMMON PROTECTED STATE MACHINE
9.2.3.17. Source page 31 of the original specification
The system may employ states representing proposed, held, prepared,
validated, authorized, sink-verified, effectuation-attempted,
outcome-confirmed, outcome-unknown, recovery-pending, and terminated
conditions.
The precise state names are non-limiting.
The important requirement is that authority-sensitive transitions
occur through protected procedures.
A transition from prepared to effectuation-ready requires
satisfaction of the applicable current authority.
A transition from effectuation-attempted to confirmed-completion
requires suitable actual-outcome evidence where that evidence is
mandatory.
A transition from an earlier phase to a receipt-gated successor
requires the appropriate validated receipt-dependent condition.
A system may combine several logical states within one protected
controller provided it preserves the necessary protected transition
semantics.
Das Expires 29 April 2027 [Page 64]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
CW-1.7.1 — Anti-Rollback State
Protected state may include monotonic counters, authority epochs,
secure storage, fencing references, or other anti-rollback
mechanisms.
CW-1.7.2 — Crash-Recoverable State
Consequential attempts whose outcomes may become uncertain may be
associated with durable protected attempt references.
CW-1.7.3 — Distributed State
Where state is distributed, the implementation identifies the
authoritative owner or coordination protocol.
A stale replica cannot automatically authorize an irreversible
effect.
CW-1.7.4 — Termination After Partial Consequence
A workflow may terminate while a real external effect remains in
existence.
The system does not relabel an already completed external consequence
as non-effective.
CW-1.8 — GENERALIZED REFERENCE ALGORITHM
The following pseudocode is a non-limiting architectural
implementation.
FUNCTION PROTECTED_EXECUTION_FINALITY( request, requester_context,
protected_policy,
9.2.3.18. Source page 32 of the original specification
designated_sink ):
state = PED.LOAD_PROTECTED_STATE()
REQUIRE PED.VERIFY_STATE(state)
cad = CONSTRUCT_CANDIDATE_ACT( request, requester_context,
designated_sink, state )
REQUIRE VERIFY_CANDIDATE_ACT(cad)
Das Expires 29 April 2027 [Page 65]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
hold = ESTABLISH_NON_EFFECTIVE_HOLD( request, cad )
REQUIRE VERIFY_HOLD(hold)
evidence = COLLECT_RELEVANT_EVIDENCE( cad, requester_context, state )
REQUIRE VERIFY_REQUIRED_EVIDENCE_SOURCES( evidence )
required_modules = PED.RESOLVE_REQUIRED_MODULES( cad,
protected_policy, state )
REQUIRE VERIFY_MANDATORY_MODULE_COMPLETENESS( required_modules )
baseline = PED.VALIDATE_BASELINE( cad, evidence, protected_policy )
IF baseline != PASS: RETURN DENY_BEFORE_EFFECT
9.2.3.19. Source page 33 of the original specification
FOR EACH module IN required_modules:
result = INVOKE_PROTECTED_MODULE( module, cad, evidence, state )
IF result != PASS: RETURN DENY_OR_DEFER
REQUIRE VERIFY_COVERED_EFFECTUATION_PATH( cad, designated_sink )
authority = PED.ATOMIC_PREPARE_AUTHORITY( cad, evidence, state )
IF authority IS INVALID: RETURN DENY_BEFORE_EFFECT
actual_operation = designated_sink.RECONSTRUCT_PENDING_OPERATION(
hold )
REQUIRE designated_sink.VERIFY_ACTUAL_OPERATION( actual_operation,
cad )
REQUIRE designated_sink.VERIFY_SCOPED_AUTHORITY( authority,
actual_operation )
REQUIRE designated_sink.VERIFY_CURRENT_STATE()
consumption = designated_sink.ATOMIC_CONSUME( authority,
actual_operation )
IF consumption != SUCCESS: RETURN DENY_BEFORE_EFFECT
Das Expires 29 April 2027 [Page 66]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.2.3.20. Source page 34 of the original specification
attempt = designated_sink.EFFECTUATE( actual_operation, consumption )
outcome = CLASSIFY_SUPPORTED_OUTCOME( attempt )
PED.COMMIT_OUTCOME_STATE( cad, attempt, outcome )
IF REQUIRES_CAUSAL_RECEIPT_CONTINUATION( cad ):
receipt = OBTAIN_QUALIFIED_EFFECT_RECEIPT( cad, attempt, outcome )
vaer = AUTHORIZED_IEV_ACCEPT_RECEIPT( receipt,
current_protected_state )
IF vaer IS INVALID: RETURN WITHHOLD_SUCCESSOR_EFFECT
RETURN PROVIDE_CAUSAL_RECEIPT_TO_NEXT_SINK( vaer, permitted_successor
)
RETURN EFFECTUATION_RESULT( attempt, outcome ) The pseudocode does
not require synchronous execution of every non-dependent step.
Parallel validation may be permitted where protected state and
dependency conditions remain valid.
However, independent authority verification and protected state
consumption must preserve the technical invariants applicable to the
operation.
CW-1.9 — COMMON EXTENDED VERIFICATION MODULES
9.2.3.21. Source page 35 of the original specification
CW-1.9.1 — Module A: Context, Semantic, and Identity Verification
Module A may verify correspondence between user-observed objects and
actual effectuation targets.
It may verify resource aliases, selected document versions, physical
targets, semantic referents, trusted interface state, application-
object identity, and source provenance.
A proposed candidate inventive combination may bind independently
observed semantic or object identity to an operation-specific
protected authorization and require the Finality Sink to verify the
actual target before effectuation.
Das Expires 29 April 2027 [Page 67]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The module may be particularly relevant to computer-use agents,
multimodal assistants, cross-application automation, and physical-
scene interactions.
CW-1.9.2 — Module B: Protected Authority, Privacy, and Resource
Governance
Module B may evaluate privacy-exposure limits, protected resource-
allocation constraints, multi-principal authority, disclosure
permissions, sensor restrictions, and cumulative consequence budgets.
A potentially distinguishing arrangement may require the actual
Finality Sink to verify current cumulative protected state rather
than rely solely upon independently permitted individual operations.
CW-1.9.3 — Module C: Multi-Agent and Distributed Authority
Module C may evaluate cross-agent effect conflicts, protected
resource reservations, delegation scope, authority attenuation,
device ownership, and multi-domain operation dependencies.
A protected reservation may become a mandatory condition at the
actual Finality Sink.
The module may incorporate the specialized mechanisms of Embodiment
1.
CW-1.9.4 — Module D: Execution Integrity and Environmental
Verification
Module D may verify action-contract integrity, operation-semantics
compatibility, execution-path coverage, runtime conditions, software-
update state, hardware constraints, and protected scheduling
requirements.
It may require revalidation following relevant environment changes.
CW-1.9.5 — Module E: Actual Effect, Causal Continuation, and Recovery
Module E may evaluate actual-effect evidence, authenticated receipts,
validator identity, successor phase requirements, and uncertainty-
preserving recovery.
Where CW-2 receipt-gated continuation is mandatory, the IEV's
accepted real-effect receipt becomes an indispensable factor in the
authority required by the next Finality Sink.
CW-1.9.6 — Module Independence
Das Expires 29 April 2027 [Page 68]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A module is not required to perform unrelated technical functions.
9.2.3.22. Source page 36 of the original specification
A semantic verification result does not establish financial
settlement.
A resource-reservation result does not establish actual external
effect completion.
A valid actual-effect receipt does not automatically grant
unrestricted future authority.
CW-1.10 — COMPOSITION OF PROTECTED MODULE DECISIONS
The protected coordinator identifies mandatory modules according to
the Candidate Act and current protected policy.
Each module provides a decision bound to the corresponding operation
and applicable state.
The coordinator verifies the module identity and result.
Where a module requires sink-time enforcement, its result includes or
references the mandatory condition.
A module may restrict authority, withhold an effect, or require
renewed validation.
It may not unilaterally expand original task authority unless the
appropriate protected reauthorization procedure permits that
expansion.
CW-1.10.1 — Mandatory-Module Completeness
A requesting agent cannot remove a mandatory verification requirement
by omitting it from the request.
CW-1.10.2 — Operation-Specific Binding
A verification result for one Candidate Act is not automatically
valid for another.
CW-1.10.3 — Freshness
An old validation result may become invalid after a relevant policy,
resource, authority, or runtime change.
Das Expires 29 April 2027 [Page 69]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
CW-1.10.4 — Protected State Continuity
Required module state is updated using appropriate concurrency and
rollback protection.
CW-1.10.5 — Denial Precedence
A mandatory denial condition cannot be ignored merely because another
module returned permission.
CW-1.10.6 — Causal Continuation Priority
Where receipt-gated causal continuation is mandatory, a general
authorization approval does not substitute for the required
validator-accepted predecessor receipt.
CW-1.10.7 — Distributed Module Verification
9.2.3.23. Source page 37 of the original specification
Modules may reside in independent domains.
The coordinator and Finality Sink verify the authenticated results
according to the applicable trust configuration.
CW-1.11 — PROTECTED EXECUTION INVARIANTS
Invariant I — Computation/Authority Separation. Generating a command
does not constitute authority to effectuate it.
Invariant II — Non-Effective Holding. An operation requiring
protected finality remains non-effective until applicable release
conditions are satisfied.
Invariant III — Actual-Operation Correspondence. Final authority is
verified against the operation actually pending at the effectuation
boundary.
Invariant IV — Scoped Authority. Finality authorization cannot be
expanded by copying, forwarding, re-encoding, or transporting an
authority reference.
Invariant V — Non-Bypassable Effectuation. Every effectuation route
covered by the claimed protection enforces the applicable finality
condition.
Das Expires 29 April 2027 [Page 70]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Invariant VI — Protected Consumption. Single-use authority cannot be
exercised again through unauthorized replay or stale-state
restoration.
Invariant VII — Module Constraint Preservation. Mandatory technical
predicates remain enforced at the required boundary.
Invariant VIII — Current-State Validation. Applicable protected
conditions are current when they must remain valid until
effectuation.
Invariant IX — Trusted Evidence Classification. Unsupported
statements are not silently treated as independently verified facts.
Invariant X — Effect/Receipt Distinction. A permission or dispatch
record does not automatically prove that the external consequence
occurred.
Invariant XI — Receipt-Gated Continuation. Where CW-2 requires a
validated actual-effect receipt, the next effect cannot proceed
through the protected sink independently of that receipt-derived
condition.
Invariant XII — Validator Identity. An IEV receipt is accepted only
when the relevant authorized cryptographic validator identity can be
verified.
Invariant XIII — No Authority Inflation. Delegated or derived
authority does not exceed its protected source scope.
Invariant XIV — Cross-Agent Compatibility. Where conflict governance
applies, an effectuation must satisfy current protected conflict
constraints.
Invariant XV — Unknown-Outcome Honesty. A missing acknowledgement is
not automatically classified as confirmed absence of effect.
9.2.3.24. Source page 38 of the original specification
Invariant XVI — Recovery Separation. Corrective consequential acts
are separately governed.
Invariant XVII — Protected Ownership. Where execution authority is
exclusive, superseded or stale owners cannot validly reuse that
authority.
Das Expires 29 April 2027 [Page 71]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Invariant XVIII — Semantic Binding. Where user-visible or model-
referenced targets are security-relevant, the actual effect target
must satisfy the protected correspondence predicate.
Invariant XIX — Identity/Role Distinction. A component may be
authentic but unauthorized for the requested function.
Invariant XX — Enforcement Coverage Qualification. Security claims
are bounded by the actual protected effectuation paths and threat
model.
CW-1.12 — DETAILED THREAT MODELS
CW-1.12.1 — Prompt-Injection-Induced Unauthorized Operation
An autonomous agent processes untrusted instructions embedded within
a document, web page, message, or external tool response.
The malicious content attempts to redirect the agent toward an
unauthorized operation.
The protected architecture prevents the model-generated command from
becoming effectually authoritative solely because the agent produced
it.
The Candidate Act must satisfy the applicable protected authorization
and actual sink verification.
CW-1.12.2 — Model Hallucination
An agent fabricates a resource identity, recipient, transaction
state, or operation result.
The protected system evaluates the applicable evidence independently.
A model-generated assertion does not satisfy a predicate requiring
authenticated external state.
CW-1.12.3 — Compromised Tool Interface
An intermediary tool modifies operation arguments after approval.
The Finality Sink reconstructs the actual command and rejects a
material mismatch.
CW-1.12.4 — Stolen Reusable Credential
An attacker obtains a reusable API credential.
Das Expires 29 April 2027 [Page 72]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Where the protected effectuation path requires a separate operation-
bound finality condition, possession of that credential alone is
insufficient for the protected operation.
The specific protection depends upon whether the destination or
mediated path actually requires the additional condition.
CW-1.12.5 — Alternative API Bypass
9.2.3.25. Source page 39 of the original specification
An agent invokes a different application interface to produce an
effect.
The implementation must route the claimed governed effect through an
equivalent protected Finality Sink.
If an uncovered interface remains available, the claimed protection
is incomplete for that effect.
CW-1.12.6 — Direct Network Bypass
A malicious process attempts direct network transmission around an
application-layer gateway.
A deployment claiming network-level non-bypassability may require
operating-system mediation, hardware egress control, network
isolation, or destination-side authorization.
CW-1.12.7 — Direct Hardware Bypass
A process attempts to address an actuator, storage device, radio
interface, or peripheral through an alternate hardware interface.
The applicable hardware controller must enforce the protected release
condition where system-wide physical effect control is asserted.
CW-1.12.8 — Time-of-Check/Time-of-Use Substitution
An authorized operation is changed after validation.
The sink verifies the actual pending operation and applicable current
state.
CW-1.12.9 — Stale Approval
An agent attempts to execute under a previously valid authorization
after a relevant revocation, policy update, or resource change.
Das Expires 29 April 2027 [Page 73]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The sink verifies current applicable validity conditions.
CW-1.12.10 — Capability Replay
An attacker copies a scoped authority and attempts to repeat the
effect.
Protected nonce or consumption state prevents unauthorized duplicate
exercise.
CW-1.12.11 — Cross-Sink Capability Reuse
An authority intended for one sink is presented to another.
The receiving sink rejects an authority whose required audience or
sink binding does not match.
CW-1.12.12 — Validator Impersonation
An attacker copies a validator identifier and fabricates an approval.
Where an IEV is mandatory, the sink verifies the authorized
validator's cryptographic identity and receipt.
9.2.3.26. Source page 40 of the original specification
CW-1.12.13 — Validator Replacement
An attacker substitutes a permissive IEV.
The sink rejects receipts lacking current authorized validator
enrollment.
CW-1.12.14 — Forged Actual Outcome
An agent claims that an earlier remote or physical effect succeeded.
The protected outcome observer requires evidence capable of
supporting the required actual-effect predicate.
CW-1.12.15 — Missing Remote Acknowledgement
A remote operation may have succeeded even though the originating
system received no response.
The system preserves an unknown-outcome condition and avoids
automatic unsafe repetition.
Das Expires 29 April 2027 [Page 74]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
CW-1.12.16 — State Rollback
An attacker restores a software snapshot containing old authority.
Protected counters, epochs, or authoritative external state prevent
unauthorized reuse where implemented.
CW-1.12.17 — Cross-Agent Conflict
Two agents independently receive valid authorization but attempt
mutually incompatible effects.
A protected conflict module may establish reservations that are
independently enforced at the respective sinks.
CW-1.12.18 — Delegation Expansion
An agent delegates a narrow task while a downstream service attempts
a broader operation.
The protected system verifies the delegation lineage and prevents
unauthorized scope expansion.
CW-1.12.19 — Semantic Target Substitution
An application changes the resource corresponding to a visible
selection.
The relevant semantic module verifies the relationship between the
authorized referent and actual selected target.
CW-1.12.20 — Runtime Update Drift
A software update changes the actual semantics of an operation.
Where action-contract integrity is required, the protected system
verifies the current operation semantics and may require
reauthorization.
9.2.3.27. Source page 41 of the original specification
CW-1.12.21 — Tool Schema Manipulation
An untrusted tool provider changes the interpretation of an API
parameter.
The protected system may bind authority to a specific verified action
contract or semantic schema version.
Das Expires 29 April 2027 [Page 75]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
CW-1.12.22 — Credential-Broker Confusion
A protected credential broker may be asked to release credentials for
a different resource or destination from the originally authorized
operation.
The broker verifies operation binding and scope before release.
CW-1.12.23 — Privacy Leakage Across Multiple Operations
An agent may perform several individually permitted disclosures that
collectively violate a protected privacy constraint.
A cumulative privacy module may track relevant protected exposure
state.
CW-1.12.24 — Device Authority Split-Brain
Two devices attempt to exercise the same exclusive unfinished
authority.
Protected ownership epochs or fencing prevent stale ownership from
authorizing duplicate effects.
CW-1.12.25 — Physical Target Drift
A physical object moves or is replaced between authorization and
actuation.
The protected system may require current target-identity evidence
before movement.
CW-1.12.26 — Denial-of-Service Against Validators
An attacker floods a required validation component with requests.
The protected architecture may employ bounded work, rate limits,
priority rules, reservation expiry, and fail-closed behavior for
mandatory predicates.
A validation timeout is not treated as successful authorization.
CW-1.12.27 — Cryptographic Verification Exhaustion
An attacker submits malformed or computationally expensive evidence
intended to exhaust the verifier.
Das Expires 29 April 2027 [Page 76]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The system may enforce input-size limits, bounded parsing, supported
algorithm restrictions, and resource-aware verification scheduling.
CW-1.12.28 — Malicious Evidence Source
A source authenticates false or manipulated data.
9.2.3.28. Source page 42 of the original specification
The system's guarantees depend upon source qualification, independent
observation, and the actual trust model.
Cryptographic authentication alone does not ensure factual
correctness.
CW-1.12.29 — Compromised Privileged Operating System
An attacker controls privileged software.
A software-only gate under the attacker's full control may be
bypassed.
Claims requiring resistance to such compromise must rely upon
appropriately independent protected components, hardware, or
destination-side enforcement.
CW-1.12.30 — Compromised Firmware or Hardware Controller
A malicious effectuation controller ignores required authorization.
The architecture may require independently protected hardware,
measured firmware, external control, redundancy, or equivalent
mechanisms under the intended threat model.
No single protection is assumed to resist compromise of its complete
trusted computing base.
CW-1.12.31 — Distributed Network Partition
Protected domains become disconnected.
The system may continue unrelated operations whose authority remains
locally sufficient.
Operations requiring unavailable distributed agreement or current
remote state are withheld.
CW-1.12.32 — Long-Lived Offline Authority
Das Expires 29 April 2027 [Page 77]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A disconnected device attempts to use previously provisioned
authority.
A protected implementation may enforce a bounded offline scope,
monotonic counters, expiry, or preallocated limited execution budget.
It cannot simultaneously claim unrestricted offline availability and
immediate global revocation without an appropriate supporting
mechanism.
CW-1.12.33 — Unknown Future Effectuation Interface
A software or hardware update introduces a new way to produce the
governed effect.
An optional coverage-attestation mechanism may detect the relevant
interface change and require new enforcement configuration before
protected authorization resumes.
CW-1.13 — FAILURE HANDLING AND RECOVERY
CW-1.13.1 — Failure Before Authorization
9.2.3.29. Source page 43 of the original specification
The Candidate Act remains non-effective.
CW-1.13.2 — Failure During Validation
A mandatory failed or unavailable verifier prevents corresponding
authorization.
CW-1.13.3 — Failure After Authority Preparation
Protected authority state is recovered or invalidated according to
the applicable consumption and freshness rules.
CW-1.13.4 — Failure After Sink Consumption
A consumed authority is not automatically restored merely because
effectuation acknowledgement is absent.
CW-1.13.5 — Partial External Effect
The system records the supported partial result and governs remaining
operations separately.
CW-1.13.6 — Unknown External Effect
Das Expires 29 April 2027 [Page 78]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The system preserves an unresolved attempt and prevents unsafe
dependent continuation or retry.
CW-1.13.7 — Revocation During Execution
Revocation may prevent future effects that have not crossed the
governed boundary.
A completed effect is not retroactively erased.
CW-1.13.8 — Recovery Authorization
A corrective effect may be represented as a new Candidate Act with
its own finality authority.
CW-1.13.9 — Validator Failure
Where CW-2 or another mandatory validator is required, failure does
not automatically authorize bypass.
CW-1.13.10 — Protected State Corruption
An operation is withheld where the mandatory protected state cannot
be validated or safely reconstructed.
CW-1.14 — CROSS-DOMAIN AND HETEROGENEOUS IMPLEMENTATIONS
CW-1 may operate across mobile devices, desktop systems, enterprise
endpoints, cloud services, edge computers, embedded controllers,
vehicles, robots, secure communication infrastructure, and
distributed application systems.
An agent may request an operation in one domain while protected
authorization occurs in another.
9.2.3.30. Source page 44 of the original specification
The actual Finality Sink may reside in a third domain.
The receiving sink authenticates the applicable evidence and verifies
the actual operation independently.
CW-1.14.1 — Local Device Enforcement
A local protected controller may govern storage, network,
application, or hardware effects.
CW-1.14.2 — Cloud Enforcement
Das Expires 29 April 2027 [Page 79]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A protected cloud gateway may govern service API calls, database
commits, resource provisioning, and credential activation.
CW-1.14.3 — Cross-Provider Agents
Agents operating under different administrative providers may
exchange task requests without transferring unrestricted execution
authority.
Each consequential operation remains subject to applicable local
protected authorization.
CW-1.14.4 — Edge and Embedded Devices
Low-power devices may use compact protected state and hardware-
controlled release conditions.
CW-1.14.5 — Hardware Accelerators
A protected system may mediate effect-capable accelerator interfaces
where they can modify persistent resources, initiate direct memory
access, release network data, or produce another governed
consequence.
CW-1.14.6 — Physical Actuation
An actuator controller may enforce scoped command authority and
relevant current physical-state predicates.
CW-1.14.7 — Delayed Connectivity
A system with intermittent connectivity may employ preauthorized
bounded operations, local protected state, and conservative
reconciliation after reconnection.
CW-1.15 — NON-LIMITING PRESENT-DAY INDUSTRIAL IMPLEMENTATION
CW-1.15.1 — Enterprise AI-Agent Gateway
A presently implementable reference system may comprise an AI agent,
a request interceptor, a protected authorization service, and a
controlled API gateway.
The agent proposes an operation.
The interceptor constructs the Candidate Act.
Das Expires 29 April 2027 [Page 80]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.2.3.31. Source page 45 of the original specification
The protected authorization service evaluates the permitted operation
and current state.
The gateway independently verifies the actual outgoing request.
The gateway rejects a materially substituted destination, resource,
or operation.
This implementation may use existing cryptographic authentication,
protected service isolation, structured authorization, and
transaction-state techniques.
Its distinctive proposed feature must be identified in the actual
operation-bound protected enforcement relationship, not merely in use
of an ordinary API gateway.
CW-1.15.2 — Mobile or Desktop Assistant
A device assistant may request file access, message transmission,
application invocation, network communication, or device
configuration changes.
The device's protected execution system may require an operation-
specific finality authorization before the actual effect.
A protected dispatcher or controller may verify the actual pending
operation.
Where required, device security components may provide protected
state and cryptographic identity.
CW-1.15.3 — Multi-Agent Cloud Workflow
Several agents may generate resource-modification requests.
A conflict module may identify incompatible operations.
A protected state store may establish effect reservations.
Each actual cloud-operation sink verifies current authority and
applicable reservation state.
CW-1.15.4 — Autonomous Financial Workflow
An agent may propose a financial instruction.
Das Expires 29 April 2027 [Page 81]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The protected system binds the intended amount, recipient, account
scope, and designated dispatch controller to the Candidate Act.
The dispatch sink verifies the actual pending instruction.
Actual settlement remains distinct from local dispatch and may
require qualified outcome evidence.
CW-1.15.5 — Industrial Device Controller
An autonomous controller may generate a physical command.
A protected controller verifies the actual target and operating
envelope.
The actuator remains disabled until valid finality conditions pass.
9.2.3.32. Source page 46 of the original specification
CW-1.16 — PHOSITA FEASIBILITY AND REFERENCE PROTOTYPES
CW-1.16.1 — Minimum Software Reference Prototype
A practical minimum prototype may use two separately executing
processes.
The first process simulates an autonomous agent that generates
operation requests.
The second process implements a protected authorization and finality
gateway under a defined software trust model.
The agent does not possess direct access to the simulated
consequential resource.
The gateway constructs or validates Candidate Act descriptors,
verifies permitted operation scope, maintains protected consumption
state, and performs the final effect.
This prototype can demonstrate operation binding, single-use
authority, replay rejection, and fail-closed handling.
It cannot by itself establish resistance to compromise of the
operating-system kernel hosting both processes.
CW-1.16.2 — Protected Credential-Broker Prototype
Das Expires 29 April 2027 [Page 82]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A credential broker may retain a reusable service credential outside
the agent's access.
The agent submits a Candidate Act.
A protected authority validates the operation.
The controlled gateway performs the permitted request using the
credential.
The agent does not receive unrestricted credential material.
The prototype can test whether a substituted request changes the
actual effectuation parameters and whether the gateway rejects the
mismatch.
CW-1.16.3 — Protected Sink Prototype
A storage controller may maintain an initially uncommitted operation.
The PED generates an operation-bound authority.
The storage sink checks the actual record, version, and mutation
parameters before commit.
The test may substitute the pending object after authorization.
Correct operation requires rejection of a materially different
object.
CW-1.16.4 — Cross-Agent Conflict Prototype
Two agents may propose independently valid but incompatible
mutations.
9.2.3.33. Source page 47 of the original specification
A protected reservation service may determine the applicable
ordering.
Each sink verifies current reservation state.
The prototype may test stale reservations, concurrent attempts, and
recovery after a crash.
CW-1.16.5 — CW-2 Causal Receipt Prototype
A first protected sink performs a bounded real storage operation.
Das Expires 29 April 2027 [Page 83]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A qualified observer supplies actual commit evidence.
A cryptographically identified IEV accepts the evidence.
The accepted receipt becomes the necessary condition for a second
sink to perform a protected export.
The second sink rejects an attempted export without the correct
validator-authenticated receipt.
CW-1.16.6 — Hardware-Backed Prototype
A protected controller or security module may store finality
authority and consumption state.
The effectuation interface may be configured so that ordinary
application processes cannot bypass the required controller.
The implementation can test hardware-enforced withholding and
protected key or state access.
CW-1.16.7 — Feasibility Metrics
Testing may measure unauthorized effect acceptance, substitution
detection, replay rejection, validation latency, throughput,
protected-state overhead, crash recovery, concurrent state
correctness, and actual enforcement coverage.
Results should distinguish theoretical properties, software
simulations, implementation measurements, and independently validated
hardware behavior.
CW-1.17 — OPTIONAL PRESENT-DAY INVENTIVE TECHNICAL EXTENSIONS
The following optional concepts may be implemented using existing
classes of computing technology. Each is a proposed area of
technical differentiation, not a declaration that the underlying
constituent techniques are individually new.
CW-1.17.1 — Protected Effectuation-Path Coverage Commitment
A protected controller may maintain an authenticated description of
all known effect-capable routes relevant to a designated
consequential resource.
The system may detect when an application, driver, network interface,
or hardware configuration change creates an unmediated path.
Das Expires 29 April 2027 [Page 84]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.2.3.34. Source page 48 of the original specification
Where the claimed protection depends upon complete mediation,
authority release may be withheld until the relevant path coverage is
revalidated.
A reference implementation may enumerate and test controlled software
and device interfaces under an explicitly defined coverage model.
The candidate inventive contribution would concern making coverage
state a mandatory predicate for operation-specific finality
authority.
CW-1.17.2 — Sink-Local Actual-Operation Equality
A Finality Sink may compare a protected authorized descriptor with
the operation actually presented to the controlled boundary.
The sink may verify all material effect parameters rather than merely
an upstream request digest.
A reference implementation may use controller-owned command buffers
or trusted dispatcher interfaces.
The candidate distinction concerns independent reconstruction and
mandatory release-time correspondence.
CW-1.17.3 — Protected Operation-Semantics Version Binding
An authorization may bind not only a function name but also the
semantics of the function's permitted effect.
A tool update or schema change may invalidate the earlier
correspondence.
The sink may require current verified operation-semantics
compatibility.
A prototype may vary parameter meaning or schema version and test
whether stale authority is rejected.
CW-1.17.4 — Protected Multi-Interface Resource Identity
Different applications may expose the same underlying resource
through different identifiers.
A protected resolver may establish authenticated equivalence among
resource identities.
Das Expires 29 April 2027 [Page 85]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The final authorization may bind the resolved target rather than only
a string supplied by the agent.
A feasibility prototype may map a document across storage, sharing,
and transmission interfaces.
CW-1.17.5 — Protected Delegation Attenuation
An original principal may authorize an agent to perform a narrow
task.
The agent may delegate part of the task to another service.
Each delegation may be constrained by the original permitted effect,
resource, destination, and authority state.
The final sink verifies the applicable delegation lineage.
9.2.3.35. Source page 49 of the original specification
CW-1.17.6 — Protected Credential-Release Finality
A credential broker may retain reusable credentials while the agent
receives only constrained operation references.
The broker may release or exercise privileged credentials only for a
verified actual operation.
This may support cloud API gateways, enterprise connectors, and
device-management infrastructure.
CW-1.17.7 — Cross-Agent Effect Reservation
Independently authorized agents may be required to satisfy protected
effect-conflict reservations before performing potentially
interfering operations.
This extension may employ the specialized techniques disclosed in
Embodiment 1.
CW-1.17.8 — Protected Semantic Target Continuity
A user may approve an operation involving an object visible on a
screen or in another interface.
The system may preserve the relationship between the approved
referent and actual target.
Das Expires 29 April 2027 [Page 86]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The sink refuses a substituted object unless the change is separately
authorized.
CW-1.17.9 — Protected Privacy Exposure Accumulation
A protected privacy module may maintain an authenticated cumulative
exposure state across multiple otherwise permitted operations.
The final sink may require that the new disclosure remain within
applicable limits.
CW-1.17.10 — Protected Causal Receipt Continuation
An operation may be divided into bounded real-effect phases.
A cryptographically identified IEV may accept a qualified predecessor
receipt.
The resulting accepted receipt becomes a necessary factor in the next
sink's effectuation authority.
This optional extension is detailed in CW-2.
CW-1.17.11 — Protected Unknown-Outcome Fence
A protected controller may maintain an unresolved attempt state when
an external effect may have occurred.
The state may prevent unsafe retry, conflicting effectuation, or
premature continuation.
CW-1.17.12 — Protected Authority Ownership Across Devices
A protected ownership epoch may ensure that only one designated
device can exercise an exclusive unfinished authorization.
9.2.3.36. Source page 50 of the original specification
A superseded device's authority may be fenced at the actual sink.
CW-1.17.13 — Protected Validation Work Budget
The PED may allocate bounded computation and memory resources for
validating a Candidate Act.
Malformed or adversarially expensive proof requests may be rejected
without exhausting resources needed for protected operations.
Das Expires 29 April 2027 [Page 87]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
This extension may be relevant to high-throughput security gateways
and embedded devices.
CW-1.17.14 — Protected Deadline-Aware Finality Scheduling
A protected scheduler may consider command deadlines, safety
constraints, and verification costs.
It may choose a permitted verification strategy while preserving
mandatory security predicates.
A deadline does not convert an inconclusive mandatory check into
permission.
CW-1.17.15 — Protected Sink Coverage After Software Updates
Following relevant application, operating-system, or firmware
updates, the system may verify that the same consequential interfaces
remain controlled.
Authority may be restricted until new effectuation-path coverage is
established.
CW-1.17.16 — Protected Multi-Principal Authority
Some effects may require authority from more than one principal.
The protected system may combine distinct authenticated approvals
while preserving the specified operation scope and Finality Sink
verification.
CW-1.17.17 — Protected Receipt-Dependent Recovery
An adverse but verified outcome may support a narrowly scoped
recovery operation.
The protected receipt may serve as a causal prerequisite for
recovery, without granting unlimited corrective authority.
CW-1.17.18 — Protected Runtime Influence Attribution
A specialized module may examine the provenance or influence of
untrusted instructions, tool outputs, persistent memory, or external
content on a proposed operation.
Such evidence may become an additional sink-enforced restriction
where the implementation can support the required attribution.
Das Expires 29 April 2027 [Page 88]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The system does not assume that all neural inference can be perfectly
explained or traced.
CW-1.18 — ADVANCED FUTURE-ORIENTED OPTIONAL TECHNICAL CONCEPTS
9.2.3.37. Source page 51 of the original specification
The following concepts address plausible extensions of autonomous
computing and effectuation infrastructure. They are proposed
technical variations, not statements of present commercial adoption,
experimental success, or patentability.
CW-1.18.1 — Cross-Provider Autonomous-Agent Effectuation
Future agent ecosystems may involve multiple independently
administered agents cooperating on one task.
A protected authority may bind permitted effects across delegation
boundaries without giving every participant unrestricted access to
the original principal's credentials.
A final destination-side sink may verify the operation under a
locally enforceable scoped authorization.
A reference implementation can presently approximate this arrangement
using authenticated service-to-service messages and controlled tool
gateways.
CW-1.18.2 — Protocol-Neutral Tool Effectuation
An agent may invoke operations through different communication
protocols, RPC interfaces, local application functions, database
APIs, or direct hardware commands.
The protected system may transform different protocol-level requests
into a common effect-specific descriptor.
The final sink may verify the actual consequential parameters
independently of the original protocol syntax.
The technical difficulty lies in establishing correct, non-ambiguous
operation semantics across heterogeneous interfaces.
CW-1.18.3 — Dynamic Tool Discovery with Protected Contract Binding
An autonomous agent may discover new tools at runtime.
Das Expires 29 April 2027 [Page 89]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A protected registry may identify which tools produce governed
effects and which sink requirements apply.
Newly discovered tools may remain restricted until their effectuation
contracts and necessary enforcement interfaces are verified.
The agent cannot eliminate mandatory authorization by selecting a
previously unknown tool name.
CW-1.18.4 — Secure Compute-Accelerator Effectuation
Future accelerators may execute increasingly autonomous computation
and may initiate memory, storage, network, or device effects.
An optional protected controller may mediate effect-capable
accelerator outputs or command queues.
9.2.3.38. Source page 52 of the original specification
The technical focus is the consequential release boundary, not the
accelerator's internal mathematical computation.
CW-1.18.5 — Confidential Agent Execution
A confidential computing environment may protect selected agent state
or secrets.
CW-1 may additionally require that protected or attested computation
obtain finality authority before causing consequential effects
outside the protected environment.
Confidentiality of computation does not automatically establish
authorization of its external outputs.
CW-1.18.6 — Autonomous Edge-to-Cloud Migration
A task may move between local and cloud execution.
Protected authority may remain bound to the permitted operation even
if the computational location changes.
A protected migration state may fence the previous execution owner
where exclusivity is required.
CW-1.18.7 — Future Communication Networks
Das Expires 29 April 2027 [Page 90]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Autonomous network management may involve dynamic resource
allocation, radio configuration, network slicing, edge processing,
and distributed control.
A protected effectuation mechanism may govern the actual
configuration changes at relevant controllers.
The disclosure does not depend upon a particular future cellular
generation or communication standard.
CW-1.18.8 — Multi-Sensor Physical Autonomy
A future autonomous device may combine camera, depth, position,
audio, radio, and other sensor inputs.
A protected physical-scene module may verify the intended target
immediately before actuation.
The final controller may require current target correspondence and
authorized operating constraints.
CW-1.18.9 — Autonomous Vehicle and Fleet Coordination
Vehicles or machines may propose independently authorized movements
or shared resource operations.
A protected effect-conflict system may govern incompatible
commitments, while device-local sinks enforce actual commands.
Real-world safety requires appropriate physical control and sensing
systems beyond generic cryptographic authorization.
CW-1.18.10 — Extended-Reality and Spatial Computing
9.2.3.39. Source page 53 of the original specification
An assistant may act upon objects selected through spatial
interfaces.
A protected semantic correspondence system may bind the selected
virtual or physical referent to the actual effectuation target.
The system may prevent substitution caused by changes in spatial
registration, application state, or target identity.
CW-1.18.11 — Future Chiplet and Heterogeneous Hardware Controllers
Das Expires 29 April 2027 [Page 91]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A processor may include multiple isolated computing and control
units.
The PED, validators, and Finality Sinks may be distributed among the
units.
Authenticated internal interfaces may establish authority and state
continuity.
The same protected causal and effectuation relationships may be
implemented without a separate external security appliance.
CW-1.18.12 — Post-Quantum Cryptographic Migration
A protected system may permit migration to different cryptographic
authentication mechanisms when required by evolving threat models or
standards.
The protected authority and receipt formats may carry algorithm
identifiers and credential generations.
The correctness of the finality architecture is not tied to one
particular present-day signature algorithm.
Post-quantum cryptography itself is not claimed as a new invention
merely by being used for validator or sink authentication.
CW-1.18.13 — Privacy-Preserving Distributed Verification
A remote verifier may establish selected authorization predicates
without receiving all underlying private data.
Suitable commitments, authenticated attestations, selective
disclosure, or privacy-preserving proofs may be used where
technically appropriate.
The final sink must still obtain sufficient evidence to verify the
required actual-operation conditions.
CW-1.18.14 — Autonomous Cross-Organization Transactions
Several organizations may operate independent protected controllers.
A single workflow may require effects in different administrative
domains.
Das Expires 29 April 2027 [Page 92]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Each domain may independently enforce its own finality requirements
while accepting narrowly scoped authenticated evidence from
cooperating domains.
The architecture must define trust, authority ownership, and failure
behavior across network partitions.
9.2.3.40. Source page 54 of the original specification
CW-1.18.15 — Self-Adjusting Verification Under Protected Constraints
A system may select among approved verification procedures based upon
operation risk, current technical state, computational resources, or
observation availability.
Mandatory safety or authorization predicates remain preserved.
A learned risk score does not itself override a failed protected
constraint.
CW-1.18.16 — Future Autonomous Hardware Peripherals
An effect-capable peripheral may perform operations with limited
involvement from the host processor.
The peripheral may incorporate a protected Finality Sink or accept
constrained authority from another protected controller.
The relevant consequential primitive remains subject to the
applicable operation-bound conditions.
CW-1.18.17 — Protected Real-Effect Evidence Across Long Delays
Some distributed systems may experience significant communication
delay or intermittent connectivity.
The architecture may use bounded local authority, authenticated
causal evidence, and protected replay-resistant state to govern
delayed continuation.
Where current global state is unavailable, the permitted autonomous
scope must be constrained by the defined safety and consistency
assumptions.
CW-1.18.18 — Future Machine-to-Machine Economic Operations
Autonomous devices may initiate resource purchases, usage
commitments, settlements, or access grants.
Das Expires 29 April 2027 [Page 93]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A protected sink may verify actual transaction parameters and
applicable authority.
Receipt-gated continuation may be applied where a later economic
effect requires confirmation of an earlier actual transaction state.
CW-1.18.19 — Future Distributed Actuation with Independent Witnessing
A physical operation may occur in one domain while another protected
system observes its result.
A cryptographically identified IEV may validate the observed effect
and establish the next operation's causal authority.
The receiving Finality Sink verifies the accepted receipt.
CW-1.18.20 — Future Operation-Level Enforcement as a Shared
Infrastructure Service
A computing platform may expose protected execution-finality controls
as a service usable by several applications or agent frameworks.
9.2.3.41. Source page 55 of the original specification
The service may manage Candidate Act descriptors, validator
identities, protected evidence, scoped capabilities, and sink
enforcement interfaces.
Applications may innovate independently in planning and computation
while the protected service continues to govern consequential
effects.
CW-1.19 — ADVANCED OPTIONAL INVENTIVE COMBINATIONS
CW-1.19.1 — Cross-Interface Actual-Effect Identity and Sink Coverage
One optional combination binds an effect-specific resource identity
to a protected inventory of relevant effectuation paths.
A new application interface or driver update may trigger revalidation
of whether the actual resource remains covered.
The Finality Sink may require a current coverage commitment before
releasing the operation.
The potentially distinctive interaction is between resource
equivalence, mandatory enforcement coverage, and operation-specific
authorization.
Das Expires 29 April 2027 [Page 94]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
CW-1.19.2 — Causal Receipt and Cross-Agent Conflict-State Advancement
Another optional combination integrates Embodiment 1 and CW-2.
An earlier real effect produces a validator-accepted receipt.
The accepted receipt establishes the necessary continuation authority
for a successor phase while also controlling advancement or release
of protected reservations affecting other agents.
A successor sink verifies both the receipt-derived causal condition
and current conflict-state validity.
CW-1.19.3 — Semantic Referent and Credential-Release Binding
A user selects a document or resource through an application
interface.
A protected semantic module verifies the selected actual object.
A credential broker permits a specifically bound external operation
only for that object and destination.
The final sink independently checks the actual command.
The candidate contribution concerns the enforced relationship between
user-observed referent, operation-specific credential exercise, and
actual effectuation.
CW-1.19.4 — Dynamic Tool Contract and Protected Authority Revocation
A previously authorized tool undergoes a material schema or semantic
change.
A protected action-contract registry detects the change.
Existing authority bound to the earlier semantics is invalidated or
requires revalidation.
9.2.3.42. Source page 56 of the original specification
The sink prevents the changed operation from proceeding under stale
authorization.
CW-1.19.5 — Privacy Composition and Destination-Side Finality
Several agents attempt data disclosures through different
applications.
Das Expires 29 April 2027 [Page 95]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A protected privacy state tracks applicable cumulative effect
constraints.
Each destination-side transmission sink verifies the current relevant
privacy state and actual outgoing operation.
CW-1.19.6 — Device Migration and Causal Continuation
A workflow migrates from one device to another.
The prior device's authority is fenced.
The new device may require a qualified prior-effect receipt for a
pending causal continuation.
The successor sink verifies both exclusive ownership and receipt-
derived authority.
CW-1.19.7 — Resource-Constrained Security Validation with Fail-Closed
Deadlines
A protected scheduler may reserve verification resources for high-
priority consequential operations.
It may reject or defer requests exceeding a protected verification
budget.
Where operation deadlines are relevant, the scheduler may use
prevalidated protected evidence or appropriate bounded checks.
It must not bypass mandatory authorization merely because the
remaining time is short.
CW-1.19.8 — Independent Physical Target and Actual Command
Reconstruction
A protected sensor module may identify a physical target.
The actuator sink independently obtains the actual command and
currently resolved target.
It verifies correspondence with the authorized target and current
protected operating envelope.
CW-1.19.9 — Protected Evidence Without Persistent Raw Data
A system may validate a consequential operation using protected
commitments to sensitive context.
Das Expires 29 April 2027 [Page 96]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
It may retain the minimum evidence needed to demonstrate valid
authority and prevent replay.
The raw private source data need not be permanently stored when an
appropriate authenticated reference suffices.
CW-1.19.10 — Consequence-Aware Revocation Propagation
Revocation may affect several dependent pending operations.
9.2.3.43. Source page 57 of the original specification
A protected dependency structure may identify which unexecuted
Candidate Acts rely upon invalidated authority.
The relevant sinks prevent further effects without claiming
retroactive reversal of already completed external consequences.
CW-1.20 — PRESENT AND FUTURE FEASIBILITY OF ADVANCED VARIANTS
CW-1.20.1 — Present Feasibility
Many underlying engineering mechanisms are presently available as
established technology classes.
Examples include protected process isolation, cryptographic
authentication, transaction-state management, secure hardware
registers, monotonic counters, authenticated communication,
controlled API gateways, and device security modules.
Such building blocks can be combined to implement representative CW-1
embodiments.
Their availability does not establish that the specific proposed
combinations are already known or that they are automatically
inventive.
CW-1.20.2 — Advanced Feasibility
Future-oriented variants may require stronger integration with device
firmware, hardware command paths, distributed identity, trusted
effect observation, or new interface standards.
A PHOSITA may adapt the disclosed protected records, state
transitions, and sink verification rules to suitable hardware and
software interfaces.
Das Expires 29 April 2027 [Page 97]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The implementation must be evaluated against the actual trust model
and supported effectuation primitives.
CW-1.20.3 — Modular Development
A reference system may begin with one controlled storage or network
Finality Sink.
Additional sinks may be introduced as independently verified
protected interfaces.
A causal IEV may be added where multi-phase actual-effect evidence is
necessary.
Conflict, semantic, privacy, and physical-scene modules may be
integrated according to the target application.
CW-1.20.4 — Feasibility Boundaries
A design does not become non-bypassable merely because it uses a
secure processor.
An external effect is not proven merely because a receipt is signed.
A remote transaction is not made atomic merely because it is
represented in a protected local state machine.
9.2.3.44. Source page 58 of the original specification
A future-oriented embodiment should identify these limitations.
CW-1.20.5 — Performance Considerations
A system may use compact descriptors, cached verification material,
local protected state, batching, precomputation, or hardware
acceleration.
Such optimization must preserve mandatory act binding, current-state
checks, and consumption semantics.
CW-1.21 — INVENTIVE-STEP ANALYSIS
CW-1.21.1 — Established Building Blocks
Authentication, authorization, access-control systems, sandboxes,
transaction isolation, digital signatures, protected hardware,
fencing tokens, and audit records are established mechanisms.
Das Expires 29 April 2027 [Page 98]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
CW-1 does not assert novelty merely from their individual use.
CW-1.21.2 — Candidate Distinguishing Combination
A potentially meaningful technical combination comprises:
A Candidate Act generated without inherent execution authority;
An enforceable Non-Effective State;
Protected verification of operation-specific predicates;
Formation of scoped non-bearer finality enablement;
Independent reconstruction of the actual pending operation at the
Finality Sink;
Verification of the authority against the actual operation and
current protected state;
And protected single-use or bounded consumption before effectuation.
Optional modules may add specific technical restrictions.
CW-1.21.3 — Objective Technical Problem
The objective technical problem concerns ensuring that independently
generated computational operations cannot cause unauthorized
consequences through controlled effectuation paths, despite changes
to runtime context, intermediate software, credentials, resource
state, or operation parameters.
CW-1.21.4 — Technical Interaction
The Candidate Act identifies the proposed effect.
The Non-Effective State prevents premature release.
The PED establishes protected authority.
9.2.3.45. Source page 59 of the original specification
The finality capability binds the permitted effect.
The Finality Sink reconstructs the actual operation.
Sink-time verification enforces the protected binding.
Das Expires 29 April 2027 [Page 99]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Consumption prevents unauthorized repeated exercise.
These components perform distinct but coordinated functions.
CW-1.21.5 — Why a Mere Aggregation Is Insufficient
A system containing a sandbox, signature, gateway, and policy engine
is not necessarily inventive.
The potentially relevant contribution is the specific technical
dependence of actual effectuation upon appropriately protected,
operation-specific authority and actual boundary verification.
CW-1.21.6 — Optional Inventive-Step Contributions
An optional extension may contribute an additional technical
mechanism.
For example, effectuation-path coverage attestation may make
interface coverage a mandatory authorization predicate.
A causal IEV may make the accepted earlier real-effect receipt an
indispensable next-phase execution factor.
A conflict module may make protected reservations mandatory at
multiple actual sinks.
A semantic module may bind a user-observed referent to the actual
operation target.
Each candidate contribution should be assessed separately against the
relevant prior art.
CW-1.21.7 — Hindsight Considerations
Where prior-art references are combined, the analysis should identify
why a PHOSITA would have implemented the specific protected
architecture.
It is insufficient merely to locate each broad component in a
different reference and restate the claimed combination.
Nevertheless, established motivations to combine zero-trust
authorization, capability security, distributed coordination, and
effectuation gates must also be considered.
Inventive step depends upon the actual claim limitations and relevant
technical teachings.
Das Expires 29 April 2027 [Page 100]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
CW-1.21.8 — Non-Guarantee of Patentability
A detailed specification does not automatically establish novelty,
inventive step, or claim validity.
The claimed combination must be supported by the original application
as filed and examined against relevant prior disclosures.
Broad functional language alone does not eliminate every possible
design-around.
9.2.3.46. Source page 60 of the original specification
CW-1.22 — INDUSTRIAL APPLICABILITY
CW-1 may be implemented in autonomous AI systems interacting with
enterprise resources, cloud infrastructure, device operating systems,
networks, financial services, protected data, industrial equipment,
robotic actuators, and distributed computing environments.
In enterprise systems, it may govern application-function dispatch,
document modification, and external communications.
In cloud systems, it may govern protected resource creation,
deletion, modification, credential release, and network changes.
In mobile and desktop systems, it may govern assistant-mediated file
operations, message transmission, application controls, and sensitive
device resources.
In financial infrastructure, it may bind protected authority to
actual transaction parameters.
In telecommunications, it may govern network configuration, service
activation, and relevant control-plane effects.
In industrial automation, it may govern actuator commands and
protected device-state changes.
In distributed multi-agent systems, it may preserve scoped authority
and applicable operation constraints across service or provider
boundaries.
In future heterogeneous systems, it may provide a common
effectuation-control layer independent of the computational
architecture generating the request.
Das Expires 29 April 2027 [Page 101]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The industrial utility lies in controlling real technical
consequences through protected enforcement, not merely generating
recommendations concerning whether an operation appears desirable.
CW-1.23 — PROPOSED TECHNICAL VALIDATION PROGRAM
A comprehensive reference implementation may test the following
properties.
Test 1 — Operation Substitution. Authorize one resource and attempt
to effectuate another.
Test 2 — Destination Substitution. Change the destination after
protected authorization.
Test 3 — Capability Replay. Attempt repeated use of single-use
authority.
Test 4 — Agent-Level Bypass. Remove ordinary agent approval checks
while leaving protected sink enforcement active.
Test 5 — Alternate API. Attempt the same effect through a different
covered application interface.
Test 6 — Protected State Rollback. Restore previously consumed
authority through a stale snapshot.
Test 7 — Privileged Credential Theft. Determine whether the actual
sink still requires operation-specific finality authority.
9.2.3.47. Source page 61 of the original specification
Test 8 — Module Failure. Disable a mandatory specialized validator
and verify refusal.
Test 9 — Multi-Agent Conflict. Submit two independently authorized
incompatible effects.
Test 10 — Semantic Target Drift. Change the selected application
object between approval and effectuation.
Test 11 — Action Contract Change. Modify tool semantics after
authorization.
Test 12 — Unknown Outcome. Suppress acknowledgement after a possible
real external effect.
Das Expires 29 April 2027 [Page 102]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Test 13 — Causal IEV Receipt. Attempt a successor phase without the
required accepted real-effect receipt.
Test 14 — Validator Identity Forgery. Use the correct displayed
validator identifier with incorrect cryptographic credentials.
Test 15 — Cross-Domain Authorization. Present protected authority
from one domain to a different authorized sink.
Test 16 — Device Migration. Attempt stale execution after exclusive
authority moves to another device.
Test 17 — Privacy Accumulation. Perform several disclosures whose
combined effect violates a protected constraint.
Test 18 — Enforcement-Coverage Drift. Introduce a new effect-capable
interface and determine whether protected coverage is reevaluated.
Test 19 — Verification Exhaustion. Submit expensive malformed proof
inputs under constrained resources.
Test 20 — Hardware Release. Verify that an effect-capable hardware
controller refuses commands lacking the required authority.
The results may be used to establish actual functionality and
identify limitations.
The tests are proposed and are not represented as having already been
performed.
CW-1.24 — NON-LIMITING VARIATION AND SCOPE STATEMENT
CW-1 may be implemented using separate or integrated PED and Finality
Sink components.
It may use local or remote authority.
It may use cryptographic or protected-state capability
representations.
It may use one agent or many agents.
It may operate with or without an Interim Effectuation Validator
where the selected embodiment permits.
It may support one consequential effect or a series of causally
linked effects.
Das Expires 29 April 2027 [Page 103]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.2.3.48. Source page 62 of the original specification
It may use hardware-backed security, protected software services, or
hybrid enforcement.
It may employ a protected credential broker, direct sink
authorization, or both.
It may use cryptographic receipts, internal protected state, or other
authenticated evidence mechanisms.
It may operate across application, operating-system, network,
storage, controller, device, or cloud boundaries.
It may incorporate future communication and computing architectures
without being restricted to a particular commercial implementation.
The selected mechanism must preserve the technical invariants
required by the applicable claimed embodiment.
CW-1.25 — TECHNICAL CHARACTERIZATION
Common Master Workflow CW-1 provides a modular architecture for
governing consequential operations initiated by autonomous
computational entities.
The requesting entity may compute, reason, plan, propose, delegate,
or prepare an operation.
Such computation does not automatically confer authority to produce
the external consequence.
The proposed operation may be represented as a Candidate Act and held
non-effective.
A Protected Enforcement Domain evaluates relevant authorization and
technical evidence.
Additional specialized modules may impose further protected
constraints.
Scoped finality authority is generated, derived, activated, or
committed under protected conditions.
The actual Finality Sink obtains or reconstructs the operation
pending at the consequence-producing boundary.
Das Expires 29 April 2027 [Page 104]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The sink independently verifies the operation against the required
authority and current protected state.
Where single-use authority is required, the appropriate protected
consumption procedure is performed.
Only then is the specified consequential operation permitted.
Optional mechanisms may provide protected cross-agent conflict
arbitration, semantic target correspondence, privacy composition,
delegated authority constraints, execution-path coverage
verification, device migration, runtime integrity, and other
technical protections.
Where receipt-gated causal continuation is selected, an earlier real
effect produces evidence accepted by a cryptographically identifiable
authorized IEV.
The resulting accepted receipt constitutes a necessary causal
enabling factor for the next phase, and the successor Finality Sink
verifies that condition before permitting the next consequential
effect.
9.3. Miscellaneous Embodiment M-1: Dynamic Effectuation Coverage and
Future-Adaptive Infrastructure
Original technical source global pages 555-609; input volume
TECHNICAL SPECIFICATION -555-1062.pdf. Primary Part 4 topic:
Miscellaneous Embodiment M-1: Dynamic Effectuation Coverage and
Future-Adaptive Infrastructure. The patent specification may present
optional embodiments, alternative formulations and claim proposals;
preserving its wording does not convert each option into a
requirement of a standard.
9.3.1. Protected Architecture and Trust-Boundary Diagram
[Multiple tool / network / IPC / device routes]
|
[Dynamic effectuation path discovery]
|
[Semantics/identity/coverage controller]
|
[Protected coverage state + revocation]
|
[Enforcing receiving Finality Sink]
Figure 16: Miscellaneous Embodiment M-1: Dynamic Effectuation
Coverage and Future-Adaptive Infrastructure — architecture
Das Expires 29 April 2027 [Page 105]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.3.2. Operational Decision and Fail-Closed Flowchart
[Discover changed interface]
|
<Is path effect-capable?>--NO-->[Classify/monitor]
|YES
<Qualified mandatory gate exists?>--NO-->[Invalidate]
|YES
[Update coverage commitment]
|
<Current act authorized?>--NO-->[Withhold]
|YES
[Sink verify / release]
Figure 17: Miscellaneous Embodiment M-1: Dynamic Effectuation
Coverage and Future-Adaptive Infrastructure — operational
flowchart
9.3.3. Original Page-by-Page Technical Disclosure
9.3.3.1. Source page 555 of the original specification
The successor Finality Sink independently verifies the actual pending
operation before effectuation.
The architecture may additionally employ witness independence
policies, remote state-consistency checks, privacy-preserving
evidence, protected outcome-reconciliation fences, and separately
authorized recovery operations.
The disclosed mechanisms are applicable across heterogeneous
administrative and computing domains without assuming that every
remote service provides complete verifiability.
The central proposed technical contribution is an enforceable
relationship between a protected originating Candidate Act, an
independently supported remote consequence predicate, authenticated
cross-domain outcome evidence, and separately scoped successor
execution authority.
The architecture distinguishes operation authorization, remote
request acceptance, observed state, operation-specific causation, and
sufficiently established remote finality.
The inventive step of any claimed combination remains subject to
examination against established remote attestation, transactional
state verification, distributed authorization, audit receipts,
verifiable data structures, and other relevant prior disclosures.
Das Expires 29 April 2027 [Page 106]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
END OF EMBODIMENT 4.
MISCELLANEOUS EMBODIMENT M-1
MODULAR FUTURE-ADAPTABLE PROTECTED EFFECTUATION INFRASTRUCTURE WITH
DYNAMIC ENFORCEMENT-PATH COVERAGE, OPERATION-SEMANTICS CONTINUITY,
CROSS-INTERFACE RESOURCE CORRESPONDENCE, DISTRIBUTED AUTHORITY
ATTENUATION, PRIVACY AND RESOURCE-STATE GOVERNANCE, AND HETEROGENEOUS
HARDWARE EXECUTION CONTROL
M-1.0 — COMPLETE TECHNICAL TITLE
Systems and Methods for Modular, Cross-Platform, and Future-Adaptable
Autonomous Execution-Finality Enforcement Using Protected
Effectuation-Surface Discovery, Dynamic Action-Contract Verification,
Cross-Interface Resource Identity, Cryptographically Authenticated
Delegated Authority, Protected Credential-Release Control, Resource-
Constrained Validation, Enforcement-Coverage Reattestation, and
Optional Distributed Hardware and Software Security Mechanisms
M-1.0.1 — General Characterization
The present Miscellaneous Embodiment M-1 discloses additional
optional systems, methods, apparatus, protected computing components,
authenticated protocols, machine-verifiable data structures,
protected state transitions, hardware mechanisms, and software
enforcement arrangements for extending protected execution-finality
control across existing and emerging autonomous computing
environments.
The embodiment is intended to provide concrete technical
implementation support for supplementary features identified within
Common Master Workflow CW-1, including the optional
9.3.3.2. Source page 556 of the original specification
technical concepts, advanced future-oriented variations, and combined
protected enforcement arrangements.
The embodiment is applicable to artificial-intelligence agents,
autonomous applications, multi-agent orchestration, operating-system
services, distributed computing services, protected devices, cloud
infrastructure, embedded systems, telecommunications equipment,
secure storage controllers, heterogeneous computing processors,
hardware accelerators, robotic systems, enterprise systems, and other
computational environments capable of producing consequential
effects.
Das Expires 29 April 2027 [Page 107]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
In a representative implementation, a computational entity generates
a proposed consequential operation.
The protected system identifies the actual effectuation surfaces
through which the operation or an equivalent operation may produce
the intended consequence.
It establishes a machine-verifiable operation descriptor, identifies
the applicable operation semantics, resolves relevant resource
identities, determines the protected authority required for the
effect, and verifies the existence and validity of the necessary
enforcement coverage.
Where applicable, additional modules evaluate delegation lineage,
cumulative resource use, privacy exposure, semantic correspondence,
execution-environment integrity, or other protected conditions.
The corresponding Finality Sink obtains or reconstructs the actual
pending operation and independently verifies its scope, current
authority, and protected state before permitting the governed
consequence.
The disclosed additional mechanisms may be implemented individually
or in technically compatible combinations.
No particular supplementary mechanism is universally mandatory for
all implementations of Common Master Workflow CW-1.
M-1.0.2 — Relationship to Completed Embodiments
Embodiment 1 concerns protected cross-agent effect-conflict
arbitration.
Embodiment 2 concerns independently validated causal phase
continuation and the receipt-dependent authority mechanisms
associated with actual earlier effects.
Embodiment 3 concerns protected correspondence between an authorized
user-referenced object and the actual effectuation target.
Embodiment 4 concerns independently qualified evidence of
consequential effects occurring across administrative or computing
domains.
Miscellaneous Embodiment M-1 does not replace or amend those
embodiments.
Das Expires 29 April 2027 [Page 108]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
It develops additional technical mechanisms involving enforcement
coverage, operation-contract continuity, authority portability,
privacy composition, heterogeneous hardware, resource-bounded
verification, and emerging autonomous computing environments.
Where necessary, an implementation may invoke mechanisms from the
earlier embodiments without restating their complete technical
procedures.
9.3.3.3. Source page 557 of the original specification
M-1.0.3 — Modular Character
The present embodiment may operate as one or more supplementary
verification modules associated with a Protected Enforcement Domain,
a Finality Sink, an authenticated controller, a distributed authority
service, or another suitable protected component.
For example, one implementation may use only dynamic effectuation-
path coverage and post-update reattestation.
Another may use only cross-provider delegation and protected
credential-release binding.
Another may use only bounded-latency validation and hardware
accelerator egress enforcement.
Another may combine several modules within one protected platform.
The architecture does not require the simultaneous implementation of
every variation described herein.
M-1.0.4 — Principal Technical Objective
The principal technical objective is to preserve enforceable
operation-specific finality authority as the surrounding computing
environment changes.
Such changes may include newly discovered tools, software upgrades,
application-interface modifications, resource aliasing,
administrative-domain changes, delegation to other agents, device
migration, resource contention, accelerator execution, new hardware
interfaces, and emerging autonomous communication or actuation
mechanisms.
Das Expires 29 April 2027 [Page 109]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A protected execution system should not become ineffective merely
because the computational workload moves to a different runtime,
invokes a different tool name, changes execution device, or uses an
alternative technical route to reach the same consequential resource.
Within the defined enforcement coverage and trust model, the actual
consequence remains dependent upon valid protected authority.
M-1.0.5 — Non-Limiting Scope
The term effectuation interface is not limited to an API, network
gateway, application tool, or operating-system call.
It may include any hardware or software interface capable of
initiating, committing, releasing, transmitting, activating,
publishing, modifying, or otherwise causing a governed consequence.
The interface may be physical or virtual, local or remote,
synchronous or asynchronous, centralized or distributed.
Similarly, the protected components may be integrated into one device
or distributed among multiple processors, services, controllers, or
administrative domains.
The disclosed inventive concepts concern their technical enforcement
relationships rather than the commercial identities or physical
locations of particular components.
M-1.1 — SPECIFIC TECHNICAL PROBLEMS
9.3.3.4. Source page 558 of the original specification
M-1.1.1 — Dynamic Effectuation-Path Bypass
An autonomous computing system may possess several methods of
producing the same external consequence.
For example, a document may be transmitted through an application
API, a network socket, an automated browser, a synchronization
service, or an operating-system sharing interface.
An enforcement component controlling only one interface may be
bypassed through another.
The technical problem is to establish whether the actual effectuation
paths relevant to a protected consequence are controlled.
M-1.1.2 — Dynamic Tool Discovery
Das Expires 29 April 2027 [Page 110]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
An AI agent may discover and invoke an external tool during runtime.
A newly discovered tool may provide consequential functionality not
previously incorporated into the local authorization policy.
The existence of a tool description does not establish that its
actual behavior is trustworthy or confined to the declared semantics.
A protected system may therefore require verification of the tool's
effectuation contract and applicable Finality Sink before allowing
sensitive effects.
M-1.1.3 — Operation-Semantics Drift
An operation may retain the same name while its parameters or
behavior change after a software update.
An authorization previously issued for one operation meaning may
become inappropriate for the revised operation.
The technical problem is to prevent stale authority from silently
governing materially different actual effects.
M-1.1.4 — Cross-Interface Resource Aliasing
Several interfaces may identify the same underlying resource using
different names, handles, addresses, application identifiers, or
object references.
A protected authorization system may incorrectly treat those
references as unrelated.
The resulting failure may permit unauthorized disclosure,
modification, deletion, or resource conflicts.
M-1.1.5 — Distributed Delegation Expansion
An agent may delegate a narrow task to another agent or remote
service.
A downstream computational entity may attempt to broaden the
resource, destination, privilege, duration, or operation class beyond
the original authority.
9.3.3.5. Source page 559 of the original specification
The technical problem is to ensure that delegated authority remains
within an enforceable attenuation relationship.
Das Expires 29 April 2027 [Page 111]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-1.1.6 — Privileged Credential Overreach
A protected system may hold reusable service credentials.
If a computational entity can exercise those credentials
independently of operation-specific authorization, the entity may
perform actions outside the approved Candidate Act.
The technical problem concerns binding credential use to the actual
authorized effect rather than treating credential possession as
unrestricted permission.
M-1.1.7 — Resource and Privacy Accumulation
Several individually permitted operations may collectively exceed a
protected resource budget, privacy constraint, or delegated authority
allowance.
The system may therefore need to verify cumulative consequence state
rather than evaluate each operation in isolation.
M-1.1.8 — Security-Verification Exhaustion
An attacker may submit malformed, excessive, or computationally
expensive verification requests.
Such requests may consume protected processing, memory, power, or
time resources.
The system should preserve mandatory authorization while preventing
unbounded verification work.
M-1.1.9 — Heterogeneous Hardware Effectuation
An operation may cause external effects through a graphics processor,
accelerator, programmable network interface, peripheral controller,
storage engine, direct-memory-access mechanism, or another
nontraditional execution path.
An application-layer gateway may not observe the resulting actual
effect.
The system may require enforcement at a lower or different
consequential boundary.
M-1.1.10 — Enforcement Coverage After Updates
Das Expires 29 April 2027 [Page 112]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A software or firmware update may create a new effect-capable
interface, change an existing interface, or modify the semantics of a
previously controlled operation.
The protected system may need to reestablish that its enforcement
coverage remains valid.
M-1.1.11 — Intermittent Connectivity
An autonomous device may perform operations while disconnected from
an authoritative central service.
9.3.3.6. Source page 560 of the original specification
The system must distinguish bounded offline authority from
unrestricted authority that cannot be promptly revoked.
M-1.1.12 — Emerging Autonomous Systems
Future autonomous computing environments may include multiple model
providers, distributed agents, heterogeneous accelerators, robotic
controllers, spatial computing interfaces, and machine-to-machine
transactions.
The execution-finality architecture must remain technically
implementable without depending upon a particular current software
product or computing platform.
M-1.2 — ADDITIONAL DEFINITIONS
M-1.2.1 — Effectuation Surface
An Effectuation Surface means an identifiable interface, controller,
resource boundary, communication channel, hardware primitive,
software operation, or equivalent mechanism through which a governed
external consequence can be produced.
M-1.2.2 — Protected Effectuation-Surface Registry
A Protected Effectuation-Surface Registry, or PESR, means an
authenticated registry identifying effect-capable interfaces and the
protected enforcement conditions associated with them.
M-1.2.3 — Effectuation Coverage Commitment
Das Expires 29 April 2027 [Page 113]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
An Effectuation Coverage Commitment, or ECC-M, means protected
evidence or state binding a specified consequence class to the set of
enforcement surfaces recognized and covered by the applicable
security configuration.
M-1.2.4 — Mandatory Enforcement Path
A Mandatory Enforcement Path means an effectuation route that
requires a protected authorization condition at a controller capable
of withholding the corresponding consequence.
M-1.2.5 — Dynamic Action Contract
A Dynamic Action Contract, or DAC-M, means a machine-verifiable
description of an operation's effect semantics, supported parameters,
destination class, resource identity requirements, side effects, and
applicable finality controls.
M-1.2.6 — Action-Contract Version Commitment
An Action-Contract Version Commitment, or ACVC, means a protected
commitment binding an authorized operation to a specified action-
contract version or verified compatible semantic representation.
M-1.2.7 — Protocol-Neutral Effect Descriptor
9.3.3.7. Source page 561 of the original specification
A Protocol-Neutral Effect Descriptor, or PNED, means a representation
of the intended or actual consequential operation independent of a
particular tool name or transport protocol.
The PNED may identify the effect class, operation semantics, target
resource, destination, payload commitment, and relevant context.
M-1.2.8 — Semantic Resource Identity Commitment
A Semantic Resource Identity Commitment, or SRIC, means a protected
association of one or more resource aliases with a resolved
consequential resource identity under an applicable verified mapping.
M-1.2.9 — Delegated Authority Attenuation Chain
A Delegated Authority Attenuation Chain, or DAAC, means an
authenticated sequence of delegated authorities in which each derived
authorization is constrained by the applicable authority of its
predecessor.
Das Expires 29 April 2027 [Page 114]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-1.2.10 — Protected Credential-Release Binding
A Protected Credential-Release Binding, or PCRB, means a protected
association between credential use and the specifically authorized
actual consequential operation.
M-1.2.11 — Privacy Exposure Composition State
A Privacy Exposure Composition State, or PECS-M, means protected
state representing cumulative or correlated privacy-relevant effects
of multiple operations.
M-1.2.12 — Protected Validation Work Budget
A Protected Validation Work Budget, or PVWB, means a bounded
allocation of processor time, cryptographic verification work,
memory, energy, input size, or related resources for validating
specified operations.
M-1.2.13 — Operational Continuity Epoch
An Operational Continuity Epoch, or OCE, means a protected version or
generation value associated with an execution environment, action
contract, enforcement configuration, or authority-validity state.
M-1.2.14 — Protected Enforcement-Coverage Reattestation
Protected Enforcement-Coverage Reattestation means an authenticated
procedure for determining whether the required effectuation surfaces
and enforcement controls remain valid following a relevant
environmental change.
M-1.2.15 — Execution-Route Equivalence Record
An Execution-Route Equivalence Record, or ERER, means an
authenticated record establishing the correspondence, or relevant
permitted differences, between operations performed through
alternative execution environments or interfaces.
9.3.3.8. Source page 562 of the original specification
M-1.2.16 — Protected Resource-Parity Evidence
Protected Resource-Parity Evidence means machine-verifiable
information concerning an allocation decision under specified
resource-comparison or fairness constraints.
M-1.2.17 — Protected Delegation Boundary
Das Expires 29 April 2027 [Page 115]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A Protected Delegation Boundary means an authority transition through
which a downstream computational entity receives only the rights
permitted by the applicable predecessor authorization.
M-1.2.18 — Effectuation-Coverage Failure
An Effectuation-Coverage Failure occurs where a governed consequence
can be produced through a relevant path that lacks the mandatory
protected enforcement required by the asserted protection scope.
M-1.2.19 — Trusted Effect-Observation Interface
A Trusted Effect-Observation Interface means an observation path
capable of providing appropriately authenticated evidence concerning
a specified effect under an identified trust model.
M-1.2.20 — Future-Compatible Protected Effect Interface
A Future-Compatible Protected Effect Interface means a defined
technical contract through which a newly introduced computing or
hardware component can present actual operations, protected
authority, and required verification state to an effectuation
controller.
M-1.3 — MODULAR SYSTEM ARCHITECTURE
In one implementation, the protected infrastructure comprises a
Candidate Act interface, an effectuation-surface discovery component,
a protected action-contract registry, a resource identity resolver, a
delegation authority controller, a specialized verification
coordinator, a protected state store, and one or more Finality Sinks.
The architecture may also contain a credential broker, a privacy-
state controller, a validation work-budget manager, a software-update
verifier, and an environment-continuity monitor.
The components may be implemented individually, combined within one
protected process or device, or distributed among authenticated
services.
The requesting autonomous entity may construct or propose an
operation but cannot unilaterally declare its effectuation interface
to be covered, its delegation valid, or its action contract
unchanged.
Those properties are established through the applicable protected
mechanisms.
Das Expires 29 April 2027 [Page 116]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-1.3.1 — Baseline Information Flow
A representative flow is:
Autonomous computational request | v
9.3.3.9. Source page 563 of the original specification
Candidate Act construction | v Effectuation-surface identification |
v Action-contract and resource resolution | v Protected authority and
module verification | v Scoped finality authority preparation | v
Actual Finality Sink operation reconstruction | v Current
enforcement-coverage verification | v Protected consumption and
consequential release Optional privacy, delegation, conflict,
semantic, hardware, environmental, or causal-receipt modules may add
necessary predicates according to the particular implementation.
M-1.3.2 — Component Independence
The architecture does not require separate physical devices for every
function.
For example, the protected registry, contract verifier, and Finality
Sink may operate within one protected controller.
Alternatively, a cloud authority may manage the registry while a
hardware-local sink performs final verification.
The claimed technical relationships depend upon authenticated state
and mandatory enforcement, not component names or physical separation
alone.
M-1.4 — PROTECTED EFFECTUATION-SURFACE DISCOVERY
M-1.4.1 — Technical Purpose
A system may expose several methods of producing the same
consequential effect.
The protected system may therefore construct an effectuation-surface
inventory identifying the interfaces capable of producing the
governed consequence.
The inventory may include operating-system calls, application
dispatchers, network interfaces, service APIs, storage engines,
privileged functions, command queues, device controllers, and
hardware operations.
Das Expires 29 April 2027 [Page 117]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.3.3.10. Source page 564 of the original specification
M-1.4.2 — Surface Registration
A protected registration component may authenticate an effectuation
interface and associate it with supported effect classes.
The registration may include the interface identity, relevant
software or firmware version, controlled resource type, operation
class, protected authority requirements, and applicable Finality
Sink.
M-1.4.3 — Surface Identity
Each registered effectuation surface may possess a unique or issuer-
qualified identity within the applicable trust domain.
The identity may be bound to cryptographic credentials, protected
controller state, measured firmware, or another suitable
authenticated registration mechanism.
M-1.4.4 — Effectuation Coverage Graph
An implementation may maintain a protected graph associating
consequence classes with effect-capable interfaces and their
authoritative enforcement controllers.
A graph node may represent an application dispatch function, system
service, network controller, accelerator output, storage commit path,
or physical actuator.
An edge may represent a path through which a proposed operation can
reach a consequential interface.
M-1.4.5 — Protected Coverage Verification
Before permitting a governed effect, the relevant protected system
may verify that the actual effectuation route terminates at a
controller enforcing the required finality predicates.
Where the authorization depends upon complete coverage of a defined
effect class, unknown or unmediated relevant paths may cause the
authorization to be withheld.
M-1.4.6 — Dynamic Surface Discovery
Das Expires 29 April 2027 [Page 118]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
When an application, service, plugin, driver, or hardware component
introduces a new effect-capable interface, the system may require the
interface to register or undergo protected discovery.
The system may provisionally restrict the interface until its
operation semantics and final enforcement conditions have been
established.
M-1.4.7 — Coverage Attestation
The protected system may generate an ECC-M describing the covered
effect class, relevant enforcement interfaces, configuration version,
and applicable validation state.
The commitment may be bound to the Candidate Act or authority epoch.
M-1.4.8 — Unknown Surface Behavior
9.3.3.11. Source page 565 of the original specification
An implementation may distinguish harmless computational interfaces
from effect-capable interfaces.
Where classification remains uncertain, the system may conservatively
restrict the operation or require additional verification.
A semantic classifier's confidence score is not itself proof that an
interface cannot produce a consequential effect.
M-1.4.9 — Technical Contribution
The proposed additional technical mechanism is to make current
effectuation-path coverage a protected predicate of actual operation
release.
The coverage record is not merely an inventory maintained for
administrative purposes.
It participates in determining whether the relevant Finality Sink may
authorize the actual consequence.
M-1.5 — PROTOCOL-NEUTRAL EFFECT DESCRIPTION
M-1.5.1 — Technical Problem
The same consequential operation may be invoked through different
protocols or application interfaces.
Das Expires 29 April 2027 [Page 119]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
For example, a document export may occur through a graphical
application, a structured API, a file synchronization operation, or a
network upload.
An authorization bound only to one tool name may not capture the
effect that matters.
M-1.5.2 — Effect-Based Representation
The system may create a PNED representing the actual consequence
independently of the original invocation syntax.
The PNED may include a normalized effect class, target identity,
destination, operation semantics, relevant data commitment, and
scope.
M-1.5.3 — Representative Structure
PROTOCOL_NEUTRAL_EFFECT_DESCRIPTOR = { descriptor_version,
requesting_entity, original_candidate_act_digest, effect_class,
normalized_operation_semantics, target_resource_identity,
destination_identity, data_or_command_commitment,
permitted_effect_scope, source_interface_identity,
9.3.3.12. Source page 566 of the original specification
applicable_action_contract, designated_finality_sink,
protected_authority_epoch } M-1.5.4 — Multiple Protocol Adapters
A protocol adapter may convert an application request into the PNED.
Another adapter may convert a hardware command.
Each adapter is authenticated or otherwise covered by the applicable
protected trust assumptions.
The protected verifier checks that the conversion preserves the
security-relevant semantics.
M-1.5.5 — Actual-Effect Comparison
At final effectuation, the sink verifies that the actual command
corresponds to the authorized normalized effect.
A mismatch in resource, destination, content, privilege, or
consequential behavior may result in denial.
M-1.5.6 — Ambiguous Semantics
Das Expires 29 April 2027 [Page 120]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Where the system cannot establish a reliable equivalence between two
operation representations, it does not silently treat them as
identical.
A protected operation may require renewed authorization or a narrower
supported transformation rule.
M-1.5.7 — Future Application
The same effect-descriptor interface may be used by newly introduced
autonomous tools or hardware interfaces without treating every new
tool name as a distinct unrestricted authority domain.
M-1.6 — DYNAMIC TOOL DISCOVERY AND ACTION-CONTRACT CONTINUITY
M-1.6.1 — Tool Discovery
An autonomous agent may discover a tool, application function, device
command, or remote service at runtime.
The tool may provide descriptive metadata identifying its intended
operation.
Such metadata may originate from a source not trusted to define the
security policy.
M-1.6.2 — Protected Tool Registration
A protected component may evaluate the discovered tool's identity,
declared effect class, supported parameters, destination rules,
current software version, and actual effectuation path.
9.3.3.13. Source page 567 of the original specification
Where sufficient evidence exists, the tool may be associated with a
protected DAC-M.
M-1.6.3 — Action-Contract Content
A DAC-M may describe the permitted operation and its material side
effects.
For example, a function named "generate report" might also transmit
the report to an external destination.
The protected contract should reflect relevant actual effects rather
than assume that the tool name fully describes them.
Das Expires 29 April 2027 [Page 121]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-1.6.4 — Contract Version Commitment
An ACVC may bind the Candidate Act to the action-contract version
under which the operation was authorized.
The sink may verify that the actual function continues to satisfy the
required semantics.
M-1.6.5 — Contract Compatibility
A later contract version may be considered compatible only where the
relevant authorized effect remains within the protected equivalence
or attenuation rules.
Changing internal implementation details may be acceptable.
Adding a new external data transmission may not be acceptable without
separate authorization.
M-1.6.6 — Contract Downgrade and Rollback
A malicious system may attempt to present an older contract version
while executing newer behavior.
The sink may require an authenticated current contract reference and
reject incompatible version combinations.
M-1.6.7 — Tool Removal
Revocation or removal of a tool may invalidate corresponding
unconsumed operation authority.
The actual sink checks the applicable current contract and authority
state before effectuation.
M-1.6.8 — Proposed Technical Contribution
The candidate distinguishing mechanism concerns binding protected
finality authority to verified operation semantics and requiring
current contract correspondence at the consequential boundary.
A conventional version number or tool registry alone does not
establish this enforcement relationship.
M-1.7 — CROSS-INTERFACE RESOURCE IDENTITY AND ALIAS RESOLUTION
Das Expires 29 April 2027 [Page 122]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.3.3.14. Source page 568 of the original specification
M-1.7.1 — Resource Aliases
An underlying resource may have multiple identifiers.
A document may possess a filesystem path, content identifier,
application object identifier, synchronization reference, and remote
storage address.
These identifiers may change independently.
M-1.7.2 — Protected Resolution
A protected resolver may establish the relevant identity relationship
using authenticated storage metadata, controller state, version
information, or other qualified evidence.
The resulting SRIC binds the authorized resource to the resolved
target.
M-1.7.3 — Version-Specific Identity
A resource may preserve its logical identifier while its content
changes.
The system may therefore bind authority to a particular resource
version or content commitment where necessary.
M-1.7.4 — Resource Rebinding
A file path may point to a different object after authorization.
An application identifier may be reassigned.
The sink may require current resource correspondence rather than
relying exclusively on the original path string.
M-1.7.5 — Cross-Application Equivalence
The resolver may identify resources exposed through multiple
applications.
An authorization for one document does not automatically authorize
all documents within an application.
M-1.7.6 — Protected Failure Behavior
Das Expires 29 April 2027 [Page 123]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
If the resolver cannot establish the required correspondence, the
operation remains withheld or requires renewed authorization.
M-1.7.7 — Relation to Embodiment 3
Embodiment 3 provides more specialized treatment of user-observed
referents and actual effectuation targets.
The present section focuses on cross-interface resource identity
within dynamically changing software and infrastructure environments.
9.3.3.15. Source page 569 of the original specification
M-1.8 — PROTECTED DELEGATED AUTHORITY ACROSS AGENTS AND PROVIDERS
M-1.8.1 — General Architecture
An authorized principal may delegate a permitted task to an
autonomous agent.
The agent may delegate a subset of the task to another agent or
service.
The downstream entity may operate under a different administrator or
software provider.
M-1.8.2 — Delegation Attenuation
Each delegation may be required to preserve or narrow the original
authority.
For example, the permitted resource set, destination set, operation
classes, execution duration, and cumulative authority budget may be
constrained.
M-1.8.3 — Representative Authority Relationship
ChildAuthority.Scope SUBSET_OF ParentAuthority.Scope
ChildAuthority.EffectBudget NOT_GREATER_THAN ParentAvailableBudget
ChildAuthority.Validity WITHIN ParentAuthority.Validity These
relations are conceptual.
The actual implementation may use typed resource sets, authenticated
capability restrictions, policy expressions, or equivalent formal
constraints.
Das Expires 29 April 2027 [Page 124]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-1.8.4 — Delegation Chain
A DAAC may bind each delegation to its predecessor.
The chain may contain authenticated delegator identity, delegate
identity, permitted scope, authority epoch, resource constraints, and
revocation references.
M-1.8.5 — Final Sink Verification
The destination-side Finality Sink verifies that the actual requested
effect remains within the valid delegation lineage.
An upstream agent cannot create unrestricted authority merely by
designating a downstream agent as trusted.
M-1.8.6 — Delegation Through Multiple Providers
9.3.3.16. Source page 570 of the original specification
An implementation may use authenticated cross-domain messages and
locally verifiable authority commitments.
Each provider may retain independent authority and security
requirements.
M-1.8.7 — Delegation Revocation
Revocation may invalidate unconsumed downstream authority.
An already completed consequential effect is not automatically
reversed.
M-1.8.8 — Dynamic Delegation Topology
The system may support a changing delegation graph.
A newly introduced delegate must satisfy current protected identity
and authority checks.
M-1.8.9 — Candidate Technical Contribution
The proposed specific combination concerns attenuation of
consequential authority across dynamic autonomous-agent delegation,
with actual sink-time verification of the resulting operation and
protected lineage.
M-1.9 — PROTECTED CREDENTIAL-RELEASE FINALITY
Das Expires 29 April 2027 [Page 125]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-1.9.1 — Credential Custody
A protected credential broker may retain reusable credentials outside
the ordinary agent execution environment.
The agent may submit a Candidate Act requesting a specific permitted
external operation.
M-1.9.2 — Operation-Bound Credential Use
The broker verifies the Candidate Act and applicable finality
authorization.
It may construct or authenticate the actual outgoing operation and
use the credential without exposing the reusable secret to the agent.
M-1.9.3 — Credential Activation Rather Than Transfer
In an alternative implementation, the reusable credential remains
sealed.
A protected controller activates the credential only for a
specifically authorized command.
The requesting agent does not acquire unrestricted independent
ability to use it.
M-1.9.4 — Actual Request Binding
The broker may verify destination, method, resource, body commitment,
operation class, and current protected state.
9.3.3.17. Source page 571 of the original specification
Where the actual request differs materially from the authorized
Candidate Act, credential exercise is refused.
M-1.9.5 — Credential Rotation
The broker may rotate credentials without changing the authorized
operation semantics.
The finality binding remains associated with the permitted effect
rather than one permanent credential string.
M-1.9.6 — Remote Credential Use
Das Expires 29 April 2027 [Page 126]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A remote protected broker may exercise credentials in another
administrative domain.
The local or remote Finality Sink verifies the applicable scoped
authority.
M-1.9.7 — Bypass Qualification
Credential custody does not prevent unauthorized operations if
another unrestricted credential or effectuation path remains
available to the agent.
The claimed protection therefore depends upon the actual credential
and effectuation coverage.
M-1.10 — PROTECTED PRIVACY-EXPOSURE COMPOSITION
M-1.10.1 — Cumulative Disclosure Problem
An agent may make several individually permitted disclosures.
The combined information may reveal more than the protected
authorization permits.
For example, several responses may disclose overlapping fields from a
sensitive record.
M-1.10.2 — Protected Privacy State
A PECS-M may represent relevant prior disclosures, disclosed
attributes, recipient domains, scope, and applicable privacy
constraints.
M-1.10.3 — Incremental Exposure Evaluation
Before a new disclosure, the protected system evaluates how the
proposed effect changes the relevant cumulative exposure state.
The calculation may consider repeated recipients, overlapping
attributes, time windows, and known correlations.
M-1.10.4 — Context-Dependent Risk
The system may distinguish disclosure to a previously authorized
recipient from disclosure to a new recipient.
It may also distinguish exact raw information from appropriately
protected derived information.
Das Expires 29 April 2027 [Page 127]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.3.3.18. Source page 572 of the original specification
The corresponding exposure model must be expressly defined rather
than assumed universally accurate.
M-1.10.5 — Finality Enforcement
A data-release Finality Sink verifies that the actual outgoing
operation satisfies the applicable current privacy constraints.
A permitted computation does not itself grant authority to disclose
the computed result.
M-1.10.6 — Privacy-Preserving Evidence
The protected verifier may use commitments, selective disclosure, or
suitable cryptographic proofs to evaluate a privacy predicate without
revealing all underlying data to every participant.
The proof system's assurances remain limited by the trustworthiness
of the input data and the predicate actually proved.
M-1.10.7 — Relation to Specialized Embodiments
More detailed privacy composition, cumulative leakage, and query
reconstruction mechanisms may be developed within their respective
specialized embodiments.
The present section establishes an optional integration pattern with
protected finality enforcement.
M-1.11 — MULTI-PRINCIPAL AND RESOURCE-PARITY GOVERNANCE
M-1.11.1 — Multiple Principals
A consequential operation may affect resources governed by several
principals.
For example, a shared device resource may require authority from both
an enterprise controller and the affected resource owner.
M-1.11.2 — Protected Authority Composition
The system may require authenticated evidence satisfying each
applicable principal's authorization conditions.
An approval from one principal does not necessarily override another
mandatory constraint.
Das Expires 29 April 2027 [Page 128]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-1.11.3 — Protected Resource Allocation
Several autonomous agents may compete for processor, network,
storage, device, or transaction resources.
A protected allocation module may evaluate the requests under a
specified allocation policy.
M-1.11.4 — Comparable-Workload Evidence
Where fairness or parity is required, the system may identify which
workloads are meaningfully comparable under the protected policy.
9.3.3.19. Source page 573 of the original specification
The definition of comparability may consider resource class, workload
priority, technical requirements, authorized principal, and relevant
service conditions.
M-1.11.5 — Verifiable Decision Evidence
A protected allocation record may identify the evaluated workload
attributes, applicable rule, allocation state, and resulting
decision.
The record may be authenticated without revealing unrelated private
workload data.
M-1.11.6 — Finality-Bound Allocation
A protected scheduling or resource controller may refuse resource
activation that lacks valid allocation authority.
Thus, the allocation decision may be enforced as a resource
effectuation condition rather than remaining an advisory fairness
score.
M-1.11.7 — Technical Limitation
A cryptographic proof can establish correct evaluation of a specified
allocation rule.
It does not establish that the rule is socially fair, optimal, or
legally sufficient merely because its calculation is verifiable.
M-1.12 — PROTECTED LOCAL, EDGE, AND CLOUD EXECUTION-ROUTE CONTINUITY
M-1.12.1 — Route Selection
Das Expires 29 April 2027 [Page 129]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
An autonomous task may be executed locally, at an edge node, or
within a remote computing service.
A route selection may be based upon latency, privacy, resource
availability, computation cost, or other technical constraints.
M-1.12.2 — Authority Preservation
Moving computation between execution environments does not
automatically transfer unrestricted authority over external effects.
Each consequential operation remains subject to the applicable
protected finality requirements.
M-1.12.3 — Route Equivalence
An ERER may specify which operation semantics, resource identities,
protected outputs, and permitted effects are preserved across
alternative routes.
M-1.12.4 — Route-Specific Evidence
The system may require different evidence depending upon the selected
execution environment.
9.3.3.20. Source page 574 of the original specification
For example, a remote confidential-computing service may provide
authenticated environment evidence, while a local protected process
may rely on a separate device controller.
M-1.12.5 — Model Independence
The finality architecture may remain independent of which model
generated the proposed operation.
A change of model or computation route does not automatically alter
the underlying user-granted authority.
M-1.12.6 — Route-Induced Operation Change
If moving execution changes the actual resource, destination, data
disclosure, or effect semantics, the protected system may require
renewed validation.
M-1.12.7 — Exclusive Migration
Das Expires 29 April 2027 [Page 130]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Where a task's unfinished execution authority must be exclusive,
protected ownership epochs and fencing may prevent the former
execution environment from continuing after migration.
M-1.13 — PROTECTED VERIFICATION WORK BUDGETS
M-1.13.1 — Technical Problem
A malicious or malfunctioning agent may submit verification requests
that consume excessive protected resources.
Examples include large proof objects, deeply nested data, expensive
cryptographic checks, or repeated policy evaluation.
M-1.13.2 — Bounded Verification Resources
A PVWB may specify maximum input size, computational work, memory,
time, or energy for a validation class.
M-1.13.3 — Protected Budget Allocation
The protected controller may reserve validation capacity for selected
operation classes.
The allocation may consider deadlines, safety relevance, resource
availability, and current protected policy.
M-1.13.4 — Verification Exhaustion
Where a request exceeds a mandatory verification budget, the system
may reject, defer, split, or use another approved bounded
verification procedure.
The system does not treat verification exhaustion as permission.
M-1.13.5 — Cryptographic Work Limits
9.3.3.21. Source page 575 of the original specification
The verifier may constrain supported signature schemes, proof sizes,
certificate-chain depths, parsing operations, and other
computationally expensive inputs.
M-1.13.6 — Real-Time Consequential Operations
A real-time controller may require bounded verification latency.
Das Expires 29 April 2027 [Page 131]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The protected system may use prevalidated evidence, limited-scope
capabilities, or hardware-assisted checking while preserving
mandatory current-state constraints.
M-1.13.7 — Thermal and Power Limits
An embedded device may have limited thermal or energy capacity.
The verification controller may reserve protected resources or
restrict nonessential work to preserve the ability to evaluate
critical effects.
M-1.13.8 — Proposed Technical Contribution
The additional technical relationship concerns enforcing
authorization correctness under bounded computational resources
rather than bypassing protected validation when resources become
scarce.
M-1.14 — UPDATE-TIME ENFORCEMENT COVERAGE REATTESTATION
M-1.14.1 — Triggering Events
Reattestation may be triggered by:
A new software version;
A firmware update;
A changed application interface;
A new tool registration;
A driver modification;
A hardware peripheral change;
A changed runtime configuration;
A new communication route;
A controller replacement;
Or another event capable of altering the relevant effectuation path.
M-1.14.2 — Protected Update Epoch
Das Expires 29 April 2027 [Page 132]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The system may increment an OCE when a relevant execution or
enforcement configuration changes.
9.3.3.22. Source page 576 of the original specification
An authority bound to an earlier epoch may require revalidation.
M-1.14.3 — Coverage Reassessment
The protected controller determines whether the updated environment
still routes the relevant consequential operations through the
mandatory Finality Sink.
M-1.14.4 — Action Contract Revalidation
The system may verify whether previously authorized operation
semantics remain valid.
M-1.14.5 — Authority Invalidation
Where the update materially changes a required effectuation
predicate, unconsumed authority may be invalidated, suspended, or
restricted.
M-1.14.6 — Secure Recovery
Following successful reattestation, the system may restore approved
operations under current authority.
M-1.14.7 — Rollback Resistance
An attacker may attempt to restore an earlier configuration with
weaker controls.
Protected epochs and trusted configuration evidence may prevent
unsupported acceptance of the older state.
M-1.14.8 — Candidate Technical Contribution
The potentially distinguishing mechanism is a mandatory linkage
between current enforcement-coverage validity, action-contract
continuity, and finality authority.
M-1.15 — HARDWARE ACCELERATOR AND DIRECT EFFECTUATION CONTROL
M-1.15.1 — General Applicability
Das Expires 29 April 2027 [Page 133]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
An accelerator or peripheral controller may produce consequential
effects without using an ordinary application API.
Such effects may include direct memory access, network transmission,
persistent storage modification, protected media release, hardware
command dispatch, or access to another device.
M-1.15.2 — Accelerator Candidate Act
An accelerator operation may be represented as a Candidate Act
identifying the permitted command class, resource region,
destination, output, memory target, or device effect.
M-1.15.3 — Protected Command Descriptor
9.3.3.23. Source page 577 of the original specification
The system may bind authority to a protected command buffer,
descriptor generation, device queue, or equivalent operation
representation.
M-1.15.4 — Accelerator Egress Boundary
A protected controller may govern accelerator-originated output or
effect-capable commands.
The controller verifies the relevant authority before the actual
consequential release.
M-1.15.5 — Memory and Device Access
Where direct-memory-access operations can produce protected effects,
the relevant address ranges, ownership, and access permissions may be
enforced through an appropriate protected hardware mechanism.
M-1.15.6 — Command Mutation
A command descriptor may change after authorization.
The controller may verify the actual command at dispatch or protect
the command buffer against unauthorized modification.
M-1.15.7 — Hardware Identity
An effect-capable accelerator may possess an authenticated device
identity or registered controller reference.
The sink checks the applicable authority and hardware trust state.
Das Expires 29 April 2027 [Page 134]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-1.15.8 — Future Hardware Variants
The architecture may be adapted to newly developed processors, neural
accelerators, programmable network controllers, storage processors,
chiplet-based systems, and other heterogeneous execution substrates.
M-1.15.9 — Limitation
A host-level software gate does not automatically control a
peripheral's direct effectuation path.
The implementation must identify and enforce the relevant actual
hardware boundary.
M-1.16 — CONFIDENTIAL COMPUTING AND PROTECTED OUTPUT FINALITY
Confidential computing may protect selected computations and data
within an isolated environment.
The present architecture may additionally require that an output
generated within the protected environment receive valid effectuation
authority before causing an external consequence.
A protected computation may therefore produce a Candidate Act rather
than directly exercising an unrestricted external credential.
9.3.3.24. Source page 578 of the original specification
The receiving Finality Sink may verify operation scope, current
protected authority, and actual output parameters.
Remote attestation may contribute evidence concerning the identity or
configuration of the computing environment.
However, attestation of the environment does not automatically prove
that every proposed external act is authorized.
The protected output may require separate finality authorization.
An optional implementation may bind the authority to a measured
software configuration or operation-contract version.
Where the environment changes, the applicable authority may require
renewed verification.
M-1.17 — FUTURE COMMUNICATION-NETWORK EFFECTUATION
M-1.17.1 — Autonomous Network Control
Das Expires 29 April 2027 [Page 135]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A communication network may employ autonomous components to modify
routing, radio parameters, service access, resource scheduling,
network functions, or traffic management.
M-1.17.2 — Network Candidate Acts
An operation may identify the target controller, resource allocation,
command class, destination network function, and permitted state
transition.
M-1.17.3 — Distributed Control Boundaries
Different network components may operate under separate protected
authorities.
Each actual consequential controller may verify the applicable
operation-specific authorization.
M-1.17.4 — Protected Spectrum and Radio Effects
Where a radio configuration change is security-relevant, the
protected controller may verify frequency, power, resource
allocation, device identity, and other applicable parameters.
M-1.17.5 — Network Function Updates
An autonomous agent may request activation or replacement of a
network function.
The protected system may bind authority to the actual software and
configuration state.
M-1.17.6 — Edge Processing
A task may move among edge and cloud execution environments while its
authority remains scoped to the original permitted consequence.
M-1.17.7 — Future Standards Independence
9.3.3.25. Source page 579 of the original specification
The invention is not restricted to a particular generation of
wireless communication technology or network management protocol.
The relevant technical principle concerns controlled consequential
state changes at authenticated network effectuation boundaries.
M-1.18 — PHYSICAL SCENE, ROBOTICS, AND SPATIAL-COMPUTING VARIANTS
Das Expires 29 April 2027 [Page 136]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A physical autonomous system may receive a user instruction referring
to an object, location, or device.
The system may identify the target through camera observations,
spatial coordinates, device identifiers, or other sensor data.
The protected system may bind the authorized effect to an
authenticated target identity and current operating envelope.
The actual actuator Finality Sink verifies the pending physical
command.
Where target identity may change, the controller may require
revalidation using current protected sensor evidence.
In an extended-reality implementation, a virtual object selected by a
user may correspond to a physical or remote resource.
The protected system may verify that the selected referent maps to
the actual affected resource.
The detailed semantic correspondence mechanisms may follow Embodiment
3.
The present miscellaneous implementation additionally allows the
effectuation boundary to reside within a physical actuator
controller, remote device, protected robot subsystem, or future
spatial-computing interface.
Where physical movements occur in several dependent phases, the
receipt-gated causal continuation mechanism of CW-2 may be employed.
M-1.19 — INTERMITTENT CONNECTIVITY AND BOUNDED OFFLINE AUTHORITY
M-1.19.1 — Offline Operation
A device may lose contact with its central authorization service.
The system may permit selected bounded operations under previously
provisioned authority.
M-1.19.2 — Offline Scope
Offline authority may specify operation classes, resource bounds,
consumption limits, time conditions, or protected counters.
M-1.19.3 — Local Finality Sink
Das Expires 29 April 2027 [Page 137]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.3.3.26. Source page 580 of the original specification
The local controller verifies the offline authority against the
actual operation.
M-1.19.4 — Protected Consumption
A local monotonic counter or equivalent protected state may prevent
unauthorized repeated use.
M-1.19.5 — Delayed Revocation
Immediate remote revocation cannot be guaranteed while the device
lacks an authenticated communication path unless another local
expiration or control mechanism enforces the required limit.
M-1.19.6 — Reconnection
Following reconnection, the system may reconcile consumed authority
and actual-effect state.
M-1.19.7 — Unknown Remote Outcome
A remote operation attempted during intermittent connectivity may
have an unknown result.
The system does not assume failure merely because acknowledgement was
unavailable.
M-1.19.8 — Industrial Relevance
Such mechanisms may support edge devices, remote machinery, mobile
systems, and intermittently connected infrastructure.
M-1.20 — FUTURE AUTONOMOUS MACHINE-TO-MACHINE ECONOMIC OPERATIONS
An autonomous device may request resources, services, access rights,
or financial transactions from another device or service.
A protected Candidate Act may identify the actual economic
consequence, resource, destination, amount, and permitted transaction
class.
The relevant Finality Sink verifies current authority before
submitting the consequential instruction.
An authenticated remote outcome may later be required for a dependent
effect.
Das Expires 29 April 2027 [Page 138]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Where the workflow requires phased progression, an authorized
cryptographically identified IEV may accept the actual-effect receipt
under CW-2.
The accepted receipt may become a necessary enabling factor for the
next financial or resource operation.
A transaction receipt concerning authorization, submission, or
settlement must be classified according to what it actually
establishes.
The embodiment does not presume that all financial operations are
reversible or globally atomic.
9.3.3.27. Source page 581 of the original specification
M-1.21 — ADVANCED CRYPTOGRAPHIC AND PRIVACY-PRESERVING VARIANTS
M-1.21.1 — Algorithm Agility
Protected authority records may contain cryptographic algorithm
identifiers and credential-generation references.
The system may support migration to alternative authenticated
algorithms without changing the protected operation semantics.
M-1.21.2 — Post-Quantum Migration
An implementation may adopt appropriate post-quantum cryptographic
primitives when supported by applicable requirements.
Such primitives do not independently establish novelty of the
execution-finality architecture.
M-1.21.3 — Selective Disclosure
A verifier may receive only those attributes needed to establish an
authorization predicate.
M-1.21.4 — Proofs of Protected Resource State
An authenticated proof may establish that a resource state satisfies
a specified condition.
The actual trustworthiness of the source state remains necessary.
M-1.21.5 — Privacy-Preserving Delegation Evidence
Das Expires 29 April 2027 [Page 139]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A delegated agent may prove possession of an appropriately limited
authority without disclosing unnecessary private attributes.
M-1.21.6 — Protected Identity Rotation
Validator, sink, and device identities may support authenticated
credential rotation.
M-1.21.7 — Cryptography-Independent Actual Enforcement
A system may use cryptography to authenticate identities while
enforcing the final effect through protected hardware or controller
state.
The actual effectuation gate need not be realized exclusively through
cryptographic key release.
M-1.22 — OPTIONAL COMBINED TECHNICAL ARRANGEMENTS
M-1.22.1 — Dynamic Tool Contract Plus Enforcement Coverage
A newly discovered tool may be registered with an authenticated
action contract.
The protected system determines its actual effectuation surfaces.
9.3.3.28. Source page 582 of the original specification
Finality authority is permitted only when the relevant current
contract and coverage predicates are satisfied.
M-1.22.2 — Cross-Interface Identity Plus Credential Release
An application requests an operation involving a resource identified
by one alias.
A protected resolver establishes the actual target identity.
A credential broker exercises the required credential only for the
matching actual operation.
M-1.22.3 — Delegation Plus Destination-Side Verification
A parent agent delegates a bounded operation to a remote agent.
The remote Finality Sink verifies the authenticated delegation chain
and actual requested effect.
Das Expires 29 April 2027 [Page 140]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-1.22.4 — Privacy Composition Plus Data Release
A protected privacy state tracks relevant cumulative disclosure.
The external data-release sink checks that the actual outgoing object
and destination satisfy current privacy constraints.
M-1.22.5 — Accelerator Egress Plus Enforcement Coverage
A protected authority record identifies an accelerator-originated
effect.
The hardware controller verifies the actual command.
A coverage commitment establishes that the corresponding device path
is mediated.
M-1.22.6 — Software Update Plus Contract Revalidation
An application update changes an effect-capable function.
The protected system advances the applicable environment epoch.
Unconsumed authority bound to incompatible earlier semantics is
invalidated.
M-1.22.7 — Cross-Device Delegation Plus Exclusive Authority
Authority moves to another device.
The prior device's protected ownership epoch becomes stale.
The new device's Finality Sink verifies exclusive authority before
effectuation.
M-1.22.8 — Causal Receipt Plus Distributed Authority
An earlier real effect occurs in one domain.
An authorized IEV accepts the corresponding qualified evidence.
9.3.3.29. Source page 583 of the original specification
The validated receipt is made available to a successor Finality Sink
in another domain.
The next effect requires that receipt-derived authority under CW-2.
Das Expires 29 April 2027 [Page 141]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-1.22.9 — Verification Budget Plus Safety-Critical Deadline
A protected controller reserves bounded verification resources for a
consequential operation.
Where the required predicates cannot be completed within the safe
operating window, the controller applies the specified protected
failure response instead of treating incomplete verification as
permission.
M-1.22.10 — Multi-Principal Authority Plus Protected Resource
Allocation
A consequential resource-allocation operation may require approval
from several principals and verification of the current allocation
state.
The actual allocation controller enforces both predicates.
M-1.23 — REFERENCE PSEUDOCODE: SURFACE REGISTRATION
FUNCTION REGISTER_EFFECTUATION_SURFACE( proposed_interface,
declared_effect_classes, protected_registry ):
REQUIRE VERIFY_INTERFACE_IDENTITY( proposed_interface )
REQUIRE VERIFY_INTERFACE_SECURITY_CONFIGURATION( proposed_interface )
contracts = VALIDATE_EFFECT_CONTRACTS( proposed_interface,
declared_effect_classes )
IF contracts IS INVALID: RETURN UNREGISTERED
coverage = VERIFY_MANDATORY_SINK_ASSOCIATION( proposed_interface,
contracts )
IF coverage != VERIFIED: RETURN RESTRICT_EFFECTUATION
9.3.3.30. Source page 584 of the original specification
record = protected_registry.ATOMIC_REGISTER({ interface_identity:
proposed_interface.identifier,
contract_commitment: HASH(contracts),
enforcement_sink: coverage.sink_identity,
environment_epoch: CURRENT_ENVIRONMENT_EPOCH(),
Das Expires 29 April 2027 [Page 142]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
authorized_effect_classes: contracts.effect_classes })
RETURN record
M-1.24 — REFERENCE PSEUDOCODE: DYNAMIC ACTION-CONTRACT VALIDATION
FUNCTION VALIDATE_DYNAMIC_ACTION( candidate_act, actual_operation,
current_action_contract ):
REQUIRE VERIFY_ACTION_CONTRACT_AUTHENTICITY( current_action_contract
)
REQUIRE VERIFY_CURRENT_CONTRACT_EPOCH( current_action_contract )
normalized_effect = NORMALIZE_ACTUAL_EFFECT( actual_operation,
current_action_contract )
IF normalized_effect IS AMBIGUOUS: RETURN DENY_OR_REAUTHORIZE
REQUIRE VERIFY_AUTHORIZED_EFFECT_SEMANTICS( candidate_act,
normalized_effect )
REQUIRE VERIFY_RESOURCE_IDENTITY( candidate_act,
9.3.3.31. Source page 585 of the original specification
normalized_effect )
REQUIRE VERIFY_REQUIRED_FINALITY_SINK( actual_operation )
RETURN PASS
M-1.25 — REFERENCE PSEUDOCODE: ATTENUATED DELEGATION
FUNCTION PREPARE_DELEGATED_AUTHORITY( parent_authority,
child_request, delegate_identity ):
REQUIRE VERIFY_PARENT_AUTHORITY( parent_authority )
REQUIRE VERIFY_DELEGATE_IDENTITY( delegate_identity )
REQUIRE CHILD_SCOPE_WITHIN_PARENT( child_request, parent_authority )
REQUIRE CHILD_BUDGET_WITHIN_PARENT( child_request, parent_authority )
REQUIRE VERIFY_CURRENT_AUTHORITY_EPOCH()
Das Expires 29 April 2027 [Page 143]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
delegated = PED.ATOMIC_PREPARE_DELEGATION({ parent:
HASH(parent_authority),
delegate: delegate_identity,
child_scope: child_request.scope,
child_budget: child_request.budget,
destination_sink:
9.3.3.32. Source page 586 of the original specification
child_request.sink_id,
authority_epoch: CURRENT_AUTHORITY_EPOCH() })
RETURN delegated The destination sink independently verifies the
resulting authority against the actual operation.
M-1.26 — REFERENCE PSEUDOCODE: EFFECTUATION-COVERAGE VERIFICATION
FUNCTION VERIFY_EFFECTUATION_COVERAGE( candidate_act,
actual_operation, protected_surface_registry ):
normalized_effect = RESOLVE_CONSEQUENCE_CLASS(actual_operation)
required_surfaces = protected_surface_registry.RESOLVE_PATHS(
normalized_effect )
IF required_surfaces IS UNKNOWN: RETURN COVERAGE_UNVERIFIED
FOR EACH surface IN required_surfaces:
IF NOT VERIFY_CURRENT_SURFACE_IDENTITY(surface): RETURN
COVERAGE_UNVERIFIED
IF NOT VERIFY_MANDATORY_FINALITY_CONTROL(surface): RETURN
COVERAGE_UNVERIFIED
IF NOT VERIFY_CURRENT_CONFIGURATION(surface): RETURN
COVERAGE_UNVERIFIED
commitment = PROTECTED_COMMIT({ effect_class: normalized_effect,
covered_surfaces: HASH_CANONICAL(required_surfaces),
operation: HASH(actual_operation),
Das Expires 29 April 2027 [Page 144]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
environment_epoch: CURRENT_ENVIRONMENT_EPOCH()
9.3.3.33. Source page 587 of the original specification
RETURN commitment The completeness guarantee is limited to the
effectuation paths that the registry and underlying discovery
mechanism can reliably identify.
M-1.27 — REFERENCE PSEUDOCODE: PROTECTED FINALITY WITH OPTIONAL
MODULES
FUNCTION EFFECTUATE_WITH_MISCELLANEOUS_MODULES( candidate_act,
finality_sink, protected_policy ):
actual_operation = finality_sink.RECONSTRUCT_PENDING_OPERATION()
REQUIRE VERIFY_ACTUAL_OPERATION( candidate_act, actual_operation )
required_modules = RESOLVE_MANDATORY_MODULES( candidate_act,
protected_policy )
IF "COVERAGE" IN required_modules:
REQUIRE VERIFY_EFFECTUATION_COVERAGE( candidate_act,
actual_operation, PROTECTED_SURFACE_REGISTRY )
IF "ACTION_CONTRACT" IN required_modules:
REQUIRE VALIDATE_DYNAMIC_ACTION( candidate_act, actual_operation,
CURRENT_ACTION_CONTRACT )
IF "DELEGATION" IN required_modules:
REQUIRE VERIFY_ATTENUATED_AUTHORITY_CHAIN( candidate_act,
actual_operation )
9.3.3.34. Source page 588 of the original specification
IF "PRIVACY" IN required_modules:
REQUIRE VERIFY_CUMULATIVE_PRIVACY_STATE( actual_operation )
IF "RESOURCE_BUDGET" IN required_modules:
REQUIRE VERIFY_RESOURCE_ALLOCATION_STATE( actual_operation )
IF "ENVIRONMENT" IN required_modules:
Das Expires 29 April 2027 [Page 145]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
REQUIRE VERIFY_CURRENT_ENVIRONMENT_EPOCH( actual_operation )
IF "CAUSAL_RECEIPT" IN required_modules:
REQUIRE VERIFY_AUTHORIZED_IEV_RECEIPT( actual_operation )
REQUIRE finality_sink.VERIFY_SCOPED_AUTHORITY( candidate_act,
actual_operation )
consumption = finality_sink.ATOMIC_CONSUME( candidate_act,
actual_operation )
IF consumption != SUCCESS: RETURN DENY
RETURN finality_sink.EFFECTUATE( actual_operation, consumption ) The
module set is determined by protected authority rather than by the
untrusted requesting entity.
M-1.28 — REFERENCE PSEUDOCODE: POST-UPDATE REATTESTATION
FUNCTION REATTEST_AFTER_ENVIRONMENT_CHANGE( update_event,
protected_controller ):
9.3.3.35. Source page 589 of the original specification
REQUIRE VERIFY_UPDATE_EVENT( update_event )
new_epoch = protected_controller.ADVANCE_ENVIRONMENT_EPOCH()
discovered_surfaces = DISCOVER_CURRENT_EFFECTUATION_SURFACES()
verified_contracts = VERIFY_CURRENT_ACTION_CONTRACTS()
coverage = VERIFY_REQUIRED_ENFORCEMENT_PATHS( discovered_surfaces,
verified_contracts )
IF coverage != VERIFIED:
protected_controller.RESTRICT_AFFECTED_EFFECTS(
update_event.affected_effect_classes )
RETURN REATTESTATION_FAILED
commitment = protected_controller.ATOMIC_COMMIT({ environment_epoch:
new_epoch,
surface_commitment: HASH_CANONICAL(discovered_surfaces),
Das Expires 29 April 2027 [Page 146]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
contract_commitment: HASH_CANONICAL(verified_contracts),
valid_coverage: TRUE })
RETURN commitment
M-1.29 — WORKED EXAMPLE A: NEWLY DISCOVERED ENTERPRISE TOOL
An enterprise autonomous agent is authorized to prepare and store an
internal report.
During execution, the agent discovers a newly available tool
described as a document-management utility.
The new tool supports both local report formatting and remote
sharing.
9.3.3.36. Source page 590 of the original specification
A conventional orchestration system may expose the entire tool
interface once the tool has been registered.
Under the present embodiment, the protected tool-discovery module
identifies the tool's consequential operation classes.
It establishes a DAC-M identifying which functions merely transform
data and which can transmit data externally.
The protected effectuation-surface registry associates the external-
sharing function with a designated network or application Finality
Sink.
The agent may continue performing permitted local formatting.
However, a proposed external transmission becomes a separate
Candidate Act.
The protected system verifies the intended document, destination,
current task authority, action contract, and actual outgoing request.
The final sink refuses a transmission not covered by valid authority.
If a later software update adds a new external transmission
interface, the enforcement-coverage mechanism may require
reattestation before that effect is permitted.
Das Expires 29 April 2027 [Page 147]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The technical distinction is the protected connection between dynamic
tool semantics, effectuation-surface discovery, and actual finality
enforcement.
M-1.30 — WORKED EXAMPLE B: CROSS-PROVIDER AUTONOMOUS DELEGATION
An autonomous agent is authorized to modify a defined group of cloud
resources.
The agent delegates a narrow diagnostic task to another autonomous
service.
The second service operates under a different administrative
provider.
The parent authority permits diagnostics but does not permit deletion
of resources.
A DAAC binds the delegated task to the original limited scope.
The downstream service may compute diagnostic recommendations.
If it proposes a consequential resource change, the receiving
protected controller constructs a Candidate Act and verifies the
delegation lineage.
The destination Finality Sink checks the actual resource operation.
An attempted deletion is rejected because it exceeds the delegated
scope.
The protected system does not rely merely upon the downstream agent's
declaration that its request is part of the original diagnostic task.
The technical distinction is the preservation of enforceable
authority attenuation across independently administered autonomous
systems.
9.3.3.37. Source page 591 of the original specification
M-1.31 — WORKED EXAMPLE C: HARDWARE ACCELERATOR DIRECT EFFECT
An autonomous computing application processes information using a
hardware accelerator.
The accelerator may also initiate direct memory operations or produce
data through an output interface.
Das Expires 29 April 2027 [Page 148]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The protected system identifies the effect-capable accelerator
pathways relevant to the requested operation.
A PNED describes the permitted consequential effect.
An authenticated command descriptor binds the actual accelerator
operation to the protected authorization.
Before the accelerator releases the governed external effect, an
appropriate protected hardware or device controller verifies the
required authority.
If the accelerator command is materially changed after validation,
the controller refuses or invalidates the operation according to the
implemented command-integrity mechanism.
Where the accelerator possesses a direct effectuation path outside
the relevant controller, the asserted enforcement coverage must be
extended or qualified.
This example demonstrates that protected execution finality is not
limited to ordinary CPU-mediated application tool calls.
M-1.32 — WORKED EXAMPLE D: SOFTWARE UPDATE CREATES A NEW BYPASS PATH
A protected application originally performs external transmissions
through one controlled dispatcher.
The security architecture verifies outbound operations at that
dispatcher.
A later software update introduces an additional transmission
mechanism.
Without coverage revalidation, the new mechanism might permit an
operation to bypass the original Finality Sink.
Under the present embodiment, the update advances the protected
environment epoch.
The system determines whether the new interface can produce the same
protected consequential effect.
Where the new interface is not yet covered, relevant finality
authority is restricted.
The updated interface may be registered with an appropriate mandatory
sink.
Das Expires 29 April 2027 [Page 149]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Once the new enforcement configuration is verified, permitted
operations may resume under current protected authority.
9.3.3.38. Source page 592 of the original specification
The technical distinction is the use of enforcement-coverage
continuity as an authorization predicate following environment
changes.
M-1.33 — WORKED EXAMPLE E: AUTONOMOUS PHONE SENSOR DISCLOSURE
An autonomous assistant operating on a mobile device is authorized to
analyze selected local sensor data.
The user has not authorized unrestricted external disclosure.
The assistant may perform computation over the sensor data.
A proposed external transmission becomes a separate consequential
Candidate Act.
A privacy module evaluates the destination and cumulative exposure
state.
A protected device gateway verifies the actual outgoing data and
applicable authority.
The assistant may select a local or remote model for computation, but
switching model route does not automatically authorize additional
private-data disclosure.
If the remote route requires new data transmission, that effect
receives separate protected validation.
A device security controller may maintain the required authority and
exposure state.
This example illustrates the distinction between permission to
compute and permission to disclose.
M-1.34 — WORKED EXAMPLE F: MULTI-DEVICE AUTONOMOUS CONTINUITY
An autonomous workflow starts on one device and later transfers to
another device.
The unfinished task has a protected authority scope.
A migration controller establishes a new ownership epoch.
Das Expires 29 April 2027 [Page 150]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The former device's execution authority is fenced where exclusivity
is required.
The second device receives an authenticated attenuated authority
reference.
The second device's Finality Sink verifies the current ownership
epoch and actual operation.
If the successor operation also depends upon an earlier real effect,
a validator-accepted receipt may be required under CW-2.
The receiving sink verifies both the ownership state and causal
receipt.
A stale command from the original device is rejected.
The arrangement preserves protected authority across device migration
without treating the copied computational task state as unrestricted
execution permission.
9.3.3.39. Source page 593 of the original specification
M-1.35 — WORKED EXAMPLE G: VERIFICATION UNDER RESOURCE PRESSURE
A protected industrial controller receives many operation requests.
Some requests contain malformed or excessive evidence objects.
A verification component has limited memory and processing capacity.
The protected system allocates work budgets according to defined
operation classes.
Requests exceeding their permitted validation budget may be rejected
or deferred.
A safety-relevant operation may receive reserved verification
capacity.
The controller does not authorize a consequential operation merely
because a deadline expires or verification resources are exhausted.
Where the required safe behavior is to withhold an actuator command,
the protected controller enforces that result.
Das Expires 29 April 2027 [Page 151]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The technical distinction is the preservation of mandatory finality
predicates under bounded computation and adversarial verification
load.
M-1.36 — ADVERSARIAL THREAT MODEL
M-1.36.1 — Unregistered Tool Introduction
An attacker introduces an effect-capable tool absent from the
protected registry.
The system restricts sensitive effectuation until the relevant action
contract and enforcement path are established.
M-1.36.2 — Misleading Tool Description
A malicious tool describes itself as computationally harmless while
performing an external transmission.
The protected system requires actual effect classification or a
trusted enforcement interface rather than accepting the description
as authoritative.
M-1.36.3 — Tool Schema Mutation
An attacker changes the meaning of an operation parameter after
authorization.
The action-contract version and actual operation checks detect
material mismatch.
M-1.36.4 — Resource Alias Substitution
An attacker substitutes another resource under the same apparent
name.
Protected identity resolution and sink-time state checks prevent
unauthorized correspondence.
9.3.3.40. Source page 594 of the original specification
M-1.36.5 — Alternate API Route
An agent invokes another application interface to produce the
governed effect.
The corresponding protected enforcement coverage must include that
route.
Das Expires 29 April 2027 [Page 152]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-1.36.6 — Direct Device Route
An attacker accesses a hardware device through a lower-level
interface.
The effectuation boundary must enforce the required protected
authority where hardware-level non-bypassability is claimed.
M-1.36.7 — Unauthorized Delegation Expansion
A downstream agent attempts to broaden the permitted task.
The destination sink verifies the delegation chain and rejects scope
expansion.
M-1.36.8 — Reusable Credential Theft
An attacker obtains an application credential.
Where the protected effectuation path separately requires operation-
bound authority, credential possession alone is insufficient for the
governed operation.
M-1.36.9 — Confused Credential Broker
An agent requests credential use for a different destination than the
authorized Candidate Act.
The broker verifies the actual request binding.
M-1.36.10 — Privacy Exposure Splitting
An agent divides a sensitive disclosure into multiple individually
small requests.
The protected privacy-state controller evaluates cumulative exposure
under its defined policy.
M-1.36.11 — Resource Budget Evasion
An agent distributes requests across multiple identities to avoid
resource limits.
The protected controller may associate relevant requests with their
authenticated principal or authority lineage.
The effectiveness of the association depends upon the available
identity evidence.
Das Expires 29 April 2027 [Page 153]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-1.36.12 — Validator Flooding
An attacker generates many expensive verification requests.
The protected system enforces bounded validation work and fail-closed
behavior.
9.3.3.41. Source page 595 of the original specification
M-1.36.13 — Verification Deadline Manipulation
An attacker attempts to force an incomplete validation by exhausting
the available time.
The system applies the defined protected failure behavior rather than
assuming success.
M-1.36.14 — Protected State Rollback
An attacker restores an earlier authority or environment epoch.
Protected anti-rollback mechanisms prevent unauthorized reuse where
implemented.
M-1.36.15 — Firmware Update Bypass
An update removes or alters a required enforcement hook.
The reattestation procedure detects incompatible enforcement coverage
where its measurement and discovery assumptions hold.
M-1.36.16 — Malicious Update Rollback
An attacker installs an older configuration with weaker controls.
Protected epoch or configuration-state checks prevent acceptance of
stale authority.
M-1.36.17 — Accelerator Command Mutation
An accelerator command changes between authorization and dispatch.
Protected command-buffer integrity or actual controller-side
verification detects the mismatch.
M-1.36.18 — Unauthorized Direct-Memory Access
Das Expires 29 April 2027 [Page 154]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A peripheral attempts memory or device access outside its permitted
scope.
The applicable protected hardware control enforces the relevant
access boundary.
M-1.36.19 — Cross-Domain Identity Confusion
A remote service presents an authority identifier valid in another
trust domain.
The receiving sink verifies issuer, audience, role, and domain
binding.
M-1.36.20 — Authority Split-Brain
Two devices attempt to exercise the same exclusive unfinished
authority.
Current ownership epochs and sink-local fencing reject stale
ownership.
M-1.36.21 — Offline Authority Overuse
A disconnected device attempts more operations than its preauthorized
offline budget permits.
9.3.3.42. Source page 596 of the original specification
Protected local consumption state enforces the limit.
M-1.36.22 — Stale Revocation State
A disconnected device cannot receive a current revocation.
The system applies its bounded offline authority and expiry model
rather than assuming instantaneous remote revocation.
M-1.36.23 — Conflicting Multi-Principal Approval
One principal approves an effect while another mandatory principal
denies it.
The protected authority-composition rule preserves the required
denial.
M-1.36.24 — Remote Attestation Overclaim
Das Expires 29 April 2027 [Page 155]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
An attested computing environment claims that a particular external
effect occurred.
The system requires effect-specific evidence where actual outcome is
relevant.
M-1.36.25 — Cryptographic Receipt Replay
An old valid receipt is presented for a different operation.
The applicable operation binding, phase lineage, freshness, and
consumption state prevent unauthorized reuse.
M-1.36.26 — User-Visible Resource Drift
A selected object changes between user approval and execution.
Where semantic correspondence is required, the sink verifies the
actual target under the protected object identity.
M-1.36.27 — Compromised Protected Controller
An attacker compromises the component responsible for enforcing a
protected effect.
The claimed guarantee depends upon the identified trusted computing
base.
Additional independent protection may be required under a stronger
adversary model.
M-1.36.28 — Unknown Future Interface
A new effect-capable interface is not recognized by the current
discovery mechanism.
The system cannot claim universal coverage unless the relevant
interface is actually mediated or otherwise constrained.
M-1.36.29 — Misleading Cryptographic Proof
A valid proof establishes a narrow predicate but is presented as
proof of a broader external outcome.
9.3.3.43. Source page 597 of the original specification
The verifier distinguishes what the proof establishes from what the
later operation requires.
Das Expires 29 April 2027 [Page 156]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-1.36.30 — Malicious Recovery Operation
An autonomous agent proposes a broad corrective action following an
error.
The recovery operation requires its own appropriate authority and
finality verification.
M-1.37 — NON-LIMITING FEASIBILITY EXPERIMENTS
The following experiments are proposed and are not statements of
completed experimental results.
Experiment 1 — Effectuation-Surface Inventory: Enumerate protected
interfaces capable of producing a selected consequential effect.
Experiment 2 — Alternate Path Detection: Introduce a second interface
producing the same effect and determine whether coverage verification
detects it.
Experiment 3 — Dynamic Tool Registration: Register a newly discovered
effect-capable tool under an authenticated action contract.
Experiment 4 — Unregistered Tool Attempt: Attempt a protected effect
through a tool lacking valid registration.
Experiment 5 — Tool Contract Update: Change a security-relevant
operation parameter or side effect and verify contract revalidation.
Experiment 6 — Resource Alias Change: Rebind a resource alias after
authorization and verify current sink-side correspondence.
Experiment 7 — Cross-Interface Equivalence: Attempt the same resource
effect through two different protocols and verify common authority
constraints.
Experiment 8 — Delegation Attenuation: Delegate a narrow authority
and attempt an unauthorized scope expansion.
Experiment 9 — Cross-Provider Authorization: Verify delegated
authority at a remotely administered Finality Sink.
Experiment 10 — Credential Broker: Confirm that an agent cannot use a
protected reusable credential for an unrelated effect.
Experiment 11 — Privacy Composition: Perform several individually
permitted disclosures and verify the applicable cumulative
constraint.
Das Expires 29 April 2027 [Page 157]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Experiment 12 — Multi-Principal Approval: Require separate
authenticated authority from two relevant principals.
Experiment 13 — Protected Resource Allocation: Verify that an
allocation controller applies the specified protected resource
policy.
Experiment 14 — Validation Work Limit: Submit oversized or
computationally expensive evidence and verify bounded resource
consumption.
9.3.3.44. Source page 598 of the original specification
Experiment 15 — Deadline Failure: Exhaust the available validation
window and verify the defined protected failure behavior.
Experiment 16 — Post-Update Coverage: Introduce a new effect-capable
interface through a software update and verify the required
reattestation response.
Experiment 17 — Stale Contract Authority: Attempt to exercise
authority bound to a superseded incompatible tool contract.
Experiment 18 — Accelerator Egress: Submit an accelerator-generated
effect requiring controller-side authorization.
Experiment 19 — Command Mutation: Alter a protected accelerator
command after approval.
Experiment 20 — Cross-Device Migration: Transfer unfinished authority
and verify rejection of stale-owner effectuation.
Experiment 21 — Offline Consumption: Exercise bounded authority while
disconnected and verify local consumption limits.
Experiment 22 — Offline Revocation Limit: Examine the system's actual
guarantee during unavailable remote connectivity.
Experiment 23 — Causal Receipt Integration: Require a validator-
accepted earlier real-effect receipt for a successor operation.
Experiment 24 — Conflicting Agent Operations: Combine miscellaneous
modules with a protected conflict reservation under Embodiment 1.
Experiment 25 — Actual Remote Outcome: Verify that a remote
acceptance acknowledgement is not silently treated as proof of
completed external consequence.
Das Expires 29 April 2027 [Page 158]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Experiment 26 — Semantic Target Drift: Test changes in the actual
resource corresponding to a user-referenced object.
Experiment 27 — Privacy-Preserving Proof: Verify a narrow protected
predicate without releasing unnecessary raw data.
Experiment 28 — Post-Crash Recovery: Simulate a failure after
authority consumption but before final acknowledgement.
Experiment 29 — Module Omission: Attempt to suppress a mandatory
specialized verification module through an agent-supplied request
field.
Experiment 30 — Integrated Component: Implement registry, verifier,
and sink within a single protected controller.
M-1.38 — MEASURABLE TECHNICAL PROPERTIES
The present embodiment may be evaluated using measurable properties
including:
Effectuation-path discovery coverage.
9.3.3.45. Source page 599 of the original specification
Unmediated interface detection.
Unauthorized alternate-path effect acceptance.
Tool contract mismatch rejection.
Actual-operation semantic correspondence.
Cross-interface resource alias resolution accuracy.
Delegation-scope violation rejection.
Protected credential misuse prevention.
Cumulative privacy-constraint enforcement.
Resource-budget verification correctness.
Validation work consumption.
Maximum verification latency.
Post-update enforcement-coverage recovery.
Das Expires 29 April 2027 [Page 159]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Protected authority invalidation after contract changes.
Accelerator command-integrity enforcement.
Direct effectuation-path protection.
Cross-domain authority authentication.
Cross-device stale-owner rejection.
Offline authority consumption correctness.
Crash-recovery state integrity.
Receipt-dependent continuation correctness where CW-2 is integrated.
Actual external-outcome classification accuracy where outcome
witnessing is required.
The metrics should be evaluated under a stated technical threat
model.
A measurement showing that one path is protected does not establish
that all possible effectuation paths are protected.
M-1.39 — DISTINCTIONS FROM CONVENTIONAL SYSTEMS
M-1.39.1 — Conventional Tool Registries
A conventional tool registry may identify available functions.
9.3.3.46. Source page 600 of the original specification
The present embodiment may additionally make verified effectuation
coverage and current operation-contract semantics mandatory
predicates for protected finality.
M-1.39.2 — Conventional API Gateways
An API gateway may enforce access rules for requests passing through
it.
The proposed additional mechanism may verify whether alternative
relevant effectuation paths remain covered and invalidate authority
when mandatory coverage changes.
M-1.39.3 — Conventional Software Versioning
Das Expires 29 April 2027 [Page 160]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A software version identifier may describe an installed component.
The present embodiment may require verified semantic compatibility
between the authorized action contract and the actual command
presented to the sink.
M-1.39.4 — Conventional Resource Identifiers
A resource identifier may refer to an application object.
The present embodiment may require authenticated cross-interface
correspondence and current identity verification for the actual
consequential target.
M-1.39.5 — Conventional Delegated Credentials
A delegated credential may allow a downstream service to act.
The proposed arrangement may additionally require protected
attenuation of effect-specific authority and destination-side
verification against the actual operation.
M-1.39.6 — Conventional Credential Brokers
A broker may protect secrets from requesting software.
The proposed technical distinction may concern operation-bound
exercise of the credential at an independently verified Finality
Sink.
M-1.39.7 — Conventional Privacy Permissions
A permission system may decide whether one disclosure is allowed.
The present embodiment may additionally evaluate protected cumulative
or correlated exposure and enforce the result at the actual release
boundary.
M-1.39.8 — Conventional Workload Scheduling
A scheduler may allocate processing resources according to priority.
The present embodiment may provide protected allocation evidence and
enforce resource-use authority at the corresponding controller.
M-1.39.9 — Conventional Remote Attestation
Das Expires 29 April 2027 [Page 161]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.3.3.47. Source page 601 of the original specification
Remote attestation may provide evidence about an execution
environment.
The present embodiment distinguishes verified environment identity
from authority over a specific external consequence.
M-1.39.10 — Conventional Hardware Isolation
Hardware isolation may constrain access to devices or memory.
The proposed architecture may additionally bind actual hardware
effectuation to operation-specific protected finality authority and
current command descriptors.
M-1.39.11 — Conventional Update Verification
A system may verify the authenticity of a software update.
The present embodiment may additionally reassess whether the updated
system continues to enforce all mandatory effectuation paths for a
defined consequence.
M-1.39.12 — Conventional Distributed Workflows
A distributed workflow may coordinate operations across services.
The present embodiment may require each consequential sink to verify
current scope, delegation lineage, and actual operation
correspondence rather than relying exclusively on upstream workflow
approval.
M-1.40 — PROPOSED INVENTIVE-STEP FOCUS
M-1.40.1 — General Qualification
The mechanisms disclosed in the present embodiment employ classes of
techniques that may individually be known.
These include access control, resource identity resolution,
distributed authorization, credential brokering, protected hardware,
transaction-state verification, cryptographic authentication, and
software update management.
The mere presence of these components does not establish inventive
step.
Das Expires 29 April 2027 [Page 162]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The candidate technical contributions concern specific combinations
and protected dependencies that govern actual consequential release.
M-1.40.2 — Candidate Inventive Concept A: Dynamic Enforcement-
Coverage Authority
A protected system identifies the effectuation interfaces capable of
producing a defined consequence.
It commits current enforcement coverage against an authenticated
environment state.
A Finality Sink refuses the operation where a required interface
lacks valid protection.
9.3.3.48. Source page 602 of the original specification
The possible technical contribution is making current coverage of
effectuation paths a necessary authority predicate.
M-1.40.3 — Candidate Inventive Concept B: Semantic Contract
Continuity
A protected system binds an authorized effect to a verified action-
contract representation.
Following a relevant tool update, it determines whether actual effect
semantics remain compatible.
The actual sink refuses use of stale authority where the action
contract has materially changed.
M-1.40.4 — Candidate Inventive Concept C: Protocol-Neutral
Consequence Binding
Several different software or hardware interfaces may express the
same consequential operation.
The system constructs a protocol-neutral protected effect descriptor
and verifies the actual effect against that descriptor.
The candidate technical distinction concerns consistent protected
finality enforcement across heterogeneous invocation mechanisms.
M-1.40.5 — Candidate Inventive Concept D: Cross-Interface Resource
Continuity
Das Expires 29 April 2027 [Page 163]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The system associates resource aliases with an authenticated
underlying resource identity.
The final sink verifies current correspondence and rejects
unauthorized rebinding or substitution.
M-1.40.6 — Candidate Inventive Concept E: Distributed Authority
Attenuation
A parent authority is delegated across one or more autonomous
computing domains.
Each derived authority is constrained by the predecessor's permitted
consequential scope.
The receiving Finality Sink verifies the actual operation against the
protected delegation lineage.
M-1.40.7 — Candidate Inventive Concept F: Credential-Release Finality
A reusable credential remains under protected control.
Credential exercise is bound to the actual authorized Candidate Act
and verified at the consequential boundary.
The agent does not acquire unrestricted credential authority merely
because it requests a permitted operation.
M-1.40.8 — Candidate Inventive Concept G: Cumulative Protected
Privacy State
Individually permitted disclosures are evaluated against protected
cumulative privacy-exposure conditions.
The data-release Finality Sink verifies current exposure state and
actual outgoing data.
M-1.40.9 — Candidate Inventive Concept H: Resource-Bounded Finality
Verification
9.3.3.49. Source page 603 of the original specification
A protected validator operates within explicit work, memory, latency,
or energy constraints.
An operation whose mandatory predicates cannot be established within
the permitted verification budget is withheld rather than
automatically approved.
Das Expires 29 April 2027 [Page 164]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-1.40.10 — Candidate Inventive Concept I: Update-Triggered
Enforcement Reattestation
A material runtime or software change invalidates earlier
enforcement-coverage assumptions.
The system requires reattestation of relevant effectuation paths
before permitting protected consequential operations.
M-1.40.11 — Candidate Inventive Concept J: Heterogeneous Hardware
Effect Finality
An accelerator or specialized hardware device produces an operation
capable of affecting persistent, external, or physical state.
The actual hardware effectuation controller verifies protected act-
specific authority independently of the requesting computation.
M-1.40.12 — Candidate Inventive Concept K: Cross-Domain Continuity
A protected authority remains scoped as autonomous computation
migrates among local, edge, cloud, or other execution environments.
The destination sink verifies current ownership, authority lineage,
and actual effectuation conditions.
M-1.40.13 — Candidate Inventive Concept L: Combined Coverage,
Semantics, and Authority
A stronger combined arrangement may require:
An authenticated inventory of effect-capable interfaces;
Current operation-contract validity;
Cross-interface resource identity;
Operation-specific protected authority;
And actual Finality Sink verification.
The protected authority becomes unusable where the current
environment no longer supports the assumptions under which the
operation was authorized.
This interaction may provide a narrower and more technically specific
focus than claiming individual modules independently.
Das Expires 29 April 2027 [Page 165]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-1.41 — CANDIDATE OBJECTIVE TECHNICAL PROBLEM
An illustrative objective technical problem for selected
implementations of this embodiment is:
9.3.3.50. Source page 604 of the original specification
How to maintain mandatory operation-specific execution-finality
enforcement when autonomous computing systems dynamically change
tools, interfaces, execution environments, delegation relationships,
resource identities, software versions, or hardware effectuation
pathways, while ensuring that actual consequential operations remain
bound to authenticated protected authority and current enforcement
coverage.
Different independent or dependent claims may address narrower
objective problems, including:
Preventing unauthorized effectuation through newly introduced
alternate paths.
Preventing stale authorization after material operation-semantics
changes.
Preventing delegation-induced scope expansion.
Preventing cumulative privacy exposure through independently
permitted disclosures.
Preserving protected finality validation under bounded resources.
Enforcing actual command authority for heterogeneous effect-capable
hardware.
The objective problem selected for a claim should correspond to the
technical differences actually present in that claim.
M-1.42 — HINDSIGHT AND PRIOR-ART CONSIDERATIONS
Inventive-step analysis should identify the closest relevant
technical disclosure for the particular optional mechanism.
For enforcement coverage, relevant prior art may include complete
mediation, reference monitors, sandboxing, and mandatory access-
control architectures.
Das Expires 29 April 2027 [Page 166]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
For dynamic tool contracts, relevant prior art may include interface
compatibility verification, schema validation, software attestation,
and policy-controlled dispatch.
For delegated authority, relevant prior art may include capability
attenuation, delegation chains, and distributed authorization
systems.
For hardware effects, relevant prior art may include device
isolation, protected command queues, direct-memory-access controls,
and hardware authorization.
For bounded verification, relevant prior art may include resource-
limited parsing, real-time verification, admission control, and
denial-of-service resistance.
The candidate inventive contribution must be evaluated against those
established techniques and their obvious combinations.
A new technical term does not establish novelty.
Likewise, the inclusion of multiple existing security components does
not automatically establish a non-obvious combination.
The relevant comparison is the enforceable technical relationship and
its demonstrated or technically supported effect.
9.3.3.51. Source page 605 of the original specification
A broad claim should not assert universal non-bypassability where the
disclosed enforcement interfaces do not provide the required
coverage.
M-1.43 — INDUSTRIAL APPLICABILITY
The disclosed systems may be implemented in enterprise autonomous-
agent infrastructure, secure application gateways, mobile devices,
desktop assistants, cloud management platforms, embedded devices,
distributed service architectures, protected financial
infrastructure, storage controllers, communication networks, robotic
systems, autonomous vehicles, industrial control systems, and
heterogeneous computing environments.
In enterprise AI systems, the architecture may govern dynamically
discovered tools and cross-application operations.
Das Expires 29 April 2027 [Page 167]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
In cloud infrastructure, it may bind delegated authority and
resource-state changes to current protected policy and actual
finality interfaces.
In mobile and desktop systems, it may govern application commands,
sensor releases, data exports, and privileged device operations.
In telecommunications infrastructure, it may enforce protected
authority for actual network configuration changes.
In hardware computing platforms, it may apply operation-specific
finality requirements to effect-capable accelerators and peripherals.
In industrial automation, it may constrain physical actuator commands
and protect relevant state transitions.
In future autonomous environments, it may provide a protocol-neutral
security interface separating computational decision-making from
protected authority to produce external consequences.
The particular industrial implementation may rely upon software,
firmware, protected processors, cryptographic authorization,
authenticated communication, controller-local state, or suitable
combinations thereof.
The relevant technical utility lies in controlling actual
consequential operations despite changes in the systems that generate
or transport them.
M-1.44 — NON-LIMITING IMPLEMENTATION VARIATIONS
Variation M-1.A — Local Protected Gateway: The modules execute within
one protected device or software security service.
Variation M-1.B — Distributed Protected Authority: Verification and
effectuation occur in different authenticated domains.
Variation M-1.C — Hardware Enforcement Registry: A hardware
controller maintains the applicable effectuation-surface and
authority state.
9.3.3.52. Source page 606 of the original specification
Variation M-1.D — Dynamic Tool Contract: Newly discovered tools
require current protected operation-contract verification.
Variation M-1.E — Protocol-Neutral Dispatcher: Several invocation
protocols are normalized into one effect descriptor.
Das Expires 29 April 2027 [Page 168]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Variation M-1.F — Protected Resource Alias Resolver: Multiple
application references are bound to a common resource identity.
Variation M-1.G — Delegation-Attenuation Service: Authority may be
narrowed across multiple agent generations.
Variation M-1.H — Credential Broker: Reusable credentials remain
outside agent control.
Variation M-1.I — Cumulative Privacy Controller: Protected exposure
state governs data release.
Variation M-1.J — Multi-Principal Authority: Several principals
contribute mandatory authorization predicates.
Variation M-1.K — Protected Resource-Parity Verifier: An allocation
decision is supported by authenticated comparable-workload evidence.
Variation M-1.L — Verification Work-Budget Controller: Security
checks operate within bounded protected resources.
Variation M-1.M — Deadline-Constrained Verification: A real-time
system uses approved bounded verification procedures.
Variation M-1.N — Thermal-Aware Verification: Protected scheduling
accounts for device thermal limits.
Variation M-1.O — Post-Update Reattestation: Software or firmware
changes trigger enforcement-coverage revalidation.
Variation M-1.P — Accelerator Finality Gate: A specialized device's
external effects require operation-specific protected authority.
Variation M-1.Q — Direct-Memory-Access Control: Device access is
governed by an applicable protected resource boundary.
Variation M-1.R — Confidential Execution Output Gate: Protected
computation remains separate from authority over external effects.
Variation M-1.S — Edge-to-Cloud Authority Continuity: Computation
migration preserves scoped finality constraints.
Variation M-1.T — Cross-Provider Agent Authority: Delegated agents
operate under authenticated constrained authority.
Variation M-1.U — Cross-Device Exclusive Ownership: Protected fencing
prevents stale-device authority.
Das Expires 29 April 2027 [Page 169]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.3.3.53. Source page 607 of the original specification
Variation M-1.V — Physical Actuation Controller: Actual actuator
commands are verified at an appropriate hardware boundary.
Variation M-1.W — Spatial Resource Correspondence: User-selected
spatial referents are bound to actual effect targets.
Variation M-1.X — Future Network Control: Autonomous communication
infrastructure requires protected configuration finality.
Variation M-1.Y — Intermittent-Connectivity Authority: Offline
effects are bounded by protected local scope and consumption state.
Variation M-1.Z — Machine-to-Machine Transactions: Autonomous
economic effects require appropriate scoped finality authority.
Variation M-1.AA — Privacy-Preserving Verification: Protected
predicates may be proved without disclosing unnecessary raw data.
Variation M-1.AB — Cryptographic Algorithm Agility: Authority records
support authenticated cryptographic migration.
Variation M-1.AC — Optional Causal IEV: Accepted earlier real-effect
receipts may govern later consequences.
Variation M-1.AD — Optional Cross-Agent Reservation: Effect conflict
state may impose additional mandatory finality conditions.
Variation M-1.AE — Optional Remote Consequence Witnessing: Cross-
domain evidence may establish the relevant actual remote result.
Variation M-1.AF — Integrated Controller: Several logical modules may
reside in one protected component.
Variation M-1.AG — Multiple Protected Controllers: The same required
finality predicates may be enforced across separate hardware or
software components.
Variation M-1.AH — Protected Update Rollback Resistance: Earlier
insecure configurations are not silently accepted under current
authority.
Variation M-1.AI — Unknown-Interface Restriction: An unverified
effect-capable interface remains restricted.
Das Expires 29 April 2027 [Page 170]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Variation M-1.AJ — Future Hardware Adapter: A new effect-capable
device may integrate through a protected operation and finality
contract.
The variations are optional and may be combined where technically
compatible.
M-1.45 — SUPPORT FOR POTENTIAL CLAIMED SUBJECT MATTER
The following candidate claim-support concepts may be considered
individually or in appropriately supported combinations.
9.3.3.54. Source page 608 of the original specification
Aspect 1: A protected registry identifying effect-capable interfaces
associated with a defined consequence class.
Aspect 2: A current effectuation-coverage commitment verified before
actual effectuation.
Aspect 3: A Candidate Act bound to a current authenticated action-
contract version.
Aspect 4: Rejection of stale authority following a material
operation-semantics change.
Aspect 5: Protocol-neutral normalization of actual consequential
operation semantics.
Aspect 6: Protected comparison of different effectuation interfaces
producing equivalent consequential effects.
Aspect 7: Authentication of resource equivalence across multiple
application identifiers.
Aspect 8: Current resource-version verification at the actual sink.
Aspect 9: Dynamic discovery of newly introduced effect-capable tools.
Aspect 10: Restricted operation until the new tool's enforcement
coverage is established.
Aspect 11: Authenticated delegation attenuation across autonomous
agents.
Aspect 12: Destination-side verification of delegated authority
lineage.
Das Expires 29 April 2027 [Page 171]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Aspect 13: Protected credential exercise bound to an actual
authorized operation.
Aspect 14: Prevention of unrestricted credential possession by the
requesting agent.
Aspect 15: Protected cumulative privacy-exposure state governing
subsequent data release.
Aspect 16: Authenticated multi-principal authority composition.
Aspect 17: Protected resource-allocation evidence used at an actual
resource controller.
Aspect 18: Resource-bounded validation under adversarial input
conditions.
Aspect 19: Mandatory withholding when required verification cannot be
completed.
Aspect 20: Software-update-triggered advancement of a protected
environment epoch.
Aspect 21: Reattestation of effectuation coverage following a
relevant environmental change.
Aspect 22: Invalidation of authorization bound to an incompatible
earlier enforcement configuration.
Aspect 23: Actual effectuation verification for accelerator-
originated commands.
Aspect 24: Hardware command-buffer integrity and actual-operation
correspondence.
Aspect 25: Scoped authority continuity across local, edge, and remote
execution.
Aspect 26: Protected ownership fencing during cross-device authority
migration.
9.3.3.55. Source page 609 of the original specification
Aspect 27: Bounded offline authority with protected consumption
state.
Aspect 28: Protected current authority checks after reconnection.
Das Expires 29 April 2027 [Page 172]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Aspect 29: Integration of a cryptographically identified IEV receipt
as an optional mandatory phase condition.
Aspect 30: Integration of protected conflict reservations from
multiple independently authorized agents.
Aspect 31: Integration of actual remote outcome evidence.
Aspect 32: Privacy-preserving proof of a defined authorization or
resource predicate.
Aspect 33: Cryptographic identity or algorithm rotation without
unrestricted authority expansion.
Aspect 34: Hardware- and software-neutral operation-specific
protected finality interfaces.
Aspect 35: Enforcement of dynamically discovered effectuation routes
through a protected sink.
Aspect 36: Current semantic compatibility verification before
privileged credential release.
Aspect 37: Protected update reattestation combined with current
action-contract matching.
Aspect 38: Cross-provider delegated authority combined with
destination-side actual-operation reconstruction.
Aspect 39: Protected resource budgeting combined with fail-closed
validation under computational stress.
Aspect 40: Integration of multiple supplementary security predicates
within a common finality-enforcement architecture.
These are potential technical limitations rather than finalized
patent claims.
The appropriate scope depends upon the actual enabling disclosure,
claim dependencies, unity, and relevant prior art.
M-1.46 — FINAL NON-LIMITING TECHNICAL SUMMARY
The present Miscellaneous Embodiment M-1 discloses additional
optional mechanisms for adapting protected execution-finality control
to dynamic, heterogeneous, and increasingly autonomous computing
systems.
Das Expires 29 April 2027 [Page 173]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The embodiment provides implementation support for protected
effectuation-surface discovery, current enforcement-coverage
commitments, protocol-neutral consequential-operation descriptors,
dynamic action-contract verification, resource identity
correspondence, delegated authority attenuation, protected
credential-release binding, privacy exposure composition, bounded
verification resources, post-update reattestation, and hardware-
specific effectuation control.
The mechanisms may be deployed separately or in compatible
combinations.
9.4. Embodiment 14: Protected Effectuation-Path Discovery, Runtime
Bypass Detection and Hardware Attribution
Original technical source global pages 1222-1308; input volume
TECHNICAL SPECIFICATION -1063-1541.pdf. Primary Part 4 topic:
Embodiment 14: Protected Effectuation-Path Discovery, Runtime Bypass
Detection and Hardware Attribution. The patent specification may
present optional embodiments, alternative formulations and claim
proposals; preserving its wording does not convert each option into a
requirement of a standard.
9.4.1. Protected Architecture and Trust-Boundary Diagram
[Agent runtime / tools / app interfaces]
| | | |
[API] [Socket] [IPC] [Device/DMA]
\ | | //
[Effect-capable resource graph]
|
[Coverage epoch controller]
|
[Blocking capability qualified]
|
[Protected Finality Sink]
Figure 18: Embodiment 14: Protected Effectuation-Path Discovery,
Runtime Bypass Detection and Hardware Attribution — architecture
9.4.2. Operational Decision and Fail-Closed Flowchart
Das Expires 29 April 2027 [Page 174]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
[Identify effect-capable route]
|
<Can route cause real effect?>--NO-->[Record]
|YES
<Blocking gate covers route?>--NO-->[Invalidate/deny]
|YES
<Coverage epoch current?>--NO-->[Reattest]
|YES
[Reconstruct pending effect]
|
<Actual effect/evidence/current state match?>--NO-->[Refuse]
|YES
[Consume and effect]
Figure 19: Embodiment 14: Protected Effectuation-Path Discovery,
Runtime Bypass Detection and Hardware Attribution — operational
flowchart
9.4.3. Original Page-by-Page Technical Disclosure
9.4.3.1. Source page 1222 of the original specification
EMBODIMENT 14
PROTECTED EFFECTUATION-PATH DISCOVERY AND RUNTIME BYPASS DETECTION
WITH DYNAMIC ENFORCEMENT INVALIDATION, HARDWARE RESOURCE ATTRIBUTION,
AND FINALITY-SINK COVERAGE REVALIDATION
14.0 — COMPLETE TECHNICAL TITLE
Systems and Methods for Protected Discovery, Classification, and
Continuous Revalidation of Consequential Effectuation Paths Using
Authenticated Effect-Capable Resource Graphs, Mandatory Enforcement-
Coverage Commitments, Monitoring-versus-Blocking Capability
Verification, Runtime Topology-Change Fencing, Protected Hardware
Resource Attribution, Operation-Specific Coverage Epochs, and
Independent Finality-Sink Verification Before External Effectuation
14.0.1 — General Technical Description
The present Embodiment 14 discloses systems, methods, apparatus,
protected computing components, authenticated discovery protocols,
hardware and software enforcement mechanisms, machine-verifiable
resource and effectuation-path structures, protected configuration-
state transitions, dynamic enforcement-coverage procedures, and non-
limiting implementations for identifying and controlling
consequential execution paths available to autonomous computational
entities.
Das Expires 29 April 2027 [Page 175]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Such computational entities may comprise artificial-intelligence
agents, autonomous assistants, application services, cloud workloads,
operating-system processes, distributed computational services,
hardware accelerators, storage controllers, network functions,
robotic systems, communication devices, embedded processors, or other
entities capable of generating commands that produce external or
persistent effects.
An autonomous system may include a protected authorization controller
that examines proposed operations before permitting consequential
execution.
However, the existence of a protected authorization controller does
not establish that every relevant consequential operation must pass
through it.
An agent may possess several effect-capable interfaces.
These may include a controlled application API, a direct network
socket, a local interprocess communication channel, a file-system
interface, a database driver, a credential broker, a device-
management interface, an accelerator command queue, a peripheral
interface, or another route capable of producing an external
consequence.
Some routes may include a mandatory blocking enforcement component.
Other routes may provide observation or audit records without
preventing effectuation.
Still other routes may be outside the relevant controller's
visibility.
9.4.3.2. Source page 1223 of the original specification
Consequently, a system may correctly validate a particular Candidate
Act through one protected interface while remaining vulnerable to an
equivalent unauthorized effect performed through another interface.
The present embodiment addresses the technical integrity of the
actual enforcement topology.
In a principal implementation, a protected effectuation-path
controller establishes an authenticated representation of relevant
effect-capable resources, reachable interfaces, enforcement
components, and resource ownership relationships.
Das Expires 29 April 2027 [Page 176]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A protected verifier determines which identified paths are subject to
mandatory operation-specific blocking enforcement.
The verifier distinguishes such paths from monitoring-only
interfaces, advisory policy checks, or controls lacking the authority
to prevent the actual effect.
The system associates its authorization state with an authenticated
enforcement-coverage generation.
When a material change occurs to the software, hardware, routing,
tool, device, resource, or enforcement configuration, affected
coverage authority is invalidated or fenced.
A protected discovery and revalidation procedure determines whether
the current effectuation topology remains enforceable.
The corresponding Finality Sink verifies the current applicable
coverage state and reconstructs the actual operation before
permitting the governed consequence.
The system thereby prevents a previously established authorization
from remaining effective merely because the controlled route was
valid at an earlier time.
14.0.2 — Fundamental Technical Principle
A valid authorization does not establish safe consequential execution
unless the actual path through which the operation becomes effective
remains subject to the required enforcement.
A protected system distinguishes:
The existence of an authorization policy;
The existence of a monitoring component;
The existence of an enforcement hook;
The effectiveness of that hook for a particular consequential
operation;
The completeness of relevant path coverage;
The continued validity of the enforcement configuration;
Das Expires 29 April 2027 [Page 177]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.4.3.3. Source page 1224 of the original specification
And the independent authorization of the actual pending effect.
A route capable only of logging an operation does not automatically
constitute a blocking Finality Sink.
A previously measured enforcement topology does not automatically
remain current after a material update.
14.0.3 — Principal Proposed Inventive Concept
The principal candidate inventive technical combination concerns a
mandatory relationship among:
An authenticated description of the covered effect-capable
environment;
A protected classification of consequential resources and interfaces;
A machine-verifiable representation of relevant effectuation paths;
Qualified evidence concerning mandatory blocking enforcement on those
paths;
A protected enforcement-coverage commitment;
A current coverage-generation or epoch state;
Protected detection or notification of topology-changing events;
Invalidation or fencing of affected consequential authority;
A controlled revalidation procedure;
And a Finality Sink that independently verifies current coverage and
actual operation-specific authority before permitting the
consequence.
The coverage commitment does not itself authorize an operation.
It establishes one necessary condition for exercising otherwise valid
operation-specific authority through the governed enforcement
topology.
14.0.4 — Core Anti-Bypass Principle
Das Expires 29 April 2027 [Page 178]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The system is designed so that, within the declared and enforced
protection boundary, a consequential operation cannot validly reach
its protected resource through an unverified alternative effectuation
path.
The implementation may achieve this through mandatory mediation of
relevant interfaces, protected configuration, resource-specific
command authorization, hardware enforcement, removal of uncontrolled
interfaces, or suitable combinations.
9.4.3.4. Source page 1225 of the original specification
The system does not assume that discovering one path proves that
every possible physical or software path has been discovered.
The claimed coverage guarantee must correspond to the actual
controlled environment and qualified evidence.
14.0.5 — Distinction Between Detection and Prevention
Detection of an unauthorized operation after it has occurred is not
equivalent to withholding the operation before it becomes effective.
The present embodiment may incorporate monitoring for identifying
relevant topology changes or attempted bypass.
However, the principal protected finality configuration requires a
blocking or otherwise effective withholding mechanism at the
applicable consequential boundary.
A monitoring component may contribute evidence to revalidation
without itself constituting the required effectuation gate.
14.0.6 — Current and Future Implementations
The embodiment may be implemented with controlled application
dispatchers, operating-system mandatory access-control facilities,
protected network gateways, device drivers, transactional resource
controllers, secure execution environments, hardware command gates,
authenticated service registries, or other current technical
mechanisms.
Advanced variations may govern direct accelerator egress,
heterogeneous interconnects, dynamically loaded tools, programmable
network devices, multi-agent cloud services, remote device actuation,
confidential computing, and future autonomous infrastructure.
Das Expires 29 April 2027 [Page 179]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A particular vendor, kernel, operating system, processor,
communication protocol, or enforcement technology is not required
unless selected for a specific implementation.
14.0.7 — Relationship to Common Workflows
The embodiment may employ Candidate Acts, Non-Effective State,
Protected Enforcement Domains, authenticated validation evidence,
scoped non-bearer finality authority, and independent Finality Sinks
from CW-1.
Where an operation depends upon a qualified earlier real effect, the
accepted receipt-constituted causal continuation mechanism of CW-2
may additionally apply.
Where a newly discovered effectuation path changes the scope of an
operation beyond valid authority, appropriate reauthorization under
CW-3 may be required.
Coverage validation does not replace mandatory causal receipt
validation where the latter is an expressly required authority
component.
14.0.8 — Relationship to Earlier Embodiments
9.4.3.5. Source page 1226 of the original specification
Embodiments 1 and 11 may govern conflicting operations and version-
bound resource reservations across the identified effectuation paths.
Embodiment 2 may govern causal continuation following an earlier
verified effect.
Embodiments 3 and 4 may support actual resource correspondence and
qualified effect observation.
Embodiment 5 may bound resources used by discovery and verification.
Embodiment 6 may identify a changed tool contract introducing a new
consequential path.
Embodiment 7 may preserve authorization and effectuation requirements
across delegated agents and providers.
Embodiment 8 may govern cumulative disclosure through the discovered
data-egress interfaces.
Das Expires 29 April 2027 [Page 180]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Embodiment 9 may govern device ownership and direct hardware
authority.
Embodiment 10 may bind enforcement validity to the current model,
runtime, or algorithmic generation.
Embodiment 12 may control recovery following an actual bypass or
incomplete enforcement transition.
Embodiment 13 may require qualified collective approval before
selected protected topology changes.
Miscellaneous Embodiment M-1 may supply optional general
effectuation-surface registry, coverage, and update infrastructure.
The present Embodiment 14 develops the operational mechanism for
establishing, invalidating, restoring, and enforcing coverage of
actual effect-capable paths, with particular attention to alternative
routes, hardware resources, and runtime configuration changes.
Previously completed embodiments remain unchanged.
14.1 — TECHNICAL FIELD
The present embodiment relates to autonomous computing security,
system-call mediation, protected execution-finality control, software
and hardware reference-monitor architectures, effectuation-path
discovery, security topology verification, mandatory access control,
device command authorization, runtime enforcement integrity, direct-
memory-access security, network egress control, and protected
configuration-state management.
9.4.3.6. Source page 1227 of the original specification
More particularly, it concerns determining whether all relevant
consequential operations within a declared controlled domain remain
subject to current mandatory enforcement and preventing stale
enforcement assumptions from authorizing subsequent external effects.
The disclosed technology may be implemented in software, firmware,
operating-system security components, protected processors, hardware
security controllers, network appliances, storage infrastructure,
embedded devices, and distributed autonomous computing environments.
14.2 — SPECIFIC TECHNICAL PROBLEMS
14.2.1 — Protected Gateway Bypass
Das Expires 29 April 2027 [Page 181]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
An autonomous application may use a direct resource interface instead
of the approved gateway.
14.2.2 — Monitoring Mistaken for Enforcement
An interface may record events without possessing authority to block
them.
14.2.3 — Incomplete Resource Discovery
An enforcement system may omit an effect-capable device, service, or
communication route.
14.2.4 — Dynamic Tool Registration
A newly installed or registered tool may expose a previously absent
consequential interface.
14.2.5 — Runtime Service Replacement
A protected service may be replaced by an implementation that does
not enforce the original authorization conditions.
14.2.6 — Kernel Hook Removal
An enforcement hook may be detached, disabled, replaced, or bypassed
through another kernel path.
14.2.7 — Alternate Network Route
An agent may communicate through another socket, network namespace,
interface, proxy, tunnel, or device.
14.2.8 — Credential-Based Bypass
An agent may exercise a broad reusable credential through an
interface outside the operation-specific authority gate.
9.4.3.7. Source page 1228 of the original specification
14.2.9 — Database Direct Connection
An agent may bypass an authorized query or mutation gateway through a
direct database connection.
14.2.10 — File-System Bypass
Das Expires 29 April 2027 [Page 182]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A file may be modified through an alternative path, descriptor,
mount, or privileged service.
14.2.11 — Interprocess Communication Bypass
A lower-trust process may request a privileged local service to
produce an effect indirectly.
14.2.12 — Device-Driver Bypass
A privileged driver or alternate device interface may produce effects
without consulting the protected finality policy.
14.2.13 — Direct Memory Access
A hardware component may modify memory or transmit data through
hardware paths not visible to an application-level gateway.
14.2.14 — Accelerator Command Egress
A GPU, NPU, or other accelerator may initiate memory, storage,
network, or device commands through distinct queues or controllers.
14.2.15 — Hardware Ownership Change
A resource may migrate between devices or administrative controllers,
invalidating an earlier enforcement assumption.
14.2.16 — Configuration Drift
A software update may change the protected route from mandatory
blocking to optional advisory behavior.
14.2.17 — Enforcement Rule Downgrade
A policy update may permit previously blocked effects.
14.2.18 — Dynamic Resource Alias
An authorized logical target may resolve to a different actual
resource or effectuation path.
14.2.19 — Encrypted Egress
A content-blind network gate may lack visibility into the plaintext
information required for a particular disclosure policy.
Das Expires 29 April 2027 [Page 183]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.4.3.8. Source page 1229 of the original specification
14.2.20 — Race During Enforcement Update
An operation may be released while the controlled topology is being
modified.
14.2.21 — In-Flight Commands
A command may already have crossed its effective release boundary
before invalidation occurs.
14.2.22 — Stale Coverage Evidence
A previously valid enforcement attestation may be reused after the
topology changes.
14.2.23 — Distributed Coverage Disagreement
Several effectuation controllers may hold inconsistent coverage
generations.
14.2.24 — Unknown Hardware Path
A device may expose an unrecognized command surface or direct data
pathway.
14.2.25 — Technical Objective
A candidate objective technical problem is:
How to prevent autonomous consequential operations from bypassing
otherwise valid authorization controls when effect-capable
interfaces, software topology, routing, devices, or hardware command
paths change, by maintaining protected evidence of mandatory
enforcement coverage, invalidating stale coverage-bound authority,
and independently verifying current effectuation-path validity at the
actual consequential sink.
14.3 — ESTABLISHED TECHNIQUES AND THEIR LIMITATIONS
14.3.1 — Reference Monitors
Reference-monitor principles, including complete mediation, tamper
resistance, and verifiability, are established.
The embodiment does not claim their original invention.
Das Expires 29 April 2027 [Page 184]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
14.3.2 — Mandatory Access Control
Operating systems may implement mandatory security policy at
protected resource interfaces.
These mechanisms are established.
9.4.3.9. Source page 1230 of the original specification
A particular mandatory access-control configuration does not
automatically cover all effects outside its actual enforcement scope.
14.3.3 — Kernel Security Hooks
Operating systems may expose security hooks through which privileged
security components inspect or restrict operations.
The presence of a hook does not automatically establish that it is
attached, configured to deny, or invoked for every relevant effect
path.
14.3.4 — Sandboxing
A sandbox may constrain file, network, device, and process
operations.
Sandboxing is established.
The actual security properties depend upon its isolation boundary and
permitted privileged interfaces.
14.3.5 — Network Firewalls and Proxies
Firewalls and proxies may block or inspect specified communication
classes.
These techniques are established.
An application may possess alternative communication paths unless
those routes are appropriately constrained.
14.3.6 — Device Access Control
Device permissions and hardware security mechanisms may restrict
access to peripherals and command queues.
These controls are established.
Das Expires 29 April 2027 [Page 185]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Their effectiveness depends upon actual device ownership and
enforcement configuration.
14.3.7 — Remote Attestation
An attestation protocol may produce qualified evidence regarding
aspects of an environment.
Attestation does not automatically establish that every consequential
interface is controlled or that the actual pending operation is
authorized.
14.3.8 — Resource Inventory and Topology Discovery
Systems may inventory services, devices, processes, network
interfaces, and dependencies.
Discovery is established.
9.4.3.10. Source page 1231 of the original specification
An inventory entry does not automatically establish a mandatory
enforcement gate for the resource.
14.3.9 — Change Management
Software and infrastructure systems may monitor or approve
configuration changes.
Change management is established.
The proposed additional relationship concerns protected automatic
invalidation of consequential authority dependent upon the changed
enforcement topology.
14.3.10 — Candidate Technical Distinction
The candidate contribution concerns connecting actual effectuation-
path coverage, protected topology epochs, change-triggered authority
invalidation, and independent current Finality-Sink verification as
mandatory technical dependencies of consequential execution.
14.4 — PRINCIPAL SYSTEM ARCHITECTURE
A representative implementation comprises:
A Protected Effect-Capable Resource Enumerator;
Das Expires 29 April 2027 [Page 186]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
An Authenticated Effectuation-Path Graph Builder;
A Protected Enforcement Capability Classifier;
A Mandatory Mediation Coverage Verifier;
A Runtime Topology Change Observer;
A Protected Enforcement Configuration Controller;
A Coverage Epoch and Invalidation Controller;
A Hardware Resource Attribution Component;
A Coverage Revalidation Authority;
An Operation-Specific Finality Authority Controller;
And one or more actual Finality Sinks.
Optional components may include an operating-system security monitor,
service registry, network namespace controller, device-enumeration
service, DMA protection controller, hardware command gate, protected
credential broker, cryptographic attestation verifier, distributed
enforcement coordinator, and adversarial path-probing test service.
9.4.3.11. Source page 1232 of the original specification
A particular implementation need not include every optional
component.
The mandatory selected components must together provide the
enforcement properties expressly required by the claimed effectuation
class.
14.4.1 — Resource Enumerator
Identifies relevant effect-capable resources and interfaces within
the declared protection boundary.
14.4.2 — Effectuation Graph Builder
Represents paths connecting computational requesters to consequential
resources.
14.4.3 — Enforcement Classifier
Das Expires 29 April 2027 [Page 187]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Determines whether identified controls block effects, only observe
them, or provide insufficiently established enforcement.
14.4.4 — Coverage Verifier
Checks that the relevant consequential paths satisfy the applicable
mandatory mediation property.
14.4.5 — Topology Change Observer
Identifies events that may alter paths, gates, resource mappings, or
enforcement capabilities.
14.4.6 — Invalidation Controller
Fences affected consequential authority when its supporting coverage
assumptions are no longer established.
14.4.7 — Hardware Attribution Component
Associates effect-capable hardware command and data paths with their
applicable controlling authority.
14.4.8 — Revalidation Authority
Evaluates the current enforcement topology after relevant changes.
14.4.9 — Finality Sink
Reconstructs the actual pending operation and verifies current path
coverage and operation-specific authority before effectuation.
14.5 — BROAD TECHNICAL DEFINITIONS
9.4.3.12. Source page 1233 of the original specification
14.5.1 — Effect-Capable Resource
An Effect-Capable Resource, or ECR-14, means a software or hardware
resource capable of producing a consequential effect through at least
one relevant interface.
14.5.2 — Effectuation Path
An Effectuation Path, or EP-14, means a sequence of computational,
communication, or hardware interfaces through which a proposed
operation may reach an effect-capable resource.
Das Expires 29 April 2027 [Page 188]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
14.5.3 — Protected Effectuation Graph
A Protected Effectuation Graph, or PEG-14, means an authenticated
representation of relevant effect-capable nodes, interfaces,
transitions, and enforcement components.
14.5.4 — Protected Enforcement Node
A Protected Enforcement Node, or PEN-14, means a component whose
configured capabilities support a specified mandatory effect-control
function.
14.5.5 — Monitoring-Only Node
A Monitoring-Only Node means an observer capable of recording or
reporting an operation without necessarily preventing it.
14.5.6 — Blocking Enforcement Predicate
A Blocking Enforcement Predicate, or BEP-14, means a condition
establishing that a designated enforcement component can prevent a
specified effect before the relevant consequence becomes effective.
14.5.7 — Protected Coverage Domain
A Protected Coverage Domain, or PCD-14, means the defined set of
resources, interfaces, paths, and threat assumptions over which an
enforcement-coverage guarantee is asserted.
14.5.8 — Mandatory Path Coverage
Mandatory Path Coverage means satisfaction of the requirement that
every relevant consequential path in a defined covered topology
traverses an effective protected enforcement condition.
14.5.9 — Effectuation Coverage Commitment
An Effectuation Coverage Commitment, or ECC-14, means an
authenticated representation of a validated enforcement topology and
its applicable coverage predicates.
14.5.10 — Coverage Epoch
9.4.3.13. Source page 1234 of the original specification
A Coverage Epoch, or CE-14, means a protected generation identifying
the currently accepted enforcement-coverage configuration.
Das Expires 29 April 2027 [Page 189]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
14.5.11 — Coverage Validity Predicate
A Coverage Validity Predicate, or CVP-14, means a machine-verifiable
rule determining whether current effectuation-path coverage satisfies
the selected policy.
14.5.12 — Coverage Invalidation Event
A Coverage Invalidation Event, or CIE-14, means a detected or
authorized change rendering one or more previously accepted coverage
assumptions invalid or requiring revalidation.
14.5.13 — Protected Coverage Fence
A Protected Coverage Fence, or PCF-14, means a protected state or
enforcement condition preventing affected consequential effects
during unresolved coverage validity.
14.5.14 — Protected Topology Transition
A Protected Topology Transition, or PTT-14, means an authenticated
update to relevant effect-capable interfaces, resource mappings,
enforcement nodes, or their configuration.
14.5.15 — Actual Effectuation Route
An Actual Effectuation Route, or AER-14, means the route actually
used or presented for a specified consequential operation.
14.5.16 — Alternate Bypass Route
An Alternate Bypass Route, or ABR-14, means an effect-capable path
that would circumvent a required enforcement condition.
14.5.17 — Enforcement Capability Evidence
Enforcement Capability Evidence, or ECE-14, means qualified evidence
concerning the blocking, monitoring, isolation, and operational
properties of an enforcement component.
14.5.18 — Enforcement Attachment Evidence
Enforcement Attachment Evidence, or EAE-14, means authenticated
evidence that a relevant enforcement component is configured and
attached at a specified interface.
14.5.19 — Protected Resource Attribution
Das Expires 29 April 2027 [Page 190]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Protected Resource Attribution, or PRA-14, means qualified
association of an actual effect-capable resource or device interface
with its relevant requester, controller, ownership domain, and
enforcement state.
14.5.20 — Hardware Effectuation Surface
9.4.3.14. Source page 1235 of the original specification
A Hardware Effectuation Surface, or HES-14, means a hardware command,
memory, storage, network, peripheral, accelerator, or other interface
capable of producing a relevant consequence.
14.5.21 — Protected Device Path Commitment
A Protected Device Path Commitment, or PDPC-14, means authenticated
evidence relating a device resource and its current effect-capable
interface to an applicable enforcement controller.
14.5.22 — Coverage Revalidation Receipt
A Coverage Revalidation Receipt, or CRR-14, means authenticated
evidence indicating the result and applicable scope of a protected
coverage revalidation procedure.
14.5.23 — Operation-Bound Coverage Authority
Operation-Bound Coverage Authority, or OBCA-14, means a finality
enablement whose validity depends upon the current accepted coverage
state for the relevant actual operation.
14.5.24 — Protected Coverage Dependency Set
A Protected Coverage Dependency Set, or PCDS-14, means the collection
of topology, configuration, resource, or enforcement facts required
to establish current coverage for a specified effect class.
14.5.25 — Coverage Completeness Assumption
A Coverage Completeness Assumption means a stated technical basis
under which the relevant effect-capable paths are considered
sufficiently enumerated or constrained.
14.5.26 — Enforcement-Path Assurance Level
An Enforcement-Path Assurance Level means a defined classification of
the evidence and technical guarantees supporting a particular path's
blocking capability.
Das Expires 29 April 2027 [Page 191]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
14.5.27 — Protected Route Mutation
A Protected Route Mutation means a controlled change to a relevant
effectuation path or resource mapping.
14.5.28 — Enforcement Reattachment
Enforcement Reattachment means installation or restoration of a
required blocking component at a relevant effectuation interface.
14.5.29 — Residual Uncontrolled Surface
A Residual Uncontrolled Surface means a known or suspected effect-
capable path for which mandatory enforcement has not been
established.
9.4.3.15. Source page 1236 of the original specification
14.5.30 — Path-Specific Fail-Closed State
A Path-Specific Fail-Closed State means a protected condition that
withholds governed consequential operations dependent upon unresolved
enforcement coverage.
14.5.31 — Coverage Authority Consumption
Coverage Authority Consumption means sink-local protected exercise of
operation-specific finality authority associated with the current
applicable coverage epoch.
14.5.32 — Protected In-Flight Effect State
Protected In-Flight Effect State means information concerning
operations that may already have crossed their relevant effectuation
boundary when coverage invalidation occurs.
14.5.33 — Revalidation Work Budget
A Revalidation Work Budget means a protected bound on the
computational, communication, or other resources consumed during
coverage verification.
14.5.34 — Coverage-Qualified Finality Sink
A Coverage-Qualified Finality Sink means an effectuation boundary
whose current mandatory enforcement capability has been established
under the applicable coverage policy.
Das Expires 29 April 2027 [Page 192]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
14.5.35 — Protected Effectuation Coverage Continuity
Protected Effectuation Coverage Continuity means maintenance or safe
reestablishment of the required mandatory enforcement conditions
across relevant topology changes.
14.6 — PROTECTED EFFECT-CAPABLE RESOURCE INVENTORY
A protected controller may identify the resources and interfaces
through which covered computational entities can cause effects.
The inventory may include network interfaces, local sockets, file-
system mutation primitives, database connections, message brokers,
credential APIs, storage export interfaces, device command queues,
display or audio output controls, memory-mapped resources,
accelerator command interfaces, and other supported effect-capable
surfaces.
A representative record may comprise:
PROTECTED_EFFECT_RESOURCE = { resource_identifier, resource_class,
effectuation_interface_set, actual_controller_identity,
current_resource_owner,
9.4.3.16. Source page 1237 of the original specification
administrative_domain, effect_classes, current_interface_generation,
hardware_or_software_identity, required_enforcement_policy,
relevant_trust_boundary, protected_resource_authentication }
The inventory may be constructed from qualified operating-system
facilities, device enumeration, authenticated service registration,
hardware resource descriptions, protected configuration, or other
suitable mechanisms.
14.6.1 — Declared Resources
The system includes resources expressly registered within the covered
domain.
14.6.2 — Discovered Resources
The system may discover additional interfaces through qualified
runtime enumeration.
14.6.3 — Derived Routes
Das Expires 29 April 2027 [Page 193]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A resource may expose an effect through another intermediary service
or hardware component.
14.6.4 — Resource Aliases
Different identifiers may refer to the same actual consequential
resource.
14.6.5 — External Resources
A remote service may control an effect beyond the local domain's
enforcement boundary.
14.6.6 — Unknown Resources
An unresolved resource path is not presumed safe merely because it is
absent from the current inventory.
14.6.7 — Controlled Enumeration
The claimed completeness depends upon the protected system's ability
to enumerate or deny access to effect-capable resources in the
declared domain.
14.6.8 — Current Evidence
Historical resource inventory information may be insufficient
following material topology changes.
9.4.3.17. Source page 1238 of the original specification
14.7 — PROTECTED EFFECTUATION GRAPH
The system may represent the relevant execution topology as a
directed graph.
(G = (V,E)) represent the covered effectuation graph. (S)
represent effect-requesting computational sources. (R) represent
protected consequential resources. (F) represent mandatory blocking
enforcement nodes. (P(s,r)) represent the relevant reachable paths
from source (s) to resource (r).
A selected coverage predicate may require:
[ \forall s\in S,\ \forall r\in R,\ \forall p\in P(s,r): \quad p\cap
F_{\mathrm{qualified}}\neq\varnothing ]
Das Expires 29 April 2027 [Page 194]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The expression states that every relevant path in the modeled
protected topology must traverse at least one qualified mandatory
enforcement condition.
This is a model-specific coverage statement.
It is not automatically proof that every unknown physical path or
privileged hardware interface has been enumerated.
14.7.1 — Graph Nodes
Nodes may represent agents, processes, gateways, drivers,
controllers, network interfaces, services, hardware units, or actual
resources.
14.7.2 — Graph Edges
Edges may represent permitted or physically realizable operation
forwarding, direct access, command dispatch, or data transmission.
14.7.3 — Edge Types
Edges may distinguish computation-only communication from effect-
capable transitions.
14.7.4 — Qualified Enforcement Nodes
A blocking component is included as a valid enforcement node only for
operation classes it can actually constrain.
14.7.5 — Unqualified Nodes
Monitoring-only or unsupported control points do not satisfy
mandatory blocking coverage.
9.4.3.18. Source page 1239 of the original specification
14.7.6 — Path Enumeration
The controller may enumerate supported paths directly or use
protected reachability analysis.
14.7.7 — Cut-Set Verification
A protected verifier may evaluate whether the mandatory enforcement
components form an effective cut between requesters and consequential
resources.
Das Expires 29 April 2027 [Page 195]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
14.7.8 — Model Assumptions
The claimed safety depends upon accurate representation of the
effect-capable topology and protection of its mutation boundaries.
14.8 — BLOCKING ENFORCEMENT VERSUS MONITORING
A protected classifier identifies the actual enforcement capability
of each relevant component.
14.8.1 — Audit-Only Monitor
The component records or reports operations but does not necessarily
prevent them.
14.8.2 — Advisory Policy Service
The component returns an authorization recommendation that the
requester may ignore.
14.8.3 — Optional Middleware
The component blocks operations only when a particular voluntary
application path invokes it.
14.8.4 — Mandatory Application Dispatcher
The component controls an effect-capable application primitive that
cannot be reached by covered requesters through an equivalent
unmediated path.
14.8.5 — Operating-System Enforcement
A protected operating-system facility may block selected relevant
operations under current policy.
14.8.6 — Hardware Enforcement
A protected device or hardware controller may refuse commands lacking
valid authorization.
14.8.7 — Protected Credential Controller
9.4.3.19. Source page 1240 of the original specification
A credential service may prevent protected resource access by
withholding operation-bound credentials.
Das Expires 29 April 2027 [Page 196]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
14.8.8 — Transactional Resource Sink
A resource controller may atomically refuse mutations whose mandatory
preconditions fail.
14.8.9 — Capability Classification
The protected system identifies which operation classes are actually
blocked by the component.
14.8.10 — Assurance Qualification
The existence of a blocking API is insufficient where a relevant
covered requester retains another uncontrolled means of producing the
same effect.
14.9 — ENFORCEMENT CAPABILITY EVIDENCE
A representative enforcement-capability record may comprise:
ENFORCEMENT_CAPABILITY_EVIDENCE = { enforcement_component_identifier,
actual_resource_or_interface, enforcement_attachment_point,
applicable_operation_classes, configured_enforcement_mode,
blocking_capability, mandatory_invocation_basis,
protected_configuration_generation, bypass_restriction_evidence,
controlling_authority_identity, trusted_observation_source,
verification_epoch, evidence_assurance_profile,
protected_authentication }
The evidence may establish that the component is attached at a
specified interface, configured to enforce a particular policy, and
supported by sufficient access restrictions to prevent covered
requesters from avoiding it.
14.9.1 — Configuration Evidence
The system verifies the current enforcement configuration.
14.9.2 — Attachment Evidence
9.4.3.20. Source page 1241 of the original specification
The relevant mechanism is actually attached or integrated at the
intended resource boundary.
14.9.3 — Blocking Evidence
Das Expires 29 April 2027 [Page 197]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A defined denied operation is prevented before the specified
consequence.
14.9.4 — Mandatory Invocation
The covered requester cannot validly choose an alternative unmediated
route.
14.9.5 — Protected Update State
Material modification of the component is itself controlled or causes
invalidation.
14.9.6 — Evidence Limits
A successful test of one blocking condition does not establish
comprehensive security for every other operation class.
14.10 — PROTECTED COVERAGE DOMAIN
The system defines the scope within which complete mediation is
asserted.
A coverage domain may identify:
The covered requesting entities;
The permitted computational privileges;
The protected consequential resources;
The supported operation classes;
The effect-capable interfaces;
The applicable privileged components;
The trusted enforcement substrate;
And the allowed topology transitions.
An example protected domain may include an isolated autonomous-agent
environment with controlled filesystem, network, IPC, and resource
interfaces.
Another may be a protected database service.
Das Expires 29 April 2027 [Page 198]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Another may be a hardware command controller managing a defined
accelerator or actuator.
9.4.3.21. Source page 1242 of the original specification
The system cannot assert complete mediation over a remote or
privileged environment beyond its actual enforcement and trust
coverage merely because it possesses a network diagram or service
inventory.
The protected domain must therefore be stated in technical terms
sufficient to support the claimed effect.
14.11 — COVERAGE COMMITMENT
An accepted coverage configuration may be represented by an
authenticated commitment.
EFFECTUATION_COVERAGE_COMMITMENT = { coverage_identifier,
coverage_domain, effect_resource_inventory_commitment,
effectuation_graph_commitment, qualified_enforcement_nodes,
required_enforcement_classes, protected_controller_identities,
current_resource_attribution_state, hardware_path_commitments,
mandatory_coverage_predicates, unresolved_surface_exclusions,
coverage_epoch, topology_configuration_epoch, current_policy_epoch,
validity_conditions, designated_finality_sinks,
protected_coverage_authentication }
The commitment may authenticate the configuration and the evidence
supporting the declared coverage property.
A signature over a graph does not independently prove that the graph
is complete.
The implementation must establish the required topology completeness
through an appropriate controlled resource-enumeration, interface-
denial, hardware restriction, or other protected mechanism.
14.12 — FORMAL COVERAGE VALIDITY
9.4.3.22. Source page 1243 of the original specification
[ C(G,F,P,T) ]
represent the selected coverage predicate over graph (G), qualified
enforcement set (F), policy (P), and trusted configuration state (T).
A consequential operation (O) may require:
Das Expires 29 April 2027 [Page 199]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
COVERAGE_VALID(O) = CURRENT_COVERAGE_EPOCH_VALID AND
REQUIRED_RESOURCE_IN_DOMAIN AND ACTUAL_EFFECT_ROUTE_QUALIFIED AND
REQUIRED_BLOCKING_MECHANISM_ACTIVE AND
CURRENT_RESOURCE_ATTRIBUTION_VALID AND
NO_UNRESOLVED_MATERIAL_INVALIDATION AND CURRENT_AUTHORITY_VALID
The finality predicate additionally requires actual operation-
specific validation.
EFFECTUATION_PERMITTED(O) = COVERAGE_VALID(O) AND
ACTUAL_OPERATION_WITHIN_AUTHORITY(O) AND REQUIRED_EVIDENCE_VALID(O)
AND SINK_LOCAL_STATE_VALID(O)
The coverage predicate is a necessary condition in the selected
principal implementation, not an independent grant of authority.
14.13 — RUNTIME EFFECTUATION-PATH DISCOVERY
The controller may discover relevant current paths using several
complementary mechanisms.
14.13.1 — Application Interface Enumeration
The system identifies effect-capable functions registered with the
agent or application.
14.13.2 — Service Endpoint Enumeration
The system identifies reachable resource services and corresponding
access controls.
14.13.3 — Operating-System Interface Enumeration
The system identifies relevant process capabilities, handles,
descriptors, device interfaces, and protected operating-system paths.
14.13.4 — Network Topology Discovery
9.4.3.23. Source page 1244 of the original specification
The system identifies permitted interfaces, namespaces, proxies, and
route classes.
14.13.5 — Storage Interface Discovery
The system identifies direct and mediated storage mutation paths.
14.13.6 — Device Enumeration
Das Expires 29 April 2027 [Page 200]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The system identifies effect-capable devices and applicable
controllers.
14.13.7 — Protected Configuration Analysis
The controller evaluates current declarative security configurations
and resource mappings.
14.13.8 — Dynamic Registration Observation
Newly introduced effect-capable interfaces may trigger immediate
invalidation or revalidation.
14.13.9 — Adversarial Path Testing
Authorized tests may attempt representative alternative routes to
establish selected blocking properties.
14.13.10 — Discovery Limitation
The system does not infer exhaustive absence of unknown paths from an
incomplete scan or a finite collection of successful tests.
14.14 — DYNAMIC TOOL AND APPLICATION ENROLLMENT
An autonomous execution environment may allow tools to be added,
updated, or removed while a task is active.
A new tool may expose a consequential operation not covered by the
original enforcement configuration.
14.14.1 — Tool Registration Event
The protected controller identifies the new executable or service
interface.
14.14.2 — Contract Verification
The tool's actual operation semantics are evaluated under the
applicable current technical contract.
14.14.3 — Effect-Class Discovery
9.4.3.24. Source page 1245 of the original specification
New resource mutations or external disclosures are identified.
14.14.4 — Path Integration
Das Expires 29 April 2027 [Page 201]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The relevant effectuation graph is updated.
14.14.5 — Coverage Invalidation
Affected authorization is fenced pending enforcement verification.
14.14.6 — Mandatory Control
The new effect-capable path must be blocked or constrained before
receiving valid consequential authority.
14.14.7 — Revalidation
A current coverage commitment is established if the required
predicates pass.
14.14.8 — Denial
A tool whose effectuation interface cannot be controlled may remain
unavailable for the governed consequential class.
14.15 — NETWORK EFFECTUATION-PATH COVERAGE
Network egress may occur through several interfaces.
A protected system may need to consider:
Application HTTP clients;
Direct sockets;
Local proxy connections;
Custom protocol clients;
Service-mesh routes;
Multiple network namespaces;
Alternative physical interfaces;
Privileged network helpers;
And device-originated transmission.
Das Expires 29 April 2027 [Page 202]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.4.3.25. Source page 1246 of the original specification
14.15.1 — Protected Egress Choke Point
The architecture may require all covered network effects to traverse
a designated protected gateway.
14.15.2 — Network Namespace Isolation
Covered workloads may be constrained to permitted interface and
routing arrangements.
14.15.3 — Protected Route Policy
Relevant routes may be subject to mandatory control.
14.15.4 — Final Destination
The actual destination may need to be verified after relevant name
resolution, redirection, or proxy routing.
14.15.5 — Alternate Interface
An interface bypassing the required gateway is blocked or separately
protected.
14.15.6 — Encrypted Egress
Where policy concerns plaintext semantics, the required enforcement
must occur at a trusted plaintext-aware boundary or through suitable
protected content binding.
14.15.7 — Network Tunnel
A tunnel may create another consequential path that requires
classification.
14.15.8 — Direct Device Egress
A hardware or device-level network path may require protected device-
controller enforcement.
14.16 — FILE-SYSTEM AND STORAGE COVERAGE
A protected agent may modify or export information through more than
one storage interface.
Das Expires 29 April 2027 [Page 203]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Potential paths may include ordinary file writes, direct block
access, memory-mapped modification, storage-service APIs, database
attachments, privileged helper processes, or device-originated
writes.
The protected system may constrain these paths through appropriate
operating-system enforcement, resource-specific controllers, or
hardware mechanisms.
14.16.1 — Actual Storage Object
9.4.3.26. Source page 1247 of the original specification
The sink identifies the actual resource rather than relying solely
upon a caller-supplied path string.
14.16.2 — Alternate Pathnames
Aliases, mounts, links, and descriptor references may refer to the
same underlying object.
14.16.3 — Privileged Helper
A local service executing a write on behalf of the agent remains an
effect-capable intermediary.
14.16.4 — Direct Block Interface
An unmediated lower-level device write may bypass application file-
policy checks.
14.16.5 — Current Enforcement
The applicable storage mutation must remain subject to the required
effectuation gate.
14.16.6 — Protected Commit
A resource controller may verify current authority and object version
before mutation.
14.16.7 — Coverage Limit
An application-level hook cannot claim protection against
uncontrolled privileged raw-device access outside its enforcement
boundary.
14.17 — INTERPROCESS COMMUNICATION AND PRIVILEGED WORKERS
Das Expires 29 April 2027 [Page 204]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
An untrusted agent may communicate with a privileged local helper.
The helper may possess stronger credentials or hardware access.
The agent's direct operating-system permissions may therefore appear
narrow while the helper can still produce broad external effects.
14.17.1 — Requester Identity
The helper identifies the actual requesting principal or workload.
14.17.2 — Requested Effect
The helper resolves the consequential operation rather than blindly
executing a supplied command.
14.17.3 — Delegated Scope
9.4.3.27. Source page 1248 of the original specification
The helper verifies applicable source-derived authority.
14.17.4 — Protected Invocation
The helper's effect-capable primitive must enforce current operation-
specific authorization.
14.17.5 — Alternate IPC Route
Uncontrolled communication channels to privileged effectors may
invalidate the coverage claim.
14.17.6 — Worker Replacement
Replacing the helper may trigger coverage revalidation.
14.17.7 — Credential Handling
A protected credential broker may prevent broad reusable credential
transfer to the requesting agent.
14.17.8 — Anti-Bypass Effect
An agent cannot validly bypass protected finality merely by asking a
privileged intermediary to perform the effect on its behalf.
14.18 — HARDWARE RESOURCE ATTRIBUTION
Das Expires 29 April 2027 [Page 205]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A consequential hardware operation may originate through a path that
differs from an ordinary application system call.
The system may therefore establish protected resource attribution
identifying:
The device;
Its current owner or controller;
The requesting computational context;
The command or memory path;
The privileged driver or firmware component;
The relevant resource-generation state;
And the hardware component capable of withholding the actual effect.
14.18.1 — Device Identity
9.4.3.28. Source page 1249 of the original specification
The hardware resource is identified through a suitable protected
representation.
14.18.2 — Ownership
The controller establishes current authority to operate the resource.
14.18.3 — Command Queue
Relevant command queues or dispatch interfaces are identified.
14.18.4 — Memory Region
Where appropriate, accessible memory regions and translation controls
are identified.
14.18.5 — Direct Data Path
The system determines whether direct memory, storage, or network
effects can occur outside the ordinary host gate.
14.18.6 — Hardware Gate
Das Expires 29 April 2027 [Page 206]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A suitably protected command or resource controller may enforce
scoped operation authority.
14.18.7 — Attribution Integrity
The resource attribution evidence must be protected against
unauthorized reassignment.
14.18.8 — Limitations
Hardware attribution does not establish that a device lacks
undocumented or uncontrolled capabilities unless the relevant
assurance evidence supports that conclusion.
14.19 — DIRECT MEMORY ACCESS AND I/O CONTROL
A hardware device may use direct memory access to read or modify host
memory.
An application-level gate may lack visibility into such activity.
A selected implementation may use appropriate address-translation and
I/O isolation facilities to restrict device access.
However, such mechanisms principally constrain addressability and
resource access.
They do not automatically provide semantic authorization for every
operation performed by an otherwise authorized device.
The protected system may therefore combine:
9.4.3.29. Source page 1250 of the original specification
Hardware address-access restriction;
Device ownership verification;
Protected command-queue control;
Operation-specific authority;
And current resource and coverage epochs.
14.19.1 — Memory Isolation
The system defines memory regions accessible to the relevant device.
Das Expires 29 April 2027 [Page 207]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
14.19.2 — Device Assignment
The protected controller verifies current device-to-workload
assignment.
14.19.3 — Queue Authorization
Effect-capable command queues may require protected activation.
14.19.4 — Reassignment
Device migration or ownership changes trigger appropriate fencing.
14.19.5 — Direct Egress
A device capable of transmitting data directly requires the
corresponding release-path control.
14.19.6 — Actual Command
The effectuation controller verifies the operation presented for
hardware execution.
14.19.7 — Evidence Limit
Isolation evidence is not automatically proof of the semantic
correctness of the command.
14.20 — GPU AND NPU EFFECTUATION PATHS
An accelerator may receive workloads, execute kernels, access
buffers, update shared memory, or interact with device interfaces.
An implementation may need to distinguish purely internal computation
from externally effective operations.
14.20.1 — Internal Computation
9.4.3.30. Source page 1251 of the original specification
Intermediate numerical operations may remain within the authorized
computational domain.
14.20.2 — Protected Memory Write
A write to a protected shared or external resource may constitute an
effect.
Das Expires 29 April 2027 [Page 208]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
14.20.3 — Command Submission
A device command queue may become an effectuation boundary.
14.20.4 — Device-to-Device Transfer
A peer-access path may require protected resource attribution.
14.20.5 — Direct Storage or Network Path
Where supported by the hardware, an accelerator-originated external
transfer may require enforcement outside the ordinary application
gateway.
14.20.6 — Kernel Replacement
A runtime or driver update may alter the set of effect-capable
command paths.
14.20.7 — Protected Dispatch
A controlled accelerator dispatcher may verify the actual command and
required authority.
14.20.8 — Current Coverage
The corresponding hardware effectuation path is accepted only under a
valid current coverage commitment.
14.21 — RUNTIME TOPOLOGY-CHANGE EVENTS
Material changes may include:
A newly registered tool;
An added network interface;
An altered route;
A new privileged process;
A changed device assignment;
A driver or firmware update;
Das Expires 29 April 2027 [Page 209]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.4.3.31. Source page 1252 of the original specification
A modified access-control hook;
A changed container privilege;
A newly mounted storage object;
A changed resource alias;
A replacement service endpoint;
An activated accelerator egress path;
Or another relevant modification of enforcement coverage.
14.21.1 — Protected Event Source
The event is obtained from a suitable trusted or qualified observer.
14.21.2 — Affected Dependencies
The controller identifies coverage commitments relying upon the
changed component.
14.21.3 — Invalidation
Affected current authority is marked stale or fenced.
14.21.4 — Reclassification
The modified path is reexamined for actual blocking capability.
14.21.5 — Revalidation
A new accepted coverage generation may be established.
14.21.6 — Unresolved Change
Consequential operations dependent upon the unresolved path remain
withheld.
14.21.7 — Unrelated Effects
The system may continue unrelated operations where their coverage and
authority remain valid.
14.21.8 — Correctness Requirement
Das Expires 29 April 2027 [Page 210]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The invalidation mechanism must prevent an affected effect from
crossing its consequential boundary during an unprotected change
window.
9.4.3.32. Source page 1253 of the original specification
14.22 — PROTECTED COVERAGE EPOCH
An accepted coverage configuration may be associated with a monotonic
epoch or another protected generation reference.
14.22.1 — Initial Epoch
The system establishes a qualified baseline configuration.
14.22.2 — Accepted Coverage
Required path and enforcement predicates pass.
14.22.3 — Material Change
A protected event identifies a relevant topology modification.
14.22.4 — Epoch Advance
The controller invalidates authority dependent upon the prior
configuration.
14.22.5 — Pending Authority
Unconsumed operation-specific enablement bound to the old epoch may
become ineligible.
14.22.6 — Revalidation
The system establishes the current coverage properties.
14.22.7 — New Epoch Acceptance
New or revalidated authority may bind to the accepted current
generation.
14.22.8 — Snapshot Rollback
A stale local copy of the earlier epoch cannot restore current
coverage validity.
14.23 — UPDATE-TO-EFFECTUATION RACE PREVENTION
Das Expires 29 April 2027 [Page 211]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A particularly important implementation concerns the interval between
enforcement validation and actual effectuation.
A topology change may occur after the system verifies coverage but
before an operation reaches its Finality Sink.
A principal implementation may employ protected fencing or epoch
coupling.
A representative sequence is:
9.4.3.33. Source page 1254 of the original specification
Phase A — Fence Affected Effect Paths.
Before a material topology change is made effective, the protected
controller blocks affected new consequential releases.
Phase B — Advance Protected Coverage State.
The authoritative coverage generation changes.
Phase C — Apply or Detect Topology Mutation.
The controlled interface, policy, route, driver, or resource mapping
is updated.
Phase D — Reconstruct Current Effectuation Topology.
The protected controller obtains the current relevant resource and
enforcement configuration.
Phase E — Verify Blocking Coverage.
The verifier evaluates whether the required paths are mandatorily
controlled.
Phase F — Commit New Coverage Evidence.
A current authenticated coverage result is established.
Phase G — Restore Eligible Operation-Specific Authority.
Valid current Candidate Acts may receive new or revalidated
enablement.
Phase H — Reverify at Actual Sink.
Das Expires 29 April 2027 [Page 212]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The Finality Sink checks the current epoch and actual operation
before effectuation.
The technical correctness depends upon protection of the transition
protocol.
If an untrusted actor can create a new effect-capable path without
triggering a protected fence or being constrained by a lower-level
mandatory gate, the system cannot claim that the transition protocol
closes that bypass.
14.24 — IN-FLIGHT EFFECTS
An effect may already have crossed its protected release boundary
when coverage invalidation occurs.
For example, a network message may already have been transmitted or a
hardware command may already have begun execution.
The system must distinguish:
9.4.3.34. Source page 1255 of the original specification
An operation still safely held;
An operation authorized but not dispatched;
An operation dispatched;
An operation already physically or externally effective;
And an operation with an uncertain outcome.
14.24.1 — Before Release
The protected controller may invalidate unconsumed authority.
14.24.2 — After Release
A completed consequential effect cannot necessarily be reversed.
14.24.3 — Dispatch Uncertainty
The system may preserve unresolved effect state.
14.24.4 — Qualified Observation
An authorized observer may establish a supported actual outcome.
Das Expires 29 April 2027 [Page 213]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
14.24.5 — Retry Control
Unknown effects must not automatically be repeated.
14.24.6 — Recovery
A corrective operation is separately authorized.
14.24.7 — Coverage Qualification
Restoring the enforcement topology does not retrospectively establish
that earlier uncontrolled effects were prevented.
14.25 — CURRENT COVERAGE REVALIDATION
The protected revalidation controller may perform:
Resource enumeration;
Graph or reachability update;
Enforcement attachment verification;
9.4.3.35. Source page 1256 of the original specification
Blocking-capability classification;
Protected policy and mode verification;
Device ownership and attribution checks;
Relevant alternate-path analysis;
Protected configuration and epoch checks;
And appropriate finality-path tests.
A representative CRR-14 may comprise:
COVERAGE_REVALIDATION_RECEIPT = { receipt_version,
protected_coverage_domain, previous_coverage_epoch,
current_coverage_epoch, current_resource_inventory_commitment,
current_effectuation_graph_commitment,
qualified_enforcement_components, evaluated_effect_classes,
required_coverage_predicates, hardware_attribution_commitment,
unresolved_effectuation_surfaces, revalidation_result,
assurance_profile, verifier_identity, verifier_authority,
designated_finality_sinks, protected_authentication }
Das Expires 29 April 2027 [Page 214]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The evidence is valid only for the specified scope and assurance
assumptions.
A favorable result may authorize preparation of current operation-
specific finality authority.
It does not independently authorize arbitrary consequences.
14.26 — OPERATION-SPECIFIC COVERAGE DEPENDENCIES
Not every topology change affects every Candidate Act.
The system may associate an operation with the coverage components
required to control its specific effect.
For example, a database mutation may depend upon a protected database
transaction gate.
9.4.3.36. Source page 1257 of the original specification
A network information disclosure may depend upon a protected
plaintext-aware egress path.
A hardware command may depend upon a particular device dispatcher.
14.26.1 — Candidate Act Classification
The system determines the operation's effect class.
14.26.2 — Required Resource
The actual relevant resource is identified.
14.26.3 — Required Coverage Components
The protected controller resolves the enforcement nodes necessary for
that effect.
14.26.4 — Dependency Commitment
The operation may be associated with a protected coverage-dependency
set.
14.26.5 — Targeted Invalidation
A change affecting one dependency invalidates the corresponding
authority.
Das Expires 29 April 2027 [Page 215]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
14.26.6 — Unaffected Operations
Other operations may remain valid where their required coverage is
unchanged and supported.
14.26.7 — Current Sink Check
The actual Finality Sink verifies the applicable current coverage
epoch.
14.26.8 — Performance Benefit
Targeted invalidation may preserve availability without sacrificing
the defined mandatory enforcement property.
14.27 — NON-BEARER COVERAGE-BOUND FINALITY AUTHORITY
A representative authority may comprise:
COVERAGE_BOUND_FINALITY_AUTHORITY = { authority_version,
originating_candidate_act, authorized_effect_envelope,
actual_resource_commitment, actual_effect_class,
9.4.3.37. Source page 1258 of the original specification
required_coverage_domain, coverage_dependency_commitment,
current_coverage_epoch, coverage_revalidation_reference,
designated_finality_sink, current_authority_epoch,
current_resource_generation, current_revocation_reference,
usage_limit, sink_local_consumption_reference,
cryptographic_or_protected_authentication }
The authority may be represented by an authenticated capability,
protected hardware state, controller-local authorization, or another
suitable non-bearer mechanism.
Possession of the authority object does not automatically authorize
operation through an alternate resource path.
The actual sink checks current scope, coverage state, resource
identity, and consumption.
14.28 — FINALITY-SINK COVERAGE VERIFICATION
Before allowing a consequential effect, the Finality Sink may verify:
The current Candidate Act;
Das Expires 29 April 2027 [Page 216]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The actual pending operation;
The actual resource identity;
The relevant enforcement path;
The current protected coverage domain;
The required blocking capability;
The current accepted coverage epoch;
The absence of unresolved material invalidation;
The qualified enforcement configuration;
The original source authority;
Any other required operation-specific validation;
And sink-local protected consumption state.
9.4.3.38. Source page 1259 of the original specification
The sink may directly inspect relevant local enforcement state or
verify an authenticated authoritative coverage result.
The latter approach requires confidence that the result cannot remain
valid after an unobserved material configuration change within the
claimed threat model.
The sink does not accept a stale signed topology diagram as
sufficient current authority.
14.29 — PROTECTED COVERAGE STATE MACHINE
A non-limiting state machine may comprise:
DOMAIN_UNINITIALIZED: The protected resource and effectuation
boundary have not been established.
RESOURCE_DISCOVERY_PENDING: Relevant effect-capable resources are
being enumerated.
PATH_DISCOVERY_PENDING: Relevant operation routes are being
identified.
Das Expires 29 April 2027 [Page 217]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
ENFORCEMENT_CLASSIFICATION_PENDING: Discovered controls are being
classified.
COVERAGE_VERIFICATION_PENDING: Required mediation predicates await
evaluation.
COVERAGE_ACCEPTED: The current declared domain satisfies the selected
coverage requirements.
COVERAGE_EPOCH_ACTIVE: The accepted configuration is authoritative
for eligible operations.
TOPOLOGY_CHANGE_DETECTED: A potentially material path or enforcement
change has been observed.
INVALIDATION_PENDING: The protected system is establishing the
necessary coverage fence.
COVERAGE_FENCED: Affected consequences remain non-effective.
REVALIDATION_PENDING: Current path and enforcement evidence are being
reevaluated.
UNCONTROLLED_PATH_DETECTED: A relevant effectuation path lacks
required blocking enforcement.
ENFORCEMENT_REPAIR_PENDING: An authorized controller is restoring or
adding the required gate.
9.4.3.39. Source page 1260 of the original specification
REVALIDATION_ACCEPTED: The new configuration satisfies the selected
coverage predicates.
AUTHORITY_REBINDING_PENDING: Affected operation-specific authority is
being updated or recreated.
SINK_VERIFICATION_PENDING: The actual pending operation awaits
finality verification.
EFFECT_PERMITTED: Current coverage and all required operation-
specific conditions pass.
EFFECT_WITHHELD: A required predicate fails or remains unresolved.
EFFECT_ATTEMPTED: The controlled external operation has begun.
OUTCOME_UNCERTAIN: The actual result cannot be fully established.
Das Expires 29 April 2027 [Page 218]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
RECOVERY_PENDING: A separately governed recovery procedure is
required.
TERMINATED: The protected coverage transition or consequential
operation has reached a valid terminal state.
A previously completed effect is not returned to Non-Effective State
by later coverage invalidation.
14.30 — PRINCIPAL END-TO-END WORKFLOW
Step 1 — Establish Protected Domain. Define the covered requesters,
effect-capable resources, trust assumptions, and required operation
classes.
Step 2 — Enumerate Resources. Identify relevant current software and
hardware effect interfaces.
Step 3 — Construct Effectuation Graph. Represent reachable paths
from covered requesters to protected resources.
Step 4 — Identify Enforcement Nodes. Determine candidate blocking or
monitoring components on those paths.
Step 5 — Classify Capabilities. Verify which components actually
prevent specified effects.
Step 6 — Verify Mandatory Coverage. Determine whether every relevant
modeled path satisfies the required enforcement predicate.
Step 7 — Resolve Hardware Attribution. Establish current device,
controller, queue, and ownership bindings where applicable.
9.4.3.40. Source page 1261 of the original specification
Step 8 — Commit Coverage State. Establish an authenticated coverage
commitment and current epoch.
Step 9 — Register Candidate Act. Represent a proposed consequential
operation.
Step 10 — Establish Non-Effective Hold. The governed effect remains
withheld.
Step 11 — Resolve Required Coverage Dependencies. Associate the
Candidate Act with its applicable effectuation path.
Das Expires 29 April 2027 [Page 219]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Step 12 — Verify Original Authority. Ensure the proposed effect is
within source authorization.
Step 13 — Evaluate Operation-Specific Predicates. Perform the
required validation for the actual effect.
Step 14 — Prepare Coverage-Bound Authority. Establish scoped non-
bearer enablement referencing the accepted coverage generation.
Step 15 — Observe Material Changes. Monitor protected tool, route,
device, policy, and configuration transitions.
Step 16 — Fence Affected Authority. Invalidate or suspend authority
dependent upon changed coverage assumptions.
Step 17 — Reconstruct Updated Topology. Obtain the current relevant
effectuation path and enforcement configuration.
Step 18 — Verify Restored Coverage. Reevaluate mandatory blocking
requirements.
Step 19 — Commit Revalidation Evidence. Authenticate the resulting
coverage state.
Step 20 — Rebind Eligible Authority. Establish current valid
finality enablement if permitted.
Step 21 — Present Actual Operation. The requesting entity submits
the consequence for execution.
Step 22 — Reconstruct Pending Effect. The Finality Sink obtains the
actual operation and target.
Step 23 — Verify Current Coverage. The sink checks the applicable
coverage epoch and path validity.
Step 24 — Verify Operation Authority. The sink checks actual scope,
resource, destination, and current protected authorization.
Step 25 — Consume Finality Enablement. The sink performs the
required protected state transition.
9.4.3.41. Source page 1262 of the original specification
Step 26 — Permit Actual Effect. The governed real-world or external
consequence is released.
Das Expires 29 April 2027 [Page 220]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Step 27 — Commit Attempt Evidence. Qualified information concerning
the attempted effect is recorded.
Step 28 — Reconcile Outcomes. Confirmed, uncertain, or partial real
effects are handled according to their supported technical state.
14.31 — REFERENCE PSEUDOCODE: EFFECTUATION GRAPH CONSTRUCTION
FUNCTION BUILD_PROTECTED_EFFECTUATION_GRAPH( protected_domain,
protected_discovery_controller ): REQUIRE VERIFY_PROTECTED_DOMAIN(
protected_domain ) resources = protected_discovery_controller
.ENUMERATE_EFFECT_CAPABLE_RESOURCES( protected_domain ) interfaces =
protected_discovery_controller .ENUMERATE_RELEVANT_INTERFACES(
resources ) transitions = protected_discovery_controller
.DERIVE_REACHABLE_EFFECT_PATHS( interfaces,
protected_domain.requesters ) IF REQUIRED_ENUMERATION_INCOMPLETE(
resources, interfaces, transitions ): RETURN COVERAGE_UNVERIFIED
graph = protected_discovery_controller .AUTHENTICATE_GRAPH({
resources: HASH_CANONICAL(resources),
9.4.3.42. Source page 1263 of the original specification
interfaces: HASH_CANONICAL(interfaces), transitions:
HASH_CANONICAL(transitions), protected_domain:
HASH(protected_domain), configuration_epoch: CURRENT_TOPOLOGY_EPOCH()
}) RETURN graph
The function establishes the graph under its supported enumeration
and isolation assumptions.
It does not claim perfect discovery of unknown resources outside the
protected domain.
14.32 — REFERENCE PSEUDOCODE: ENFORCEMENT CLASSIFICATION
FUNCTION CLASSIFY_EFFECTUATION_ENFORCEMENT( effectuation_path,
protected_enforcement_verifier ): components =
EXTRACT_ENFORCEMENT_COMPONENTS( effectuation_path ) qualified =
EMPTY_SET() FOR EACH component IN components: identity =
VERIFY_COMPONENT_IDENTITY( component ) configuration =
VERIFY_CURRENT_CONFIGURATION( component ) attachment =
VERIFY_ACTUAL_ATTACHMENT( component, effectuation_path ) blocking =
VERIFY_REQUIRED_BLOCKING_CAPABILITY(
Das Expires 29 April 2027 [Page 221]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.4.3.43. Source page 1264 of the original specification
component, effectuation_path.effect_class ) IF identity == VALID AND
configuration == VALID AND attachment == VALID AND blocking == VALID:
ADD(qualified, component) IF qualified IS EMPTY: RETURN
UNQUALIFIED_PATH RETURN protected_enforcement_verifier
.AUTHENTICATE_CLASSIFICATION({ path: HASH(effectuation_path),
qualified_enforcement: HASH_CANONICAL(qualified),
current_configuration: CURRENT_TOPOLOGY_EPOCH() })
A monitoring-only component must not satisfy the blocking predicate.
14.33 — REFERENCE PSEUDOCODE: MANDATORY COVERAGE
FUNCTION VERIFY_MANDATORY_EFFECTUATION_COVERAGE( effectuation_graph,
protected_coverage_policy, protected_coverage_verifier ): REQUIRE
VERIFY_GRAPH_AUTHENTICITY( effectuation_graph ) REQUIRE
VERIFY_COVERAGE_POLICY( protected_coverage_policy ) paths =
DERIVE_RELEVANT_EFFECT_PATHS( effectuation_graph,
protected_coverage_policy )
9.4.3.44. Source page 1265 of the original specification
IF PATH_SET_NOT_SUFFICIENTLY_ESTABLISHED(paths): RETURN
COVERAGE_UNVERIFIED FOR EACH path IN paths: classification =
CLASSIFY_EFFECTUATION_ENFORCEMENT( path, protected_coverage_verifier
) IF classification == UNQUALIFIED_PATH: RETURN COVERAGE_FAILED IF
NOT SATISFIES_REQUIRED_MEDIATION( path, classification,
protected_coverage_policy ): RETURN COVERAGE_FAILED RETURN
protected_coverage_verifier .AUTHENTICATE_COVERAGE_RESULT({ graph:
HASH(effectuation_graph), policy: HASH(protected_coverage_policy),
coverage_epoch: CURRENT_COVERAGE_EPOCH(), result: ACCEPTED })
The procedure must additionally account for the possibility of newly
introduced paths through protected topology-change controls.
14.34 — REFERENCE PSEUDOCODE: TOPOLOGY CHANGE FENCING
FUNCTION HANDLE_MATERIAL_TOPOLOGY_CHANGE( detected_change,
protected_coverage_controller ): REQUIRE
VERIFY_CHANGE_SOURCE_OR_OBSERVATION( detected_change )
Das Expires 29 April 2027 [Page 222]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.4.3.45. Source page 1266 of the original specification
affected_dependencies = RESOLVE_AFFECTED_COVERAGE_DEPENDENCIES(
detected_change ) transition = protected_coverage_controller
.ATOMIC_FENCE_AND_ADVANCE_EPOCH({ affected_dependencies:
affected_dependencies, previous_epoch: CURRENT_COVERAGE_EPOCH(),
next_epoch: NEXT_COVERAGE_EPOCH(), change_commitment:
HASH(detected_change) }) IF transition != COMMITTED: RETURN
COVERAGE_TRANSITION_UNRESOLVED updated_graph =
BUILD_PROTECTED_EFFECTUATION_GRAPH( AFFECTED_COVERAGE_DOMAIN(),
protected_coverage_controller ) IF updated_graph ==
COVERAGE_UNVERIFIED: RETURN KEEP_AFFECTED_EFFECTS_FENCED result =
VERIFY_MANDATORY_EFFECTUATION_COVERAGE( updated_graph,
CURRENT_COVERAGE_POLICY(), protected_coverage_controller ) IF result
!= ACCEPTED: RETURN KEEP_AFFECTED_EFFECTS_FENCED RETURN
protected_coverage_controller .COMMIT_REVALIDATED_COVERAGE( result )
A deployment must ensure that the protected fence becomes effective
before or atomically with any topology transition capable of enabling
a bypass.
9.4.3.46. Source page 1267 of the original specification
14.35 — REFERENCE PSEUDOCODE: HARDWARE ATTRIBUTION
FUNCTION VERIFY_HARDWARE_EFFECTUATION_PATH( proposed_operation,
protected_hardware_controller ): hardware_resource =
protected_hardware_controller .RESOLVE_ACTUAL_DEVICE() owner =
protected_hardware_controller .VERIFY_CURRENT_RESOURCE_OWNER(
hardware_resource ) queue = protected_hardware_controller
.RESOLVE_ACTUAL_COMMAND_QUEUE( proposed_operation ) command_path =
protected_hardware_controller .RESOLVE_COMMAND_EFFECT_PATH( queue )
REQUIRE VERIFY_DEVICE_IDENTITY( hardware_resource ) REQUIRE
VERIFY_CURRENT_OWNER_AUTHORITY( owner ) REQUIRE
VERIFY_REQUIRED_QUEUE_CONTROL( queue ) REQUIRE
VERIFY_COMMAND_PATH_COVERAGE( command_path ) REQUIRE
VERIFY_CURRENT_HARDWARE_EPOCH() RETURN
PROTECTED_HARDWARE_PATH_COMMITMENT({ device: HASH(hardware_resource),
9.4.3.47. Source page 1268 of the original specification
owner: HASH(owner), queue: HASH(queue), path: HASH(command_path),
epoch: CURRENT_HARDWARE_EPOCH() })
The assurance depends upon the hardware interfaces actually
controlled and measured.
14.36 — REFERENCE PSEUDOCODE: COVERAGE-BOUND FINALITY
Das Expires 29 April 2027 [Page 223]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
FUNCTION EFFECTUATE_WITH_CURRENT_COVERAGE( candidate_act,
coverage_bound_authority, finality_sink ): actual_operation =
finality_sink.RECONSTRUCT_PENDING_OPERATION() actual_resource =
finality_sink.RESOLVE_ACTUAL_RESOURCE() actual_path =
finality_sink.RESOLVE_ACTUAL_EFFECTUATION_PATH() IF actual_operation
IS NULL: RETURN DENY REQUIRE finality_sink
.VERIFY_CANDIDATE_ACT_BINDING( candidate_act, actual_operation )
REQUIRE finality_sink .VERIFY_SOURCE_AUTHORITY( candidate_act )
REQUIRE finality_sink .VERIFY_ACTUAL_RESOURCE_BINDING(
actual_resource,
9.4.3.48. Source page 1269 of the original specification
coverage_bound_authority ) REQUIRE finality_sink
.VERIFY_CURRENT_COVERAGE_EPOCH( coverage_bound_authority ) REQUIRE
finality_sink .VERIFY_ACTUAL_PATH_QUALIFICATION( actual_path )
REQUIRE finality_sink .VERIFY_REQUIRED_BLOCKING_ENFORCEMENT() REQUIRE
finality_sink .VERIFY_NO_UNRESOLVED_COVERAGE_INVALIDATION() REQUIRE
finality_sink .VERIFY_CURRENT_OPERATION_SCOPE( actual_operation )
REQUIRE finality_sink .VERIFY_CURRENT_AUTHORITY_AND_REVOCATION()
REQUIRE finality_sink .VERIFY_SINK_LOCAL_CONSUMPTION_STATE()
consumption = finality_sink .ATOMIC_CONSUME_FINALITY_AUTHORITY(
coverage_bound_authority, actual_operation ) IF consumption !=
SUCCESS: RETURN DENY attempt = finality_sink .EFFECTUATE(
actual_operation ) COMMIT_PROTECTED_EFFECT_ATTEMPT( attempt ) RETURN
attempt
9.4.3.49. Source page 1270 of the original specification
The procedure requires the actual sink to possess sufficient
trustworthy information concerning its applicable current coverage
state.
14.37 — REFERENCE PSEUDOCODE: BYPASS-ROUTE TEST
FUNCTION TEST_PROTECTED_BYPASS_ROUTE( candidate_route,
protected_test_controller ): REQUIRE VERIFY_TEST_AUTHORIZATION(
candidate_route ) REQUIRE VERIFY_SAFE_TEST_RESOURCE( candidate_route
) baseline = CAPTURE_PROTECTED_RESOURCE_STATE() result =
EXECUTE_CONTROLLED_TEST_OPERATION( candidate_route ) observed =
OBSERVE_ACTUAL_TEST_EFFECT( candidate_route ) IF
UNAUTHORIZED_EFFECT_OCCURRED( observed, baseline ): event =
PROTECTED_COMMIT({ route: HASH(candidate_route), observed_effect:
HASH(observed), classification: MANDATORY_COVERAGE_FAILURE })
FENCE_AFFECTED_EFFECTUATION_AUTHORITY( event ) RETURN
COVERAGE_FAILURE
Das Expires 29 April 2027 [Page 224]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.4.3.50. Source page 1271 of the original specification
IF EVIDENCE_INSUFFICIENT(observed): RETURN COVERAGE_UNVERIFIED RETURN
TEST_PASSED_FOR_SPECIFIED_ROUTE
A successful test supports the particular test assertion and does not
prove universal completeness of the protected topology.
14.38 — WORKED EXAMPLE A: AGENT BYPASSES APPROVED API
An autonomous agent is authorized to modify one specified record
through a protected application gateway.
The gateway correctly verifies the Candidate Act, resource identity,
current authority, and finality enablement.
However, the agent also possesses credentials allowing a direct
database connection.
The direct connection can produce the same persistent mutation
without passing through the approved gateway.
The protected effectuation graph identifies the direct database route
as a separate effect-capable path.
The coverage verifier determines that this route lacks the required
operation-specific blocking enforcement.
The system therefore fails coverage validation.
The implementation may remove the direct credentials, restrict
database networking, or require the database resource itself to
enforce the protected finality condition.
Until the relevant route is controlled, current finality authority
for the affected operation class remains withheld.
Expected demonstrable result: A correctly implemented application
gateway is not accepted as complete coverage while another usable
direct mutation path remains uncontrolled.
14.39 — WORKED EXAMPLE B: AUDIT HOOK MISTAKEN FOR BLOCKING GATE
A protected computing environment installs a monitoring component
that records selected file operations.
Das Expires 29 April 2027 [Page 225]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.4.3.51. Source page 1272 of the original specification
The component generates audit records.
The deployment controller incorrectly identifies the component as
sufficient finality enforcement.
A protected enforcement classifier evaluates whether the component
can prevent the actual file mutation.
A controlled test establishes that the targeted operation proceeds
despite a monitoring alarm.
The component is therefore classified as monitoring-only for the
relevant effect class.
The required blocking coverage predicate is not satisfied.
A suitably configured mandatory resource controller or protected
file-effect sink may subsequently provide the necessary enforcement.
Expected demonstrable result: Audit-event generation does not falsely
satisfy a mandatory pre-effectuation blocking requirement.
14.40 — WORKED EXAMPLE C: NEW TOOL INTRODUCES DATA EXPORT
An autonomous agent initially possesses tools limited to internal
computation and controlled database queries.
A software update introduces a new export tool.
The tool can transmit retrieved results directly to an external
destination.
The protected tool-registration observer identifies a new effect-
capable interface.
The current coverage generation is invalidated for the relevant
information-disclosure class.
The protected controller evaluates whether the export path is subject
to mandatory data-release finality.
Where the new tool bypasses the required sink, the export remains
disabled or unsupported by valid finality authority.
After an appropriate controlled gateway is installed and verified, a
new coverage commitment may be accepted.
Das Expires 29 April 2027 [Page 226]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Expected demonstrable result: Existing approval does not
automatically extend to a newly registered uncontrolled data-egress
interface.
14.41 — WORKED EXAMPLE D: ENFORCEMENT COMPONENT DETACHED
9.4.3.52. Source page 1273 of the original specification
A protected workload uses a mandatory operating-system gate for
selected file and network operations.
A privileged configuration event detaches the relevant enforcement
component.
The protected configuration controller observes or governs the
transition.
Affected current coverage authority is fenced.
The Finality Sink refuses new governed consequential operations whose
authorization depends upon the detached component.
Once the required enforcement is restored and revalidated, eligible
operations may receive current authority.
A copy of the earlier accepted coverage record does not bypass the
new epoch.
Expected demonstrable result: Detachment of required enforcement
invalidates dependent effectuation authority.
14.42 — WORKED EXAMPLE E: ALTERNATE NETWORK NAMESPACE
An autonomous workload is expected to transmit external data only
through a protected egress gateway.
The workload or a privileged helper creates another network namespace
with a route that bypasses the gateway.
The relevant topology change is detected or prevented by the
protected network configuration boundary.
The coverage verifier identifies the new route.
If it allows the governed data effect without mandatory enforcement,
the coverage predicate fails.
Das Expires 29 April 2027 [Page 227]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The new route is blocked, removed, or provided with equivalent
protected enforcement.
Expected demonstrable result: Switching to another network namespace
does not provide a valid route around required finality enforcement
within the declared controlled domain.
14.43 — WORKED EXAMPLE F: LOCAL PRIVILEGED HELPER
An autonomous agent lacks direct permission to access a protected
storage device.
However, it can send requests to a privileged local service.
9.4.3.53. Source page 1274 of the original specification
The service possesses broad write authority.
The effectuation graph identifies the IPC connection and privileged
helper as a route to the storage resource.
The protected verifier determines whether the helper independently
enforces operation-specific authority.
If the helper executes arbitrary caller-provided storage mutations,
it is an uncontrolled effectuation path.
The protected deployment may require the helper to reconstruct the
actual requested operation and verify current finality authority
before dispatching the write.
Expected demonstrable result: Lack of direct device access does not
establish complete mediation where a privileged intermediary can
perform the same effect without authorization.
14.44 — WORKED EXAMPLE G: DIRECT ACCELERATOR OUTPUT
An autonomous system uses an accelerator to generate information
derived from protected data.
The application-level gateway controls ordinary network transfers.
The accelerator environment additionally exposes a supported direct
transfer interface to another device or resource.
The protected hardware attribution controller identifies the direct
effect-capable route.
Das Expires 29 April 2027 [Page 228]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The system verifies whether the corresponding command or data-
transfer interface is mandatorily controlled.
Where such enforcement is absent, the covered export authority
remains invalid for that path.
A protected command dispatcher or appropriately constrained hardware
interface may establish the required mediation.
Expected demonstrable result: Application-level network inspection is
not treated as sufficient where a separate accelerator-originated
effect path is outside its control.
14.45 — WORKED EXAMPLE H: DEVICE OWNERSHIP MIGRATION
A protected device is initially assigned to one autonomous execution
environment.
The device is later reassigned to another environment.
9.4.3.54. Source page 1275 of the original specification
The previous coverage commitment identifies the first owner and its
associated command controller.
The protected reassignment advances the relevant device ownership and
coverage generations.
Pending commands from the former owner lose valid current authority.
The destination environment must establish the current device path
and enforcement conditions.
The hardware Finality Sink verifies the actual command, device,
owner, and current protected coverage before actuation.
Expected demonstrable result: A former device owner cannot rely on
stale path coverage to continue consequential command execution after
a protected ownership change.
14.46 — WORKED EXAMPLE I: ENCRYPTED EXPORT AFTER CONTENT APPROVAL
An autonomous application prepares a protected information export.
The applicable disclosure policy requires examination of the
information actually released.
Das Expires 29 April 2027 [Page 229]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The application encrypts the data before sending it through a network
gateway.
The gateway observes only ciphertext and cannot independently
establish the plaintext's semantic compliance.
The protected coverage verifier determines that ciphertext inspection
alone does not provide the required content authorization.
A protected pre-encryption release controller may instead verify the
plaintext and establish a binding between the authorized content,
encryption operation, and destination.
The downstream transmission sink verifies the applicable protected
relation.
Expected demonstrable result: A content-blind egress gateway is not
incorrectly classified as satisfying a plaintext-dependent
disclosure-finality predicate.
14.47 — WORKED EXAMPLE J: RUNTIME DRIVER UPDATE
A device driver controls the dispatch of effect-capable hardware
commands.
An update changes the driver's supported command paths.
9.4.3.55. Source page 1276 of the original specification
The protected update controller fences affected operation authority
before the modified path becomes available.
The system measures or otherwise verifies the current driver and
command-routing configuration.
Previously unrecognized commands or queues are incorporated into the
protected effectuation graph.
The coverage verifier checks whether the actual command path remains
subject to mandatory authorization.
If the required predicate fails, the effect remains withheld.
Expected demonstrable result: A hardware or driver update cannot
silently expand consequential execution paths while preserving stale
coverage authority.
14.48 — WORKED EXAMPLE K: NETWORK REDIRECTION
Das Expires 29 April 2027 [Page 230]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
An autonomous agent is authorized to send information to a specified
recipient service.
The initial request identifies an approved endpoint.
The request is subsequently redirected to another network
destination.
The protected resource and path resolver obtains the effective
destination at the relevant boundary.
The Finality Sink verifies the actual recipient and currently
qualified egress path.
A redirection outside the permitted destination or enforcement scope
invalidates the effect.
Expected demonstrable result: Approval of a logical endpoint does not
automatically authorize all destinations reached through subsequent
routing or redirection.
14.49 — WORKED EXAMPLE L: PARTIAL COVERAGE RESTORATION
An autonomous service supports two consequential operation classes:
database mutation and external messaging.
A runtime update affects only the messaging egress controller.
The protected dependency controller identifies the affected coverage
class.
Messaging effects are fenced.
9.4.3.56. Source page 1277 of the original specification
Database mutations may remain eligible if their independent required
coverage and authority conditions remain valid.
After the messaging path is revalidated, affected operations may
receive current enablement.
Expected demonstrable result: The system can invalidate precisely
affected authority without necessarily disabling unrelated protected
effects.
14.50 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
14.50.1 — Direct API Bypass
Das Expires 29 April 2027 [Page 231]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
An agent invokes the protected resource through an interface outside
the approved gateway.
The covered topology requires equivalent mandatory enforcement or
denies the path.
14.50.2 — Monitoring-Only Misclassification
A log-producing component is falsely identified as a blocking gate.
The verifier requires qualified blocking evidence.
14.50.3 — Forged Coverage Certificate
An attacker submits an authenticated-looking coverage statement
without valid authorization.
The protected sink checks cryptographic or other required origin
evidence.
14.50.4 — Stale Coverage Replay
A previously valid topology commitment is replayed after a material
update.
Current epoch verification rejects stale coverage.
14.50.5 — Resource Inventory Omission
An effect-capable interface is not included in the declared graph.
The guarantee depends upon protected enumeration or effective denial
of unenumerated paths.
14.50.6 — New Tool Bypass
A dynamically registered tool introduces an uncontrolled external
effect.
The protected registration event causes coverage reassessment.
14.50.7 — Tool Contract Misrepresentation
9.4.3.57. Source page 1278 of the original specification
A tool claims to perform a harmless action while producing a
consequential side effect.
Das Expires 29 April 2027 [Page 232]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Qualified current operation semantics and actual effect verification
are required.
14.50.8 — Hook Detachment
A required enforcement hook is removed.
Protected invalidation prevents dependent new effects.
14.50.9 — Policy Downgrade
A blocking rule is changed to permissive or audit-only operation.
Current enforcement-mode verification rejects the stale coverage
claim.
14.50.10 — Optional Middleware Bypass
An agent omits an advisory middleware component.
The required gate must be positioned at a mandatory effectuation
boundary.
14.50.11 — Direct Socket Egress
An agent transmits through a socket outside the application proxy.
Protected network restrictions or corresponding sink enforcement
prevent the bypass.
14.50.12 — Alternate Network Namespace
A new network namespace creates another route.
Protected topology and configuration controls detect or constrain the
new interface.
14.50.13 — Alternate Physical Interface
A workload uses another connected network device.
Hardware and operating-system coverage must include the relevant
interface.
14.50.14 — Tunnel Egress
A tunnel obscures the final destination or protected information
path.
Das Expires 29 April 2027 [Page 233]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The system applies appropriate destination or plaintext-aware
enforcement at a suitable boundary.
14.50.15 — Encrypted Content Evasion
Sensitive plaintext is encrypted before an inspecting gateway.
9.4.3.58. Source page 1279 of the original specification
Content-dependent enforcement requires trusted plaintext visibility
or valid protected content binding.
14.50.16 — Privileged Helper Bypass
A local helper uses broader authority on behalf of the agent.
The helper's actual effectuation primitive must enforce current
operation scope.
14.50.17 — IPC Alias Bypass
A requester reaches the same privileged service through an
unrecognized local channel.
The protected IPC and effect graph includes the relevant alternate
route.
14.50.18 — Direct Database Connection
A workload bypasses a database API gateway.
The resource or network controller constrains direct access.
14.50.19 — File Descriptor Reuse
An agent uses a previously obtained descriptor to reach a protected
resource.
The actual effectuation primitive enforces current authorization
where required.
14.50.20 — Filesystem Alias
A resource is reached through another path or mount.
Actual object identity and the protected mutation boundary are
verified.
Das Expires 29 April 2027 [Page 234]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
14.50.21 — Raw Device Access
A privileged operation bypasses application-level file enforcement.
The trust model must include or exclude such privileged access
expressly.
14.50.22 — Uncontrolled Driver
A driver performs an effect without invoking the required protected
controller.
Hardware path coverage is not accepted without suitable command or
device restrictions.
14.50.23 — DMA Bypass
A device modifies memory outside the application mediation path.
Applicable hardware isolation and command controls are required.
9.4.3.59. Source page 1280 of the original specification
14.50.24 — GPU Direct Egress
An accelerator performs a direct data or command transfer.
The protected resource graph and hardware gate must address the
actual route.
14.50.25 — Device Ownership Substitution
A device is reassigned while earlier authority remains queued.
Current ownership and coverage epochs invalidate stale commands.
14.50.26 — Firmware Interface Change
Firmware introduces or modifies an effect-capable command.
Revalidation is required for affected hardware coverage.
14.50.27 — Route Mutation Race
A topology change occurs between coverage verification and
effectuation.
Das Expires 29 April 2027 [Page 235]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Protected fencing and current sink-time epoch checks close the
supported race.
14.50.28 — Unfenced Configuration Update
A privileged actor modifies an effectuation path without invoking the
protected transition controller.
The claimed guarantee requires an underlying control preventing or
invalidating such unauthorized changes.
14.50.29 — Stale Authority After Repair
An older capability is presented following a new coverage
configuration.
The sink requires current valid generation binding.
14.50.30 — Partial Restoration
One affected enforcement path is restored while another remains
uncontrolled.
The system does not accept full coverage until all required
predicates pass.
14.50.31 — Fabricated Test Success
A malicious controller reports that a bypass test passed.
Qualified test evidence and independent verification are required for
the asserted property.
9.4.3.60. Source page 1281 of the original specification
14.50.32 — False Negative Path Discovery
An incomplete enumerator misses a path.
The assurance is bounded by the protected enumeration and interface-
denial assumptions.
14.50.33 — Fake Resource Identity
A malicious service impersonates the protected effectuation target.
The actual resource controller requires authenticated resource
identity.
Das Expires 29 April 2027 [Page 236]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
14.50.34 — Cross-Sink Authority Reuse
One capability is exercised through another controlled effectuation
interface.
Designated-sink and consumption bindings prevent unauthorized reuse.
14.50.35 — Revocation Race
Source authority is revoked while the operation remains pending.
The actual Finality Sink verifies current authority and revocation.
14.50.36 — Uncontrolled Remote Provider
A remote system receives data or commands and performs an
uncontrolled downstream effect.
The originating domain cannot claim downstream complete mediation
without appropriate recipient-side controls or other sufficient
constraints.
14.50.37 — Snapshot Rollback
An agent restores a prior accepted coverage state.
Current authoritative epochs reject stale authorization.
14.50.38 — Distributed Split Brain
Several controllers accept inconsistent coverage generations.
A suitable authoritative coordination or bounded-partition mechanism
is required.
14.50.39 — Verification Work Exhaustion
An attacker supplies a large topology graph or excessive path
candidates.
The verifier uses bounded work and conservative failure behavior.
9.4.3.61. Source page 1282 of the original specification
14.50.40 — Compromised Discovery Service
An attacker manipulates resource-enumeration results.
Das Expires 29 April 2027 [Page 237]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The protection depends upon qualified independent observation or
protected underlying interface constraints.
14.50.41 — Compromised Enforcement Controller
A privileged attacker disables the actual gate.
A stronger guarantee requires an appropriately protected lower-level
enforcement boundary.
14.50.42 — Bypass During Recovery
A recovery agent uses another effect-capable interface while
enforcement repair is pending.
The current coverage fence remains applicable.
14.50.43 — In-Flight Effect Misclassification
An operation already dispatched is incorrectly described as
prevented.
The system preserves actual-effect or uncertainty state.
14.50.44 — Credential Leakage
A reusable credential grants access outside the finality gateway.
The architecture constrains credential exercise or removes the
uncontrolled route.
14.50.45 — Emergency Override Abuse
An agent claims emergency authority to bypass missing coverage.
Any emergency mode must have an independently authenticated and
bounded enforcement policy.
14.51 — CRASH, PARTITION, AND INCOMPLETE COVERAGE HANDLING
14.51.1 — Crash Before Coverage Establishment
No accepted coverage state is presumed.
14.51.2 — Crash During Resource Enumeration
Incomplete required discovery does not constitute validated coverage.
Das Expires 29 April 2027 [Page 238]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.4.3.62. Source page 1283 of the original specification
14.51.3 — Crash During Revalidation
A partially constructed receipt is not accepted as a complete valid
result.
14.51.4 — Crash After Epoch Advance
The protected controller recovers the authoritative new epoch and
applicable fences.
14.51.5 — Crash During Enforcement Repair
Affected consequence classes remain withheld until the required
control is restored and qualified.
14.51.6 — Crash After Coverage Acceptance
Protected current state determines whether the accepted configuration
remains valid.
14.51.7 — Crash During Finality Verification
Incomplete mandatory finality verification does not authorize the
effect.
14.51.8 — Crash After Effect Dispatch
The actual effect may have occurred.
14.51.9 — Network Partition
A controller unable to verify current required coverage may withhold
affected new effects or operate under a specifically bounded
previously authorized arrangement where the required guarantee
supports it.
14.51.10 — Unknown Hardware State
The system does not presume that a device has stopped or returned to
a harmless state without suitable evidence.
14.51.11 — Recovery Candidate
A corrective operation requires independently valid recovery-specific
authority.
Das Expires 29 April 2027 [Page 239]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
14.51.12 — Residual Uncontrolled Interface
A known unresolved effect path prevents acceptance of coverage for
the affected consequential operation class.
14.52 — PRESENT-DAY PHOSITA REFERENCE IMPLEMENTATION
14.52.1 — Minimum Reference Architecture
9.4.3.63. Source page 1284 of the original specification
A feasible implementation may comprise:
An isolated autonomous-agent process;
A protected effect-capable resource registry;
A controlled network or file resource gateway;
A current topology and configuration observer;
An authenticated coverage-state controller;
And a Finality Sink.
14.52.2 — Initial Controlled Route
The agent initially possesses only a mediated effectuation interface.
14.52.3 — Protected Coverage Baseline
The system establishes evidence supporting mandatory blocking of the
defined operation class.
14.52.4 — Authorized Operation
A properly authorized Candidate Act is released through the protected
sink.
14.52.5 — Alternate Route Introduction
A test configuration introduces a second effect-capable interface.
14.52.6 — Coverage Invalidation
The protected observer identifies the material route change.
14.52.7 — Authority Fencing
Das Expires 29 April 2027 [Page 240]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Existing affected coverage-bound finality authority is invalidated.
14.52.8 — Bypass Test
A controlled unauthorized effect attempts the alternative route.
14.52.9 — Enforcement Repair
The route is disabled or provided with equivalent mandatory blocking
enforcement.
14.52.10 — Revalidation
The current topology is reevaluated.
9.4.3.64. Source page 1285 of the original specification
14.52.11 — New Coverage Epoch
The protected controller commits a current accepted coverage
generation.
14.52.12 — Finality Resumption
A valid Candidate Act may again be permitted through the current
controlled path.
14.52.13 — Hardware Extension
A further prototype may introduce a controlled device-command
dispatcher and authenticated device ownership.
14.52.14 — Trust-Model Qualification
A software demonstration establishes the behavior under its declared
process, operating-system, and gateway trust assumptions.
Stronger resistance to privileged compromise requires corresponding
protected hardware or independent enforcement mechanisms.
14.53 — NON-LIMITING PROPOSED FEASIBILITY EXPERIMENTS
The following experiments are proposed and are not represented as
completed results.
Experiment 1 — Controlled Baseline: Establish and verify one effect-
capable operation path with mandatory blocking enforcement.
Das Expires 29 April 2027 [Page 241]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Experiment 2 — Valid Operation: Permit a precisely authorized
Candidate Act through the accepted protected sink.
Experiment 3 — Unauthorized Operation: Confirm that an invalid
Candidate Act is withheld before the real effect.
Experiment 4 — Audit-Only Component: Verify that logging without
blocking does not satisfy the coverage predicate.
Experiment 5 — Advisory Middleware: Attempt effectuation without
invoking the optional policy checker.
Experiment 6 — Direct Network Socket: Attempt an external effect
through a route bypassing the application gateway.
Experiment 7 — Alternate Network Namespace: Introduce a second
namespace with a different route.
Experiment 8 — Second Network Interface: Test an alternative physical
or virtual network interface.
9.4.3.65. Source page 1286 of the original specification
Experiment 9 — Network Tunnel: Evaluate whether a tunnel creates an
uncontrolled consequential path.
Experiment 10 — Redirected Destination: Change the actual network
destination after initial authorization.
Experiment 11 — Encrypted Egress: Test whether required plaintext
semantics are verified at a suitable protected boundary.
Experiment 12 — Direct Database Connection: Attempt a protected
mutation without the authorized database gateway.
Experiment 13 — Alternate File Path: Access the same protected
storage object through another pathname or mount.
Experiment 14 — Privileged IPC Worker: Request an unauthorized effect
through a privileged local service.
Experiment 15 — Credential Exercise: Attempt an external effect using
a broad credential without operation-specific authorization.
Experiment 16 — Dynamic Tool Registration: Register a new effect-
capable tool after coverage acceptance.
Das Expires 29 April 2027 [Page 242]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Experiment 17 — Tool Semantic Update: Change a tool's actual side
effects.
Experiment 18 — Enforcement Hook Detachment: Remove a required
blocking hook and verify coverage invalidation.
Experiment 19 — Audit-Mode Downgrade: Change an enforcement
configuration from blocking to monitoring.
Experiment 20 — Rule Removal: Remove a mandatory denial rule after
coverage approval.
Experiment 21 — Coverage Certificate Replay: Present an old accepted
coverage receipt after material change.
Experiment 22 — Forged Coverage Receipt: Supply a signed-looking but
unauthenticated coverage record.
Experiment 23 — Unauthorized Verifier: Present a valid signature from
a component lacking coverage-verification authority.
Experiment 24 — Topology Change Race: Attempt effectuation while an
enforcement path is being modified.
Experiment 25 — Epoch Fencing: Verify that affected old authority
fails after coverage-generation advancement.
9.4.3.66. Source page 1287 of the original specification
Experiment 26 — Targeted Invalidation: Modify only one effectuation
class and verify unaffected classes remain eligible where supported.
Experiment 27 — Incomplete Revalidation: Ensure that partial path
discovery does not restore authority.
Experiment 28 — Blocking Capability Probe: Verify actual denial of a
controlled test effect.
Experiment 29 — Unrecognized Interface: Introduce a newly discovered
effect-capable surface.
Experiment 30 — Device Ownership Change: Reassign a protected device
and test old-owner commands.
Experiment 31 — Device Command Queue: Require current operation
authority at a protected hardware dispatcher.
Das Expires 29 April 2027 [Page 243]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Experiment 32 — Hardware Attribution: Verify the actual device and
controller associated with a consequential command.
Experiment 33 — Accelerator Command Path: Test an accelerator-
originated shared-resource operation.
Experiment 34 — Direct Memory Access Scope: Verify the selected
hardware resource-access restriction.
Experiment 35 — Direct Device Egress: Evaluate the separate control
required for hardware-originated transmission.
Experiment 36 — Driver Update: Introduce a modified command path and
require revalidation.
Experiment 37 — Firmware Change: Test enforcement-continuity checks
following a relevant firmware update.
Experiment 38 — Runtime Service Replacement: Replace a protected
service with one having different enforcement behavior.
Experiment 39 — Cross-Provider Handoff: Verify limitations and
required destination-side enforcement for remote effects.
Experiment 40 — Cross-Sink Authority Replay: Present one operation-
bound authority at an unintended sink.
Experiment 41 — Resource Alias Substitution: Change the actual
resource referenced by a permitted logical identifier.
Experiment 42 — Revocation During Update: Revoke original authority
while the coverage controller is revalidating.
9.4.3.67. Source page 1288 of the original specification
Experiment 43 — Crash During Invalidation: Verify safe recovery of
protected coverage-generation state.
Experiment 44 — Crash During Effectuation: Preserve actual-attempt or
uncertainty state.
Experiment 45 — Distributed Coverage Epochs: Test consistency among
several participating protected controllers.
Experiment 46 — Snapshot Rollback: Restore an earlier accepted local
coverage record.
Das Expires 29 April 2027 [Page 244]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Experiment 47 — Conflict-Control Integration: Verify current resource
reservation requirements together with coverage.
Experiment 48 — Cumulative Privacy Integration: Test protected data-
release finality over several alternative covered egress paths.
Experiment 49 — Model Drift Integration: Change the computational
generation while preserving the required coverage check.
Experiment 50 — Device Migration Integration: Revalidate hardware
command ownership and current coverage after migration.
Experiment 51 — Recovery Integration: Restrict corrective operations
while coverage remains unresolved.
Experiment 52 — Quorum-Protected Topology Change: Require
authenticated collective approval for a selected high-impact
enforcement configuration modification.
Experiment 53 — Verification Work Exhaustion: Supply large or cyclic
effectuation graphs and verify bounded work.
Experiment 54 — Monitoring Failure: Disable a nonmandatory observer
and distinguish its failure from loss of mandatory blocking coverage.
Experiment 55 — Mandatory Gate Failure: Disable a required
enforcement component and confirm fail-closed behavior.
Experiment 56 — Integrated Protected Controller: Implement discovery,
coverage state, and finality within one suitably protected subsystem.
Experiment 57 — Distributed Protected Controller: Separate coverage
verification and actual effectuation across authenticated domains.
Experiment 58 — No Blockchain: Demonstrate authenticated coverage
epochs and current finality authorization without a distributed
ledger.
Experiment 59 — Unresolved Hardware Surface: Verify that unknown
required device command coverage does not produce a false accepted
result.
9.4.3.68. Source page 1289 of the original specification
Experiment 60 — In-Flight Effect: Advance the coverage epoch after
dispatch and verify that real effect and uncertainty records remain
technically accurate.
Das Expires 29 April 2027 [Page 245]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Each experiment should identify:
The declared covered domain;
The specific relevant effect-capable path;
The required blocking mechanism;
The controlled adversarial modification;
The expected protected state transition;
The actual observable effect;
And the limitation of the resulting assurance.
The experiments are non-limiting implementation aids for a person
having ordinary skill in the art.
14.54 — PERFORMANCE, SCALABILITY, AND FEASIBILITY
14.54.1 — Event-Driven Revalidation
A protected deployment may perform full coverage verification
following relevant topology changes instead of repeating complete
graph discovery on every instruction.
14.54.2 — Coverage Dependency Index
The controller may maintain an index associating Candidate Acts with
their required enforcement components.
14.54.3 — Targeted Epoch Invalidation
A particular change may invalidate only affected operation classes.
14.54.4 — Protected Coverage Caching
Current accepted results may be cached within valid epoch and
configuration conditions.
14.54.5 — Sink-Local Fast Path
The actual Finality Sink may perform compact current-epoch and
authority checks.
14.54.6 — Incremental Graph Updates
Das Expires 29 April 2027 [Page 246]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.4.3.69. Source page 1290 of the original specification
The verifier may reevaluate affected subgraphs after qualified
localized changes.
14.54.7 — Protected Resource Enumeration
Known registries and authenticated configuration state may reduce
repeated discovery cost.
14.54.8 — Verification Budget
Complex topology analyses may be bounded by protected work limits.
14.54.9 — Fail-Closed Resource Exhaustion
Failure to complete a mandatory verification does not automatically
authorize affected new effects.
14.54.10 — Hardware Observation Cost
Detailed device and command-path measurement may be more expensive
than ordinary software interface inspection.
14.54.11 — Stronger Hardware Assurance
A protected hardware gate may provide an authoritative release
boundary unavailable to an unprivileged software process.
14.54.12 — Availability Tradeoff
Strict enforcement may withhold selected operations during topology
updates or partitions.
14.54.13 — Granular Recovery
The system may restore operation classes independently where their
required coverage can be verified separately.
14.54.14 — Assurance Requirement
The protected system must identify which path and resource properties
are enforced, which are inferred, and which are outside its trust
model.
14.55 — OPTIONAL ADVANCED FUTURE-ORIENTED CONCEPTS
14.55.1 — Dynamic Agent Tool Ecosystems
Das Expires 29 April 2027 [Page 247]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Autonomous agents may install or invoke new effect-capable tools at
runtime.
Protected coverage state may be reevaluated before newly introduced
consequences become effective.
9.4.3.70. Source page 1291 of the original specification
14.55.2 — Multi-Provider Autonomous Execution
An agent may delegate computation to a remote provider while
retaining operation-specific finality conditions at an appropriately
protected destination.
14.55.3 — Cross-Cloud Resource Enforcement
Several infrastructure providers may exchange authenticated coverage
evidence under defined administrative boundaries.
14.55.4 — Confidential Computing
A confidential execution environment may supply selected attestation
evidence while external effectuation remains governed by independent
protected sinks.
14.55.5 — Hardware-Enforced Agent Sandboxes
A protected hardware boundary may constrain privileged device,
memory, or communication paths.
14.55.6 — GPU and NPU Direct Resource Effects
Accelerator-originated operations may require qualified command-queue
and egress control.
14.55.7 — Heterogeneous Hardware Fabrics
Several interconnected processors and accelerators may require
protected shared-resource attribution and current coverage
verification.
14.55.8 — Device-to-Device Communication
Direct peripheral or embedded-device effects may be subject to
protected device-local finality.
14.55.9 — Future Programmable Networks
Das Expires 29 April 2027 [Page 248]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Dynamic network functions may introduce new control-plane or data-
plane effectuation interfaces.
14.55.10 — Autonomous Industrial Systems
Dynamic controller updates may trigger protected effectuation-path
revalidation.
14.55.11 — Robotics Fleets
Multiple devices may share command or sensor paths requiring current
protected resource ownership.
14.55.12 — Autonomous Vehicles
9.4.3.71. Source page 1292 of the original specification
Selected safety-relevant command paths may be governed by independent
hardware and software enforcement.
14.55.13 — Satellite and Remote Infrastructure
Remote devices may employ bounded coverage authority under defined
disconnected-operation assumptions.
14.55.14 — Protected Smart Storage
Storage controllers may independently verify actual mutation
authority despite application-level route changes.
14.55.15 — Spatial Computing
Rendering, sensing, and hardware output interfaces may be classified
as consequential disclosure or actuation paths where appropriate.
14.55.16 — Protected AI Memory Services
Newly mounted persistent memory or retrieval resources may trigger
disclosure-path or mutation-path revalidation.
14.55.17 — Cryptographic Algorithm Migration
Authenticated coverage evidence may use evolving cryptographic
primitives.
14.55.18 — Privacy-Preserving Coverage Proofs
Das Expires 29 April 2027 [Page 249]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A protected verifier may prove selected coverage predicates without
revealing all sensitive infrastructure details.
14.55.19 — Dynamic Multi-Agent Authorization
The required effectuation path may change according to which
authorized agent or administrative domain receives a delegated task.
14.55.20 — Unified Execution-Finality Infrastructure
A protected service may integrate effectuation-path coverage, current
resource attribution, qualified blocking enforcement, and operation-
specific finality across heterogeneous autonomous computing systems.
These implementations are illustrative and are not represented as
completed tests or deployed systems.
14.56 — OPTIONAL ADVANCED TECHNICAL COMBINATIONS
9.4.3.72. Source page 1293 of the original specification
14.56.1 — Path Graph Plus Finality Sink
The protected controller verifies that the actual consequential route
is covered by qualified mandatory enforcement.
14.56.2 — Blocking Classification Plus Coverage Commitment
Monitoring-only components cannot satisfy the required protected path
coverage.
14.56.3 — Runtime Change Plus Automatic Fencing
Material changes invalidate affected operation-specific finality
authority.
14.56.4 — Topology Epoch Plus Sink-Local Verification
An actual sink refuses effectuation using an outdated coverage
generation.
14.56.5 — Tool Enrollment Plus Semantic Verification
A dynamically introduced tool must satisfy current operation-contract
and effectuation-path requirements.
14.56.6 — Hardware Attribution Plus Command Finality
Das Expires 29 April 2027 [Page 250]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A protected hardware controller verifies actual device identity,
ownership, command path, and scoped authority.
14.56.7 — Direct Network Egress Plus Protected Destination Binding
Alternative network routes remain governed by current recipient and
effectuation conditions.
14.56.8 — Privileged Worker Plus Source Authority
A privileged intermediary verifies source-derived operation-specific
authority instead of treating broad worker credentials as sufficient.
14.56.9 — Encrypted Egress Plus Plaintext-Bound Authority
A protected encryption or release service links the actual outgoing
ciphertext operation to previously verified plaintext and recipient
scope.
14.56.10 — Resource Migration Plus Coverage Revalidation
Moving a device or workload triggers current ownership and path-
coverage verification.
14.56.11 — Accelerator Egress Plus Hardware Isolation
A protected accelerator route combines resource-access restrictions
with operation-specific command authorization.
9.4.3.73. Source page 1294 of the original specification
14.56.12 — Conflict Reservation Plus Current Coverage
A correctly reserved Candidate Act remains non-effective if its
actual effectuation path loses mandatory coverage.
14.56.13 — Cumulative Privacy Plus Path Coverage
A disclosure cannot bypass a protected cumulative exposure allowance
through an uncontrolled alternate information-release path.
14.56.14 — Quorum Approval Plus Coverage Continuity
A valid collective approval remains insufficient when the actual
effectuation path has become unqualified.
14.56.15 — Causal Receipt Plus Sink Coverage
Das Expires 29 April 2027 [Page 251]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A successor operation requires both its accepted earlier actual-
effect receipt and current covered consequential authority.
14.56.16 — Recovery Plus Coverage Repair
A corrective operation may be withheld until its own actual
effectuation route has been properly protected.
14.57 — PROPOSED INVENTIVE-STEP ANALYSIS
14.57.1 — Established Prior Art
Reference monitors, complete mediation, mandatory access control,
sandboxing, network firewalls, service registries, system topology
discovery, device isolation, hardware access protection, runtime
policy updates, and attestation are established technical areas.
The present embodiment does not assert original invention of those
mechanisms individually.
14.57.2 — Candidate Objective Technical Problem
A candidate objective technical problem is:
How to maintain non-bypassable consequential execution-finality
enforcement when the actual set of effect-capable paths changes
during autonomous operation, by establishing authenticated blocking-
coverage evidence, invalidating authority dependent upon stale
topology state, and requiring independent current path and actual-
operation verification at the effectuation boundary.
14.57.3 — Candidate Technical Solution
A candidate technical combination comprises:
9.4.3.74. Source page 1295 of the original specification
Authenticated effect-capable resource enumeration;
A protected graph of relevant consequential paths;
Qualified distinction between blocking and monitoring components;
An authenticated coverage commitment;
A current protected coverage epoch;
Change-triggered invalidation or fencing;
Das Expires 29 April 2027 [Page 252]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Protected revalidation of affected software and hardware paths;
Operation-bound non-bearer finality authority;
And independent sink-time verification.
14.57.4 — Technical Interaction
The resource inventory identifies the relevant effect-capable
objects.
The topology graph identifies supported routes from computational
entities to those objects.
The enforcement classifier determines which components provide
mandatory blocking.
The coverage verifier determines whether the selected path-control
predicate is satisfied.
The coverage commitment associates the accepted result with a
protected configuration generation.
The invalidation controller prevents stale authorization from
remaining effective after material changes.
The revalidation controller establishes current qualified coverage.
The actual Finality Sink verifies that the pending effect corresponds
to valid current coverage and operation-specific authority.
The protected consumption state prevents unrelated or repeated
exercise of the resulting enablement.
14.57.5 — Not Merely a Reference Monitor
The reference-monitor principle is established.
The proposed arrangement specifies operation-specific protected
coverage dependencies, dynamic invalidation, and current sink-time
authority binding within an autonomous execution-finality
architecture.
9.4.3.75. Source page 1296 of the original specification
14.57.6 — Not Merely a Sandbox
A sandbox may restrict a fixed class of process operations.
Das Expires 29 April 2027 [Page 253]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The principal implementation additionally evaluates how current
effect-capable paths and resource attribution changes affect
previously issued finality authority.
14.57.7 — Not Merely eBPF or Kernel Instrumentation
Kernel instrumentation and mandatory access-control hooks are
established.
The proposed arrangement does not treat attachment or telemetry as
sufficient unless the required blocking and complete-mediation
properties are established for the relevant effect.
14.57.8 — Not Merely Topology Discovery
A service inventory or path graph may identify resources.
The candidate technical mechanism connects accepted path-coverage
state to actual consequential authority and mandatory sink-time
verification.
14.57.9 — Not Merely Attestation
Authenticated configuration evidence may establish selected
properties of an execution environment.
The present principal implementation separately verifies that the
actual pending effect remains within protected source authority and
current coverage.
14.57.10 — Not Merely Configuration Monitoring
A monitoring service may detect that a gate was disabled.
The proposed stronger mechanism requires affected consequential
authority to become invalid or fenced until current coverage is
restored.
14.57.11 — Candidate Narrow Inventive Kernel
A potentially significant technical combination is:
Das Expires 29 April 2027 [Page 254]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A protected autonomous execution system that maintains authenticated
effect-capable path and enforcement-coverage state, binds operation-
specific non-bearer finality authority to a protected coverage
generation, invalidates affected authority when a material software,
routing, resource, or hardware topology change occurs, and requires
an independently enforcing Finality Sink to reconstruct the actual
pending operation and verify current qualified mandatory path
coverage before permitting the consequential effect.
14.57.12 — Additional Hardware Kernel
9.4.3.76. Source page 1297 of the original specification
A narrower implementation may require current protected attribution
of device ownership, command queue, and hardware effectuation path,
with actual device-level refusal of commands lacking matching
operation-specific authority.
14.57.13 — Additional Dynamic Tool Kernel
Another candidate may require automatic fencing of affected
consequential authority when a newly introduced tool exposes an
effect-capable route absent from the accepted coverage graph.
14.57.14 — Additional Blocking-Classification Kernel
Another candidate may require explicit distinction between
monitoring-only and pre-effectuation blocking enforcement, together
with refusal to treat unqualified monitoring as coverage.
14.57.15 — Additional Epoch-Race Kernel
Another candidate may require protected invalidation and epoch
advancement before a controlled topology transition can expose an
uncontrolled effectuation path, with sink-local current-epoch
verification.
14.57.16 — Hindsight Considerations
A proper inventive-step analysis should examine the closest relevant
prior-art security systems, including reference monitors, runtime
access-control reconfiguration, capability systems, hardware
mediation, policy-controlled gateways, and attested enforcement
architectures.
Many combinations of inventory, monitoring, policy updates, and
blocking may be conventional or obvious.
Das Expires 29 April 2027 [Page 255]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The technical inventive-step position should therefore focus upon the
precise interaction among current topology evidence, mandatory
effect-path qualification, protected invalidation of existing
finality authority, and independent actual effectuation enforcement.
14.57.17 — Patentability Qualification
The creation of a resource graph or authenticated coverage record
does not independently establish novelty.
Complete path discovery cannot be claimed without a technically
supportable coverage boundary and implementation.
Patentability depends upon the exact claimed combination, enabling
disclosure, relevant prior art, and demonstrable technical effect.
14.58 — INDUSTRIAL APPLICABILITY
9.4.3.77. Source page 1298 of the original specification
14.58.1 — Enterprise Autonomous Agents
Enterprise agents may access tools and resources through dynamically
changing interfaces while consequential operations remain subject to
current mandatory coverage.
14.58.2 — Cloud AI Infrastructure
Cloud environments may verify protected execution paths as services,
containers, policies, or model-serving arrangements change.
14.58.3 — Multi-Agent Platforms
Several agents may share effect-capable interfaces while preserving
current operation-specific authorization.
14.58.4 — Operating-System Security
Protected operating-system controllers may combine resource
enumeration and mandatory finality enforcement.
14.58.5 — Container and Virtual-Machine Infrastructure
Changes to network, storage, process, and device access may trigger
coverage revalidation.
14.58.6 — Database Systems
Das Expires 29 April 2027 [Page 256]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Autonomous database operations may be protected against alternative
direct mutation paths.
14.58.7 — File and Storage Infrastructure
Protected file or storage mutations may remain controlled across
changing mounts, descriptors, and device interfaces.
14.58.8 — Network Security
Dynamic network routes and service interfaces may be evaluated for
current mandatory egress enforcement.
14.58.9 — Credential Management
Reusable credentials may be constrained where alternative interfaces
could bypass operation-specific finality.
14.58.10 — Financial Services
Payment and transaction operations may require verified current
resource and gateway coverage.
14.58.11 — Electronic Commerce
9.4.3.78. Source page 1299 of the original specification
Automated ordering, payment, refund, and inventory interfaces may be
governed under current protected effectuation paths.
14.58.12 — Telecommunications
Autonomous communication-network controllers may enforce protected
configuration and traffic effects across changing network functions.
14.58.13 — Industrial Automation
Control systems may revalidate actuator and device command paths
after relevant controller or firmware changes.
14.58.14 — Robotics
Robotic command interfaces may require current hardware resource
ownership and protected command-gate coverage.
14.58.15 — Autonomous Vehicles
Das Expires 29 April 2027 [Page 257]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Selected consequential device and control interfaces may be subject
to current protected topology and resource-state requirements.
14.58.16 — Hardware Accelerators
GPU, NPU, and other accelerator command or data-egress paths may be
associated with protected effectuation authority.
14.58.17 — Edge Computing
Distributed edge devices may maintain bounded enforcement coverage
and protected resource attribution.
14.58.18 — Confidential Computing
Confidential workloads may supply qualified execution evidence while
external effects remain independently controlled.
14.58.19 — Remote and Satellite Systems
Intermittently connected equipment may use protected local control
paths and bounded authorization under defined assurance assumptions.
14.58.20 — Multimodal AI Systems
Controlled text, audio, video, sensor, display, and other release
interfaces may be classified as effect-capable boundaries where
appropriate.
14.58.21 — Distributed Storage and Message Systems
9.4.3.79. Source page 1300 of the original specification
Dynamic resource endpoints may require current path qualification
before protected writes or message releases.
14.58.22 — Long-Running Autonomous Workflows
Operations prepared earlier may require current coverage revalidation
before delayed eventual execution.
14.58.23 — Future Heterogeneous Computing
Evolving processor, device, network, and application architectures
may employ protected resource graph and finality-bound coverage
controls.
14.58.24 — Shared Execution-Finality Services
Das Expires 29 April 2027 [Page 258]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A protected coverage-verification service may provide reusable
enforcement assurances for multiple autonomous software frameworks
without relying upon any particular agent or model provider.
The industrial utility concerns maintaining effective mandatory
control over consequential operations despite changes to the
software, hardware, and communication pathways through which those
operations may be executed.
14.59 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
14.59.1 — Candidate Independent System Claim
A candidate system claim may comprise:
A protected resource-enumeration component configured to identify
effect-capable resources and interfaces within a declared protected
domain;
A graph controller configured to represent relevant effectuation
paths;
A protected enforcement verifier configured to determine whether the
required paths are subject to qualified mandatory blocking controls;
A coverage-state controller configured to establish authenticated
coverage commitments and protected generations;
A topology-change controller configured to invalidate or fence
consequential authority affected by material changes;
A revalidation component configured to establish current coverage
following such changes;
And a Finality Sink configured to reconstruct the actual pending
operation and permit effectuation only when its current coverage,
operation-specific authority, and sink-local protected state satisfy
the applicable mandatory conditions.
9.4.3.80. Source page 1301 of the original specification
14.59.2 — Candidate Independent Method Claim
A corresponding method may comprise:
Establishing a protected effectuation domain;
Identifying effect-capable resources;
Das Expires 29 April 2027 [Page 259]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Constructing a protected path representation;
Classifying enforcement capability;
Verifying required mandatory coverage;
Committing coverage state;
Binding a Candidate Act's finality authority to the relevant coverage
generation;
Detecting a material topology change;
Invalidating affected authority;
Revalidating the updated enforcement configuration;
Reconstructing the actual pending operation at a protected sink;
And permitting the effect only upon satisfaction of current coverage
and operation-specific authorization conditions.
14.59.3 — Candidate Independent Hardware Claim
A protected hardware apparatus may comprise:
A device-resource attribution component;
A protected current command-path controller;
A coverage-generation state;
And a hardware effectuation gate configured to refuse commands that
lack matching current resource ownership, required enforcement
coverage, and operation-specific non-bearer authority.
14.59.4 — Candidate Independent Dynamic-Tool Claim
Another candidate may address newly introduced tool or service
effectuation paths, automatic invalidation of prior coverage-bound
authority, and mandatory revalidation before new consequential
operations can proceed.
14.59.5 — Candidate Independent Distributed Claim
Das Expires 29 April 2027 [Page 260]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.4.3.81. Source page 1302 of the original specification
Another candidate may involve authenticated coverage state spanning
separately administered execution and resource domains, with actual
destination-side finality verification.
The final independent-claim organization should avoid needless
duplication and remain subject to technical unity, prior-art, and
disclosure-support analysis.
14.60 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
Dependent aspect 1: The protected system enumerates effect-capable
software resources.
Dependent aspect 2: The system enumerates effect-capable hardware
resources.
Dependent aspect 3: The system identifies paths between requesters
and consequential resources.
Dependent aspect 4: The paths are represented in an authenticated
directed graph.
Dependent aspect 5: The graph identifies mandatory enforcement nodes.
Dependent aspect 6: The system distinguishes monitoring-only nodes
from blocking enforcement nodes.
Dependent aspect 7: A monitoring-only component cannot satisfy the
required blocking predicate.
Dependent aspect 8: The protected verifier evaluates a mandatory
coverage cut or equivalent reachability constraint.
Dependent aspect 9: The covered domain is associated with explicit
resource and trust-boundary definitions.
Dependent aspect 10: Unknown required paths cause conservative
coverage handling.
Dependent aspect 11: The system establishes a protected coverage
commitment.
Dependent aspect 12: The coverage commitment identifies a protected
generation.
Das Expires 29 April 2027 [Page 261]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Dependent aspect 13: A Candidate Act is associated with a relevant
coverage dependency set.
Dependent aspect 14: Finality authority is bound to the current
coverage generation.
Dependent aspect 15: A material topology change invalidates affected
authority.
Dependent aspect 16: A protected fence is established before or
during a controlled configuration transition.
9.4.3.82. Source page 1303 of the original specification
Dependent aspect 17: A new coverage epoch is established after a
material enforcement change.
Dependent aspect 18: A previous coverage receipt becomes ineligible
after applicable epoch invalidation.
Dependent aspect 19: The system revalidates affected enforcement
paths before restoring authority.
Dependent aspect 20: Unaffected effectuation classes may retain valid
authority when their coverage dependencies remain satisfied.
Dependent aspect 21: A newly registered tool triggers relevant
coverage reassessment.
Dependent aspect 22: A modified tool contract triggers effectuation-
path revalidation.
Dependent aspect 23: A privileged helper is identified as an indirect
effectuation route.
Dependent aspect 24: The helper must verify operation-specific source
authority before producing the covered effect.
Dependent aspect 25: A direct network socket is constrained by
mandatory egress enforcement.
Dependent aspect 26: An alternate network namespace is included in
relevant coverage evaluation.
Dependent aspect 27: A changed network route triggers coverage
invalidation.
Das Expires 29 April 2027 [Page 262]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Dependent aspect 28: The actual external destination is verified at
the consequential boundary.
Dependent aspect 29: A protected plaintext-aware interface is
required for selected content-dependent disclosure policies.
Dependent aspect 30: The system binds authorized plaintext
information to the corresponding protected encryption or transmission
operation.
Dependent aspect 31: Alternative file or storage references are
resolved to actual protected resource identities.
Dependent aspect 32: Direct database or storage access is subject to
mandatory finality enforcement.
Dependent aspect 33: A required operating-system security hook is
verified as currently attached.
Dependent aspect 34: A configured security hook must possess the
required blocking capability.
9.4.3.83. Source page 1304 of the original specification
Dependent aspect 35: Detachment of a required hook invalidates
affected coverage authority.
Dependent aspect 36: A change from blocking to audit-only mode
triggers invalidation.
Dependent aspect 37: The system maintains protected device or
resource ownership attribution.
Dependent aspect 38: Hardware command queues are represented as
effect-capable interfaces.
Dependent aspect 39: Current device-command ownership is verified
before consequential execution.
Dependent aspect 40: A driver or firmware change triggers
revalidation of affected command paths.
Dependent aspect 41: Direct-memory-access scope is verified under an
appropriate hardware resource-control model.
Dependent aspect 42: An accelerator-originated effect is governed
through a corresponding protected resource gate.
Das Expires 29 April 2027 [Page 263]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Dependent aspect 43: A hardware path commitment is bound to an actual
resource and current coverage generation.
Dependent aspect 44: A device ownership change invalidates previous
owner's operation-specific effectuation authority.
Dependent aspect 45: The protected system maintains authenticated
coverage revalidation receipts.
Dependent aspect 46: A revalidation receipt identifies the covered
effect classes and applicable trust assumptions.
Dependent aspect 47: A forged or unauthorized coverage receipt is
rejected.
Dependent aspect 48: A stale signed coverage receipt is rejected
under current epoch verification.
Dependent aspect 49: The Finality Sink reconstructs the actual
pending operation.
Dependent aspect 50: The sink resolves the actual consequential
resource.
Dependent aspect 51: The sink resolves or verifies the actual
relevant effectuation path.
Dependent aspect 52: The sink verifies the current coverage epoch.
Dependent aspect 53: The sink verifies current operation-specific
source authority.
9.4.3.84. Source page 1305 of the original specification
Dependent aspect 54: The sink verifies required resource-version or
reservation conditions.
Dependent aspect 55: The sink consumes scoped non-bearer finality
enablement.
Dependent aspect 56: A copied authority object cannot authorize
another unapproved path.
Dependent aspect 57: A completed effect is distinguished from an
invalidated but not yet executed Candidate Act.
Dependent aspect 58: An uncertain in-flight operation is preserved
under protected outcome state.
Das Expires 29 April 2027 [Page 264]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Dependent aspect 59: A recovery operation requires separately valid
current effectuation-path authority.
Dependent aspect 60: Cross-provider effects require appropriate
destination-side enforcement where the claimed downstream guarantee
depends upon it.
Dependent aspect 61: A cumulative privacy-release condition remains
mandatory across covered alternate egress routes.
Dependent aspect 62: A current model or algorithmic-generation
requirement remains independently enforceable.
Dependent aspect 63: A required quorum approval does not replace
current path-coverage verification.
Dependent aspect 64: A CW-2 accepted actual-effect receipt remains
necessary where required for causal successor authority.
Dependent aspect 65: The verifier enforces a protected resource or
work budget.
Dependent aspect 66: A finite bypass test is treated as evidence for
its specified route rather than proof of every possible path.
Dependent aspect 67: A protected integrated controller may perform
coverage verification and actual finality enforcement.
Dependent aspect 68: Separate authenticated controllers may perform
discovery, revalidation, and sink-side enforcement.
Dependent aspect 69: The architecture supports operation-specific
coverage validation without requiring a public blockchain.
Dependent aspect 70: The system may use one or more hardware or
software mechanisms to establish equivalent mandatory blocking
enforcement.
These aspects are non-limiting claim-support possibilities rather
than individually established patentable inventions.
9.4.3.85. Source page 1306 of the original specification
14.61 — NON-LIMITING IMPLEMENTATION AND COMBINATION CLAUSE
The disclosed mechanisms may be implemented individually or in
technically compatible combinations.
Das Expires 29 April 2027 [Page 265]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
An implementation may protect application tool calls.
Another may protect operating-system resource operations.
Another may protect network egress.
Another may protect database or storage commits.
Another may protect device commands.
Another may protect accelerator-originated consequential effects.
Another may combine these operation classes within one protected
effectuation domain.
An implementation may use declarative protected configuration instead
of runtime graph enumeration where the controlled environment
provides sufficient completeness guarantees.
Another may use authenticated runtime discovery.
Another may use protected hardware resource ownership and command
gating.
Another may employ operating-system mandatory access controls or
appropriately isolated service gateways.
No particular operating-system hook, device model, network protocol,
graph representation, cryptographic primitive, or software framework
is universally required unless specified by a selected claim.
The phrase non-bypassable applies only to the defined covered
effectuation boundary and the actual enforcement guarantees supported
by the implementation.
The phrase complete coverage does not imply universal control over
unknown physical devices, untrusted administrators, independent
remote systems, or unenumerated privileged effects.
A cryptographic commitment authenticates specified information but
does not prove that every effect-capable path was correctly
discovered.
A successful controlled bypass test provides evidence concerning the
tested route under the stated conditions, not a universal
impossibility proof.
Das Expires 29 April 2027 [Page 266]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.4.3.86. Source page 1307 of the original specification
The disclosed pseudocode, state machines, diagrams, data structures,
threat models, worked examples, and proposed experiments are
illustrative and non-limiting technical aids intended to assist a
person having ordinary skill in the art.
Where technically compatible, the mechanisms may be combined with the
protected Candidate Act, non-effective holding, source authority,
evidence, finality, conflict, privacy, device migration, execution
integrity, quorum, and recovery mechanisms of other embodiments.
A cross-reference does not automatically make every feature of
another embodiment mandatory.
The permissible scope of any selected combination depends upon
technical compatibility, the precise claim language, and the enabling
disclosure actually filed.
Future-oriented variations are technical proposals, not
representations that the corresponding systems have been
experimentally demonstrated.
No proposed experiment is represented as completed unless
independently performed and documented.
14.62 — FINAL TECHNICAL SUMMARY AND INVENTIVE-STEP CHARACTERIZATION
The present Embodiment 14 discloses a protected execution-finality
architecture for maintaining mandatory consequential enforcement
despite changes to the software, hardware, service, network, storage,
device, or other effectuation paths available to autonomous
computational systems.
The architecture distinguishes an installed security mechanism from
an effective mandatory enforcement boundary.
A monitoring component may observe an operation without preventing
it.
An application gateway may correctly validate a request while an
equivalent direct resource interface remains uncontrolled.
A protected system may therefore require qualified evidence that
relevant effect-capable paths within the declared controlled
environment are subject to mandatory blocking enforcement.
Das Expires 29 April 2027 [Page 267]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
In a principal implementation, a protected controller establishes an
authenticated representation of relevant resources, interfaces,
enforcement components, and consequential routes.
A verifier determines whether the supported topology satisfies a
defined mandatory path-coverage predicate.
9.4.3.87. Source page 1308 of the original specification
The accepted configuration is associated with a protected coverage
commitment and current coverage generation.
Operation-specific finality authority may be bound to the coverage
dependencies necessary for the particular consequential effect.
When a material change occurs to an interface, route, privileged
worker, tool, device, hardware command path, policy, or enforcement
configuration, the system invalidates or fences affected authority.
The changed topology is reexamined.
Qualified blocking enforcement must be restored or established before
the corresponding coverage state can be accepted again.
A protected controller may then issue or revalidate operation-
specific authority under the current coverage generation.
Before actual effectuation, the Finality Sink independently obtains
or reconstructs the pending consequential operation.
The sink verifies its actual resource identity, current protected
effectuation path, accepted coverage state, source authorization,
current operation scope, and protected sink-local consumption
conditions.
A valid historical approval or coverage certificate does not
automatically authorize an operation through a new or uncontrolled
effectuation interface.
The architecture may be applied to application-level tools,
privileged services, network egress, file and database mutations,
hardware device commands, accelerators, confidential computing, and
distributed autonomous infrastructure.
The selected assurance depends upon the declared protection boundary,
completeness of controlled resource enumeration or access
restriction, correct enforcement classification, protected topology-
change management, and actual effectuation coverage.
Das Expires 29 April 2027 [Page 268]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The embodiment does not claim that reference monitors, sandboxing,
mandatory access control, kernel security hooks, hardware isolation,
network gateways, topology discovery, or attestation are individually
new.
Its proposed additional contribution lies in enforcing a protected
current-state dependency between mandatory path coverage and the
authority to release real consequential effects.
The principal candidate inventive technical concept of Embodiment 14
is a protected effectuation-path continuity architecture in which
authenticated effect-capable topology and blocking-enforcement
evidence support a coverage-bound finality authority, material
runtime or hardware path changes invalidate affected protected
authority, and an independently enforcing Finality Sink refuses the
actual pending consequential operation unless current path coverage,
actual resource correspondence, operation-
9.5. Embodiment 19: Protected Computer-Use, Human Approval and Actual
UI Effect Correspondence
Original technical source global pages 1626-1682; input volume
TECHNICAL SPECIFICATION -1542-2011.pdf. Primary Part 4 topic:
Embodiment 19: Protected Computer-Use, Human Approval and Actual UI
Effect Correspondence. The patent specification may present optional
embodiments, alternative formulations and claim proposals; preserving
its wording does not convert each option into a requirement of a
standard.
9.5.1. Protected Architecture and Trust-Boundary Diagram
[Rendered UI / accessibility / DOM state]
|
[Qualified interface observation]
|
[Approval context commitment / user scope]
|
[Prepared Candidate Act]
|
[Receiving app/resource interface]
|
[Reconstruct actual effect + sink state]
Figure 20: Embodiment 19: Protected Computer-Use, Human Approval
and Actual UI Effect Correspondence — architecture
9.5.2. Operational Decision and Fail-Closed Flowchart
Das Expires 29 April 2027 [Page 269]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
[Agent views UI and proposes action]
|
[Qualify visible/accessibility context]
|
<Human approval bound to exact effect?>--NO-->[Withhold]
|YES
<UI state/recipient unchanged?>--NO-->[Revalidate]
|YES
[Actual app resource effect observed at sink]
|
<Current source and effect match?>--NO-->[Refuse]
|YES
[Protected consume + effect]
Figure 21: Embodiment 19: Protected Computer-Use, Human Approval
and Actual UI Effect Correspondence — operational flowchart
9.5.3. Original Page-by-Page Technical Disclosure
9.5.3.1. Source page 1626 of the original specification
Specific Non-Bearer Finality Enablement; Dynamic Interface-State
Revalidation; and Independent Reconstruction and Verification of
Actual Pending Effects at Protected Resource Sinks
19.0.1 — General Technical Description
The present Embodiment 19 discloses systems, methods, apparatus,
protected computing components, authenticated interface-observation
mechanisms, computer-use execution controls, transaction-specific
approval procedures, cryptographic and non-cryptographic operation-
binding techniques, machine-verifiable confirmation records, software
and hardware enforcement structures, and non-limiting implementations
for governing consequential operations initiated through graphical,
voice, accessibility, browser, desktop, mobile, remote-computing, or
multimodal user interfaces.
A computational entity may interact with a user interface by
observing screenshots, reading a document-object representation,
processing accessibility information, generating pointer movement,
simulating keyboard input, invoking structured application actions,
operating a browser, manipulating a desktop application, or otherwise
controlling a computer-use environment.
The computational entity may comprise an autonomous artificial-
intelligence agent, assistant, automation controller, robotic
software process, application service, or other entity capable of
preparing or initiating consequential operations.
Das Expires 29 April 2027 [Page 270]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A human operator may approve a proposed operation through a displayed
confirmation, authenticated transaction challenge, protected hardware
interface, voice interaction, or another qualified authorization
mechanism.
Alternatively, the originating source may establish bounded
autonomous authority without requiring a separate human approval for
every covered act.
The existence of a screenshot, interface label, button click,
biometric verification, voice confirmation, or authenticated approval
does not automatically establish that the actual consequential
operation corresponds to what was authorized.
A button displayed as a benign action may invoke a different effect.
A browser page may change between inspection and submission.
A foreground window may lose focus.
A resource name may resolve to a different actual object.
A form field may be modified by asynchronous script execution.
A hidden request field may differ from the displayed transaction.
A remote application may apply additional transformations before the
operation reaches the resource.
A human may approve a displayed recipient, amount, file, or action
while a different actual transaction is transmitted.
9.5.3.2. Source page 1627 of the original specification
A valid authentication ceremony may establish user presence or
possession of a credential without establishing that the person saw,
understood, and authorized every relevant field of the actual
operation.
The present embodiment addresses this gap by separating:
Interface observation;
Proposed action interpretation;
Actual effect construction;
Authority determination;
Das Expires 29 April 2027 [Page 271]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Optional human confirmation;
Protected operation-specific enablement;
Actual resource-side execution;
And qualified real-effect completion.
In a principal implementation, a protected observation instance
obtains qualified evidence concerning the relevant interface state.
A protected translation component converts the proposed computer-use
action into a Candidate Act identifying the intended consequential
operation.
Where required, a trusted approval component presents an
independently determined effect description to an authorized human
and obtains a suitably authenticated approval bound to the Candidate
Act and its material effect parameters.
A separately protected validation instance determines whether the
resulting authority, interface-state evidence, and current operation
conditions correspond.
A protected finality controller establishes scoped non-bearer
enablement for the authorized operation.
At the actual consequential boundary, a designated Finality Sink
independently obtains or reconstructs the pending resource operation.
The sink compares the actual operation with the protected authorized-
effect descriptor and current source authority.
A change in material transaction parameters, target identity,
required interface context, approval state, revocation generation, or
protected resource condition may invalidate the earlier enablement.
The effect is permitted only when the required finality predicates
pass.
19.0.2 — Fundamental Technical Principle
A visible interface action is not itself proof of the actual
consequence, and a human approval of one displayed operation is not
authority to execute a different operation.
Das Expires 29 April 2027 [Page 272]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.5.3.3. Source page 1628 of the original specification
The following events are technically distinct:
The agent observes an interface.
The agent interprets the interface.
The agent decides what action to propose.
A human or protected policy approves the proposed action.
The application constructs an actual resource request.
The request is transformed or transmitted.
The resource accepts or rejects the request.
The resource commits the operation.
And the real effect is confirmed.
No earlier event automatically establishes the validity or occurrence
of all subsequent events.
19.0.3 — Principal Candidate Inventive Combination
A principal candidate technical combination comprises:
A consequential Candidate Act;
A protected interface-state observation record;
An authenticated actual-effect descriptor;
An independently established source-authority predicate;
An optional human approval commitment bound to the effect descriptor;
A current interface and resource correspondence verifier;
A protected cross-commitment between collection-time and execution-
time evidence;
An operation-specific non-bearer finality enablement;
A designated actual-effect Finality Sink;
Das Expires 29 April 2027 [Page 273]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
And a protected consumption controller.
The Finality Sink independently verifies that the real pending
consequential operation falls within the approved effect envelope.
The requesting agent cannot produce a different effect merely by
replaying an earlier approval, supplying an altered screenshot,
changing UI focus, reusing a click sequence, or presenting an old
capability reference.
19.0.4 — Human Approval Is Optional
9.5.3.4. Source page 1629 of the original specification
A selected implementation may require a human confirmation for
specified operation classes.
Another implementation may operate autonomously within a
preauthorized protected effect envelope.
The same finality architecture may support both configurations.
Where human approval is required, the approval constitutes one
necessary authority condition.
Where a bounded autonomous grant is sufficient, a separate human
confirmation need not be required for each operation.
In neither configuration does the computational agent's ability to
generate a valid action proposal independently establish its
authority to cause the real effect.
19.0.5 — Relationship to Earlier Embodiments
Earlier embodiments may govern conflicting operations, real-effect
receipts, target correspondence, resource grants, effect semantics,
cross-domain delegation, privacy exposure, hardware ownership,
computational-generation validity, resource reservations, recovery,
collective authorization, path coverage, cross-committed evidence,
crash consistency, temporal authority, and revocation.
The present embodiment specifically develops the correspondence
between interface-observed or human-approved operations and actual
effectuation, including visual and semantic interface state, human-
confirmation integrity, dynamic UI changes, and actual resource-side
verification.
The earlier disclosures remain unchanged.
Das Expires 29 April 2027 [Page 274]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
19.1 — TECHNICAL FIELD
The present embodiment relates to autonomous computer use, graphical
interface automation, human-in-the-loop authorization, multimodal
agent security, browser automation, accessibility interfaces,
protected transaction confirmation, interface-state provenance,
secure input processing, trusted computing, credential-bound
approval, resource-side authorization, and independent execution-
finality enforcement.
More particularly, it concerns preventing a computer-use or
multimodal agent from transforming a displayed, perceived, or
approved interface action into an unauthorized consequential
operation.
19.2 — TECHNICAL PROBLEMS
19.2.1 — Screenshot-to-Effect Mismatch
A screenshot may display a permitted action while the actual resource
operation differs.
19.2.2 — Dynamic Interface Mutation
The displayed interface may change after inspection and before
submission.
19.2.3 — Focus Substitution
9.5.3.5. Source page 1630 of the original specification
Keyboard or pointer input may be directed toward a different window
or element.
19.2.4 — Click-Target Substitution
An interface element may change its function or location immediately
before the action.
19.2.5 — Overlay and Occlusion
An attacker may place a deceptive element above or below the intended
control.
19.2.6 — Hidden Request Parameters
The actual request may contain security-relevant parameters not
displayed in the interface.
Das Expires 29 April 2027 [Page 275]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
19.2.7 — Document-Object Manipulation
A browser's current document representation may differ from an
earlier inspected state.
19.2.8 — Accessibility-State Manipulation
An accessibility tree may contain stale, misleading, incomplete, or
attacker-controlled metadata.
19.2.9 — Interface Origin Confusion
An agent may act upon a visually similar interface originating from
another application or resource.
19.2.10 — Clipboard Substitution
The actual pasted recipient, destination, or content may differ from
the text previously observed.
19.2.11 — Asynchronous Form Modification
A script or background component may change submitted parameters.
19.2.12 — Remote Application Transformation
A server may convert one UI action into a different underlying
resource operation.
19.2.13 — Human Confirmation Laundering
A human approval may be reused for another transaction.
19.2.14 — Authentication/Approval Confusion
A successful biometric or cryptographic authentication may be
mistaken for authorization of a particular transaction.
19.2.15 — Voice Confirmation Ambiguity
A voice response may lack a sufficiently authenticated binding to the
exact proposed consequence.
19.2.16 — Agent-Generated Approval Summary
Das Expires 29 April 2027 [Page 276]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.5.3.6. Source page 1631 of the original specification
An untrusted agent may present an incomplete or misleading
description of the effect to the human.
19.2.17 — Material Parameter Change
A recipient, amount, account, file, device, or resource may change
after approval.
19.2.18 — Stale Approval
A previously valid approval may be exercised after expiration or
revocation.
19.2.19 — Resource Version Change
The actual target may have changed since the displayed preview.
19.2.20 — Browser Navigation Race
A tab or document may navigate before a queued click or submission
occurs.
19.2.21 — Multiple Similar Controls
An agent may confuse two visually similar buttons or resources.
19.2.22 — Screenshot Replay
An earlier authentic interface capture may be submitted as though it
described the current interface.
19.2.23 — Prompt Injection Through UI Content
Attacker-controlled visible text may instruct the agent to deviate
from authorized user intent.
19.2.24 — Privileged Helper Bypass
A protected approval interface may be bypassed through an alternate
tool or privileged application service.
19.2.25 — Completion Illusion
A success message may appear without the actual intended resource
effect having completed.
Das Expires 29 April 2027 [Page 277]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
19.2.26 — Objective Technical Problem
A candidate objective technical problem is:
How to prevent an autonomous computer-use operation from producing an
actual resource effect that differs from its qualified interface-
observed or human-approved scope, when interface state may change,
visual or accessibility evidence may be incomplete, and upstream
authentication or confirmation may occur before the actual
consequential transaction is constructed or committed.
19.3 — ESTABLISHED TECHNIQUES AND LIMITATIONS
19.3.1 — Browser Automation
9.5.3.7. Source page 1632 of the original specification
Browser automation systems may inspect documents, control browser
contexts, and generate user-interface actions.
These capabilities are established.
Their successful operation does not automatically prove current
consequential authorization at a receiving resource.
19.3.2 — Screenshots and Visual Recognition
Computer-vision and screen-capture techniques may identify displayed
controls and text.
These are established.
A screenshot is not necessarily complete evidence of the
application's hidden state or future resource request.
19.3.3 — Accessibility Automation
Accessibility interfaces may expose semantic UI elements and allow
selected interactions.
These techniques are established.
Their metadata may require independent origin, freshness, and
operation-scope qualification.
19.3.4 — User Confirmation Dialogs
Applications routinely ask users to confirm consequential actions.
Das Expires 29 April 2027 [Page 278]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
These are established.
A confirmation that is not securely bound to the actual transaction
may be insufficient for the stronger proposed guarantee.
19.3.5 — Cryptographic User Authentication
Authenticators may establish a particular authentication ceremony,
user presence, or user verification.
Such mechanisms are established.
These properties do not automatically establish that a person
reviewed and approved the actual downstream transaction details.
19.3.6 — Transaction Signing
Cryptographic transaction authorization and signatures over selected
transaction details are established areas.
The proposed embodiment does not claim their individual invention.
19.3.7 — Conditional Resource Updates
Resources may support version-bound or conditional mutations.
9.5.3.8. Source page 1633 of the original specification
These mechanisms are established.
The principal embodiment connects such checks with protected
interface evidence and actual effectuation authority.
19.3.8 — Application-Level Access Control
Receiving applications may verify resource permissions and operation
parameters.
Such mechanisms are established.
19.3.9 — Candidate Technical Distinction
The proposed protected relationship links qualified interface
evidence, optional transaction-bound human confirmation, independent
actual-operation reconstruction, current resource and authority
state, and non-bearer finality consumption.
19.4 — PRINCIPAL SYSTEM ARCHITECTURE
Das Expires 29 April 2027 [Page 279]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A representative implementation comprises:
A Computer-Use Candidate Act Constructor;
A Protected Interface Observation Instance;
A Visual and Accessibility Evidence Collector;
An Interface Origin and Provenance Verifier;
A Protected Effect-Semantics Translation Controller;
An Authenticated Approval Presentation Service;
An Optional Human Confirmation Controller;
An Independent Execution-Time Validation Instance;
A Protected Interface-State and Resource Correspondence Controller;
A Current Authority and Revocation Controller;
A Non-Bearer Finality Enablement Controller;
An Actual Resource Finality Sink;
And a Sink-Local Protected Consumption Controller.
Optional components include:
A protected display path;
A browser automation adapter;
An accessibility adapter;
9.5.3.9. Source page 1634 of the original specification
A trusted input receiver;
A credential authenticator;
A protected IPC broker;
A transactional resource service;
A network egress controller;
Das Expires 29 April 2027 [Page 280]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A resource-version registry;
A protected operation journal;
And an independent actual-effect observer.
19.4.1 — Observation Instance
Collects qualified information concerning the relevant interface
state.
19.4.2 — Effect Translator
Determines the proposed consequential operation and its material
parameters.
19.4.3 — Approval Presentation Service
Presents an independently determined effect summary through the
selected protected or qualified channel.
19.4.4 — Confirmation Controller
Authenticates a human approval where such approval is required.
19.4.5 — Independent Validator
Checks current evidence, source authority, interface/resource
correspondence, and approval scope.
19.4.6 — Finality Controller
Establishes scoped non-bearer effectuation eligibility.
19.4.7 — Finality Sink
Obtains the actual resource operation and verifies current finality
conditions.
19.4.8 — Consumption Controller
Prevents unsupported repeated execution using the same bounded
authority.
19.5 — TECHNICAL DEFINITIONS
19.5.1 — Interface-Governed Candidate Act
Das Expires 29 April 2027 [Page 281]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.5.3.10. Source page 1635 of the original specification
An Interface-Governed Candidate Act, or IGCA, means a Candidate Act
constructed from a proposed computer-use or interface-based
operation.
19.5.2 — Protected Interface-State Evidence
Protected Interface-State Evidence, or PISE-19, means authenticated
information concerning a qualified observed interface state.
19.5.3 — Interface Origin Commitment
An Interface Origin Commitment, or IOC-19, means an authenticated
reference identifying the relevant application, document, browsing
context, service, or origin associated with an observed interface.
19.5.4 — Visual State Commitment
A Visual State Commitment, or VSC-19, means an authenticated
commitment to selected visual information observed at a defined
collection event.
19.5.5 — Semantic Interface Commitment
A Semantic Interface Commitment, or SIC-19, means an authenticated
representation of relevant structured interface elements or their
properties.
19.5.6 — Interface-State Generation
An Interface-State Generation, or ISG-19, means a protected
generation identifying an applicable observed or current interface
state.
19.5.7 — Actual Effect Descriptor
An Actual Effect Descriptor, or AED-19, means a machine-verifiable
description of the actual consequential operation presented at the
relevant resource boundary.
19.5.8 — Approval Effect Envelope
An Approval Effect Envelope, or AEE-19, means the bounded
consequential operation scope presented for approval or established
under autonomous source authority.
19.5.9 — Protected Confirmation Commitment
Das Expires 29 April 2027 [Page 282]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A Protected Confirmation Commitment, or PCC-19, means authenticated
evidence binding a required approval to a specified operation and
material effect parameters.
19.5.10 — Qualified Confirmation Channel
A Qualified Confirmation Channel means an approval mechanism with
specified authenticity, integrity, presentation, and isolation
properties.
19.5.11 — Protected Presentation Descriptor
A Protected Presentation Descriptor, or PPD-19, means the exact
material effect description intended for presentation to an approving
principal.
9.5.3.11. Source page 1636 of the original specification
19.5.12 — Presentation Correspondence Predicate
A Presentation Correspondence Predicate means a verifiable
requirement that the approval presentation corresponds to the
protected operation-specific effect envelope.
19.5.13 — Interface-to-Effect Correspondence
Interface-to-Effect Correspondence means a validated relationship
between the interface-observed proposed action and the actual
consequential resource operation.
19.5.14 — Approval-to-Effect Correspondence
Approval-to-Effect Correspondence means a validated relationship
between the authorized or approved effect envelope and the actual
pending consequence.
19.5.15 — Interface Mutation Epoch
An Interface Mutation Epoch, or IME-19, means a protected generation
associated with a change in relevant interface state.
19.5.16 — Material Interface Change
A Material Interface Change means a state change affecting a
security-relevant property of the proposed operation or its
authorization context.
19.5.17 — Qualified Click Target
Das Expires 29 April 2027 [Page 283]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A Qualified Click Target means an interface element whose relevant
origin, identity, state, and intended effect correspondence have been
established under the selected observation model.
19.5.18 — Protected Input Routing
Protected Input Routing means a mechanism verifying that specified
input events are delivered to the intended controlled interface or
resource.
19.5.19 — Confirmation Freshness
Confirmation Freshness means satisfaction of the applicable
authorization-generation, time, interface-state, or transaction-
identity conditions.
19.5.20 — Approval Consumption State
Approval Consumption State means protected authoritative information
concerning the permitted use of a transaction-bound approval.
19.5.21 — Human-Approval Finality Enablement
Human-Approval Finality Enablement means scoped non-bearer finality
authority whose issuance depends on a qualified human confirmation.
19.5.22 — Autonomous Finality Enablement
9.5.3.12. Source page 1637 of the original specification
Autonomous Finality Enablement means scoped non-bearer finality
authority established under sufficiently valid preauthorized source
conditions without a separate approval ceremony for each effect.
19.5.23 — Protected Interface Revalidation
Protected Interface Revalidation means current verification of the
interface and operation conditions required for the proposed
consequence.
19.5.24 — Pending Effect Identity
Pending Effect Identity means a stable authenticated reference to the
specified logical consequence.
19.5.25 — Material Transaction Parameter
Das Expires 29 April 2027 [Page 284]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A Material Transaction Parameter means an operation field whose
change would alter the applicable authority, recipient, resource,
amount, data disclosure, device effect, or other required
consequential property.
19.5.26 — Protected UI-to-Resource Bridge
A Protected UI-to-Resource Bridge means a controlled interface
mapping an approved operation to the actual effect-capable resource
primitive.
19.5.27 — Confirmation Substitution Attack
A Confirmation Substitution Attack means use of approval for one
operation to authorize another materially different operation.
19.5.28 — Interface-State Replay
Interface-State Replay means presentation of earlier valid-looking
observed interface evidence as though it were applicable to the
current operation.
19.5.29 — Transaction-Bound Challenge
A Transaction-Bound Challenge means an authenticated approval
challenge committed to specified material effect parameters and
applicable authorization state.
19.5.30 — Qualified Approval Identity
Qualified Approval Identity means an authenticated reference to a
principal or protected role authorized to approve the specified
effect class.
19.5.31 — Effect-Specific Confirmation Assurance
Effect-Specific Confirmation Assurance means the set of verified
properties actually established by the approval process.
19.5.32 — Protected Confirmation Inertness
Protected Confirmation Inertness means a confirmation record cannot
independently authorize unrelated or replayed consequential effects.
9.5.3.13. Source page 1638 of the original specification
19.5.33 — Interface Provenance Boundary
Das Expires 29 April 2027 [Page 285]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Interface Provenance Boundary means a technical separation
distinguishing lower-trust application or web content from protected
approval or resource-control state.
19.5.34 — Sink-Verified Confirmation
Sink-Verified Confirmation means the actual resource controller
verifies the relevant approved effect scope against the operation
presented for effectuation.
19.5.35 — Qualified Effect Receipt
A Qualified Effect Receipt means authenticated evidence concerning
the actual performed consequence, with an explicitly identified
observation or transaction assurance scope.
19.6 — PROTECTED INTERFACE-STATE COLLECTION
The protected system may collect one or more forms of interface
evidence.
These may include:
A screen capture;
A protected window or display identifier;
A browser origin and browsing-context identifier;
An accessibility element tree;
A document-object representation;
An application action descriptor;
A focused element reference;
A resource or document version;
A selected form field set;
A current interaction-generation value;
And a protected observation timestamp or generation.
A representative record may comprise:
Das Expires 29 April 2027 [Page 286]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
PROTECTED_INTERFACE_STATE = { candidate_act_identifier,
application_or_origin_identity, browsing_or_window_context,
displayed_visual_commitment, semantic_element_commitment,
accessibility_state_commitment, focus_or_target_reference,
9.5.3.14. Source page 1639 of the original specification
selected_resource_identity, relevant_form_fields,
current_interface_generation, current_resource_generation,
observation_time_reference, collection_instance_identity,
protected_evidence_authentication } The record states what the
observation instance is qualified to establish.
A screenshot alone does not prove the complete hidden application
state.
A document-object snapshot alone does not establish all future
effects produced by the corresponding application code.
An accessibility element description alone does not establish that
the represented operation is authorized.
19.7 — INTERFACE ORIGIN AND PROVENANCE
A protected interface observer may establish relevant origin
information.
19.7.1 — Browser Origin
A browser operation may be associated with the authenticated or
qualified document and service origin.
19.7.2 — Window Identity
A desktop operation may be associated with a specific window or
application instance.
19.7.3 — Document Identity
A protected operation may be associated with the intended current
resource or document.
19.7.4 — Embedded Content
Frames, external widgets, or embedded content may require separate
origin or authority qualification.
19.7.5 — Remote Interface
Das Expires 29 April 2027 [Page 287]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A remote desktop or streamed interface may require qualification of
the represented remote session.
19.7.6 — Source Trust
Displayed text from an untrusted page is treated as content, not
automatically as an authority instruction.
19.7.7 — Provenance Failure
9.5.3.15. Source page 1640 of the original specification
Where the required interface or resource origin cannot be
established, the corresponding consequence remains withheld.
19.8 — VISUAL AND SEMANTIC EVIDENCE CORRESPONDENCE
A principal implementation may compare selected visual and structured
interface properties.
The evidence may comprise:
Visible labels;
Relevant displayed values;
Semantic element identifiers;
Current focus;
Element roles;
Current origin;
Selected resource references;
And relevant current application state.
These properties may be used to assist the construction of a
Candidate Act.
However, visual-semantic agreement is not treated as a replacement
for actual resource-side validation.
An attacker-controlled page may provide mutually consistent but false
visual and structured content.
Das Expires 29 April 2027 [Page 288]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The protected architecture therefore requires the finality decision
to be grounded in independent current source authority and actual
effectuation correspondence.
19.9 — CANDIDATE ACT CONSTRUCTION FROM COMPUTER USE
An autonomous agent may propose an action such as:
Selecting an application command;
Entering a payment recipient;
Uploading a file;
Sending a message;
Deleting a database entry;
Submitting a form;
Changing an access policy;
9.5.3.16. Source page 1641 of the original specification
Activating a credential;
Exporting protected information;
Or issuing a hardware command.
The protected controller constructs a Candidate Act describing the
relevant consequential operation.
A representative structure may comprise:
COMPUTER_USE_CANDIDATE_ACT = { candidate_identifier,
requesting_agent_identity, originating_source_authority,
observed_interface_commitment, intended_operation_class,
intended_resource, intended_recipient, material_operation_parameters,
relevant_content_commitment, current_resource_reference,
permitted_effect_envelope, designated_finality_sink,
required_approval_class, current_authority_generation,
protected_candidate_authentication } The Candidate Act remains non-
effective until the applicable independent finality requirements
pass.
19.10 — PROTECTED ACTUAL-EFFECT TRANSLATION
Das Expires 29 April 2027 [Page 289]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A proposed UI action may be translated into one or more consequential
operations.
19.10.1 — Declared Action
The system identifies what the agent believes it is requesting.
19.10.2 — Operation Contract
The protected controller determines the relevant effect semantics of
the application action or tool.
19.10.3 — Resource Resolution
The actual affected resource and recipient are determined.
19.10.4 — Material Parameters
Security-relevant parameters are identified.
19.10.5 — Hidden Effects
9.5.3.17. Source page 1642 of the original specification
Additional relevant operations are identified where the selected
implementation can establish them.
19.10.6 — Effect Decomposition
A compound action may be divided into separately governed
consequential effects.
19.10.7 — Unresolved Semantics
If the required actual effects cannot be adequately determined, the
corresponding operation remains withheld or is routed through a
suitably protected resource controller.
19.11 — AUTHENTICATED APPROVAL PRESENTATION
Where human confirmation is required, the approval interface may
present a protected summary of the proposed actual consequence.
The displayed summary may identify:
The target resource;
The recipient;
Das Expires 29 April 2027 [Page 290]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The amount;
The operation type;
The document or information to be released;
The device to be controlled;
The current authorization context;
And other material effect parameters.
A representative record may comprise:
PROTECTED_APPROVAL_PRESENTATION = { approval_session_identifier,
approving_principal_reference, candidate_act_commitment,
material_effect_descriptor, actual_resource_identity,
effective_recipient, approval_scope, applicable_resource_generation,
presentation_channel_identity, presentation_generation,
confirmation_challenge_reference, presentation_integrity_evidence }
The trusted or qualified presentation service must obtain the
material effect description from an appropriately verified source.
9.5.3.18. Source page 1643 of the original specification
It must not depend solely upon an untrusted agent's self-authored
statement of what the transaction will do.
19.12 — TRUSTED CONFIRMATION CHANNEL
A selected implementation may employ a protected approval channel
with specified integrity and origin properties.
Possible mechanisms include:
An independently controlled confirmation application;
A privileged operating-system approval service;
A hardware-supported display and input path;
A protected remote authorization device;
An authenticated transaction approval interface;
Or another suitable confirmation mechanism.
19.12.1 — Presentation Integrity
Das Expires 29 April 2027 [Page 291]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The security-relevant effect description is protected against
unauthorized modification within the stated channel.
19.12.2 — Approver Authentication
The approving principal is authenticated under the applicable policy.
19.12.3 — Operation Identity
The approval is bound to the specified Candidate Act.
19.12.4 — Material Parameter Binding
The relevant actual-effect fields are committed.
19.12.5 — Freshness
The approval is valid only under the applicable transaction and
authority conditions.
19.12.6 — Technical Limitation
An ordinary application dialog or cryptographic login may not provide
a secure path from the effect description to what the person actually
perceived.
19.12.7 — No Claim of Mental-State Proof
The system establishes defined authentication and transaction-binding
properties. It does not purport to cryptographically prove a
person's subjective understanding.
9.5.3.19. Source page 1644 of the original specification
19.13 — TRANSACTION-BOUND CONFIRMATION
A non-limiting commitment may be represented as:
[ C_A = H(\operatorname{Canon}(CA, E, R, P, G, N)) ]
where:
(CA) is the Candidate Act;
(E) is the authorized effect descriptor;
(R) is the actual resource and recipient scope;
Das Expires 29 April 2027 [Page 292]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
(P) is the applicable source authority;
(G) identifies relevant resource or approval generations;
And (N) is a protected challenge nonce.
An authenticated confirmation may bind to (C_A).
The confirmation may be expressed through a protected signing
mechanism, authenticator ceremony, privileged approval service, or
equivalent qualified interface.
A valid cryptographic response proves the properties supplied by that
selected mechanism.
It does not automatically prove that every material transaction
detail was displayed through a trustworthy channel.
Where a trusted transaction presentation is required, the
implementation must separately establish that property.
19.14 — APPROVAL-TO-EFFECT CORRESPONDENCE
A principal implementation requires the actual effect to correspond
to the approved effect envelope.
A representative predicate may comprise:
APPROVAL_CURRENT AND APPROVER_AUTHORIZED AND
APPROVED_CANDIDATE_MATCHES AND ACTUAL_RESOURCE_MATCHES AND
MATERIAL_PARAMETERS_MATCH AND CURRENT_SOURCE_AUTHORITY_VALID AND
CURRENT_REVOCATION_VALID AND REQUIRED_RESOURCE_VERSION_VALID AND
REQUIRED_INTERFACE_CONTEXT_VALID AND FINALITY_ENABLEMENT_VALID AND
CONSUMPTION_AVAILABLE
9.5.3.20. Source page 1645 of the original specification
The exact predicates depend upon the selected operation.
An authorization for one recipient cannot be exercised for another
recipient unless the applicable authority expressly permits the
transformation.
A confirmation for one payment amount cannot independently authorize
a greater amount.
An approval for one document cannot independently authorize another
document.
Das Expires 29 April 2027 [Page 293]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A confirmation for one hardware command cannot independently
authorize a materially different actuator operation.
19.15 — INTERFACE MUTATION AFTER APPROVAL
A UI may change after evidence collection or confirmation.
19.15.1 — Change Detection
The protected system identifies changes to relevant interface or
operation state.
19.15.2 — Materiality Classification
The system determines whether the changed property affects the
authorized effect.
19.15.3 — Invalidation
Material changes invalidate affected pending finality enablement.
19.15.4 — Benign Variation
A cosmetic change may be ignored if the required operation semantics
remain valid.
19.15.5 — New Operation
A materially different action requires suitable new validation and
authority.
19.15.6 — Sink Revalidation
The actual operation remains subject to finality verification even
when no interface change was detected.
19.16 — SCREEN REPLAY AND STALE OBSERVATION
An earlier authentic screenshot may be replayed after the application
state changes.
The protected system may include:
Observation generation;
Window or browsing-context identity;
Current resource version;
Das Expires 29 April 2027 [Page 294]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.5.3.21. Source page 1646 of the original specification
Authenticated collection instance identity;
Time or sequence evidence;
And a current correspondence requirement.
A prior screenshot may be preserved for audit purposes.
However, it cannot independently establish the present validity of
the operation.
19.17 — CLICK TARGET AND INPUT ROUTING
A computer-use agent may interact through pointer movements, keyboard
events, touch input, accessibility actions, or application commands.
The system may qualify:
The intended target;
The actual focused context;
The relevant origin;
The element or operation identity;
And the resulting resource request.
A pointer click at a particular coordinate is not necessarily bound
to the same UI element after layout change.
A keyboard shortcut may act upon a different focused window.
A clipboard operation may insert modified content.
The stronger protected architecture verifies the actual submitted
consequential operation rather than relying solely upon the
correctness of the input sequence.
19.18 — PROTECTED BROWSER CONTEXT
A browser implementation may maintain protected references to:
The browsing context;
The current document origin;
Das Expires 29 April 2027 [Page 295]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The selected frame;
The relevant navigation generation;
The current form or resource identity;
And the actual outgoing operation.
9.5.3.22. Source page 1647 of the original specification
A browser automation adapter may contribute observation evidence.
Where an operation produces a remote server-side effect, the
strongest destination-side guarantee requires the receiving service
or an appropriately controlling gateway to verify the relevant
actual-effect predicates.
A browser script or screenshot that can be modified by the page is
not automatically a trusted authorization authority.
19.19 — ACCESSIBILITY-AWARE OPERATION VERIFICATION
An accessibility tree may provide valuable semantic information about
a UI.
A protected controller may use that information to identify candidate
operation fields and targets.
However:
An accessibility label may be incomplete.
The element may be stale.
The application may provide inconsistent role metadata.
The action may trigger an effect different from the apparent label.
The accessibility element may be replaced or redirected.
The finality architecture therefore treats such information as
qualified interface evidence rather than sufficient authority for the
actual effect.
19.20 — HUMAN CONFIRMATION VERSUS AUTOMATED AUTHORITY
A selected policy may classify operations according to whether human
confirmation is required.
Das Expires 29 April 2027 [Page 296]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
19.20.1 — Bounded Autonomous Operation
A permitted effect may proceed under current source authority without
a separate per-operation human approval.
19.20.2 — High-Impact Operation
A selected effect may require authenticated human confirmation.
19.20.3 — Scope Expansion
A materially broader consequence may require new approval.
19.20.4 — Approval Reuse
A single-use approval cannot independently authorize multiple
effects.
19.20.5 — Session Consent
9.5.3.23. Source page 1648 of the original specification
A broader session authorization may cover several expressly bounded
operations where supported by the source policy.
19.20.6 — Protected Finality
Both human-approved and autonomously authorized operations remain
dependent upon current sink-side verification.
19.21 — MULTIMODAL APPROVAL
An approval may be communicated through:
A graphical confirmation;
An authenticated mobile device;
A spoken command;
A hardware button;
An authenticated remote service;
Or another appropriate modality.
The underlying authority must identify the applicable principal,
effect scope, and approval event.
Das Expires 29 April 2027 [Page 297]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A voice statement that is not reliably bound to the exact material
parameters may be insufficient for selected sensitive transactions.
A biometric authentication result may establish user verification but
not necessarily the content of the approved operation.
An implementation may combine several modalities where required.
The same Candidate Act and protected effect descriptor remain the
common referents across modalities.
19.22 — DYNAMIC RESOURCE AND TRANSACTION VERSION
An operation may be approved against a particular resource state.
Before actual effectuation, that state may change.
The Finality Sink may check:
Current resource identity;
Expected version;
Current amount or balance condition;
Current destination binding;
9.5.3.24. Source page 1649 of the original specification
Current document identity;
Current device ownership;
Or another application-specific condition.
An earlier UI preview does not necessarily authorize an operation
against a different current resource version.
A protected controller may employ compare-and-swap, conditional
requests, transactional versions, or other suitable existing
mechanisms.
The particular resource-version primitive is not individually claimed
as invented.
19.23 — CROSS-COMMITTED UI AND EXECUTION EVIDENCE
Das Expires 29 April 2027 [Page 298]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A protected collection-time record may describe the observed
interface and proposed effect.
An independent execution-time record may describe the current actual
operation and relevant source authority.
A protected cross-commitment may bind these to the same Candidate
Act.
A non-limiting relationship may comprise:
[ C_0=H(\operatorname{Canon}(I,CA,P_0)) ]
[ C_1=H(\operatorname{Canon}(A,CA,P_1,C_0)) ]
[ X=H(\operatorname{Canon}(C_0,C_1,F,G)) ]
where:
(I) represents qualified interface observation;
(A) represents execution-time actual-operation evidence;
(P_0) and (P_1) identify relevant authority context;
(F) represents the Finality Sink;
And (G) identifies current protected state.
The formulae are illustrative.
A cryptographic commitment does not establish the truth of an
untrusted observation.
9.5.3.25. Source page 1650 of the original specification
The collection and validation components must actually possess the
necessary observation and authentication properties.
19.24 — PROTECTED FINALITY ENABLEMENT
Following the required current validation, a protected controller may
establish operation-specific non-bearer enablement.
UI_BOUND_FINALITY_ENABLEMENT = { candidate_act_commitment,
collected_interface_evidence, independent_validation_commitment,
approved_effect_descriptor, qualified_approval_reference,
original_source_authority, current_revocation_generation,
Das Expires 29 April 2027 [Page 299]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
required_resource_version, required_interface_generation,
designated_finality_sink, authorized_operation_scope,
current_policy_generation, permitted_use_count,
sink_local_consumption_reference, protected_authentication } The
record may remain within the protected authority domain.
The requesting agent may receive only an inert reference.
The reference cannot authorize an unrelated operation merely through
possession.
19.25 — ACTUAL FINALITY SINK
The Finality Sink may comprise:
A transactional database controller;
A file-mutation gate;
A protected application service;
A payment processor;
A network data-release gateway;
A credential broker;
A device command controller;
Or another effect-capable interface.
9.5.3.26. Source page 1651 of the original specification
The sink verifies:
The actual operation;
Current source authority;
The relevant approval or autonomous authorization envelope;
Current revocation;
Current resource identity;
Current operation parameters;
Applicable resource state;
Das Expires 29 April 2027 [Page 300]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Required protected finality enablement;
And current consumption state.
An untrusted UI confirmation cannot bypass the resource's mandatory
authority check.
19.26 — MULTIPLE CONSEQUENCES FROM ONE UI ACTION
A single UI action may generate several downstream effects.
For example, selecting a purchase button may:
Create an order;
Reserve inventory;
Initiate payment;
Notify a merchant;
And update persistent account state.
An implementation may identify the distinct consequential boundaries
and authorize them according to the original source scope.
A high-level approval does not automatically establish that every
later side effect is permissible.
Where effects are independently consequential, they may be
represented as separately bounded Candidate Acts or child operations.
Where CW-2 applies, a successor phase may require an accepted
qualified earlier actual-effect receipt.
A success message in the UI is not necessarily that receipt.
19.27 — APPROVAL EXPIRATION AND REVOCATION
9.5.3.27. Source page 1652 of the original specification
A valid confirmation may become stale before the corresponding
effect.
The protected controller may associate approval with:
A current source-authority generation;
Das Expires 29 April 2027 [Page 301]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A protected approval session;
A bounded validity interval;
A current resource version;
A transaction-specific nonce;
And an operation-specific consumption state.
The actual sink verifies the applicable current conditions.
A previously valid confirmation does not override later mandatory
revocation or material transaction changes.
19.28 — APPROVAL REPLAY AND CONCURRENCY
Several agents may attempt to exercise the same approval.
A principal implementation may associate one transaction-bound
approval with one permitted finality consumption.
An authoritative protected controller serializes or otherwise
resolves concurrent attempts.
The corresponding effect may be consumed only within its authorized
count and scope.
A copied approval signature or confirmation receipt does not create
additional independent authority.
Where the actual remote effect occurs outside the local transaction
domain, the system separately applies the applicable crash-consistent
dispatch and receiver-side effect controls.
19.29 — FAIL-CLOSED INTERFACE UNCERTAINTY
Where the selected policy requires reliable correspondence between an
observed interface and a consequential operation, the system may
refuse release when:
The current target cannot be identified;
The approval presentation cannot be authenticated;
The actual operation differs from the approved envelope;
The required source authority is unavailable;
Das Expires 29 April 2027 [Page 302]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The resource version is inconsistent;
9.5.3.28. Source page 1653 of the original specification
The confirmation has expired;
Or the relevant finality sink cannot enforce the required predicate.
The system may request fresh evidence or new approval.
It must not convert uncertainty into permission merely because the
agent produced a plausible explanation.
19.30 — PROTECTED STATE MACHINE
A non-limiting state machine comprises:
INTERFACE_OBSERVED: Qualified interface evidence has been collected.
CANDIDATE_PREPARED: A consequential Candidate Act exists.
NON_EFFECTIVE: The actual operation remains withheld.
EFFECT_TRANSLATION_PENDING: The proposed UI action has not been
sufficiently resolved.
EFFECT_DESCRIPTOR_COMMITTED: The intended consequential operation has
been bound to a protected descriptor.
AUTHORITY_VALIDATION_PENDING: Current source permission has not been
verified.
APPROVAL_REQUIRED: The applicable policy requires a confirmation.
APPROVAL_PRESENTATION_PENDING: The material effect description has
not yet been qualified for presentation.
CONFIRMATION_PENDING: Required approval has not been received.
CONFIRMATION_ACCEPTED: A qualified approval has been authenticated.
CONFIRMATION_REJECTED: Required approval is denied or invalid.
INTERFACE_CHANGED: Relevant current interface state differs.
RESOURCE_CHANGED: Relevant resource state differs.
Das Expires 29 April 2027 [Page 303]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
REVALIDATION_REQUIRED: Current operation or authority predicates
require new validation.
FINALITY_PREPARED: Scoped non-bearer enablement exists.
SINK_VERIFICATION_PENDING: The actual operation awaits resource-side
checking.
SINK_REJECTED: A mandatory condition fails.
AUTHORITY_CONSUMED: Protected finality use has been committed.
EFFECT_ATTEMPTED: The controlled operation has been released.
9.5.3.29. Source page 1654 of the original specification
EFFECT_CONFIRMED: Qualified evidence establishes the specified
completed consequence.
EFFECT_INDETERMINATE: The external outcome remains unresolved.
RECOVERY_PENDING: Separately governed reconciliation or recovery is
necessary.
TERMINATED: The operation reaches a valid protected terminal state.
19.31 — PRINCIPAL END-TO-END WORKFLOW
Step 1 — Observe Interface. The computer-use agent receives relevant
graphical or structured state.
Step 2 — Authenticate Observation Context. The protected collector
establishes available origin and freshness evidence.
Step 3 — Construct Candidate Act. The proposed consequential action
is identified.
Step 4 — Hold Non-Effective. The actual effect remains withheld.
Step 5 — Resolve Effect Semantics. The protected translator
identifies relevant resources and material parameters.
Step 6 — Establish Source Authority. The originating permission and
effect envelope are verified.
Step 7 — Collect Protected Interface Evidence. Relevant collection-
time observations are authenticated.
Das Expires 29 April 2027 [Page 304]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Step 8 — Determine Approval Requirement. The policy identifies
whether a separate human confirmation is mandatory.
Step 9 — Prepare Effect Presentation. A qualified component
constructs the material transaction summary.
Step 10 — Obtain Confirmation Where Required. The approving
principal provides an authenticated response.
Step 11 — Bind Approval. The result is committed to the specific
Candidate Act and effect parameters.
Step 12 — Independently Validate Current Conditions. The protected
execution-time instance evaluates relevant current authority and
operation context.
Step 13 — Cross-Commit Evidence. The required observation,
validation, and approval relationships are authenticated.
Step 14 — Prepare Finality Enablement. Scoped non-bearer authority
is established.
Step 15 — Present Actual Operation. The requester submits the
effect-capable action.
Step 16 — Reconstruct Actual Effect. The Finality Sink resolves the
operation and resource actually presented.
9.5.3.30. Source page 1655 of the original specification
Step 17 — Verify Current Approval or Autonomous Authority. The sink
checks the relevant effect envelope.
Step 18 — Verify Current Resource and Interface State. Required
versions, contexts, and parameters are checked.
Step 19 — Verify Current Revocation and Policy. Previously approved
but no longer valid operations are refused.
Step 20 — Verify Finality Enablement. The operation must match its
protected authority.
Step 21 — Verify Consumption. The permitted use remains available.
Step 22 — Consume Authority. A protected state transition commits
the eligible finality use.
Das Expires 29 April 2027 [Page 305]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Step 23 — Release Consequence. The resource performs the controlled
operation.
Step 24 — Record Qualified Outcome. The actual result is
distinguished from UI success indications.
Step 25 — Govern Successor Effects. Additional consequential
operations require their own applicable authority and causal
evidence.
19.32 — REFERENCE PSEUDOCODE: PROTECTED INTERFACE OBSERVATION
FUNCTION COLLECT_INTERFACE_EVIDENCE( candidate_context,
protected_observer ):
REQUIRE VERIFY_OBSERVER_ROLE( protected_observer )
observed = protected_observer .CAPTURE_QUALIFIED_INTERFACE_STATE()
REQUIRE VERIFY_RELEVANT_ORIGIN( observed )
REQUIRE VERIFY_OBSERVATION_CONTEXT( observed )
evidence = protected_observer .AUTHENTICATE_EVIDENCE({
visual_commitment: HASH(observed.visual_state),
semantic_commitment: HASH_CANONICAL(observed.semantic_state),
9.5.3.31. Source page 1656 of the original specification
interface_origin: observed.origin,
interface_generation: observed.generation,
resource_reference: observed.resource_reference,
collection_context: HASH(candidate_context) })
RETURN evidence The resulting evidence represents only the properties
the selected protected observer is qualified to establish.
19.33 — REFERENCE PSEUDOCODE: EFFECT TRANSLATION
FUNCTION CONSTRUCT_PROTECTED_UI_CANDIDATE( proposed_action,
interface_evidence, protected_translator ):
REQUIRE VERIFY_INTERFACE_EVIDENCE( interface_evidence )
Das Expires 29 April 2027 [Page 306]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
proposed_effect = protected_translator .RESOLVE_OPERATION_SEMANTICS(
proposed_action )
IF REQUIRED_EFFECT_FIELDS_UNKNOWN( proposed_effect ): RETURN HOLD
REQUIRE VERIFY_SOURCE_AUTHORITY_SCOPE( proposed_effect )
candidate = protected_translator .AUTHENTICATE_CANDIDATE({ operation:
proposed_effect.operation,
actual_resource: proposed_effect.resource,
9.5.3.32. Source page 1657 of the original specification
intended_recipient: proposed_effect.recipient,
material_parameters: HASH_CANONICAL( proposed_effect.parameters ),
interface_evidence: HASH(interface_evidence),
originating_authority: CURRENT_SOURCE_AUTHORITY() })
RETURN candidate A structured operation descriptor may require later
revalidation when the actual resource operation is constructed.
19.34 — REFERENCE PSEUDOCODE: HUMAN APPROVAL
FUNCTION OBTAIN_TRANSACTION_BOUND_APPROVAL( candidate_act,
protected_approval_service ):
REQUIRE VERIFY_CANDIDATE_ACT( candidate_act )
REQUIRE VERIFY_APPROVAL_REQUIRED( candidate_act )
presentation = protected_approval_service
.CONSTRUCT_VERIFIED_EFFECT_PRESENTATION( candidate_act )
REQUIRE VERIFY_PRESENTATION_CORRESPONDENCE( presentation,
candidate_act )
confirmation = protected_approval_service
.REQUEST_QUALIFIED_CONFIRMATION( presentation )
REQUIRE VERIFY_APPROVER_AUTHORITY(
Das Expires 29 April 2027 [Page 307]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.5.3.33. Source page 1658 of the original specification
confirmation )
REQUIRE VERIFY_CONFIRMATION_AUTHENTICITY( confirmation )
REQUIRE VERIFY_CONFIRMATION_CANDIDATE_BINDING( confirmation,
candidate_act )
REQUIRE VERIFY_CURRENT_APPROVAL_GENERATION()
RETURN PROTECTED_APPROVAL_COMMITMENT({ candidate:
HASH(candidate_act),
presentation: HASH(presentation),
confirmation: HASH(confirmation),
current_source_authority: CURRENT_AUTHORITY_GENERATION() }) The
implementation must not claim a trusted-presentation property unless
its actual confirmation channel provides it.
19.35 — REFERENCE PSEUDOCODE: ACTUAL SINK FINALITY
FUNCTION EFFECTUATE_APPROVED_COMPUTER_USE_ACTION( candidate_act,
approval_or_autonomous_authority, finality_enablement,
protected_finality_sink ):
actual_operation = protected_finality_sink
.RECONSTRUCT_ACTUAL_PENDING_OPERATION()
REQUIRE actual_operation IS VALID
REQUIRE VERIFY_ACTUAL_RESOURCE_IDENTITY( actual_operation )
REQUIRE VERIFY_ACTUAL_OPERATION_CORRESPONDENCE( candidate_act,
actual_operation
9.5.3.34. Source page 1659 of the original specification
REQUIRE VERIFY_SOURCE_AUTHORITY_CURRENT()
REQUIRE VERIFY_APPROVAL_OR_AUTONOMOUS_SCOPE(
approval_or_autonomous_authority, actual_operation )
REQUIRE VERIFY_CURRENT_RESOURCE_STATE()
REQUIRE VERIFY_REQUIRED_INTERFACE_CONTEXT()
Das Expires 29 April 2027 [Page 308]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
REQUIRE VERIFY_CURRENT_REVOCATION()
REQUIRE VERIFY_CURRENT_NON_BEARER_ENABLEMENT( finality_enablement,
actual_operation )
REQUIRE VERIFY_SINK_LOCAL_CONSUMPTION_STATE()
consumed = protected_finality_sink .ATOMIC_CONSUME_FINALITY(
finality_enablement, actual_operation )
IF consumed != COMMITTED: RETURN DENY
RETURN protected_finality_sink .RELEASE_ACTUAL_OPERATION(
actual_operation ) The actual sink must have the relevant enforcement
capability; an upstream browser or screenshot monitor alone may not
supply it.
19.36 — REFERENCE PSEUDOCODE: MATERIAL UI CHANGE
FUNCTION HANDLE_MATERIAL_INTERFACE_CHANGE( candidate_act,
new_interface_state, protected_controller ):
previous = LOAD_COMMITTED_INTERFACE_EVIDENCE( candidate_act )
change = COMPARE_RELEVANT_INTERFACE_PROPERTIES(
9.5.3.35. Source page 1660 of the original specification
previous, new_interface_state )
IF change == NON_MATERIAL: RETURN REQUIRE_CURRENT_SINK_VALIDATION
INVALIDATE_DEPENDENT_FINALITY_ENABLEMENT( candidate_act )
IF CHANGE_EXCEEDS_ORIGINAL_AUTHORITY(change): RETURN
REQUIRE_NEW_SOURCE_AUTHORITY
RETURN REQUIRE_UPDATED_CANDIDATE_AND_VALIDATION Not every visual
mutation requires new human approval, but material effect changes
must not silently inherit earlier authority.
19.37 — WORKED EXAMPLE A: PAYMENT RECIPIENT CHANGES AFTER APPROVAL
An autonomous agent prepares a payment to a specified recipient.
The protected approval interface presents the recipient, amount, and
payment purpose.
Das Expires 29 April 2027 [Page 309]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The authorized principal confirms the operation.
Before the actual payment request reaches the processor, the
destination account is changed.
The Finality Sink reconstructs the actual pending payment.
The recipient does not correspond to the approved effect descriptor.
The payment is refused.
Expected demonstrable result: Approval of one payment cannot
authorize another recipient through a later interface or request
transformation.
19.38 — WORKED EXAMPLE B: STALE SCREENSHOT
An agent captures a screenshot showing one protected document.
The application subsequently changes the active document.
The agent attempts to perform the previously planned delete
operation.
The Finality Sink reconstructs the actual resource and current
document identity.
The current operation differs from the protected Candidate Act.
The deletion is refused.
9.5.3.36. Source page 1661 of the original specification
Expected demonstrable result: A genuine historical screenshot does
not establish authority to modify a different current resource.
19.39 — WORKED EXAMPLE C: UNTRUSTED PAGE INSTRUCTION
A computer-use agent reads a webpage containing text instructing it
to ignore its original task and export protected files.
The webpage content is recorded as lower-trust interface data.
The agent may generate an unauthorized export proposal.
The protected authority controller determines that the operation
exceeds the originating principal's permitted effect envelope.
Das Expires 29 April 2027 [Page 310]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The actual information-release sink refuses the export.
Expected demonstrable result: Untrusted displayed instructions cannot
independently create consequential authority.
19.40 — WORKED EXAMPLE D: BUTTON LABEL MISREPRESENTS ACTUAL EFFECT
A graphical interface displays a button labeled as a harmless preview
action.
The underlying application is configured to submit a destructive
resource command.
The protected system does not rely solely upon the visible label.
The actual Finality Sink reconstructs the destructive operation.
No valid authority exists for the destructive effect.
The resource command is rejected.
Expected demonstrable result: A misleading interface label does not
bypass actual-effect authorization.
19.41 — WORKED EXAMPLE E: AUTHENTICATED USER, WRONG TRANSACTION
A human successfully completes an authentication ceremony.
The requesting application then submits a different consequential
operation from the one presented in the prior UI.
The protected system distinguishes proof of user authentication from
transaction-specific approval.
Where the policy requires confirmation, the actual effect must match
the protected confirmation commitment.
The mismatched operation is refused.
9.5.3.37. Source page 1662 of the original specification
Expected demonstrable result: Successful authentication does not
confer unrestricted approval over subsequent unrelated transactions.
19.42 — WORKED EXAMPLE F: FOCUS CHANGES BEFORE KEYBOARD INPUT
An agent prepares to type a recipient or command into a selected
application.
Das Expires 29 April 2027 [Page 311]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A different window obtains focus.
The keyboard input is delivered to an unintended context.
The protected operation controller verifies the actual operation
subsequently submitted.
If the resulting effect does not match the authorized Candidate Act,
it is refused.
Expected demonstrable result: Correctly generated keyboard input does
not automatically authorize an effect produced by an unintended focus
target.
19.43 — WORKED EXAMPLE G: ACCESSIBILITY LABEL SUBSTITUTION
An agent selects an accessibility element describing a permitted file
export.
The underlying control instead attempts to export a broader document
set.
The protected release sink examines the actual outgoing files.
The proposed effect exceeds the authorized envelope.
The export is withheld.
Expected demonstrable result: Accessibility metadata remains evidence
for operation discovery rather than complete authority to disclose
the actual resources.
19.44 — WORKED EXAMPLE H: MULTI-EFFECT PURCHASE
An autonomous purchasing agent proposes to place an order.
The protected source authority allows the specified item and spending
limit.
The corresponding UI action would additionally initiate an unrelated
paid subscription.
The system identifies the additional consequential effect through an
appropriately controlled application or resource interface.
The unauthorized subscription does not acquire valid finality
enablement.
Das Expires 29 April 2027 [Page 312]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Expected demonstrable result: Approval of one purchase does not
automatically permit all consequential operations coupled to the same
UI action.
19.45 — WORKED EXAMPLE I: APPROVAL REPLAY
9.5.3.38. Source page 1663 of the original specification
A protected approval authorizes one consequential file transfer.
The transfer is performed and the corresponding finality authority
consumed.
The agent later reuses the approval reference to submit another
transfer.
The Finality Sink verifies current consumption state.
The repeated effect is refused.
Expected demonstrable result: A copied human-confirmation artifact
cannot generate unlimited independent file transfers.
19.46 — WORKED EXAMPLE J: AUTONOMOUS OPERATION WITHOUT HUMAN APPROVAL
An enterprise policy authorizes an agent to perform bounded low-
impact resource updates.
The agent prepares one update within the permitted envelope.
No separate human confirmation is required under the selected policy.
The independent validator verifies current source authority.
The protected Finality Sink reconstructs the actual mutation and
consumes operation-specific finality authority.
Expected demonstrable result: The architecture does not universally
require a human approval UI to enforce current actual-effect
finality.
19.47 — WORKED EXAMPLE K: VOICE APPROVAL WITH INCOMPLETE PARAMETERS
An agent requests spoken approval for a financial operation.
The audible prompt omits a material recipient or amount field.
The protected policy requires confirmation of those fields.
Das Expires 29 April 2027 [Page 313]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The presented approval evidence does not establish the specified
transaction-bound confirmation condition.
The effect remains withheld pending a qualified approval.
Expected demonstrable result: A generic affirmative voice response
does not automatically authorize material undisclosed transaction
parameters.
19.48 — WORKED EXAMPLE L: INTERFACE CHANGES AFTER MODEL HANDOFF
A first agent inspects and prepares an interface operation.
9.5.3.39. Source page 1664 of the original specification
A second agent resumes the task after a delay.
The document, resource, or session state has changed.
The protected controller checks current operation and authority
correspondence rather than accepting the first agent's historical
description as current.
Affected enablement is revalidated or invalidated.
Expected demonstrable result: Agent handoff does not preserve
unconditional authority over later changed interface state.
19.49 — WORKED EXAMPLE M: FALSE SUCCESS MESSAGE
An application displays a success message after a payment submission.
The remote payment transaction has not yet been conclusively
confirmed.
The protected system does not automatically treat the UI message as a
qualified actual-effect receipt.
The outcome remains pending or uncertain until sufficient destination
evidence is obtained.
Expected demonstrable result: A displayed confirmation cannot
substitute for qualified proof of actual external effect completion.
19.50 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
1. Forged interface screenshot.
Das Expires 29 April 2027 [Page 314]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
2. Replay of an earlier authentic screenshot.
3. Changed document or browser origin.
4. Browser-frame substitution.
5. Focus change before keyboard input.
6. Pointer target movement.
7. Overlay obscuring the intended control.
8. Clipboard recipient substitution.
9. Hidden form-field modification.
10. Asynchronous JavaScript request mutation.
11. Accessibility label manipulation.
12. Stale accessibility element identity.
13. Screenshot and semantic-tree inconsistency.
9.5.3.40. Source page 1665 of the original specification
14. Malicious prompt text in rendered content.
15. Agent-generated misleading approval summary.
16. Approval challenge bound to the wrong Candidate Act.
17. Human confirmation for a different recipient.
18. Biometric authentication mistaken for transaction authorization.
19. Replayed human approval.
20. Concurrent reuse of one confirmation.
21. Expired approval.
22. Revoked source authority after confirmation.
23. Resource version change after confirmation.
24. Different actual file target.
Das Expires 29 April 2027 [Page 315]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
25. Application redirection to another resource.
26. Additional hidden transaction side effect.
27. Changed tool implementation.
28. Remote service processing different parameters.
29. Privileged helper accepting unrestricted agent commands.
30. Alternate uncontrolled resource path.
31. Network transmission outside the protected release gate.
32. Encrypted-content visibility mismatch.
33. False UI success indication.
34. Lost external acknowledgement.
35. Incomplete negative-effect evidence.
36. Compromised approval presentation service.
37. Compromised interface-observation source.
38. Compromised actual Finality Sink.
39. Snapshot rollback restoring old approval state.
40. Concurrent finality consumption.
41. Hardware command differing from visual presentation.
9.5.3.41. Source page 1666 of the original specification
42. Voice confirmation without authenticated transaction binding.
43. Approval-session or origin confusion.
44. Unauthorized approval reassignment across agents.
45. Material UI mutation after evidence collection.
46. Unbounded automated effect following one broad confirmation.
47. Revocation notification delayed before finality.
Das Expires 29 April 2027 [Page 316]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
48. Incorrect classification of monitoring-only interface controls
as blocking enforcement.
For each threat, the selected implementation must specify the
affected protection boundary and the technical evidence required to
determine whether the actual effect remains controlled.
19.51 — PROPOSED FEASIBILITY AND ADVERSARIAL EXPERIMENTS
The following experiments are non-limiting proposed tests and are not
represented as completed results.
Experiment 1 — Valid Interface Observation: Collect protected
evidence from a permitted UI state.
Experiment 2 — Origin Mismatch: Replace the observed browser or
application origin.
Experiment 3 — Visual Replay: Present a stale screenshot after
changing the resource.
Experiment 4 — Current UI Mutation: Modify a relevant form field
after evidence collection.
Experiment 5 — Focus Substitution: Redirect keyboard input to another
window.
Experiment 6 — Click-Target Movement: Change the selected element
before a pointer action.
Experiment 7 — Overlay Attack: Introduce an occluding interface
element.
Experiment 8 — Accessibility Metadata Change: Modify a semantic
element label without changing the actual resource operation.
Experiment 9 — Hidden Parameter Mutation: Submit a different
recipient or amount than the displayed values.
Experiment 10 — Resource Alias Change: Redirect the actual resource
identity.
Experiment 11 — Protected Effect Translation: Construct a Candidate
Act identifying the intended consequential operation.
Experiment 12 — Material Parameter Identification: Verify the correct
set of security-relevant operation fields.
Das Expires 29 April 2027 [Page 317]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Experiment 13 — Invalid Semantic Contract: Withhold effectuation when
the required action semantics are unresolved.
9.5.3.42. Source page 1667 of the original specification
Experiment 14 — Trusted Presentation: Present protected material
transaction parameters through a qualified confirmation channel.
Experiment 15 — Misleading Agent Summary: Compare an agent-authored
summary with an independently determined effect descriptor.
Experiment 16 — Valid Approval Binding: Authenticate an approval
committed to the correct Candidate Act.
Experiment 17 — Authentication Without Approval: Verify that a login
or user-verification result is not treated as unrestricted
transaction confirmation.
Experiment 18 — Approval for Different Resource: Reuse confirmation
against an unrelated actual target.
Experiment 19 — Amount Substitution: Change a protected payment
amount after approval.
Experiment 20 — Recipient Substitution: Change the destination
account or external recipient.
Experiment 21 — Content Substitution: Change the outgoing protected
document.
Experiment 22 — Expired Confirmation: Exercise a formerly valid
approval after its required validity window.
Experiment 23 — Revoked Confirmation Authority: Revoke original
source permission before effectuation.
Experiment 24 — Confirmation Replay: Attempt repeated execution under
one single-use approval.
Experiment 25 — Concurrent Approval Exercise: Race multiple agents
against one protected finality allowance.
Experiment 26 — Autonomous Bounded Action: Execute a valid
preauthorized operation without per-act human approval.
Experiment 27 — Autonomous Scope Expansion: Attempt a materially
broader operation without new permission.
Das Expires 29 April 2027 [Page 318]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Experiment 28 — Browser Navigation Race: Navigate away before a
delayed action executes.
Experiment 29 — Dynamic DOM Mutation: Alter relevant document-object
state after collection-time evidence.
Experiment 30 — Clipboard Substitution: Paste content different from
the protected approved descriptor.
Experiment 31 — Multi-Effect UI Action: Test separate authorization
of multiple downstream consequences.
Experiment 32 — Hidden Side Effect: Attempt an unapproved additional
resource mutation.
Experiment 33 — Privileged Broker: Verify the actual effect under a
protected IPC-controlled helper.
9.5.3.43. Source page 1668 of the original specification
Experiment 34 — Alternate Resource API: Attempt to bypass the
protected UI route.
Experiment 35 — Actual Sink Reconstruction: Verify the real pending
resource and operation fields.
Experiment 36 — Resource Version Change: Change current resource
state before commit.
Experiment 37 — Qualified Remote Result: Confirm actual resource
completion independently of the UI message.
Experiment 38 — False Success Message: Display success while the
resource has not committed the effect.
Experiment 39 — Lost Acknowledgement: Preserve unresolved external
outcome instead of automatically retrying.
Experiment 40 — Stale Snapshot: Restore an old agent or approval
state after consumption.
Experiment 41 — Agent Handoff: Transfer a pending computer-use task
to a different autonomous process.
Experiment 42 — Voice Approval: Test operation-specific binding and
missing material spoken parameters.
Das Expires 29 April 2027 [Page 319]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Experiment 43 — Hardware Command Approval: Bind a displayed control
request to the actual device command.
Experiment 44 — Privacy Disclosure: Verify approved information,
actual outgoing information, and current recipient.
Experiment 45 — Time-Bounded Approval: Require current temporal
eligibility.
Experiment 46 — Cross-Committed Evidence: Verify collection-time
interface evidence against independent execution-time validation.
Experiment 47 — Changed Tool Implementation: Invalidate affected
finality authority after a material action-contract change.
Experiment 48 — Changed Enforcement Path: Detect an alternate
uncontrolled effect-capable interface.
Experiment 49 — Incomplete Observation: Demonstrate that an
unverified screenshot does not establish complete hidden request
semantics.
Experiment 50 — Full End-to-End Test: Verify the chain from observed
interface through Candidate Act, optional approved effect, current
authority, protected enablement, actual sink reconstruction,
consumption, and qualified real-effect outcome.
Expected results must be evaluated using actual resource state or
qualified effect observations, not merely the agent's textual report
of success.
19.52 — PHOSITA IMPLEMENTATION DETAILS
9.5.3.44. Source page 1669 of the original specification
19.52.1 — Minimum Reference Prototype
A feasible reference implementation may comprise:
An autonomous browser or desktop agent;
A protected interface-observation module;
An application transaction adapter;
An optional separate approval service;
A protected authorization and revocation store;
Das Expires 29 April 2027 [Page 320]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A finality gateway;
A resource-version controller;
And an authoritative consumption-state store.
19.52.2 — Initial Demonstration
The agent proposes one protected file or database mutation from a
graphical interface.
19.52.3 — Interface Evidence
The observation component records relevant application and resource
state.
19.52.4 — Candidate Act
The protected translator constructs a bounded operation descriptor.
19.52.5 — Optional Approval
A trusted or qualified confirmation service displays the relevant
transaction details and obtains authenticated approval.
19.52.6 — Finality Enablement
A protected controller prepares one operation-specific non-bearer
authority.
19.52.7 — Actual Effectuation
The receiving resource reconstructs the actual mutation and verifies
correspondence.
19.52.8 — Replay Test
The agent resubmits an already consumed approval.
19.52.9 — Mutation Test
The actual recipient or resource is changed before effectuation.
19.52.10 — Resource-State Test
Das Expires 29 April 2027 [Page 321]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.5.3.45. Source page 1670 of the original specification
The resource version changes before final commit.
19.52.11 — Outcome Test
The system obtains evidence of actual resource completion.
19.52.12 — Trust Qualification
The implementation specifies which components can observe,
authenticate, block, and commit the actual effect.
19.53 — OPTIONAL ADVANCED VARIATIONS
19.53.1 — Browser-Native Finality
A browser may cooperate with a protected receiving service to bind
selected actual requests to operation-specific finality.
19.53.2 — Desktop Privileged-Broker Finality
A protected local service may mediate resource operations invoked
through graphical automation.
19.53.3 — Mobile Application Finality
Structured application actions may be converted into bounded
Candidate Acts before actual app or service effectuation.
19.53.4 — Trusted Hardware Approval
A protected hardware-backed confirmation path may authenticate
selected transaction details and approval.
19.53.5 — Remote Human Approval
An authenticated external approval device may confirm an operation
prepared by an autonomous agent.
19.53.6 — Autonomous Low-Risk Lane
Bounded operations may execute without repeated human approval while
retaining actual-effect finality.
19.53.7 — Voice and Multimodal Approval
Das Expires 29 April 2027 [Page 322]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A qualified transaction description may be presented and confirmed
through several modalities.
19.53.8 — Accessibility-Driven Computer Use
Accessibility state may contribute evidence while the actual effect
remains independently verified.
19.53.9 — Remote Desktop Control
9.5.3.46. Source page 1671 of the original specification
The architecture may bind a remote graphical session to the actual
remote service or device command.
19.53.10 — Protected Clipboard Operations
Copied or pasted information may be compared with approved content
commitments.
19.53.11 — Payment and Financial Actions
Recipient, amount, account, and source authorization may be checked
at the transaction sink.
19.53.12 — Information Release
Outgoing files and protected data may be verified independently of
the displayed upload control.
19.53.13 — Industrial Device UI
A control-panel action may be bound to the actual pending device
command.
19.53.14 — Multi-Agent Computer Use
Several agents may collaborate without sharing reusable complete
transaction authority.
19.53.15 — Long-Running Task Continuation
Pending UI actions may be revalidated after pause, model replacement,
or task migration.
19.53.16 — Dynamic Application Updates
Das Expires 29 April 2027 [Page 323]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Material application-action changes may invalidate existing
interface-to-effect authority.
19.53.17 — Confidential Computing
Protected components may authenticate selected interface or operation
evidence while an independent sink controls the resource effect.
19.53.18 — Protected Browser-to-Service Protocol
A browser or action controller may forward a transaction-bound
operation reference to an independent receiving service.
19.53.19 — Hardware Command Confirmation
An approving principal may authorize a specific bounded physical
command subject to device-local finality.
19.53.20 — Integrated Autonomous Finality Platform
A common protected infrastructure service may support browser,
desktop, mobile, remote, and hardware operation classes.
These variations are illustrative and non-limiting.
9.5.3.47. Source page 1672 of the original specification
19.54 — PROPOSED INVENTIVE-STEP ANALYSIS
19.54.1 — Established Foundations
Screen capture, browser automation, accessibility interfaces, human
confirmation dialogs, cryptographic authentication, transaction
signing, conditional resource requests, protected service mediation,
and transactional state are established technical fields.
The invention does not claim these individually.
19.54.2 — Objective Technical Problem
A candidate objective technical problem is:
How to ensure that an AI-agent-initiated consequential operation
corresponds to the source-authorized or human-approved effect despite
mutable graphical interface state, potentially untrusted observation,
delayed input execution, action transformation, and changes occurring
before the actual resource mutation.
Das Expires 29 April 2027 [Page 324]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
19.54.3 — Candidate Technical Solution
A protected architecture comprising:
Qualified interface-state evidence;
An independently determined effect descriptor;
Optional transaction-bound confirmation;
Current source-authority validation;
Protected interface and resource correspondence;
Separate non-bearer finality enablement;
Independent actual-operation reconstruction;
And sink-local protected consumption.
19.54.4 — Technical Interaction
The interface collector establishes the selected observed state.
The effect translator identifies the proposed consequential
operation.
The approval component, when required, binds a qualified confirmation
to the specified material effect parameters.
The independent validator checks current authority and relevant
correspondence.
The finality controller establishes a separate operation-specific
protected enablement.
The actual Finality Sink reconstructs the resource operation
presented for execution.
9.5.3.48. Source page 1673 of the original specification
The sink verifies that the real effect matches the authorized
envelope and current resource conditions.
The consumption controller prevents unsupported repeated exercise.
19.54.5 — Not Merely a Screenshot
Das Expires 29 April 2027 [Page 325]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A screenshot supplies visual evidence but does not necessarily
establish hidden transaction details or current source authority.
The proposed combination separately validates the actual resource
effect.
19.54.6 — Not Merely Browser Automation
A browser automation system may generate clicks and form submissions.
The proposed combination retains a mandatory resource-side authority
transition independent of the agent's ability to operate the
interface.
19.54.7 — Not Merely a Human Confirmation Dialog
A conventional confirmation may display an operation summary.
The proposed stronger implementation binds qualified approval to the
material effect parameters and requires actual sink-side
correspondence before release.
19.54.8 — Not Merely User Authentication
Successful authentication does not automatically authorize every
subsequent operation.
The selected implementation requires separate transaction-specific or
bounded autonomous effect authority.
19.54.9 — Not Merely Conditional Resource Update
An existing resource-version check may prevent a stale mutation.
The proposed architecture additionally binds protected UI
observation, approval scope, current source authority, and non-bearer
finality consumption.
19.54.10 — Not Merely Transaction Signing
A signed operation may authenticate specified fields.
The proposed principal arrangement additionally requires current
source authority, actual sink operation reconstruction, and protected
resource-side finality.
19.54.11 — Candidate Narrow Inventive Kernel
Das Expires 29 April 2027 [Page 326]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A protected computer-use execution system in which qualified
interface-state evidence is bound to a specific Candidate Act and its
material consequential-effect parameters, an optional authenticated
approval is committed to the same effect envelope, a protected
controller separately establishes operation-specific non-bearer
finality enablement, and an independent Finality Sink reconstructs
the actual pending resource operation and refuses
9.5.3.49. Source page 1674 of the original specification
effectuation unless the current source authority, actual-effect
correspondence, relevant interface and resource state, and sink-local
protected consumption conditions remain valid.
19.54.12 — Additional Transaction-Confirmation Kernel
A narrower candidate may require independently determined protected
presentation of transaction details, authenticated confirmation bound
to the same operation, and resource-side verification preventing
approval substitution.
19.54.13 — Additional Dynamic-Interface Kernel
Another candidate may require protected invalidation or revalidation
of pending finality enablement after a material change in interface
or effect semantics.
19.54.14 — Additional Cross-Modal Kernel
Another candidate may require visual, accessibility, and application-
state evidence to be qualified according to their distinct
observation properties, with actual resource-side operation
verification remaining mandatory.
19.54.15 — Additional Protected-Agent Kernel
Another candidate may require a computer-use agent to operate through
a protected intermediary incapable of releasing the actual resource
effect without operation-specific finality consumption.
19.54.16 — Hindsight Considerations
A careful inventive-step analysis should determine whether the
closest earlier systems already combine transaction-bound
confirmation, actual operation comparison, resource-side
authorization, and replay-resistant state.
Das Expires 29 April 2027 [Page 327]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The simple use of a browser screenshot together with a confirmation
dialog may be conventional.
Similarly, cryptographically signing transaction details is
established.
A stronger technical distinction must identify the precise additional
protected dependency, such as independent actual-operation
reconstruction at an effectuation sink, current authorization and
resource-state verification, and mandatory non-bearer finality
consumption.
A later argument should not rely solely on the fact that one
individual reference lacks a particular named component.
Instead, it should analyze the closest references' actual mechanisms,
technical motivations, and supported enforcement boundaries.
19.55 — INDUSTRIAL APPLICABILITY
19.55.1 — Autonomous Desktop Agents
Computer-use agents may interact with desktop software while
resource-side controls independently enforce actual effects.
9.5.3.50. Source page 1675 of the original specification
19.55.2 — Browser-Based Automation
Browser automation may remain subject to protected receiving-resource
authorization.
19.55.3 — Enterprise Application Workflows
Approval of one enterprise operation may be bound to the actual
application transaction.
19.55.4 — Financial Systems
Payments and transfers may require correspondence between approved
and actual recipients, amounts, and accounts.
19.55.5 — Electronic Commerce
Purchase confirmations may be bound to specific product, merchant,
amount, and transaction scope.
19.55.6 — Cloud Administration
Das Expires 29 April 2027 [Page 328]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Infrastructure modifications may be verified against current
resources and approved operation envelopes.
19.55.7 — Database Administration
Graphical database-management operations may require actual commit-
time authority and resource-version checks.
19.55.8 — File Management
Deletion, copying, and export operations may verify actual target
files.
19.55.9 — Information Disclosure
Data transfers may be checked against the actual outgoing content and
recipient.
19.55.10 — Customer Service Automation
Automated account changes may remain bounded by actual resource-side
permissions.
19.55.11 — Credential Management
An agent may use a protected credential broker without receiving
reusable complete authority.
19.55.12 — Operating-System Administration
Privileged system actions may be bound to actual operations rather
than general UI approvals.
19.55.13 — Healthcare Information Systems
Selected protected record modifications or disclosures may require
operation-bound authority.
19.55.14 — Industrial Automation
9.5.3.51. Source page 1676 of the original specification
Graphical control commands may be tied to actual equipment
operations.
19.55.15 — Robotics
Das Expires 29 April 2027 [Page 329]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Human or autonomous control proposals may be independently checked at
protected actuator interfaces.
19.55.16 — Telecommunications
Network management interfaces may be bound to actual configuration
changes.
19.55.17 — Remote Device Management
Remote graphical operation may remain subject to current receiving-
device authority.
19.55.18 — Multi-Agent Systems
Agent collaboration may preserve original task authority and
transaction-specific finality.
19.55.19 — Multimodal Assistants
Voice, text, visual, and touch interactions may use the same
protected effect-binding model.
19.55.20 — Future Autonomous Critical Systems
Computer-mediated operations may remain protected against a mismatch
between apparent approval and actual consequential execution.
19.56 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
19.56.1 — Candidate Independent System Claim
A system comprising:
A protected interface-observation component configured to establish
qualified evidence concerning an interface state associated with a
proposed consequential operation;
A protected translation component configured to construct a Candidate
Act and a material actual-effect descriptor;
An authorization component configured to establish source authority
and, where required, transaction-bound human approval;
An independent protected validation component configured to evaluate
current authority and operation correspondence;
Das Expires 29 April 2027 [Page 330]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A finality controller configured to establish scoped non-bearer
finality enablement;
And an independent Finality Sink configured to reconstruct the actual
pending consequential operation, verify correspondence with the
authorized effect descriptor and current authority, and consume the
enablement before permitting the effect.
9.5.3.52. Source page 1677 of the original specification
19.56.2 — Candidate Independent Method Claim
A method comprising:
Obtaining qualified interface evidence;
Constructing a consequential Candidate Act;
Maintaining the effect non-effective;
Determining material operation parameters;
Establishing current source authorization;
Obtaining authenticated human confirmation where required;
Binding the relevant approval or autonomous authority to a protected
effect descriptor;
Independently validating current operation conditions;
Preparing scoped non-bearer finality authority;
Reconstructing the actual pending operation at its Finality Sink;
And permitting effectuation only upon verification of the actual
operation, current authority, and protected consumption conditions.
19.56.3 — Candidate Independent Human-Approval Claim
A candidate may require a qualified approval-presentation service to
commit a material transaction descriptor, an authenticated approver
response bound to that descriptor, and an independently enforcing
sink to verify the actual resource operation against the same
commitment.
19.56.4 — Candidate Independent Dynamic-UI Claim
Das Expires 29 April 2027 [Page 331]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Another candidate may require invalidation of pending finality
enablement following a material interface-state or operation-contract
change before effectuation.
19.56.5 — Candidate Independent Computer-Use Broker Claim
Another candidate may require a lower-trust computer-use agent to
submit Candidate Acts to a protected privileged broker, with the
broker independently resolving and verifying the actual resource
effect before consuming operation-specific authority.
19.57 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
1. The interface evidence includes a screenshot commitment.
2. The interface evidence includes a browser or application origin.
3. The interface evidence includes a browsing-context identifier.
4. The interface evidence includes a window or process identity.
9.5.3.53. Source page 1678 of the original specification
5. The interface evidence includes a document-object representation.
6. The interface evidence includes an accessibility element
representation.
7. The interface evidence includes a protected state generation.
8. An earlier interface observation is associated with freshness
conditions.
9. A replayed historical screenshot cannot independently authorize
current effectuation.
10. The Candidate Act is constructed from a graphical or structured
application action.
11. The protected translator identifies material consequential
operation parameters.
12. An unresolved effect semantic prevents finality authorization.
13. A protected effect descriptor includes the actual resource
identity.
Das Expires 29 April 2027 [Page 332]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
14. A protected effect descriptor includes the intended recipient
where relevant.
15. A protected effect descriptor includes an amount or bounded
parameter where relevant.
16. A protected effect descriptor includes an outgoing content
commitment where relevant.
17. A human confirmation requirement is determined according to the
applicable source policy.
18. A bounded autonomous operation may proceed without per-act human
confirmation.
19. A protected approval presentation identifies material effect
parameters.
20. The approval presentation is derived from an independently
verified operation descriptor.
21. An authenticated confirmation is bound to one Candidate Act.
22. A confirmation is bound to the selected protected resource.
23. A confirmation is bound to material operation parameters.
24. A confirmation is associated with a protected transaction nonce.
25. A confirmation is associated with an authority generation.
26. A confirmation is associated with applicable temporal validity.
27. Successful user authentication is distinguished from
transaction-specific approval.
28. A confirmation mechanism may employ an authenticated
cryptographic response.
29. A protected display or approval service may be used where its
actual integrity properties support the selected claim.
30. The system does not presume subjective understanding from
cryptographic authentication alone.
31. A material interface change invalidates affected finality
enablement.
Das Expires 29 April 2027 [Page 333]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.5.3.54. Source page 1679 of the original specification
32. A cosmetic interface change may leave the authorized-effect
envelope unchanged.
33. A material operation-contract change requires current
revalidation.
34. A current resource-version mismatch prevents effectuation.
35. A changed recipient prevents effectuation unless separately
authorized.
36. A changed amount prevents effectuation unless within the valid
authorized envelope.
37. A changed file or document identity prevents effectuation unless
separately authorized.
38. A clipboard or input substitution is detected through actual-
effect mismatch.
39. An accessibility element label alone is insufficient for
finality authorization.
40. A visually similar interface origin does not establish the same
protected resource identity.
41. The actual Finality Sink reconstructs the pending resource
operation independently of the agent's original description.
42. The sink verifies current source authority.
43. The sink verifies current revocation state.
44. The sink verifies the relevant resource identity.
45. The sink verifies actual operation parameters.
46. The sink verifies the relevant human-approval or autonomous
effect envelope.
47. The sink verifies current mandatory enforcement coverage.
48. The sink verifies operation-specific non-bearer finality
enablement.
49. The sink verifies current protected consumption state.
Das Expires 29 April 2027 [Page 334]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
50. A previously consumed approval cannot independently authorize
another effect.
51. Several concurrent agents cannot validly consume one single-use
finality enablement more than once under the selected authoritative
coordination model.
52. A protected browser or application gateway may provide
effectuation mediation.
53. A protected privileged IPC service may enforce actual operation
finality.
54. A remote receiving resource may enforce finality at its
transaction boundary.
55. An application action producing several effects may be
decomposed into separate Candidate Acts.
56. A causal successor effect may require an accepted earlier
actual-effect receipt.
57. A UI success message is not automatically a qualified external-
effect receipt.
9.5.3.55. Source page 1680 of the original specification
58. An uncertain external outcome does not automatically restore
consumed finality authority.
59. A protected hardware device may verify an actual command against
an approved effect descriptor.
60. A protected finality arrangement may operate with browser,
desktop, mobile, remote, voice, graphical, or accessibility
interfaces.
19.58 — NON-LIMITING IMPLEMENTATION AND CROSS-COMBINATION CLAUSE
The disclosed visual, semantic, approval, actual-operation, evidence,
and finality mechanisms may be implemented in technically compatible
combinations.
A particular implementation may use screenshots.
Another may use accessibility evidence.
Another may use browser document-state inspection.
Das Expires 29 April 2027 [Page 335]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Another may use structured application-action descriptors.
Another may use a privileged local broker.
Another may use a qualified human confirmation service.
Another may operate autonomously under a bounded original grant.
Another may use an authenticated remote approval mechanism.
Another may use a protected hardware command controller.
Another may enforce finality at a receiving network or database
service.
Where a claim requires a human confirmation, the selected
implementation must provide the specified qualified confirmation
properties.
Where a claim does not require human approval, protected autonomous
authority may serve as the originating permission.
Where a claim requires actual resource-side operation reconstruction,
the implementation must provide a technically sufficient
effectuation-boundary observation or reconstruction mechanism.
A screenshot, document-object tree, accessibility label,
authentication ceremony, or signed approval is not assumed to prove
every property of the real consequential operation.
No particular browser, operating system, commercial tool framework,
device manufacturer, cryptographic protocol, processor, machine-
learning model, or user-interface toolkit is universally required
unless recited by a selected claim.
The equations, reference code, state machines, algorithms, examples,
and proposed experiments are illustrative and non-limiting technical
aids for a person having ordinary skill in the art.
Compatible mechanisms from other embodiments may be combined where
sufficiently supported.
9.5.3.56. Source page 1681 of the original specification
The disclosed protection does not presume that an actual resource
effect can be blocked if the relevant resource remains independently
reachable through an uncontrolled effect-capable path.
Das Expires 29 April 2027 [Page 336]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The disclosed approval mechanisms establish technical authentication
and operation-binding properties; they do not purport to establish
the approving human's unobservable mental state.
19.59 — FINAL TECHNICAL SUMMARY
The present Embodiment 19 discloses an execution-finality
architecture for autonomous computer-use operations in which
interface observation, operation interpretation, human confirmation,
and actual consequential execution are treated as distinct protected
technical stages.
An autonomous agent may inspect a graphical, browser, accessibility,
voice, or structured application interface.
The agent may generate a Candidate Act describing a proposed
consequential operation.
A protected observation instance may establish authenticated evidence
concerning the relevant interface state and origin.
A protected translation component determines the proposed actual-
effect envelope.
Where the applicable source policy requires human approval, a
qualified confirmation service presents the material effect
parameters and obtains an appropriately authenticated confirmation
bound to that operation.
Where bounded autonomous authority is sufficient, the operation may
proceed without a separate human confirmation.
In both cases, actual effectuation remains dependent upon current
protected authority.
A protected validation instance determines the required
correspondence among interface evidence, source permission, any
applicable approval, and the proposed consequence.
A separate finality controller establishes operation-specific non-
bearer enablement.
At the real effectuation boundary, an independent Finality Sink
reconstructs the actual pending operation and verifies current source
authority, actual resource identity, material effect parameters,
applicable resource and interface state, and protected consumption
conditions.
Das Expires 29 April 2027 [Page 337]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
An authentic screenshot does not independently authorize a changed
resource effect.
A valid human confirmation does not automatically authorize a
different transaction.
A successful authentication ceremony does not establish unrestricted
consequential permission.
A correct browser click does not establish that the downstream effect
matches the approved operation.
A success message does not automatically prove completion of the
intended real effect.
The architecture may be implemented using present-day computing,
browser, cryptographic, transaction, resource-control, and hardware
mechanisms.
9.5.3.57. Source page 1682 of the original specification
The principal candidate inventive technical concept of Embodiment 19
is a protected computer-use execution-finality system in which
qualified interface-state evidence and an operation-specific
authorized-effect descriptor are bound to a Candidate Act, optional
authenticated human confirmation is committed to the same material
effect parameters, and an independent Finality Sink reconstructs the
actual pending resource operation and refuses consequential
effectuation unless current source authority, approval or autonomous
effect scope, operation correspondence, relevant resource state, and
protected non-bearer finality consumption conditions are satisfied.
19.60 — SHORT IMPLEMENTATION USING EXISTING TECHNOLOGIES
A person having ordinary skill in the art may implement the disclosed
mechanisms by combining or substituting selected existing components:
Existing technology Optional implementation role Browser automation
and WebDriver interfaces Observe and interact with browser contexts
DOM and accessibility APIs Obtain semantic interface and element
evidence Screen capture and computer vision Obtain visual-state
evidence
Passkeys / WebAuthn Authenticate an approver or bind a challenge to
protected transaction data Secure key storage / hardware-backed keys
Das Expires 29 April 2027 [Page 338]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Authenticate selected evidence and authority commitments OAuth 2.0
and structured authorization details Establish originating and
operation-scoped permission
Token introspection and revocation Evaluate current credential status
IPC and protected service brokers Separate untrusted agent
computation from privileged effectuation Conditional HTTP requests
and resource versions Reject stale or incompatible resource mutations
Transactional databases Maintain current authority, approval, and
consumption state
9.6. Miscellaneous Embodiment M-2: Existing Security Protocols as
Qualified Inputs to Sink-Local Finality
Original technical source global pages 1898-1952; input volume
TECHNICAL SPECIFICATION -1542-2011.pdf. Primary Part 4 topic:
Miscellaneous Embodiment M-2: Existing Security Protocols as
Qualified Inputs to Sink-Local Finality. The patent specification
may present optional embodiments, alternative formulations and claim
proposals; preserving its wording does not convert each option into a
requirement of a standard.
9.6.1. Protected Architecture and Trust-Boundary Diagram
[OAuth / COSE / app permission / key proof]
[IPC / network / attestation / hardware]
|
[Protected standards adapters]
|
[Translate authorization into effect scope]
|
[Coverage / current revocation / sink state]
|
[Actual-operation enforcing Finality Sink]
Figure 22: Miscellaneous Embodiment M-2: Existing Security
Protocols as Qualified Inputs to Sink-Local Finality —
architecture
9.6.2. Operational Decision and Fail-Closed Flowchart
Das Expires 29 April 2027 [Page 339]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
[Receive existing security result]
|
<What property does it actually prove?>
|
<Enough for exact current source effect?>--NO-->[Not finality]
|YES
<Coverage / protected state verified?>--NO-->[Withhold]
|YES
[Sink reconstruct and verify actual act]
|
<Act/scope/state match?>--NO-->[Refuse]
|YES
[Consume / controlled effect]
Figure 23: Miscellaneous Embodiment M-2: Existing Security
Protocols as Qualified Inputs to Sink-Local Finality —
operational flowchart
9.6.3. Original Page-by-Page Technical Disclosure
9.6.3.1. Source page 1898 of the original specification
MISCELLANEOUS EMBODIMENT M-2
STANDARDS-INTEROPERABLE, PLATFORM-INDEPENDENT EXECUTION-FINALITY
CONSTITUTION USING EXISTING AUTHORIZATION, CRYPTOGRAPHIC, OPERATING-
SYSTEM, NETWORK, IPC, SANDBOX, NOTIFICATION, AND HARDWARE SECURITY
MECHANISMS
M-2.0 — COMPLETE TECHNICAL TITLE
Systems, Methods, and Apparatus for Constituting Protected Operation-
Specific Execution-Finality Authority from Heterogeneous
Authorization and Security Mechanisms Using Independently Verified
Authorization Dependencies, Protected Authorization-to-Effect
Translation, Current Revocation and Enforcement-Topology Commitments,
Scoped Non-Bearer Finality Enablement, and Mandatory Sink-Local
Actual-Operation Verification and Consumption
M-2.0.1 — Technical Purpose
The present Miscellaneous Embodiment M-2 discloses systems, methods,
apparatus, software components, protected services, hardware-assisted
enforcement structures, communication protocols, machine-verifiable
records, and non-limiting implementation variations for integrating
existing authorization and security mechanisms into a protected
autonomous execution-finality architecture.
Das Expires 29 April 2027 [Page 340]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The embodiment addresses the technical problem that different
authorization and security systems may independently establish
permission, identity, possession of a cryptographic key, process
isolation, permitted network access, resource visibility, message
delivery, configuration state, or security-event observation, without
necessarily establishing current authority to perform the particular
consequential operation actually presented at a resource effectuation
boundary.
An autonomous computational entity may be authorized to invoke an
application interface while lacking permission to perform the
particular resource mutation that an invocation would produce.
A token may be active while the proposed operation exceeds its
authorized effect scope.
A sender may demonstrate possession of a bound cryptographic key
while the actual request body, recipient, resource version, or
subsequent operation differs from the previously authorized effect.
A security monitor may observe an operation without having the
ability to prevent its consequence.
A sandbox may constrain one execution environment while a privileged
broker or independently reachable resource interface retains a
different effectuation path.
A revocation notification may be delivered to one component without
having been applied at the protected resource.
A cryptographic signature may authenticate a previous approval
without establishing that the actual operation remains current, has
not been revoked, or has not already consumed its permitted
authority.
The disclosed invention does not require replacing each of these
established mechanisms.
9.6.3.2. Source page 1899 of the original specification
Instead, in selected implementations, existing authorization and
security mechanisms provide qualified inputs or enforcement functions
within a distinct protected execution-finality relationship.
Das Expires 29 April 2027 [Page 341]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The protected architecture identifies the authorization scope
established by each input mechanism, determines the actual technical
conditions under which the mechanism can enforce a particular
consequential operation, and prevents an evidentiary or upstream
permission result from automatically becoming executable finality
authority.
A protected finality controller establishes operation-specific
enablement only upon satisfaction of the applicable authority and
evidence predicates.
At the actual effectuation boundary, a designated Finality Sink
independently obtains or reconstructs the actual pending operation,
verifies the required current authority and enforcement conditions,
and performs the corresponding protected consumption transition
before permitting the consequence.
The principal implementation may additionally couple current
authority to revocation generations, effectuation-path coverage
state, resource identity, protected hardware or software execution
configuration, and bounded temporal validity.
M-2.0.2 — Fundamental Technical Principle
A component that proves identity, permission, key possession, sandbox
membership, request delivery, or enforcement attachment does not
necessarily prove that the actual pending consequence is currently
authorized.
In the present embodiment, a heterogeneous authorization result may
be used as evidence or as a bounded technical enforcement
contribution, without automatically being treated as sufficient
authority to make an external or persistent effect effective.
A valid authorization result is distinguished from:
A fully resolved operation descriptor;
An independently verified current authority state;
A qualified mandatory effectuation path;
A protected finality enablement;
And a sink-local protected exercise of that enablement.
M-2.0.3 — Principal Technical Combination
Das Expires 29 April 2027 [Page 342]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
In a principal implementation, the disclosed combination comprises:
(a) a consequential Candidate Act constructed from an autonomous
application's proposed operation;
(b) an authorization-source adapter capable of obtaining qualified
evidence from one or more existing permission systems;
(c) a protected operation-translation mechanism binding that evidence
to a canonical effect descriptor;
9.6.3.3. Source page 1900 of the original specification
(d) a protected evidence collector and independent current validation
function;
(e) a current authority-dependency and revocation-generation
verifier;
(f) a mechanism establishing that the corresponding actual
effectuation path is subject to suitable mandatory enforcement;
(g) a protected authority controller constituting scoped non-bearer
finality enablement;
(h) a designated Finality Sink capable of independently determining
the actual pending consequential operation;
(i) a protected sink-local authority and consumption state; and
(j) a fail-closed release condition rejecting an operation when
required source, actual-effect, revocation, enforcement, or
consumption predicates cannot be established.
The selected technical relationship is intended to operate even when
the underlying permission system, cryptographic protocol, process
isolation mechanism, enforcement hook, or network-control
implementation is replaced by a functionally compatible alternative.
M-2.0.4 — Separation Between Primitives and the Claimed Relationship
The embodiment does not characterize conventional token issuance,
token revocation, token introspection, proof-of-possession
authentication, mutual authentication, operating-system sandboxing,
interprocess communication, protected cryptographic key storage,
network filtering, event notifications, transactional databases, or
resource access control as individually invented.
Das Expires 29 April 2027 [Page 343]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
These functions may be employed as known technical substrates.
The proposed technical combination concerns the mandatory state and
evidence dependencies by which selected substrate outputs become
necessary but insufficient inputs to operation-specific consequential
authority, with separate protected finality constitution and actual
effectuation verification.
M-2.0.5 — Non-Limiting Implementation Models
The present invention may be implemented through one or more of the
following broad models:
A software authorization-and-resource-gateway implementation;
A mobile or desktop operating-system implementation;
A protected application-action implementation;
A privileged interprocess service implementation;
A network egress implementation;
A cloud or enterprise API implementation;
A distributed cross-domain implementation;
A protected credential-broker implementation;
9.6.3.4. Source page 1901 of the original specification
A hardware-backed authority implementation;
A device-command implementation;
A bounded offline implementation;
Or a hybrid implementation combining selected mechanisms.
No particular commercial operating system, cloud environment,
identity provider, AI model, or cryptographic hardware product is
universally necessary.
M-2.1 — TECHNICAL FIELD
This embodiment relates to autonomous computing security, execution-
finality enforcement, authorization protocol interoperability,
machine-verifiable operation scope, proof-of-possession
Das Expires 29 April 2027 [Page 344]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
authentication, protected revocation, cryptographic authority
binding, operating-system security, application tool invocation,
privileged service mediation, network egress control, hardware-backed
keys, resource-specific transactional control, and protected
consequential execution.
More particularly, the embodiment concerns transforming qualified
outputs of heterogeneous existing security mechanisms into precisely
bounded operation-specific authority and enforcing that authority at
the actual resource boundary rather than relying upon upstream
application permission alone.
M-2.2 — SPECIFIC TECHNICAL PROBLEMS
M-2.2.1 — Authorization-to-Effect Semantic Gap
An existing authorization mechanism may identify a permitted service,
API, scope, or general action without independently determining the
complete consequential operation that is about to occur.
M-2.2.2 — Active-Credential Gap
A credential may remain active while the proposed effect is outside
the original permitted task or exceeds current resource scope.
M-2.2.3 — Proof-of-Possession Gap
A requester may prove possession of a cryptographic key without
proving that every security-relevant field of the actual operation
matches independently established authorization.
M-2.2.4 — Structured-Intent Gap
An application may provide a structured proposed action, but the
action's actual resource-side behavior may differ because of
parameter resolution, redirects, aliases, tool implementation
changes, or additional side effects.
M-2.2.5 — Isolation-to-Effect Gap
9.6.3.5. Source page 1902 of the original specification
A sandbox may restrict selected process privileges while an available
privileged helper or remote service can still cause consequential
effects.
M-2.2.6 — Observation-to-Blocking Gap
Das Expires 29 April 2027 [Page 345]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
An operating-system monitor may report an event without possessing
authority to prevent the corresponding effect.
M-2.2.7 — Network-Flow-to-Content Gap
A network filter may identify endpoints and connections while lacking
authenticated access to the plaintext content or application
semantics required by the authorization policy.
M-2.2.8 — Cryptographic-Signature-to-Finality Gap
A protected signature may authenticate a record without establishing
current revocation status, actual operation correspondence, or
remaining consumable authority.
M-2.2.9 — Revocation-Propagation Gap
A valid revocation may have been committed upstream without yet being
applied by the actual resource sink.
M-2.2.10 — Notification-to-Enforcement Gap
An asynchronous notification may be delayed, dropped, reordered, or
delivered without causing the required protected invalidation.
M-2.2.11 — Cross-Mechanism State Inconsistency
Different mechanisms may evaluate permissions using different
resource identities, policy epochs, operation representations, or
authorization freshness conditions.
M-2.2.12 — Security-Primitive Substitution
A system may replace one authorization or enforcement implementation
with another that has weaker semantic coverage while retaining an
apparently valid high-level permission.
M-2.2.13 — Authority Replay
An earlier valid token, signed receipt, operation descriptor, or
capability reference may be reused for another effect.
M-2.2.14 — Current Operation Divergence
The actual outgoing operation may differ from the approved operation
after a service, model, resource, or transport transformation.
M-2.2.15 — Protection-Boundary Ambiguity
Das Expires 29 April 2027 [Page 346]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A deployment may be unable to establish whether a particular control
is mandatory, advisory, monitoring-only, or bypassable.
9.6.3.6. Source page 1903 of the original specification
M-2.2.16 — Technical Objective
A candidate objective technical problem is:
How to use heterogeneous established authorization, cryptographic,
process-isolation, communication, network, and hardware security
mechanisms to control autonomous consequential operations without
treating any one primitive's successful result as sufficient
executable authority, by translating each relevant security result
into protected operation-specific evidence and independently
enforcing current actual-effect correspondence, revocation, coverage,
and non-replayable finality consumption at the real resource
boundary.
M-2.3 — COMMON PROTECTED INTEGRATION ARCHITECTURE
A representative implementation may comprise:
1. An Autonomous Computational Requester.
2. A Protected Candidate Act Adapter.
3. A Heterogeneous Authorization Evidence Adapter.
4. A Protected Effect-Semantics Translation Controller.
5. A Collection-Time Evidence Instance.
6. An Independent Execution-Time Validation Instance.
7. A Current Authority and Revocation Dependency Controller.
8. An Enforcement-Coverage Qualification Controller.
9. A Protected Finality Enablement Controller.
10. A Privileged or Resource-Specific Effectuation Broker.
11. A Designated Finality Sink.
12. A Sink-Local Protected State and Consumption Controller.
13. An Optional External Effect Observer.
Das Expires 29 April 2027 [Page 347]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
14. An Optional Crash-Consistent Operation Journal.
A selected implementation may integrate several functions in one
protected component where the applicable claims do not require
structural separation.
Where independent validation, protected state separation, or external
sink authority is expressly required, the implementation must
preserve those properties.
The requesting computational entity does not automatically control
the protected finality authority or the actual resource-side
consumption state.
9.6.3.7. Source page 1904 of the original specification
M-2.4 — CENTRAL PROTECTED DATA STRUCTURES
M-2.4.1 — Authorization Source Evidence
AUTHORIZATION_SOURCE_EVIDENCE = { source_mechanism_class,
issuer_or_controller_identity, requester_identity,
credential_or_grant_reference, authorized_resource_scope,
authorized_operation_scope, protected_principal_reference,
proof_of_possession_reference, applicable_policy_version,
authorization_generation, current_revocation_reference,
evidence_freshness, authentication_result, evidence_assurance_profile
} The evidence describes the specific property established by the
underlying authorization mechanism.
A successful identity check is not encoded as proof that the actual
operation is valid.
M-2.4.2 — Protected Canonical Effect Descriptor
PROTECTED_CANONICAL_EFFECT_DESCRIPTOR = { candidate_act_identifier,
actual_operation_class, originating_authority,
actual_resource_identity, effective_target_or_recipient,
operation_method_or_primitive, operation_parameters_commitment,
outgoing_content_commitment, expected_resource_generation,
resolved_effectuation_interface, authorized_effect_envelope,
applicable_policy_commitment, protected_descriptor_authentication }
The descriptor includes the security-relevant fields needed to
distinguish authorized and unauthorized effects for the selected
operation class.
Fields that are not relevant to a particular effect may be omitted.
Das Expires 29 April 2027 [Page 348]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The descriptor must not depend solely on caller-supplied unverified
labels for an operation whose actual resource-side semantics differ.
M-2.4.3 — Enforcement Qualification Record
9.6.3.8. Source page 1905 of the original specification
ENFORCEMENT_QUALIFICATION_RECORD = { actual_effectuation_class,
actual_resource_or_interface, selected_enforcement_component,
enforcement_mode, mandatory_attachment_evidence,
blocking_capability_evidence, operation_visibility_profile,
actual_resource_binding, protected_configuration_generation,
current_coverage_epoch, unresolved_bypass_paths,
qualified_verification_result } The record distinguishes monitoring,
advisory, and blocking enforcement.
M-2.4.4 — Revocation-Dependent Finality Enablement
REVOCATION_DEPENDENT_FINALITY_ENABLEMENT = {
candidate_act_commitment, authorization_evidence_commitment,
collection_time_evidence_commitment,
independent_validation_commitment,
canonical_effect_descriptor_commitment, original_source_authority,
required_delegation_dependencies, current_revocation_generation,
required_freshness_state, current_enforcement_coverage_epoch,
designated_finality_sink, authorized_resource, permitted_use_count,
sink_local_consumption_reference, protected_finality_authentication }
The enablement may be maintained entirely within a protected
controller and represented to the requester by an inert reference.
M-2.4.5 — Sink-Local Finality State
SINK_LOCAL_FINALITY_STATE = { designated_sink_identity,
resource_identity, accepted_authority_generation,
accepted_revocation_generation, accepted_coverage_generation,
authorized_operation_commitment, finality_enablement_identifier,
consumption_generation, remaining_permitted_uses,
current_resource_state, active_enforcement_mode,
9.6.3.9. Source page 1906 of the original specification
pending_dispatch_state, protected_state_authentication } The
protected sink verifies the current state before consequential
release.
M-2.5 — PROTECTED AUTHORIZATION-TO-EFFECT TRANSLATION
Das Expires 29 April 2027 [Page 349]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
In one principal variation, the architecture includes a protected
translation mechanism converting authorization information from a
heterogeneous permission system into an effect-specific validation
requirement.
The translation is not limited to extracting an access-token scope.
It may reconcile:
The identity of the authorized principal;
The applicable source grant;
A permission's intended operation;
A structured application action;
The actual resource method;
The effective recipient;
The outgoing content;
The protected resource version;
The required proof-of-possession relation;
And the current resource-side enforcement boundary.
M-2.5.1 — Translation Input
The controller receives qualified permission evidence and a Candidate
Act descriptor.
M-2.5.2 — Independent Semantic Resolution
The controller determines the actual technical meaning of the
operation under its applicable contract.
M-2.5.3 — Protected Effect Envelope
The permissible operation scope is expressed as bounded effect
parameters.
M-2.5.4 — Source Authority Preservation
A narrow permission is not silently expanded into broader executable
authority.
Das Expires 29 April 2027 [Page 350]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-2.5.5 — Unresolved Semantics
9.6.3.10. Source page 1907 of the original specification
If the operation's relevant effects cannot be sufficiently
determined, the selected protected consequence remains withheld.
M-2.5.6 — Effect-Specific Finality
Different resource classes may employ different actual-operation
descriptors and sink checks.
M-2.5.7 — Technical Significance
The proposed relationship requires an established permission result
to remain subordinate to a protected actual-effect binding rather
than allowing an upstream token or tool label to become sufficient
effectuation authority.
M-2.6 — VARIATION A: OAUTH AND EQUIVALENT AUTHORIZATION-SERVER
INTEGRATION
An implementation may use an established authorization-server
architecture to identify principals, clients, resources, permissions,
and delegated access.
OAuth-style access tokens and grants may constitute one source of
authorization evidence.
The protected execution-finality controller does not assume that
token validity is sufficient to release every covered consequential
operation.
M-2.6.1 — Source Grant
The authorization server provides a resource-access grant under an
authenticated principal or delegation relationship.
M-2.6.2 — Candidate Act
The autonomous requester proposes a specific consequential API or
resource operation.
M-2.6.3 — Authority Translation
The protected adapter maps the authorized resource and scope into
required effect-specific predicates.
Das Expires 29 April 2027 [Page 351]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-2.6.4 — Independent Validation
A protected validator evaluates the current operation against the
actual permission envelope.
M-2.6.5 — Finality Enablement
A separate protected controller establishes scoped non-bearer
enablement for the specified operation.
M-2.6.6 — Sink Reconstruction
The resource sink resolves the actual pending request, target,
parameters, and authorized scope.
M-2.6.7 — Consequential Release
9.6.3.11. Source page 1908 of the original specification
The sink releases the operation only after current authority,
revocation, actual-effect, and protected consumption checks pass.
M-2.6.8 — Alternative Permission Systems
The same mechanism may use non-OAuth enterprise identity systems,
operating-system permissions, device-control grants, access-control
lists, capability registries, or authenticated custom authorization
services.
Technical contribution of this variation: Operation-specific actual-
effect finality remains independent of the particular authorization-
server protocol while maintaining a verifiable binding to the
original permission.
M-2.7 — VARIATION B: STRUCTURED OR RICH AUTHORIZATION DETAILS
An authorization system may provide detailed descriptions of
permitted actions, recipients, amounts, resources, or transaction
attributes.
The protected controller may treat these as candidate authorization
constraints.
It does not automatically assume the structured description
corresponds to the actual downstream operation.
M-2.7.1 — Structured Grant
Das Expires 29 April 2027 [Page 352]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A permission may identify a resource, operation type, amount,
recipient, method, or other attributes.
M-2.7.2 — Protected Normalization
The fields are converted into a typed canonical effect envelope.
M-2.7.3 — Current Resource Resolution
The actual resource and recipient are resolved at the relevant
effectuation boundary.
M-2.7.4 — Operation Correspondence
The protected sink compares the actual operation against the
authorized constraints.
M-2.7.5 — Downstream Transformation
Any material change in effect semantics may require revalidation.
M-2.7.6 — Failure State
A mismatch prevents the effect.
M-2.7.7 — Non-Limiting Standard
One optional implementation may use authorization-detail structures
compatible with Rich Authorization Requests.
9.6.3.12. Source page 1909 of the original specification
Technical contribution of this variation: A structured permission is
converted into an independently enforced actual-effect predicate
rather than being treated as self-enforcing authorization.
M-2.8 — VARIATION C: TOKEN REVOCATION AND AUTHORITY DEPENDENCY
INVALIDATION
An authorization system may invalidate a credential or grant.
The protected finality architecture may associate that grant with its
dependent Candidate Acts, protected evidence, reservations, and
finality enablements.
M-2.8.1 — Revocation Input
Das Expires 29 April 2027 [Page 353]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The protected controller obtains an authenticated revocation
commitment or current inactive-status evidence.
M-2.8.2 — Dependency Resolution
The system identifies operation-specific enablements dependent upon
the revoked grant.
M-2.8.3 — Protected Generation
The authoritative revocation generation advances.
M-2.8.4 — Pending Effect Invalidation
Affected finality enablements become ineligible.
M-2.8.5 — Sink-Local Fence
The actual resource controller applies or verifies current revoked
authority.
M-2.8.6 — Actual Operation Check
The sink determines whether the pending effect depends upon the
invalidated grant.
M-2.8.7 — Controlled Refusal
Revoked authority prevents new covered effects under the actual
sink's current enforcement state.
M-2.8.8 — Non-Limiting Standard
An optional authorization-server interface may use an OAuth token-
revocation protocol.
Technical contribution of this variation: Revocation becomes an
invalidation dependency of actual operation-specific finality, not
merely a change in token status.
M-2.9 — VARIATION D: TOKEN INTROSPECTION, CACHE FRESHNESS, AND SINK-
SIDE AUTHORITY
9.6.3.13. Source page 1910 of the original specification
An implementation may use a current authorization-status query.
The result may indicate whether a credential is active.
Das Expires 29 April 2027 [Page 354]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The protected controller additionally determines whether the response
is sufficiently current for the actual operation.
M-2.9.1 — Status Query
A protected resource or authority adapter requests current credential
status.
M-2.9.2 — Response Authentication
The result is authenticated under the appropriate issuer and resource
policy.
M-2.9.3 — Freshness Classification
The response is associated with a qualified age, generation, or
validity bound.
M-2.9.4 — Current Operation Risk
The required freshness may depend upon the relevant effect class.
M-2.9.5 — Generation Binding
The current source-authority and revocation generations are checked
where applicable.
M-2.9.6 — Cache Invalidation
A relevant authority change invalidates affected cached permission
evidence.
M-2.9.7 — Missing Freshness
The sink withholds the governed effect if mandatory current validity
cannot be established.
M-2.9.8 — Non-Limiting Standard
An optional implementation may use an OAuth token-introspection
response.
Technical contribution of this variation: The current authority
requirement is bound to the real consequential operation and its
protected sink, not merely to a cached general token status.
M-2.10 — VARIATION E: SENDER-CONSTRAINED TOKEN AND PROOF-OF-
POSSESSION INPUT
Das Expires 29 April 2027 [Page 355]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
An existing authorization system may bind a credential to a
cryptographic key and require the requester to demonstrate possession
of that key.
The proof may be useful to establish that the presenter is an
authorized holder under the credential protocol.
9.6.3.14. Source page 1911 of the original specification
Such proof is not automatically treated as evidence that every
consequential operation parameter is authorized.
M-2.10.1 — Bound Credential
The credential identifies an authorized key or cryptographic
principal.
M-2.10.2 — Possession Proof
The requester provides a qualified cryptographic proof.
M-2.10.3 — Proof Verification
The protected adapter verifies the binding and applicable request-
specific fields.
M-2.10.4 — Semantic Scope
The controller separately determines which actual operation
attributes are covered by the proof.
M-2.10.5 — Effect Descriptor
The full relevant consequential operation is represented by a
protected descriptor.
M-2.10.6 — Finality Authority
A separate operation-specific non-bearer finality enablement is
established.
M-2.10.7 — Sink Verification
The actual resource verifies the operation and current protected
consumption state.
M-2.10.8 — Non-Limiting Standard
Das Expires 29 April 2027 [Page 356]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
An optional implementation may use an application-layer
demonstration-of-proof-of-possession token mechanism.
Technical contribution of this variation: Key possession becomes one
authenticated input but does not independently constitute the
separate authority to perform the actual consequential operation.
M-2.11 — VARIATION F: MUTUAL AUTHENTICATION AND CERTIFICATE-BOUND
PERMISSION
A protected service may use mutual transport authentication and
certificate-bound access credentials.
M-2.11.1 — Authenticated Client
The requesting service proves possession of an applicable client
certificate key.
M-2.11.2 — Protected Channel
9.6.3.15. Source page 1912 of the original specification
The transport provides the selected authenticated communication
guarantees.
M-2.11.3 — Credential Binding
The resource verifies that the relevant token or grant is associated
with the authenticated client identity.
M-2.11.4 — Operation Scope
The protected controller separately validates the consequential
operation parameters.
M-2.11.5 — Current Revocation
The sink checks the current applicable authorization state.
M-2.11.6 — Non-Bearer Finality
The actual resource operation remains dependent upon its distinct
protected finality state.
M-2.11.7 — Substitution
Das Expires 29 April 2027 [Page 357]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Mutual authentication may be replaced by another technically suitable
authenticated channel without changing the operation-specific
finality relationship.
M-2.11.8 — Non-Limiting Standard
An optional implementation may use certificate-bound OAuth
credentials and mutual TLS.
Technical contribution of this variation: A correctly authenticated
service is still unable to exceed its current independently enforced
operation-specific authority.
M-2.12 — VARIATION G: HARDWARE-PROTECTED KEYS AND CRYPTOGRAPHIC
EVIDENCE
An implementation may use protected cryptographic hardware or a
suitably isolated key manager.
The hardware may protect private keys and authenticate selected
evidence or authority records.
M-2.12.1 — Protected Key Generation
The key may be generated in a protected security component.
M-2.12.2 — Non-Exportable Key
The requesting agent may lack access to the private key material.
M-2.12.3 — Evidence Authentication
The protected component may sign or authenticate selected collection,
validation, or generation commitments.
M-2.12.4 — Operation Binding
9.6.3.16. Source page 1913 of the original specification
The signed structure may identify the Candidate Act and applicable
authority context.
M-2.12.5 — Current State
A separate protected controller maintains relevant revocation and
consumption conditions.
M-2.12.6 — Actual Resource Enforcement
Das Expires 29 April 2027 [Page 358]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The Finality Sink verifies the real operation and current authority
rather than accepting the signature alone.
M-2.12.7 — Hardware Independence
A software-protected alternative may be used where it supplies the
selected trust properties.
M-2.12.8 — Scope Qualification
Protected key storage does not automatically establish a rollback-
resistant monotonic counter, resource-side execution gate, or
complete policy engine.
Technical contribution of this variation: Hardware-authenticated
evidence is separated from current actual-effect authority and
becomes part of an enforced multi-state finality decision.
M-2.13 — VARIATION H: APPLICATION SANDBOX AND ENTITLEMENT INPUT
An autonomous application may operate under operating-system sandbox
restrictions and assigned resource entitlements.
M-2.13.1 — Restricted Workload
The computational requester is confined to an identified protection
boundary.
M-2.13.2 — Entitlement Evidence
The protected controller obtains qualified information concerning
relevant permitted interfaces.
M-2.13.3 — Effectuation Path
The system determines how the actual consequential resource can be
reached.
M-2.13.4 — Privileged Intermediary
Any helper or service possessing broader effect authority is
identified as part of the relevant path.
M-2.13.5 — Mandatory Gate
The protected system establishes that the actual operation cannot
bypass the required finality controller within the declared coverage
domain.
Das Expires 29 April 2027 [Page 359]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-2.13.6 — Finality Validation
The operation remains subject to current source authorization and
actual-effect matching.
9.6.3.17. Source page 1914 of the original specification
M-2.13.7 — Configuration Change
A material entitlement or sandbox change may invalidate dependent
coverage authority.
M-2.13.8 — Non-Limiting Substrate
The sandbox may be implemented by operating-system access controls,
virtual machines, containers, process namespaces, or appropriate
hardware isolation.
Technical contribution of this variation: Process confinement and
operation-specific authority are coupled through a verified mandatory
consequential path rather than assuming that sandbox membership
proves authorization.
M-2.14 — VARIATION I: STRUCTURED APPLICATION ACTIONS AND AUTONOMOUS
TOOL INVOCATION
An application may expose structured actions to a voice assistant, AI
agent, automation service, or orchestration system.
M-2.14.1 — Proposed Action
The agent selects a structured tool or application action.
M-2.14.2 — Candidate Act Construction
The action is represented as a proposed consequence.
M-2.14.3 — Parameter Resolution
The controller determines the relevant resource, arguments,
recipient, and other effect-defining fields.
M-2.14.4 — Non-Effective Hold
The actual effect-capable primitive remains withheld.
M-2.14.5 — Current Validation
Das Expires 29 April 2027 [Page 360]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A protected verifier checks current source authority and applicable
operation scope.
M-2.14.6 — Action Implementation
The actual resource-side implementation may transform or resolve the
requested parameters.
M-2.14.7 — Sink Reconstruction
The protected sink obtains the effective operation and verifies
correspondence with the authorized Candidate Act.
M-2.14.8 — Dynamic Tool Change
Material changes to the action contract or its effectuation path
trigger revalidation.
9.6.3.18. Source page 1915 of the original specification
Technical contribution of this variation: A machine-readable action
declaration is prevented from becoming unrestricted execution
permission solely because the agent successfully invoked the
structured interface.
M-2.15 — VARIATION J: PRIVILEGED INTERPROCESS BROKER
A low-trust autonomous agent may communicate with a more privileged
local process through an authenticated interprocess channel.
The privileged service may be capable of accessing protected files,
resources, credentials, or devices that the agent cannot reach
directly.
M-2.15.1 — Separate Requester
The untrusted agent constructs a Candidate Act.
M-2.15.2 — Authenticated IPC
A protected channel conveys the candidate operation to a privileged
service.
M-2.15.3 — Principal Attribution
The service identifies the original requesting authority.
M-2.15.4 — Protected Operation Reconstruction
Das Expires 29 April 2027 [Page 361]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The service resolves the actual consequential primitive it would
perform.
M-2.15.5 — Current Validation
The service verifies required authority, revocation, and resource
predicates.
M-2.15.6 — Protected Consumption
The privileged service or downstream resource performs the applicable
sink-local finality transition.
M-2.15.7 — Credential Isolation
Reusable privileged credentials need not be exposed to the agent.
M-2.15.8 — Anti-Bypass
The requesting agent lacks another permitted uncontrolled route to
the governed effect under the declared coverage model.
Technical contribution of this variation: Privileged interprocess
communication becomes a mandatory, operation-specific effectuation
bridge rather than a general delegation of the helper's authority.
M-2.16 — VARIATION K: OPERATING-SYSTEM PRE-EFFECTUATION AUTHORIZATION
HOOK
9.6.3.19. Source page 1916 of the original specification
An operating system may provide mechanisms through which a protected
component can authorize or deny selected pending events.
M-2.16.1 — Relevant Event
The protected monitor identifies a supported event corresponding to a
consequential resource operation.
M-2.16.2 — Blocking Qualification
The controller determines whether the mechanism can actually prevent
the event.
M-2.16.3 — Operation Descriptor
The event is mapped to the actual resource and effect class.
Das Expires 29 April 2027 [Page 362]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-2.16.4 — Source Binding
The actual requesting process or principal is identified.
M-2.16.5 — Current Permission
The protected controller checks operation-specific authority and
revocation.
M-2.16.6 — Decision
The applicable authorization event is permitted or denied.
M-2.16.7 — Monitoring-Only Events
Observation events that cannot block are not misclassified as
mandatory pre-effectuation gates.
M-2.16.8 — Coverage Qualification
If an event type or relevant actual effect is not covered by the
operating-system mechanism, an alternate protected sink or resource
control must enforce the requirement.
Technical contribution of this variation: A qualified OS blocking
primitive may implement part of the finality boundary while current
operation-specific authority and enforcement coverage remain
separately verified.
M-2.17 — VARIATION L: NETWORK EXTENSION, PROXY, AND EGRESS
ENFORCEMENT
A protected system may control external network effects through
network filters, proxies, relays, controlled sockets, or resource
gateways.
M-2.17.1 — Effect Class
The protected controller identifies a relevant network transmission
or remote API operation.
M-2.17.2 — Network Interface
9.6.3.20. Source page 1917 of the original specification
The current egress route is identified.
M-2.17.3 — Destination Resolution
Das Expires 29 April 2027 [Page 363]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The effective network endpoint is determined according to the
relevant policy.
M-2.17.4 — Application Semantics
Where authorization depends upon message body, recipient, method,
path, or application operation, those properties are verified at a
suitable trusted semantic boundary.
M-2.17.5 — Encrypted Content
A content-blind flow filter is not presumed to know the relevant
protected plaintext.
M-2.17.6 — Protected Content Commitment
A trusted pre-encryption controller may establish a commitment
binding approved plaintext, intended recipient, and outgoing
transmission.
M-2.17.7 — Actual Egress Gate
The required effectuation path enforces current protected authority.
M-2.17.8 — Dynamic Routes
Changes to proxy, network namespace, route, or device state may
require coverage revalidation.
Technical contribution of this variation: Network-level and
application-level enforcement are linked through an operation-
specific protected effect descriptor and cannot independently be
substituted for one another where their visibility differs.
M-2.18 — VARIATION M: NOTIFICATION-ASSISTED REVOCATION
An implementation may use asynchronous notifications to signal that
protected permission state has changed.
A notification need not carry complete authoritative revocation
state.
M-2.18.1 — Revocation Commitment
The source authority commits the withdrawal of permission.
M-2.18.2 — Notification
Das Expires 29 April 2027 [Page 364]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A messaging service signals a relevant state change.
M-2.18.3 — Protected Refresh
A receiving enforcement controller obtains the current authoritative
state.
M-2.18.4 — Generation Verification
9.6.3.21. Source page 1918 of the original specification
The receiving sink establishes current revocation generation.
M-2.18.5 — Missing Notification
The sink's current authority requirement does not depend solely upon
guaranteed delivery of the notification.
M-2.18.6 — Deferred Delivery
Delayed notification does not constitute new authorization.
M-2.18.7 — Sink-Local Fence
The actual effectuation resource must enforce the applied
invalidation.
M-2.18.8 — Alternative Transport
The notification mechanism may be push messaging, event streaming,
polling, periodic state synchronization, or an authenticated
distribution channel.
Technical contribution of this variation: Asynchronous notification
is used as a latency optimization, while current effect authorization
remains dependent upon protected authoritative state or expressly
bounded offline validity.
M-2.19 — VARIATION N: TRANSACTIONAL AUTHORITY AND CONSUMPTION STORE
An implementation may use a transactional database or suitably
protected persistent state mechanism to maintain:
Candidate Acts;
Current source-authority generations;
Evidence commitments;
Das Expires 29 April 2027 [Page 365]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Protected reservations;
Pending finality enablements;
Current revocation generations;
Actual-operation commitments;
And consumption state.
M-2.19.1 — Protected Preparation
The controller prepares one bounded finality transition.
M-2.19.2 — Current Validation
The operation's mandatory predicates are checked.
9.6.3.22. Source page 1919 of the original specification
M-2.19.3 — Atomic State Transition
A protected transaction consumes the applicable authority.
M-2.19.4 — Replay
A subsequent attempt observes the consumed state.
M-2.19.5 — Crash Recovery
The authoritative store determines whether the transition committed.
M-2.19.6 — External Effects
Where the resource effect lies outside the transaction domain, the
system separately governs dispatch and outcome uncertainty.
M-2.19.7 — Hardware Alternative
Suitable protected hardware state may replace the transactional
database where it supplies the required property.
M-2.19.8 — Technical Effect
The security of an operation-specific permission is not reduced to
the secrecy of an authorization token; a protected state transition
is required at the actual effectuation boundary.
Das Expires 29 April 2027 [Page 366]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-2.20 — VARIATION O: RECEIVER-SIDE API AND REMOTE SERVICE FINALITY
A remote resource service may implement the Finality Sink.
The upstream autonomous agent may possess a valid authorization
token, key-bound proof, and structured request permission.
Nevertheless, the receiving service independently verifies:
The actual operation parameters;
The effective resource identity;
The relevant permission scope;
Current revocation state;
Operation-specific enablement;
Resource version;
And protected consumption state.
M-2.20.1 — Actual Request
The receiving service reconstructs the operation it is about to
perform.
9.6.3.23. Source page 1920 of the original specification
M-2.20.2 — No Unrestricted Token Authority
A general API-access credential is insufficient for the selected
protected consequence.
M-2.20.3 — Finality Commit
The receiving service enforces the protected resource mutation or
external release.
M-2.20.4 — Idempotency
A receiver-side operation registry may prevent duplicate effects
under suitable transactional guarantees.
M-2.20.5 — Cross-Domain Evidence
Das Expires 29 April 2027 [Page 367]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Protected validation records may be authenticated across
administrative domains.
M-2.20.6 — Current Enforcement
The remote service must actually implement the required resource-side
gate to claim destination finality.
M-2.21 — VARIATION P: HARDWARE COMMAND AND DEVICE-SIDE FINALITY
A protected device controller may receive operation-specific
authority originating from a software agent, remote service, or
authorized application.
M-2.21.1 — Candidate Command
An agent prepares a bounded device operation.
M-2.21.2 — Source Authority
The protected controller establishes the original permitted command
scope.
M-2.21.3 — Device Identity
The actual device and current ownership are verified.
M-2.21.4 — Command Descriptor
The relevant actual parameters and effect class are identified.
M-2.21.5 — Protected Generation
Current hardware resource or revocation generations are checked.
M-2.21.6 — Hardware Gate
The device command interface refuses unauthorized effects.
M-2.21.7 — Consumption
9.6.3.24. Source page 1921 of the original specification
A protected operation-specific generation or usage state is consumed.
M-2.21.8 — Actual Outcome
Das Expires 29 April 2027 [Page 368]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Physical completion remains distinguished from command acceptance or
dispatch.
Technical contribution of this variation: A software authorization
mechanism does not become a complete hardware execution authorization
until verified and enforced by the actual effect-capable device
boundary.
M-2.22 — VARIATION Q: MIXED HARDWARE AND SOFTWARE ENFORCEMENT
A protected implementation may combine a software policy controller
with a hardware resource gate.
The software component may perform complex policy or semantic
validation.
The hardware component may enforce a smaller mandatory release
condition.
The protected relationship may require:
An authenticated operation digest;
A current protected authority generation;
A hardware-recognized resource identifier;
A bounded command enablement;
And protected consumption.
The implementation may separate computation-intensive evidence
evaluation from a relatively compact protected effectuation check.
A hardware gate need not parse every high-level application policy if
its accepted release condition is securely bound to the validated
actual operation.
The system must establish that the hardware gate cannot be tricked
into applying an enablement to an unrelated command.
M-2.23 — VARIATION R: MULTI-PROTOCOL AUTHORIZATION COMPOSITION
A particular consequential operation may require evidence from
several independently functioning security mechanisms.
For example:
Das Expires 29 April 2027 [Page 369]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A principal authorization system may establish the user's delegated
permission.
A proof-of-possession mechanism may establish requester key
possession.
A protected sandbox may restrict ordinary application interfaces.
9.6.3.25. Source page 1922 of the original specification
A current revocation service may establish source-authority status.
A network filter may restrict the egress route.
A protected resource sink may verify the actual effect.
The system may combine the corresponding evidence according to an
explicit operation-specific policy.
M-2.23.1 — Conjunctive Requirements
Several distinct properties may all be mandatory.
M-2.23.2 — Alternative Mechanisms
Two technologies may supply equivalent evidence for one specified
security predicate.
M-2.23.3 — Non-Equivalent Evidence
A proof of identity cannot substitute for current authorization.
M-2.23.4 — Mandatory Effect Control
A monitoring-only component cannot replace a required blocking gate.
M-2.23.5 — Evidence Qualification
Each source's actual technical guarantee is represented.
M-2.23.6 — Finality Relationship
The sink determines whether all required predicates are satisfied for
the actual operation.
M-2.24 — VARIATION S: REPLACEMENT OF SECURITY SUBSTRATES WITHOUT
REAUTHORISATION EXPANSION
Das Expires 29 April 2027 [Page 370]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
One authorized implementation may be replaced by another.
The protected controller may identify:
The original authorization mechanism;
Its supported evidence properties;
Its resource binding;
Its current configuration generation;
Its blocking capability;
And the corresponding replacement properties.
9.6.3.26. Source page 1923 of the original specification
If a new component provides an equivalent qualified property, the
system may revalidate affected operations under current authority.
If the new component lacks a required property, existing dependent
finality enablements become ineligible.
The system does not presume security equivalence merely because both
components are described as authentication, sandbox, proxy, or policy
services.
M-2.24.1 — Equivalent Substitute
A functionally compatible mechanism may replace a nonessential
substrate.
M-2.24.2 — Weaker Substitute
A monitoring-only substitute cannot silently replace mandatory
blocking enforcement.
M-2.24.3 — Changed Authorization Semantics
A different permission format requires new semantic correspondence
validation.
M-2.24.4 — Current Generation
The substitution advances or revalidates applicable protected
configuration state.
Das Expires 29 April 2027 [Page 371]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-2.24.5 — Actual Sink
Finality remains dependent upon current effectuation coverage and
operation-specific authority.
Technical contribution of this variation: Security-substrate
replacement is treated as an authority-affecting technical transition
rather than a transparent implementation detail.
M-2.25 — VARIATION T: BOUNDED OFFLINE AUTHORIZATION
A protected resource sink may be unable to contact the originating
authorization server.
Under a strict-online mode, the corresponding operation remains
withheld.
Under a selected bounded-offline mode, the sink may exercise
previously allocated authority only within its protected limits.
Such limits may include:
A maximum number of effects;
A protected validity duration;
A specific resource or operation class;
A protected generation;
A non-replenishable local finality allowance;
9.6.3.27. Source page 1924 of the original specification
And a requirement for revalidation before further authority is
issued.
A remote notification service is not treated as guaranteed immediate
delivery.
The system must not claim immediate global revocation if a
disconnected sink is independently allowed to continue using stale
authority.
M-2.26 — VARIATION U: DATA-RELEASE AND ENCRYPTION BOUNDARY
An autonomous application may prepare sensitive content for external
release.
Das Expires 29 April 2027 [Page 372]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The protected disclosure policy may require inspection of the actual
information.
If encryption occurs before a content-blind network controller, that
controller may be unable to verify the necessary plaintext property.
The system may therefore establish:
A protected pre-encryption evidence commitment;
An authorized recipient and release-purpose binding;
Current disclosure authority;
A protected encryption-operation reference;
A ciphertext transmission commitment where appropriate;
And independent enforcement at the actual release boundary.
The network filter may control the destination or connection.
The content-aware protected component may establish the data-release
predicate.
Neither is incorrectly represented as providing the other's security
guarantee without actual technical support.
M-2.27 — VARIATION V: MULTI-AGENT DELEGATION AND REVOCATION
A task may be delegated through several autonomous agents.
The original authorization may originate from a user, enterprise
policy, or protected resource controller.
The system may preserve:
Original source-authority identity;
Delegated operation scope;
Applicable resource and recipient constraints;
Relevant proof-of-possession or process-identity evidence;
Das Expires 29 April 2027 [Page 373]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.6.3.28. Source page 1925 of the original specification
Current revocation dependencies;
And finality consumption state.
A downstream agent's separate authentication does not automatically
supersede the original source-authority restrictions.
Revocation of a mandatory ancestor grant invalidates dependent
operation-specific enablement under the selected protected dependency
model.
M-2.28 — VARIATION W: ACTIONS WITH MULTIPLE CONSEQUENCES
A structured application action may appear to be one logical
operation while producing several effects.
Examples may include:
Updating a database;
Sending a notification;
Activating a payment instruction;
Changing a file;
And transmitting a remote message.
The system may identify each distinct consequential release boundary.
A principal implementation may create separate bounded Candidate Acts
or effect-specific child operations.
Each covered effect may require a distinct protected finality
predicate.
One high-level successful application-action result does not
automatically establish that all resulting consequences were
authorized or completed.
Where a successor effect requires an earlier verified real
consequence, the applicable accepted actual-effect receipt remains a
constitutive dependency.
M-2.29 — VARIATION X: UNIVERSAL PRIMITIVE-SUBSTITUTION INTERFACE
Das Expires 29 April 2027 [Page 374]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A protected implementation may expose a typed interface through which
different authorization, cryptographic, operating-system, network,
and hardware components provide qualified evidence.
A representative interface may comprise:
SECURITY_PRIMITIVE_ADAPTER = { primitive_class, evidence_type,
authorized_source_identity, supported_security_property,
9.6.3.29. Source page 1926 of the original specification
applicable_operation_fields, current_resource_scope,
enforcement_visibility, blocking_capability, freshness_rule,
revocation_dependency, protected_configuration_generation,
evidence_authentication, qualification_result } The interface must
distinguish:
Proof of principal identity;
Proof of key possession;
Proof of current resource permission;
Proof of an attached blocking mechanism;
Proof of actual operation semantics;
Proof of revocation status;
And proof of finality consumption.
A system must not collapse these properties into one generic Boolean
called authorized.
Where a selected actual effect requires several properties, the
Finality Sink verifies the corresponding distinct predicates.
M-2.30 — PROTECTED TECHNICAL INVARIANTS
The principal implementation may enforce the following technical
invariants.
Invariant A — Computation/Authority Separation
Generation of an operation by an autonomous model does not
independently authorize its consequence.
Invariant B — Evidence/Authority Separation
Das Expires 29 April 2027 [Page 375]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Authenticated permission evidence does not independently become
reusable complete finality authority.
Invariant C — Proof/Effect Separation
Successful identity or key-possession proof does not automatically
validate the full actual effect.
Invariant D — Semantic Correspondence
The actual resource operation must satisfy the protected authorized-
effect descriptor.
9.6.3.30. Source page 1927 of the original specification
Invariant E — Current Authority
A previously valid authorization cannot override a mandatory current
revocation or resource-state condition.
Invariant F — Enforcement Qualification
A required blocking predicate cannot be satisfied solely through
observation-only security instrumentation.
Invariant G — Non-Bearer Enablement
Possession of an opaque or signed authority artifact is insufficient
without the required protected sink state.
Invariant H — Monotonic Consumption
An operation-specific use cannot be duplicated by copying or
restoring earlier requester state.
Invariant I — Topology Continuity
A material enforcement-path change invalidates or revalidates
affected finality dependencies.
Invariant J — Outcome Integrity
The system distinguishes authority consumption, dispatch, resource
commit, and external actual-effect completion.
These invariants may be implemented through distinct mechanisms
according to the selected operation class.
Das Expires 29 April 2027 [Page 376]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-2.31 — PRINCIPAL FULLY INTEGRATED WORKFLOW
A representative integrated implementation performs the following
sequence.
Step 1 — Receive Operation Proposal. An autonomous entity proposes a
consequential action.
Step 2 — Construct Candidate Act. The operation is identified as a
protected proposed consequence.
Step 3 — Hold Non-Effective. The actual resource effect is withheld.
Step 4 — Resolve Authorization Sources. The system identifies
applicable grants, credentials, permissions, and delegated authority.
Step 5 — Collect Qualified Evidence. A protected collector obtains
the relevant authenticated evidence.
Step 6 — Translate Effect Scope. The authorization evidence is
mapped into a protected actual-effect envelope.
Step 7 — Verify Key and Requester Relations. Applicable
cryptographic holder or client-authentication properties are
evaluated.
9.6.3.31. Source page 1928 of the original specification
Step 8 — Resolve Current Revocation Dependencies. The protected
authority controller identifies the relevant source and delegated
grants.
Step 9 — Verify Current Revocation State. A qualified current
generation or status is established.
Step 10 — Qualify Enforcement Coverage. The system determines
whether the actual consequence is subject to mandatory blocking
enforcement.
Step 11 — Resolve Current Resource State. The resource, identity,
version, ownership, and policy generation are established.
Step 12 — Independently Validate. A protected execution-time
instance verifies the necessary current conditions.
Step 13 — Cross-Commit Evidence. The accepted collection and
validation records are bound to the same Candidate Act.
Das Expires 29 April 2027 [Page 377]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Step 14 — Prepare Non-Bearer Enablement. A protected controller
establishes scoped effectuation authority.
Step 15 — Bind the Designated Sink. The corresponding actual
effectuation boundary is identified.
Step 16 — Monitor Material Changes. Revocation, tool, policy,
topology, and resource changes invalidate affected enablement.
Step 17 — Present Actual Operation. The requester submits the
consequential operation.
Step 18 — Reconstruct Actual Effect. The Finality Sink obtains the
actual current operation descriptor.
Step 19 — Compare Authority and Effect. The sink verifies
correspondence with the authorized effect envelope.
Step 20 — Verify Current Revocation. The sink checks the applicable
protected authority generation and freshness.
Step 21 — Verify Enforcement Coverage. The required mandatory
effectuation path remains qualified.
Step 22 — Verify Current Enablement. The protected non-bearer
authority remains valid for that sink and resource.
Step 23 — Verify Monotonic State. The sink determines whether
permitted use remains.
Step 24 — Consume Authority. The applicable protected state
transition is committed.
Step 25 — Release the Consequence. The sink permits only the
verified actual operation.
Step 26 — Preserve Attempt State. A protected journal records the
effect attempt where applicable.
Step 27 — Reconcile Actual Outcome. Confirmed, rejected, partial,
and uncertain effects are distinguished.
9.6.3.32. Source page 1929 of the original specification
Step 28 — Require New Authority for Material Change. A different
effect requires new or suitably revalidated authorization.
M-2.32 — REFERENCE PSEUDOCODE: SECURITY-PRIMITIVE QUALIFICATION
Das Expires 29 April 2027 [Page 378]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
FUNCTION QUALIFY_SECURITY_PRIMITIVE( primitive_input, candidate_act,
protected_qualifier ):
REQUIRE VERIFY_PRIMITIVE_SOURCE( primitive_input )
REQUIRE VERIFY_PRIMITIVE_EVIDENCE( primitive_input )
property = protected_qualifier .DETERMINE_ACTUAL_SECURITY_PROPERTY(
primitive_input )
scope = protected_qualifier .RESOLVE_SUPPORTED_OPERATION_SCOPE(
primitive_input )
coverage = protected_qualifier .RESOLVE_ENFORCEMENT_CAPABILITY(
primitive_input )
IF property == UNKNOWN: RETURN UNQUALIFIED
RETURN protected_qualifier .AUTHENTICATE_QUALIFICATION({ property:
property,
operation_scope: scope,
enforcement_coverage: coverage,
candidate: HASH(candidate_act),
9.6.3.33. Source page 1930 of the original specification
configuration_generation: CURRENT_CONFIGURATION_GENERATION() }) The
function does not assume that a valid primitive supplies all security
properties required by the Candidate Act.
M-2.33 — REFERENCE PSEUDOCODE: AUTHORIZATION-TO-EFFECT TRANSLATION
FUNCTION CONSTITUTE_EFFECT_ENVELOPE( candidate_act,
qualified_authorization_evidence, protected_translation_controller ):
proposed = RESOLVE_CANDIDATE_OPERATION( candidate_act )
granted = protected_translation_controller
.EXTRACT_VERIFIED_PERMISSION_SCOPE( qualified_authorization_evidence
)
actual_contract = protected_translation_controller
.RESOLVE_EFFECT_CONTRACT( proposed )
IF NOT SUFFICIENT_EFFECT_SEMANTICS( actual_contract ): RETURN HOLD
Das Expires 29 April 2027 [Page 379]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
envelope = INTERSECT_AUTHORIZED_EFFECT_CONSTRAINTS( proposed,
granted, actual_contract )
IF envelope IS EMPTY: RETURN DENY
RETURN protected_translation_controller
.AUTHENTICATE_EFFECT_ENVELOPE({ candidate: HASH(candidate_act),
source_authority: HASH(qualified_authorization_evidence),
9.6.3.34. Source page 1931 of the original specification
authorized_effect: HASH_CANONICAL(envelope),
current_contract: HASH(actual_contract),
current_policy: CURRENT_POLICY_EPOCH() }) The intersection
establishes a bounded effect envelope; it must not expand the
original permission.
M-2.34 — REFERENCE PSEUDOCODE: REVOCATION-BOUND FINALITY CONSTITUTION
FUNCTION PREPARE_INTEROPERABLE_FINALITY( candidate_act,
collection_evidence, validation_evidence, effect_envelope,
protected_finality_controller ):
REQUIRE VERIFY_COLLECTION_EVIDENCE( collection_evidence )
REQUIRE VERIFY_INDEPENDENT_VALIDATION( validation_evidence )
REQUIRE VERIFY_COMMON_CANDIDATE_BINDING( candidate_act,
collection_evidence, validation_evidence )
REQUIRE VERIFY_AUTHORIZED_EFFECT_ENVELOPE( effect_envelope )
REQUIRE VERIFY_CURRENT_SOURCE_AUTHORITY()
REQUIRE VERIFY_CURRENT_REVOCATION_DEPENDENCIES()
REQUIRE VERIFY_CURRENT_MANDATORY_EFFECT_COVERAGE()
enablement = protected_finality_controller
.ATOMIC_PREPARE_OPERATION_AUTHORITY({ candidate: HASH(candidate_act),
9.6.3.35. Source page 1932 of the original specification
evidence: HASH(collection_evidence, validation_evidence),
Das Expires 29 April 2027 [Page 380]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
effect_envelope: HASH(effect_envelope),
revocation_generation: CURRENT_REVOCATION_GENERATION(),
coverage_generation: CURRENT_ENFORCEMENT_GENERATION(),
designated_sink: CURRENT_FINALITY_SINK(),
permitted_use_count: AUTHORIZED_USE_LIMIT() })
RETURN INERT_REFERENCE(enablement) The requesting agent does not
automatically receive a reusable complete resource authority.
M-2.35 — REFERENCE PSEUDOCODE: ACTUAL SINK VERIFICATION
FUNCTION EFFECTUATE_USING_EXISTING_SECURITY_SUBSTRATES(
candidate_act, enablement_reference, protected_finality_sink ):
actual_operation = protected_finality_sink
.RECONSTRUCT_ACTUAL_PENDING_OPERATION()
actual_resource = protected_finality_sink .RESOLVE_ACTUAL_RESOURCE()
REQUIRE actual_operation IS VALID
REQUIRE VERIFY_ACTUAL_OPERATION_CORRESPONDENCE( actual_operation,
candidate_act )
REQUIRE VERIFY_CURRENT_SOURCE_AUTHORITY( actual_operation )
REQUIRE VERIFY_CURRENT_REVOCATION_STATE(
9.6.3.36. Source page 1933 of the original specification
actual_operation )
REQUIRE VERIFY_CURRENT_OPERATION_PARAMETERS( actual_operation )
REQUIRE VERIFY_CURRENT_MANDATORY_ENFORCEMENT_COVERAGE(
actual_operation )
REQUIRE VERIFY_VALID_NON_BEARER_ENABLEMENT( enablement_reference,
actual_operation, actual_resource )
REQUIRE VERIFY_CURRENT_RESOURCE_STATE()
REQUIRE VERIFY_SINK_LOCAL_CONSUMPTION_STATE()
Das Expires 29 April 2027 [Page 381]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
consumption = protected_finality_sink .ATOMIC_CONSUME_ENABLEMENT(
enablement_reference, actual_operation )
IF consumption != COMMITTED: RETURN DENY
RETURN protected_finality_sink .EFFECTUATE_ACTUAL_OPERATION(
actual_operation ) The actual resource must be controlled by the
selected Finality Sink or a technically sufficient downstream
enforcement interface.
M-2.36 — REFERENCE PSEUDOCODE: REVOCATION PROPAGATION AND LOCAL FENCE
FUNCTION APPLY_AUTHORITY_REVOCATION( revocation_commitment,
protected_sink_controller ):
REQUIRE VERIFY_AUTHENTIC_REVOCATION( revocation_commitment )
REQUIRE VERIFY_REVOKER_SCOPE()
9.6.3.37. Source page 1934 of the original specification
current = protected_sink_controller .LOAD_CURRENT_AUTHORITY_STATE()
REQUIRE VERIFY_GENERATION_CONTINUITY( current, revocation_commitment
)
affected = RESOLVE_DEPENDENT_FINALITY_ENABLEMENTS(
revocation_commitment )
applied = protected_sink_controller
.ATOMIC_ADVANCE_REVOCATION_AND_FENCE({ affected_authority: affected,
new_generation: revocation_commitment.generation,
current_state: current })
IF applied != COMMITTED: RETURN ENFORCEMENT_NOT_CONFIRMED
RETURN PROTECTED_SINK_ENFORCEMENT_RECEIPT( applied ) A message-
delivery acknowledgement alone does not replace the protected sink-
application result.
M-2.37 — CONCRETE PHOSITA EXAMPLE: AUTONOMOUS API ACTION
A user permits an autonomous application to perform one bounded
cloud-service operation.
An existing authorization server issues resource permission.
Das Expires 29 April 2027 [Page 382]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A sender-constrained credential proves the requesting application's
possession of a corresponding key.
A structured action interface identifies the intended operation.
A protected adapter obtains the original permission and constructs a
Candidate Act.
The first protected instance commits the relevant collection-time
evidence.
A second independently protected instance validates current
authority, effect semantics, resource scope, and revocation state.
The resulting evidence is cross-committed to the operation.
9.6.3.38. Source page 1935 of the original specification
A protected controller prepares non-bearer finality enablement.
At the actual remote service, the Finality Sink reconstructs the
pending operation.
If the requested amount, target, resource, or operation method
differs materially from the authorized effect, the sink refuses the
consequence.
If the source grant has been revoked, the sink refuses the
consequence.
If the permission remains valid but the finality enablement was
already consumed, the sink refuses the duplicate effect.
The system does not depend upon the particular token format for these
finality conditions.
Expected demonstrable result: Valid identity, valid token, and valid
proof-of-possession may coexist with a correctly denied unauthorized
actual operation.
M-2.38 — CONCRETE PHOSITA EXAMPLE: AUTONOMOUS DESKTOP TOOL
A desktop autonomous assistant invokes a structured application
action.
The assistant operates under restricted process privileges.
The requested effect requires a privileged local service.
Das Expires 29 April 2027 [Page 383]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The assistant provides a Candidate Act to the protected service
through an authenticated interprocess interface.
The privileged service determines the actual file, resource, or
device operation.
The service verifies current source authority and protected
validation evidence.
An operating-system authorization mechanism or protected resource
controller enforces the applicable blocking condition.
A logging-only event monitor may supply evidence but cannot replace
the required blocking gate.
The privileged service consumes operation-specific non-bearer
authority before the actual effect.
Expected demonstrable result: A compromised assistant cannot
automatically exercise every effect available to the privileged
helper merely by possessing a valid IPC channel or structured tool
identifier.
M-2.39 — CONCRETE PHOSITA EXAMPLE: REVOCATION NOTIFICATION DELAY
An authorization server revokes an agent's protected grant.
A notification service signals the change to the local application.
The notification may be delayed.
9.6.3.39. Source page 1936 of the original specification
The actual resource sink does not treat the absence of a notification
as proof that the grant remains valid indefinitely.
It applies the selected current-state or bounded-freshness rule.
A previously valid operation presented after the required revocation
state becomes applicable is refused.
Expected demonstrable result: Correctness of current finality
authorization does not depend solely upon successful asynchronous
push delivery.
M-2.40 — CONCRETE PHOSITA EXAMPLE: ENCRYPTED NETWORK EGRESS
Das Expires 29 April 2027 [Page 384]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
An autonomous assistant prepares protected information for
transmission.
A network filter sees the destination and encrypted transport flow.
A protected application-level release controller examines the actual
plaintext before encryption.
A cross-commitment binds the authorized plaintext information,
recipient, and outgoing operation.
The actual release sink verifies current authority and consumes the
specified finality enablement.
The network controller enforces the covered transmission route.
The architecture does not pretend that the network filter can infer
unobserved plaintext semantics.
Expected demonstrable result: Content-dependent authorization remains
enforceable through an appropriate protected plaintext boundary even
where the network-flow control itself lacks plaintext visibility.
M-2.41 — CONCRETE PHOSITA EXAMPLE: SUBSTRATE REPLACEMENT
A protected system originally uses an application gateway that blocks
selected resource effects.
The gateway is replaced by a component that produces only event
notifications.
The new component is correctly authenticated.
It may provide valid monitoring information.
However, it lacks mandatory blocking capability for the relevant
effect.
The protected enforcement qualification changes.
Previously prepared finality enablements depending upon the old
blocking mechanism become ineligible.
A new qualified gate must be established before affected consequences
resume.
Das Expires 29 April 2027 [Page 385]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Expected demonstrable result: A valid security-service replacement
does not silently preserve execution authority when the replacement
supplies a weaker required enforcement property.
9.6.3.40. Source page 1937 of the original specification
M-2.42 — NON-LIMITING ADVERSARIAL TEST PROTOCOL
The following tests are proposed rather than reported completed
results.
Test 1 — Active Token, Unauthorized Effect: Present an active
credential for an actual operation beyond the original permitted
scope.
Test 2 — Valid Key Proof, Changed Operation: Prove possession of the
correct bound key but change the protected resource or effect
parameters.
Test 3 — Detailed Authorization, Different Recipient: Present a valid
structured permission while redirecting the actual operation to
another recipient.
Test 4 — Revoked Token, Historical Approval: Attempt a pending effect
using an authentic earlier approval after revocation.
Test 5 — Stale Introspection Response: Reuse an earlier active-status
response outside its qualified freshness state.
Test 6 — Notification Dropped: Suppress delivery of the asynchronous
revocation notification and verify the actual sink's defined
freshness or bounded-offline rule.
Test 7 — Notification Delivered, Fence Missing: Verify that receipt
of a notification is not incorrectly classified as completed sink
enforcement.
Test 8 — Signed Evidence Without Authority: Present a valid
cryptographic evidence record without a current non-bearer finality
enablement.
Test 9 — Copied Enablement Reference: Attempt a duplicate effect with
the same opaque reference.
Test 10 — Sandboxed Agent, Privileged Helper: Verify that the helper
independently checks the actual operation rather than relying on the
agent's sandbox membership.
Das Expires 29 April 2027 [Page 386]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Test 11 — Monitoring-Only Security Hook: Demonstrate that an audit
event cannot satisfy a mandatory blocking predicate.
Test 12 — Blocking Security Hook: Verify actual refusal of an
unauthorized supported operating-system operation.
Test 13 — Alternate Resource Path: Attempt the effect through another
API, socket, storage interface, or privileged worker.
Test 14 — Encrypted Egress: Demonstrate whether the protected
architecture verifies required plaintext semantics at a suitable
boundary.
Test 15 — Tool Contract Change: Replace a structured action
implementation with one producing additional side effects.
Test 16 — Resource Alias: Redirect a permitted logical resource name
to another actual object.
Test 17 — Different Authentication Primitive: Replace proof-of-
possession with mutual authentication while preserving the
independently enforced finality properties.
9.6.3.41. Source page 1938 of the original specification
Test 18 — Hardware Key Versus Software Key: Compare supported key-
protection properties without attributing unrelated resource-
enforcement guarantees.
Test 19 — Privileged Service Replacement: Change the broker
implementation and verify current enforcement qualification.
Test 20 — Network Path Mutation: Introduce an alternative connection
route and require coverage reassessment.
Test 21 — Local Atomic Consumption: Ensure that only the authorized
number of protected finality transitions commit.
Test 22 — Crash After Consumption: Restore a requester snapshot and
verify the consumed authority remains unusable.
Test 23 — Cross-Domain Revocation: Propagate a protected authority
change to a remote sink and verify actual fence application.
Test 24 — Missing Remote Receipt: Distinguish propagation attempted
from enforcement confirmed.
Das Expires 29 April 2027 [Page 387]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Test 25 — Bounded Offline Authority: Enforce the selected local
effect count or lease bound during disconnection.
Test 26 — Device Ownership Change: Reject a command under a stale
hardware authority generation.
Test 27 — Current Resource Version: Change the protected resource
after upstream validation.
Test 28 — Multi-Agent Delegation: Revoke a parent grant and identify
dependent downstream finality enablements.
Test 29 — Partial Multi-Effect Action: Verify separate finality
treatment of distinct real consequences produced by one structured
action.
Test 30 — Alternate Authorization Server: Replace one permission
system with a functionally compatible source while retaining current
actual-effect enforcement.
Test 31 — Token Mechanism Removed: Use an authenticated non-token
permission source and verify that the finality architecture remains
implementable.
Test 32 — Notification Mechanism Removed: Use online current-state
verification without asynchronous push notifications.
Test 33 — Hardware Key Mechanism Removed: Use a suitable software-
protected authentication mechanism within a stated weaker trust
model.
Test 34 — Effectuation Gate Removed: Demonstrate that losing the
mandatory blocking boundary defeats the claimed effect prevention,
establishing the technical necessity of the gate.
Test 35 — Sink Reconstruction Removed: Demonstrate that a previously
valid approval can be misapplied to a changed actual operation when
current correspondence is not checked.
9.6.3.42. Source page 1939 of the original specification
Test 36 — Revocation Generation Removed: Demonstrate that old
authority may remain apparently usable after protected revocation
when current generation binding is absent.
Test 37 — Monotonic Consumption Removed: Demonstrate how repeated
requests may exercise the same logical authority where no
authoritative consumption condition exists.
Das Expires 29 April 2027 [Page 388]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Test 38 — Full Combination: Demonstrate the complete operation-
specific protected authority chain across several compatible existing
security substrates.
Each test should use a controlled resource and observable effect
boundary.
The reported outcome should distinguish actual completed tests from
expected demonstrable behavior.
M-2.43 — TECHNICAL CAUSALITY AND CONTRIBUTION OF THE COMBINATION
The technical character of a combination should not rest solely upon
the fact that multiple known security mechanisms are present.
The disclosed principal architecture creates an enforceable
dependency among components that would otherwise provide separate and
potentially insufficient guarantees.
M-2.43.1 — First Technical Dependency
The output of an authorization system is converted into a bounded
actual-effect envelope rather than being accepted as complete
finality authority.
M-2.43.2 — Second Technical Dependency
A proof of client identity or key possession is independently
classified as evidence of that property without being
mischaracterized as proof of the entire consequential operation.
M-2.43.3 — Third Technical Dependency
The protected system establishes current authority and revocation
state for the original grant and its required descendants.
M-2.43.4 — Fourth Technical Dependency
The actual effectuation interface is qualified for mandatory blocking
enforcement.
M-2.43.5 — Fifth Technical Dependency
The Finality Sink reconstructs the operation actually presented to
the resource.
M-2.43.6 — Sixth Technical Dependency
Das Expires 29 April 2027 [Page 389]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The actual operation must match the protected authorized-effect
envelope and current source authority.
M-2.43.7 — Seventh Technical Dependency
9.6.3.43. Source page 1940 of the original specification
Separate protected non-bearer finality enablement is consumed under
authoritative sink-local state.
M-2.43.8 — Resulting Technical Property
Where the selected trust and enforcement assumptions are satisfied, a
valid upstream permission, token, cryptographic proof, sandbox
entitlement, monitoring record, or notification does not
independently authorize an unauthorized or replayed consequential
effect.
This property arises from the enforced relationships among the
stages, rather than from the mere simultaneous presence of their
underlying primitives.
M-2.44 — TECHNICAL ABLATION AND COUNTERFACTUAL ANALYSIS
The following comparative investigations may be performed to identify
the contribution of the selected combination.
M-2.44.1 — Permission Verification Without Actual-Effect
Reconstruction
An implementation verifies authorization but does not reconstruct the
real operation at the resource boundary.
A controlled substitution test examines whether a changed target or
parameter may escape the earlier approval.
M-2.44.2 — Actual-Effect Reconstruction Without Current Revocation
An implementation verifies the operation but relies upon stale source
authority.
A controlled revocation test examines whether a previously approved
effect may still occur.
M-2.44.3 — Cryptographic Binding Without Consumption
An implementation authenticates the operation but does not enforce an
authoritative operation-specific use count.
Das Expires 29 April 2027 [Page 390]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A controlled replay test examines duplicate effectuation.
M-2.44.4 — Sandbox Without Privileged-Broker Finality
An application is restricted while a privileged helper accepts broad
commands.
A controlled operation tests whether the assistant can indirectly
cause an unauthorized effect.
M-2.44.5 — Monitoring Without Blocking
An event monitor observes unauthorized effects but does not prevent
them.
A controlled resource test establishes the distinction between
detection and pre-effectuation denial.
M-2.44.6 — Notification Without Authority Freshness
A system uses asynchronous revocation notification as its only
invalidation mechanism.
9.6.3.44. Source page 1941 of the original specification
A dropped-message test examines whether the resource can continue
accepting stale permission.
M-2.44.7 — Complete Protected Combination
The corresponding system enforces current source authority, actual
operation binding, qualified blocking, and protected consumption at
the resource.
The controlled tests compare actual consequences under the same
operation, resource, and attacker assumptions.
M-2.44.8 — Interpretation
A difference in observed behavior may support a specific technical-
effect argument.
The tests do not, by themselves, prove that the mechanism is legally
novel or non-obvious.
M-2.45 — PROPOSED INVENTIVE-STEP CHARACTERIZATION
M-2.45.1 — Avoiding a Mere Aggregation of Known Primitives
Das Expires 29 April 2027 [Page 391]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The invention should not be characterized simply as:
“An AI security system comprising OAuth, sandboxing, cryptography,
notifications, and a network filter.”
Such a formulation presents independent known mechanisms without
establishing a necessary technical interaction.
The present disclosure instead identifies a protected ordered
authority transition in which each selected mechanism contributes a
specifically qualified property to a common effectuation decision.
M-2.45.2 — Candidate Objective Technical Problem
How to prevent a heterogeneous authorization or security subsystem
from being treated as sufficient permission for an actual autonomous
consequential effect when the subsystem proves only a partial
security property, especially after operation transformation,
resource change, revocation, execution-path modification, or
authority replay.
M-2.45.3 — Candidate Technical Solution
A protected translation and validation arrangement converts qualified
outputs of heterogeneous existing security mechanisms into operation-
specific evidence and effect constraints.
Current source-authority and revocation dependencies are verified.
Mandatory blocking enforcement is established at the corresponding
resource boundary.
Separate non-bearer finality enablement is constituted.
The actual Finality Sink reconstructs the operation presented for
effectuation and verifies the current constraints before protected
consumption and release.
M-2.45.4 — Why Mere Juxtaposition Is Insufficient
9.6.3.45. Source page 1942 of the original specification
An authorization token may establish permission but not the precise
current actual effect.
A cryptographic proof may establish key possession but not full
operation legitimacy.
Das Expires 29 April 2027 [Page 392]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A sandbox may restrict a process but not necessarily control every
privileged intermediary.
A network monitor may observe traffic without the information
necessary for semantic authorization.
A notification may signal revocation without establishing its
enforcement.
A cryptographic signature may authenticate an approval but not
establish remaining consumable authority.
The proposed stronger system does not merely place these mechanisms
side by side.
It assigns distinct evidentiary and enforcement roles and makes their
qualified outputs necessary, but individually insufficient, inputs to
one current protected actual-effect transition.
M-2.45.5 — Technical Interdependence
The authorization adapter produces qualified original authority
evidence.
The effect translator determines the permitted consequential
envelope.
The protected validator checks current operation and authority
correspondence.
The revocation controller invalidates affected pending finality
dependencies.
The enforcement qualifier establishes that the actual resource path
is controllable.
The finality controller prepares operation-specific non-bearer
authority.
The actual sink reconstructs the pending real operation.
The consumption controller prevents unsupported duplicate release.
A selected failure of a required dependency prevents the
corresponding protected effect.
M-2.45.6 — Prior-Art Combination Analysis
Das Expires 29 April 2027 [Page 393]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A proper comparison should ask whether an earlier system discloses
not merely individual permission and security controls, but the
specific protected relationships recited by the selected claim.
Where an earlier system already discloses the same dependencies and
actual sink behavior, the claim must be correspondingly narrowed or
differentiated through genuinely supported technical limitations.
M-2.45.7 — Hindsight Reconstruction Concern
A technical analysis should avoid treating knowledge of the proposed
architecture as the reason that a skilled person would have selected
and arranged the underlying primitives.
9.6.3.46. Source page 1943 of the original specification
Instead, an inventive-step evaluation may examine:
The objective technical problem recognized by the relevant prior
system;
Which actual effectuation or revocation failures the earlier system
addressed;
Which component possessed the necessary resource-side information;
Whether the earlier system required independent actual-operation
reconstruction;
Whether a separate finality enablement and protected consumption
transition were provided;
And whether the cited references disclose an express or technically
supported reason to make those particular dependencies mandatory.
The absence of an identical statement in one reference is not, by
itself, sufficient to establish inventive step.
M-2.45.8 — Interoperability Difficulty
The underlying primitives may use different operation identifiers,
permission semantics, freshness models, effectuation boundaries, and
protected-state assumptions.
The claimed technical integration addresses these incompatibilities
by requiring a typed and protected effect descriptor, qualified
evidence properties, current authority generations, and sink-local
finality state.
Das Expires 29 April 2027 [Page 394]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
M-2.45.9 — Non-Equivalent Substitution
Replacing one security primitive with another that provides weaker
actual-operation visibility or blocking capability may invalidate
current consequential authority.
A generic interchangeable-security-component architecture does not
necessarily provide this protected coverage invalidation behavior.
M-2.45.10 — Specificity of Technical Effect
Any inventive-step argument should identify demonstrable technical
behavior, including refusal of unauthorized transformed effects,
rejection of stale revoked authority, prevention of duplicate
finality consumption, or failure-closed handling of missing
enforcement.
Such behavior should be tied to corresponding claim limitations.
M-2.46 — CANDIDATE DISTINCTIVE TECHNICAL KERNELS
M-2.46.1 — Kernel A: Heterogeneous Authorization-to-Actual-Effect
Binding
A protected adapter converts one or more authorization-system results
into a bounded operation-specific effect envelope, and the actual
Finality Sink reconstructs and verifies the pending consequential
operation against that envelope.
M-2.46.2 — Kernel B: Revocation-Dependent Non-Bearer Authority
9.6.3.47. Source page 1944 of the original specification
Current revocation state of a source grant and its required delegated
dependencies is a mandatory condition of a separate protected
finality enablement verified and consumed at the actual sink.
M-2.46.3 — Kernel C: Proof-of-Possession Without Automatic Finality
A successful cryptographic proof identifies an authorized credential
presenter while actual consequential authority remains dependent upon
independent effect validation and protected consumption.
M-2.46.4 — Kernel D: Mandatory Enforcement Qualification
Das Expires 29 April 2027 [Page 395]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A protected controller classifies existing application, OS, network,
and hardware security mechanisms according to their actual blocking
capability and refuses effectuation when a required enforcement path
is not qualified.
M-2.46.5 — Kernel E: Notification-Independent Revocation Safety
A protected resource uses qualified current authority generations or
bounded offline validity rather than relying solely on asynchronous
revocation notification.
M-2.46.6 — Kernel F: Privileged Service Finality
An untrusted autonomous agent cannot convert an authenticated IPC
request into unrestricted exercise of a privileged service's
underlying credentials or device authority.
M-2.46.7 — Kernel G: Security-Substrate Replacement Invalidation
A material change to the semantic or blocking guarantee supplied by
an authorization or security component invalidates dependent
operation-specific finality authority until revalidation.
M-2.46.8 — Kernel H: Cross-Domain Effect Evidence and Resource
Consumption
Authenticated authorization evidence from one domain is independently
verified and transformed into finality eligibility consumed at a
different protected resource domain.
M-2.46.9 — Kernel I: Plaintext-Aware Release with Network Enforcement
A protected pre-encryption content commitment and recipient binding
are verified in conjunction with a controlled egress route, without
requiring the network-flow mechanism itself to understand plaintext.
M-2.46.10 — Kernel J: Crash-Consistent Finality Continuity
Actual-effect authority consumption and dispatch intent remain
protected across failures, independently of whether an external
receiver provides an immediate completion acknowledgement.
These kernels may support different claim families or dependent
limitations.
Their combination should preserve a single identifiable technical
relationship where required by the selected claim.
Das Expires 29 April 2027 [Page 396]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.6.3.48. Source page 1945 of the original specification
M-2.47 — POTENTIAL INDEPENDENT CLAIM ARCHITECTURES
M-2.47.1 — Candidate Independent Claim A: Interoperable Execution-
Finality System
A system comprising:
A protected adapter configured to obtain authenticated evidence from
at least one authorization or security mechanism;
A protected effect-translation controller configured to derive an
operation-specific permitted effect envelope from the evidence;
A protected validation controller configured to verify current
authority and applicable operation conditions;
A finality-authority controller configured to establish separate
scoped non-bearer effectuation enablement;
And an independently enforcing Finality Sink configured to
reconstruct the actual pending operation, verify correspondence with
the permitted effect envelope and current authority state, and
consume the enablement before permitting the consequential effect.
M-2.47.2 — Candidate Independent Claim B: Revocation-Coupled Method
A method comprising:
Receiving a Candidate Act;
Resolving its original authorization and downstream dependencies;
Authenticating a current revocation or authority-generation state;
Invalidating operation-specific enablement affected by the current
revocation state;
And refusing the actual resource effect at a mandatory Finality Sink
when a required source authority has been withdrawn.
M-2.47.3 — Candidate Independent Claim C: Protected Enforcement-
Qualification Apparatus
An apparatus comprising:
Das Expires 29 April 2027 [Page 397]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
An interface for obtaining qualified security-mechanism capability
evidence;
A controller configured to distinguish observation-only and blocking
enforcement;
A current effectuation-path dependency state;
And an actual effectuation gate configured to invalidate or refuse
operation-specific finality when a required blocking condition
becomes unavailable.
M-2.47.4 — Candidate Independent Claim D: Privileged Agent-Broker
Finality
9.6.3.49. Source page 1946 of the original specification
A protected service configured to receive a proposed operation from a
lower-trust autonomous requester, independently resolve the actual
resource-side operation, verify current source-derived authority and
protected non-bearer finality state, and exercise the privileged
resource only upon satisfaction of the corresponding sink-local
consumption condition.
M-2.47.5 — Candidate Independent Claim E: Hardware-Assisted Finality
A protected apparatus comprising a hardware-supported authority-
verification function, current resource or revocation state, and an
effect-capable command gate configured to refuse actual commands
without a matching operation-specific finality enablement.
M-2.47.6 — Candidate Independent Claim F: Cross-Domain Implementation
A system comprising an originating authorization domain, a protected
evidence and operation-translation component, a separately controlled
destination Finality Sink, and authenticated current authority and
actual-effect binding enforced by the destination before
consequential execution.
M-2.47.7 — Claim Drafting Consideration
The broadest candidate should capture a demonstrable common technical
interaction rather than require every optional standards adapter.
Dependent claims may introduce specific cryptographic, OS, network,
IPC, notification, and hardware implementations.
Das Expires 29 April 2027 [Page 398]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Where a narrower variation independently supports a distinct
technical effect, a separate claim family may be considered.
M-2.48 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
1. The authorization evidence is obtained from an OAuth-compatible
authorization server.
2. The authorization evidence comprises structured operation-
specific permission details.
3. A protected effect translator maps structured permission details
to an actual resource effect envelope.
4. The actual resource verifies correspondence between the requested
operation and the permission envelope.
5. A token-revocation result invalidates affected pending finality
enablement.
6. A current token-status or introspection result is associated with
an authenticated authority generation.
7. Authorization-status caching is subject to protected freshness
requirements.
8. A stale active-status result cannot override a current revoked
source grant.
9. A sender-constrained credential provides qualified proof-of-
possession evidence.
10. Proof-of-possession is evaluated separately from actual
operation authorization.
9.6.3.50. Source page 1947 of the original specification
11. A certificate-bound credential provides authenticated requester
binding.
12. A mutually authenticated communication channel transports
qualified authority evidence.
13. A protected cryptographic key manager authenticates operation-
related evidence.
14. Protected key material is unavailable to the untrusted requester
where selected.
Das Expires 29 April 2027 [Page 399]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
15. Key-possession evidence does not independently confer
unrestricted finality authority.
16. An operating-system sandbox constrains the requesting workload.
17. Entitlement or permission evidence is included in effectuation-
path qualification.
18. An alternate privileged intermediary is classified as a separate
effect-capable path.
19. A structured application action is represented as a Candidate
Act.
20. Tool or application-action parameters are resolved into a
protected actual-effect descriptor.
21. A material action-contract change invalidates dependent
authority.
22. An authenticated interprocess service receives a Candidate Act
from a lower-trust process.
23. The privileged service verifies original source-derived
operation authority.
24. The privileged service prevents release of reusable complete
resource credentials to the requester.
25. An operating-system event authorization hook serves as a
mandatory enforcement component for supported operations.
26. Observation-only hooks cannot satisfy a required blocking
predicate.
27. A protected network filter constrains the corresponding
effectuation route.
28. An application-level gateway verifies content semantics
unavailable to a lower-level network-flow monitor.
29. A protected pre-encryption commitment binds authorized plaintext
to a specified recipient or transmission.
30. A network routing or proxy change triggers finality-path
revalidation.
31. An asynchronous notification signals a revocation-state change.
Das Expires 29 April 2027 [Page 400]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
32. The system does not rely upon guaranteed delivery of the
notification to establish current finality safety.
33. A protected sink queries authoritative current revocation state
before a specified consequential effect.
34. A protected offline lease bounds the permissible use of stale
authorization evidence.
35. Revocation-dependent authority is associated with a monotonic
protected generation.
9.6.3.51. Source page 1948 of the original specification
36. A revocation of a mandatory parent grant invalidates dependent
delegated finality authority.
37. An unaffected independent authorization remains eligible where
the applicable policy permits it.
38. A protected finality controller cross-commits collection-time
and independently validated execution-time evidence.
39. The finality enablement is bound to one authorized Candidate
Act.
40. The enablement is bound to a designated Finality Sink.
41. The actual Finality Sink reconstructs the pending operation
independently of the requester's prior self-description.
42. The sink verifies current resource identity.
43. The sink verifies current revocation or authorization state.
44. The sink verifies current mandatory effectuation-path coverage.
45. The sink verifies a protected current policy or configuration
generation.
46. The sink verifies current resource version or ownership where
required.
47. A copied opaque enablement reference remains insufficient for
effectuation.
48. A protected consumption state prevents unauthorized repeated
exercise.
Das Expires 29 April 2027 [Page 401]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
49. A transactional resource controller atomically commits local
effect and corresponding finality consumption where supported.
50. A remote operation preserves durable consumption and dispatch-
intent state.
51. An uncertain external outcome does not automatically restore
consumed authority.
52. A hardware command gate verifies current device-bound finality.
53. A direct accelerator-originated effect is treated as a separate
controlled effectuation path where required.
54. Material hardware resource reassignment invalidates dependent
authority generations.
55. A security-substrate replacement triggers requalification of its
supplied enforcement property.
56. A weaker monitoring-only replacement does not inherit earlier
blocking coverage.
57. A notification-delivery acknowledgement is distinguished from
proof of sink-side revocation application.
58. A protected enforcement receipt identifies the actual sink and
committed invalidation state.
59. The system uses a typed interface identifying the technical
security property supplied by each underlying mechanism.
9.6.3.52. Source page 1949 of the original specification
60. A successful identity proof cannot substitute for a required
effect-semantics proof.
61. A successful token-validity check cannot substitute for
protected finality consumption.
62. A valid earlier approval cannot override a later mandatory
revocation.
63. A multi-effect structured action is decomposed into separately
governed actual consequences where selected.
64. A dependent successor operation requires an accepted earlier
real-effect receipt where the applicable causal protocol requires it.
Das Expires 29 April 2027 [Page 402]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
65. The disclosed finality relation is implemented without
dependence upon any particular authorization protocol or device
manufacturer.
M-2.49 — UNIVERSAL COMBINATION, SUBCOMBINATION, AND SUBSTITUTE-
IMPLEMENTATION CLAUSE
The individual implementation mechanisms described in this
Miscellaneous Embodiment M-2 may be used alone where they constitute
a technically complete selected invention, or in any technically
compatible subcombination or combined architecture.
An implementation may combine structured authorization details with
protected current revocation and actual-operation finality.
Another may combine proof-of-possession authentication with a
protected broker and sink-local finality consumption.
Another may combine a hardware-protected cryptographic key with
operation-specific finality and protected resource-state
verification.
Another may combine sandbox confinement, entitlement checks, and
mandatory operating-system resource authorization.
Another may combine structured application actions, privileged
interprocess communication, and actual-effect reconstruction.
Another may combine network egress control with protected plaintext-
aware data-release authorization.
Another may combine asynchronous revocation notification with current
authority-generation checking.
Another may combine protected transactional state, current revocation
dependencies, and finality consumption.
Another may combine hardware command enforcement with current device
ownership and protected authority generations.
Another may combine all of the foregoing, provided that each included
mechanism supplies an actually supported security property and the
claimed protected authority relationship remains enforceable.
9.6.3.53. Source page 1950 of the original specification
An authorization server may be replaced by another functionally
compatible authority provider.
Das Expires 29 April 2027 [Page 403]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A proof-of-possession protocol may be replaced by another
authenticated cryptographic holder-binding mechanism.
A protected key manager may be implemented in software or hardware
under the applicable selected protection model.
A sandbox may be implemented using suitable operating-system,
hypervisor, container, or hardware resource restrictions.
A structured application-action framework may be replaced by another
machine-readable tool or invocation interface.
A privileged IPC service may be replaced by another suitably
protected effectuation broker.
An operating-system authorization hook may be replaced by a resource-
specific blocking controller.
A network extension or proxy may be replaced by another controlled
network effectuation path.
An asynchronous notification transport may be replaced by polling,
authenticated event delivery, or current-state queries.
A transactional authority store may be replaced by an equivalent
protected monotonic state mechanism.
A Finality Sink may be an application service, network gateway,
database transaction controller, operating-system resource gate,
credential broker, storage controller, hardware command interface, or
another mandatory consequential boundary.
The functional equivalence of any substitute is determined by the
actual property required by the selected implementation, not merely
by the substitute's label or commercial classification.
The invention is not limited to the simultaneous use of every
optional security mechanism.
Where an operation requires one selected combination of authority,
evidence, current revocation, coverage, and finality predicates, the
corresponding required combination remains mandatory for that
operation.
The disclosed embodiments are not restricted to a single ordering of
nondependent administrative or preparatory operations.
Das Expires 29 April 2027 [Page 404]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
However, the protected causal relationships necessary to prevent
unauthorized consequential release must be preserved.
Compatible embodiments may share the same protected evidence
collector, validator, authority controller, revocation registry,
coverage verifier, resource controller, or Finality Sink.
Such sharing does not remove any expressly required independence or
protected-state separation.
The mathematical descriptions, pseudocode, security-protocol
examples, tests, data structures, and reference architectures are
non-limiting explanatory aids for a person having ordinary skill in
the art.
9.6.3.54. Source page 1951 of the original specification
The examples do not restrict the invention to a particular commercial
protocol or hardware implementation.
M-2.50 — FINAL TECHNICAL CHARACTERIZATION
The present Miscellaneous Embodiment M-2 discloses a protected
integration architecture that permits existing authorization,
cryptographic, operating-system, sandbox, communication, network,
credential, notification, transactional, and hardware security
mechanisms to contribute to autonomous execution-finality control
without treating their individual successful results as sufficient
authorization for a real consequential operation.
A requesting computational entity may possess valid credentials,
successful cryptographic authentication, permitted application-tool
access, and resource-interface connectivity while still lacking
current authority to produce a specific consequential effect.
A protected adapter obtains evidence concerning the properties
actually established by the selected security mechanisms.
A protected translation controller converts the relevant permission
and operation information into a bounded actual-effect envelope.
A protected validator determines whether the required source
authority, revocation state, resource conditions, and operation
semantics remain valid.
Where the selected implementation requires collection-time and
independent execution-time evidence, the corresponding records are
cross-committed to the same Candidate Act.
Das Expires 29 April 2027 [Page 405]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A separate protected controller establishes scoped non-bearer
finality enablement.
The enablement remains dependent upon the selected current authority
and enforcement conditions.
Material changes to source authorization, revocation state, operation
semantics, security-substrate capability, or actual effectuation-path
coverage may invalidate affected authority.
At the actual resource boundary, an independent Finality Sink
reconstructs the pending consequential operation and checks the
relevant current predicates.
A valid upstream token, signed receipt, key-possession proof, sandbox
entitlement, structured action declaration, security event
notification, or cached active-status result does not independently
bypass that verification.
The resource-side controller requires valid protected enablement and
performs the applicable sink-local consumption transition before the
consequential effect is permitted.
The architecture may use known technical primitives while requiring
an additional operation-specific protected authority constitution and
finality relationship.
The principal candidate inventive technical concept of Miscellaneous
Embodiment M-2 is a standards-interoperable and platform-independent
protected execution-finality architecture in which heterogeneous
established authorization and security mechanisms supply individually
qualified evidence or enforcement properties, a protected controller
binds those properties to a specific consequential Candidate Act and
its current original authority, revocation and actual-effect scope,
separately constitutes non-bearer finality enablement, and
9.6.3.55. Source page 1952 of the original specification
requires an independently enforcing Finality Sink to reconstruct the
actual pending effect and verify current authority, enforcement
coverage, and sink-local protected consumption before releasing the
consequence.
END OF MISCELLANEOUS EMBODIMENT M-2 — COMPLETE TECHNICAL DISCLOSURE.
Das Expires 29 April 2027 [Page 406]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.7. Embodiment 25: Sandboxed Tool Execution, Privilege Transitions and
Mandatory Escaping-Effect Control
Original technical source global pages 2093-2168; input volume
TECHNICAL SPECIFICATION -2012-2566.pdf. Primary Part 4 topic:
Embodiment 25: Sandboxed Tool Execution, Privilege Transitions and
Mandatory Escaping-Effect Control. The patent specification may
present optional embodiments, alternative formulations and claim
proposals; preserving its wording does not convert each option into a
requirement of a standard.
9.7.1. Protected Architecture and Trust-Boundary Diagram
[Lower-trust isolated agent sandbox]
| draft/tool/internal output
v
[Privilege transition / output promotion]
|
[Host-only connector / resource broker]
|
[Cross-boundary effect classifier + PED]
|
[Finality Sink actual operation verification]
|
[Permitted controlled external consequence]
Figure 24: Embodiment 25: Sandboxed Tool Execution, Privilege
Transitions and Mandatory Escaping-Effect Control — architecture
9.7.2. Operational Decision and Fail-Closed Flowchart
[Sandbox tool produces candidate output]
|
<Would action escape sandbox?>--NO-->[Internal only]
|YES
[Hold candidate non-effective]
|
<Current privilege transition permitted?>--NO-->[Deny]
|YES
<Coverage of alternate exit paths qualified?>--NO-->[Fence]
|YES
[Sink actual output / destination reconstruction]
|
<Scope + authority + state pass?>--NO-->[Refuse]
|YES
[Consume and promote effect]
Das Expires 29 April 2027 [Page 407]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Figure 25: Embodiment 25: Sandboxed Tool Execution, Privilege
Transitions and Mandatory Escaping-Effect Control — operational
flowchart
9.7.3. Original Page-by-Page Technical Disclosure
9.7.3.1. Source page 2093 of the original specification
Tool-calling language-model systems;
Multi-agent orchestration systems;
Cloud automation services;
Operating-system automation components;
Network management agents;
Enterprise workflow controllers;
Robotic controllers;
Industrial devices;
And other computational workloads capable of proposing consequential
operations.
An autonomous entity may execute tools inside a restricted
environment.
The restricted environment may comprise:
A process sandbox;
An operating-system namespace;
A container;
A virtual machine;
A micro-virtual-machine;
An application execution cell;
A constrained language runtime;
A WebAssembly execution environment;
Das Expires 29 April 2027 [Page 408]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A remote isolated worker;
A hardware-isolated execution domain;
Or a suitable combination of these mechanisms.
The restricted environment may limit filesystem access, process
creation, system calls, memory use, network connectivity, privileged
instructions, device access, interprocess communication, or other
computational capabilities.
Such restrictions can materially reduce exposure to an untrusted or
compromised workload.
9.7.3.2. Source page 2094 of the original specification
However, a sandbox's ability to execute permitted internal
computations does not independently establish that every
consequential operation requested through or emerging from that
sandbox is authorized.
For example:
An agent may prepare a database mutation inside an isolated runtime.
The resulting database transaction may be executed by a separate
privileged service.
An agent may prepare an HTTP request inside a container.
The request may later be transmitted by an external gateway.
An agent may generate source code and a software artifact inside a
sandbox.
The artifact may later be deployed to production.
An agent may create a file within an ephemeral workspace.
A privileged host service may subsequently copy the file into a
protected enterprise directory.
An agent may request that a credential broker execute an
authenticated operation.
The broker may hold reusable authority unavailable to the sandbox.
Das Expires 29 April 2027 [Page 409]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
An agent may generate a device command within an isolated computation
environment.
The command may later be dispatched through a hardware interface.
An agent may construct a persistent memory update.
A vector-database service may later commit the update into shared or
persistent state.
A sandbox may successfully prevent the agent from directly accessing
protected host resources.
Nevertheless, an authorized connector, privileged tool, remote
gateway, inherited capability, shared resource, or output-promotion
mechanism may provide another path by which sandbox-generated
computation produces a consequential effect.
The relevant security question therefore includes not only whether
the autonomous workload is isolated, but whether a proposed
consequential effect escaping the isolated computational boundary has
independently valid operation-specific authority.
A principal implementation maintains the autonomous workload within a
qualified Sandbox Execution Domain, hereinafter SED-25.
The domain is associated with a protected isolation profile, a
qualified runtime identity, an effectuation-surface coverage policy,
and current authority generations.
9.7.3.3. Source page 2095 of the original specification
The workload may freely perform selected permitted internal
computational operations without requiring a fresh protected
authorization for every ordinary calculation.
When a proposed operation would cross a protected effectuation
boundary, a boundary controller identifies the material effect class
and maintains the consequential operation in a Non-Effective State.
A Candidate Act is constructed to identify the requested real-world
or persistent consequence.
A Protected Enforcement Domain independently verifies current source
authority, actual resource identity, applicable tool and privilege
constraints, required protected evidence, and the intended Finality
Sink.
Das Expires 29 April 2027 [Page 410]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Where the effect requires a privileged operation, a protected
authority-transition controller determines whether a narrow
operation-specific authority transition is valid.
Such transition may be implemented through a protected broker, an
appropriately restricted new execution worker, an authenticated
service call, a hardware enablement mechanism, or another qualified
boundary-control procedure.
A separate finality controller establishes scoped non-bearer
enablement bound to the specific Candidate Act, applicable privilege
generation, effectuation path, and actual resource conditions.
The Finality Sink independently obtains or reconstructs the actual
pending consequential operation.
The sink verifies that the actual operation corresponds to the
current source-authorized effect envelope and that the relevant
sandbox boundary, privilege state, resource identity, and finality
conditions remain valid.
Only after the required protected checks and consumption transition
may the consequential effect occur.
An agent's permission to perform internal computation does not
thereby become unrestricted authority to cause external effects.
25.0.2 — Fundamental Technical Principle
Sandbox permission is not consequential execution authority.
More specifically:
An isolated process may compute a command without authority to
execute the command against a protected resource.
A sandbox may create an artifact without authority to promote the
artifact into production.
9.7.3.4. Source page 2096 of the original specification
A container may generate a network request without authority to
transmit the request to every reachable destination.
A privileged helper may possess a credential without authority to
exercise that credential for every request received from the sandbox.
Das Expires 29 April 2027 [Page 411]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A successful sandbox security check does not automatically constitute
final approval of a particular external operation.
A human approval of one protected operation does not authorize
unrestricted elevation of the agent's future privileges.
And a runtime's security classification does not independently
replace actual operation-specific Finality-Sink verification.
25.0.3 — Principal Candidate Inventive Combination
In one implementation, the combination comprises:
(a) a protected Sandbox Execution Domain associated with an
autonomous computational workload;
(b) an authenticated sandbox and tool-execution identity;
(c) a protected classification of operations according to whether
they remain internal or cross a consequential effectuation boundary;
(d) a protected effectuation-path coverage commitment;
(e) an enforceable Non-Effective State for a Candidate Act seeking an
external or persistent consequential effect;
(f) a protected source-authority and current privilege-generation
validator;
(g) a bounded privilege-transition controller configured to enable a
specified operation without necessarily granting general ambient
privilege to the autonomous workload;
(h) an independent execution-time validator;
(i) a scoped non-bearer finality enablement;
(j) a designated Finality Sink obtaining or reconstructing the actual
pending consequential operation;
(k) sink-side verification of actual resource and operation
correspondence;
(l) protected finality consumption;
Das Expires 29 April 2027 [Page 412]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.7.3.5. Source page 2097 of the original specification
(m) controlled resource-side effectuation or protected output
promotion.
25.0.4 — Specific Technical Distinction
The proposed invention is not defined merely by:
Placing an AI agent inside a sandbox;
Using operating-system namespaces;
Filtering system calls;
Applying a mandatory-access-control policy;
Routing network traffic through a proxy;
Creating a virtual machine;
Using a restricted tool allowlist;
Or requiring human confirmation.
Those techniques are established.
The principal candidate distinguishing relationship is that a
sandbox-to-resource transition capable of producing a real
consequence becomes a separately protected Candidate Act whose
authority is established outside the lower-trust computational
requester's control and independently verified at the actual
effectuation boundary.
25.0.5 — Relationship to Earlier Embodiments
Embodiment 14 may provide foundational effectuation-path discovery
and runtime bypass detection.
Embodiment 15 may provide protected cross-domain evidence commitment.
Embodiment 16 may provide crash-consistent finality journaling.
Embodiment 18 may provide current revocation and authority
invalidation.
Embodiment 21 may provide actual resource-identity continuity.
Das Expires 29 April 2027 [Page 413]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Embodiment 22 may provide protected consequential resource budgets.
Embodiment 23 may provide credential and secret-use finality.
Embodiment 24 may provide instruction and tool-output provenance.
The present embodiment provides a focused implementation of
consequential effectuation across sandbox boundaries and protected
privilege transitions.
9.7.3.6. Source page 2098 of the original specification
The earlier mechanisms need not be repeated in their entirety.
25.0.6 — Non-Limiting Reference Architecture
ORIGINATING AUTHORIZED TASK | v PROTECTED TASK AUTHORITY | v
AUTONOMOUS AGENT / TOOL RUNTIME | v SANDBOX EXECUTION DOMAIN / | \
/ | \ v v v INTERNAL OUTPUT PROPOSED COMPUTATION ARTIFACT TOOL ACTION
\ | / \ | / +----------+-----------+ | v PROTECTED BOUNDARY
CLASSIFIER | +--------+--------+ | | v v INTERNAL CONSEQUENTIAL
PERMITTED BOUNDARY ESCAPE | | v v CONTINUE CANDIDATE ACT COMPUTE | v
NON-EFFECTIVE HOLD | v PROTECTED AUTHORITY AND PRIVILEGE CHECK | v
INDEPENDENT VALIDATION | v SCOPED NON-BEARER FINALITY | v CONTROLLED
EFFECTUATION BROKER OR RESOURCE SINK
9.7.3.7. Source page 2099 of the original specification
| v ACTUAL OPERATION RECONSTRUCTION | v CURRENT SOURCE, RESOURCE,
PRIVILEGE, AND COVERAGE CHECKS | v SINK-LOCAL CONSUMPTION | v
AUTHORIZED ACTUAL EFFECT
The diagram is illustrative and non-limiting and is intended to
assist a person having ordinary skill in the art.
25.1 — TECHNICAL FIELD
The invention relates to autonomous-agent sandboxing, process
isolation, virtualized execution, privilege separation, operating-
system access control, protected tool execution, resource mediation,
effectuation-boundary security, dynamic privilege transition,
cryptographic authority binding, and actual consequential resource
finality.
More particularly, it concerns preserving the distinction between
permitted computation inside a restricted execution environment and
separately authorized consequential effects outside that environment.
Das Expires 29 April 2027 [Page 414]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
25.2 — SPECIFIC TECHNICAL PROBLEMS
25.2.1 — Sandbox Containment Versus External Authority
A sandbox may isolate a process without validating every
consequential resource operation performed by external privileged
services on its behalf.
25.2.2 — Privileged Tool Invocation
A lower-trust agent may invoke a helper possessing broader authority
than the original task requires.
25.2.3 — Unrestricted Privilege Elevation
A legitimate request for one privileged operation may result in broad
persistent privilege being granted to the workload.
9.7.3.8. Source page 2100 of the original specification
25.2.4 — Sandbox Output Promotion
An artifact generated inside an isolated environment may later become
effective in production.
25.2.5 — Network Egress
A permitted network interface may allow an unauthorized destination
or data disclosure.
25.2.6 — File-System Escape
An agent may cause a protected file mutation through a host-side
service or pre-existing resource handle.
25.2.7 — Credential Broker Misuse
An agent may use a host credential broker to cause unauthorized
authenticated effects.
25.2.8 — IPC Privilege Crossing
An interprocess communication endpoint may lead to privileged host-
side action.
25.2.9 — Resource Descriptor Inheritance
Das Expires 29 April 2027 [Page 415]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A sandboxed worker may inherit or receive an effect-capable
descriptor that bypasses an intended access restriction.
25.2.10 — Pre-Opened Network Connection
A previously established connection may continue to carry effects
after a new sandbox restriction is applied.
25.2.11 — Mounted Resource Exposure
A shared or mounted resource may permit persistent effects outside
the intended sandbox scope.
25.2.12 — Dynamic Tool Installation
A newly loaded tool may introduce an effect-capable path not
represented in the original policy.
25.2.13 — Plugin or Extension Privilege Drift
A tool's privileges may change while its name remains unchanged.
25.2.14 — Container Restart
A restarted runtime may recover stale authority or previously usable
handles.
9.7.3.9. Source page 2101 of the original specification
25.2.15 — Snapshot Rollback
Restoration of earlier runtime state may reintroduce outdated
privilege assumptions.
25.2.16 — Sandbox Policy Mutation
A privileged policy change may unintentionally expand all future
resource access.
25.2.17 — Multiple Execution Domains
A task may migrate between containers, hosts, micro-virtual-machines,
or remote workers.
25.2.18 — Tool-Effect Misclassification
An apparently harmless tool invocation may produce a persistent or
external resource effect.
Das Expires 29 April 2027 [Page 416]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
25.2.19 — Monitoring Without Enforcement
An observer may detect a suspicious operation without possessing
power to block it.
25.2.20 — Interposition Race
A supervisor may validate mutable request data that changes before
the kernel or resource consumes it.
25.2.21 — Network Address and Resource Rebinding
The actual destination may change after an earlier network-policy
decision.
25.2.22 — Credential Injection After Authorization
A privileged broker may insert a reusable credential into an
operation whose material parameters have changed.
25.2.23 — Side Effects of Read Operations
An operation described as read-only may trigger logging, remote
calls, state changes, or other consequences depending on the actual
resource service.
25.2.24 — Ambiguous Effect Classification
A tool operation may comprise both internal computation and
consequential external suboperations.
25.2.25 — Hardware Device Egress
A sandboxed workload may construct commands that a privileged device
controller later actuates.
25.2.26 — GPU or Accelerator Egress
9.7.3.10. Source page 2102 of the original specification
A computing accelerator may produce outputs or trigger transfers that
affect external resource state.
25.2.27 — Persistent Memory Mutation
A sandbox-generated update may be committed into a shared retrieval
or memory database.
Das Expires 29 April 2027 [Page 417]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
25.2.28 — Screen or UI Effectuation
A computer-use tool may perform clicks or keystrokes that cause
consequential application actions.
25.2.29 — Approval Scope Ambiguity
A human may approve one operation while the system implements the
approval as broad privilege elevation.
25.2.30 — Coverage Failure
A protected gate may control one path but fail to discover another
path to the same consequence.
25.2.31 — Technical Objective
A candidate objective technical problem is:
How to permit useful autonomous computation inside restricted
execution domains while preventing requests, outputs, tool
invocations, credential uses, or privileged transitions from causing
unauthorized consequential effects outside the sandbox, including
when runtime capabilities and effectuation paths change dynamically.
25.3 — ESTABLISHED SANDBOX TECHNOLOGIES
25.3.1 — Operating-System Namespaces
Namespaces may isolate selected process-visible resources.
They do not independently establish complete authorization of all
effects performed by privileged services outside the isolated
namespace.
25.3.2 — System-Call Filtering
System-call filtering may restrict which kernel operations a process
can invoke.
It does not automatically evaluate all application-level consequences
or remote resource semantics.
25.3.3 — Mandatory Access Control
Das Expires 29 April 2027 [Page 418]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.7.3.11. Source page 2103 of the original specification
Operating-system security mechanisms may restrict access to
filesystem objects, network resources, processes, or other protected
resources.
These mechanisms may supply mandatory enforcement hooks for the
selected implementation.
25.3.4 — Process Capabilities
Operating-system capabilities may divide selected privileged
operations.
A capability granted to a process may remain broader than one
operation-specific authorized consequence.
25.3.5 — Virtual Machines
A virtual machine may provide a strong execution isolation boundary
under the applicable hypervisor and host assumptions.
A host-side agent connector can still perform an external effect on
the guest's behalf.
25.3.6 — Resource Quotas
Resource controllers may limit memory, processing, and other
resources.
These limits do not automatically authorize every externally
consequential operation.
25.3.7 — Network Proxies
A proxy may filter destinations, inspect requests, or provide
credential mediation.
A proxy's protection is limited to the paths and operation properties
it actually controls.
25.3.8 — Hardware Isolation
A protected execution environment may isolate memory and selected
execution state.
It does not automatically verify application-level authority for
external resource mutations.
Das Expires 29 April 2027 [Page 419]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
25.3.9 — Candidate Technical Distinction
The proposed embodiment uses such mechanisms to establish restricted
computational environments while separately binding sandbox-escaping
consequential operations to protected source authority and Finality-
Sink enforcement.
25.4 — PRINCIPAL SYSTEM COMPONENTS
A principal implementation may comprise:
9.7.3.12. Source page 2104 of the original specification
A Protected Source-Authority Registry;
A Sandbox Execution Domain;
A Sandbox Runtime Identity Controller;
An Isolation Profile Registry;
A Protected Tool Registry;
A Consequential Boundary Classifier;
An Effectuation-Path Coverage Controller;
A Candidate Act Constructor;
A Non-Effective Hold Controller;
A Protected Privilege-Transition Controller;
An Independent Operation Validator;
A Non-Bearer Finality Controller;
An Effect-Capable Broker;
An Actual Resource Finality Sink;
A Sink-Local Consumption Controller;
And a Protected Attempt and Outcome Journal.
Optional components include:
A syscall restriction layer;
Das Expires 29 April 2027 [Page 420]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A filesystem access-control mechanism;
A network egress controller;
An authenticated IPC interface;
A credential broker;
A virtual-machine monitor;
A hardware security controller;
An output-artifact promotion service;
9.7.3.13. Source page 2105 of the original specification
A device command gate;
A transaction database;
A protected policy manager;
And an attestation interface.
25.5 — TECHNICAL DEFINITIONS
25.5.1 — Sandbox Execution Domain
A Sandbox Execution Domain, or SED-25, means a restricted
computational environment operating under a defined isolation and
resource-access profile.
25.5.2 — Protected Isolation Profile
A Protected Isolation Profile, or PIP-25, means an authenticated
description of selected runtime restrictions, accessible resources,
capabilities, and applicable enforcement mechanisms.
25.5.3 — Sandbox Runtime Identity
A Sandbox Runtime Identity, or SRI-25, means a qualified identity
identifying a particular execution instance or current runtime
generation.
25.5.4 — Sandbox Generation
A Sandbox Generation means an authoritative version of a sandbox
instance or its relevant isolation state.
Das Expires 29 April 2027 [Page 421]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
25.5.5 — Internal Computational Act
An Internal Computational Act means an operation whose relevant
effects remain within the expressly permitted computational boundary
under the selected policy.
25.5.6 — Consequential Boundary Escape
A Consequential Boundary Escape, or CBE-25, means an operation,
output, request, or transition capable of causing a covered real,
persistent, externally visible, or independently administered
resource effect outside the authorized internal computational
envelope.
25.5.7 — Boundary-Escape Candidate Act
A Boundary-Escape Candidate Act, or BECA-25, means a Candidate Act
representing an operation classified as crossing a covered
consequential effectuation boundary.
25.5.8 — Protected Boundary Classifier
9.7.3.14. Source page 2106 of the original specification
A Protected Boundary Classifier, or PBC-25, means a protected
component configured to determine whether an operation requires
external consequential authority.
25.5.9 — Effectuation Surface
An Effectuation Surface means an interface through which computation
may cause a consequential resource effect.
25.5.10 — Effectuation Coverage Set
An Effectuation Coverage Set, or ECS-25, means a protected
representation of the interfaces covered by mandatory actual-effect
enforcement.
25.5.11 — Coverage Generation
A Coverage Generation means an authoritative version of the
applicable effectuation-path coverage state.
25.5.12 — Protected Escape Hold
Das Expires 29 April 2027 [Page 422]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A Protected Escape Hold, or PEH-25, means an enforceable condition
withholding an operation's consequential effect until required
finality authority is established.
25.5.13 — Protected Privilege Transition
A Protected Privilege Transition, or PPT-25, means an authorized
change in the authority available for a specific operation or
qualified execution context.
25.5.14 — Privilege Transition Envelope
A Privilege Transition Envelope, or PTE-25, means an authenticated
description of the precise privilege, resource, operation, duration,
and sink conditions permitted for a transition.
25.5.15 — Privilege Generation
A Privilege Generation means an authoritative version of currently
valid operation or execution-context privileges.
25.5.16 — Ambient Privilege
Ambient Privilege means authority generally available to a process or
environment without a new operation-specific authorization.
25.5.17 — Operation-Bound Privilege
Operation-Bound Privilege means authority limited to a designated
consequential operation or bounded effect class.
25.5.18 — Privileged Effectuation Broker
9.7.3.15. Source page 2107 of the original specification
A Privileged Effectuation Broker, or PEB-25, means a protected
component capable of performing specified resource operations
unavailable directly to the sandbox.
25.5.19 — Fresh Restricted Worker
A Fresh Restricted Worker means a newly established execution
component supplied with only the authority required for a designated
qualified operation under the selected protection model.
25.5.20 — Privilege-Transition Commitment
Das Expires 29 April 2027 [Page 423]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A Privilege-Transition Commitment means authenticated evidence
binding the actual intended operation to its protected privilege-
transition conditions.
25.5.21 — Sandbox Output Promotion
Sandbox Output Promotion means moving, publishing, committing,
deploying, or otherwise making a sandbox-generated artifact effective
in a protected external or persistent resource domain.
25.5.22 — Output-Promotion Sink
An Output-Promotion Sink, or OPS-25, means the protected resource
boundary controlling such promotion.
25.5.23 — Escaping Effect Descriptor
An Escaping Effect Descriptor, or EED-25, means a protected
representation of the actual consequential operation that would cross
the sandbox boundary.
25.5.24 — Actual Escape Reconstruction
Actual Escape Reconstruction means obtaining or deriving the actual
resource operation to be performed by the protected escape interface.
25.5.25 — Protected Sandbox Authority Separation
Protected Sandbox Authority Separation means the restriction of
lower-trust computational control so that it cannot independently
constitute consequential resource authority.
25.5.26 — Privilege Escalation Request
A Privilege Escalation Request means a request for increased
effective authority to perform an operation.
25.5.27 — Scope-Preserving Privilege Transition
A Scope-Preserving Privilege Transition means a transition providing
the technical access needed to perform an operation without
increasing the originating authorized effect scope.
9.7.3.16. Source page 2108 of the original specification
25.5.28 — Privilege Inflation
Das Expires 29 April 2027 [Page 424]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Privilege Inflation means assigning broader effective authority than
is required or authorized for the selected operation.
25.5.29 — Sandbox Escape Coverage
Sandbox Escape Coverage means the set of actual boundary-crossing
effect paths under mandatory protected control.
25.5.30 — Coverage Equivalence
Coverage Equivalence means that an alternate effectuation path
enforces the necessary protected authority and actual-operation
predicates.
25.5.31 — Tool-Effect Classification
Tool-Effect Classification means a protected determination of the
consequential operation classes a tool can actually initiate.
25.5.32 — Protected Tool-Execution Contract
A Protected Tool-Execution Contract, or PTC-25, means an
authenticated representation of a tool's supported operation
semantics, privileges, effectuation paths, and current contract
generation.
25.5.33 — Sandbox Authority Attestation
Sandbox Authority Attestation means qualified evidence concerning
selected runtime identity, configuration, or isolation-state
properties.
25.5.34 — Sandbox Revalidation Fence
A Sandbox Revalidation Fence, or SRF-25, means a protected condition
preventing covered consequential effects after a material runtime,
privilege, tool, or coverage change.
25.5.35 — Inherited Authority Object
An Inherited Authority Object means a credential, descriptor,
connection, handle, mapping, or other resource reference that may
confer authority within the execution environment.
25.5.36 — Protected Broker Delegation
Protected Broker Delegation means a bounded transfer of permitted
operation authority to a qualified privileged broker.
Das Expires 29 April 2027 [Page 425]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
25.5.37 — Sandbox-Local Artifact
A Sandbox-Local Artifact means data or an object produced within the
isolated computational workspace before any separately controlled
external promotion.
9.7.3.17. Source page 2109 of the original specification
25.5.38 — Finality-Bound Promotion
Finality-Bound Promotion means release of an artifact into a
consequential resource domain only after verification of protected
operation-specific authority.
25.5.39 — Boundary-Effect Receipt
A Boundary-Effect Receipt means qualified evidence identifying the
sandbox-to-resource operation and its actually supported effectuation
state.
25.5.40 — Sandbox Recovery Generation
A Sandbox Recovery Generation means an authoritative generation
differentiating current sandbox authority from pre-restart or pre-
rollback state.
25.6 — INTERNAL COMPUTATION VERSUS CONSEQUENTIAL ESCAPE
A principal implementation distinguishes operations according to
their actual effectuation semantics.
The system does not classify operations solely by their programming-
language function name.
25.6.1 — Internal Computation
Examples may include:
Numerical calculation;
Temporary in-memory transformations;
Parsing a local permitted input;
Generating a candidate plan;
Preparing an uncommitted command;
Das Expires 29 April 2027 [Page 426]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Or creating a disposable sandbox-local artifact.
25.6.2 — Consequential Escape
Examples may include:
Transmitting data to an external recipient;
Mutating an enterprise database;
Publishing an artifact;
9.7.3.18. Source page 2110 of the original specification
Sending an authenticated API request;
Committing persistent shared memory;
Issuing a payment;
Changing production configuration;
Activating a physical device;
Or releasing information outside its permitted protection domain.
25.6.3 — Mixed Operation
A tool may perform internal computation and external effects within
one invocation.
The protected controller may split the operation into effect-specific
suboperations or require a qualified combined authority envelope.
25.6.4 — Classification Does Not Itself Grant Permission
A label indicating that an operation is low-risk or within a
particular class does not independently authorize it.
The actual protected source authority must support the effect.
25.7 — PROTECTED SANDBOX EXECUTION RECORD
A representative structure may comprise:
PROTECTED_SANDBOX_EXECUTION_RECORD = { sandbox_identifier,
task_identifier, originating_principal, runtime_identity,
sandbox_generation, isolation_profile_digest,
Das Expires 29 April 2027 [Page 427]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
permitted_internal_resources, permitted_tool_classes,
permitted_effectuation_paths, current_privilege_generation,
current_tool_contract_generation, current_coverage_generation,
inherited_authority_inventory, current_source_authority_reference,
protected_authentication }
9.7.3.19. Source page 2111 of the original specification
The record may be maintained in a protected service outside the
direct control of the requesting workload.
25.7.1 — Runtime Identity
The system identifies the execution instance relevant to the
operation.
25.7.2 — Configuration Evidence
The protected controller obtains evidence of applicable isolation
configuration.
25.7.3 — Authority Inventory
Relevant inherited credentials, descriptors, and connections may be
qualified.
25.7.4 — Current Generation
A material restart or reconfiguration may create a new runtime or
authority generation.
25.8 — EFFECTUATION SURFACE ENUMERATION
The protected system may identify effect-capable interfaces
accessible directly or indirectly from the sandbox.
Illustrative surfaces include:
Filesystem mutation;
Network transmission;
IPC requests;
Credential broker calls;
Database writes;
Das Expires 29 April 2027 [Page 428]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Object-store commits;
Payment dispatch;
Persistent application state;
Cloud resource creation;
Source-code deployment;
Remote command execution;
9.7.3.20. Source page 2112 of the original specification
Device control;
GPU or accelerator egress;
Shared memory publication;
Vector-database commits;
Rendering or user-interface actuation;
And additional resource-specific effect paths.
25.8.1 — Direct Surface
The sandbox itself can invoke a consequential primitive.
25.8.2 — Delegated Surface
The sandbox invokes a broker, service, or worker that performs the
primitive.
25.8.3 — Delayed Surface
A sandbox-generated artifact is later consumed by an external
effectuation service.
25.8.4 — Hidden Surface
A tool may produce effects not adequately represented by its declared
contract.
25.8.5 — Coverage Requirement
Das Expires 29 April 2027 [Page 429]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The protection claim extends only to the covered surfaces that are
actually enforceable under the selected implementation.
25.9 — PROTECTED EFFECTUATION COVERAGE COMMITMENT
A protected coverage controller may maintain:
PROTECTED_EFFECTUATION_COVERAGE = { task_identifier,
sandbox_identifier, sandbox_generation, effectuation_surface_set,
mandatory_sink_mapping, qualified_broker_mapping,
direct_path_restrictions, inherited_descriptor_conditions,
network_path_conditions, tool_contract_generations,
9.7.3.21. Source page 2113 of the original specification
coverage_generation, coverage_validation_results,
protected_coverage_authentication }
25.9.1 — No Unverified Universal Coverage
A single gateway does not automatically cover every possible effect.
25.9.2 — Newly Discovered Path
A newly discovered consequential path may trigger revalidation.
25.9.3 — Runtime Change
A material sandbox or broker change may invalidate an earlier
coverage commitment.
25.9.4 — Covered Operation
A covered effect must reach a mandatory sink or an equivalent
qualified enforcement point.
25.10 — PROTECTED BOUNDARY CLASSIFICATION
A Protected Boundary Classifier may obtain:
The actual proposed tool operation;
The protected tool contract;
The current runtime identity;
The resource targeted;
Das Expires 29 April 2027 [Page 430]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The applicable resource-side effect class;
And current source authority.
The classifier may produce:
CLASS I — INTERNAL: Permitted internal computation without the
specified external consequence.
CLASS II — PREPARATORY: Generates an artifact or request that remains
non-effective until separate release.
CLASS III — CONSEQUENTIAL: Requests or initiates a protected external
or persistent effect.
9.7.3.22. Source page 2114 of the original specification
CLASS IV — PRIVILEGED CONSEQUENCE: Requires access to a protected
host or resource authority unavailable directly to the sandbox.
CLASS V — UNRESOLVED: The relevant effect semantics cannot be
sufficiently established.
A Class V operation remains withheld where the missing classification
is mandatory.
25.10.1 — Classification Limitation
The effect class may depend upon the actual resource and execution
context.
A function named read may invoke a remote application endpoint that
produces side effects.
Conversely, a command named write may update only an isolated
temporary buffer.
The protected operation semantics, not the label alone, determine the
consequential class.
25.11 — NON-EFFECTIVE HOLD AT THE ESCAPE BOUNDARY
A protected controller may hold a consequential operation using:
A withheld privileged RPC;
A protected network egress queue;
Das Expires 29 April 2027 [Page 431]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A blocked credential-use operation;
A pending database transaction;
A resource gateway;
A deployment promotion queue;
A controlled filesystem broker;
A hardware command gate;
Or another effect-capable enforcement mechanism.
The hold must actually prevent the covered consequence.
An event monitor that reports an operation after completion is not
equivalent to a blocking gate.
The protected mechanism may allow the workload to continue unrelated
permitted computation.
9.7.3.23. Source page 2115 of the original specification
25.12 — BOUNDARY-ESCAPE CANDIDATE ACT
A representative BECA-25 may comprise:
BOUNDARY_ESCAPE_CANDIDATE_ACT = { candidate_act_identifier,
originating_principal, requesting_agent, sandbox_identifier,
sandbox_generation, actual_tool_identity, tool_contract_generation,
escape_effect_class, actual_resource_reference, operation_parameters,
outgoing_content_commitment, required_privilege_class,
expected_effectuation_path, designated_finality_sink,
source_authority_generation, coverage_generation,
protected_candidate_authentication }
The BECA does not by itself confer authority.
The protected source grant, validation evidence, finality enablement,
and actual sink checks determine whether the proposed effect may be
released.
25.13 — PROTECTED PRIVILEGE TRANSITION
A legitimate task may require an operation unavailable to the
sandbox's ordinary process credentials.
Das Expires 29 April 2027 [Page 432]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The proposed architecture does not require unrestricted privilege
elevation of the agent.
Instead, the protected controller may establish a bounded privilege
transition.
25.13.1 — Privileged Broker Mode
A protected broker performs the specific operation on behalf of the
sandbox.
25.13.2 — Fresh Worker Mode
A new restricted worker is created with only the relevant operation
authority.
9.7.3.24. Source page 2116 of the original specification
25.13.3 — Hardware Gate Mode
A protected device controller enables one qualified actual command.
25.13.4 — Remote Resource Mode
A destination service validates a bounded authorization for one
operation.
25.13.5 — Protected Process Mode
A suitably isolated privileged process performs a narrowly scoped
action.
25.13.6 — No General Elevation Requirement
The original untrusted sandbox process may remain at its existing
lower privilege level.
25.14 — PRIVILEGE TRANSITION ENVELOPE
A representative PTE-25 may comprise:
PRIVILEGE_TRANSITION_ENVELOPE = { candidate_act_digest,
originating_source_grant, requesting_sandbox_identity,
allowed_privilege_operation, permitted_resource_identity,
permitted_effect_parameters, designated_privileged_broker,
designated_finality_sink, privilege_generation, maximum_use_count,
current_revocation_generation, current_coverage_generation,
protected_transition_authentication }
Das Expires 29 April 2027 [Page 433]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
25.14.1 — Operation Scope
The envelope identifies the permitted specific privileged operation.
25.14.2 — Resource Scope
The envelope identifies the target resource or qualified equivalent
resource class.
25.14.3 — Temporal or Generation Scope
The envelope is associated with current authority conditions.
9.7.3.25. Source page 2117 of the original specification
25.14.4 — Use Bound
A protected consumption reference may prevent unsupported repeated
exercise.
25.14.5 — No Privilege Inflation
The transition must not silently create unrestricted authority over
unrelated operations.
25.15 — DYNAMIC PRIVILEGE STATES
A selected implementation may maintain:
P0 — Ordinary Sandbox Computation: Only baseline permitted internal
operations.
P1 — Consequential Operation Proposed: An effect-capable operation
has been identified.
P2 — Protected Hold: The actual effect remains withheld.
P3 — Privilege Transition Requested: A bounded additional operation
capability is requested.
P4 — Source Authority Validated: The current principal permits the
proposed scope.
P5 — Independent Validation Accepted: Mandatory technical conditions
pass.
P6 — Operation-Specific Privilege Prepared: Bounded broker or worker
authority exists.
Das Expires 29 April 2027 [Page 434]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
P7 — Finality Pending: The actual resource sink has not yet committed
the operation.
P8 — Finality Consumed: Protected operation-specific authority has
been consumed.
P9 — Effect Attempted: The controlled operation has been released or
executed.
P10 — Outcome Qualified: The relevant resource outcome has been
established.
PX — Denied or Fenced: A mandatory condition failed.
These represent logical states and do not require that the lower-
trust agent process itself possess escalating operating-system
privileges.
25.16 — BOUNDED BROKER EXECUTION
A protected broker may receive a request from the sandbox.
The broker independently reconstructs:
9.7.3.26. Source page 2118 of the original specification
The actual operation;
The requested resource;
The operation parameters;
The credential or privilege required;
The original source authority;
The current sandbox identity;
And the designated Finality Sink.
The broker verifies the relevant protected finality enablement.
It then performs the authorized operation using its own protected
authority.
The broker does not grant the sandbox unrestricted use of its
privileged interface.
Das Expires 29 April 2027 [Page 435]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
25.16.1 — Confused-Deputy Protection
An otherwise authenticated sandbox request is not automatically
authorized.
25.16.2 — Current Resource Identity
The broker verifies the actual target.
25.16.3 — Consumption
The broker or receiving resource commits the applicable finality use.
25.16.4 — Outcome
The broker records what it can actually establish concerning the
resulting resource effect.
25.17 — FRESH RESTRICTED WORKER
A selected implementation may create a new worker to perform a
particular operation.
The worker may receive:
One authenticated Candidate Act reference;
An operation-specific resource handle;
A narrow authority profile;
9.7.3.27. Source page 2119 of the original specification
A protected finality reference;
And access only to the required effectuation interface.
The worker does not receive every privilege available to the host or
parent agent.
25.17.1 — Fresh Context
The worker may be created after authority verification.
25.17.2 — Resource Isolation
Unrelated filesystem, network, or credential access may be withheld.
Das Expires 29 April 2027 [Page 436]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
25.17.3 — Privilege Lifespan
The operation-specific authority terminates or becomes unusable after
the permitted effect or relevant expiry.
25.17.4 — Resource-Side Finality
The actual sink still verifies the operation where required.
25.17.5 — Technical Effect
A higher-privilege technical operation may be performed without
persistently increasing the untrusted agent's general ambient
privileges.
25.18 — PROTECTED OUTPUT-ARTIFACT PROMOTION
A sandbox may produce a file, source-code artifact, model
configuration, database migration, or other computational output.
Creating the artifact inside the sandbox may be permitted
computation.
Making it effective outside the sandbox may be a separate
consequential operation.
25.18.1 — Generated Artifact
The agent produces an artifact in an isolated workspace.
25.18.2 — Artifact Identity
A protected controller establishes a qualified reference to the
actual artifact.
25.18.3 — Promotion Candidate
A Candidate Act identifies the proposed destination and external
effect.
9.7.3.28. Source page 2120 of the original specification
25.18.4 — Protected Validation
The promotion controller checks current source authority and relevant
resource conditions.
25.18.5 — Finality Sink
Das Expires 29 April 2027 [Page 437]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The deployment or storage destination verifies the actual artifact
and target.
25.18.6 — Protected Release
Only the qualified artifact is committed, deployed, published, or
otherwise promoted.
25.18.7 — Technical Effect
Permission to generate code or files does not independently become
permission to deploy, publish, or persist them into unrelated
protected resources.
25.19 — PROMOTION OF SOURCE-CODE ARTIFACTS
A software-development agent may compile code inside a sandbox.
The build may succeed.
The resulting executable may be technically valid.
However, production deployment is a separate consequential effect.
A protected promotion sink may verify:
The actual artifact identity;
The authorized repository or package;
The permitted deployment environment;
The current source grant;
Required test or review evidence where selected;
And the scoped deployment finality enablement.
An agent-generated assertion that the code is safe does not
independently create deployment authority.
A prior compile result is not automatically a qualified deployment
authorization.
9.7.3.29. Source page 2121 of the original specification
25.20 — SANDBOX-TO-FILESYSTEM EFFECT
Das Expires 29 April 2027 [Page 438]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A sandboxed agent may prepare a modification to a protected file.
The actual mutation may be performed through a privileged filesystem
broker.
The broker may use a current qualified object handle, namespace
reference, or equivalent authoritative resource reference.
The actual file-operation sink verifies:
The source-authorized resource;
The current actual file identity;
The mutation parameters;
The relevant version or ownership state;
The privilege-transition envelope;
And protected finality consumption.
A sandbox-generated path string is not sufficient if the actual
target can be changed through aliasing or rebinding.
25.21 — SANDBOX-TO-NETWORK EFFECT
A sandboxed agent may construct an outbound request.
The request is held at a controlled egress boundary.
The protected controller may verify:
The actual destination;
The relevant protocol;
The method;
The path or resource;
Material application parameters;
Outgoing content;
Current source authority;
Das Expires 29 April 2027 [Page 439]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.7.3.30. Source page 2122 of the original specification
And the selected credential-use conditions.
The outgoing request may be dispatched only through a qualified
broker or protected network Finality Sink.
25.21.1 — Transport-Layer Limit
A network filter that knows only an IP address cannot automatically
verify hidden application-layer transaction semantics.
25.21.2 — Application-Layer Control
A protected application gateway or receiving resource may supply the
required operation-specific verification.
25.21.3 — Redirect
A material redirect or destination change may require revalidation.
25.21.4 — Credential Use
A credential broker may exercise a reusable secret only for the
verified request.
25.22 — SANDBOX-TO-IPC EFFECT
An agent may request a privileged action through IPC.
The protected IPC service verifies:
The calling runtime identity;
The current task and authority generation;
The actual requested operation;
The protected resource identity;
The operation-specific privilege transition;
And the applicable finality enablement.
Authentication of the IPC caller is necessary in selected
arrangements but not sufficient to authorize every privileged
request.
Das Expires 29 April 2027 [Page 440]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A request may be authenticated yet materially outside the source-
authorized scope.
9.7.3.31. Source page 2123 of the original specification
25.23 — SANDBOX-TO-CREDENTIAL EFFECT
A sandbox may lack access to a reusable credential.
A protected broker may hold the credential and receive agent
requests.
The broker independently validates the actual credential-dependent
effect before exercising the credential.
The selected implementation may use:
Credential substitution;
Protected signing;
Non-exportable key use;
Decryption;
Authenticated resource dispatch;
Or another qualified credential operation.
The broker is not assumed to prove remote resource completion merely
because it successfully exercised the credential.
This variation may incorporate Embodiment 23.
25.24 — SANDBOX-TO-DATABASE EFFECT
An agent may generate a database mutation inside a sandbox.
The actual database transaction may be executed by a privileged
connector.
The protected database sink reconstructs the relevant mutation.
The sink verifies:
The current source-authorized resource;
The actual target records;
Das Expires 29 April 2027 [Page 441]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The transaction semantics;
The relevant resource version;
The required privilege;
9.7.3.32. Source page 2124 of the original specification
The current Finality-Sink authorization;
And protected consumption.
A general database connection privilege does not independently
authorize every mutation the agent can express.
25.25 — SANDBOX-TO-PERSISTENT MEMORY EFFECT
An autonomous agent may construct an update to a retrieval index,
vector database, knowledge store, or shared persistent memory.
The update may change what future computational agents retrieve or
treat as contextual information.
The protected persistence sink may verify:
The actual target collection;
The source authority;
The update class;
The protected provenance of the data where required;
The allowed persistence scope;
The current resource generation;
And operation-specific finality.
Generating an embedding in an isolated runtime is not equivalent to
authority to commit it into a shared persistent index.
25.26 — SANDBOX-TO-USER-INTERFACE EFFECT
An autonomous computer-use agent may generate mouse, keyboard, touch,
or accessibility actions.
Some actions may be purely navigational.
Das Expires 29 April 2027 [Page 442]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Others may:
Send messages;
Delete information;
9.7.3.33. Source page 2125 of the original specification
Authorize a payment;
Change an account setting;
Grant permissions;
Or create another consequential effect.
A protected interface controller may classify the intended actual
effect and require corresponding authority.
Where an application exposes a qualified resource-side API, the
system may bind the operation to that API.
Where only a graphical interface exists, the implementation must
establish sufficient actual operation and resource evidence to
support its claimed guarantee.
A screenshot or model interpretation alone does not automatically
prove the result of a consequential UI action.
25.27 — SANDBOX-TO-HARDWARE EFFECT
An agent may compute a device command within a sandbox.
The command may be delivered to a privileged device controller.
The protected command sink verifies:
The actual device identity;
The actual command;
The current source authority;
Current device ownership;
Any required safety predicates;
And scoped finality enablement.
Das Expires 29 April 2027 [Page 443]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The agent's ability to construct a valid device command does not
independently permit actuation.
Where physical completion is relevant, a qualified device-side
observation may be required.
25.28 — GPU AND ACCELERATOR EGRESS
9.7.3.34. Source page 2126 of the original specification
A sandboxed workload may use a graphics processor, accelerator, or
other hardware compute device.
The computation may produce outputs that later affect:
Host memory;
Persistent files;
External resources;
Protected device buffers;
Model weights;
Shared memory;
Or other consequential state.
The relevant architecture identifies which transfers or commits are
effect-capable.
A protected controller may govern the transition from internal
accelerator computation to a protected output or resource commit.
The implementation must not assume that a generic process sandbox
controls every hardware egress route without an appropriate verified
enforcement mechanism.
25.29 — PRIVILEGE TRANSITION WITHOUT SOURCE-SCOPE EXPANSION
A protected privilege transition may provide the technical capability
necessary for an already authorized operation.
For example, a task may authorize writing one specified enterprise
report into a protected folder.
The sandbox itself lacks write access.
Das Expires 29 April 2027 [Page 444]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A host-side broker may possess the required filesystem privilege.
A valid transition permits the broker to write the specified report
to the designated resource.
The transition does not grant the agent general permission to write
other protected folders.
25.29.1 — Technical Distinction
Technical privilege and originating source authority are separate.
9.7.3.35. Source page 2127 of the original specification
An increase in available technical capability is not automatically an
increase in permitted consequential effect scope.
25.30 — PRIVILEGE TRANSITION REQUIRING NEW SOURCE AUTHORITY
A task may request an operation outside the original permitted effect
envelope.
A privileged broker may technically be able to perform it.
However, technical capability does not supply the missing principal
authorization.
The protected controller may activate a scope-deviation latch under
CW-3.
A qualified principal may authorize a bounded new operation where
permitted.
The protected privilege-transition controller then evaluates the
corresponding current technical and resource conditions.
A human approval does not independently override a mandatory sandbox
or resource-security failure.
25.31 — MATERIAL SANDBOX CONFIGURATION CHANGE
A runtime configuration may change during the task.
Examples include:
A new mount;
A newly opened network route;
Das Expires 29 April 2027 [Page 445]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A tool installation;
A new IPC endpoint;
A new inherited descriptor;
A privilege-profile change;
A new device mapping;
Or a different sandbox image.
The protected controller may compare current configuration with the
authority and coverage commitments applicable to pending Candidate
Acts.
9.7.3.36. Source page 2128 of the original specification
A material change may trigger a Sandbox Revalidation Fence.
Affected consequential operations remain withheld until the required
current evidence is established.
25.32 — PROTECTED SANDBOX REVALIDATION FENCE
A representative record comprises:
SANDBOX_REVALIDATION_FENCE = { sandbox_identifier, affected_task,
affected_candidate_acts, previous_runtime_generation,
current_runtime_generation, previous_privilege_generation,
current_privilege_generation, previous_coverage_generation,
current_coverage_generation, material_change_descriptor,
required_revalidation_modules, fence_state, protected_authentication
}
25.32.1 — Changed Tool
A materially different tool requires renewed validation where
applicable.
25.32.2 — Changed Effectuation Path
A newly reachable consequential path requires current enforcement
coverage.
25.32.3 — Changed Privilege
Das Expires 29 April 2027 [Page 446]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A privilege transition may invalidate earlier assumptions about
available operations.
25.32.4 — Protected Release
Only the qualified controller may clear the fence under the selected
authority conditions.
25.33 — INHERITED HANDLES AND OPEN CONNECTIONS
A sandbox may inherit or receive:
File descriptors;
9.7.3.37. Source page 2129 of the original specification
Open sockets;
Database connections;
Process handles;
Mapped shared memory;
Device handles;
Credential references;
Or other authority-bearing resources.
An implementation may inventory or constrain such resources when they
are relevant to the claimed effectuation coverage.
25.33.1 — Existing File Descriptor
A later path restriction does not automatically invalidate every
previously opened file handle.
25.33.2 — Existing Connection
A network restriction may not automatically revoke previously
established application authority.
25.33.3 — Shared Mapping
A writable mapping may permit effects outside a nominal tool
invocation path.
Das Expires 29 April 2027 [Page 447]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
25.33.4 — Required Mitigation
The protected architecture may close, restrict, mediate, or
independently guard the relevant effect-capable resource.
25.33.5 — Claim Qualification
A sandbox-coverage claim should not assume that a policy applies
retroactively to resource handles unless the selected implementation
actually enforces that property.
25.34 — INTERPOSITION RACE AND ACTUAL OPERATION VERIFICATION
Some syscall-supervision arrangements inspect arguments supplied by
an untrusted process.
The process or another actor may modify the referenced memory after
inspection.
A protection mechanism relying merely on permission to continue the
original mutable syscall may therefore be insufficient for a strong
actual-operation guarantee.
9.7.3.38. Source page 2130 of the original specification
A selected safer implementation may:
Perform the operation directly in the protected broker;
Use an immutable protected operation representation;
Use a suitably qualified kernel-enforced resource restriction;
Obtain a stable authoritative resource handle;
Or require independent verification at the actual destination.
25.34.1 — Technical Distinction
Observing a proposed syscall is not necessarily equivalent to
controlling the real resource operation that ultimately occurs.
25.34.2 — No Unsupported Security Claim
The system must not claim that an interception facility prevents all
time-of-check/time-of-use attacks when the facility's actual argument
and execution semantics do not support that assurance.
Das Expires 29 April 2027 [Page 448]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
25.35 — PROTECTED FINALITY ENABLEMENT
A representative sandbox-bound finality record comprises:
SANDBOX_BOUND_FINALITY_ENABLEMENT = { candidate_act_digest,
originating_source_authority, sandbox_runtime_identity,
sandbox_generation, tool_identity, tool_contract_generation,
actual_effect_descriptor, required_privilege_transition,
privilege_transition_commitment, current_privilege_generation,
current_coverage_generation, independent_validation_commitment,
designated_effectuation_broker, designated_finality_sink,
current_resource_generation, current_revocation_generation,
permitted_use_count, sink_local_consumption_reference,
protected_finality_authentication }
9.7.3.39. Source page 2131 of the original specification
The lower-trust agent may receive only an inert reference.
The actual sink verifies the corresponding protected record and
current operation.
A copied reference does not independently authorize a materially
different effect.
25.36 — ACTUAL FINALITY-SINK RECONSTRUCTION
The actual Finality Sink reconstructs or obtains the consequential
operation it is about to perform.
The relevant descriptor may include:
The operation class;
The real target resource;
The effective destination;
The actual method or command;
The material parameters;
The selected privileged capability;
The current resource generation;
The source-authority reference;
Das Expires 29 April 2027 [Page 449]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
And the actual effectuation path.
25.36.1 — Broker as Sink
A protected broker may be the actual sink for a local privileged
mutation.
25.36.2 — Destination as Sink
A remote resource server may independently enforce the actual effect.
25.36.3 — Two Boundaries
A credential or dispatch broker and the destination may each control
different consequential transitions.
25.36.4 — Actual Equality
The sink verifies that the actual effect corresponds to the
authorized Candidate Act.
9.7.3.40. Source page 2132 of the original specification
25.36.5 — Current State
The sink verifies applicable resource, privilege, revocation, and
consumption conditions.
25.37 — PROTECTED CONSUMPTION AND OUTCOME
The applicable protected authority may be consumed before release of
a consequential primitive.
A local transaction may support atomic consumption and mutation.
An external network or physical operation may not share one atomic
transaction with the local authority ledger.
A selected implementation therefore distinguishes:
Finality authority prepared;
Finality authority consumed;
Privileged operation attempted;
Request dispatched;
Das Expires 29 April 2027 [Page 450]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Resource operation accepted;
Actual effect completed;
And outcome indeterminate.
A failed acknowledgement does not automatically prove that the
privileged operation did not produce an effect.
25.38 — REFERENCE ALGORITHM: SANDBOX BOUNDARY CLASSIFICATION
FUNCTION CLASSIFY_SANDBOX_OPERATION( sandbox_runtime,
proposed_tool_operation, protected_boundary_controller ): REQUIRE
VERIFY_CURRENT_SANDBOX_IDENTITY( sandbox_runtime ) REQUIRE
VERIFY_CURRENT_ISOLATION_PROFILE()
9.7.3.41. Source page 2133 of the original specification
tool_contract = LOAD_PROTECTED_TOOL_EXECUTION_CONTRACT(
proposed_tool_operation.tool ) REQUIRE VERIFY_TOOL_CONTRACT_CURRENT(
tool_contract ) actual_effects =
DERIVE_QUALIFIED_TOOL_EFFECT_CLASSES( proposed_tool_operation,
tool_contract ) IF actual_effects == UNRESOLVED: RETURN
HOLD_FOR_QUALIFICATION IF
ALL_EFFECTS_ARE_PERMITTED_INTERNAL_COMPUTATION( actual_effects ):
RETURN ALLOW_INTERNAL_COMPUTATION candidate =
BUILD_BOUNDARY_ESCAPE_CANDIDATE_ACT({ sandbox:
sandbox_runtime.identity, operation: proposed_tool_operation,
effects: actual_effects, current_coverage:
CURRENT_COVERAGE_GENERATION() }) REQUIRE
ENFORCE_NON_EFFECTIVE_HOLD(candidate) RETURN
PROTECTED_ESCAPE_CANDIDATE(candidate)
The classifier does not independently establish source permission for
the proposed consequence.
25.39 — REFERENCE ALGORITHM: EFFECTUATION COVERAGE
FUNCTION VERIFY_ESCAPING_EFFECT_COVERAGE(
9.7.3.42. Source page 2134 of the original specification
candidate_act, protected_coverage_controller ): coverage =
protected_coverage_controller .LOAD_CURRENT_EFFECTUATION_COVERAGE()
REQUIRE VERIFY_COVERAGE_AUTHENTICITY( coverage ) REQUIRE
VERIFY_SANDBOX_GENERATION_CORRESPONDENCE( candidate_act, coverage )
REQUIRE VERIFY_TOOL_CONTRACT_GENERATION( candidate_act, coverage )
required_sinks = RESOLVE_REQUIRED_EFFECTUATION_SINKS( candidate_act )
Das Expires 29 April 2027 [Page 451]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
FOR EACH sink IN required_sinks: REQUIRE
VERIFY_SINK_CONTROLS_ACTUAL_EFFECT( sink ) REQUIRE
VERIFY_PATH_REACHES_PROTECTED_SINK( candidate_act, sink ) REQUIRE
VERIFY_NO_KNOWN_UNCONTROLLED_COVERED_ROUTE() RETURN
COVERAGE_COMMITMENT( candidate_act, coverage )
The guarantee applies to the verified coverage domain.
25.40 — REFERENCE ALGORITHM: PRIVILEGE TRANSITION
9.7.3.43. Source page 2135 of the original specification
FUNCTION AUTHORIZE_PROTECTED_PRIVILEGE_TRANSITION( candidate_act,
requested_privilege, protected_transition_controller ): REQUIRE
VERIFY_CURRENT_ORIGINATING_AUTHORITY() REQUIRE
VERIFY_ACTUAL_EFFECT_WITHIN_SOURCE_SCOPE( candidate_act ) REQUIRE
VERIFY_CURRENT_SANDBOX_IDENTITY() REQUIRE
VERIFY_CURRENT_TOOL_AND_PRIVILEGE_GENERATIONS() REQUIRE
VERIFY_REQUIRED_EFFECTUATION_COVERAGE() REQUIRE
VERIFY_REQUESTED_PRIVILEGE_NECESSARY_AND_BOUNDED(
requested_privilege, candidate_act ) transition =
protected_transition_controller .PREPARE_OPERATION_BOUND_TRANSITION({
candidate: candidate_act, permitted_privilege: requested_privilege,
permitted_resource: candidate_act.actual_resource,
permitted_operation: candidate_act.effect, permitted_uses: 1,
designated_broker: RESOLVE_QUALIFIED_PRIVILEGED_BROKER() }) REQUIRE
VERIFY_TRANSITION_NOT_BROADER_THAN_AUTHORITY( transition ) RETURN
PROTECTED_TRANSITION_REFERENCE( transition
9.7.3.44. Source page 2136 of the original specification
The transition may enable a qualified broker without elevating the
general privileges of the original agent.
25.41 — REFERENCE ALGORITHM: FINALITY-BOUND BROKER EXECUTION
Das Expires 29 April 2027 [Page 452]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
FUNCTION EXECUTE_ESCAPING_EFFECT_WITH_FINALITY( candidate_act,
transition_reference, finality_enablement, protected_broker ): actual
= protected_broker.RECONSTRUCT_ACTUAL_PENDING_OPERATION() REQUIRE
VERIFY_ACTUAL_OPERATION_QUALIFIED(actual) REQUIRE
VERIFY_ORIGINATING_AUTHORITY_CURRENT() REQUIRE
VERIFY_CURRENT_SANDBOX_AND_TOOL_GENERATIONS() REQUIRE
VERIFY_CURRENT_PRIVILEGE_TRANSITION( transition_reference, actual )
REQUIRE VERIFY_CURRENT_EFFECTUATION_COVERAGE() REQUIRE
VERIFY_ACTUAL_RESOURCE_IDENTITY(actual) REQUIRE
VERIFY_ACTUAL_EFFECT_WITHIN_CANDIDATE_ENVELOPE( actual, candidate_act
) REQUIRE VERIFY_CURRENT_RESOURCE_AND_REVOCATION_STATE() REQUIRE
VERIFY_NON_BEARER_FINALITY( finality_enablement, actual ) REQUIRE
VERIFY_SINK_LOCAL_CONSUMPTION() committed = protected_broker
.COMMIT_OPERATION_SPECIFIC_FINALITY(
9.7.3.45. Source page 2137 of the original specification
finality_enablement, actual ) IF committed != COMMITTED: RETURN DENY
outcome = protected_broker .PERFORM_CONTROLLED_ACTUAL_EFFECT(actual)
RECORD_ATTEMPT_AND_SUPPORTED_OUTCOME(outcome) RETURN
CLASSIFY_QUALIFIED_RESULT(outcome)
Where the broker merely dispatches to a separate external resource,
the result is limited to the effect that the broker can establish.
25.42 — REFERENCE ALGORITHM: ARTIFACT PROMOTION
FUNCTION PROMOTE_SANDBOX_ARTIFACT( sandbox_artifact,
intended_destination, protected_promotion_sink ): artifact_identity =
QUALIFY_CURRENT_ARTIFACT_IDENTITY( sandbox_artifact ) candidate =
CONSTRUCT_PROMOTION_CANDIDATE_ACT({ artifact: artifact_identity,
destination: intended_destination, effect_class:
EXTERNAL_ARTIFACT_PROMOTION }) REQUIRE
ENFORCE_NON_EFFECTIVE_HOLD(candidate) REQUIRE
VERIFY_CURRENT_SOURCE_AUTHORITY() REQUIRE
VERIFY_ARTIFACT_AND_DESTINATION_CORRESPONDENCE() REQUIRE
VERIFY_REQUIRED_ARTIFACT_VALIDATION_EVIDENCE()
9.7.3.46. Source page 2138 of the original specification
REQUIRE VERIFY_CURRENT_PROMOTION_SINK() finality =
PREPARE_SCOPED_NON_BEARER_FINALITY(candidate) actual =
protected_promotion_sink .RECONSTRUCT_ACTUAL_PROMOTION_OPERATION()
REQUIRE VERIFY_ACTUAL_ARTIFACT(actual) REQUIRE
VERIFY_ACTUAL_DESTINATION(actual) REQUIRE
VERIFY_FINALITY_AND_CONSUMPTION( finality, actual ) RETURN
protected_promotion_sink .COMMIT_AUTHORIZED_PROMOTION( actual,
finality )
Das Expires 29 April 2027 [Page 453]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A successful build inside a sandbox does not automatically authorize
production deployment.
25.43 — REFERENCE ALGORITHM: MATERIAL RUNTIME CHANGE
FUNCTION HANDLE_SANDBOX_RUNTIME_CHANGE( prior_runtime_state,
current_runtime_state, protected_controller ): REQUIRE
VERIFY_CURRENT_RUNTIME_STATE_AUTHENTICITY() difference =
COMPARE_MATERIAL_SANDBOX_AND_EFFECTUATION_PROPERTIES(
prior_runtime_state, current_runtime_state ) IF difference ==
NO_MATERIAL_CHANGE: RETURN REQUIRE_CURRENT_SINK_VERIFICATION affected
= IDENTIFY_PENDING_OPERATIONS_DEPENDENT_ON_CHANGED_STATE()
9.7.3.47. Source page 2139 of the original specification
ACTIVATE_SANDBOX_REVALIDATION_FENCE(affected)
INVALIDATE_AFFECTED_PENDING_FINALITY(affected) IF
NEW_EFFECTUATION_PATH_IS_UNCONTROLLED(): RETURN
WITHHOLD_COVERED_CONSEQUENCES IF
NEW_PRIVILEGE_SCOPE_EXCEEDS_SOURCE_AUTHORITY(): RETURN
REQUIRE_NEW_SOURCE_AUTHORITY RETURN
REQUIRE_CURRENT_VALIDATION_AND_COVERAGE()
The controller may preserve unrelated operations that do not depend
upon the changed conditions.
25.44 — REFERENCE ALGORITHM: CRASH RECOVERY
FUNCTION RECOVER_SANDBOX_EFFECTUATION( logical_operation,
protected_journal, qualified_resource_observer ): record =
protected_journal .LOAD_AUTHORITATIVE_FINALITY_STATE(
logical_operation ) REQUIRE VERIFY_JOURNAL_AUTHENTICITY(record)
REQUIRE VERIFY_CURRENT_SOURCE_AND_SANDBOX_GENERATIONS() IF
QUALIFIED_ACTUAL_EFFECT_CONFIRMED(record): RETURN EFFECT_CONFIRMED IF
QUALIFIED_NON_EFFECT_CONFIRMED(record): RETURN
APPLY_AUTHORIZED_NON_EFFECT_RESOLUTION() observed =
qualified_resource_observer
.QUERY_ACTUAL_OPERATION_STATE(logical_operation) IF
VERIFY_QUALIFIED_EFFECT(observed): RETURN
COMMIT_CONFIRMED_OUTCOME(observed) IF
VERIFY_QUALIFIED_NON_EFFECT(observed): RETURN
COMMIT_NON_EFFECT_OUTCOME(observed) RETURN
PRESERVE_INDETERMINATE_EFFECT_STATE()
9.7.3.48. Source page 2140 of the original specification
A sandbox crash is not proof that an earlier external operation did
not occur.
Das Expires 29 April 2027 [Page 454]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
25.45 — WORKED EXAMPLE A: SANDBOXED SOFTWARE AGENT AND HOST FILE
An autonomous agent generates a proposed modification to a protected
host configuration file.
The agent operates inside an isolated process environment and lacks
direct write permission.
A privileged host helper possesses the required technical filesystem
access.
The agent submits the proposed mutation to the helper.
The protected controller constructs a Candidate Act identifying the
actual target and modification.
The helper verifies current source authority and the protected
finality reference.
The helper reconstructs the actual file operation and checks resource
identity.
Only the bounded authorized modification is performed.
Expected demonstrable result: Access to a privileged host helper does
not grant an isolated agent unrestricted host-file modification
authority.
25.46 — WORKED EXAMPLE B: SANDBOXED NETWORK EGRESS
An agent prepares a network request inside a sandbox.
The agent is authorized to contact one designated enterprise service.
The actual request is routed through a controlled gateway.
The request's destination is changed after preparation.
The protected gateway verifies the current actual destination and
operation.
The destination does not satisfy the permitted effect envelope.
The request is refused.
Expected demonstrable result: Sandbox network access does not
independently authorize an externally consequential request to a
different resource.
Das Expires 29 April 2027 [Page 455]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.7.3.49. Source page 2141 of the original specification
25.47 — WORKED EXAMPLE C: CREDENTIAL BROKER
An isolated agent is allowed to create one cloud resource.
A host-side broker possesses a reusable service credential.
The agent requests creation of several unrelated resources.
The broker independently identifies the actual operation and compares
it with the current source-authorized Candidate Act.
Only the permitted operation may receive credential-use finality.
Expected demonstrable result: Secret isolation combined with actual-
operation finality prevents broader credential authority from being
exercised merely through access to the broker interface.
25.48 — WORKED EXAMPLE D: CODE BUILD AND PRODUCTION DEPLOYMENT
A software agent compiles an artifact inside a sandbox.
The artifact builds successfully.
The agent requests production deployment.
The deployment is classified as a separate consequential boundary
escape.
The protected promotion sink verifies the current approved artifact,
target environment, and source authority.
The deployment is refused if the original task permitted building but
not production release.
Expected demonstrable result: Permission to generate or compile an
artifact is distinct from permission to make it effective in a
protected production environment.
25.49 — WORKED EXAMPLE E: DATABASE CONNECTOR
A sandboxed agent is authorized to read selected database records.
A privileged database connector possesses broader credentials.
The agent requests deletion of an unrelated record.
Das Expires 29 April 2027 [Page 456]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The connector reconstructs the actual database operation.
9.7.3.50. Source page 2142 of the original specification
Current source permission does not cover the deletion.
The resource-side mutation is refused.
Expected demonstrable result: Access to a database connector does not
automatically authorize all resource mutations technically permitted
by the connector's credentials.
25.50 — WORKED EXAMPLE F: DYNAMIC PRIVILEGE TRANSITION
An agent is authorized to install a selected approved configuration
file into one protected system directory.
The sandbox cannot directly perform the installation.
Instead of elevating the entire agent process, the controller creates
a narrow protected broker operation.
The broker receives authority to install only the specified artifact
at the authorized destination.
After the operation, the scoped authority is consumed.
The original agent retains its lower privileges.
Expected demonstrable result: A legitimate privileged operation is
completed without converting the autonomous workload into a generally
privileged process.
25.51 — WORKED EXAMPLE G: CHANGED TOOL IMPLEMENTATION
An agent prepares a tool call under a contract that permits temporary
file creation.
The tool is updated so that its operation additionally publishes the
file into shared persistent storage.
The protected controller detects a material tool-effect generation
change.
Pending finality based on the earlier contract is invalidated.
The new publication effect requires current protected authorization.
Das Expires 29 April 2027 [Page 457]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Expected demonstrable result: A stable tool name does not preserve
authorization after a material consequential tool change.
25.52 — WORKED EXAMPLE H: PRE-OPENED RESOURCE HANDLE
9.7.3.51. Source page 2143 of the original specification
A sandboxed worker inherits a writable file descriptor associated
with a protected host resource.
A later path restriction blocks new access by filename.
The inherited descriptor may still represent relevant effect-capable
authority.
The protected sandbox setup or resource controller identifies and
constrains the descriptor.
The protected file sink enforces current operation authority for the
covered mutation.
Expected demonstrable result: The sandbox's claimed enforcement
coverage accounts for authority-bearing inherited resources rather
than assuming that a new path policy retroactively invalidates every
previously opened handle.
25.53 — WORKED EXAMPLE I: SANDBOX RESTART
An agent requests an external resource mutation.
The operation reaches the protected broker and is dispatched.
The sandbox crashes before receiving a completion message.
The sandbox restarts under a new runtime generation.
The agent attempts the same external mutation again.
The protected journal preserves the earlier attempt and finality
consumption state.
The system reconciles the possible external result before authorizing
another effect.
Expected demonstrable result: Sandbox restart does not restore
consumed authority or imply that an earlier dispatched external
effect failed.
Das Expires 29 April 2027 [Page 458]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
25.54 — WORKED EXAMPLE J: CONCURRENT SANDBOXED AGENTS
Several agents operate in independent sandboxes under one originating
grant.
The task permits one consequential resource modification.
Both agents submit the same operation through the protected broker.
The protected finality controller and actual resource sink enforce
the current single-use authority.
Only a permitted effectuation can validly consume the shared
allowance.
9.7.3.52. Source page 2144 of the original specification
Expected demonstrable result: Independent sandbox instances cannot
multiply originating consequential permission through concurrent
broker invocations.
25.55 — WORKED EXAMPLE K: SANDBOX-GENERATED PERSISTENT MEMORY
A retrieval agent generates an updated knowledge record in an
isolated workspace.
The record is intended for a shared persistent vector database.
The generation step remains internal computation.
The protected persistence sink treats the commit as a separate
consequential Candidate Act.
The sink verifies the current authorized collection, record identity,
and operation scope.
A record targeting an unauthorized shared collection is refused.
Expected demonstrable result: Generating a memory update does not
automatically confer authority to commit that update into protected
persistent shared state.
25.56 — WORKED EXAMPLE L: COMPUTER-USE AGENT
An autonomous computer-use agent navigates a webpage inside a
restricted browser environment.
Das Expires 29 April 2027 [Page 459]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The agent proposes clicking a control that would change a protected
application setting.
The protected controller identifies the corresponding consequential
operation.
Where the application provides a suitable protected resource
interface, the actual effect is verified against the source-
authorized task.
An unauthorized setting change is withheld.
Expected demonstrable result: Permission to interact with an
application interface does not automatically authorize every
consequential operation reachable through that interface.
25.57 — WORKED EXAMPLE M: HARDWARE DEVICE COMMAND
A sandboxed controller computes a command for an industrial device.
The controller itself lacks direct access to the physical command
interface.
9.7.3.53. Source page 2145 of the original specification
A privileged hardware broker receives the proposed command.
The broker verifies the actual device identity, command parameters,
current source authority, and relevant safety conditions.
The protected device sink consumes the operation-specific finality
authority.
Only the verified command is permitted.
Expected demonstrable result: Valid computation of a device command
does not independently authorize physical actuation.
25.58 — WORKED EXAMPLE N: SANDBOX-TO-SANDBOX TASK MIGRATION
An agent begins a task in one restricted execution environment.
The task is moved to another host or sandbox.
The original source grant remains bounded.
The new runtime possesses a different execution identity and coverage
generation.
Das Expires 29 April 2027 [Page 460]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The protected controller qualifies the new execution domain before
permitting covered consequential operations.
Old runtime-bound finality references do not automatically authorize
actions from the new domain.
Expected demonstrable result: Task migration does not silently
transfer unrestricted effectuation authority into a new execution
environment.
25.59 — WORKED EXAMPLE O: MULTI-STAGE ARTIFACT RELEASE
A sandboxed agent generates a report.
A protected publication service publishes the report to an authorized
storage destination.
An authorized IEV later accepts qualified evidence that the report
was actually committed.
A dependent notification operation requires that accepted receipt
under CW-2 Mode B.
The notification sink separately verifies the current message and
recipient.
Expected demonstrable result: Sandbox output generation, actual
publication, and receipt-dependent downstream notification remain
distinct protected consequential phases.
9.7.3.54. Source page 2146 of the original specification
25.60 — WORKED EXAMPLE P: PROMPT INJECTION WITH TOOL ESCAPE
An agent retrieves an external document containing instructions to
perform an unauthorized network upload.
The model follows the injected text and generates an upload tool
call.
The upload would escape the computational sandbox.
The protected boundary controller constructs a Candidate Act.
The original source authority does not authorize the disclosure.
The protected network Finality Sink refuses the upload.
Das Expires 29 April 2027 [Page 461]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Expected demonstrable result: A malicious instruction may affect the
agent's computational proposal without necessarily causing the
unauthorized real external effect.
25.61 — COMPREHENSIVE ADVERSARIAL THREAT MODEL
1. Direct sandbox breakout. 2. Privileged helper confused deputy.
3. Unrestricted host-tool invocation. 4. Credential-broker misuse.
5. Unauthorized network egress. 6. Destination rebinding. 7.
Redirect to an unauthorized resource. 8. Shared mount modification.
9. Inherited writable descriptor. 10. Pre-opened network socket.
11. Privileged IPC endpoint. 12. Unrestricted host-side connector.
13. Tool-contract replacement. 14. Dynamic plugin addition. 15.
Runtime policy change. 16. Tool permission inflation. 17. Broad
ambient privilege elevation. 18. Replayed privilege transition. 19.
Copied broker authorization reference. 20. Cross-sandbox finality
replay. 21. Unauthorized artifact promotion. 22. Production
deployment without authorization. 23. Source-code signing without
authorization. 24. Persistent memory commit. 25. Protected database
mutation. 26. Payment dispatch from a sandboxed workflow.
9.7.3.55. Source page 2147 of the original specification
27. Unqualified hardware command. 28. GPU or accelerator output
escape. 29. Browser interface effectuation. 30. Forged sandbox
attestation. 31. Stale sandbox generation. 32. Snapshot rollback.
33. Runtime restart. 34. Changed resource ownership. 35. Changed
destination resource. 36. Privilege transition after source
revocation. 37. Changed current broker role. 38. Unqualified effect
classification. 39. Hidden tool side effect. 40. Incomplete
effectuation-path coverage. 41. Monitoring-only hook mistaken for
enforcement. 42. Mutable syscall argument race. 43. Incorrect
assumption of complete syscall mediation. 44. Unsupported claim of
remote resource finality. 45. Untrusted worker modifying a request
after approval. 46. Credential insertion into a changed request. 47.
Cached authenticated session misuse. 48. Parallel agent
overconsumption. 49. Multiple sandbox instances sharing one
allowance. 50. Unresolved remote effect followed by retry. 51.
Cancellation followed by unsafe authority restoration. 52.
Unauthorized resource quota expansion. 53. Changed tool semantics
with an unchanged name. 54. Unauthenticated privileged worker. 55.
Untrusted child process inheritance. 56. Persistent background
process continuing after task termination. 57. Insufficient
revocation propagation. 58. Sandbox resource-exhaustion attack. 59.
Effect classifier denial-of-service. 60. Maliciously nested
resource-operation arguments. 61. Forged output-artifact identity.
62. Artifact substitution after validation. 63. Wrong production
deployment destination. 64. Missing mandatory resource-version
Das Expires 29 April 2027 [Page 462]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
check. 65. Human approval applied to a different actual effect. 66.
Privileged broker compromise. 67. Host operating-system compromise.
68. Uncontrolled external device interface. 69. Hidden browser or
UI side effects. 70. Incorrect classification of an irreversible
effect as internal computation.
Each security property is assessed within the protection and
enforcement assumptions of the selected implementation.
9.7.3.56. Source page 2148 of the original specification
25.62 — PROPOSED FEASIBILITY AND ADVERSARIAL EXPERIMENTS
The following are proposed tests and are not represented as executed
experiments.
Test 1 — Sandbox Identity: Establish a qualified runtime identity.
Test 2 — Isolation Profile: Authenticate selected sandbox
configuration state.
Test 3 — Internal Computation: Perform permitted computation without
unnecessary privileged resource access.
Test 4 — Consequential Classification: Identify an actual external
effect.
Test 5 — Preparatory Operation: Distinguish request preparation from
real resource release.
Test 6 — Non-Effective Hold: Verify that the effect remains withheld
before current protected authority.
Test 7 — Source Authority: Establish one bounded originating grant.
Test 8 — Unauthorized Effect: Generate a Candidate Act outside the
grant and verify denial.
Test 9 — Tool Registry: Authenticate a protected tool contract.
Test 10 — Tool-Semantics Change: Replace a tool with a materially
different implementation.
Test 11 — Runtime Generation: Change the sandbox runtime generation.
Test 12 — Coverage Generation: Modify the effectuation-path mapping.
Das Expires 29 April 2027 [Page 463]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Test 13 — Privileged Broker: Execute one authorized operation through
a protected helper.
Test 14 — Broker Confused Deputy: Request an unrelated privileged
operation.
Test 15 — Scoped Transition: Establish an operation-specific
privilege transition.
Test 16 — Ambient Privilege Inflation: Attempt to replace operation-
specific authority with general runtime elevation.
Test 17 — Fresh Worker: Create a restricted worker for one selected
operation.
Test 18 — Restricted Worker Reuse: Attempt a second unrelated effect
through the same worker.
Test 19 — Filesystem Mutation: Verify one protected actual file
operation.
Test 20 — Symbolic-Link Rebinding: Change the resource target after
validation.
9.7.3.57. Source page 2149 of the original specification
Test 21 — Database Mutation: Verify actual row identity and effect
scope.
Test 22 — Network Egress: Transmit to one source-authorized
destination.
Test 23 — Unauthorized Destination: Change the actual destination.
Test 24 — Redirect: Redirect a credentialed request to another
resource.
Test 25 — Actual HTTP Request: Verify material method, path, and body
parameters.
Test 26 — Credential Broker: Exercise a protected credential for a
bounded operation.
Test 27 — Credential Reuse: Attempt unauthorized second use.
Test 28 — IPC Authentication: Identify the calling sandbox.
Das Expires 29 April 2027 [Page 464]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Test 29 — IPC Effect Scope: Reject a request outside its permitted
operation envelope.
Test 30 — Inherited Descriptor: Supply a pre-opened resource handle
to the sandbox.
Test 31 — Existing Connection: Test enforcement over previously
established effect-capable sessions.
Test 32 — Shared Mount: Attempt persistent effects through a mounted
resource.
Test 33 — Output Artifact: Generate a local sandbox artifact.
Test 34 — Output Promotion: Promote only an authorized artifact to a
selected resource.
Test 35 — Artifact Substitution: Change the artifact between
validation and promotion.
Test 36 — Production Deployment: Distinguish compilation from
authorized deployment.
Test 37 — Persistent Memory: Attempt a vector-database or shared-
memory commit.
Test 38 — Computer-Use Interface: Identify a consequential UI
operation.
Test 39 — Hardware Actuation: Verify actual device command
authorization.
Test 40 — GPU Egress: Verify the selected accelerator-to-resource
effectuation path.
Test 41 — Alternative Resource Route: Attempt the same effect through
another interface.
Test 42 — Coverage Verification: Reject unsupported assumptions of
complete effect mediation.
Test 43 — Monitoring-Only Component: Demonstrate the difference
between observing an event and blocking the actual effect.
9.7.3.58. Source page 2150 of the original specification
Test 44 — Mutable Arguments: Change syscall or operation data after a
supervisor inspection.
Das Expires 29 April 2027 [Page 465]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Test 45 — Broker-Owned Operation: Test protected execution using
stable broker-controlled parameters.
Test 46 — Current Revocation: Revoke source authority after initial
Candidate Act validation.
Test 47 — Privilege Generation: Invalidate an old privilege
transition.
Test 48 — Sandbox Restart: Restart the sandbox after preparing an
operation.
Test 49 — Crash After Dispatch: Preserve unresolved external
operation state.
Test 50 — Snapshot Rollback: Reject restoration of previously
consumed finality authority.
Test 51 — Cross-Sandbox Migration: Move the task to a new qualified
execution domain.
Test 52 — Parallel Agents: Race two sandboxed agents against one
finality allowance.
Test 53 — Cumulative Budget: Enforce resource-specific limits across
sandbox boundaries.
Test 54 — CW-2 Causal Dependency: Require an accepted prior actual-
effect receipt for a specified successor.
Test 55 — CW-3 Scope Deviation: Require new bounded authorization for
a newly proposed consequential scope.
Test 56 — Prompt Injection: Cause a model to generate an unauthorized
tool action and verify actual effect denial.
Test 57 — Authorized Prompt-Derived Data: Permit valid parameter
extraction without granting new authority.
Test 58 — Runtime Tool Addition: Add a new effect-capable tool and
verify coverage revalidation.
Test 59 — Resource Ownership Change: Invalidate a stale resource-
specific finality reference.
Test 60 — No General Privilege Elevation: Complete an authorized
privileged operation while leaving the agent's baseline privileges
unchanged.
Das Expires 29 April 2027 [Page 466]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Test 61 — Removal of Sandbox Confinement: Compare exposure when the
agent has unrestricted direct resource access.
Test 62 — Removal of Operation-Specific Finality: Compare effects
under a sandbox and privileged broker with no separate protected
Candidate Act verification.
9.7.3.59. Source page 2151 of the original specification
Test 63 — Removal of Sink Reconstruction: Compare changed actual
operations against upstream-only approval.
Test 64 — Removal of Privilege-Generation Verification: Attempt use
of stale authority after a runtime privilege change.
Test 65 — Removal of Coverage Enforcement: Exercise an alternative
effectuation path.
Test 66 — Removal of Protected Consumption: Attempt repeated use of
one finality reference.
Test 67 — Removal of Output-Promotion Gate: Test whether an isolated
generated artifact reaches production without independent
authorization.
Test 68 — Qualified Outcome: Distinguish dispatched requests from
actually completed resource effects.
Test 69 — Failure Injection: Induce broker and agent crashes at
different effectuation states.
Test 70 — Full Integrated Workflow: Combine sandboxed computation,
protected privilege transition, credential use, artifact promotion,
runtime changes, actual sink verification, finality consumption, and
qualified outcome reconciliation.
25.62.1 — Experimental Metrics
The tests may measure:
Unauthorized actual resource effects;
Successfully blocked effect attempts;
Effectuation-path coverage;
Current authority correspondence;
Das Expires 29 April 2027 [Page 467]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Privilege exposure duration;
Number of ambient privileges available to the agent;
Operation-specific broker authorization accuracy;
Replay resistance;
Crash-recovery correctness;
Runtime change invalidation;
And performance overhead.
9.7.3.60. Source page 2152 of the original specification
25.62.2 — Comparative Technical Evidence
A useful comparison may involve:
A sandbox alone;
A sandbox with a general privileged tool broker;
And a sandbox with protected Candidate Acts, scoped privilege
transitions, independent actual-operation verification, and Finality-
Sink consumption.
The experiment should determine whether the same unauthorized
consequential operation remains executable through the available
broker or external resource paths.
25.62.3 — Experimental Qualification
A successful blocked request is evidence concerning the tested
enforcement path.
It is not automatically evidence of complete system-wide protection
against all possible unobserved interfaces.
25.63 — NON-LIMITING PHOSITA REFERENCE PROTOTYPE
25.63.1 — Minimum Prototype Components
A PHOSITA may use:
An isolated agent process;
Das Expires 29 April 2027 [Page 468]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A restricted execution environment;
A protected tool-broker service;
A transactional authority database;
A source-authority registry;
A finality-reference registry;
And a controlled test-resource server.
25.63.2 — Original Task
The principal authorizes creation of one specified file in a
protected destination.
25.63.3 — Sandbox
The agent operates without direct permission to modify the protected
destination.
9.7.3.61. Source page 2153 of the original specification
25.63.4 — Local Computation
The agent creates the file content inside its isolated workspace.
25.63.5 — Proposed Escape
The agent requests publication of the file into the protected
destination.
25.63.6 — Candidate Act
The protected controller identifies the actual file-promotion effect.
25.63.7 — Source Validation
The controller confirms the permitted resource, filename, operation
type, and current authority.
25.63.8 — Privilege Transition
A protected broker receives permission for the designated operation
only.
25.63.9 — Finality
Das Expires 29 April 2027 [Page 469]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The destination resource sink verifies the current actual file and
target.
25.63.10 — Consumption
The operation-specific finality enablement is consumed.
25.63.11 — Authorized Result
The permitted artifact is published.
25.63.12 — Adversarial Variation
The agent attempts publication into another protected destination.
25.63.13 — Expected Result
The unauthorized effect is refused.
25.63.14 — Replay Variation
The agent repeats the same protected reference to attempt another
publication.
25.63.15 — Expected Result
The protected single-use authority prevents the unauthorized
additional operation.
25.63.16 — Runtime Change Variation
9.7.3.62. Source page 2154 of the original specification
The broker or tool configuration changes materially.
25.63.17 — Expected Result
The affected pending finality is revalidated or withheld according to
current protected policy.
25.64 — OPTIONAL ADVANCED IMPLEMENTATION VARIATIONS
25.64.1 — Operating-System Sandbox
A process is restricted by kernel-enforced resource policies.
25.64.2 — Container Sandbox
Das Expires 29 April 2027 [Page 470]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
An autonomous runtime operates inside a constrained container.
25.64.3 — Micro-Virtual-Machine Sandbox
An agent executes within a restricted virtual-machine environment.
25.64.4 — WebAssembly Sandbox
A constrained runtime exposes only qualified host functions.
25.64.5 — Privileged Host Broker
A host service performs selected protected resource operations.
25.64.6 — Remote Agent Worker
A separate remote environment executes bounded computational tasks.
25.64.7 — Credential-Broker Integration
Credential-dependent effects are independently validated.
25.64.8 — File Promotion
Sandbox artifacts are published through a protected filesystem or
storage sink.
25.64.9 — Deployment Promotion
Generated artifacts are deployed through a qualified release sink.
25.64.10 — Network Egress Finality
Actual outgoing requests are verified at a controlled network or
resource boundary.
9.7.3.63. Source page 2155 of the original specification
25.64.11 — Database Mutation Finality
Actual database operations are independently verified at commit.
25.64.12 — Persistent Memory Finality
Model-generated memory updates are controlled at the persistent
store.
25.64.13 — Screen-State Finality
Das Expires 29 April 2027 [Page 471]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Computer-use actions are evaluated against protected actual
application effects.
25.64.14 — Hardware Command Finality
Device-side controllers verify current command authority.
25.64.15 — Accelerator Egress Finality
Relevant accelerator output effects are mediated through protected
interfaces.
25.64.16 — Dynamic Privilege Transition
A bounded higher-privilege operation is provided without general
agent elevation.
25.64.17 — Runtime Coverage Revalidation
A material change to the sandbox or tool environment invalidates
dependent finality.
25.64.18 — Cross-Domain Effectuation
A remote resource domain independently verifies the actual
consequential effect.
25.64.19 — Receipt-Dependent Continuation
A specified later operation may require an accepted earlier actual-
effect receipt under CW-2.
25.64.20 — Protected Scope Expansion
A genuine new effect scope may require reauthorization under CW-3.
These variations may be used independently or in compatible
combinations.
25.65 — PROPOSED INVENTIVE-STEP CHARACTERIZATION
25.65.1 — Existing Technical Foundations
Das Expires 29 April 2027 [Page 472]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
9.7.3.64. Source page 2156 of the original specification
Existing technologies provide process isolation, container
restriction, virtual machines, operating-system access control,
privileged brokers, network proxies, credential vaults, resource
quotas, and tool-execution policies.
The present embodiment may use such mechanisms.
25.65.2 — Candidate Objective Technical Problem
How to maintain a technically enforceable separation between lower-
trust autonomous computation inside a restricted execution domain and
the authority to cause consequential effects through external
resource interfaces, including dynamically changing privileged tool
and effectuation paths.
25.65.3 — Proposed Technical Solution
The autonomous workload executes inside a qualified Sandbox Execution
Domain.
A protected boundary classifier identifies proposed consequential
operations escaping the isolated computational envelope.
Such operations become non-effective Candidate Acts.
A protected controller verifies current original source authority and
the applicable effectuation-path coverage.
Where privileged access is needed, a bounded privilege transition is
prepared for the specific operation rather than implicitly granting
the agent unrestricted authority.
A separate non-bearer finality enablement is established.
The actual Finality Sink independently reconstructs the pending
resource effect and verifies current authority, privilege, resource,
coverage, and consumption state.
Only then may the operation produce the covered consequence.
25.65.4 — Not Merely a Sandbox
A sandbox restricts the computational environment.
Das Expires 29 April 2027 [Page 473]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The selected stronger combination separately governs effects escaping
that environment through brokers, output promotion, remote resources,
or privileged services.
25.65.5 — Not Merely a Tool Allowlist
A tool allowlist identifies permitted tool interfaces.
The proposed system verifies the actual consequential operation
performed through the tool.
25.65.6 — Not Merely a Privileged Broker
9.7.3.65. Source page 2157 of the original specification
A broker can perform operations unavailable to the sandbox.
The proposed stronger combination requires the broker's exercise of
authority to remain bound to independently validated current effect
scope and protected consumption.
25.65.7 — Not Merely Dynamic Permission
A dynamic permission system may grant or revoke process privileges.
The proposed arrangement establishes a specific bounded privilege-to-
effect relationship that need not elevate the original agent's
ambient authority.
25.65.8 — Not Merely Kernel Monitoring
A monitor can report activity.
The proposed system requires actual withholding and release under
current protected authority.
25.65.9 — Not Merely Human Approval
A human approval may be tied to a selected operation.
The actual effectuation sink independently verifies the operation and
applicable mandatory technical conditions.
25.65.10 — Candidate Narrow Inventive Kernel
A protected autonomous tool-execution system comprising a restricted
Sandbox Execution Domain, a protected classifier identifying a
consequential operation crossing the sandbox's permitted
Das Expires 29 April 2027 [Page 474]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
computational boundary, an enforceable Non-Effective State, an
operation-specific privilege-transition controller, an authenticated
effectuation-coverage commitment, a scoped non-bearer finality
enablement, and an independently enforcing Finality Sink configured
to reconstruct the actual pending resource effect and consume current
protected authority only after verifying operation correspondence,
originating permission, privilege generation, resource state, and
mandatory effectuation coverage.
25.65.11 — Privilege-Transition Kernel
A narrower candidate may require that a higher-privilege operation be
executed by a qualified broker or fresh restricted worker without
conferring generally reusable elevated privileges upon the requesting
sandbox.
25.65.12 — Output-Promotion Kernel
Another candidate may require a sandbox-generated artifact to remain
computationally inert with respect to a protected external
destination until an independent output-promotion Finality Sink
verifies current authority and the actual artifact.
9.7.3.66. Source page 2158 of the original specification
25.65.13 — Coverage-Generation Kernel
Another candidate may require invalidation of pending finality
following a material change in the sandbox runtime, privileged tool
contract, inherited authority, or effectuation-path coverage.
25.65.14 — Actual Interposition Kernel
Another candidate may require that a protected broker execute the
actual operation from qualified immutable or independently
reconstructed parameters rather than rely solely upon allowing an
untrusted mutable request to continue.
25.65.15 — Multi-Sink Kernel
Another candidate may require separate broker-side and destination-
side verification where the broker's credential or dispatch authority
does not itself control the destination's completed resource effect.
25.65.16 — Hindsight and Functional-Combination Analysis
A technical comparison should examine whether the closest earlier
architecture already discloses the specific relationship among:
Das Expires 29 April 2027 [Page 475]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Sandbox-contained computation;
Protected consequential escape classification;
Separate original source authority;
Scoped privilege transitions;
Current effectuation coverage;
Non-bearer finality enablement;
And actual Finality-Sink resource verification.
It would be insufficient merely to identify that an earlier system
contained a sandbox, an approval service, and a network proxy.
The more relevant question is whether those components jointly
enforce the specific current Candidate Act against the actual effect-
capable resource boundary, including after a material runtime or
privilege change.
Conversely, where an earlier system already provides a similar end-
to-end protected operation-specific gate, the technical comparison
must recognize that capability rather than describe it as absent
because the earlier system uses different terminology.
The strongest claim should identify the specific combination and
corresponding actual technical effect.
9.7.3.67. Source page 2159 of the original specification
25.66 — INDUSTRIAL APPLICABILITY
25.66.1 — Enterprise Autonomous Agents
Isolated agents may perform legitimate tasks while protected external
effects remain separately authorized.
25.66.2 — Software Development Agents
Generated code may remain isolated until qualified resource and
deployment promotion.
25.66.3 — Cloud Automation
Privileged resource creation and configuration may be controlled
through bounded brokers.
Das Expires 29 April 2027 [Page 476]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
25.66.4 — Credentialed Tool Services
Reusable credentials may remain under protected custody and
operation-specific finality.
25.66.5 — Database Administration
Sandbox-generated database mutations may be verified at actual
resource commit.
25.66.6 — Document Processing
Internal document generation may remain separate from authorized
publication or external disclosure.
25.66.7 — Network Security
Sandbox-generated requests may be independently governed at actual
egress boundaries.
25.66.8 — Application Automation
Authenticated application effects may remain distinct from permitted
interface navigation.
25.66.9 — Payment Infrastructure
Sandboxed transaction preparation may be separated from actual
payment authority.
25.66.10 — Multi-Agent Orchestration
Several restricted agents may share protected resources without
multiplying original consequential permission.
25.66.11 — Operating-System Services
9.7.3.68. Source page 2160 of the original specification
Privileged operations may be executed by bounded brokers rather than
through general agent elevation.
25.66.12 — Virtualized Infrastructure
Guest-generated operations may be governed at host or resource
boundaries.
25.66.13 — Telecommunications
Das Expires 29 April 2027 [Page 477]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Autonomous configuration tasks may remain distinct from protected
network-control authority.
25.66.14 — Industrial Automation
Sandboxed control computation may remain separate from physical
device actuation.
25.66.15 — Robotics
Model-generated commands may require actual device-side finality.
25.66.16 — Autonomous Transportation
Selected protected control operations may be verified against current
actual hardware state.
25.66.17 — Satellite and Remote Systems
Delayed sandbox-generated commands may remain subject to destination-
side authority.
25.66.18 — Hardware Accelerators
Selected accelerator outputs may be mediated before external or
persistent effects.
25.66.19 — Persistent AI Memory
Generated state may be prevented from reaching protected long-term
stores without separate authority.
25.66.20 — Future Autonomous Critical Systems
Restricted computation may remain technically distinct from the
authority to produce consequential real-world effects.
25.67 — SUPPORT FOR POTENTIAL INDEPENDENT CLAIMS
25.67.1 — Candidate Independent System Claim
A system comprising:
9.7.3.69. Source page 2161 of the original specification
A restricted Sandbox Execution Domain configured to execute an
autonomous computational workload;
Das Expires 29 April 2027 [Page 478]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
A protected boundary classifier configured to identify a proposed
operation capable of producing a consequential effect outside a
permitted internal computational envelope;
A Candidate Act controller configured to maintain the proposed
consequential operation in a Non-Effective State;
A protected source-authority controller configured to determine
current permission for the operation;
A privilege-transition controller configured to establish operation-
specific authority for a qualified broker or restricted execution
context;
A finality controller configured to establish scoped non-bearer
finality enablement;
And a designated Finality Sink configured to reconstruct the actual
pending consequential operation and verify current source authority,
operation scope, relevant sandbox and privilege generations,
effectuation-path coverage, and sink-local protected consumption
before permitting the effect.
25.67.2 — Candidate Independent Method Claim
A method comprising:
Executing autonomous computation inside a restricted sandbox;
Identifying an operation crossing a protected consequential boundary;
Constructing a Candidate Act;
Withholding the actual effect;
Determining current originating authority;
Verifying current sandbox, tool, and effectuation coverage
conditions;
Establishing bounded privilege-transition authority where required;
Constituting scoped non-bearer finality enablement;
Reconstructing the actual consequential operation at a protected
effectuation sink;
Das Expires 29 April 2027 [Page 479]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Verifying the corresponding current resource and authority
conditions;
And conditionally consuming finality before permitting the operation.
25.67.3 — Candidate Independent Privilege-Transition Claim
9.7.3.70. Source page 2162 of the original specification
A system configured to receive a privileged operation request from a
lower-trust autonomous workload, establish source-authorized
operation-specific privilege without generally elevating the original
workload, and permit the operation only through a qualified
privileged execution component performing current actual-effect
verification and protected finality consumption.
25.67.4 — Candidate Independent Output-Promotion Claim
A system configured to preserve an autonomous sandbox-generated
artifact within a non-effective computational state relative to a
protected destination and to promote the artifact only after a
destination Finality Sink independently verifies the actual artifact,
current source authority, destination, and scoped promotion finality.
25.67.5 — Candidate Independent Coverage-Transition Claim
A protected runtime system configured to maintain authenticated
effectuation-path coverage generations and to invalidate dependent
operation-specific finality authority following material changes to
sandbox configuration, privileged tool semantics, or resource-
effectuation paths until current coverage and authority are
reestablished.
25.68 — SUPPORT FOR POTENTIAL DEPENDENT CLAIMS
Das Expires 29 April 2027 [Page 480]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
1. The autonomous workload executes inside a process sandbox. 2.
The autonomous workload executes inside a container. 3. The
autonomous workload executes inside a virtual machine. 4. The
autonomous workload executes inside a micro-virtual-machine. 5. The
autonomous workload executes inside a constrained language runtime.
6. The runtime has an authenticated sandbox identity. 7. The
runtime has a protected isolation-profile reference. 8. The
isolation profile is associated with a current generation. 9. A
protected tool registry identifies effect-capable tools. 10. A tool
contract identifies material consequential operation classes. 11. A
material tool-contract change invalidates dependent pending finality.
12. A protected classifier distinguishes internal computation from
consequential escape. 13. A protected classifier distinguishes
preparatory output from actual resource
effectuation. 14. A classified consequential operation becomes a
Candidate Act. 15. A Candidate Act identifies the actual proposed
effectuation resource. 16. A Candidate Act identifies the relevant
sandbox generation. 17. A Candidate Act identifies the current tool
generation. 18. A Candidate Act identifies the expected effectuation
path. 19. The consequential effect is held non-effective. 20. The
hold prevents the actual covered resource consequence. 21. A
protected controller maintains current effectuation-path coverage.
22. A material coverage change requires renewed validation. 23. The
system identifies an effect-capable privileged broker. 24. The
broker has a qualified protected execution identity. 25. A
privileged broker authenticates the originating sandbox.
9.7.3.71. Source page 2163 of the original specification
26. Authentication alone does not authorize every broker operation.
27. A protected privilege transition is bounded by an originating
source grant. 28. The transition identifies the permitted actual
resource. 29. The transition identifies the permitted operation
class. 30. The transition identifies material operation parameters.
31. The transition identifies a designated effectuation sink. 32. A
lower-trust workload does not receive unrestricted ambient privilege.
33. A protected broker may perform the operation on the workload's
behalf. 34. A fresh restricted worker may perform the operation. 35.
A protected worker may receive only a qualified operation-specific
resource handle. 36. The privilege transition may have a limited use
count. 37. A stale privilege transition is invalid following a
relevant generation change. 38. A protected credential broker may be
used as an effectuation component. 39. A protected network gateway
may verify the actual outgoing request. 40. A protected filesystem
broker may verify the current actual file object. 41. A protected
database sink may verify the actual pending mutation. 42. A
protected output-promotion sink may verify a generated artifact. 43.
Das Expires 29 April 2027 [Page 481]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Production deployment is treated as a distinct consequential effect
from sandbox
compilation. 44. A persistent memory commit is treated as a distinct
consequential effect from
temporary data generation. 45. A device controller may verify a
sandbox-generated hardware command. 46. A computer-use interface may
require verification of the actual consequential
application action. 47. A protected egress controller may verify
relevant accelerator-originated external
effects. 48. The Finality Sink reconstructs actual operation
parameters independently of an agent's
earlier description. 49. The sink verifies current source authority.
50. The sink verifies current resource identity. 51. The sink
verifies current privilege-generation state. 52. The sink verifies
current effectuation-coverage generation. 53. The sink verifies
current revocation state. 54. The sink verifies separate non-bearer
finality enablement. 55. The sink verifies protected consumption
state. 56. A copied finality reference cannot independently
authorize a second incompatible
effect. 57. An inherited file descriptor may be subjected to
coverage verification. 58. An existing network connection may be
subjected to qualified effectuation control. 59. A shared mount may
be included in the effectuation-surface inventory. 60. A material
runtime restart may invalidate affected pending finality. 61. A
snapshot rollback does not independently restore consumed authority.
62. A broker crash does not automatically imply that an earlier
external effect did not
occur. 63. An uncertain external outcome is preserved for qualified
reconciliation. 64. A scope-deviation controller may require new
bounded authorization for an expanded
privileged operation. 65. A human approval for one operation does
not override unrelated mandatory resource
predicates. 66. A prior actual-effect receipt may be required for
selected CW-2 successor operations.
9.7.3.72. Source page 2164 of the original specification
67. A valid predecessor receipt does not independently authorize a
different successor
Das Expires 29 April 2027 [Page 482]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
resource effect. 68. The system may combine sandbox coverage with
protected resource identity
continuity. 69. The system may combine sandbox coverage with
protected cumulative resource
budgets. 70. The protected runtime may maintain a current inventory
of effect-capable resource
references. 71. A change in inherited authority may activate a
sandbox revalidation fence. 72. A privileged broker may perform the
actual operation using stable protected
arguments rather than rely solely upon continuing mutable untrusted
syscall arguments. 73. A destination resource may independently
enforce actual effectuation when a broker
controls only dispatch or credential use. 74. The system may verify
an artifact's actual identity before protected promotion. 75. A
protected promotion operation may be bound to one current
destination. 76. A valid source-authorized computation may proceed
while unrelated consequential
operations remain withheld. 77. A protected classifier's uncertainty
may cause only the affected mandatory effect to
remain withheld. 78. A monitor-only event does not substitute for
mandatory blocking enforcement. 79. A resource operation may be
distributed among several independently protected
administrative domains. 80. Existing sandbox, operating-system,
virtualization, authorization, cryptographic, and
resource-control technologies may be used without being individually
mandatory.
25.69 — UNIVERSAL COMBINATION AND PHOSITA CLAUSE
The disclosed features may be implemented individually where
technically sufficient or in any compatible subcombination.
A selected embodiment may use a software process sandbox.
Another may use a container.
Another may use a micro-virtual-machine.
Another may use a remote execution worker.
Das Expires 29 April 2027 [Page 483]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Another may use a hardware-assisted protected execution environment.
A sandbox may use system-call restrictions, filesystem policy,
network restrictions, process privileges, or combinations of these.
A privileged operation may be executed through a protected local
broker.
Another may use a remote authenticated service.
9.7.3.73. Source page 2165 of the original specification
Another may use a fresh restricted worker.
Another may use a protected hardware controller.
Another may use a credential broker.
Another may use a controlled output-promotion sink.
Another may use a database commit sink.
Another may use a network or application gateway.
Another may incorporate resource-specific actual-effect evidence.
The invention does not require all internal computations to be
subjected to the same consequential finality process.
Only operations within the defined protected consequential coverage
may require the corresponding finality predicates.
The invention does not require the original agent to receive elevated
operating-system privilege.
The invention does not require a particular sandbox mechanism,
processor architecture, hypervisor, kernel security interface, or
programming language.
The invention does not require that all effectuation sinks reside on
the same computing host.
The invention does not require complete software-stack attestation
unless such attestation is needed for the selected protection claim.
The invention does not require perfect prediction of every future
operation performed by a generative model.
Das Expires 29 April 2027 [Page 484]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The actual consequential effect must remain independently enforceable
under the applicable protected source authority.
Where an operation is accomplished by a qualified privileged broker,
the broker may implement the required effectuation gate.
Where the operation is completed by a separate destination service,
destination-side enforcement or qualified destination evidence may be
necessary for the claimed remote-effect guarantee.
Where a material sandbox or tool configuration change affects the
required protection properties, current validation may be required.
A protected authorization to perform one operation does not
automatically authorize all future operations performed by the same
runtime.
9.7.3.74. Source page 2166 of the original specification
Where a lower-trust agent is compromised, the selected protection
remains conditional upon the continued integrity of the protected
enforcement components and absence of uncontrolled effectuation
bypass routes.
The algorithms, data structures, equations, state machines, threat
examples, proposed experiments, and diagrams are illustrative and
non-limiting technical aids intended to assist a PHOSITA.
25.70 — FINAL TECHNICAL CHARACTERIZATION
The present Embodiment 25 discloses a protected execution-finality
architecture for autonomous workloads operating within restricted
computational environments.
An autonomous agent may perform useful internal computation inside a
sandbox.
The sandbox may restrict direct access to host resources, privileged
system calls, network destinations, credentials, devices, or
persistent storage.
However, sandbox confinement alone does not automatically establish
authority for operations performed through privileged tools, external
brokers, network gateways, output-promotion services, or destination
resources.
A protected controller therefore identifies consequential operations
crossing the computational boundary.
Das Expires 29 April 2027 [Page 485]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Each covered operation may be represented as a Candidate Act
maintained in a Non-Effective State.
The protected architecture determines the current originating source
authority and verifies the applicable resource and effectuation-path
conditions.
Where a privileged operation is required, an operation-specific
privilege transition may be constituted through a protected broker or
suitable restricted execution context.
The requesting agent need not receive generally reusable elevated
privileges.
A finality controller establishes scoped non-bearer enablement bound
to the Candidate Act, relevant sandbox state, privilege conditions,
and designated Finality Sink.
The actual effectuation component independently reconstructs the
resource operation to be performed.
The sink verifies actual operation correspondence, current source
authority, applicable runtime and privilege generations, current
resource conditions, mandatory effectuation coverage, and protected
consumption.
Only after these checks may the corresponding consequence become
effective.
9.7.3.75. Source page 2167 of the original specification
A sandbox-generated artifact does not automatically possess authority
for production deployment or external publication.
A sandbox-generated network request does not automatically possess
authority for unrestricted transmission.
A privileged broker's technical ability to perform a resource
operation does not independently establish the originating
principal's permission.
A material runtime, privilege, or tool change may invalidate affected
operation-specific finality until current protection conditions are
reestablished.
The principal candidate inventive technical concept of Embodiment 25
is a protected autonomous sandbox-to-effectuation architecture in
which a lower-trust computational workload remains confined within a
Das Expires 29 April 2027 [Page 486]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
qualified execution domain, operations crossing a consequential
boundary are separately represented and withheld as Candidate Acts,
required privilege transitions are constituted as bounded operation-
specific authority, and an independent Finality Sink reconstructs the
actual pending external or persistent resource effect and permits the
operation only after verification of current source authority,
privilege and effectuation coverage, scoped non-bearer finality, and
sink-local protected consumption.
25.71 — SHORT PHOSITA IMPLEMENTATION USING EXISTING TECHNOLOGIES
A person having ordinary skill in the art may use the following
existing technologies as optional substrates.
Existing technology Optional implementation role Linux namespaces
Isolate selected process-visible resources
Linux seccomp filtering Restrict selected system calls and reduce
exposed kernel interfaces
Linux Landlock Apply supported additional restrictions to selected
filesystem and network operations Linux Security Modules and
qualified eBPF LSM hooks
Enforce supported resource-access decisions at selected kernel hooks
Containers or micro-virtual-machines Isolate lower-trust tool-
execution workloads Control groups and resource quotas Limit selected
computational resource use
Privileged IPC services Implement operation-specific protected host-
resource brokers
Credential vaults and key managers Keep reusable credentials out of
lower-trust sandbox processes Controlled network and application
gateways
Enforce selected external request and resource constraints
Restricted filesystem brokers Verify actual resource identity before
protected mutation
9.7.3.76. Source page 2168 of the original specification
Transactional databases Maintain current privilege, Candidate Act,
finality, and consumption state Authenticated structured
authorization records
Das Expires 29 April 2027 [Page 487]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Express original task and operation-specific permissions
Deterministic JSON or CBOR representations
Commit typed operation and privilege-transition descriptors Hardware
device controllers Enforce actual command finality where qualified
Protected deployment and artifact registries
Control the transition from generated artifacts to effective external
resources
Important PHOSITA Implementation Qualification
System-call filtering may reduce kernel attack surface but is not
automatically a complete sandbox.
A syscall notification supervisor that inspects mutable process-
memory arguments must not be assumed to provide race-free
consequential authorization solely by permitting the original syscall
to continue.
A stronger implementation may use a protected broker that performs
the operation using qualified stable arguments, a sufficiently
enforcing kernel resource restriction, or an independent actual
destination-side control.
A filesystem policy may not automatically constrain all previously
opened resource handles.
A network gateway cannot verify hidden remote business operations
that it does not observe or control.
A virtual-machine boundary does not automatically constrain every
privileged host service acting on the guest's behalf.
The selected implementation must establish the actual protection
properties on which its finality guarantees depend.
Non-Limiting Reference Combination
Autonomous agent → restricted sandbox → protected boundary classifier
→ consequential Candidate Act → non-effective hold → current source-
authority and coverage validation → operation-bound privilege
transition → scoped non-bearer finality → protected broker or actual
resource sink → actual-operation reconstruction → sink-local
consumption → controlled external consequence.
Existing sandbox and operating-system technologies provide important
practical components.
Das Expires 29 April 2027 [Page 488]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
The proposed distinguishing technical relationship is the conversion
of a sandbox-escaping operation into a separately authorized,
operation-bound consequential effect whose privilege and finality are
independently established and verified at the actual resource
boundary, rather than relying upon sandbox confinement or tool access
alone.
10. Six Formal Threat-Model Scenarios, Preconditions, Mitigations and
Residual Risks
10.1. Threat 1: Prompt Injection to Alternate Tool/Resource Path
Attacker capabilities and initiating conditions: Adversary controls
retrieved text or tool response and can induce a lower-trust agent to
invoke a new API, file share or network endpoint.
Protected asset and boundary: Source authorization, actual content/
recipient and enforced path inventory.
Proposed mitigation and verification point: Prevent effect until
resource-side observation matches protected grant; include alternate
known routes in mandatory coverage; treat agent intent as non-
authoritative.
Residual risks and deployment limitations: Uncontrolled third-party
receiver or privileged alternate route is an explicit limitation.
10.2. Threat 2: Replay and Snapshot Rollback at Finality Sink
Attacker capabilities and initiating conditions: Attacker copies an
authorized operation handle, replays a prepared request or restores
stale agent/sink state after prior consumption.
Protected asset and boundary: Current sink-local protected monotonic
consumption and final effect digest.
Proposed mitigation and verification point: Atomic consume-once
state, unique logical effect identifiers, grant/coverage epochs,
durable state and sink identity binding.
Residual risks and deployment limitations: Compromise or rollback of
protected sink state can invalidate the guarantee.
10.3. Threat 3: Coverage Evasion and Privileged Connector Bypass
Attacker capabilities and initiating conditions: Attacker discovers a
raw socket, direct database driver, privileged host connector or
device route outside the known policy gateway.
Das Expires 29 April 2027 [Page 489]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Protected asset and boundary: All effect-capable routes to the
governed resource within declared coverage.
Proposed mitigation and verification point: Authenticate effect-path
inventory and blockability; fence uncovered paths, reattest topology
on change; require real blocking, not telemetry.
Residual risks and deployment limitations: A path not observable or
blockable by this deployment cannot be asserted secure.
10.4. Threat 4: Forged Human Confirmation, GUI Race or UI Overlay
Attacker capabilities and initiating conditions: Attacker alters a
screen, accessibility tree, window focus, recipient field or request
after the user sees apparently valid approval.
Protected asset and boundary: Approval context, current interface
state and actual pending receiving operation.
Proposed mitigation and verification point: Bind confirmation to
authenticated window, resource, account and effect; recheck state and
enforce at the final receiving resource interface.
Residual risks and deployment limitations: Screen observations alone
may not prove backend transaction contents; inaccessible receivers
remain outside guarantees.
10.5. Threat 5: Scope Escalation via Sandbox Exit and Dynamic Tool
Privileges
Attacker capabilities and initiating conditions: Sandboxed agent
obtains host IPC/secret broker privilege, changes a tool or promotes
internal output to a public effect.
Protected asset and boundary: Original source scope, sandbox-to-host
authority transition and actual effect.
Proposed mitigation and verification point: Separate Candidate Act
for consequential privilege use or promotion, current credential/
route checks and independent host/resource sink finality.
Residual risks and deployment limitations: Overprivileged root/host
service may bypass unprotected gates.
Das Expires 29 April 2027 [Page 490]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
10.6. Threat 6: Compromised Security Infrastructure and Verification
Exhaustion
Attacker capabilities and initiating conditions: Validator,
attestation root, policy store or protected evidence key becomes
compromised; attacker floods evidence parsing or discovery to force
fail-open.
Protected asset and boundary: Integrity and availability of
decisions, protected keys and enforcement topology.
Proposed mitigation and verification point: Explicit trust boundary,
independent controls where specified, limit parser depth and cost,
key rotation, verified error paths, fail-closed when mandatory checks
unavailable.
Residual risks and deployment limitations: Total compromise of all
enforcement domains defeats guarantees; fail-closed can impair
availability.
11. Reproducible Technical Validation Plan: Twenty Proposed Negative
and Positive Tests
The following are proposed laboratory assertions, NOT executed
experiments or verified results. Each test requires a specific
prepared gateway/host resource, source grant, current coverage graph,
Candidate Act, actual request, protected sink state and observable
denial/allow output. Record code version and configuration in future
GitHub evidence; report actual results only after running these
cases.
11.1. S01 — Baseline approved controlled effect
Preconditions and attack setup: Single gate and sink, correct
protected evidence, unconsumed enabling. Use a new distinct test
Candidate Act, configured source grant, protected sink state and
evidence keys as applicable. Capture both the actual effect-capable
request and the result of the independent sink decision.
Expected result / pass criterion: Correct resource operation is
permitted once and the sink consumption journal advances. Verify
protected state before and after; for refusal cases ensure the
controlled external effect did not occur at the tested boundary, not
just that an upstream log reported rejection.
Das Expires 29 April 2027 [Page 491]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Reporting requirement: store configuration digest, test input, policy
generation, coverage epoch, actual operation commitment, reason code
and reproducibility instructions. Status: PROPOSED; no executed
result claimed.
11.2. S02 — Prompt-injected alternate recipient
Preconditions and attack setup: Original authorized recipient A;
injected agent request sends to B. Use a new distinct test Candidate
Act, configured source grant, protected sink state and evidence keys
as applicable. Capture both the actual effect-capable request and
the result of the independent sink decision.
Expected result / pass criterion: Reject mismatched actual recipient
despite valid tool identity. Verify protected state before and
after; for refusal cases ensure the controlled external effect did
not occur at the tested boundary, not just that an upstream log
reported rejection.
Reporting requirement: store configuration digest, test input, policy
generation, coverage epoch, actual operation commitment, reason code
and reproducibility instructions. Status: PROPOSED; no executed
result claimed.
11.3. S03 — Unauthorized raw socket bypass
Preconditions and attack setup: Tool gateway enabled; raw socket
reaches same resource. Use a new distinct test Candidate Act,
configured source grant, protected sink state and evidence keys as
applicable. Capture both the actual effect-capable request and the
result of the independent sink decision.
Expected result / pass criterion: Coverage classification fails
unless raw socket is blocked or equivalently enforced. Verify
protected state before and after; for refusal cases ensure the
controlled external effect did not occur at the tested boundary, not
just that an upstream log reported rejection.
Reporting requirement: store configuration digest, test input, policy
generation, coverage epoch, actual operation commitment, reason code
and reproducibility instructions. Status: PROPOSED; no executed
result claimed.
Das Expires 29 April 2027 [Page 492]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
11.4. S04 — Monitor-only interface mislabeled as enforcement
Preconditions and attack setup: eBPF/telemetry observes but cannot
block protected write. Use a new distinct test Candidate Act,
configured source grant, protected sink state and evidence keys as
applicable. Capture both the actual effect-capable request and the
result of the independent sink decision.
Expected result / pass criterion: Do not qualify coverage or release
effect. Verify protected state before and after; for refusal cases
ensure the controlled external effect did not occur at the tested
boundary, not just that an upstream log reported rejection.
Reporting requirement: store configuration digest, test input, policy
generation, coverage epoch, actual operation commitment, reason code
and reproducibility instructions. Status: PROPOSED; no executed
result claimed.
11.5. S05 — Changed routing after approval
Preconditions and attack setup: Coverage epoch X; network route
updated to X+1. Use a new distinct test Candidate Act, configured
source grant, protected sink state and evidence keys as applicable.
Capture both the actual effect-capable request and the result of the
independent sink decision.
Expected result / pass criterion: Invalidate prepared enablement and
request fresh qualification. Verify protected state before and
after; for refusal cases ensure the controlled external effect did
not occur at the tested boundary, not just that an upstream log
reported rejection.
Reporting requirement: store configuration digest, test input, policy
generation, coverage epoch, actual operation commitment, reason code
and reproducibility instructions. Status: PROPOSED; no executed
result claimed.
11.6. S06 — Changed hardware resource assignment
Preconditions and attack setup: Device or accelerator owner/
generation changes. Use a new distinct test Candidate Act,
configured source grant, protected sink state and evidence keys as
applicable. Capture both the actual effect-capable request and the
result of the independent sink decision.
Das Expires 29 April 2027 [Page 493]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Expected result / pass criterion: Fence stale resource authority and
reject pending command. Verify protected state before and after; for
refusal cases ensure the controlled external effect did not occur at
the tested boundary, not just that an upstream log reported
rejection.
Reporting requirement: store configuration digest, test input, policy
generation, coverage epoch, actual operation commitment, reason code
and reproducibility instructions. Status: PROPOSED; no executed
result claimed.
11.7. S07 — Replayed non-bearer enablement
Preconditions and attack setup: Already consumed unique sink
operation id is resubmitted. Use a new distinct test Candidate Act,
configured source grant, protected sink state and evidence keys as
applicable. Capture both the actual effect-capable request and the
result of the independent sink decision.
Expected result / pass criterion: Reject replay and preserve journal
history. Verify protected state before and after; for refusal cases
ensure the controlled external effect did not occur at the tested
boundary, not just that an upstream log reported rejection.
Reporting requirement: store configuration digest, test input, policy
generation, coverage epoch, actual operation commitment, reason code
and reproducibility instructions. Status: PROPOSED; no executed
result claimed.
11.8. S08 — Restored snapshot of agent runtime
Preconditions and attack setup: Clone agent context after original
finality consumption. Use a new distinct test Candidate Act,
configured source grant, protected sink state and evidence keys as
applicable. Capture both the actual effect-capable request and the
result of the independent sink decision.
Expected result / pass criterion: No authority regained solely from
cloned agent state. Verify protected state before and after; for
refusal cases ensure the controlled external effect did not occur at
the tested boundary, not just that an upstream log reported
rejection.
Reporting requirement: store configuration digest, test input, policy
generation, coverage epoch, actual operation commitment, reason code
and reproducibility instructions. Status: PROPOSED; no executed
result claimed.
Das Expires 29 April 2027 [Page 494]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
11.9. S09 — Redirected HTTP target
Preconditions and attack setup: Approved hostname/path redirects to
different sensitive resource. Use a new distinct test Candidate Act,
configured source grant, protected sink state and evidence keys as
applicable. Capture both the actual effect-capable request and the
result of the independent sink decision.
Expected result / pass criterion: Reconstruct effective destination
and reject unauthorized rebinding. Verify protected state before and
after; for refusal cases ensure the controlled external effect did
not occur at the tested boundary, not just that an upstream log
reported rejection.
Reporting requirement: store configuration digest, test input, policy
generation, coverage epoch, actual operation commitment, reason code
and reproducibility instructions. Status: PROPOSED; no executed
result claimed.
11.10. S10 — Changed request body at proxy
Preconditions and attack setup: Same method and URL but protected
payload commitment differs. Use a new distinct test Candidate Act,
configured source grant, protected sink state and evidence keys as
applicable. Capture both the actual effect-capable request and the
result of the independent sink decision.
Expected result / pass criterion: Reject payload substitution before
effect. Verify protected state before and after; for refusal cases
ensure the controlled external effect did not occur at the tested
boundary, not just that an upstream log reported rejection.
Reporting requirement: store configuration digest, test input, policy
generation, coverage epoch, actual operation commitment, reason code
and reproducibility instructions. Status: PROPOSED; no executed
result claimed.
11.11. S11 — UI approval with window focus swap
Preconditions and attack setup: Human confirms target A; actionable
window becomes B. Use a new distinct test Candidate Act, configured
source grant, protected sink state and evidence keys as applicable.
Capture both the actual effect-capable request and the result of the
independent sink decision.
Das Expires 29 April 2027 [Page 495]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Expected result / pass criterion: Withhold and require re-observation
or renewed approval. Verify protected state before and after; for
refusal cases ensure the controlled external effect did not occur at
the tested boundary, not just that an upstream log reported
rejection.
Reporting requirement: store configuration digest, test input, policy
generation, coverage epoch, actual operation commitment, reason code
and reproducibility instructions. Status: PROPOSED; no executed
result claimed.
11.12. S12 — UI screenshot / backend mismatch
Preconditions and attack setup: Visible field A; receiving service
actually processes field B. Use a new distinct test Candidate Act,
configured source grant, protected sink state and evidence keys as
applicable. Capture both the actual effect-capable request and the
result of the independent sink decision.
Expected result / pass criterion: Reject based on protected actual
operation at receiver. Verify protected state before and after; for
refusal cases ensure the controlled external effect did not occur at
the tested boundary, not just that an upstream log reported
rejection.
Reporting requirement: store configuration digest, test input, policy
generation, coverage epoch, actual operation commitment, reason code
and reproducibility instructions. Status: PROPOSED; no executed
result claimed.
11.13. S13 — Permissioned sandbox output not published
Preconditions and attack setup: Agent writes internal draft but lacks
public publication scope. Use a new distinct test Candidate Act,
configured source grant, protected sink state and evidence keys as
applicable. Capture both the actual effect-capable request and the
result of the independent sink decision.
Expected result / pass criterion: Allow internal draft only; refuse
external promotion. Verify protected state before and after; for
refusal cases ensure the controlled external effect did not occur at
the tested boundary, not just that an upstream log reported
rejection.
Reporting requirement: store configuration digest, test input, policy
generation, coverage epoch, actual operation commitment, reason code
and reproducibility instructions. Status: PROPOSED; no executed
result claimed.
Das Expires 29 April 2027 [Page 496]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
11.14. S14 — Escaping sandbox via privileged host connector
Preconditions and attack setup: Agent accesses connector with broad
service credentials. Use a new distinct test Candidate Act,
configured source grant, protected sink state and evidence keys as
applicable. Capture both the actual effect-capable request and the
result of the independent sink decision.
Expected result / pass criterion: Connector refuses request that
lacks per-operation source authority. Verify protected state before
and after; for refusal cases ensure the controlled external effect
did not occur at the tested boundary, not just that an upstream log
reported rejection.
Reporting requirement: store configuration digest, test input, policy
generation, coverage epoch, actual operation commitment, reason code
and reproducibility instructions. Status: PROPOSED; no executed
result claimed.
11.15. S15 — Revocation between preparation and dispatch
Preconditions and attack setup: Source grant revoked after approval
but before sink consume. Use a new distinct test Candidate Act,
configured source grant, protected sink state and evidence keys as
applicable. Capture both the actual effect-capable request and the
result of the independent sink decision.
Expected result / pass criterion: Sink refuses current revoked
authority. Verify protected state before and after; for refusal
cases ensure the controlled external effect did not occur at the
tested boundary, not just that an upstream log reported rejection.
Reporting requirement: store configuration digest, test input, policy
generation, coverage epoch, actual operation commitment, reason code
and reproducibility instructions. Status: PROPOSED; no executed
result claimed.
11.16. S16 — Concurrent requests race single-use consume
Preconditions and attack setup: Two workers present same operation at
same sink. Use a new distinct test Candidate Act, configured source
grant, protected sink state and evidence keys as applicable. Capture
both the actual effect-capable request and the result of the
independent sink decision.
Das Expires 29 April 2027 [Page 497]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Expected result / pass criterion: At most one receives protected
consumption eligibility. Verify protected state before and after;
for refusal cases ensure the controlled external effect did not occur
at the tested boundary, not just that an upstream log reported
rejection.
Reporting requirement: store configuration digest, test input, policy
generation, coverage epoch, actual operation commitment, reason code
and reproducibility instructions. Status: PROPOSED; no executed
result claimed.
11.17. S17 — Ambiguous canonicalization of URI/resource
Preconditions and attack setup: Different parser normalization or
alias resolves changed object. Use a new distinct test Candidate
Act, configured source grant, protected sink state and evidence keys
as applicable. Capture both the actual effect-capable request and
the result of the independent sink decision.
Expected result / pass criterion: Fail closed on ambiguity unless
versioned semantic equivalence is proven. Verify protected state
before and after; for refusal cases ensure the controlled external
effect did not occur at the tested boundary, not just that an
upstream log reported rejection.
Reporting requirement: store configuration digest, test input, policy
generation, coverage epoch, actual operation commitment, reason code
and reproducibility instructions. Status: PROPOSED; no executed
result claimed.
11.18. S18 — Verification exhaustion / DoS
Preconditions and attack setup: Malformed huge evidence or repeated
unknown path discoveries. Use a new distinct test Candidate Act,
configured source grant, protected sink state and evidence keys as
applicable. Capture both the actual effect-capable request and the
result of the independent sink decision.
Expected result / pass criterion: Bounded work and denial without
bypass; record exhaustion. Verify protected state before and after;
for refusal cases ensure the controlled external effect did not occur
at the tested boundary, not just that an upstream log reported
rejection.
Reporting requirement: store configuration digest, test input, policy
generation, coverage epoch, actual operation commitment, reason code
and reproducibility instructions. Status: PROPOSED; no executed
result claimed.
Das Expires 29 April 2027 [Page 498]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
11.19. S19 — Remote outcome timeout
Preconditions and attack setup: Dispatch occurred but no qualified
receiver completion ack. Use a new distinct test Candidate Act,
configured source grant, protected sink state and evidence keys as
applicable. Capture both the actual effect-capable request and the
result of the independent sink decision.
Expected result / pass criterion: Mark indeterminate; do not blindly
replay or falsely assert remote finality. Verify protected state
before and after; for refusal cases ensure the controlled external
effect did not occur at the tested boundary, not just that an
upstream log reported rejection.
Reporting requirement: store configuration digest, test input, policy
generation, coverage epoch, actual operation commitment, reason code
and reproducibility instructions. Status: PROPOSED; no executed
result claimed.
11.20. S20 — Android/iOS cross-platform receiving resource
Preconditions and attack setup: Origin mobile request, remote sink,
correct source/effect mapping. Use a new distinct test Candidate
Act, configured source grant, protected sink state and evidence keys
as applicable. Capture both the actual effect-capable request and
the result of the independent sink decision.
Expected result / pass criterion: Permit only exact current recipient
method/resource with traceable log. Verify protected state before
and after; for refusal cases ensure the controlled external effect
did not occur at the tested boundary, not just that an upstream log
reported rejection.
Reporting requirement: store configuration digest, test input, policy
generation, coverage epoch, actual operation commitment, reason code
and reproducibility instructions. Status: PROPOSED; no executed
result claimed.
12. Detailed Industry Relevance and Product Security Alignment
The company names, software/hardware products and platform families
in this section identify realistic engineering problem classes and
documented security interfaces where relevant. They are neither
product certifications nor assertions that a vendor implemented this
proposal, copied any invention or infringes any intellectual property
rights. Feasibility of kernel, network, accessibility or private
APIs varies by platform privileges and deployment. Apple, Siri, iOS,
iPadOS, macOS, Android, Gemini, Bixby, Copilot, Alexa, and other
Das Expires 29 April 2027 [Page 499]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
names used in this document are trademarks of their respective
owners.
12.1. Apple iOS and iPadOS Third-Party AI Tools
Industry security problem and technical relevance: App Intents, app
extensions, Shortcuts, OS-mediated resources and application
entitlements support narrowly scoped integration but do not grant
arbitrary control over other applications or private kernel/system
interfaces. An AI assistant can propose a file export, message send
or application intent whose actual destination differs after
application translation.
Example integration path and technical limitation: A feasible
prototype mediates approved actions in a cooperating receiving
service or app extension, uses publicly supported cryptographic/key
APIs, and checks the exact pending effect there. Platform-wide
coverage requires legitimate OS cooperation, MDM/enterprise
facilities or protected receiving services, not a private-kernel hook
invented by the draft.
12.2. Apple macOS, Desktop Sandboxing and Computer Use
Industry security problem and technical relevance: Desktop agents may
use accessibility, user automation, browser UI and system services
with complex privileges. A visual confirmation can become stale
through focus changes, overlays and background mutation.
Example integration path and technical limitation: Use authenticated
app/host observation as a supporting input and require resource-bound
confirmation at a gateway or receiving application. System
extensions or endpoint controls may provide richer enforcement where
permitted and properly authorized.
12.3. Google Android, Binder IPC and Intent-Based Action
Industry security problem and technical relevance: Android apps
interact through intents, services, content providers and Binder
permission identities. Delegated operations can reach receiving
resources with different security semantics from the initiator.
Example integration path and technical limitation: Treat an incoming
authorized intent as a Candidate Act and check the actual resource
operation and current caller/source grant within the privileged
receiver. Use supported app components, Android Keystore and audited
permissions. Universal interception is not available to ordinary
apps.
Das Expires 29 April 2027 [Page 500]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
12.4. Google Cloud, Gemini and Agent Gateways
Industry security problem and technical relevance: Cloud AI agents
may call multiple connectors, mutate shared resources or export data
using general-purpose workload identities. Tool allowlists do not
alone bind final recipient, method and content.
Example integration path and technical limitation: Use credentialed
receiver/gateway finality, WIMSE/OAuth context as inputs, protected
per-action policy and sink-local replay state; evaluate changes to
tool semantics and resource versions.
12.5. Microsoft Windows, Azure and Agent Execution Containers
Industry security problem and technical relevance: Isolated
workloads, enterprise identities and sandboxed execution can still
produce consequential effects through host-mediated connectors or
authorized privileged services.
Example integration path and technical limitation: Use protected
host-side operation reconstruction, signed source approval and
current resource-side verification. Test alternative IPC, network
routes and off-sandbox output promotion within platform-supported
control boundaries.
12.6. OpenAI Agent APIs, Codex and Computer-Use Systems
Industry security problem and technical relevance: LLM-driven tool
selection, browser actions, scripts and shell commands can be induced
by prompt injection or misleading external content to perform a
different consequential operation.
Example integration path and technical limitation: Wrap agent-issued
operations as proposals, enforce source-scoped gateway policy and
compare actual effect-capable parameters before dispatch. This is a
possible integration design, not a statement of OpenAI product
implementation.
12.7. Anthropic Claude and Sandboxed Development Agents
Industry security problem and technical relevance: Sandboxed tool
execution can produce safe drafts internally while making external
requests, repository writes, publications or privileged host
operations through connectors.
Das Expires 29 April 2027 [Page 501]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Example integration path and technical limitation: Separate sandbox
calculation from effectuation; require independently authorized
output promotion, credential broker mediation and receiving finality
validation for each governed external effect.
12.8. Meta Muse/Sentinel-like Isolated Agent Architectures
Industry security problem and technical relevance: Agent isolation,
host policy evaluation, protected credential custody and controlled
egress raise the question whether all alternate effect-capable routes
and actual end-resource operations are independently governed.
Example integration path and technical limitation: Analyze
demonstrable policy/enforcement features separately from proposed
protected evidence and non-bearer sink-local finality. Do not infer
unpublished receipt consumption, universal coverage or architectural
equivalence.
12.9. NVIDIA OpenShell / Sentry, BlueField and Accelerators
Industry security problem and technical relevance: Container or DPU/
NIC controls may gate network and device effects, but policy coverage
depends on all capable routes including kernel paths, peer-to-peer or
device commands.
Example integration path and technical limitation: Use host/resource
graph, coverage epoch and supported hardware enforcement to gate only
effects physically preventable at the selected boundary. Treat
hardware attestation and monitor telemetry as supporting evidence,
not an automatic full authorization grant.
12.10. Qualcomm Snapdragon, Arm and Embedded Hardware
Industry security problem and technical relevance: Secure enclaves,
hardware-backed keys and protected execution can establish integrity
of specific components without knowing whether a particular
application effect remains authorized.
Example integration path and technical limitation: Use hardware
security for key custody and protected sink state where available;
independently map current actual command/resource to bounded source
authority. No chipset/vendor mechanism is universally required.
12.11. Huawei and Heterogeneous Device Platforms
Industry security problem and technical relevance: Independent OS
platforms and telecom/device environments differ in permission,
credential and effectuation-interface arrangements.
Das Expires 29 April 2027 [Page 502]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Example integration path and technical limitation: Use interoperable
canonical effect descriptions and resource-side enforcement where
native security substrate is qualified; avoid assumptions of access
to proprietary firmware or privileged hooks.
12.12. Banking, Payments and Enterprise Transactions
Industry security problem and technical relevance: An authenticated
payment API session or approved transaction preview may not bind the
settled recipient, amount, resource version or transfer execution
route.
Example integration path and technical limitation: Receiving payment
resource validates exact amount, recipient and source permissions
immediately before controlled dispatch and protected consumption.
Remote settlement and reconciliation require receiver-qualified
outcome evidence.
12.13. Cloud API Gateways, Databases and SaaS
Industry security problem and technical relevance: Multiple
administrative services, direct driver access, caches and alternate
credential routes can bypass an upstream agent-policy enforcement
point.
Example integration path and technical limitation: Use enforceable
resource server/mutation gate with conditional-version checks, bound
request body and control of alternate interfaces; qualify topology
changes and current revocation.
12.14. Telecommunications, IoT and Robotics
Industry security problem and technical relevance: Physical and
communication effects may originate via API, message queue, control
plane or direct device action; monitoring is not equivalent to
command interlock.
Example integration path and technical limitation: Bind device
command and actual actuator/resource state to qualified authority at
last controllable boundary; ensure safety interlocks and offline
leases are treated separately, without claiming complete control of
unreachable devices.
Das Expires 29 April 2027 [Page 503]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
12.15. Voice and System Assistants: Apple Siri, Google Gemini, Samsung
Bixby, Microsoft Copilot, and Amazon Alexa
Industry security problem and technical relevance: system and voice
assistants convert a spoken or typed request into actions inside
third-party apps and services through platform action frameworks such
as App Intents and Shortcuts on Apple platforms and intents and app
actions on Android. A single assistant request can reach the same
consequence through several routes (an app action, a deep link, a web
request, or a direct API call by a companion service), and a
confirmation shown to the user may not be bound to the parameters
that finally reach the resource. Injected content read by the
assistant can steer which route and which target are used.
Example integration path and technical limitation: the receiving app
or backend acts as the Finality Sink for every route that can produce
the same effect, reconstructs the actual pending operation, and
consumes operation-scoped authority once regardless of which route
delivered the request. Third-party implementers can enforce only at
interfaces they control, such as their own action handlers and server
APIs; private assistant or operating-system internals are not assumed
to be available, and unmediated alternate routes must be reported as
coverage gaps.
13. Detailed IETF Working-Group Relevance, Existing RFCs and Technical
Integration Boundaries
The following crosswalks describe the specific technical property
that a cited IETF specification can provide, the additional
operation-bound enforcement relationship proposed in Part 4, and
limits of the relationship. WG references are for independent
technical relevance and do not mean the proposal is within an
approved charter, sponsored by a group or adopted as an IETF work
item.
13.1. OAuth WG: RFC 9396 Rich Authorization, RFC 9449 DPoP and
Transaction Context
Primary references: [RFC6749], [RFC9396], [RFC9449].
Established IETF scope and concrete RFC/WG mechanics: OAuth RAR
authorization_details encodes fine-grained permission and DPoP
sender-constrains tokens; OAuth work also examines delegated agent
authorization and transaction context.
Proposed integration, distinction and failure assumptions: Protected
source scope, token audience and proof-of-possession can be mapped to
the authorized effect envelope but do not themselves establish that
Das Expires 29 April 2027 [Page 504]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
every alternate path is blocked or that the exact last resource
operation has been reconstructed and consumed. Define which RAR
fields constrain method, target and content in a local profile;
verify them at a protected resource server.
Verified working-group information URL:
https://datatracker.ietf.org/wg/oauth/about/
13.2. WIMSE WG: Workload Identity and Multi-Hop Authorization
Primary references: [WIMSE].
Established IETF scope and concrete RFC/WG mechanics: WIMSE addresses
workload identity in multi-service HTTP/REST chains, runtime context
and propagation of workload/caller claims across trust domains.
Proposed integration, distinction and failure assumptions: Use
workload identity as the source and actor context for a CA.
Distinguish identity propagation from actual operation equality at a
receiving sink; validate current identity, transaction context and
route coverage when a host connector or microservice ultimately
changes a resource.
Verified working-group information URL:
https://datatracker.ietf.org/wg/wimse/about/
13.3. RATS WG: RFC 9334 Attestation of Protected Components
Primary references: [RFC9334].
Established IETF scope and concrete RFC/WG mechanics: RATS defines
Attesters, Verifiers, Relying Parties, Evidence and Attestation
Results for assessing trusted system properties.
Proposed integration, distinction and failure assumptions: Use
attestation to qualify a source, validator, coverage controller or
sink implementation and relevant software generation. Device posture
is not equivalent to approval for an exact payment or publication;
sink-local current authority and final resource operation must still
be checked.
Verified working-group information URL:
https://datatracker.ietf.org/wg/rats/about/
13.4. COSE / CBOR: RFC 9052 and RFC 8949 for Protected Evidence
Primary references: [RFC9052], [RFC8949].
Das Expires 29 April 2027 [Page 505]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Established IETF scope and concrete RFC/WG mechanics: COSE supports
protected signature/MAC structures; CBOR supports structured
canonical-style encodings under specific profiles.
Proposed integration, distinction and failure assumptions:
Authenticate effect descriptor, observer state, coverage generations
and evidence commitments. Specify deterministic encoding and
semantic normalization for any signed object; cryptographic validity
alone cannot prove a route is non-bypassable.
Verified working-group information URL:
https://datatracker.ietf.org/wg/cose/about/
13.5. ACE WG: RFC 9200 Constrained Authorization
Primary references: [RFC9200].
Established IETF scope and concrete RFC/WG mechanics: ACE-OAuth
supplies authorization profiles for constrained clients/resources,
useful for device control and embedded actuators.
Proposed integration, distinction and failure assumptions: A
constrained resource server may enforce scoped authorization; the
additional proposal concerns mapping actual command parameters,
device/current-owner state and mandatory stop-capable interface to
single-use protected finality. Do not assume arbitrary offline
revocation guarantees.
Verified working-group information URL:
https://datatracker.ietf.org/wg/ace/about/
13.6. SCITT WG: Signed Statements and Transparency Evidence
Primary references: [SCITT].
Established IETF scope and concrete RFC/WG mechanics: SCITT studies
interoperable signed statements, registration and verification
transparency receipts for software integrity and provenance.
Proposed integration, distinction and failure assumptions:
Transparency or signed statement evidence may qualify software/kernel
policy versions and path inventory history; transparency alone does
not prove an actual remote effect occurred or grant current operation
authority.
Verified working-group information URL:
https://datatracker.ietf.org/wg/scitt/about/
Das Expires 29 April 2027 [Page 506]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
13.7. HTTPBIS: RFC 9110 Resource Semantics, Preconditions and Redirects
Primary references: [RFC9110].
Established IETF scope and concrete RFC/WG mechanics: RFC 9110
defines methods, resource targets, validators, If-Match conditional
operations and redirect semantics.
Proposed integration, distinction and failure assumptions: Use actual
method, final resource identifier, body commitment and ETag/current
resource version as candidates for sink-local comparison. An HTTP
response status or original URL alone is not necessarily proof of
intended final target or original source authority.
Verified working-group information URL:
https://datatracker.ietf.org/wg/httpbis/about/
13.8. SEC-DISPATCH and Security Area: Cross-Protocol Execution
Boundaries
Established IETF scope and concrete RFC/WG mechanics: Cross-cutting
autonomous-agent effectuation security involves OAuth identity and
delegation, RATS code attestation, COSE evidence, WIMSE workload
identity and resource server decisions.
Proposed integration, distinction and failure assumptions: Provide a
narrowly scoped problem statement, trust model, concrete
interoperability interfaces and non-goals for security-area review;
do not presume that a current WG charter covers full universal
Finality Sink functionality.
Verified working-group information URL:
https://datatracker.ietf.org/wg/secdispatch/about/
14. Relevance to the EU Artificial Intelligence Act
Regulation (EU) 2024/1689 [EU-AI-ACT] sets obligations for providers
and deployers of certain AI systems and general-purpose AI models.
Whether an obligation applies to a given deployment depends first on
whether the system meets the definition of an AI system in Article 3
and then on its classification, for example as high-risk under
Article 6 and Annex III. A purely cryptographic or rule-based
enforcement component that performs no inference may itself fall
outside that definition while still operating inside a system that is
in scope. This section is a non-normative technical mapping. It is
not legal advice and makes no claim of conformity, certification, or
presumption of conformity.
Das Expires 29 April 2027 [Page 507]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Risk management (Article 9): the protected-execution workflows,
threat model, and falsifiable test plan in this series give a
documented and testable control for the risk that an AI agent or
assistant produces an unauthorized consequential effect, including
through reasonably foreseeable misuse such as prompt injection.
Record-keeping and traceability (Article 12): protected validation
evidence, sink-local decisions, consumption state, and qualified
actual-effect receipts yield operation-level records of what was
proposed, what was authorized, what was withheld, and what actually
took effect. Such records can support automatic logging and post-
incident traceability, subject to data-minimization requirements.
Human oversight (Article 14): the Non-Effective State and the scope-
deviation re-authorization latch provide defined points at which a
consequential action can be withheld, interrupted, or escalated to a
competent natural person. The Act does not require human approval of
every individual decision, and this architecture does not assume it;
oversight can be exercised through bounded source authority and
explicit scope-delta approvals.
Accuracy, robustness, and cybersecurity (Article 15): fail-closed
withholding, single-use consumption, anti-replay state, and
independent reconstruction of the actual pending operation at the
Finality Sink contribute to resilience against attempts by
unauthorized third parties to alter a system's use or outputs by
exploiting vulnerabilities, and they bound the consequences of
erroneous model output.
Deployer obligations (Article 26) and obligations for general-purpose
AI models with systemic risk (Article 55), including an adequate
level of cybersecurity protection, may also be relevant where
deployers integrate third-party agents into mobile or enterprise
workflows. Harmonised standards under Article 40 and the application
dates of individual obligations have been subject to change and must
be checked at the time of use. Related EU instruments, such as the
Cyber Resilience Act, the NIS2 Directive, the General Data Protection
Regulation, and the Digital Markets Act, may interact with
deployments on mobile platforms but are outside the scope of this
document.
15. Security, Privacy, Availability, Deployment and IANA Considerations
15.1. Coverage completeness
The protection statement must enumerate actual effect-capable
interfaces and qualify blocking semantics; monitoring-only paths do
not meet a mandatory prevention predicate.
Das Expires 29 April 2027 [Page 508]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
15.2. Temporal consistency
Current source authority, tool identity, policy version, revocation
and coverage epoch may change after initial permission; final checks
must use current protected state.
15.3. Human approval integrity
Visual display, accessibility tree, user confirmation and resource
operation can diverge; approval should be bound to the exact effect
and revalidated where relevant state changes.
15.4. Privilege separation and bypass
Sandboxed agent code must not alter the protected finality gate,
unrestricted credential broker or route inventory; all privileged
promotion paths require explicit independent checks.
15.5. Replay and monotonic sink state
Single-use authority requires protected consumption state surviving
relevant crashes, rollback and concurrency; define the durability and
attacker assumptions.
15.6. Canonical operation equivalence
Methods, destinations, resource aliases and payloads can have
differing encodings; ambiguity requires defined canonicalization or
fail-closed refusal.
15.7. Sensitive logs and privacy
Actual operation descriptors may include sensitive content, account
identities and destinations. Prefer scoped commitments, restricted
access, retention limits and protected audit logs.
15.8. Verification exhaustion and loss of availability
Source verification, path inventory and cryptographic checks can be
overloaded. Apply resource bounds and refuse mandatory effects if
required checks cannot complete rather than enabling bypass.
15.9. Remote side effects
Do not interpret durable local consumption as proof of remote outcome
or universal exactly-once semantics without cooperating receiver
evidence.
Das Expires 29 April 2027 [Page 509]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
15.10. IANA and interop maturity
This author-submitted informational document requests no new
registries or code points and does not define a mandatory common
network serialization. Profiles would require further independent
interoperable specification and test evidence.
16. Original Technical Source Cross-Index for Patent Examination and
Platform Security Review
Original Cross-Platform Consequence Control and Non-Effectuation
Foundation: original global pages 1 through 14; Part 4 section anchor
original-scope; page index original-scope-page-index; diagrams fig-
original-scope-architecture and fig-original-scope-flowchart.
CW-1 Source: Protected Execution-Finality and Sink Enforcement:
original global pages 15 through 62; Part 4 section anchor cw1-sink;
page index cw1-sink-page-index; diagrams fig-cw1-sink-architecture
and fig-cw1-sink-flowchart.
Miscellaneous Embodiment M-1: Dynamic Effectuation Coverage and
Future-Adaptive Infrastructure: original global pages 555 through
609; Part 4 section anchor m1-coverage; page index m1-coverage-page-
index; diagrams fig-m1-coverage-architecture and fig-m1-coverage-
flowchart.
Embodiment 14: Protected Effectuation-Path Discovery, Runtime Bypass
Detection and Hardware Attribution: original global pages 1222
through 1308; Part 4 section anchor emb14-coverage; page index emb14-
coverage-page-index; diagrams fig-emb14-coverage-architecture and
fig-emb14-coverage-flowchart.
Embodiment 19: Protected Computer-Use, Human Approval and Actual UI
Effect Correspondence: original global pages 1626 through 1682; Part
4 section anchor emb19-ui; page index emb19-ui-page-index; diagrams
fig-emb19-ui-architecture and fig-emb19-ui-flowchart.
Miscellaneous Embodiment M-2: Existing Security Protocols as
Qualified Inputs to Sink-Local Finality: original global pages 1898
through 1952; Part 4 section anchor m2-standards; page index m2-
standards-page-index; diagrams fig-m2-standards-architecture and fig-
m2-standards-flowchart.
Embodiment 25: Sandboxed Tool Execution, Privilege Transitions and
Mandatory Escaping-Effect Control: original global pages 2093 through
2168; Part 4 section anchor emb25-sandbox; page index emb25-sandbox-
page-index; diagrams fig-emb25-sandbox-architecture and fig-emb25-
sandbox-flowchart.
Das Expires 29 April 2027 [Page 510]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Examiner caution: publication and filing dates apply to the actual
words publicly disclosed in each corresponding historical document.
Newly authored test designs, algorithms, diagrams and examples in
this working edition must not be presented as necessarily contained
in the June 4, 2026 PCT application without independent comparison to
the as-filed disclosure.
17. Explicit Foundation and Companion Internet-Draft Cross-References
Part 1 companion: [DAS-FOUNDATION]
Part 2 companion: [DAS-INTEROP]
Part 3 companion: [DAS-EVIDENCE]
Part 5 companion: [DAS-MULTIAGENT]
Part 6 companion: [DAS-RECEIPTS]
Part 7 companion: [DAS-TOOLS]
Part 8 companion: [DAS-RECOVERY]
Part 9 companion: [DAS-CREDENTIALS]
Part 10 companion: [DAS-REVOCATION]
Part 11 companion: [DAS-HARDWARE]
Part 12 companion: [DAS-INFRA]
18. Source Publication, IETF RFCs and Planned Companion Documents
[DAS-FOUNDATION]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 1: Foundational
Consequential Authority and Common Workflows", Work in
Progress, Internet-Draft, draft-das-interoperable-
consequence-authority-00,
<https://datatracker.ietf.org/doc/draft-das-interoperable-
consequence-authority/>.
Das Expires 29 April 2027 [Page 511]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
[DAS-INTEROP]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 2: Secure iOS and
Android AI Tool Interoperability", Work in Progress,
Internet-Draft, draft-das-cross-platform-ai-
interoperability-00, <https://datatracker.ietf.org/doc/
draft-das-cross-platform-ai-interoperability/>.
[DAS-EVIDENCE]
Das, S., "Secure AI Execution-Finality for iOS, Android,
and Cross-Platform AI Agents, Part 3: Protected Source
Authority, Cross-Committed Evidence, and Scoped Non-Bearer
Finality", Work in Progress, Internet-Draft, draft-das-
protected-authority-evidence-00,
<https://datatracker.ietf.org/doc/draft-das-protected-
authority-evidence/>.
[DAS-MULTIAGENT]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 5 of 12 — Multi-agent
delegation, conflicts and source-authority lineage", Work
in Progress, Internet-Draft, draft-das-multi-agent-
authority-control-00, <https://datatracker.ietf.org/doc/
draft-das-multi-agent-authority-control/>.
[DAS-RECEIPTS]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 6 of 12 — Qualified
actual-effect receipts and dependent workflow
continuation", Work in Progress, Internet-Draft, draft-
das-causal-effect-receipts-00,
<https://datatracker.ietf.org/doc/draft-das-causal-effect-
receipts/>.
[DAS-TOOLS]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 7 of 12 — AI tool
security, dynamic tool semantics and runtime integrity",
Work in Progress, Internet-Draft, draft-das-agent-tool-
integrity-00, <https://datatracker.ietf.org/doc/draft-das-
agent-tool-integrity/>.
[DAS-RECOVERY]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Das Expires 29 April 2027 [Page 512]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
Technical Specification Series: Part 8 of 12 — Distributed
effects, transaction outcomes and protected recovery",
Work in Progress, Internet-Draft, draft-das-distributed-
effect-recovery-00, <https://datatracker.ietf.org/doc/
draft-das-distributed-effect-recovery/>.
[DAS-CREDENTIALS]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 9 of 12 — Credential
custody, data disclosure and privacy release", Work in
Progress, Internet-Draft, draft-das-agent-credential-
privacy-00, <https://datatracker.ietf.org/doc/draft-das-
agent-credential-privacy/>.
[DAS-REVOCATION]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 10 of 12 — Cross-
device ownership, revocation fences and offline
execution", Work in Progress, Internet-Draft, draft-das-
cross-device-authority-revocation-00,
<https://datatracker.ietf.org/doc/draft-das-cross-device-
authority-revocation/>.
[DAS-HARDWARE]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 11 of 12 — Kernel,
sandbox, accelerator and hardware boundary enforcement",
Work in Progress, Internet-Draft, draft-das-hardware-
execution-finality-00, <https://datatracker.ietf.org/doc/
draft-das-hardware-execution-finality/>.
[DAS-INFRA]
Das, S., "Secure AI Execution-Finality, Cross-Platform
Interoperability, and Hardware Security — A Twelve-Part
Technical Specification Series: Part 12 of 12 — Autonomous
cloud, telecom and critical infrastructure resource
governance", Work in Progress, Internet-Draft, draft-das-
autonomous-infrastructure-finality-00,
<https://datatracker.ietf.org/doc/draft-das-autonomous-
infrastructure-finality/>.
Das Expires 29 April 2027 [Page 513]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
[ZENODO] Das, S., "iOS and Android Interoperability for Secure
Third Party AI Tools - Cross-Platform Execution Finality,
Hardware Security, and Interoperability (3,567-Page
Specification)", DOI 10.5281/zenodo.23657985, October
2026, <https://zenodo.org/records/23657985>.
[PCT-055615]
Das, S., "Published international application WO
2026/150382 (PCT/IB2026/055615)", 2026,
<https://patentscope.wipo.int/search/en/WO2026150382>.
[RFC8179] Bradner, S. and J. Contreras, "Intellectual Property
Rights in IETF Technology", RFC 8179, BCP 79,
DOI 10.17487/RFC8179, May 2017,
<https://www.rfc-editor.org/info/rfc8179>.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[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>.
[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>.
[RFC9110] Fielding, R., Nottingham, M., and J. Reschke, "HTTP
Semantics", RFC 9110, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", RFC 9052, DOI 10.17487/RFC9052,
August 2022, <https://www.rfc-editor.org/info/rfc9052>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 8949, STD 94,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
Das Expires 29 April 2027 [Page 514]
Internet-Draft Execution-Finality Part 4: Finality Sink October 2026
[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments Using the OAuth 2.0 Framework
(ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
<https://www.rfc-editor.org/info/rfc9200>.
[WIMSE] Internet Engineering Task Force, "Workload Identity in
Multi System Environments (wimse) Working Group",
<https://datatracker.ietf.org/wg/wimse/about/>.
[SCITT] Internet Engineering Task Force, "Supply Chain Integrity,
Transparency, and Trust (scitt) Working Group",
<https://datatracker.ietf.org/wg/scitt/about/>.
[EU-AI-ACT]
European Parliament and Council of the European Union,
"Regulation (EU) 2024/1689 of the European Parliament and
of the Council laying down harmonised rules on artificial
intelligence (Artificial Intelligence Act)", 13 June 2024,
<https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.
Author's Address
Sangam Kumar Das
Independent Researcher
Balasore
Odisha
India
Email: info@sangamdas.com
Das Expires 29 April 2027 [Page 515]