Network Working Group S. Das Internet-Draft Independent Inventor Intended status: Informational 16 October 2026 Expires: 19 April 2027 Protected Execution-Finality Architecture for AI and Autonomous Systems: Act-Bound Capabilities and Effectuation-Boundary Verification draft-das-agent-execution-finality-00 Abstract This document describes a proposed protected execution-finality architecture for artificial-intelligence agents, autonomous software systems, confidential computing environments, and distributed execution infrastructures. The architecture addresses a fundamental security distinction: the ability of an AI agent or computational process to generate, prepare, or request an operation does not independently establish the protected authority required to make that operation effective. The proposed architecture separates the computation plane from protected execution authority through mandatory operation interception, Non-Effective State staging, machine-verifiable Candidate Act Descriptors, a Protected Enforcement Domain (PED), protected authorization-state management, scoped non-bearer execution capabilities, and Finality Sink verification. A Candidate Act remains non-effective until the applicable authority, purpose, destination, execution scope, runtime context, policy epoch, freshness, revocation, and other mandatory authorization predicates have been validated. Where required, protected validation evidence is committed before, or atomically with, capability availability. The designated Finality Sink independently verifies the capability against the actual operation and applicable protected state immediately before permitting the governed consequential effect. The architecture addresses AI-agent sandbox isolation, mandatory and non-bypassable mediation, out-of-process permission authorities, executable-specific access restrictions, network and API egress enforcement, destination resolution, redirect consistency, credential brokering, protected credential substitution, privileged connectors, human and developer approval, runtime policy modification, multi- agent delegation, taint and provenance-based authorization, and fail- closed execution control. For technical discoverability and independent architectural examination, related publicly documented industry systems include Meta Muse/Sentinel and NVIDIA OpenShell, NemoClaw, and the Open Agent Das Expires 19 April 2027 [Page 1] Internet-Draft Protected AI Execution Finality October 2026 Safety Platform/Sentry. Relevant engineering terminology includes Muse Secure VM, isolated runtime cells, host-side permission authority, forward proxies, surrogate credentials, just-in-time credential insertion, eBPF/LSM-based taint propagation, controlled network egress, executable-specific policy enforcement, developer- approved policy changes, and hardware-assisted monitoring through SmartNICs, data processing units, BlueField, and DOCA. These references identify relevant public engineering contexts and functional security objectives; they do not establish that the named systems implement the complete architecture described here. The principal technical distinction examined in this document concerns the relationship between an upstream permission decision and independently enforceable authority at the actual effectuation boundary. The proposed execution-finality sequence includes protected validation of a concrete Candidate Act, required protected- state handling, validation-evidence commitment, operation-bound capability release, and mandatory verification of that capability by the applicable Finality Sink. The architecture distinguishes conventional permission checking, credential isolation, model- computation admission, and post-event monitoring or quarantine from the separate authorization conditions required before an externally consequential operation becomes effective. The document further describes enforcement across network gateways, host operating systems, credential-release interfaces, service meshes, autonomous code-deployment systems, confidential virtual machines, protected storage, database commitments, accelerator fabrics, DMA/RDMA transfers, SmartNICs, DPUs, hardware Finality Latches, and receiving-side execution boundaries. It addresses protected state consumption, capability replay prevention, policy- version fencing, distributed revocation, hardware attestation, workload migration, snapshot rollback, crash-consistent recovery, and prevention of unauthorized duplicate effects. Authorization of one effectuation boundary does not automatically establish authority for a distinct downstream consequence. This individual Informational Internet-Draft presents architectural mechanisms, enforcement points, implementation alternatives, and security considerations for independent technical examination. It does not specify a complete interoperable wire protocol or request IANA allocations. Industry and product names are used solely for technical relevance, terminology identification, and discoverability, without implying affiliation, endorsement, copying, derivation, infringement, patent validity, or architectural identity. Das Expires 19 April 2027 [Page 2] Internet-Draft Protected AI Execution Finality October 2026 Related Indian Patent Disclosures and Claimed Priority: The author identifies Indian Application No. 202531130665, dated 23 December 2025, as an earlier related foundational disclosure, together with Indian provisional applications 202631000572 (3 January 2026), 202631001586 (7 January 2026), and 202631002990 (12 January 2026) concerning execution-time authorization and irreversible-boundary enforcement. Indian Application No. 202631124028 is separately identified as a related patent-pending application. Related International Patent Applications and WIPO Publications: The author identifies PCT/IB2025/058316 (Mothership; WO 2025/210622), PCT/IB2026/053385 (ALF-PCT; WO 2026/115520), PCT/IB2026/055615 (DAS Protocols I; WO 2026/150382), PCT/IB2026/055760 (DAS Protocols II; WO 2026/150383), PCT/IB2026/055870 (DAS Protocols III; WO 2026/150384), PCT/IB2026/056058 (DAS Protocols IV; WO 2026/154461), PCT/ IB2026/056809 (DAS Protocols V; WO 2026/172334), and PCT/ IB2026/056941 (DAS Protocols VI; WO 2026/172336) as related technical disclosures. These application identifiers and publication references are provided to facilitate independent examination of the original technical documents and their chronology. Any claimed priority entitlement depends upon the actual subject-matter support contained in the corresponding earlier filing and the applicable legal requirements. The filing chronology does not imply that every technical mechanism described in this Internet-Draft was disclosed in every earlier application. Fundamental architectural principle: Computation is not authority to act. 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 19 April 2027. Das Expires 19 April 2027 [Page 3] Internet-Draft Protected AI Execution Finality October 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Status, Scope, and Interpretation . . . . . . . . . . . . . . 43 2. Industry Terminology and Technical Scope . . . . . . . . . . 43 3. Technical Discoverability and Architectural Terminology . . . 45 3.1. Product Names and Search Expressions . . . . . . . . . . 45 3.2. Published-System Vocabulary and Corresponding Technical Examination Topics . . . . . . . . . . . . . . . . . . . 46 3.3. Five Technical Examination Questions . . . . . . . . . . 47 3.4. Specific Architectural Distinctions Requiring Verification . . . . . . . . . . . . . . . . . . . . . . 48 3.5. Combined Technical Search Phrase . . . . . . . . . . . . 48 4. Author-Reported Indian Filing Chronology and Underlying Concepts . . . . . . . . . . . . . . . . . . . . . . . . 49 5. Related Patent Applications and Intellectual Property Disclosure . . . . . . . . . . . . . . . . . . . . . . . 49 5.1. Indian Applications and Earlier Disclosures . . . . . . . 50 5.2. International Patent Application Identifiers . . . . . . 50 5.3. Publication, Priority, and Scope Distinctions . . . . . . 51 5.4. IETF IPR Disclosure Process . . . . . . . . . . . . . . . 51 6. Scope and Technical Field . . . . . . . . . . . . . . . . . . 51 7. Background and Motivation . . . . . . . . . . . . . . . . . . 52 7.1. 1. Development of Autonomous Artificial-Intelligence Execution Systems . . . . . . . . . . . . . . . . . . . 52 7.2. 2. Limitations of Conventional Authentication and Authorization . . . . . . . . . . . . . . . . . . . . . 53 7.3. 3. Separation of Computation and Execution Authority . . 54 7.4. 4. Limitations of Sandboxing and Process Isolation Alone . . . . . . . . . . . . . . . . . . . . . . . . . 55 7.5. 5. Limits of Model-Level Safety and Computation Admission . . . . . . . . . . . . . . . . . . . . . . . 55 7.6. 6. Credential Exposure and Privileged Tool Execution . . 56 7.7. 7. Delegated AI Agents and Authority Propagation . . . . 57 7.8. 8. Time-of-Check and Time-of-Use Vulnerabilities . . . . 57 Das Expires 19 April 2027 [Page 4] Internet-Draft Protected AI Execution Finality October 2026 7.9. 9. Limitations of Post-Event Monitoring and Audit . . . 58 7.10. 10. Distributed State, Replay and Recovery Problems . . 58 7.11. 11. Confidential Computing and Cryptographic Key Authority . . . . . . . . . . . . . . . . . . . . . . . 59 7.12. 12. Hardware and Accelerator Effectuation Boundaries . . 60 7.13. 13. Multi-Boundary and Receiving-Side Enforcement . . . 60 7.14. 14. Earlier Technical Disclosures and Related Applications . . . . . . . . . . . . . . . . . . . . . . 61 7.15. 15. Technical Problem to Be Solved . . . . . . . . . . . 62 8. Proposed Technical Architecture . . . . . . . . . . . . . . . 63 8.1. 16. General Protected Execution-Finality Architecture . 63 8.2. 17. Candidate Act and Non-Effective State . . . . . . . 64 8.3. 18. Canonical Candidate Act Descriptor . . . . . . . . . 65 8.4. 19. Protected Enforcement Domain . . . . . . . . . . . . 66 8.5. 20. Transaction-Bound Authorization and Protected State . . . . . . . . . . . . . . . . . . . . . . . . . 66 8.6. 21. Protected Validation Evidence . . . . . . . . . . . 67 8.7. 22. Scoped, Non-Bearer Execution Capability . . . . . . 67 8.8. 23. Mandatory Finality Sink Verification . . . . . . . . 68 8.9. 24. Agent Sandbox and Protected Egress . . . . . . . . . 69 8.10. 25. Credential-Release and Protected Key-Use Finality . 69 8.11. 26. Confidential-VM and User-Controlled Key Authority . 70 8.12. 27. Multi-Agent Delegation . . . . . . . . . . . . . . . 71 8.13. 28. Model-Path and Downstream Effectuation Separation . 71 8.14. 29. Hardware Finality Latch and Accelerator Transfers . 72 8.15. 30. Hardware Watchdog and Revocation Interlock . . . . . 72 8.16. 31. Confidential Governance VM and Hardware-Attested Effectuation . . . . . . . . . . . . . . . . . . . . . . 73 8.17. 32. Portable Cloud Workloads and Policy-Version Fencing . . . . . . . . . . . . . . . . . . . . . . . . 73 8.18. 33. Atomic State, Replay Prevention and Recovery . . . . 74 8.19. 34. Multiple Finality Sinks and Receiving-Side Enforcement . . . . . . . . . . . . . . . . . . . . . . 75 8.20. 35. Fail-Closed Handling . . . . . . . . . . . . . . . . 75 9. Architecture Summary . . . . . . . . . . . . . . . . . . . . 76 9.1. 36. General Summary . . . . . . . . . . . . . . . . . . 76 9.2. 37. Protected Agent Execution . . . . . . . . . . . . . 76 9.3. 38. Transaction-Bound Credential Control . . . . . . . . 77 9.4. 39. Protected State and Atomic Finality . . . . . . . . 77 9.5. 40. Multi-Agent Delegation . . . . . . . . . . . . . . . 78 9.6. 41. Model-Path and Effectuation-Path Separation . . . . 78 9.7. 42. Hardware-Assisted Finality . . . . . . . . . . . . . 78 9.8. 43. Confidential Governance and Key Authority . . . . . 79 9.9. 44. Monitoring and Revocation . . . . . . . . . . . . . 79 9.10. 45. Cross-Cloud Portability . . . . . . . . . . . . . . 79 9.11. 46. Independent Downstream Finality . . . . . . . . . . 80 9.12. 47. Technical Advantages . . . . . . . . . . . . . . . . 80 9.13. 48. General Inventive Principle . . . . . . . . . . . . 81 Das Expires 19 April 2027 [Page 5] Internet-Draft Protected AI Execution Finality October 2026 10. Terminology and Definitions . . . . . . . . . . . . . . . . . 82 10.1. 1. AI-Agent Execution Environment . . . . . . . . . . . 82 10.2. 2. Proposed Operation and Candidate Act . . . . . . . . 82 10.3. 3. Externally Effective Operation . . . . . . . . . . . 82 10.4. 4. Non-Effective State (NES) . . . . . . . . . . . . . 83 10.5. 5. Mandatory Interception and Mediation . . . . . . . . 83 10.6. 6. Execution-Finality Boundary . . . . . . . . . . . . 83 10.7. 7. Finality Sink . . . . . . . . . . . . . . . . . . . 83 10.8. 8. Protected Enforcement Domain (PED) and Cryptographically Isolated Enforcement Domain (CIED) . 84 10.9. 9. Protected Isolation from Agent Control . . . . . . . 84 10.10. 10. Non-Bypassable Governed Execution Path . . . . . . 85 10.11. 11. Finality Sink Verification . . . . . . . . . . . . 85 10.12. 12. Fail-Closed Enforcement . . . . . . . . . . . . . . 85 10.13. 13. Authority Object . . . . . . . . . . . . . . . . . 86 10.14. 14. Candidate Act Descriptor (CAD) . . . . . . . . . . 86 10.15. 15. Canonical Descriptor and Equality Verification . . 86 10.16. 16. Authority Predicate and Protected Authorization Predicate . . . . . . . . . . . . . . . . . . . . . . . 87 10.17. 17. Authorized Purpose and Execution Scope . . . . . . 87 10.18. 18. Protected Validation Evidence . . . . . . . . . . . 88 10.19. 19. Ledger-Anchored Validation Receipt (LAVR) and Egress LAVR . . . . . . . . . . . . . . . . . . . . . . . . . 88 10.20. 20. Zero-Knowledge Ledger-Anchored Validation Receipt (ZK-LAVR) . . . . . . . . . . . . . . . . . . . . . . . 88 10.21. 21. Protected Evidence Commitment and Ordering . . . . 89 10.22. 22. Scoped Execution Capability . . . . . . . . . . . . 89 10.23. 23. Non-Bearer Capability . . . . . . . . . . . . . . . 89 10.24. 24. Human Approval and Approval Artifact . . . . . . . 90 10.25. 25. Protected Policy State and Policy Epoch . . . . . . 90 10.26. 26. Runtime Execution Context . . . . . . . . . . . . . 91 10.27. 27. Nonce, Freshness, and Expiry . . . . . . . . . . . 91 10.28. 28. Revocation . . . . . . . . . . . . . . . . . . . . 91 10.29. 29. Capability Consumption . . . . . . . . . . . . . . 92 10.30. 30. Atomic Protected-State Transition . . . . . . . . . 92 10.31. 31. Formal Candidate Act State Machine . . . . . . . . 93 10.32. 32. Replay and Unauthorized Reuse . . . . . . . . . . . 93 10.33. 33. Duplicate External Effect Prevention . . . . . . . 93 10.34. 34. Crash, Retry, and Recovery . . . . . . . . . . . . 94 10.35. 35. Audit Evidence . . . . . . . . . . . . . . . . . . 94 10.36. 36. Bounded-Time and Latency-Aware Enforcement . . . . 95 10.37. 37. Algorithmic Logic Fingerprint (ALF) . . . . . . . . 95 10.38. 38. Algorithmic Intent Fingerprint (AIF) . . . . . . . 95 10.39. 39. Runtime Behavioral Descriptor (RBD) . . . . . . . . 96 10.40. 40. Tool and Workflow Graph . . . . . . . . . . . . . . 96 10.41. 41. Provenance and Taint . . . . . . . . . . . . . . . 97 10.42. 42. Untrusted Input Influence . . . . . . . . . . . . . 97 10.43. 43. Self-Mutation . . . . . . . . . . . . . . . . . . . 97 Das Expires 19 April 2027 [Page 6] Internet-Draft Protected AI Execution Finality October 2026 10.44. 44. Delegation . . . . . . . . . . . . . . . . . . . . 98 10.45. 45. Delegation Limits . . . . . . . . . . . . . . . . . 98 10.46. 46. Candidate Deployment Act . . . . . . . . . . . . . 99 10.47. 47. Supply-Chain Authority Object . . . . . . . . . . . 99 10.48. 48. Screen-State Finality Object (SSFO) . . . . . . . . 99 10.49. 49. Network Destination, Endpoint, and Route Scope . . 100 10.50. 50. Credential Broker . . . . . . . . . . . . . . . . . 100 10.51. 51. Surrogate Credentials . . . . . . . . . . . . . . . 101 10.52. 52. Protected Credential Release . . . . . . . . . . . 101 10.53. 53. Privileged Connector . . . . . . . . . . . . . . . 101 10.54. 54. Service-Mesh and Proxy Finality Enforcement . . . . 102 10.55. 55. Protected Computation Admission . . . . . . . . . . 102 10.56. 56. Model Authorization and External Execution Authorization . . . . . . . . . . . . . . . . . . . . . 103 10.57. 57. Candidate Commerce Act . . . . . . . . . . . . . . 103 10.58. 58. Destination Resolution and Redirect Control . . . . 103 10.59. 59. Confidential Virtual Machine (Confidential VM) . . 104 10.60. 60. Hardware Attestation . . . . . . . . . . . . . . . 104 10.61. 61. Hardware Trust Root and Virtual Trusted Platform Module (vTPM) . . . . . . . . . . . . . . . . . . . . . 105 10.62. 62. Hardware Composite Algorithmic Logic Fingerprint (ALF) . . . . . . . . . . . . . . . . . . . . . . . . . 105 10.63. 63. User-Controlled Root Key . . . . . . . . . . . . . 105 10.64. 64. Derived and Wrapped Keys . . . . . . . . . . . . . 106 10.65. 65. Cryptographic Authorization Commitment . . . . . . 106 10.66. 66. Hardware Freshness . . . . . . . . . . . . . . . . 107 10.67. 67. Hardware Finality Latch . . . . . . . . . . . . . . 107 10.68. 68. Candidate Fabric Transfer Act . . . . . . . . . . . 107 10.69. 69. Virtual-Machine Snapshot Rollback . . . . . . . . . 108 10.70. 70. Migration, Recovery, and Failover . . . . . . . . . 108 10.71. 71. Workload and Tenant Identity . . . . . . . . . . . 109 10.72. 72. Cloud Control Plane . . . . . . . . . . . . . . . . 109 10.73. 73. Watchdog Monitoring State . . . . . . . . . . . . . 109 10.74. 74. Quarantine . . . . . . . . . . . . . . . . . . . . 110 10.75. 75. Multiple Finality Sinks . . . . . . . . . . . . . . 110 10.76. 76. Distributed Revocation . . . . . . . . . . . . . . 111 10.77. 77. Out-of-Band Monitoring and Inline Enforcement . . . 111 10.78. 78. Cross-Component Authorization Consistency . . . . . 111 10.79. 1. Protected Enforcement Domain (PED) . . . . . . . . . 112 10.80. 2. Finality Sink (FS) . . . . . . . . . . . . . . . . . 112 10.81. 3. Candidate Act (CA) . . . . . . . . . . . . . . . . . 113 10.82. 4. Compute Plane (CP) . . . . . . . . . . . . . . . . . 113 11. Detailed Execution-Finality Workflows . . . . . . . . . . . . 114 11.1. WF-01 — Universal Protected Execution-Finality Workflow for AI and Autonomous Computing Systems . . . . . . . . 114 11.1.1. WF-01.1 — Technical Field and Purpose . . . . . . . 114 11.1.2. WF-01.2 — Participating Technical Components . . . . 114 11.1.3. WF-01.3 — System Initialization . . . . . . . . . . 116 Das Expires 19 April 2027 [Page 7] Internet-Draft Protected AI Execution Finality October 2026 11.1.4. WF-01.4 — Establishment of the Governed Execution Path . . . . . . . . . . . . . . . . . . . . . . . . 117 11.1.5. WF-01.5 — Generation of a Candidate Act . . . . . . 118 11.1.6. WF-01.6 — Interception and Non-Effective Staging . . 118 11.1.7. WF-01.7 — Construction of the Candidate Act Descriptor . . . . . . . . . . . . . . . . . . . . . 119 11.1.8. WF-01.8 — Acquisition of Applicable Authority . . . 121 11.1.9. WF-01.9 — Protected Authorization-Predicate Validation . . . . . . . . . . . . . . . . . . . . . 122 11.1.10. WF-01.10 — Protected Authorization-State Operation . . . . . . . . . . . . . . . . . . . . . . 123 11.1.11. WF-01.11 — Generation and Commitment of Protected Validation Evidence . . . . . . . . . . . . . . . . . 124 11.1.12. WF-01.12 — Protected Finality Transaction . . . . . 125 11.1.13. WF-01.13 — Generation of Scoped Non-Bearer Capability . . . . . . . . . . . . . . . . . . . . . 126 11.1.14. WF-01.14 — Transfer or Availability of the Capability . . . . . . . . . . . . . . . . . . . . . 127 11.1.15. WF-01.15 — Reconstruction or Verification at the Finality Sink . . . . . . . . . . . . . . . . . . . . 127 11.1.16. WF-01.16 — Capability Verification at the Finality Sink . . . . . . . . . . . . . . . . . . . . . . . . 128 11.1.17. WF-01.17 — Protected Capability Consumption . . . . 129 11.1.18. WF-01.18 — Controlled External Effectuation . . . . 130 11.1.19. WF-01.19 — Illustrative Network-Egress Implementation . . . . . . . . . . . . . . . . . . . 131 11.1.20. WF-01.20 — Failure, Timeout, and Denial Handling . . 132 11.1.21. WF-01.21 — Concurrency, Crash Recovery, and Duplicate-Effect Handling . . . . . . . . . . . . . . 133 11.1.22. WF-01.22 — Alternative Structural Implementations . 133 11.1.23. WF-01.23 — Technical Result . . . . . . . . . . . . 134 11.2. WF-02 — Protected AI-Agent Sandbox Isolation, Mandatory Interception, and Host Egress Enforcement . . . . . . . 135 11.2.1. WF-02.1 — Technical Purpose . . . . . . . . . . . . 135 11.2.2. WF-02.2 — Participating Components . . . . . . . . . 135 11.2.3. WF-02.3 — Establishment of the Sandbox Trust Boundary . . . . . . . . . . . . . . . . . . . . . . 136 11.2.4. WF-02.4 — Identification of Governed Effectuation Paths . . . . . . . . . . . . . . . . . . . . . . . . 137 11.2.5. WF-02.5 — Mandatory Mediation and Path-Coverage Condition . . . . . . . . . . . . . . . . . . . . . . 138 11.2.6. WF-02.6 — Agent Operation Generation . . . . . . . . 138 11.2.7. WF-02.7 — Interception Before Effectuation . . . . . 139 11.2.8. WF-02.8 — Non-Effective Staging and Immutable Request Representation . . . . . . . . . . . . . . . . . . . 140 11.2.9. WF-02.9 — Candidate Sandbox Egress Act Descriptor . 141 11.2.10. WF-02.10 — Retrieval of Sandbox Egress Authority Object . . . . . . . . . . . . . . . . . . . . . . . 142 Das Expires 19 April 2027 [Page 8] Internet-Draft Protected AI Execution Finality October 2026 11.2.11. WF-02.11 — Protected Authorization-Predicate Validation . . . . . . . . . . . . . . . . . . . . . 143 11.2.12. WF-02.12 — Protected Grant-State and Freshness Handling . . . . . . . . . . . . . . . . . . . . . . 144 11.2.13. WF-02.13 — Egress Validation-Evidence Commitment . . 145 11.2.14. WF-02.14 — Sandbox Egress Capability Issuance . . . 146 11.2.15. WF-02.15 — Independent Host Finality Sink Verification . . . . . . . . . . . . . . . . . . . . 147 11.2.16. WF-02.16 — Host Shell and Executable-Specific Enforcement . . . . . . . . . . . . . . . . . . . . . 148 11.2.17. WF-02.17 — Persistent File and Host-State Mutation Enforcement . . . . . . . . . . . . . . . . . . . . . 149 11.2.18. WF-02.18 — Network and API Egress Enforcement . . . 150 11.2.19. WF-02.19 — Credential and Connector Boundary . . . . 150 11.2.20. WF-02.20 — Continuous Sandbox Egress and Micro-Receipts . . . . . . . . . . . . . . . . . . . 151 11.2.21. WF-02.21 — Runtime Drift, Revocation, and Policy Updates . . . . . . . . . . . . . . . . . . . . . . . 151 11.2.22. WF-02.22 — Failure and Containment Handling . . . . 152 11.2.23. WF-02.23 — Crash, Retry, and Capability-Reuse Handling . . . . . . . . . . . . . . . . . . . . . . 153 11.2.24. WF-02.24 — Alternative Enforcement Implementations . . . . . . . . . . . . . . . . . . . 153 11.2.25. WF-02.25 — Technical Verification and Test Conditions . . . . . . . . . . . . . . . . . . . . . 154 11.2.26. WF-02.26 — Technical Effect . . . . . . . . . . . . 155 11.3. WF-03 — Network Authorization, Canonical Requests, Destination Resolution, Redirect Consistency, and Executable-Specific Egress Control . . . . . . . . . . 156 11.3.1. WF-03.1 — Technical Purpose . . . . . . . . . . . . 156 11.3.2. WF-03.2 — Participating Technical Components . . . . 157 11.3.3. WF-03.3 — Establishment of the Controlled Network Path . . . . . . . . . . . . . . . . . . . . . . . . 159 11.3.4. WF-03.4 — Candidate Network Act Generation . . . . . 159 11.3.5. WF-03.5 — Capture of the Actual Request Representation . . . . . . . . . . . . . . . . . . . 160 11.3.6. WF-03.6 — Canonical Network Operation Descriptor . . 161 11.3.7. WF-03.7 — Request-Normalization Rules . . . . . . . 162 11.3.8. WF-03.8 — Destination Classification and Resolution . . . . . . . . . . . . . . . . . . . . . 163 11.3.9. WF-03.9 — Resolution-Dependent Authorization . . . . 164 11.3.10. WF-03.10 — DNS Rebinding and Address-Substitution Handling . . . . . . . . . . . . . . . . . . . . . . 165 11.3.11. WF-03.11 — Executable-Specific Network Authorization . . . . . . . . . . . . . . . . . . . . 166 11.3.12. WF-03.12 — Combined Executable and Destination Scope . . . . . . . . . . . . . . . . . . . . . . . . 167 11.3.13. WF-03.13 — Protected Authority Validation . . . . . 168 Das Expires 19 April 2027 [Page 9] Internet-Draft Protected AI Execution Finality October 2026 11.3.14. WF-03.14 — Protected Grant-State and Evidence Commitment . . . . . . . . . . . . . . . . . . . . . 170 11.3.15. WF-03.15 — Scoped Network Egress Capability . . . . 171 11.3.16. WF-03.16 — Verification Immediately Before Network Effectuation . . . . . . . . . . . . . . . . . . . . 172 11.3.17. WF-03.17 — Redirection and Multi-Hop Request Control . . . . . . . . . . . . . . . . . . . . . . . 173 11.3.18. WF-03.18 — Connection Reuse, HTTP Multiplexing, and Session Binding . . . . . . . . . . . . . . . . . . . 174 11.3.19. WF-03.19 — Encrypted Traffic and Application-Layer Visibility . . . . . . . . . . . . . . . . . . . . . 175 11.3.20. WF-03.20 — Proxy, Service-Mesh, and Network-Hardware Alternatives . . . . . . . . . . . . . . . . . . . . 176 11.3.21. WF-03.21 — Time-of-Check and Time-of-Use Protection . . . . . . . . . . . . . . . . . . . . . 176 11.3.22. WF-03.22 — Continuous Network Egress and Rolling Authorization . . . . . . . . . . . . . . . . . . . . 177 11.3.23. WF-03.23 — Protected Capability Consumption and Retry Handling . . . . . . . . . . . . . . . . . . . . . . 178 11.3.24. WF-03.24 — Failure and Fail-Closed Conditions . . . 179 11.3.25. WF-03.25 — Illustrative End-to-End API Egress Implementation . . . . . . . . . . . . . . . . . . . 180 11.3.26. WF-03.26 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . . 181 11.3.27. WF-03.27 — Alternative Authorization Granularity . . 183 11.3.28. WF-03.28 — Structural and Security Variations . . . 183 11.3.29. WF-03.29 — Technical Effect . . . . . . . . . . . . 184 11.4. WF-04 — Transaction-Bound Agent Authorization, Protected Grant-State Consumption, Credential Broker, and Atomic Credential Effectuation . . . . . . . . . . . . . . . . 185 11.4.1. WF-04.1 — Technical Purpose . . . . . . . . . . . . 185 11.4.2. WF-04.2 — Participating Components . . . . . . . . . 186 11.4.3. WF-04.3 — Credential and Authorization Separation . 188 11.4.4. WF-04.4 — Establishment of Protected Credential Custody . . . . . . . . . . . . . . . . . . . . . . . 188 11.4.5. WF-04.5 — Non-Authoritative Credential Reference . . 189 11.4.6. WF-04.6 — Candidate Credential-Mediated Act Generation . . . . . . . . . . . . . . . . . . . . . 190 11.4.7. WF-04.7 — Interception and Non-Effective State . . . 191 11.4.8. WF-04.8 — Canonical Operation Descriptor . . . . . . 192 11.4.9. WF-04.9 — Normalization and Actual-Operation Correspondence . . . . . . . . . . . . . . . . . . . 194 11.4.10. WF-04.10 — Protected Authority Object . . . . . . . 194 11.4.11. WF-04.11 — Protected Authorization Predicates . . . 195 11.4.12. WF-04.12 — Protected Authorization-Grant Record . . 196 11.4.13. WF-04.13 — Protected Grant-State Reservation . . . . 197 11.4.14. WF-04.14 — Concurrency and Double-Consumption Prevention . . . . . . . . . . . . . . . . . . . . . 198 Das Expires 19 April 2027 [Page 10] Internet-Draft Protected AI Execution Finality October 2026 11.4.15. WF-04.15 — Protected Validation-Evidence Commitment . . . . . . . . . . . . . . . . . . . . . 199 11.4.16. WF-04.16 — Protected Credential-Finality Transaction . . . . . . . . . . . . . . . . . . . . . 200 11.4.17. WF-04.17 — Scoped Credential-Effectuation Capability . . . . . . . . . . . . . . . . . . . . . 201 11.4.18. WF-04.18 — Authenticated Credential-Executor Interface . . . . . . . . . . . . . . . . . . . . . . 202 11.4.19. WF-04.19 — Independent Verification of the Actual Operation . . . . . . . . . . . . . . . . . . . . . . 202 11.4.20. WF-04.20 — Finality Sink Verification Predicate . . 203 11.4.21. WF-04.21 — Protected Credential Selection and Release . . . . . . . . . . . . . . . . . . . . . . . 205 11.4.22. WF-04.22 — Surrogate Credential Substitution Variant . . . . . . . . . . . . . . . . . . . . . . . 205 11.4.23. WF-04.23 — Binding Credential Substitution to the Exact Request . . . . . . . . . . . . . . . . . . . . 206 11.4.24. WF-04.24 — Redirect and Credential-Leakage Prevention . . . . . . . . . . . . . . . . . . . . . 207 11.4.25. WF-04.25 — Atomic Credential Application and Effectuation Boundary . . . . . . . . . . . . . . . . 208 11.4.26. WF-04.26 — Protected Effectuation Outcome State . . 209 11.4.27. WF-04.27 — Crash Recovery and Duplicate-Effect Prevention . . . . . . . . . . . . . . . . . . . . . 210 11.4.28. WF-04.28 — Human Approval as a Protected Predicate . . . . . . . . . . . . . . . . . . . . . . 211 11.4.29. WF-04.29 — Multiple Credential and Effectuation Boundaries . . . . . . . . . . . . . . . . . . . . . 211 11.4.30. WF-04.30 — Illustrative End-to-End Enterprise API Implementation . . . . . . . . . . . . . . . . . . . 212 11.4.31. WF-04.31 — Alternative Credential Implementations . 213 11.4.32. WF-04.32 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . . 214 11.4.33. WF-04.33 — Technical Result . . . . . . . . . . . . 216 11.5. WF-05 — Privileged Connector Isolation, Authenticated Inter-Component Communication, Independent Executor Verification, and Cross-Component Finality Consistency 217 11.5.1. WF-05.1 — Technical Purpose . . . . . . . . . . . . 217 11.5.2. WF-05.2 — Participating Technical Components . . . . 218 11.5.3. WF-05.3 — Establishment of the Agent-to-Connector Trust Boundary . . . . . . . . . . . . . . . . . . . 220 11.5.4. WF-05.4 — Privileged Connector Security Configuration . . . . . . . . . . . . . . . . . . . . 220 11.5.5. WF-05.5 — Authentication of Inter-Component Communication . . . . . . . . . . . . . . . . . . . . 221 11.5.6. WF-05.6 — Connector Identity and Attestation . . . . 222 11.5.7. WF-05.7 — Candidate Connector Act Generation . . . . 223 Das Expires 19 April 2027 [Page 11] Internet-Draft Protected AI Execution Finality October 2026 11.5.8. WF-05.8 — Mandatory Interception and Non-Effective Staging . . . . . . . . . . . . . . . . . . . . . . . 224 11.5.9. WF-05.9 — Construction of an Operation-Specific Canonical Descriptor . . . . . . . . . . . . . . . . 225 11.5.10. WF-05.10 — Cryptographic Authorization Commitment . 226 11.5.11. WF-05.11 — Protected Authority Validation . . . . . 227 11.5.12. WF-05.12 — Protected Grant-State Validation and Consumption . . . . . . . . . . . . . . . . . . . . . 228 11.5.13. WF-05.13 — Protected Validation-Evidence Commitment . . . . . . . . . . . . . . . . . . . . . 229 11.5.14. WF-05.14 — Operation-Scoped Execution Capability . . 230 11.5.15. WF-05.15 — Protected Capability Delivery . . . . . . 231 11.5.16. WF-05.16 — Independent Executor Verification . . . . 232 11.5.17. WF-05.17 — Independent Verification Predicate . . . 233 11.5.18. WF-05.18 — Cross-Component Authorization Consistency . . . . . . . . . . . . . . . . . . . . . 234 11.5.19. WF-05.19 — Mathematical Cross-Component Consistency Condition . . . . . . . . . . . . . . . . . . . . . . 235 11.5.20. WF-05.20 — Protection Against Cross-Component State Drift . . . . . . . . . . . . . . . . . . . . . . . . 236 11.5.21. WF-05.21 — Authorization Epoch and Revocation Fence . . . . . . . . . . . . . . . . . . . . . . . . 237 11.5.22. WF-05.22 — Protection Against the Confused-Deputy Condition . . . . . . . . . . . . . . . . . . . . . . 238 11.5.23. WF-05.23 — Credential and Resource Isolation . . . . 239 11.5.24. WF-05.24 — Final Operation Binding and Mutation Prevention . . . . . . . . . . . . . . . . . . . . . 239 11.5.25. WF-05.25 — Multiple Effectuation Boundaries . . . . 240 11.5.26. WF-05.26 — Illustrative End-to-End Privileged Connector Implementation . . . . . . . . . . . . . . 240 11.5.27. WF-05.27 — Alternative Host and Distributed Implementations . . . . . . . . . . . . . . . . . . . 242 11.5.28. WF-05.28 — Failure, Timeout, and Recovery Handling . . . . . . . . . . . . . . . . . . . . . . 243 11.5.29. WF-05.29 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . . 244 11.5.30. WF-05.30 — Technical Effect . . . . . . . . . . . . 246 11.6. WF-06 — Untrusted-Input Provenance, Process-Lineage Influence Propagation, Taint-State Authorization Degradation, and Protected Egress Finality . . . . . . 247 11.6.1. WF-06.1 — Technical Purpose . . . . . . . . . . . . 247 11.6.2. WF-06.2 — Participating Technical Components . . . . 248 11.6.3. WF-06.3 — Instruction Trust Hierarchy . . . . . . . 250 11.6.4. WF-06.4 — Source and Context-Unit Identification . . 250 11.6.5. WF-06.5 — Connector Boundary Receipt . . . . . . . . 252 11.6.6. WF-06.6 — Construction of the Instruction Taint Boundary Object . . . . . . . . . . . . . . . . . . . 253 11.6.7. WF-06.7 — Influence-State Representation . . . . . . 254 Das Expires 19 April 2027 [Page 12] Internet-Draft Protected AI Execution Finality October 2026 11.6.8. WF-06.8 — Secure Execution-Lineage Identity . . . . 255 11.6.9. WF-06.9 — Initial Influence-State Assignment . . . . 256 11.6.10. WF-06.10 — Defined Untrusted-Information Interaction Events . . . . . . . . . . . . . . . . . . . . . . . 257 11.6.11. WF-06.11 — Protected Influence-State Update . . . . 258 11.6.12. WF-06.12 — Process Creation and Descendant Propagation . . . . . . . . . . . . . . . . . . . . . 259 11.6.13. WF-06.13 — Process Execution and Image Replacement . . . . . . . . . . . . . . . . . . . . . 260 11.6.14. WF-06.14 — Session, Agent, and Worker-Lineage Propagation . . . . . . . . . . . . . . . . . . . . . 260 11.6.15. WF-06.15 — IPC, Shared Memory, and Cross-Process Information Transfer . . . . . . . . . . . . . . . . 261 11.6.16. WF-06.16 — Protected Event-Update Ordering . . . . . 262 11.6.17. WF-06.17 — Influence-Based Authorization Degradation . . . . . . . . . . . . . . . . . . . . . 263 11.6.18. WF-06.18 — Removal of a Broader Authorization Lane . . . . . . . . . . . . . . . . . . . . . . . . 264 11.6.19. WF-06.19 — Candidate Act Formation Following Untrusted Input . . . . . . . . . . . . . . . . . . . . . . . . 265 11.6.20. WF-06.20 — Candidate Act Provenance and Influence Validation . . . . . . . . . . . . . . . . . . . . . 266 11.6.21. WF-06.21 — Instruction Taint Boundary Predicate . . 267 11.6.22. WF-06.22 — Protected Trust Elevation . . . . . . . . 268 11.6.23. WF-06.23 — Protected Revalidation and Influence-State Reset . . . . . . . . . . . . . . . . . . . . . . . . 269 11.6.24. WF-06.24 — Binding Influence State to the Scoped Execution Capability . . . . . . . . . . . . . . . . 269 11.6.25. WF-06.25 — Prevention of Stale Broader-Authority Reuse . . . . . . . . . . . . . . . . . . . . . . . . 271 11.6.26. WF-06.26 — Independent Finality Sink Verification . 272 11.6.27. WF-06.27 — Concrete Process-Lineage Example . . . . 273 11.6.28. WF-06.28 — Process-Lineage Implementation Variants . . . . . . . . . . . . . . . . . . . . . . 274 11.6.29. WF-06.29 — Completeness and Conservative Attribution . . . . . . . . . . . . . . . . . . . . . 275 11.6.30. WF-06.30 — Crash, Restart, and Lineage-State Continuity . . . . . . . . . . . . . . . . . . . . . 276 11.6.31. WF-06.31 — Failure and Fail-Closed Handling . . . . 276 11.6.32. WF-06.32 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . . 277 11.6.33. WF-06.33 — Technical Effect . . . . . . . . . . . . 279 11.7. WF-07 — Protected Browser Automation, Computer-Use Actions, Screen-State Finality Object, and GUI Effectuation Control . . . . . . . . . . . . . . . . . . . . . . . . 280 11.7.1. WF-07.1 — Technical Purpose . . . . . . . . . . . . 280 11.7.2. WF-07.2 — Participating Technical Components . . . . 281 Das Expires 19 April 2027 [Page 13] Internet-Draft Protected AI Execution Finality October 2026 11.7.3. WF-07.3 — Identification of the GUI Effectuation Boundary . . . . . . . . . . . . . . . . . . . . . . 283 11.7.4. WF-07.4 — Mandatory GUI Action Mediation . . . . . . 284 11.7.5. WF-07.5 — Candidate GUI Action Generation . . . . . 285 11.7.6. WF-07.6 — Interception and Non-Effective Staging . . 285 11.7.7. WF-07.7 — Contemporaneous Screen-State Capture . . . 286 11.7.8. WF-07.8 — Screen-State Digest . . . . . . . . . . . 288 11.7.9. WF-07.9 — Semantic Interface Measurement . . . . . . 288 11.7.10. WF-07.10 — Semantic-State Commitment . . . . . . . . 290 11.7.11. WF-07.11 — Coordinate-System Normalization . . . . . 290 11.7.12. WF-07.12 — Geometric Target Verification . . . . . . 291 11.7.13. WF-07.13 — Semantic-Geometric Equivalence . . . . . 292 11.7.14. WF-07.14 — Overlay, Z-Order, and Occlusion Verification . . . . . . . . . . . . . . . . . . . . 293 11.7.15. WF-07.15 — Hardware-Rendered and Semantic Coherence . . . . . . . . . . . . . . . . . . . . . . 294 11.7.16. WF-07.16 — Screen-Action Descriptor . . . . . . . . 295 11.7.17. WF-07.17 — Construction of the Screen-State Finality Object . . . . . . . . . . . . . . . . . . . . . . . 296 11.7.18. WF-07.18 — Application Context and Target-Origin Validation . . . . . . . . . . . . . . . . . . . . . 297 11.7.19. WF-07.19 — Purpose and Risk-Class Validation . . . . 298 11.7.20. WF-07.20 — Protected Human Authorization . . . . . . 298 11.7.21. WF-07.21 — Protected Predicate Evaluation . . . . . 299 11.7.22. WF-07.22 — Protected State and Validation-Evidence Commitment . . . . . . . . . . . . . . . . . . . . . 300 11.7.23. WF-07.23 — Scoped Screen-Action Capability . . . . . 302 11.7.24. WF-07.24 — Immediate Pre-Dispatch Verification . . . 303 11.7.25. WF-07.25 — Time-of-Check and Time-of-Use Protection . . . . . . . . . . . . . . . . . . . . . 304 11.7.26. WF-07.26 — Protected Capability Consumption . . . . 305 11.7.27. WF-07.27 — Browser Form Submission Example . . . . . 306 11.7.28. WF-07.28 — Payment-Confirmation and High-Risk Action Example . . . . . . . . . . . . . . . . . . . . . . . 307 11.7.29. WF-07.29 — Terminal and Native-Application Variations . . . . . . . . . . . . . . . . . . . . . 308 11.7.30. WF-07.30 — Failure and Fail-Closed Handling . . . . 309 11.7.31. WF-07.31 — Agent Context Correction After Denial . . 310 11.7.32. WF-07.32 — Alternative Structural Implementations . 310 11.7.33. WF-07.33 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . . 311 11.7.34. WF-07.34 — Technical Effect . . . . . . . . . . . . 313 11.8. WF-08 — Autonomous Commerce, Purchase Authorization, Payment Instructions, Protected Spending Constraints, and Commerce Finality Sink Enforcement . . . . . . . . . . 314 11.8.1. WF-08.1 — Technical Purpose . . . . . . . . . . . . 314 11.8.2. WF-08.2 — Participating Technical Components . . . . 315 Das Expires 19 April 2027 [Page 14] Internet-Draft Protected AI Execution Finality October 2026 11.8.3. WF-08.3 — Identification of the Commercial Effectuation Boundary . . . . . . . . . . . . . . . . 317 11.8.4. WF-08.4 — Establishment of the Governed Commerce Path . . . . . . . . . . . . . . . . . . . . . . . . 318 11.8.5. WF-08.5 — User Mandate Formation . . . . . . . . . . 319 11.8.6. WF-08.6 — Protected Mandate Corridor . . . . . . . . 320 11.8.7. WF-08.7 — Candidate Commerce Act Generation . . . . 321 11.8.8. WF-08.8 — Mandatory Interception and Non-Effective Staging . . . . . . . . . . . . . . . . . . . . . . . 322 11.8.9. WF-08.9 — Candidate Commerce Act Descriptor . . . . 323 11.8.10. WF-08.10 — Canonical Commercial Descriptor . . . . . 325 11.8.11. WF-08.11 — Exact Monetary Representation . . . . . . 326 11.8.12. WF-08.12 — Merchant and Counterparty Verification . 327 11.8.13. WF-08.13 — Merchant Offer and Settlement-Descriptor Formation . . . . . . . . . . . . . . . . . . . . . . 328 11.8.14. WF-08.14 — Protected Market-Compliance Authority Object . . . . . . . . . . . . . . . . . . . . . . . 329 11.8.15. WF-08.15 — AIF, ALF, and RBD Validation . . . . . . 330 11.8.16. WF-08.16 — Protected Commercial Authorization Predicates . . . . . . . . . . . . . . . . . . . . . 331 11.8.17. WF-08.17 — Protected Spending-Budget State . . . . . 332 11.8.18. WF-08.18 — Atomic Budget Reservation . . . . . . . . 333 11.8.19. WF-08.19 — Spending and Authorization-State Consistency . . . . . . . . . . . . . . . . . . . . . 334 11.8.20. WF-08.20 — Protected Commerce Validation Evidence . 334 11.8.21. WF-08.21 — Privacy-Preserving Market Validation . . 335 11.8.22. WF-08.22 — Commerce Actuation Capability . . . . . . 336 11.8.23. WF-08.23 — Commerce Finality Sink Verification . . . 337 11.8.24. WF-08.24 — Purchase, Payment Authorization, Capture, and Settlement . . . . . . . . . . . . . . . . . . . 339 11.8.25. WF-08.25 — Controlled Payment Credential Application . . . . . . . . . . . . . . . . . . . . . 340 11.8.26. WF-08.26 — Merchant Offer Changes and Settlement Consistency . . . . . . . . . . . . . . . . . . . . . 341 11.8.27. WF-08.27 — Autonomous Auction and Bid Control . . . 342 11.8.28. WF-08.28 — Continuous Commerce and Micro-Validation . . . . . . . . . . . . . . . . . . 343 11.8.29. WF-08.29 — Ranking, Recommendation, and Advertising Effectuation . . . . . . . . . . . . . . . . . . . . 344 11.8.30. WF-08.30 — Protected Commerce Outcome-State Machine . . . . . . . . . . . . . . . . . . . . . . . 345 11.8.31. WF-08.31 — Protected Spending Reservation Release . 346 11.8.32. WF-08.32 — Duplicate Purchase and Payment Protection . . . . . . . . . . . . . . . . . . . . . 347 11.8.33. WF-08.33 — Concrete Autonomous Purchase Example . . 347 11.8.34. WF-08.34 — Example of Merchant-Agent Manipulation . 349 11.8.35. WF-08.35 — Failure and Fail-Closed Handling . . . . 349 11.8.36. WF-08.36 — Implementation Alternatives . . . . . . . 350 Das Expires 19 April 2027 [Page 15] Internet-Draft Protected AI Execution Finality October 2026 11.8.37. WF-08.37 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . . 351 11.8.38. WF-08.38 — Technical Effect . . . . . . . . . . . . 353 11.9. WF-09 — Protected Agent Self-Modification, Policy-Digest Transitions, Developer Approval, and Mutation-Activation Finality . . . . . . . . . . . . . . . . . . . . . . . 354 11.9.1. WF-09.1 — Technical Purpose . . . . . . . . . . . . 354 11.9.2. WF-09.2 — Participating Technical Components . . . . 355 11.9.3. WF-09.3 — Establishment of the Mutation Trust Boundary . . . . . . . . . . . . . . . . . . . . . . 357 11.9.4. WF-09.4 — Identification of Governed Mutation Classes . . . . . . . . . . . . . . . . . . . . . . . 358 11.9.5. WF-09.5 — Candidate Self-Mutation Act Generation . . 359 11.9.6. WF-09.6 — Mandatory Mutation Interception . . . . . 359 11.9.7. WF-09.7 — Non-Effective Mutation Staging . . . . . . 360 11.9.8. WF-09.8 — Pre-Mutation State Measurement . . . . . . 361 11.9.9. WF-09.9 — Proposed Post-Mutation State Measurement . . . . . . . . . . . . . . . . . . . . . 362 11.9.10. WF-09.10 — Canonical Mutation Descriptor . . . . . . 363 11.9.11. WF-09.11 — Configuration Difference and Authority Expansion Analysis . . . . . . . . . . . . . . . . . 365 11.9.12. WF-09.12 — Self-Mutation Authority Object . . . . . 366 11.9.13. WF-09.13 — Protected Baseline and Mutation-Class Validation . . . . . . . . . . . . . . . . . . . . . 367 11.9.14. WF-09.14 — AIF, ALF, and Runtime-Behavior Validation . . . . . . . . . . . . . . . . . . . . . 368 11.9.15. WF-09.15 — Evaluation and Regression-Evidence Generation . . . . . . . . . . . . . . . . . . . . . 368 11.9.16. WF-09.16 — Regression and Safety Evidence Verification . . . . . . . . . . . . . . . . . . . . 369 11.9.17. WF-09.17 — Developer or Operator Approval . . . . . 370 11.9.18. WF-09.18 — Developer Approval as a Protected Predicate . . . . . . . . . . . . . . . . . . . . . . 371 11.9.19. WF-09.19 — Overall Protected Mutation Validation . . 372 11.9.20. WF-09.20 — Protected Mutation-State Record . . . . . 373 11.9.21. WF-09.21 — Protected Validation-Evidence Commitment . . . . . . . . . . . . . . . . . . . . . 375 11.9.22. WF-09.22 — Scoped Self-Modification Capability . . . 376 11.9.23. WF-09.23 — Verification at the Mutation-Activation Finality Sink . . . . . . . . . . . . . . . . . . . . 377 11.9.24. WF-09.24 — Activation Predicate . . . . . . . . . . 377 11.9.25. WF-09.25 — Atomic or Ordered Protected Activation . 379 11.9.26. WF-09.26 — Runtime Policy Publication and Reader Consistency . . . . . . . . . . . . . . . . . . . . . 380 11.9.27. WF-09.27 — Mutation Activation and Actual Runtime Verification . . . . . . . . . . . . . . . . . . . . 380 11.9.28. WF-09.28 — Runtime Revocation and Epoch Advancement . . . . . . . . . . . . . . . . . . . . . 381 Das Expires 19 April 2027 [Page 16] Internet-Draft Protected AI Execution Finality October 2026 11.9.29. WF-09.29 — Policy Mutation and Outstanding Candidate Acts . . . . . . . . . . . . . . . . . . . . . . . . 382 11.9.30. WF-09.30 — Distributed Policy Mutation . . . . . . . 382 11.9.31. WF-09.31 — Self-Modification Versus Downstream Effectuation . . . . . . . . . . . . . . . . . . . . 383 11.9.32. WF-09.32 — Concrete Tool-Policy Mutation Example . . 383 11.9.33. WF-09.33 — Adapter and Model-Configuration Mutation Example . . . . . . . . . . . . . . . . . . . . . . . 385 11.9.34. WF-09.34 — Rollback, Recovery, and Failure Handling . . . . . . . . . . . . . . . . . . . . . . 386 11.9.35. WF-09.35 — Protected Mutation Outcome State . . . . 386 11.9.36. WF-09.36 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . . 388 11.9.37. WF-09.37 — Alternative Technical Implementations . . 390 11.9.38. WF-09.38 — Technical Effect . . . . . . . . . . . . 391 11.10. WF-10 — Protected Multi-Agent Delegation, Parent–Child Authority Derivation, Recursive Delegation Limits, and Sub-Agent Acceptance Finality . . . . . . . . . . . . . 392 11.10.1. WF-10.1 — Technical Purpose . . . . . . . . . . . . 392 11.10.2. WF-10.2 — Participating Technical Components . . . 393 11.10.3. WF-10.3 — Establishment of the Parent Authority Boundary . . . . . . . . . . . . . . . . . . . . . . 395 11.10.4. WF-10.4 — Delegation as a Separately Governed Consequential Act . . . . . . . . . . . . . . . . . . 397 11.10.5. WF-10.5 — Candidate Delegation Act Generation . . . 397 11.10.6. WF-10.6 — Interception and Non-Effective Delegation Staging . . . . . . . . . . . . . . . . . . . . . . . 398 11.10.7. WF-10.7 — Canonical Candidate Delegation Act Descriptor . . . . . . . . . . . . . . . . . . . . . 399 11.10.8. WF-10.8 — Mathematical Descriptor Construction . . 400 11.10.9. WF-10.9 — Subordinate Agent Identity Verification . . . . . . . . . . . . . . . . . . . . 401 11.10.10. WF-10.10 — Delegation Authority Object . . . . . . 402 11.10.11. WF-10.11 — Authority Attenuation Principle . . . . 404 11.10.12. WF-10.12 — Multi-Dimensional Delegated Scope . . . 404 11.10.13. WF-10.13 — Protected Context Handoff Escrow . . . . 405 11.10.14. WF-10.14 — Context Minimization and Integrity Binding . . . . . . . . . . . . . . . . . . . . . . . 406 11.10.15. WF-10.15 — Tool-Scope Attenuation . . . . . . . . . 407 11.10.16. WF-10.16 — Credential and Memory Authority Attenuation . . . . . . . . . . . . . . . . . . . . . 408 11.10.17. WF-10.17 — Protected Budget Allocation . . . . . . 408 11.10.18. WF-10.18 — Atomic Child Budget Reservation . . . . 409 11.10.19. WF-10.19 — Cumulative Budget Containment . . . . . 410 11.10.20. WF-10.20 — Recursive Delegation Constraint . . . . 410 11.10.21. WF-10.21 — Mathematical Recursion-Depth Control . . 411 11.10.22. WF-10.22 — Parent–Child Authority Lineage . . . . . 412 Das Expires 19 April 2027 [Page 17] Internet-Draft Protected AI Execution Finality October 2026 11.10.23. WF-10.23 — Purpose Continuity and Prohibited Authority Laundering . . . . . . . . . . . . . . . . 413 11.10.24. WF-10.24 — ALF, AIF, Provenance, and Runtime Validation . . . . . . . . . . . . . . . . . . . . . 413 11.10.25. WF-10.25 — Protected Delegation Validation Predicate . . . . . . . . . . . . . . . . . . . . . . 414 11.10.26. WF-10.26 — Constrained Delegation Decision . . . . 415 11.10.27. WF-10.27 — Protected Delegation-State Commitment . 416 11.10.28. WF-10.28 — Delegation LAVR Commitment . . . . . . . 416 11.10.29. WF-10.29 — Delegation Capability Generation . . . . 417 11.10.30. WF-10.30 — Delegation Capability Delivery . . . . . 419 11.10.31. WF-10.31 — Independent Delegation-Acceptance Verification . . . . . . . . . . . . . . . . . . . . 419 11.10.32. WF-10.32 — Delegation Acceptance Predicate . . . . 420 11.10.33. WF-10.33 — Controlled Child-Agent Activation . . . 421 11.10.34. WF-10.34 — Separation of Delegation and Downstream Effectuation . . . . . . . . . . . . . . . . . . . . 422 11.10.35. WF-10.35 — Recursive Child Delegation . . . . . . . 422 11.10.36. WF-10.36 — Revocation and Descendant Authority . . 423 11.10.37. WF-10.37 — Return Artifact as a Separate Candidate Act . . . . . . . . . . . . . . . . . . . . . . . . . 423 11.10.38. WF-10.38 — Return Artifact Verification . . . . . . 424 11.10.39. WF-10.39 — Return Artifact Admission Capability . . 425 11.10.40. WF-10.40 — Concrete Parent–Child Research Example . . . . . . . . . . . . . . . . . . . . . . . 426 11.10.41. WF-10.41 — Concrete Recursive Delegation Example . 427 11.10.42. WF-10.42 — Controlled Remote-Agent Implementation . . . . . . . . . . . . . . . . . . . 428 11.10.43. WF-10.43 — Failure and Fail-Closed Handling . . . . 428 11.10.44. WF-10.44 — Crash, Retry, and Delegation Recovery . 429 11.10.45. WF-10.45 — Alternative Technical Implementations . 430 11.10.46. WF-10.46 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . . 431 11.10.47. WF-10.47 — Technical Effect . . . . . . . . . . . . 434 11.11. WF-11 — Protected Autonomous Code Changes, Artifact Signing, Software Supply-Chain Authorization, Agent-Generated Skill Deployment, and Progressive Release Finality . . . . . . . . . . . . . . . . . . . . . . . 435 11.11.1. WF-11.1 — Technical Purpose . . . . . . . . . . . . 435 11.11.2. WF-11.2 — Participating Technical Components . . . 436 11.11.3. WF-11.3 — Establishment of the Software Supply-Chain Trust Boundary . . . . . . . . . . . . . . . . . . . 438 11.11.4. WF-11.4 — Identification of Governed Release Boundaries . . . . . . . . . . . . . . . . . . . . . 439 11.11.5. WF-11.5 — Mandatory Interception and Release-Path Coverage . . . . . . . . . . . . . . . . . . . . . . 440 11.11.6. WF-11.6 — Generation of the Candidate Deployment Act . . . . . . . . . . . . . . . . . . . . . . . . . 441 Das Expires 19 April 2027 [Page 18] Internet-Draft Protected AI Execution Finality October 2026 11.11.7. WF-11.7 — Interception and Non-Effective Staging . 441 11.11.8. WF-11.8 — Construction of the Candidate Deployment Act Descriptor . . . . . . . . . . . . . . . . . . . 442 11.11.9. WF-11.9 — Deterministic Descriptor Encoding . . . . 444 11.11.10. WF-11.10 — Acquisition of the Supply-Chain Authority Object . . . . . . . . . . . . . . . . . . . . . . . 445 11.11.11. WF-11.11 — Authorized Development Purpose Validation . . . . . . . . . . . . . . . . . . . . . 446 11.11.12. WF-11.12 — Approved Logic and Workflow Validation . . . . . . . . . . . . . . . . . . . . . 446 11.11.13. WF-11.13 — Runtime Behavioral and Provenance Validation . . . . . . . . . . . . . . . . . . . . . 447 11.11.14. WF-11.14 — Changed-File and Dependency-Scope Validation . . . . . . . . . . . . . . . . . . . . . 448 11.11.15. WF-11.15 — Credential, Privilege, and Network-Egress Change Validation . . . . . . . . . . . . . . . . . . 449 11.11.16. WF-11.16 — Test, Scan, Review, and Approval Validation . . . . . . . . . . . . . . . . . . . . . 450 11.11.17. WF-11.17 — Protected Release Authorization Predicate . . . . . . . . . . . . . . . . . . . . . . 450 11.11.18. WF-11.18 — Protected Deployment-State Reservation . . . . . . . . . . . . . . . . . . . . . 451 11.11.19. WF-11.19 — Deployment Validation-Evidence Commitment . . . . . . . . . . . . . . . . . . . . . 452 11.11.20. WF-11.20 — Privacy-Preserving Deployment Validation Variant . . . . . . . . . . . . . . . . . . . . . . . 453 11.11.21. WF-11.21 — Protected Deployment-Finality Transaction . . . . . . . . . . . . . . . . . . . . . 454 11.11.22. WF-11.22 — Scoped Release Capability Generation . . 455 11.11.23. WF-11.23 — Artifact and Commit Binding . . . . . . 456 11.11.24. WF-11.24 — Binding Source Changes to Built Artifacts . . . . . . . . . . . . . . . . . . . . . . 457 11.11.25. WF-11.25 — Protected Artifact-Signing and Publication Keys . . . . . . . . . . . . . . . . . . . . . . . . 457 11.11.26. WF-11.26 — Hardware-Latched Release Procedure . . . 458 11.11.27. WF-11.27 — Independent Verification at the Release Finality Sink . . . . . . . . . . . . . . . . . . . . 459 11.11.28. WF-11.28 — Finality-Specific Release Operations . . 460 11.11.29. WF-11.29 — Agent-Generated Skill and Plugin Deployment . . . . . . . . . . . . . . . . . . . . . 461 11.11.30. WF-11.30 — Skill Installation and Activation Finality . . . . . . . . . . . . . . . . . . . . . . 462 11.11.31. WF-11.31 — Separation of Skill Activation from Later Tool Execution . . . . . . . . . . . . . . . . . . . 463 11.11.32. WF-11.32 — Progressive Deployment and Stage-Specific Authority . . . . . . . . . . . . . . . . . . . . . . 463 11.11.33. WF-11.33 — Stage-Associated Micro-LAVRs and Rollout Capabilities . . . . . . . . . . . . . . . . . . . . 464 Das Expires 19 April 2027 [Page 19] Internet-Draft Protected AI Execution Finality October 2026 11.11.34. WF-11.34 — Runtime Drift and Rollout Interruption . . . . . . . . . . . . . . . . . . . . 465 11.11.35. WF-11.35 — Rollout Progression Predicate . . . . . 466 11.11.36. WF-11.36 — Protected Capability Consumption and Duplicate-Release Prevention . . . . . . . . . . . . 467 11.11.37. WF-11.37 — Policy Updates, Revocation, and Artifact Invalidation . . . . . . . . . . . . . . . . . . . . 468 11.11.38. WF-11.38 — Time-of-Check and Time-of-Use Protection . . . . . . . . . . . . . . . . . . . . . 468 11.11.39. WF-11.39 — Crash, Timeout, and Deployment Recovery . . . . . . . . . . . . . . . . . . . . . . 469 11.11.40. WF-11.40 — Illustrative Autonomous Code-Deployment Example . . . . . . . . . . . . . . . . . . . . . . . 471 11.11.41. WF-11.41 — Illustrative Agent-Generated Skill Example . . . . . . . . . . . . . . . . . . . . . . . 472 11.11.42. WF-11.42 — Illustrative Progressive Production Rollout . . . . . . . . . . . . . . . . . . . . . . . 472 11.11.43. WF-11.43 — Failure and Fail-Closed Conditions . . . 473 11.11.44. WF-11.44 — Alternative Technical Implementations . 474 11.11.45. WF-11.45 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . . 475 11.11.46. WF-11.46 — Claim-Specific Technical Support . . . . 478 11.11.47. WF-11.47 — Technical Effect . . . . . . . . . . . . 480 11.12. WF-12 — Protected Cloud-Native Service-Mesh Execution, Sidecar-Proxy Finality, Workload-to-Service Authorization, Route-Bound Capabilities, and Non-Bypassable Cloud Effectuation . . . . . . . . . . . . . . . . . . . . . 481 11.12.1. WF-12.1 — Technical Purpose . . . . . . . . . . . . 481 11.12.2. WF-12.2 — Participating Technical Components . . . 482 11.12.3. WF-12.3 — Establishment of the Cloud Workload Trust Boundary . . . . . . . . . . . . . . . . . . . . . . 485 11.12.4. WF-12.4 — Identification of Governed Cloud Effectuation Boundaries . . . . . . . . . . . . . . . 486 11.12.5. WF-12.5 — Mandatory Interception and Path-Coverage Requirement . . . . . . . . . . . . . . . . . . . . . 487 11.12.6. WF-12.6 — Candidate Cloud Act Generation . . . . . 487 11.12.7. WF-12.7 — Infrastructure Interception Before Effectuation . . . . . . . . . . . . . . . . . . . . 488 11.12.8. WF-12.8 — Non-Effective Staging and Immutable Request Representation . . . . . . . . . . . . . . . . . . . 489 11.12.9. WF-12.9 — Workload and Service Identity Establishment . . . . . . . . . . . . . . . . . . . . 490 11.12.10. WF-12.10 — Construction of the Candidate Cloud Act Descriptor . . . . . . . . . . . . . . . . . . . . . 490 11.12.11. WF-12.11 — Canonical Descriptor Encoding . . . . . 492 11.12.12. WF-12.12 — Acquisition of Applicable Cloud Authority . . . . . . . . . . . . . . . . . . . . . . 493 Das Expires 19 April 2027 [Page 20] Internet-Draft Protected AI Execution Finality October 2026 11.12.13. WF-12.13 — Behavioral-Logic and Runtime Validation . . . . . . . . . . . . . . . . . . . . . 493 11.12.14. WF-12.14 — Destination and Network-Route Validation . . . . . . . . . . . . . . . . . . . . . 494 11.12.15. WF-12.15 — Protected Authorization-Predicate Evaluation . . . . . . . . . . . . . . . . . . . . . 495 11.12.16. WF-12.16 — Protected Authorization-State Handling . . . . . . . . . . . . . . . . . . . . . . 496 11.12.17. WF-12.17 — Protected Cloud Validation-Evidence Commitment . . . . . . . . . . . . . . . . . . . . . 496 11.12.18. WF-12.18 — Protected Cloud-Finality Transaction . . 498 11.12.19. WF-12.19 — Scoped Execution-Enabling Capability Generation . . . . . . . . . . . . . . . . . . . . . 498 11.12.20. WF-12.20 — Source Workload and Service Identity Binding . . . . . . . . . . . . . . . . . . . . . . . 500 11.12.21. WF-12.21 — Mutually Authenticated Transport-Session Binding . . . . . . . . . . . . . . . . . . . . . . . 501 11.12.22. WF-12.22 — Capability Delivery to the Infrastructure Finality Sink . . . . . . . . . . . . . . . . . . . . 502 11.12.23. WF-12.23 — Independent Cloud Finality Sink Verification . . . . . . . . . . . . . . . . . . . . 502 11.12.24. WF-12.24 — Cloud Finality Verification Predicate . 503 11.12.25. WF-12.25 — Controlled Service-Mesh Effectuation . . 504 11.12.26. WF-12.26 — Service-Mesh Bypass Prevention . . . . . 505 11.12.27. WF-12.27 — Unauthorized Service Substitution . . . 505 11.12.28. WF-12.28 — Route and Policy-State Mismatch . . . . 506 11.12.29. WF-12.29 — Multi-Hop Service Invocation . . . . . . 507 11.12.30. WF-12.30 — Message-Bus and Asynchronous Workflow Control . . . . . . . . . . . . . . . . . . . . . . . 507 11.12.31. WF-12.31 — Continuous Service Sessions and Rolling Capabilities . . . . . . . . . . . . . . . . . . . . 508 11.12.32. WF-12.32 — Capability Consumption and Replay Protection . . . . . . . . . . . . . . . . . . . . . 509 11.12.33. WF-12.33 — Distributed Service-Mesh State Consistency . . . . . . . . . . . . . . . . . . . . . 510 11.12.34. WF-12.34 — Policy Updates and Revocation During Runtime . . . . . . . . . . . . . . . . . . . . . . . 511 11.12.35. WF-12.35 — Credential and Privileged Connector Integration . . . . . . . . . . . . . . . . . . . . . 511 11.12.36. WF-12.36 — Crash, Retry, and Incomplete Service Effectuation . . . . . . . . . . . . . . . . . . . . 512 11.12.37. WF-12.37 — Illustrative Cloud-Native Service-Mesh Implementation . . . . . . . . . . . . . . . . . . . 513 11.12.38. WF-12.38 — Illustrative Service Substitution Attack . . . . . . . . . . . . . . . . . . . . . . . 514 11.12.39. WF-12.39 — Illustrative Alternative Network-Path Attack . . . . . . . . . . . . . . . . . . . . . . . 514 11.12.40. WF-12.40 — Alternative Technical Implementations . 515 Das Expires 19 April 2027 [Page 21] Internet-Draft Protected AI Execution Finality October 2026 11.12.41. WF-12.41 — Failure and Fail-Closed Conditions . . . 516 11.12.42. WF-12.42 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . . 517 11.12.43. WF-12.43 — Claim-Specific Technical Support . . . . 520 11.12.44. WF-12.44 — Technical Effect . . . . . . . . . . . . 521 11.13. WF-13 — Protected Pre-Computation Model Admission, Algorithmic Logic Fingerprint Verification, Runtime Behavioral Governance, Model-Loader Authorization, and Separate Downstream Execution Finality . . . . . . . . 522 11.13.1. WF-13.1 — Technical Purpose . . . . . . . . . . . . 522 11.13.2. WF-13.2 — Participating Technical Components . . . 523 11.13.3. WF-13.3 — Establishment of the Computation Admission Boundary . . . . . . . . . . . . . . . . . . . . . . 526 11.13.4. WF-13.4 — Identification of Governed Computation-Start Events . . . . . . . . . . . . . . 526 11.13.5. WF-13.5 — Generation of the Candidate Computation Admission Act . . . . . . . . . . . . . . . . . . . . 527 11.13.6. WF-13.6 — Pending Admission State . . . . . . . . . 528 11.13.7. WF-13.7 — Governed Computation-Context Descriptor . . . . . . . . . . . . . . . . . . . . . 529 11.13.8. WF-13.8 — Canonical Computation Descriptor Formation . . . . . . . . . . . . . . . . . . . . . . 530 11.13.9. WF-13.9 — Acquisition of Applicable Computation Authority . . . . . . . . . . . . . . . . . . . . . . 531 11.13.10. WF-13.10 — Approved Algorithmic Logic Fingerprint Condition . . . . . . . . . . . . . . . . . . . . . . 532 11.13.11. WF-13.11 — Composite ALF and Multi-Component Model Configuration . . . . . . . . . . . . . . . . . . . . 533 11.13.12. WF-13.12 — Authorized Purpose and Context Validation . . . . . . . . . . . . . . . . . . . . . 534 11.13.13. WF-13.13 — Protected Pre-Computation Authorization Predicate . . . . . . . . . . . . . . . . . . . . . . 534 11.13.14. WF-13.14 — Protected Authorization-State Handling . . . . . . . . . . . . . . . . . . . . . . 535 11.13.15. WF-13.15 — Computation-Admission Validation Evidence . . . . . . . . . . . . . . . . . . . . . . 536 11.13.16. WF-13.16 — Computation-Start Authorization Artifact . . . . . . . . . . . . . . . . . . . . . . 537 11.13.17. WF-13.17 — Model and Workflow Measurement Binding . . . . . . . . . . . . . . . . . . . . . . . 538 11.13.18. WF-13.18 — Independent Computation-Admission Verification . . . . . . . . . . . . . . . . . . . . 539 11.13.19. WF-13.19 — Computation Admission Verification Predicate . . . . . . . . . . . . . . . . . . . . . . 540 11.13.20. WF-13.20 — Protected Model-Loader Admission . . . . 541 11.13.21. WF-13.21 — Model Loader Verification Sequence . . . 541 11.13.22. WF-13.22 — Accelerator and Model-State Activation . . . . . . . . . . . . . . . . . . . . . 542 Das Expires 19 April 2027 [Page 22] Internet-Draft Protected AI Execution Finality October 2026 11.13.23. WF-13.23 — Runtime Behavioral Descriptor Formation . . . . . . . . . . . . . . . . . . . . . . 543 11.13.24. WF-13.24 — Runtime Behavioral Drift and Continued Governance . . . . . . . . . . . . . . . . . . . . . 544 11.13.25. WF-13.25 — Pre-Computation and Runtime Authorization Separation . . . . . . . . . . . . . . . . . . . . . 544 11.13.26. WF-13.26 — Separate Downstream Execution Authority . . . . . . . . . . . . . . . . . . . . . . 545 11.13.27. WF-13.27 — Downstream Finality Verification Sequence . . . . . . . . . . . . . . . . . . . . . . 546 11.13.28. WF-13.28 — Example: Approved Model, Unauthorized Tool Operation . . . . . . . . . . . . . . . . . . . . . . 547 11.13.29. WF-13.29 — Example: Unauthorized Adapter Substitution . . . . . . . . . . . . . . . . . . . . 547 11.13.30. WF-13.30 — Example: Retrieval-Policy Modification . . . . . . . . . . . . . . . . . . . . 548 11.13.31. WF-13.31 — Authorization Refresh and Policy Epoch Changes . . . . . . . . . . . . . . . . . . . . . . . 548 11.13.32. WF-13.32 — Replay and Unauthorized Reuse Prevention . . . . . . . . . . . . . . . . . . . . . 549 11.13.33. WF-13.33 — Crash, Restart, and Recovery . . . . . . 550 11.13.34. WF-13.34 — Alternative Structural Implementations . . . . . . . . . . . . . . . . . . . 550 11.13.35. WF-13.35 — Failure and Fail-Closed Conditions . . . 551 11.13.36. WF-13.36 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . . 553 11.13.37. WF-13.37 — Claim-Specific Technical Support . . . . 555 11.13.38. WF-13.38 — Technical Effect . . . . . . . . . . . . 556 11.14. WF-14 — Protected Model-Path and Downstream Effectuation-Path Dual Authorization, Inference-to-Act Context Binding, Streaming Output Control, Multi-Sink Classification, and Remote Finality Verification . . . 558 11.14.1. WF-14.1 — Technical Purpose . . . . . . . . . . . . 558 11.14.2. WF-14.2 — Participating Technical Components . . . 559 11.14.3. WF-14.3 — Establishment of Two Governed Authorization Boundaries . . . . . . . . . . . . . . . . . . . . . 562 11.14.4. WF-14.4 — Model-Path Trust Boundary . . . . . . . . 563 11.14.5. WF-14.5 — Downstream Effectuation Trust Boundary . 564 11.14.6. WF-14.6 — Generation of the Proposed Inference Request . . . . . . . . . . . . . . . . . . . . . . . 565 11.14.7. WF-14.7 — Protected Computation-Admission Validation . . . . . . . . . . . . . . . . . . . . . 565 11.14.8. WF-14.8 — Protected Computation-Admission Record . 566 11.14.9. WF-14.9 — Admission Record Authentication and Binding . . . . . . . . . . . . . . . . . . . . . . . 567 11.14.10. WF-14.10 — Controlled Model Computation . . . . . . 568 11.14.11. WF-14.11 — Identification of the Consequential Operation . . . . . . . . . . . . . . . . . . . . . . 569 Das Expires 19 April 2027 [Page 23] Internet-Draft Protected AI Execution Finality October 2026 11.14.12. WF-14.12 — Non-Effective State for the Derived Candidate Act . . . . . . . . . . . . . . . . . . . . 570 11.14.13. WF-14.13 — Inference-to-Act Context Binding . . . . 570 11.14.14. WF-14.14 — Downstream Candidate Act Descriptor . . 571 11.14.15. WF-14.15 — Canonical Operation Descriptor . . . . . 573 11.14.16. WF-14.16 — Acquisition of Operation-Specific Execution Authority . . . . . . . . . . . . . . . . . 573 11.14.17. WF-14.17 — Protected Downstream Authorization Predicates . . . . . . . . . . . . . . . . . . . . . 574 11.14.18. WF-14.18 — Protected Authorization-State Handling . . . . . . . . . . . . . . . . . . . . . . 575 11.14.19. WF-14.19 — Protected Operation-Specific Evidence Commitment . . . . . . . . . . . . . . . . . . . . . 576 11.14.20. WF-14.20 — Protected Downstream Finality Transaction . . . . . . . . . . . . . . . . . . . . . 577 11.14.21. WF-14.21 — Operation-Specific Execution Capability . . . . . . . . . . . . . . . . . . . . . 577 11.14.22. WF-14.22 — Independent Downstream Finality Sink Verification . . . . . . . . . . . . . . . . . . . . 578 11.14.23. WF-14.23 — Downstream Finality Verification Predicate . . . . . . . . . . . . . . . . . . . . . . 579 11.14.24. WF-14.24 — Distinction Between Model Authorization and Effectuation Authorization . . . . . . . . . . . 580 11.14.25. WF-14.25 — Revocation of Model Access . . . . . . . 580 11.14.26. WF-14.26 — Already Generated and Buffered Candidate Acts . . . . . . . . . . . . . . . . . . . . . . . . 581 11.14.27. WF-14.27 — Model-Path Interruption and External-Effect Timing . . . . . . . . . . . . . . . 582 11.14.28. WF-14.28 — Streaming Model Output and Partial-Action Classification . . . . . . . . . . . . . . . . . . . 582 11.14.29. WF-14.29 — Non-Effective Buffering of Streaming Operations . . . . . . . . . . . . . . . . . . . . . 583 11.14.30. WF-14.30 — Completed or Bounded Candidate Act Formation . . . . . . . . . . . . . . . . . . . . . . 584 11.14.31. WF-14.31 — Partial-Action Finality Predicate . . . 585 11.14.32. WF-14.32 — Multi-Sink Effectuation Classification . . . . . . . . . . . . . . . . . . . 585 11.14.33. WF-14.33 — Multi-Sink Authorization Independence . 586 11.14.34. WF-14.34 — Receiving-Side and Remote Finality Sink . . . . . . . . . . . . . . . . . . . . . . . . 587 11.14.35. WF-14.35 — Remote Actual-Operation Reconstruction . . . . . . . . . . . . . . . . . . . 588 11.14.36. WF-14.36 — Receiving-Side Verification Predicate . 589 11.14.37. WF-14.37 — Illustrative End-to-End AI-Agent Transaction . . . . . . . . . . . . . . . . . . . . . 590 11.14.38. WF-14.38 — Illustrative Model-Interruption Attack . . . . . . . . . . . . . . . . . . . . . . . 591 11.14.39. WF-14.39 — Illustrative Multi-Sink Workflow . . . . 591 Das Expires 19 April 2027 [Page 24] Internet-Draft Protected AI Execution Finality October 2026 11.14.40. WF-14.40 — Protected Capability Consumption and Replay Prevention . . . . . . . . . . . . . . . . . . 592 11.14.41. WF-14.41 — Crash, Retry, and Recovery . . . . . . . 593 11.14.42. WF-14.42 — Alternative Structural Implementations . . . . . . . . . . . . . . . . . . . 594 11.14.43. WF-14.43 — Failure and Fail-Closed Conditions . . . 595 11.14.44. WF-14.44 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . . 596 11.14.45. WF-14.45 — Claim-Specific Technical Support . . . . 599 11.14.46. WF-14.46 — Technical Effect . . . . . . . . . . . . 601 11.15. WF-15 — Protected Cross-Domain AI-Fabric Transfer Finality, GPU/TPU/NPU Accelerator Isolation, Hardware-Latched DMA and Interconnect Admission, Continuous Tensor-Stream Authorization, Hardware Freshness, and Line-Rate Capability Verification . . . . . . . . . . . 602 11.15.1. WF-15.1 — Technical Purpose . . . . . . . . . . . . 602 11.15.2. WF-15.2 — Participating Technical Components . . . 604 11.15.3. WF-15.3 — Establishment of the Accelerator and Fabric Trust Boundaries . . . . . . . . . . . . . . . . . . 606 11.15.4. WF-15.4 — Hardware-Assisted Enforcement Configuration . . . . . . . . . . . . . . . . . . . . 607 11.15.5. WF-15.5 — Definition of the Governed Transfer Effect . . . . . . . . . . . . . . . . . . . . . . . 608 11.15.6. WF-15.6 — Generation of the Candidate Fabric Transfer Act . . . . . . . . . . . . . . . . . . . . . . . . . 609 11.15.7. WF-15.7 — Interception and Non-Effective Transfer Staging . . . . . . . . . . . . . . . . . . . . . . . 610 11.15.8. WF-15.8 — Candidate Fabric Transfer Act Descriptor Formation . . . . . . . . . . . . . . . . . . . . . . 611 11.15.9. WF-15.9 — Canonical Transfer Descriptor Encoding . 612 11.15.10. WF-15.10 — Acquisition of Cross-Domain Fabric Authority . . . . . . . . . . . . . . . . . . . . . . 613 11.15.11. WF-15.11 — Source-Domain Authority Validation . . . 614 11.15.12. WF-15.12 — Destination-Domain Authority Validation . . . . . . . . . . . . . . . . . . . . . 615 11.15.13. WF-15.13 — Computation-Data Classification . . . . 615 11.15.14. WF-15.14 — Approved Workload Graph and Transfer Envelope . . . . . . . . . . . . . . . . . . . . . . 616 11.15.15. WF-15.15 — Fabric Route and Switch Validation . . . 617 11.15.16. WF-15.16 — Protected Fabric Authorization Predicate . . . . . . . . . . . . . . . . . . . . . . 618 11.15.17. WF-15.17 — Protected Fabric Authorization-State Handling . . . . . . . . . . . . . . . . . . . . . . 619 11.15.18. WF-15.18 — Fabric Transfer Validation Evidence . . 619 11.15.19. WF-15.19 — Protected Fabric Finality Transaction . 621 11.15.20. WF-15.20 — Scoped Fabric Transfer Capability . . . 621 11.15.21. WF-15.21 — Illustrative Cryptographic Capability Representation . . . . . . . . . . . . . . . . . . . 623 Das Expires 19 April 2027 [Page 25] Internet-Draft Protected AI Execution Finality October 2026 11.15.22. WF-15.22 — Independent Verification at the Fabric Finality Sink . . . . . . . . . . . . . . . . . . . . 624 11.15.23. WF-15.23 — Fabric Finality Verification Predicate . . . . . . . . . . . . . . . . . . . . . . 625 11.15.24. WF-15.24 — Hardware-Latched Transfer Admission . . 626 11.15.25. WF-15.25 — Hardware-Latch Activation Sequence . . . 627 11.15.26. WF-15.26 — Continuous Tensor and Memory-Transfer Validation . . . . . . . . . . . . . . . . . . . . . 627 11.15.27. WF-15.27 — Rolling Transfer Authorization State . . 628 11.15.28. WF-15.28 — Continuous Transfer Monitoring and Drift Detection . . . . . . . . . . . . . . . . . . . . . . 629 11.15.29. WF-15.29 — Transfer-Size and Workload-Graph Anomaly Handling . . . . . . . . . . . . . . . . . . . . . . 630 11.15.30. WF-15.30 — Hardware-Freshness Binding . . . . . . . 631 11.15.31. WF-15.31 — Hardware-Freshness Verification Procedure . . . . . . . . . . . . . . . . . . . . . . 632 11.15.32. WF-15.32 — Prevention of Replay Across Device Reset . . . . . . . . . . . . . . . . . . . . . . . . 633 11.15.33. WF-15.33 — Cold-Path Authority Validation . . . . . 633 11.15.34. WF-15.34 — Bounded-Time Local Fabric Verification . . . . . . . . . . . . . . . . . . . . 634 11.15.35. WF-15.35 — Local Capability-Table Implementation . 635 11.15.36. WF-15.36 — Time-of-Check and Time-of-Use Protection . . . . . . . . . . . . . . . . . . . . . 636 11.15.37. WF-15.37 — Protected Capability Consumption . . . . 636 11.15.38. WF-15.38 — Crash, Timeout, Reset, and Recovery . . 637 11.15.39. WF-15.39 — Illustrative GPU-to-GPU Tensor Transfer . . . . . . . . . . . . . . . . . . . . . . 638 11.15.40. WF-15.40 — Illustrative DMA-Bypass Attempt . . . . 639 11.15.41. WF-15.41 — Illustrative Continuous Tensor-Stream Rollout . . . . . . . . . . . . . . . . . . . . . . . 640 11.15.42. WF-15.42 — Illustrative Hardware Freshness and Replay Attack . . . . . . . . . . . . . . . . . . . . . . . 640 11.15.43. WF-15.43 — Alternative Technical Implementations . 641 11.15.44. WF-15.44 — Failure and Fail-Closed Conditions . . . 642 11.15.45. WF-15.45 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . . 644 11.15.46. WF-15.46 — Claim-Specific Technical Support . . . . 647 11.15.47. WF-15.47 — Technical Effect . . . . . . . . . . . . 648 11.16. WF-16 — Distributed Hardware-Watchdog Execution Interlock, Protected Monitoring-State Attestation, Multi-Sink Revocation Fencing, Fail-Closed Monitoring Failure, and Effectuation-State-Preserving Quarantine . . . . . . . 650 11.16.1. WF-16.1 — Technical Purpose . . . . . . . . . . . . 650 11.16.2. WF-16.2 — Participating Technical Components . . . 651 11.16.3. WF-16.3 — Establishment of the Monitoring and Execution Trust Boundaries . . . . . . . . . . . . . 654 11.16.4. WF-16.4 — Definition of Out-of-Band Monitoring . . 655 Das Expires 19 April 2027 [Page 26] Internet-Draft Protected AI Execution Finality October 2026 11.16.5. WF-16.5 — Identification of Governed Consequential Boundaries . . . . . . . . . . . . . . . . . . . . . 656 11.16.6. WF-16.6 — Mandatory Effectuation-Path Coverage . . 657 11.16.7. WF-16.7 — Monitoring-State Collection . . . . . . . 658 11.16.8. WF-16.8 — Protected Monitoring-State Record . . . . 659 11.16.9. WF-16.9 — Monitoring-State Versioning . . . . . . . 660 11.16.10. WF-16.10 — Hardware-Attested Monitoring State . . . 661 11.16.11. WF-16.11 — Protected Attestation Verification . . . 662 11.16.12. WF-16.12 — Candidate Act Generation . . . . . . . . 662 11.16.13. WF-16.13 — Interception and Non-Effective Staging . . . . . . . . . . . . . . . . . . . . . . . 663 11.16.14. WF-16.14 — Candidate Act Descriptor Formation . . . 664 11.16.15. WF-16.15 — Canonical Descriptor and Monitoring-State Binding . . . . . . . . . . . . . . . . . . . . . . . 665 11.16.16. WF-16.16 — Acquisition of Operation-Specific Authority . . . . . . . . . . . . . . . . . . . . . . 666 11.16.17. WF-16.17 — Combined Monitoring and Operation Authorization . . . . . . . . . . . . . . . . . . . . 666 11.16.18. WF-16.18 — Protected Authorization-State Transition . . . . . . . . . . . . . . . . . . . . . 667 11.16.19. WF-16.19 — Protected Validation-Evidence Commitment . . . . . . . . . . . . . . . . . . . . . 668 11.16.20. WF-16.20 — Protected Watchdog-Finality Transaction . . . . . . . . . . . . . . . . . . . . . 669 11.16.21. WF-16.21 — Monitoring-State-Bound Execution Capability . . . . . . . . . . . . . . . . . . . . . 670 11.16.22. WF-16.22 — Multiple Independently Enforceable Finality Sinks . . . . . . . . . . . . . . . . . . . 671 11.16.23. WF-16.23 — Independent Finality Sink Verification . . . . . . . . . . . . . . . . . . . . 672 11.16.24. WF-16.24 — Monitoring-State-Aware Sink Predicate . 673 11.16.25. WF-16.25 — Watchdog-Detected Violation . . . . . . 674 11.16.26. WF-16.26 — Protected Revocation-Fence Advancement . . . . . . . . . . . . . . . . . . . . . 674 11.16.27. WF-16.27 — Enforcement of Superseded Monitoring Versions . . . . . . . . . . . . . . . . . . . . . . 675 11.16.28. WF-16.28 — Prevention Despite Continued or Interrupted Model Access . . . . . . . . . . . . . . 676 11.16.29. WF-16.29 — Monitoring-State Unavailability . . . . 677 11.16.30. WF-16.30 — Stale and Inconsistent Monitoring-State Handling . . . . . . . . . . . . . . . . . . . . . . 677 11.16.31. WF-16.31 — Protected Monitoring Recovery . . . . . 678 11.16.32. WF-16.32 — Quarantine Initiation . . . . . . . . . 679 11.16.33. WF-16.33 — Quarantine Enforcement . . . . . . . . . 680 11.16.34. WF-16.34 — Preservation of Effectuation State During Quarantine . . . . . . . . . . . . . . . . . . . . . 681 11.16.35. WF-16.35 — No Automatic Rollback or Replay Authority . . . . . . . . . . . . . . . . . . . . . . 682 Das Expires 19 April 2027 [Page 27] Internet-Draft Protected AI Execution Finality October 2026 11.16.36. WF-16.36 — Cross-Component Monitoring-State Consistency . . . . . . . . . . . . . . . . . . . . . 683 11.16.37. WF-16.37 — Illustrative Network and Storage Dual-Sink System . . . . . . . . . . . . . . . . . . . . . . . 684 11.16.38. WF-16.38 — Illustrative Watchdog-to-Finality Revocation . . . . . . . . . . . . . . . . . . . . . 685 11.16.39. WF-16.39 — Illustrative Continued-Inference Scenario . . . . . . . . . . . . . . . . . . . . . . 685 11.16.40. WF-16.40 — Illustrative Watchdog Failure . . . . . 686 11.16.41. WF-16.41 — Illustrative Quarantine After Possible External Effect . . . . . . . . . . . . . . . . . . . 686 11.16.42. WF-16.42 — Alternative Technical Implementations . 687 11.16.43. WF-16.43 — Failure and Fail-Closed Conditions . . . 688 11.16.44. WF-16.44 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . . 689 11.16.45. WF-16.45 — Claim-Specific Technical Support . . . . 692 11.16.46. WF-16.46 — Technical Effect . . . . . . . . . . . . 694 11.17. WF-17 — Protected Confidential Virtual-Machine Execution, Hardware-Rooted Composite ALF Validation, Workload-to-Act Authorization, Privacy-Preserving Validation, Tenant-Bound Capabilities, and Snapshot-Rollback-Resistant Finality 695 11.17.1. WF-17.1 — Technical Purpose . . . . . . . . . . . . 695 11.17.2. WF-17.2 — Participating Technical Components . . . 697 11.17.3. WF-17.3 — Establishment of the Confidential-Computing Trust Boundary . . . . . . . . . . . . . . . . . . . 699 11.17.4. WF-17.4 — Isolation of Protected Execution Authority . . . . . . . . . . . . . . . . . . . . . . 700 11.17.5. WF-17.5 — Identification of Governed Effectuation Paths . . . . . . . . . . . . . . . . . . . . . . . . 701 11.17.6. WF-17.6 — Execution-Context Measurement . . . . . . 702 11.17.7. WF-17.7 — Execution-Context Measurement Record . . 702 11.17.8. WF-17.8 — Hardware-Rooted Composite ALF Formation . . . . . . . . . . . . . . . . . . . . . . 703 11.17.9. WF-17.9 — Composite ALF Cryptographic Representation . . . . . . . . . . . . . . . . . . . 704 11.17.10. WF-17.10 — Authentication of the Measurement Source . . . . . . . . . . . . . . . . . . . . . . . 705 11.17.11. WF-17.11 — Runtime-Used Configuration Verification . . . . . . . . . . . . . . . . . . . . 706 11.17.12. WF-17.12 — Distinguishing Launch Attestation from Runtime Integrity . . . . . . . . . . . . . . . . . . 707 11.17.13. WF-17.13 — Candidate Act Generation . . . . . . . . 708 11.17.14. WF-17.14 — Interception and Non-Effective Staging . . . . . . . . . . . . . . . . . . . . . . . 708 11.17.15. WF-17.15 — Candidate Act Descriptor Construction . 709 11.17.16. WF-17.16 — Canonical Candidate Act Descriptor . . . 710 11.17.17. WF-17.17 — Acquisition of Applicable Authority . . 711 Das Expires 19 April 2027 [Page 28] Internet-Draft Protected AI Execution Finality October 2026 11.17.18. WF-17.18 — Protected Runtime and Operation Authorization . . . . . . . . . . . . . . . . . . . . 712 11.17.19. WF-17.19 — Protected Authorization-State Operations . . . . . . . . . . . . . . . . . . . . . 713 11.17.20. WF-17.20 — Protected Validation-Evidence Commitment . . . . . . . . . . . . . . . . . . . . . 713 11.17.21. WF-17.21 — Protected Confidential-Workload Finality Transaction . . . . . . . . . . . . . . . . . . . . . 714 11.17.22. WF-17.22 — Scoped Non-Bearer Execution Capability . . . . . . . . . . . . . . . . . . . . . 715 11.17.23. WF-17.23 — Privacy-Preserving Protected Validation Evidence . . . . . . . . . . . . . . . . . . . . . . 717 11.17.24. WF-17.24 — Confidential Validation and Finality Sink Independence . . . . . . . . . . . . . . . . . . . . 718 11.17.25. WF-17.25 — Independent Finality Sink Verification . . . . . . . . . . . . . . . . . . . . 719 11.17.26. WF-17.26 — Finality Sink Verification Predicate . . 719 11.17.27. WF-17.27 — Tenant and Destination Scope Binding . . 720 11.17.28. WF-17.28 — Cross-Tenant Authority Isolation . . . . 721 11.17.29. WF-17.29 — Virtual-Machine Snapshot Rollback Threat . . . . . . . . . . . . . . . . . . . . . . . 722 11.17.30. WF-17.30 — Protected Rollback-Resistant State . . . 723 11.17.31. WF-17.31 — Capability Consumption Before and During Effectuation . . . . . . . . . . . . . . . . . . . . 724 11.17.32. WF-17.32 — Virtual-Machine Snapshot Restoration . . 724 11.17.33. WF-17.33 — Snapshot-Replay Rejection . . . . . . . 725 11.17.34. WF-17.34 — VM Migration and Workload Replacement . 726 11.17.35. WF-17.35 — Revocation and Policy-Epoch Changes . . 726 11.17.36. WF-17.36 — Time-of-Check and Time-of-Use Protection . . . . . . . . . . . . . . . . . . . . . 727 11.17.37. WF-17.37 — Illustrative Confidential AI-Agent API Operation . . . . . . . . . . . . . . . . . . . . . . 728 11.17.38. WF-17.38 — Illustrative Composite ALF Mismatch . . 729 11.17.39. WF-17.39 — Illustrative Cross-Tenant Destination Substitution . . . . . . . . . . . . . . . . . . . . 730 11.17.40. WF-17.40 — Illustrative Snapshot-Rollback Attack . 730 11.17.41. WF-17.41 — Illustrative Privacy-Preserving Validation . . . . . . . . . . . . . . . . . . . . . 731 11.17.42. WF-17.42 — Failure, Crash, and Recovery Handling . 731 11.17.43. WF-17.43 — Alternative Technical Implementations . 732 11.17.44. WF-17.44 — Failure and Fail-Closed Conditions . . . 733 11.17.45. WF-17.45 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . . 735 11.17.46. WF-17.46 — Claim-Specific Technical Support . . . . 738 11.17.47. WF-17.47 — Technical Effect . . . . . . . . . . . . 740 Das Expires 19 April 2027 [Page 29] Internet-Draft Protected AI Execution Finality October 2026 11.18. WF-18 — Confidential Governance Virtual Machine, Hardware-Rooted Attestation, Protected Governance-Key Isolation, Authenticated Fabric Capability Delivery, and Hardware-Enforced SmartNIC Finality . . . . . . . . . . 741 11.18.1. WF-18.1 — Technical Purpose . . . . . . . . . . . . 741 11.18.2. WF-18.2 — Participating Technical Components . . . 742 11.18.3. WF-18.3 — Establishment of the AI Compute-to-Governance Trust Boundary . . . . . . . . 745 11.18.4. WF-18.4 — Establishment of the Confidential Governance VM . . . . . . . . . . . . . . . . . . . . 746 11.18.5. WF-18.5 — Governance-Node Identity Registration . . 747 11.18.6. WF-18.6 — Hardware Finality Gate Attestation Object Formation . . . . . . . . . . . . . . . . . . . . . . 747 11.18.7. WF-18.7 — Hardware Trust-Root Verification . . . . 749 11.18.8. WF-18.8 — Governance Attestation State Registration . . . . . . . . . . . . . . . . . . . . 750 11.18.9. WF-18.9 — Protected Governance-Key Isolation . . . 750 11.18.10. WF-18.10 — Protected Capability Issuance Key Use . 751 11.18.11. WF-18.11 — Candidate Act Generation . . . . . . . . 752 11.18.12. WF-18.12 — Non-Effective Staging . . . . . . . . . 752 11.18.13. WF-18.13 — Candidate Act Descriptor Formation . . . 753 11.18.14. WF-18.14 — Canonical Candidate Act Representation . . . . . . . . . . . . . . . . . . . 754 11.18.15. WF-18.15 — Candidate Act Authority Validation . . . 755 11.18.16. WF-18.16 — Combined Attestation and Act-Specific Authorization Predicate . . . . . . . . . . . . . . . 756 11.18.17. WF-18.17 — Protected Authorization-State Handling . . . . . . . . . . . . . . . . . . . . . . 757 11.18.18. WF-18.18 — Protected Validation Evidence . . . . . 757 11.18.19. WF-18.19 — Scoped Execution-Capability Generation . . . . . . . . . . . . . . . . . . . . . 758 11.18.20. WF-18.20 — Cryptographically Authenticated Capability . . . . . . . . . . . . . . . . . . . . . 759 11.18.21. WF-18.21 — Authenticated Fabric-Management Capability Delivery . . . . . . . . . . . . . . . . . . . . . . 760 11.18.22. WF-18.22 — Capability Delivery and Actual-Operation Consistency . . . . . . . . . . . . . . . . . . . . . 761 11.18.23. WF-18.23 — Hardware Finality Sink Verification . . 762 11.18.24. WF-18.24 — Hardware Finality Verification Predicate . . . . . . . . . . . . . . . . . . . . . . 763 11.18.25. WF-18.25 — Hardware-Enforced Transmission Interlock . . . . . . . . . . . . . . . . . . . . . . 764 11.18.26. WF-18.26 — Confidential Governance Measurement Change . . . . . . . . . . . . . . . . . . . . . . . 764 11.18.27. WF-18.27 — Attestation Revalidation . . . . . . . . 765 11.18.28. WF-18.28 — Hardware-Freshness Binding . . . . . . . 766 11.18.29. WF-18.29 — Snapshot, Reset, and Hardware Replay Resistance . . . . . . . . . . . . . . . . . . . . . 767 Das Expires 19 April 2027 [Page 30] Internet-Draft Protected AI Execution Finality October 2026 11.18.30. WF-18.30 — Capability Consumption and Hardware State . . . . . . . . . . . . . . . . . . . . . . . . 767 11.18.31. WF-18.31 — Attestation-State Revocation at Distributed Controllers . . . . . . . . . . . . . . . 768 11.18.32. WF-18.32 — Illustrative Confidential Governance VM and SmartNIC Deployment . . . . . . . . . . . . . . . 769 11.18.33. WF-18.33 — Illustrative Compromised AI Compute Process . . . . . . . . . . . . . . . . . . . . . . . 770 11.18.34. WF-18.34 — Illustrative Governance Firmware Measurement Change . . . . . . . . . . . . . . . . . 771 11.18.35. WF-18.35 — Illustrative Hardware-Freshness Replay Attack . . . . . . . . . . . . . . . . . . . . . . . 771 11.18.36. WF-18.36 — Crash, Reset, and Recovery . . . . . . . 772 11.18.37. WF-18.37 — Alternative Technical Implementations . 773 11.18.38. WF-18.38 — Failure and Fail-Closed Conditions . . . 773 11.18.39. WF-18.39 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . . 775 11.18.40. WF-18.40 — Claim-Specific Technical Support . . . . 778 11.18.41. WF-18.41 — Technical Effect . . . . . . . . . . . . 779 11.19. WF-19 — User-Controlled Confidential Virtual Machine, Root-Key Sovereignty, Attested Derived-Key Release, Separate Data-Access and Execution Authority, Privacy-Preserving Finality Evidence, and Rollback-Resistant Recovery . . . . . . . . . . . . . . 780 11.19.1. WF-19.1 — Technical Purpose . . . . . . . . . . . . 781 11.19.2. WF-19.2 — Participating Technical Components . . . 782 11.19.3. WF-19.3 — Separation of Confidentiality and Execution Authority . . . . . . . . . . . . . . . . . . . . . . 784 11.19.4. WF-19.4 — Confidential Virtual-Machine Establishment . . . . . . . . . . . . . . . . . . . . 785 11.19.5. WF-19.5 — User-Controlled Root-Key Establishment . 786 11.19.6. WF-19.6 — Protected User-Data Encryption . . . . . 786 11.19.7. WF-19.7 — Hardware-Rooted Confidential-VM Attestation . . . . . . . . . . . . . . . . . . . . . 787 11.19.8. WF-19.8 — Verification of the Confidential-VM Measurement . . . . . . . . . . . . . . . . . . . . . 788 11.19.9. WF-19.9 — User-Authorized Data-Access Scope . . . . 789 11.19.10. WF-19.10 — Protected Data-Access Authorization Predicate . . . . . . . . . . . . . . . . . . . . . . 790 11.19.11. WF-19.11 — Derived, Wrapped, or Session-Limited Key Release . . . . . . . . . . . . . . . . . . . . . . . 790 11.19.12. WF-19.12 — Illustrative Protected Key Derivation . 791 11.19.13. WF-19.13 — Bounded Cryptographic Data Access . . . 792 11.19.14. WF-19.14 — Dual Authorization for Data Access and External Effect . . . . . . . . . . . . . . . . . . . 793 11.19.15. WF-19.15 — Candidate Act Generation . . . . . . . . 793 11.19.16. WF-19.16 — Interception and Non-Effective State . . 794 11.19.17. WF-19.17 — Canonical Candidate Act Descriptor . . . 795 Das Expires 19 April 2027 [Page 31] Internet-Draft Protected AI Execution Finality October 2026 11.19.18. WF-19.18 — Operation-Specific Authority Validation . . . . . . . . . . . . . . . . . . . . . 796 11.19.19. WF-19.19 — Protected Authorization-State Handling . . . . . . . . . . . . . . . . . . . . . . 797 11.19.20. WF-19.20 — Protected Validation-Evidence Commitment . . . . . . . . . . . . . . . . . . . . . 797 11.19.21. WF-19.21 — Protected Execution-Finality Transaction . . . . . . . . . . . . . . . . . . . . . 798 11.19.22. WF-19.22 — Cryptographically Bound Operation-Specific Capability . . . . . . . . . . . . . . . . . . . . . 799 11.19.23. WF-19.23 — Independent Finality Sink Verification . . . . . . . . . . . . . . . . . . . . 800 11.19.24. WF-19.24 — Operation and Attestation Substitution Protection . . . . . . . . . . . . . . . . . . . . . 801 11.19.25. WF-19.25 — Privacy-Preserving Execution Evidence . 801 11.19.26. WF-19.26 — Distinction Between Authorization Evidence and Completion Evidence . . . . . . . . . . . . . . . 802 11.19.27. WF-19.27 — Root-Key Confidentiality During Evidence Verification . . . . . . . . . . . . . . . . . . . . 803 11.19.28. WF-19.28 — Separate Key-Access and Execution Revocation . . . . . . . . . . . . . . . . . . . . . 804 11.19.29. WF-19.29 — Confidential-VM Backup and Snapshot Protection . . . . . . . . . . . . . . . . . . . . . 804 11.19.30. WF-19.30 — Attested Recovery of the Confidential VM . . . . . . . . . . . . . . . . . . . . . . . . . 805 11.19.31. WF-19.31 — Protected Capability-Consumption State Continuity . . . . . . . . . . . . . . . . . . . . . 806 11.19.32. WF-19.32 — Snapshot-Rollback Replay Protection . . 807 11.19.33. WF-19.33 — User Root-Key Continuity During Recovery . . . . . . . . . . . . . . . . . . . . . . 807 11.19.34. WF-19.34 — Illustrative Confidential AI-Agent Document Processing . . . . . . . . . . . . . . . . . 808 11.19.35. WF-19.35 — Illustrative Connected-Service Credential Operation . . . . . . . . . . . . . . . . . . . . . . 809 11.19.36. WF-19.36 — Illustrative VM Snapshot Recovery . . . 809 11.19.37. WF-19.37 — Failure, Crash, and Recovery Handling . 810 11.19.38. WF-19.38 — Alternative Technical Implementations . 811 11.19.39. WF-19.39 — Failure and Fail-Closed Conditions . . . 812 11.19.40. WF-19.40 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . . 813 11.19.41. WF-19.41 — Claim-Specific Technical Support . . . . 816 11.19.42. WF-19.42 — Technical Effect . . . . . . . . . . . . 818 11.20. WF-20 — Protected Derived-Key and Wrapped-Key Enablement, Attestation-Bound Key Release, Cryptographic Key-Use Finality, Separation of Data Access from Execution Authority, and Hardware-Enforced Credential and Effectuation Control . . . . . . . . . . . . . . . . . 819 11.20.1. WF-20.1 — Technical Purpose . . . . . . . . . . . . 819 Das Expires 19 April 2027 [Page 32] Internet-Draft Protected AI Execution Finality October 2026 11.20.2. WF-20.2 — Participating Technical Components . . . 821 11.20.3. WF-20.3 — Separation of Root-Key Control and AI Computation . . . . . . . . . . . . . . . . . . . . . 823 11.20.4. WF-20.4 — Root-Key and Derived-Key Distinction . . 824 11.20.5. WF-20.5 — User-Authorized Key Scope . . . . . . . . 825 11.20.6. WF-20.6 — Hardware Attestation Before Key Enablement . . . . . . . . . . . . . . . . . . . . . 826 11.20.7. WF-20.7 — Protected Key-Enablement Decision . . . . 827 11.20.8. WF-20.8 — Derived-Key Release . . . . . . . . . . . 828 11.20.9. WF-20.9 — Wrapped-Key Enablement . . . . . . . . . 829 11.20.10. WF-20.10 — Session-Limited Key Enablement . . . . . 830 11.20.11. WF-20.11 — Bounded Cryptographic Operation Without Key Export . . . . . . . . . . . . . . . . . . . . . 830 11.20.12. WF-20.12 — Cryptographic Access Is Not External Execution Authority . . . . . . . . . . . . . . . . . 831 11.20.13. WF-20.13 — Candidate Cryptographic Operation . . . 832 11.20.14. WF-20.14 — Interception of the Consequential Operation . . . . . . . . . . . . . . . . . . . . . . 832 11.20.15. WF-20.15 — Candidate Act Descriptor Formation . . . 833 11.20.16. WF-20.16 — Canonical Candidate Act Representation . . . . . . . . . . . . . . . . . . . 834 11.20.17. WF-20.17 — Protected Operation-Specific Authority . . . . . . . . . . . . . . . . . . . . . . 835 11.20.18. WF-20.18 — Operation-Specific Authorization Predicate . . . . . . . . . . . . . . . . . . . . . . 836 11.20.19. WF-20.19 — Protected State Transition . . . . . . . 837 11.20.20. WF-20.20 — Protected Validation-Evidence Commitment . . . . . . . . . . . . . . . . . . . . . 837 11.20.21. WF-20.21 — Operation-Specific Execution Capability . . . . . . . . . . . . . . . . . . . . . 838 11.20.22. WF-20.22 — Protected Key-Use Finality Sink . . . . 839 11.20.23. WF-20.23 — External Effectuation Finality Sink . . 840 11.20.24. WF-20.24 — Relationship Between Key-Use and External Finality . . . . . . . . . . . . . . . . . . . . . . 840 11.20.25. WF-20.25 — Governance-Key Isolation . . . . . . . . 841 11.20.26. WF-20.26 — Attestation-Dependent Governance Key Use . . . . . . . . . . . . . . . . . . . . . . . . . 841 11.20.27. WF-20.27 — Hardware-Freshness Binding . . . . . . . 842 11.20.28. WF-20.28 — Revocation of Data-Access Keys . . . . . 843 11.20.29. WF-20.29 — Revocation of External Execution Authority . . . . . . . . . . . . . . . . . . . . . . 843 11.20.30. WF-20.30 — Key Rotation and Version Continuity . . 844 11.20.31. WF-20.31 — Snapshot and Backup Recovery . . . . . . 845 11.20.32. WF-20.32 — Key-State and Capability-State Separation . . . . . . . . . . . . . . . . . . . . . 845 11.20.33. WF-20.33 — Crash Between Authorization and Effectuation . . . . . . . . . . . . . . . . . . . . 846 Das Expires 19 April 2027 [Page 33] Internet-Draft Protected AI Execution Finality October 2026 11.20.34. WF-20.34 — Illustrative User-Controlled Encrypted Data Access . . . . . . . . . . . . . . . . . . . . . 847 11.20.35. WF-20.35 — Illustrative Protected Credential Broker . . . . . . . . . . . . . . . . . . . . . . . 848 11.20.36. WF-20.36 — Illustrative Signing-Key Finality . . . 848 11.20.37. WF-20.37 — Illustrative Snapshot Replay . . . . . . 849 11.20.38. WF-20.38 — Alternative Technical Implementations . 850 11.20.39. WF-20.39 — Failure and Fail-Closed Conditions . . . 850 11.20.40. WF-20.40 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . . 852 11.20.41. WF-20.41 — Claim-Specific Technical Support . . . . 854 11.20.42. WF-20.42 — Technical Effect . . . . . . . . . . . . 856 11.21. WF-21 — Hardware Finality Latch, NIC/SmartNIC/DPU Enforcement, Protected DMA and Network Admission, Capability-Dependent Hardware Effectuation, and Fail-Closed Revocation . . . . . . . . . . . . . . . . . . . . . . 858 11.21.1. WF-21.1 — Technical Purpose . . . . . . . . . . . . 858 11.21.2. WF-21.2 — Participating Technical Components . . . 859 11.21.3. WF-21.3 — Definition of Hardware Finality Latch . . 861 11.21.4. WF-21.4 — Distinction Among PED, Finality Gate, Finality Sink, and Latch . . . . . . . . . . . . . . 862 11.21.5. WF-21.5 — Establishment of the Hardware Enforcement Boundary . . . . . . . . . . . . . . . . . . . . . . 863 11.21.6. WF-21.6 — Candidate Act Generation . . . . . . . . 864 11.21.7. WF-21.7 — Interception and Non-Effective State . . 864 11.21.8. WF-21.8 — Candidate Act Descriptor Formation . . . 865 11.21.9. WF-21.9 — Canonical Hardware Operation Representation . . . . . . . . . . . . . . . . . . . 866 11.21.10. WF-21.10 — Acquisition of Hardware Effectuation Authority . . . . . . . . . . . . . . . . . . . . . . 867 11.21.11. WF-21.11 — Protected Authorization Predicate . . . 868 11.21.12. WF-21.12 — Protected Authorization-State Transition . . . . . . . . . . . . . . . . . . . . . 869 11.21.13. WF-21.13 — Protected Validation-Evidence Commitment . . . . . . . . . . . . . . . . . . . . . 869 11.21.14. WF-21.14 — Scoped Hardware Execution Capability . . 870 11.21.15. WF-21.15 — Illustrative Capability Authentication . . . . . . . . . . . . . . . . . . . 871 11.21.16. WF-21.16 — Capability Delivery to the Hardware Controller . . . . . . . . . . . . . . . . . . . . . 872 11.21.17. WF-21.17 — Hardware Finality Sink Verification . . 873 11.21.18. WF-21.18 — Hardware Effectuation Predicate . . . . 874 11.21.19. WF-21.19 — Hardware Finality Latch State Machine . 874 11.21.20. WF-21.20 — Hardware-Latched DMA and Accelerator Transfer . . . . . . . . . . . . . . . . . . . . . . 875 11.21.21. WF-21.21 — SmartNIC and DPU Network Forwarding . . 876 11.21.22. WF-21.22 — Hardware Fast-Path Verification . . . . 877 Das Expires 19 April 2027 [Page 34] Internet-Draft Protected AI Execution Finality October 2026 11.21.23. WF-21.23 — Continuous and Windowed Transfer Authorization . . . . . . . . . . . . . . . . . . . . 878 11.21.24. WF-21.24 — Hardware-Freshness and Replay Protection . . . . . . . . . . . . . . . . . . . . . 878 11.21.25. WF-21.25 — Optional Confidential Governance Node . 879 11.21.26. WF-21.26 — Optional Hardware Watchdog Interlock . . 880 11.21.27. WF-21.27 — Protected Revocation Fence . . . . . . . 880 11.21.28. WF-21.28 — Protection Against Hardware Bypass Paths . . . . . . . . . . . . . . . . . . . . . . . . 881 11.21.29. WF-21.29 — Independent Hardware Effectuation Verification . . . . . . . . . . . . . . . . . . . . 882 11.21.30. WF-21.30 — Capability Consumption and Concurrency . . . . . . . . . . . . . . . . . . . . . 882 11.21.31. WF-21.31 — Device Reset and Recovery . . . . . . . 883 11.21.32. WF-21.32 — Partial Transfer and Indeterminate Completion . . . . . . . . . . . . . . . . . . . . . 883 11.21.33. WF-21.33 — Illustrative NIC Egress Finality . . . . 884 11.21.34. WF-21.34 — Illustrative GPU DMA Finality . . . . . 885 11.21.35. WF-21.35 — Illustrative DPU Watchdog and Revocation Interlock . . . . . . . . . . . . . . . . . . . . . . 885 11.21.36. WF-21.36 — Illustrative Confidential Governance VM and SmartNIC . . . . . . . . . . . . . . . . . . . . 886 11.21.37. WF-21.37 — Failure and Fail-Closed Conditions . . . 886 11.21.38. WF-21.38 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . . 888 11.21.39. WF-21.39 — Claim-Specific Technical Coverage . . . 890 11.21.40. WF-21.40 — Technical Effect . . . . . . . . . . . . 892 11.22. WF-22 — Portable Cloud-VM Agent Authority, Cross-Cloud Workload Identity, Runtime Policy-Epoch Synchronization, Hardware-Supervised Egress, Migration and Snapshot Protection, and Downstream Effectuation Finality . . . 893 11.22.1. WF-22.1 — Technical Purpose . . . . . . . . . . . . 893 11.22.2. WF-22.2 — Participating Technical Components . . . 895 11.22.3. WF-22.3 — Supported Portable AI Execution Substrates . . . . . . . . . . . . . . . . . . . . . 898 11.22.4. WF-22.4 — Separation of Workload Deployment and Execution Authority . . . . . . . . . . . . . . . . . 898 11.22.5. WF-22.5 — Establishment of the Workload Identity . 899 11.22.6. WF-22.6 — Execution-Context Measurement . . . . . . 900 11.22.7. WF-22.7 — Authentication of the Execution-Context Measurement . . . . . . . . . . . . . . . . . . . . . 901 11.22.8. WF-22.8 — Protected Workload Authority Registration . . . . . . . . . . . . . . . . . . . . 902 11.22.9. WF-22.9 — Candidate Act Generation . . . . . . . . 903 11.22.10. WF-22.10 — Interception and Non-Effective Staging . . . . . . . . . . . . . . . . . . . . . . . 903 11.22.11. WF-22.11 — Candidate Act Descriptor . . . . . . . . 904 Das Expires 19 April 2027 [Page 35] Internet-Draft Protected AI Execution Finality October 2026 11.22.12. WF-22.12 — Canonical Candidate Act Representation . . . . . . . . . . . . . . . . . . . 905 11.22.13. WF-22.13 — Protected Operation Authorization . . . 906 11.22.14. WF-22.14 — Protected Authorization Predicate . . . 907 11.22.15. WF-22.15 — Protected Authorization-State Handling . . . . . . . . . . . . . . . . . . . . . . 907 11.22.16. WF-22.16 — Protected Validation-Evidence Commitment . . . . . . . . . . . . . . . . . . . . . 908 11.22.17. WF-22.17 — Scoped Portable-Workload Execution Capability . . . . . . . . . . . . . . . . . . . . . 909 11.22.18. WF-22.18 — Illustrative Cryptographic Capability . 910 11.22.19. WF-22.19 — Independent Finality Sink Verification . . . . . . . . . . . . . . . . . . . . 911 11.22.20. WF-22.20 — Finality Verification Predicate . . . . 911 11.22.21. WF-22.21 — Protected Runtime Policy Updates Across Replicas . . . . . . . . . . . . . . . . . . . . . . 912 11.22.22. WF-22.22 — Authorization-State Version Advancement . . . . . . . . . . . . . . . . . . . . . 913 11.22.23. WF-22.23 — Replica Consistency and Stale Capability Rejection . . . . . . . . . . . . . . . . . . . . . . 914 11.22.24. WF-22.24 — Hardware-Supervised Cloud Egress . . . . 915 11.22.25. WF-22.25 — Hardware Egress Admission Sequence . . . 915 11.22.26. WF-22.26 — Identification of Runtime Transitions . 916 11.22.27. WF-22.27 — Runtime-Transition State Record . . . . 917 11.22.28. WF-22.28 — Migration of Pending Candidate Acts . . 918 11.22.29. WF-22.29 — Runtime Migration Revalidation Predicate . . . . . . . . . . . . . . . . . . . . . . 918 11.22.30. WF-22.30 — Snapshot and Checkpoint Restoration . . 919 11.22.31. WF-22.31 — Protected Capability-Consumption State Across Migration . . . . . . . . . . . . . . . . . . 920 11.22.32. WF-22.32 — Duplicate Effectuation Prevention During Failover . . . . . . . . . . . . . . . . . . . . . . 920 11.22.33. WF-22.33 — Failover State-Reconciliation Procedure . . . . . . . . . . . . . . . . . . . . . . 921 11.22.34. WF-22.34 — Model-Access Authorization . . . . . . . 922 11.22.35. WF-22.35 — Separate Downstream Operation Authorization . . . . . . . . . . . . . . . . . . . . 922 11.22.36. WF-22.36 — Interruption or Revocation of Future Model Access . . . . . . . . . . . . . . . . . . . . . . . 923 11.22.37. WF-22.37 — Illustrative Cross-Cloud Migration . . . 924 11.22.38. WF-22.38 — Illustrative Kubernetes Replica Policy Update . . . . . . . . . . . . . . . . . . . . . . . 924 11.22.39. WF-22.39 — Illustrative SmartNIC-Supervised Agent Egress . . . . . . . . . . . . . . . . . . . . . . . 925 11.22.40. WF-22.40 — Illustrative Snapshot Replay . . . . . . 925 11.22.41. WF-22.41 — Illustrative Model-Path and Effectuation-Path Separation . . . . . . . . . . . . 926 Das Expires 19 April 2027 [Page 36] Internet-Draft Protected AI Execution Finality October 2026 11.22.42. WF-22.42 — Time-of-Check and Time-of-Use Protection . . . . . . . . . . . . . . . . . . . . . 926 11.22.43. WF-22.43 — Fail-Closed Runtime Policy Handling . . 927 11.22.44. WF-22.44 — Alternative Technical Implementations . 928 11.22.45. WF-22.45 — Failure and Fail-Closed Conditions . . . 929 11.22.46. WF-22.46 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . . 930 11.22.47. WF-22.47 — Claim-Specific Technical Support . . . . 933 11.22.48. WF-22.48 — Technical Effect . . . . . . . . . . . . 935 11.23. WF-23 — Atomic Protected-State Consumption, Validation-Evidence Commitment, Non-Bearer Capability Replay Prevention, Crash-Consistent Finality, and Duplicate-Effect Recovery . . . . . . . . . . . . . . . 937 11.23.1. WF-23.1 — Technical Purpose . . . . . . . . . . . . 937 11.23.2. WF-23.2 — Participating Technical Components . . . 938 11.23.3. WF-23.3 — Establishment of the Protected Authorization Boundary . . . . . . . . . . . . . . . 941 11.23.4. WF-23.4 — Distinguishing Authorization from Effectuation . . . . . . . . . . . . . . . . . . . . 942 11.23.5. WF-23.5 — Candidate Act Generation . . . . . . . . 942 11.23.6. WF-23.6 — Candidate Act Identifier and Attempt Identifier . . . . . . . . . . . . . . . . . . . . . 943 11.23.7. WF-23.7 — Interception and Non-Effective State . . 944 11.23.8. WF-23.8 — Canonical Candidate Act Descriptor . . . 945 11.23.9. WF-23.9 — Protected Grant-State Record . . . . . . 946 11.23.10. WF-23.10 — Grant Eligibility Verification . . . . . 947 11.23.11. WF-23.11 — Atomic Protected-State Transition . . . 947 11.23.12. WF-23.12 — Concurrency and Double-Consumption Prevention . . . . . . . . . . . . . . . . . . . . . 948 11.23.13. WF-23.13 — Protected Grant Reservation . . . . . . 949 11.23.14. WF-23.14 — Atomic Finality Commit . . . . . . . . . 950 11.23.15. WF-23.15 — Protected Validation-Evidence Commitment . . . . . . . . . . . . . . . . . . . . . 950 11.23.16. WF-23.16 — Capability Preparation Versus Capability Release . . . . . . . . . . . . . . . . . . . . . . . 951 11.23.17. WF-23.17 — Scoped Non-Bearer Capability . . . . . . 952 11.23.18. WF-23.18 — Current-State Finality Sink Verification . . . . . . . . . . . . . . . . . . . . 953 11.23.19. WF-23.19 — Finality Verification Predicate . . . . 954 11.23.20. WF-23.20 — Capability Consumption at Effectuation . . . . . . . . . . . . . . . . . . . . 955 11.23.21. WF-23.21 — Formal Candidate Act State Machine . . . 955 11.23.22. WF-23.22 — Protected Effectuation Outcome State . . 956 11.23.23. WF-23.23 — Distinction Between Reserved and Confirmed Effective . . . . . . . . . . . . . . . . . . . . . . 957 11.23.24. WF-23.24 — Anti-Replay Protection . . . . . . . . . 958 11.23.25. WF-23.25 — Replay-Prevention Predicate . . . . . . 959 Das Expires 19 April 2027 [Page 37] Internet-Draft Protected AI Execution Finality October 2026 11.23.26. WF-23.26 — Cross-Destination and Cross-Sink Reuse Prevention . . . . . . . . . . . . . . . . . . . . . 959 11.23.27. WF-23.27 — Retry Following Timeout . . . . . . . . 960 11.23.28. WF-23.28 — Protected Recovery Predicate . . . . . . 961 11.23.29. WF-23.29 — Recovery After Failure Before Protected Commitment . . . . . . . . . . . . . . . . . . . . . 962 11.23.30. WF-23.30 — Recovery After Commitment but Before Capability Delivery . . . . . . . . . . . . . . . . . 962 11.23.31. WF-23.31 — Recovery After Capability Delivery but Before Effectuation . . . . . . . . . . . . . . . . . 963 11.23.32. WF-23.32 — Recovery After Effectuation Attempt . . 964 11.23.33. WF-23.33 — Receiving-Side Reconciliation . . . . . 964 11.23.34. WF-23.34 — Idempotency and Duplicate-Effect Protection . . . . . . . . . . . . . . . . . . . . . 965 11.23.35. WF-23.35 — Protected Retry Authority . . . . . . . 966 11.23.36. WF-23.36 — Revocation During an Interrupted Operation . . . . . . . . . . . . . . . . . . . . . . 966 11.23.37. WF-23.37 — Snapshot and State-Rollback Protection . . . . . . . . . . . . . . . . . . . . . 967 11.23.38. WF-23.38 — Distributed Protected-State Consistency . . . . . . . . . . . . . . . . . . . . . 967 11.23.39. WF-23.39 — Atomicity and Remote-Effect Limitation . . . . . . . . . . . . . . . . . . . . . 968 11.23.40. WF-23.40 — Illustrative Atomic Grant Consumption . 969 11.23.41. WF-23.41 — Illustrative Crash Before Capability Release . . . . . . . . . . . . . . . . . . . . . . . 970 11.23.42. WF-23.42 — Illustrative Timeout After Credential-Mediated Effectuation . . . . . . . . . . 970 11.23.43. WF-23.43 — Illustrative Snapshot Replay . . . . . . 971 11.23.44. WF-23.44 — Illustrative Cross-Sink Capability Reuse . . . . . . . . . . . . . . . . . . . . . . . . 971 11.23.45. WF-23.45 — Alternative Technical Implementations . 972 11.23.46. WF-23.46 — Failure and Fail-Closed Conditions . . . 973 11.23.47. WF-23.47 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . . 974 11.23.48. WF-23.48 — Claim-Specific Technical Support . . . . 977 11.23.49. WF-23.49 — Technical Effect . . . . . . . . . . . . 978 11.24. WF-24 — Multiple Finality Sinks, Independent Downstream Verification, Multi-Boundary Candidate Act Classification, Receiving-Side Finality, and Protected Cross-Boundary Execution Authority . . . . . . . . . . . . . . . . . . 979 11.24.1. WF-24.1 — Technical Purpose . . . . . . . . . . . . 980 11.24.2. WF-24.2 — Participating Technical Components . . . 981 11.24.3. WF-24.3 — Distinction Between Computation and Effectuation . . . . . . . . . . . . . . . . . . . . 984 11.24.4. WF-24.4 — Identification of Distinct Effectuation Classes . . . . . . . . . . . . . . . . . . . . . . . 985 11.24.5. WF-24.5 — Effectuation Boundary Registry . . . . . 985 Das Expires 19 April 2027 [Page 38] Internet-Draft Protected AI Execution Finality October 2026 11.24.6. WF-24.6 — Classification of a Multi-Operation Workflow . . . . . . . . . . . . . . . . . . . . . . 986 11.24.7. WF-24.7 — Separation of Delegation from Downstream Effectuation . . . . . . . . . . . . . . . . . . . . 987 11.24.8. WF-24.8 — Delegation Acceptance Boundary . . . . . 988 11.24.9. WF-24.9 — Subordinate-Agent Candidate Act . . . . . 988 11.24.10. WF-24.10 — Separation of Model Admission from Downstream Effectuation . . . . . . . . . . . . . . . 989 11.24.11. WF-24.11 — Inference-to-Act Context Binding . . . . 990 11.24.12. WF-24.12 — Candidate Act Generation and Holding . . 990 11.24.13. WF-24.13 — Operation-Specific Descriptor Formation . . . . . . . . . . . . . . . . . . . . . . 991 11.24.14. WF-24.14 — Canonical Candidate Act Representation . . . . . . . . . . . . . . . . . . . 992 11.24.15. WF-24.15 — Operation-Specific Authority Validation . . . . . . . . . . . . . . . . . . . . . 993 11.24.16. WF-24.16 — Protected Authorization Predicate . . . 994 11.24.17. WF-24.17 — Protected Authorization-State Handling . . . . . . . . . . . . . . . . . . . . . . 994 11.24.18. WF-24.18 — Protected Validation-Evidence Commitment . . . . . . . . . . . . . . . . . . . . . 995 11.24.19. WF-24.19 — Scoped Execution-Capability Release . . 996 11.24.20. WF-24.20 — Independent Finality Sink Verification . . . . . . . . . . . . . . . . . . . . 997 11.24.21. WF-24.21 — Effectuation Verification Predicate . . 998 11.24.22. WF-24.22 — Multi-Sink Capability Independence . . . 998 11.24.23. WF-24.23 — Receiving-Side Finality . . . . . . . . 999 11.24.24. WF-24.24 — Remote Actual-Operation Descriptor . . .1000 11.24.25. WF-24.25 — Receiving-Side Verification Predicate .1000 11.24.26. WF-24.26 — Source-Side Transmission and Receiving-Side Commitment . . . . . . . . . . . . . .1001 11.24.27. WF-24.27 — Streaming Outputs and Partial Actions .1002 11.24.28. WF-24.28 — Buffering of Consequential Streaming Output . . . . . . . . . . . . . . . . . . . . . . .1003 11.24.29. WF-24.29 — Model-Access Interruption and Buffered Operations . . . . . . . . . . . . . . . . . . . . .1003 11.24.30. WF-24.30 — Multi-Hop Agent Workflow . . . . . . . .1004 11.24.31. WF-24.31 — Scoped Multi-Stage Authorization . . . .1004 11.24.32. WF-24.32 — Cross-Boundary Context Continuity . . .1005 11.24.33. WF-24.33 — Separate Credential Application . . . .1006 11.24.34. WF-24.34 — Separate Persistent-State Commitment . .1006 11.24.35. WF-24.35 — Separate Payment Effectuation . . . . .1006 11.24.36. WF-24.36 — Cross-Sink Capability Substitution . . .1007 11.24.37. WF-24.37 — Protected State Across Multiple Sinks .1007 11.24.38. WF-24.38 — Revocation Across Consequential Boundaries . . . . . . . . . . . . . . . . . . . . .1008 11.24.39. WF-24.39 — Protected Operation Outcomes . . . . . .1008 Das Expires 19 April 2027 [Page 39] Internet-Draft Protected AI Execution Finality October 2026 11.24.40. WF-24.40 — Crash and Recovery Across Multiple Finality Sinks . . . . . . . . . . . . . . . . . . .1009 11.24.41. WF-24.41 — Receiving-Side Completion Reconciliation . . . . . . . . . . . . . . . . . . .1010 11.24.42. WF-24.42 — Illustrative End-to-End Enterprise Agent Workflow . . . . . . . . . . . . . . . . . . . . . .1011 11.24.43. WF-24.43 — Illustrative Remote Payment Verification . . . . . . . . . . . . . . . . . . . .1012 11.24.44. WF-24.44 — Illustrative Model-Quarantine Scenario . . . . . . . . . . . . . . . . . . . . . .1012 11.24.45. WF-24.45 — Illustrative Delegated-Agent Boundary .1013 11.24.46. WF-24.46 — Illustrative Cross-Sink Replay . . . . .1013 11.24.47. WF-24.47 — Alternative Technical Implementations .1014 11.24.48. WF-24.48 — Failure and Fail-Closed Conditions . . .1015 11.24.49. WF-24.49 — PHOSITA Verification and Negative Tests . . . . . . . . . . . . . . . . . . . . . . . .1016 11.24.50. WF-24.50 — Claim-Specific Technical Coverage . . .1019 11.24.51. WF-24.51 — Technical Effect . . . . . . . . . . . .1020 12. Deployment Contexts . . . . . . . . . . . . . . . . . . . . .1022 13. Technical Enforcement Points and Boundary Conditions . . . .1031 13.1. EP-01: Protected AI-Agent Sandbox Egress Finality System . . . . . . . . . . . . . . . . . . . . . . . .1031 13.2. EP-02: Sandbox Boundary Interception . . . . . . . . . .1033 13.3. EP-03: Concrete Act Descriptor . . . . . . . . . . . . .1033 13.4. EP-04: Intent, Logic and Behavioral Verification . . . .1033 13.5. EP-05: Untrusted Content and Taint-Lineage Governance .1034 13.6. EP-06: Network Egress Finality . . . . . . . . . . . . .1034 13.7. EP-07: Credential Broker Finality . . . . . . . . . . .1034 13.8. EP-08: File, Shell and Host-System Enforcement . . . . .1035 13.9. EP-09: Protected Human Approval . . . . . . . . . . . .1035 13.10. EP-10: Agent-Initiated Policy Mutation . . . . . . . . .1035 13.11. EP-11: Sub-Agent Delegation . . . . . . . . . . . . . .1036 13.12. EP-12: Continuous Egress Validation . . . . . . . . . .1036 13.13. EP-13: Revocation and Policy-Epoch Enforcement . . . . .1036 13.14. EP-14: Hardware-Rooted Enforcement . . . . . . . . . . .1037 13.15. EP-15: Browser and Computer-Use Finality . . . . . . . .1037 13.16. EP-16: Autonomous Commerce . . . . . . . . . . . . . . .1037 13.17. EP-17: Privacy-Preserving Validation Receipt . . . . . .1038 13.18. EP-18: Fail-Closed Denial and Containment . . . . . . .1038 13.19. EP-19: Canonical Authorization-to-Execution Binding . .1038 13.20. EP-20: Protected Grant-State Consumption . . . . . . . .1038 13.21. EP-21: Atomic Credential-Release Transaction . . . . . .1039 13.22. EP-22: Privileged Connector Verification . . . . . . . .1039 13.23. EP-23: Destination Resolution and Redirect Consistency . . . . . . . . . . . . . . . . . . . . . .1039 13.24. EP-24: Crash, Retry and Duplicate-Effect Protection . .1040 13.25. EP-25: Process-Lineage Authority Degradation . . . . . .1040 13.26. EP-26: Policy Mutation Activation Interlock . . . . . .1040 Das Expires 19 April 2027 [Page 40] Internet-Draft Protected AI Execution Finality October 2026 13.27. EP-27: Cross-Component Finality Consistency . . . . . .1041 13.28. EP-28: Transaction-Bound Agent Authorization and Credential Effectuation System . . . . . . . . . . . .1041 13.29. EP-29: Protected Credential Substitution . . . . . . . .1042 13.30. EP-30: Independent Executor Attestation . . . . . . . .1043 13.31. EP-31: Protected Effectuation Outcome State . . . . . .1043 13.32. EP-32: Method of Protected Agent Egress Finality . . . .1043 13.33. EP-33: State-Bound Finality and Replay Protection . . .1044 13.34. EP-34: Protected Self-Modification Finality System . . .1045 13.35. EP-35: Before-and-After Policy Binding . . . . . . . . .1046 13.36. EP-36: Evaluation and Regression Evidence . . . . . . .1046 13.37. EP-37: Developer Approval as a Protected Predicate . . .1046 13.38. EP-38: Runtime Revocation and Mutation Revalidation . .1046 13.39. EP-39: Protected Sub-Agent Delegation Finality System .1047 13.40. EP-40: Child-Agent Scope Restriction . . . . . . . . . .1048 13.41. EP-41: Recursive Delegation Control . . . . . . . . . .1048 13.42. EP-42: Separation of Delegation from Downstream Effectuation . . . . . . . . . . . . . . . . . . . . .1048 13.43. EP-43: Protected Autonomous Code-Deployment Finality System . . . . . . . . . . . . . . . . . . . . . . . .1048 13.44. EP-44: Artifact and Commit Binding . . . . . . . . . . .1049 13.45. EP-45: Protected Signing or Publication Key . . . . . .1050 13.46. EP-46: Agent-Generated Skill Deployment . . . . . . . .1050 13.47. EP-47: Staged Deployment and Drift Interruption . . . .1050 13.48. EP-48: Protected Cross-Domain AI-Fabric Transfer Finality System . . . . . . . . . . . . . . . . . . . . . . . .1050 13.49. EP-49: Fabric Transfer Descriptor Granularity . . . . .1052 13.50. EP-50: Hardware-Latched Transfer Admission . . . . . . .1052 13.51. EP-51: Continuous Tensor or Memory-Transfer Validation . . . . . . . . . . . . . . . . . . . . . .1052 13.52. EP-52: Hardware-Freshness Binding . . . . . . . . . . .1052 13.53. EP-53: Separated Cold-Path Validation and Line-Rate Finality . . . . . . . . . . . . . . . . . . . . . . .1053 13.54. EP-54: Protected Pre-Computation Model Admission System . . . . . . . . . . . . . . . . . . . . . . . .1053 13.55. EP-55: Model and Workflow Measurement Binding . . . . .1054 13.56. EP-56: Protected Model-Loader Admission . . . . . . . .1054 13.57. EP-57: Separate Downstream Execution Authority . . . . .1054 13.58. EP-58: Protected Service-Mesh Effectuation System . . .1055 13.59. EP-59: Service Identity and Session Binding . . . . . .1056 13.60. EP-60: Service-Mesh Bypass Prevention . . . . . . . . .1056 13.61. EP-61: Fail-Closed Route and Policy Mismatch . . . . . .1056 13.62. EP-62: Distributed Hardware-Watchdog Execution Interlock System . . . . . . . . . . . . . . . . . . . . . . . .1056 13.63. EP-63: Hardware-Attested Monitoring State . . . . . . .1057 13.64. EP-64: Watchdog-to-Finality Revocation Fence . . . . . .1057 13.65. EP-65: Prevention Despite Continued Model Access . . . .1058 13.66. EP-66: Monitoring Failure and Stale-State Handling . . .1058 Das Expires 19 April 2027 [Page 41] Internet-Draft Protected AI Execution Finality October 2026 13.67. EP-67: Quarantine with Effectuation-State Preservation . . . . . . . . . . . . . . . . . . . . .1058 13.68. EP-68: Model-Path and Effectuation-Path Dual Authorization System . . . . . . . . . . . . . . . . . . . . . . . .1058 13.69. EP-69: Inference-to-Act Context Binding . . . . . . . .1060 13.70. EP-70: Streaming Output and Partial-Action Control . . .1060 13.71. EP-71: Multi-Sink Effectuation Classification . . . . .1060 13.72. EP-72: Remote Effectuation Verification . . . . . . . .1060 13.73. EP-73: Confidential Cloud AI-Agent Execution and Cryptographic Finality . . . . . . . . . . . . . . . .1061 13.74. EP-74: Hardware-Rooted Composite ALF . . . . . . . . . .1062 13.75. EP-75: Measured Workload Configuration . . . . . . . . .1062 13.76. EP-76: Privacy-Preserving Cryptographic Validation . . .1063 13.77. EP-77: Cloud Tenant and Destination Scope . . . . . . .1063 13.78. EP-78: Virtual-Machine Snapshot Replay Resistance . . .1063 13.79. EP-79: Confidential Governance VM and Hardware-Attested SmartNIC Finality . . . . . . . . . . . . . . . . . . .1063 13.80. EP-80: Confidential VM Attestation Object . . . . . . .1064 13.81. EP-81: Confidential Governance-Key Isolation . . . . . .1065 13.82. EP-82: Attestation Change Disables Capability Issuance . . . . . . . . . . . . . . . . . . . . . . .1065 13.83. EP-83: Cryptographically Bound Hardware Freshness . . .1065 13.84. EP-84: User-Controlled Confidential VM with Cryptographically Bound Execution Authority . . . . . .1065 13.85. EP-85: User-Held Root-Key and Attested Derived-Key Release . . . . . . . . . . . . . . . . . . . . . . . .1066 13.86. EP-86: Dual Authorization for Decryption and External Effect . . . . . . . . . . . . . . . . . . . . . . . .1067 13.87. EP-87: Cryptographic Binding of Confidential-VM State to Candidate Act . . . . . . . . . . . . . . . . . . . . .1067 13.88. EP-88: Privacy-Preserving Execution Evidence . . . . . .1067 13.89. EP-89: Confidential-VM Recovery and Key-State Continuity . . . . . . . . . . . . . . . . . . . . . .1068 13.90. EP-90: Portable Cloud-VM Agent Authority and Hardware Effectuation System . . . . . . . . . . . . . . . . . .1068 13.91. EP-91: VM and Container Identity Attestation . . . . . .1069 13.92. EP-92: Runtime Policy Changes Across Cloud Replicas . .1069 13.93. EP-93: Hardware-Supervised Cloud Egress . . . . . . . .1070 13.94. EP-94: Cross-Runtime Migration and Snapshot Protection . . . . . . . . . . . . . . . . . . . . . .1070 13.95. EP-95: Model-Path Authorization Does Not Replace Effectuation Authorization . . . . . . . . . . . . . .1070 14. Security Considerations . . . . . . . . . . . . . . . . . . .1070 14.1. Threat Model and Enforcement Coverage . . . . . . . . .1071 14.2. Canonicalization and Operation Substitution . . . . . .1071 14.3. Capability Protection and Context Binding . . . . . . .1071 14.4. Protected State, Revocation, and Fail-Closed Behavior .1071 14.5. Credential and Delegation Boundaries . . . . . . . . . .1072 Das Expires 19 April 2027 [Page 42] Internet-Draft Protected AI Execution Finality October 2026 14.6. Monitoring Versus Prevention . . . . . . . . . . . . . .1072 14.7. Remote Completion and Recovery Limits . . . . . . . . .1072 14.8. Operational Assurance and Testing . . . . . . . . . . .1072 15. Relationship to Existing Standards . . . . . . . . . . . . .1073 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . .1073 17. References . . . . . . . . . . . . . . . . . . . . . . . . .1073 Author's Address . . . . . . . . . . . . . . . . . . . . . . . .1073 1. Status, Scope, and Interpretation This document presents technical enforcement approaches for Internet community review. Terminology such as Candidate Act, Protected Enforcement Domain, and Finality Sink denotes architectural functions; it is not intended to state patent claim scope. The collection of techniques is not a single mandatory interoperable profile. Deployment claims of non-bypassability and fail-closed operation require implementation-specific threat models and evidence. 2. Industry Terminology and Technical Scope This document examines AI-agent sandbox isolation, independent permission authorities, mandatory network-egress enforcement, credential brokering, runtime policy controls, and hardware-assisted security mechanisms discussed in publicly documented systems including Meta Muse/Sentinel and NVIDIA OpenShell/Sentry, with particular attention to protected authorization-state commitment, act-bound non-bearer execution capabilities, and independent verification at consequential effectuation boundaries. Contemporary AI-agent security architectures are described using terminology such as sandboxed agent execution, out-of-process policy enforcement, isolated agent runtimes, mandatory network-egress mediation, credential brokering, privileged connectors, executable- specific permissions, runtime policy approval, hardware-assisted monitoring, and model-access governance. Public implementations and architectural discussions associated with these areas include Meta Muse/Sentinel and NVIDIA OpenShell, NemoClaw, and the Open Agent Safety Platform, including Sentry and BlueField-based monitoring and enforcement. These references identify relevant engineering contexts and publicly used terminology; they do not establish architectural identity, implementation equivalence, historical priority, or the presence of every mechanism described in this document. Industry and product names in this document are used solely as factual identifiers and search terminology to illustrate the relevance of public technical discussions and to facilitate Das Expires 19 April 2027 [Page 43] Internet-Draft Protected AI Execution Finality October 2026 independent architectural examination. All such names and trademarks remain the property of their respective owners. Their inclusion does not imply endorsement, affiliation, sponsorship, access to nonpublic information, copying, derivation, infringement, validity or scope of any patent claim, or that the named systems implement the complete mechanisms described here. Any functional correspondence must be evaluated from dated primary technical disclosures; chronology and patent priority require separate documentary and legal assessment. The architecture described here additionally examines the technical conditions under which a generated operation acquires authority to produce a consequential effect. Its principal proposed enforcement sequence includes: 1. Mandatory interception of a proposed Candidate Act before its governed effectuation boundary. 2. Maintenance of the Candidate Act in a Non-Effective State. 3. Construction of a verifiable, effectuation-relevant Candidate Act Descriptor. 4. Protected authorization-predicate validation and required protected-state handling. 5. Commitment of mandatory validation evidence before, or atomically with, scoped execution-capability availability. 6. Release or activation of an act-bound, non-bearer execution capability. 7. Verification of that capability against the actual operation and required current state at the applicable Finality Sink. 8. Fail-closed withholding where mandatory verification fails. The architecture distinguishes sandbox confinement, policy approval, credential isolation, computation admission, hardware monitoring, and post-event quarantine from the separate authorization conditions required for a consequential downstream operation. It addresses enforcement arrangements involving agent runtimes, network proxies, API gateways, credential brokers, cloud service meshes, protected storage interfaces, confidential virtual machines, SmartNICs, data processing units, accelerator fabrics, and receiving- side execution interfaces. Das Expires 19 April 2027 [Page 44] Internet-Draft Protected AI Execution Finality October 2026 Computation, possession of a credential reference, admission to a model, or successful execution within a protected runtime does not independently confer authority to complete every downstream consequential operation. Each separately governed effectuation boundary remains subject to its applicable authorization and verification requirements. This document presents these mechanisms for technical examination and does not assert that the named industry systems implement the complete described sequence, derive from this work, or satisfy equivalent security guarantees. 3. Technical Discoverability and Architectural Terminology This section supplies search terminology and technical examination questions for readers studying AI-agent security architectures, including the publicly described Meta Muse and Sentinel architecture announced on 8 September 2026. It is a discoverability and engineering-comparison aid, not an assertion of copying, infringement, patentability, identity, or adoption by Meta. Product- specific descriptions should be independently checked against the original dated Meta publication and any relevant as-released technical materials. 3.1. Product Names and Search Expressions Examples of text search expressions that may help locate discussions of the named system and related protected execution mechanisms follow. They are suggested queries rather than claims about any patent examiner's actual search practice. * "Meta Muse" "Sentinel" "AI agent" * "Muse Secure VM" "sandbox" "agent" * "Sentinel" "permission authority" "egress" * "surrogate credential" "credential broker" "proxy" * "agent" "egress" "destination" "policy" * "Sentinel" "privileged connector" "host worker" * "Muse" "taint" "eBPF" "LSM" * "Meta Muse" "approval" "tool execution" * "agent" "concrete operation" "authorization" Das Expires 19 April 2027 [Page 45] Internet-Draft Protected AI Execution Finality October 2026 * "Candidate Act" "Finality Sink" "execution capability" * "AI-agent sandbox security" "independent host-side permission authority" * "network egress enforcement" "protected credential brokering" * "concrete-operation authorization" "act-bound execution capabilities" * "independent effectuation-boundary verification" "downstream consequence" 3.2. Published-System Vocabulary and Corresponding Technical Examination Topics In public descriptions of Meta Muse/Sentinel, the following terminology provides starting points for examination. The adjacent execution-finality terminology identifies a question or possible functional correspondence, not an assertion that Meta provides the full execution-finality mechanism. * Sentinel as a host-side or outside-runtime permission authority: examine isolation of authorization logic and state from the agent; compare to a Protected Enforcement Domain (PED) only to the extent its protected authority functions are established. * Muse runtime and isolated agent execution cell, including the Muse Secure VM: examine sandbox boundaries, mandatory mediation, privileged host services, and all reachable bypass paths. * Agent-generated actions subject to Sentinel allow, deny, or ask decisions: examine separation of computation from permission authority, the concreteness of the request checked, and human approval as a protected predicate. * Controlled forward proxy and host-side network egress: examine executable, destination, protocol, port, HTTP method and path, decoded request content, DNS resolution, selected IP address, redirect, connection reuse, and the actual governed network effect. * Credential isolation, surrogate credentials, host credential services, and just-in-time application of real credentials: examine non-authoritative references, credential custody, authenticated connector identity, concrete request binding, and whether credential use is separately verified at the effectuation interface. Das Expires 19 April 2027 [Page 46] Internet-Draft Protected AI Execution Finality October 2026 * Privileged host-side connectors or workers: examine separated connector execution, authenticated service interfaces, granted credential allowlists, and verification of requested operations. * Provenance, taint, eBPF and Linux Security Module (LSM) enforcement: examine how lower-trust input influences process, subprocess, session, or action lineage and whether that influence changes automatic permissions or requires escalated approval. * Approval workflows and runtime policy changes: examine what an authorized developer or user approves, whether the approval matches the actual operation, and whether subsequent policy or revocation state invalidates earlier permission. * Execution-finality terms for separate study: Candidate Act, Non- Effective State (NES), Candidate Act Descriptor (CAD), protected validation-evidence commitment, scoped non-bearer capability, Finality Gate, Finality Sink, protected grant consumption, and independent receiving-side effectuation verification. 3.3. Five Technical Examination Questions These questions distinguish ordinary permission controls from the more specific causal requirements discussed elsewhere in this draft. * Authority separation: is permission controlled independently of the agent, and which protected component exclusively manages applicable validation logic, state, and enablement? * Concrete-operation binding: which exact request, destination, executable or connector, credential scope, requesting context, payload attributes, and policy version are validated? * Protected authorization state: how are grants, usage limits, policy changes, revocation, nonce freshness, reservation, and consumption handled under concurrent or retried operations? * Execution enablement: does the implementation use an internal allow/deny/ask decision or a separately authenticated and scoped capability, and if a capability exists, what actual verifier checks its bindings? * Final enforcement boundary: is the actual consequential operation verified immediately before effectuation, and does upstream network permission remain distinct from receiving-side database commitment, payment execution, storage modification, or other separately governed effects? Das Expires 19 April 2027 [Page 47] Internet-Draft Protected AI Execution Finality October 2026 3.4. Specific Architectural Distinctions Requiring Verification An isolated runtime, a policy decision, an egress proxy, and credential secrecy can each be valuable safeguards without independently proving that validation evidence was committed before capability availability, that an act-bound non-bearer capability was issued, or that a distinct Finality Sink verification occurred. In the protected execution-finality sequence described in this document, the proposed consequential operation is intercepted and held non-effective; an effectuation-relevant descriptor is formed; required protected authority predicates and state are checked; required validation evidence is committed before or atomically with capability availability; a scoped non-bearer execution capability is made available; the applicable Finality Sink checks that capability against the actual operation and mandatory current state; failure leaves the governed operation non-effective. The Finality Sink and PED are functionally distinct in this sequence but need not be in different physical devices. Whether Meta Muse/ Sentinel employs equivalent separate state, receipt, capability, consumption, or sink-verification conditions requires affirmative evidence, not inference from a host-side permission check. Source-side network forwarding authority does not itself establish receiving-side authorization for database mutation, financial settlement, persistent storage commit, or physical actuation. Similarly, stopping model inference or quarantining a workload after detection cannot retroactively prevent an already completed operation. Product names and terms appearing here are provided for independent research and keyword discoverability. They do not establish that a patent application supports a claimed combination at an earlier date; that assessment requires reading the particular as-filed application independently. 3.5. Combined Technical Search Phrase AI-agent sandbox security; independent host-side permission authority; network egress enforcement; protected credential brokering; concrete-operation authorization; act-bound execution capabilities; independent effectuation-boundary verification; privileged connectors; eBPF/LSM provenance and taint; developer approval; multi-sink downstream execution control. Das Expires 19 April 2027 [Page 48] Internet-Draft Protected AI Execution Finality October 2026 Industry terms are not defined as interchangeable with architectural components merely by their juxtaposition. A technical evaluation should distinguish announced behavior, implemented code, functional overlap, different enforcement guarantees, and missing evidence. 4. Author-Reported Indian Filing Chronology and Underlying Concepts The author identifies Indian application No. 202531130665, with a reported corrected filing date of 23 December 2025, as an earlier Indian filing concerning underlying execution-authority and execution-boundary concepts. The application number and corrected date are author-reported and are not independently authenticated in this Internet-Draft. The author further identifies separate Indian provisional applications dated 3 January, 7 January, and 12 January 2026 as earlier technical filings addressing aspects of cryptographic execution-time enforcement, protected authority at consequential commit or settlement boundaries, and multi-authority context- dependent execution authorization, respectively. Their individual disclosures must be examined independently when assessing support for any particular mechanism or combination. Indian application No. 202631124028 is separately identified below as patent pending. This document does not establish that this application was filed in January 2026 or that it is legally entitled to the filing date of any earlier application. Priority entitlement, incorporation, continuity, and support for specific subject matter depend on the relevant official application records and the disclosures actually present in each filing. The dates and application identifiers in this subsection provide research and patent-disclosure context only; they do not assert that all architectural features, workflows, or enforcement points in this Internet-Draft were disclosed on 23 December 2025 or in any single January 2026 application. 5. Related Patent Applications and Intellectual Property Disclosure Patent-pending notice: The author identifies Indian patent application No. 202631124028 as a patent application associated with the general subject area of protected AI-agent execution and execution-finality enforcement. Its filing date, exact disclosure coverage, prosecution status, and relationship to particular portions of this Internet-Draft have not been independently verified in this document. The application number is provided for discoverability, not as a statement of a granted patent, formal priority entitlement, or incorporation by reference. Das Expires 19 April 2027 [Page 49] Internet-Draft Protected AI Execution Finality October 2026 The author also identifies the following earlier Indian and international applications as related technical disclosures. Identifiers and reported publication designations are included to facilitate independent inspection of the underlying records. Each application remains a distinct document; listing applications together does not establish that a particular integrated technical combination is disclosed in any one of them. 5.1. Indian Applications and Earlier Disclosures Indian provisional application dated 3 January 2026: Cryptographic Execution-Time Enforcement System with Purpose- and Jurisdiction- Bound Authorization and Split Execution Control (application number not stated here). Indian provisional application dated 7 January 2026: Systems and Methods for Cryptographic Enforcement of Execution Authority at Commit-Time, Settlement-Time, and Other Irreversible System Boundaries in Distributed, Hardware-Backed Digital Systems (application number not stated here). Indian provisional application dated 12 January 2026: Systems and Methods for Execution-Time Authorization Using Multi-Authority, Quantum-Resilient, and Context-Adaptive Cryptographic Enforcement at Irreversible Execution Boundaries (application number not stated here). Indian application No. 202631124028: identified by the author as patent pending; the specific linkage to any earlier priority document is not established by this listing. 5.2. International Patent Application Identifiers Mothership baseline: PCT/IB2025/058316. No publication designation is asserted here. Filed in 2025 (author-reported date: 17 August 2025); no publication number has been verified for this entry. ALF-PCT: PCT/IB2026/053385. Reported publication: WO 2026/115520 A2. Published 4 June 2026. DAS Protocols I: PCT/IB2026/055615. Reported publication: WO 2026/150382. Published 16 July 2026. DAS Protocols II: PCT/IB2026/055760. Reported publication: WO 2026/150383. Published 16 July 2026. DAS Protocols III: PCT/IB2026/055870. Reported publication: WO 2026/150384. Published 16 July 2026. Das Expires 19 April 2027 [Page 50] Internet-Draft Protected AI Execution Finality October 2026 DAS Protocols IV: PCT/IB2026/056058. Reported publication: WO 2026/154461 A2. Published 23 July 2026. DAS Protocols V: PCT/IB2026/056809. Reported publication: WO 2026/172334. Published August 2026 (exact publication date not verified here). DAS Protocols VI: PCT/IB2026/056941. No publication designation is asserted here. Filing identifier supplied by the author; no verified publication designation is stated. 5.3. Publication, Priority, and Scope Distinctions A PCT filing and an international publication are distinct events; an unpublished application must not be described as publicly available merely because a filing identifier exists. Publication identifiers and dates should be checked against WIPO PATENTSCOPE or official filing records before being relied upon as documentary evidence. A patent application reference does not by itself establish patentability, validity, enforceable claim scope, ownership, effective priority for a specific technical feature, or an implemented and tested system. A later document cannot acquire earlier support for a particular combination merely by listing multiple earlier filings. Technical and priority assessments require the actual as-filed passages of each relevant application. 5.4. IETF IPR Disclosure Process This bibliographic notice is separate from the IETF intellectual- property-rights disclosure process. If applicable patent rights cover technology proposed for adoption or implementation in an IETF contribution, the relevant IETF IPR disclosure obligations and procedures must be addressed separately under the current IETF rules. This document does not state licensing terms or assert that an IETF IPR disclosure has been submitted for application No. 202631124028. The named industry architectures are mentioned only to aid technical search and discussion. Their inclusion is not an allegation of infringement, copying, technical derivation, or equivalence. 6. Scope and Technical Field [0001] the proposed architecture relates generally to computer security, artificial-intelligence systems, autonomous software agents, distributed computing, confidential computing, hardware- assisted enforcement, cryptographic authorization, and protection of consequential computer operations. Das Expires 19 April 2027 [Page 51] Internet-Draft Protected AI Execution Finality October 2026 [0002] More particularly, the architecture relates to systems and methods for separating the generation, computation, preparation, staging, or selection of an operation from the protected authority required to cause that operation to become externally effective. [0003] the architecture further relates to non-bypassable execution- finality enforcement, protected authorization-state management, operation-specific cryptographic capabilities, credential-release controls, confidential virtual machines, hardware attestation, agent delegation, sandbox egress, executable-specific permissions, multi- boundary authorization, accelerator and network-fabric transfers, hardware watchdogs, SmartNIC and data processing unit enforcement, cross-cloud workload portability, and fail-closed recovery. [0004] the architecture may be implemented in artificial-intelligence agent environments, enterprise computing, cloud and hybrid-cloud infrastructures, autonomous coding systems, software-development agents, model-serving infrastructure, protected tool execution, secure network interfaces, connected-service systems, storage controllers, transaction-processing systems, accelerators, and cyber- physical environments. [0005] the architecture is not restricted to any particular artificial-intelligence model, operating system, virtualization platform, processor architecture, cloud service provider, cryptographic algorithm, hardware vendor, or application protocol. 7. Background and Motivation 7.1. 1. Development of Autonomous Artificial-Intelligence Execution Systems [0006] Artificial-intelligence systems have evolved from predominantly informational processing systems into computational environments capable of generating, requesting, preparing, and initiating operations having practical consequences beyond the immediate model-computation process. [0007] Contemporary AI-agent environments may access enterprise information, generate software artifacts, invoke tools, initiate network communications, interact with external APIs, read or modify files, perform database operations, access connected services, coordinate subordinate agents, initiate deployments, and prepare financial or infrastructure-control instructions. Das Expires 19 April 2027 [Page 52] Internet-Draft Protected AI Execution Finality October 2026 [0008] An artificial-intelligence agent may autonomously select an execution path, determine tool arguments, construct a network request, or sequence several dependent operations without requiring a separate human decision for every intermediate computational step. [0009] Such systems introduce a technical distinction between the generation of a proposed operation and the authority required to produce its practical consequence. [0010] A computational component may be capable of constructing an executable operation while lacking independent authority to complete that operation. [0011] This distinction becomes particularly significant where an operation can produce persistent, externally visible, financially consequential, security-sensitive, cryptographically binding, or physically effective results. [0012] Examples include disclosure of confidential information, execution of production commands, modification of protected databases, application of privileged credentials, publication of software artifacts, transfer of accelerator-resident data, and transmission of commands to external infrastructure. [0013] A principal technical problem is therefore how to permit useful autonomous computation while ensuring that the corresponding consequential operation cannot become effective unless the required protected authorization conditions are satisfied. 7.2. 2. Limitations of Conventional Authentication and Authorization [0014] Conventional computing systems employ authentication, access- control lists, role-based access control, attribute-based access control, delegated permissions, access tokens, API credentials, operating-system permissions, network access rules, and related mechanisms to restrict access to resources. [0015] These mechanisms are useful and may provide strong security guarantees within their configured scopes. [0016] However, the fact that a process is authenticated or has access to a resource does not necessarily establish that every concrete consequential operation generated by the process has been separately evaluated against current operation-specific authority. Das Expires 19 April 2027 [Page 53] Internet-Draft Protected AI Execution Finality October 2026 [0017] An authenticated AI agent may possess a valid service credential while preparing a request involving an unauthorized destination, changed recipient, excessive transaction amount, prohibited data scope, or another context not permitted by the governing authority. [0018] A permission may apply to an account, service, application, process, resource, or session rather than being cryptographically or otherwise verifiably bound to the complete effectuation-relevant attributes of a particular operation. [0019] Similarly, an earlier authorization decision may become stale following a change in protected policy, delegation scope, workload identity, execution environment, revocation state, or resource configuration. [0020] A technical need therefore exists for arrangements in which authorization of a concrete operation is enforced at the boundary where that operation would acquire its governed practical effect. 7.3. 3. Separation of Computation and Execution Authority [0021] Artificial-intelligence computation and execution authority are distinguishable functions. [0022] Computation may include inference, reasoning, planning, simulation, tool selection, code generation, request preparation, and construction of executable instructions. [0023] Execution authority determines whether a particular proposed operation is permitted to cross the relevant boundary and produce a consequential effect. [0024] Conventional security arrangements may combine these functions within one process or application-controlled workflow. [0025] Where the requesting process can modify or bypass its own authorization logic, protected policy state, or enforcement mechanism, the resulting authority separation may be insufficient for the specified threat model. [0026] Accordingly, there is a need for architectures in which protected validation logic, authorization state, and execution- enablement authority are isolated from unilateral control by the requesting computational component. Das Expires 19 April 2027 [Page 54] Internet-Draft Protected AI Execution Finality October 2026 [0027] The computational component may continue generating proposals, but it cannot independently confer protected execution authority upon those proposals. 7.4. 4. Limitations of Sandboxing and Process Isolation Alone [0028] Sandboxes, containers, virtual machines, restricted runtimes, operating-system permissions, and process-isolation mechanisms are established approaches for controlling software behavior. [0029] These mechanisms can restrict accessible files, processes, system calls, network destinations, credentials, and other resources. [0030] Nevertheless, an isolated agent may legitimately possess access to selected tools, services, or interfaces capable of producing consequential effects. [0031] A sandbox may therefore prevent some prohibited activity while still requiring an additional authorization decision for a concrete operation passing through an otherwise permitted interface. [0032] For example, an agent may be authorized to invoke an enterprise API but not to submit every possible request or parameter combination supported by that API. [0033] Likewise, permission to communicate with an approved hostname does not necessarily determine whether a particular request body, recipient, data classification, operation type, or transaction amount is authorized. [0034] A further technical problem arises where a process may access alternative network interfaces, privileged connectors, host-side tools, storage services, or hardware paths that are not subject to the intended mandatory mediation. [0035] There is therefore a need for protected effectuation-path coverage that prevents a governed operation from acquiring its specified consequence through an accessible bypass interface. 7.5. 5. Limits of Model-Level Safety and Computation Admission [0036] Artificial-intelligence systems may employ input filtering, output filtering, model classifiers, safety policies, inference- admission controls, monitoring systems, and human approval procedures. [0037] Such mechanisms may reduce the likelihood of unsafe or unauthorized operations being proposed. Das Expires 19 April 2027 [Page 55] Internet-Draft Protected AI Execution Finality October 2026 [0038] However, a model-level safety determination and a downstream effectuation authorization control different technical events. [0039] A model may have already generated a consequential tool request before further inference is interrupted. [0040] A prepared request may remain buffered in an execution environment, connector, queue, service, or downstream component even after the model is prevented from producing further output. [0041] Consequently, interruption of future model access does not necessarily prevent a previously generated operation from becoming effective. [0042] Nor does successful model-admission authorization establish that every resulting network request, credential use, persistent mutation, or external command has been individually authorized. [0043] A technical need exists for downstream enforcement that remains effective independently of whether the model is permitted to continue inference. 7.6. 6. Credential Exposure and Privileged Tool Execution [0044] AI-agent environments frequently use service credentials, API keys, access tokens, signing keys, enterprise connectors, and other privileged mechanisms. [0045] Credential brokers, secret stores, delegated authorization, proxy-mediated requests, and privileged service interfaces can restrict direct exposure of sensitive credentials. [0046] Nevertheless, credential secrecy and operation authorization are distinct security properties. [0047] An agent may be unable to read a protected credential while still requesting a credential-mediated operation through an authorized broker. [0048] The corresponding broker must determine whether the concrete requested operation falls within the permitted authority. [0049] Where a credential is released, substituted, applied, or used to authenticate an operation, the application of that credential may itself form part of a consequential effectuation sequence. Das Expires 19 April 2027 [Page 56] Internet-Draft Protected AI Execution Finality October 2026 [0050] There is therefore a need to bind protected credential use to the particular authorized operation, destination, execution context, and effectuation boundary rather than treating access to a credential broker as unlimited permission to use the corresponding service identity. 7.7. 7. Delegated AI Agents and Authority Propagation [0051] Autonomous systems may delegate work to subordinate agents, tool processes, service workers, or other execution components. [0052] A delegation may authorize a specified task, tool category, data scope, execution budget, recursion depth, or time interval. [0053] However, admission of a delegated task is distinguishable from authorization of the consequential operations subsequently generated by the subordinate component. [0054] A subordinate agent may prepare requests that exceed its authorized task scope or affect resources requiring separate execution authority. [0055] A technical problem therefore arises when general delegated permissions are implicitly propagated into unrestricted downstream effectuation authority. [0056] There is a need for bounded delegation coupled with separate protected validation of consequential operations generated under that delegation. 7.8. 8. Time-of-Check and Time-of-Use Vulnerabilities [0057] In distributed execution systems, the context evaluated during authorization may differ from the context present when an operation becomes effective. [0058] Such differences may arise from changes in the destination, recipient, request payload, workload identity, policy epoch, authorization state, executable, tool arguments, route, resource identifier, or execution environment. [0059] A previously valid authorization decision may not remain valid for a materially different operation. [0060] Similarly, a capability or receipt originally associated with one operation may be replayed or substituted in an attempt to authorize another operation. Das Expires 19 April 2027 [Page 57] Internet-Draft Protected AI Execution Finality October 2026 [0061] A need therefore exists for deterministic or otherwise verifiable operation descriptors and effectuation-boundary comparisons that preserve the relationship between the authorized operation and the operation actually presented for execution. 7.9. 9. Limitations of Post-Event Monitoring and Audit [0062] Audit systems and security-monitoring components may record events, detect anomalies, report violations, or initiate containment. [0063] Such capabilities are valuable for visibility, accountability, investigation, and incident response. [0064] However, evidence generated after a consequential effect does not retroactively prevent that effect. [0065] For example, an alert raised after transmission does not reverse disclosure of data already transmitted. [0066] Likewise, quarantining an AI workload after an externally effective operation does not establish that the earlier operation was prevented. [0067] A technical need exists for enforcement systems that make the required validation state a prerequisite to effectuation while separately preserving monitoring, audit, and post-event containment functions. 7.10. 10. Distributed State, Replay and Recovery Problems [0068] AI-agent execution may involve concurrent requests, repeated operations, communication timeouts, service restarts, workload migration, virtual-machine snapshots, distributed replicas, and partial failures. [0069] In such environments, an execution authorization may be presented more than once or under a changed operational context. [0070] A single-use authorization may be consumed by competing requests if its usage state is not protected by an appropriate consistency mechanism. [0071] A restored workload snapshot may contain a previously valid capability that was subsequently consumed or revoked. [0072] A communication timeout may occur after a remote service has already completed an operation. Das Expires 19 April 2027 [Page 58] Internet-Draft Protected AI Execution Finality October 2026 [0073] An agent may consequently attempt a retry without knowing whether the original operation became effective. [0074] These problems require protected authorization-state consumption, anti-replay controls, state-version verification, outcome classification, and recovery conditions distinguishing pending, reserved, confirmed-effective, denied, and indeterminate operations. [0075] Local authorization-state atomicity alone does not guarantee exactly-once completion at an arbitrary remote service. [0076] Accordingly, recovery mechanisms should preserve current protected authority while employing authenticated receiving-side status, durable idempotency, or other appropriate duplicate-effect controls where available. 7.11. 11. Confidential Computing and Cryptographic Key Authority [0077] Confidential virtual machines, trusted execution environments, hardware security modules, memory-encryption systems, and hardware- attestation mechanisms provide security properties relating to computation, memory, measured execution, and cryptographic key protection. [0078] However, successful attestation of a workload does not automatically authorize every consequential operation the workload may generate. [0079] Similarly, authority to decrypt protected user information does not necessarily confer authority to export or disclose that information. [0080] A derived key, wrapped key, session-limited key, or protected credential may enable a bounded cryptographic operation while leaving separate downstream effectuation authorization unresolved. [0081] A need therefore exists for architectures separating protected data-access authority, cryptographic key-use authority, and operation-specific execution authority. [0082] There is additionally a need to prevent restoration of a confidential-VM snapshot from reviving previously consumed or revoked execution capabilities. Das Expires 19 April 2027 [Page 59] Internet-Draft Protected AI Execution Finality October 2026 7.12. 12. Hardware and Accelerator Effectuation Boundaries [0083] Artificial-intelligence infrastructure increasingly employs GPUs, TPUs, NPUs, accelerator interconnects, SmartNICs, data processing units, network fabrics, DMA and RDMA mechanisms, protected storage controllers, and programmable hardware-enforcement components. [0084] These systems may execute transfers and operations at rates for which repeated high-cost policy evaluation is impractical. [0085] However, an accelerator's ability to produce an output or construct a transfer descriptor does not independently establish authority to release that output into another trust domain. [0086] Likewise, availability of a network interface does not itself establish authorization for a particular packet, request, destination, or transfer. [0087] A technical need exists for hardware-associated effectuation controls that permit protected authorization to be evaluated separately from high-speed transfer admission while requiring the hardware boundary to enforce the resulting scoped authority. [0088] Such arrangements may employ protected capability tables, queue-admission controls, DMA authorization, hardware freshness, bounded transfer windows, and authenticated control-plane communication. 7.13. 13. Multi-Boundary and Receiving-Side Enforcement [0089] A single AI-generated workflow may include several independently consequential operations. [0090] These may include model computation, delegated task acceptance, credential application, network transmission, receiving- side processing, database commitment, financial settlement, and physical actuation. [0091] Authorization at one boundary does not necessarily authorize a different operation at another boundary. [0092] In particular, authorization to transmit a request does not automatically establish authority to execute a receiving-side database mutation or financial transaction. Das Expires 19 April 2027 [Page 60] Internet-Draft Protected AI Execution Finality October 2026 [0093] A technical need therefore exists for architectures that identify the distinct Finality Sinks involved in a workflow and require the applicable execution capability to be verified at each separately governed consequential boundary. 7.14. 14. Earlier Technical Disclosures and Related Applications [0094] The present technical field includes earlier Indian provisional and international patent disclosures relating to cryptographic execution authorization, protected enforcement, Algorithmic Logic Fingerprinting, and control of irreversible execution boundaries. [0095] An Indian provisional application dated 3 January 2026, entitled Cryptographic Execution-Time Enforcement System with Purpose- and Jurisdiction-Bound Authorization and Split Execution Control, describes execution-time control using cryptographically derived execution handles, execution-scope objects, runtime-verified Algorithmic Logic Fingerprinting, and enforcement separating computation from execution authority. [0096] An Indian provisional application dated 7 January 2026, entitled Systems and Methods for Cryptographic Enforcement of Execution Authority at Commit-Time, Settlement-Time, and Other Irreversible System Boundaries in Distributed, Hardware-Backed Digital Systems, describes commit-time and settlement-time authority gates, execution-authority receipts, authority-dependent downstream execution, controlled persistence, revocation, and fail-closed enforcement at consequential system boundaries. [0097] An Indian provisional application dated 12 January 2026, entitled Systems and Methods for Execution-Time Authorization Using Multi-Authority, Quantum-Resilient, and Context-Adaptive Cryptographic Enforcement at Irreversible Execution Boundaries, describes execution-time authorization using protected multi- authority conditions, cryptographic execution capabilities, context- sensitive authority requirements, and enforcement at irreversible operational boundaries. [0098] Related international application PCT/IB2026/053385, published as WO 2026/115520 A2, concerns hardware-enforced cryptographic execution-time governance using capability withholding, Algorithmic Logic Fingerprinting, and enforcement at irreversible execution boundaries. [0099] Related international applications in the DAS series include: PCT/IB2026/055615 (DAS Protocols I), published as WO 2026/150382; Das Expires 19 April 2027 [Page 61] Internet-Draft Protected AI Execution Finality October 2026 PCT/IB2026/055760 (DAS Protocols II), published as WO 2026/150383 A2; PCT/IB2026/055870 (DAS Protocols III), published as WO 2026/150384 A2; PCT/IB2026/056058 (DAS Protocols IV), published as WO 2026/154461 A2; and PCT/IB2026/056809 (DAS Protocols V), published as WO 2026/172334 A2. [0100] These disclosures address different aspects of protected execution-finality architecture, including agentic execution, Candidate Act control, authority separation, protected capabilities, output release, device-side enforcement, and hardware-associated effectuation. [0101] The present specification describes further integrated systems, implementation procedures, alternative embodiments, and technical mechanisms relating to protected AI-agent execution, transaction-bound authorization, credential and key-release control, hardware finality, multi-boundary enforcement, and portable computing environments. [0102] References to earlier applications provide technical context. Any formal priority claim, incorporation by reference, or entitlement to an earlier effective filing date is governed by the applicable filing record and legal requirements and is not established merely by the present description. 7.15. 15. Technical Problem to Be Solved [0103] Accordingly, there remains a need for a protected execution architecture capable of permitting autonomous computation while withholding authority over consequential operations until required operation-specific validation succeeds. [0104] More particularly, there is a need for an architecture providing one or more of the following technical properties: (a) separation of computation from protected execution authority; (b) mandatory interception of governed Candidate Acts; (c) Non-Effective State holding; (d) canonical operation-specific descriptors; (e) independent protected authority validation; Das Expires 19 April 2027 [Page 62] Internet-Draft Protected AI Execution Finality October 2026 (f) protected grant and authorization-state management; (g) validation-evidence commitment; (h) scoped, non-bearer execution-capability release; (i) independent Finality Sink verification; (j) credential and cryptographic key-use enforcement; (k) bounded delegation and agent sandbox control; (l) multi-agent and multi-boundary effectuation control; (m) hardware-associated finality enforcement; (n) runtime monitoring and revocation; (o) confidential workload and governance-node attestation; (p) cloud migration and snapshot replay protection; and (q) crash-consistent recovery with duplicate-effect prevention. [0105] the proposed architecture addresses these technical problems through the architecture and embodiments described below. 8. Proposed Technical Architecture 8.1. 16. General Protected Execution-Finality Architecture [0106] In one aspect, the architecture provides a protected execution-finality system comprising an AI-Agent Execution Environment, an operation-interception component, a Candidate Act staging mechanism, a Protected Enforcement Domain, a protected authorization-state mechanism, an execution-capability component, and a Finality Sink. [0107] The AI-Agent Execution Environment generates, selects, prepares, stages, or requests a consequential operation. [0108] The operation-interception component classifies the operation as a Candidate Act and prevents it from becoming effective through the governed execution path before completion of the required protected finality conditions. Das Expires 19 April 2027 [Page 63] Internet-Draft Protected AI Execution Finality October 2026 [0109] The Candidate Act may be represented in a Non-Effective State by a pending request, blocked operation, queued command, inactive transaction, protected buffer, or equivalent technical arrangement. [0110] A Candidate Act Descriptor identifies the actual operation and the finality-relevant context required for authorization. [0111] The Protected Enforcement Domain obtains or resolves the applicable Authority Object and validates the Candidate Act against the required protected authorization predicates. [0112] The protected system performs any mandatory authorization- state handling, validation-evidence commitment, and capability- release conditions. [0113] Upon successful completion of the applicable protected prerequisites, a scoped execution capability is released, registered, activated, or otherwise made available for the authorized operation. [0114] The designated Finality Sink independently verifies the applicable capability and protected conditions against the actual operation before permitting it to become effective. [0115] If a mandatory condition fails, the governed operation remains non-effective or is denied. 8.2. 17. Candidate Act and Non-Effective State [0116] A Candidate Act may comprise any proposed or prepared operation that would create a governed practical consequence if permitted to proceed. [0117] Examples include network transmission, API invocation, credential application, storage commitment, software deployment, payment execution, model-state export, accelerator transfer, protected cryptographic signing, and physical actuation. [0118] The Non-Effective State separates the computational creation of the operation from the technical event at which the operation acquires its governed consequence. [0119] The operation may be fully computed or ready for execution while remaining unable to cross the designated effectuation boundary. [0120] The Non-Effective State may be implemented through protected queue control, inactive hardware descriptors, controlled service interfaces, bounded transaction staging, or equivalent enforcement mechanisms. Das Expires 19 April 2027 [Page 64] Internet-Draft Protected AI Execution Finality October 2026 8.3. 18. Canonical Candidate Act Descriptor [0121] In another aspect, the system constructs a canonical Candidate Act Descriptor identifying the operation and its required authorization context. [0122] The descriptor may comprise one or more of: (a) operation identifier; (b) operation class; (c) requesting workload; (d) target resource; (e) destination or recipient; (f) operation parameters; (g) payload digest; (h) execution purpose; (i) delegated authority; (j) required runtime measurement; (k) policy epoch; (l) protected authorization-state version; (m) nonce; (n) validity interval; and (o) Finality Sink identity. [0123] The descriptor may be authenticated, hashed, sealed, or otherwise represented so that materially different effectuation- relevant operations can be distinguished. [0124] A Finality Sink may reconstruct the actual operation descriptor and compare it with the authorized descriptor or its permitted bounded scope. [0125] The comparison prevents an authorization for one operation from being silently substituted for a materially different operation. Das Expires 19 April 2027 [Page 65] Internet-Draft Protected AI Execution Finality October 2026 8.4. 19. Protected Enforcement Domain [0126] The Protected Enforcement Domain comprises a protected execution, authorization, governance, or enforcement boundary. [0127] It is isolated from unilateral authority controlled by the requesting AI agent. [0128] The PED may perform one or more of: (a) Authority Object authentication; (b) execution-scope verification; (c) workload identity validation; (d) runtime policy verification; (e) protected-state updates; (f) revocation checks; (g) nonce and freshness validation; (h) protected validation-evidence commitment; (i) bounded execution-capability generation; and (j) fail-closed withholding. [0129] In selected implementations, the PED may comprise a Cryptographically Isolated Enforcement Domain providing stronger protected key custody, integrity, isolation, and rollback-resistance properties. [0130] The PED and Finality Sink may be physically separate or integrated into one protected component, provided that the required authorization and effectuation-verification functions remain enforced. 8.5. 20. Transaction-Bound Authorization and Protected State [0131] In another aspect, the architecture provides protected authorization-state handling for Candidate Acts. [0132] An authorization grant may be associated with a permitted operation, validity interval, remaining usage allowance, nonce, policy epoch, and revocation state. Das Expires 19 April 2027 [Page 66] Internet-Draft Protected AI Execution Finality October 2026 [0133] The protected system prevents unauthorized concurrent consumption of a single-use grant. [0134] A protected atomic-state transition may verify and update grant state, nonce state, capability usage, and authorization-state references consistently. [0135] Where required, the authorization-state transition and validation-evidence commitment form a protected finality transaction. [0136] An incomplete required transaction cannot produce a valid usable execution capability. [0137] The atomicity of protected authorization state is distinguishable from completion of an arbitrary external operation at a remote service. 8.6. 21. Protected Validation Evidence [0138] In another aspect, the system generates or commits protected validation evidence associated with the Candidate Act. [0139] The evidence may comprise a LAVR, AVR, authenticated receipt, sealed authorization commitment, or equivalent protected representation. [0140] The evidence may identify the Candidate Act Descriptor, applicable authority, protected-state transition, policy epoch, nonce, and designated Finality Sink. [0141] Where required by the embodiment, the evidence is committed before, or atomically with, the availability of the corresponding scoped execution capability. [0142] Such protected validation evidence is distinguishable from ordinary post-event logging. [0143] The protected evidence establishes the specified authorization conditions; additional completion evidence may be used to establish whether the consequential operation actually became effective. 8.7. 22. Scoped, Non-Bearer Execution Capability [0144] Following successful protected authorization, the system makes available a scoped execution capability. [0145] The capability is bound to the concrete Candidate Act and applicable authorization context. Das Expires 19 April 2027 [Page 67] Internet-Draft Protected AI Execution Finality October 2026 [0146] Depending upon the embodiment, it may bind operation class, workload identity, destination, resource scope, protected state, freshness, policy epoch, receipt commitment, validity interval, usage count, and Finality Sink identity. [0147] The capability may comprise a cryptographically signed artifact, MAC-authenticated permit, sealed execution handle, protected table entry, hardware enablement condition, or equivalent mechanism. [0148] The capability is not treated as unrestricted bearer authority. [0149] Its use remains dependent upon verification of the required operation, state, scope, and Finality Sink bindings. [0150] Possession of a copy of the capability does not independently authorize arbitrary replay, substitution, or execution at another boundary. 8.8. 23. Mandatory Finality Sink Verification [0151] In another aspect, the Finality Sink verifies the required execution capability at or immediately before the governed consequential boundary. [0152] The verification may include: (a) capability authenticity; (b) actual operation correspondence; (c) permitted execution scope; (d) recipient or destination; (e) protected-state validity; (f) required evidence commitment; (g) freshness and nonce; (h) revocation; (i) usage state; and (j) designated sink identity. Das Expires 19 April 2027 [Page 68] Internet-Draft Protected AI Execution Finality October 2026 [0153] The Finality Sink permits the operation only when all mandatory predicates succeed. [0154] Where the Finality Sink governs network transmission, the enforcement point may be a gateway, egress proxy, NIC, SmartNIC, or DPU. [0155] Where the Finality Sink governs persistent modification, it may be a protected storage or database-commit interface. [0156] Where the operation involves credentials, the Finality Sink may be a protected credential broker or controlled service interface. [0157] Where the operation involves hardware actuation, the Finality Sink may control the corresponding physical effectuation interface. 8.9. 24. Agent Sandbox and Protected Egress [0158] In another aspect, an AI-agent runtime operates within a sandboxed or otherwise restricted execution environment. [0159] A protected authority outside the unilateral control of the agent governs selected consequential tool, network, file, and process operations. [0160] The system may evaluate executable identity, destination, resource scope, network protocol, request method, path, payload attributes, or other specified conditions. [0161] A requested operation may be classified as an agent sandbox- egress Candidate Act. [0162] The PED validates the applicable sandbox-egress Authority Object and protected policy state. [0163] Only an authorized operation receives the required scoped execution capability. [0164] The protected egress or tool Finality Sink verifies the capability before permitting the governed effect. [0165] Runtime policy changes may be subject to protected approval, policy-version advancement, and revocation handling. 8.10. 25. Credential-Release and Protected Key-Use Finality [0166] In another aspect, the architecture provides protected credential-release and credential-use control. Das Expires 19 April 2027 [Page 69] Internet-Draft Protected AI Execution Finality October 2026 [0167] An AI agent may refer to a connected service or protected credential without receiving unrestricted access to the underlying secret. [0168] A protected broker or key-use component may maintain the credential within a protected authority domain. [0169] The proposed credential-mediated operation is represented by a Candidate Act Descriptor identifying its actual destination, operation class, resource, parameters, and applicable authority. [0170] The PED validates the operation. [0171] The corresponding protected credential-use or downstream Finality Sink verifies the required capability before permitting credential application or the governed external effect. [0172] A key identifier, credential reference, or successful authenticated session does not independently authorize unrelated operations. 8.11. 26. Confidential-VM and User-Controlled Key Authority [0173] In another aspect, an AI workload executes within an attested confidential virtual machine. [0174] Protected user data is encrypted using user-controlled or user-authorized key material. [0175] A protected root-key authority may provide bounded derived- key, wrapped-key, session-limited-key, or controlled cryptographic access upon satisfaction of required attestation and data-access conditions. [0176] Data-access authorization remains distinct from execution- finality authorization. [0177] A workload permitted to decrypt or use protected data does not automatically obtain authority to transmit or otherwise effectuate that data. [0178] A proposed consequential operation is separately authorized and subjected to the required Finality Sink verification. [0179] Following backup restoration or workload recovery, current attestation, key-access scope, revocation, and capability-consumption conditions remain applicable. Das Expires 19 April 2027 [Page 70] Internet-Draft Protected AI Execution Finality October 2026 8.12. 27. Multi-Agent Delegation [0180] In another aspect, the system supports bounded delegation among AI agents. [0181] A primary agent may propose delegation of a specified subtask to a subordinate agent. [0182] The delegation is evaluated against an applicable Delegation Authority Object. [0183] A Delegation Capability may restrict tool classes, data scope, time window, recursion depth, resource usage, execution budget, or other conditions. [0184] Acceptance of the delegation does not independently authorize later consequential operations generated by the subordinate agent. [0185] Each separately governed downstream operation remains subject to its own Candidate Act validation and applicable Finality Sink verification. 8.13. 28. Model-Path and Downstream Effectuation Separation [0186] In another aspect, the architecture provides separate controls for model-computation admission and externally effective operations. [0187] A model-access component may govern permitted models, workloads, execution contexts, or inference requests. [0188] A downstream Candidate Act remains subject to separate protected authorization. [0189] A valid model-computation admission record may contribute authenticated context to downstream authorization without replacing the downstream execution capability. [0190] Where an inference request produces streaming or partial tool operations, the system identifies the consequential unit that requires protected finality. [0191] Interruption, denial, or quarantine of further model computation does not independently authorize release of an already buffered Candidate Act. Das Expires 19 April 2027 [Page 71] Internet-Draft Protected AI Execution Finality October 2026 8.14. 29. Hardware Finality Latch and Accelerator Transfers [0192] In another aspect, a hardware-associated Finality Sink controls a consequential transfer or operation. [0193] The hardware controller may comprise a NIC, SmartNIC, DPU, GPU, accelerator, FPGA, ASIC, interconnect controller, or protected storage interface. [0194] A Hardware Finality Latch prevents admission of the governed operation until the required scoped capability has been verified. [0195] The controlled operation may comprise network transmission, DMA, RDMA, tensor export, accelerator-to-host transfer, accelerator- to-accelerator transfer, storage commitment, or another protected interface. [0196] For streaming transfers, a capability may authorize bounded transfer windows, units, size limits, routes, memory regions, or usage allowances. [0197] The hardware controller verifies applicable freshness and scope before admitting each required unit or window. [0198] High-cost authorization may occur through the PED while lower- cost protected capability verification is performed at the hardware fast path. [0199] A performance objective does not eliminate mandatory enforcement at the governed hardware boundary. 8.15. 30. Hardware Watchdog and Revocation Interlock [0200] In another aspect, an isolated or out-of-band monitoring domain generates protected monitoring-state information. [0201] The information may identify workload identity, monitoring- state version, validity, and enforcement status. [0202] The PED may require an acceptable monitoring-state record before authorizing a consequential Candidate Act. [0203] The resulting capability may be bound to the required monitoring-state version. [0204] A hardware or protected Finality Sink verifies that the applicable monitoring state remains acceptable before effectuation. Das Expires 19 April 2027 [Page 72] Internet-Draft Protected AI Execution Finality October 2026 [0205] Where a security event invalidates required monitoring state, protected revocation or version advancement causes affected capabilities to fail subsequent mandatory verification. [0206] Quarantine may prevent additional governed operations while preserving the actual completion status of earlier operations. [0207] The system distinguishes monitoring and post-event containment from actual pre-effectuation prevention. 8.16. 31. Confidential Governance VM and Hardware-Attested Effectuation [0208] In another aspect, protected execution authority is maintained within a confidential governance virtual machine or separately protected governance component. [0209] A hardware-rooted attestation mechanism authenticates the applicable governance identity and measured execution configuration. [0210] Protected capability-issuance keys remain isolated from ordinary AI compute processes. [0211] The governance component evaluates the Candidate Act against operation-specific authority. [0212] A scoped capability may be conveyed through an authenticated fabric-management communication path to a SmartNIC, DPU, or other hardware-associated Finality Sink. [0213] The Finality Sink verifies the required issuing authority, registered attestation state, actual operation, policy state, and hardware freshness. [0214] Invalid mandatory governance attestation or capability state prevents the governed external transmission. 8.17. 32. Portable Cloud Workloads and Policy-Version Fencing [0215] In another aspect, an AI workload may execute across containers, virtual machines, confidential VMs, Kubernetes workloads, on-premises infrastructure, hybrid clouds, and accelerator-backed environments. [0216] An authenticated workload identity and machine-verifiable execution-context measurement are associated with the applicable protected authority. Das Expires 19 April 2027 [Page 73] Internet-Draft Protected AI Execution Finality October 2026 [0217] The PED maintains authorization-state versions and current execution-policy predicates. [0218] A capability is bound to the required workload identity, Candidate Act, authorization-state version, and Finality Sink. [0219] Following migration, container replacement, failover, or snapshot restoration, a pending Candidate Act is revalidated where a required execution-context condition has changed. [0220] An incompatible earlier capability is not accepted merely because the workload's computational state was successfully restored. [0221] Protected capability-consumption and revocation state remains authoritative independently of rollback-accessible workload snapshots. 8.18. 33. Atomic State, Replay Prevention and Recovery [0222] In another aspect, the system maintains protected grant, capability, nonce, policy, revocation, and operation-outcome state. [0223] Required protected authorization-state operations are performed with the consistency necessary to prevent unauthorized concurrent consumption. [0224] A capability bound to a specific Candidate Act, policy epoch, authorization-state version, nonce, and Finality Sink is rejected when mandatory state becomes invalid. [0225] The system distinguishes capability preparation, protected commitment, capability release, Finality Sink admission, and confirmed effectuation. [0226] Following timeout or crash, a retry is correlated with the original operation identifier. [0227] Where previous completion is indeterminate, the recovery mechanism verifies the required duplicate-effect prevention conditions before permitting another consequential attempt. [0228] The architecture does not presume that local authorization- state atomicity establishes exactly-once completion at an unrelated external system. Das Expires 19 April 2027 [Page 74] Internet-Draft Protected AI Execution Finality October 2026 8.19. 34. Multiple Finality Sinks and Receiving-Side Enforcement [0229] In another aspect, the system classifies operations according to their effectuation boundaries. [0230] Distinct operations within a workflow may require independently enforceable network, tool, credential, storage, financial, hardware, or physical Finality Sinks. [0231] A capability authorizing one boundary does not automatically authorize another. [0232] A receiving-side Finality Sink may reconstruct the actual operation and verify the corresponding capability and protected validation-state commitment. [0233] Authorization of an upstream network request does not independently establish authorization of a receiving-side database commit, payment execution, or physical actuation. [0234] Each independently governed consequence remains subject to its applicable protected execution-finality conditions. 8.20. 35. Fail-Closed Handling [0235] In another aspect, the system refuses effectuation when a mandatory protected condition is unavailable, invalid, expired, revoked, replayed, consumed, inconsistent, or unverifiable. [0236] Failure conditions may include invalid Authority Objects, stale policy epochs, missing validation receipts, invalid capability authentication, incompatible runtime measurements, incorrect Finality Sink identities, exhausted usage limits, unavailable monitoring state, and failed protected-state commitments. [0237] A timeout, process crash, communication failure, or hardware restart does not create unrestricted execution authority. [0238] Separately authorized emergency, recovery, or Safe-Baseline operations may be supported where expressly permitted by their governing authority. [0239] Such exceptions do not automatically bypass the protected finality conditions applicable to the original Candidate Act. Das Expires 19 April 2027 [Page 75] Internet-Draft Protected AI Execution Finality October 2026 9. Architecture Summary 9.1. 36. General Summary [0240] the proposed architecture provides systems, methods, apparatus, and computer-readable instructions for protected execution-finality control of consequential operations generated by artificial-intelligence agents and associated computational environments. [0241] the architecture separates the ability to compute, prepare, propose, stage, or route an operation from the protected authority required to make that operation effective. [0242] In a principal embodiment, an AI-Agent Execution Environment generates a Candidate Act. [0243] A mandatory interception component prevents the Candidate Act from crossing its governed effectuation boundary while required execution-finality conditions remain unsatisfied. [0244] A Candidate Act Descriptor provides a verifiable representation of the operation and its finality-relevant context. [0245] A Protected Enforcement Domain independently validates the applicable Authority Object, operation scope, protected state, freshness, revocation, and required execution context. [0246] The protected system performs any mandatory authorization- state transition and validation-evidence commitment. [0247] A scoped execution capability is generated, released, activated, or made available only when the applicable protected conditions succeed. [0248] The designated Finality Sink independently verifies the capability and actual operation before permitting the Candidate Act to become externally effective. [0249] Failure of a mandatory condition results in withholding or denial of the corresponding effect. 9.2. 37. Protected Agent Execution [0250] In one embodiment, the architecture provides protected execution for AI agents operating within sandboxed, containerized, virtualized, or cloud-hosted environments. Das Expires 19 April 2027 [Page 76] Internet-Draft Protected AI Execution Finality October 2026 [0251] The system may control tool invocation, network egress, file operations, executable identity, service access, credential use, or another effect-capable interface. [0252] Operation-specific authority is maintained outside the agent's unilateral control. [0253] Runtime policy updates, developer approvals, grant revocation, and usage restrictions may be enforced through protected policy state. 9.3. 38. Transaction-Bound Credential Control [0254] In another embodiment, the architecture provides transaction- bound authorization for credential-mediated operations. [0255] A protected broker maintains or controls access to the required credential. [0256] The concrete operation is represented by a Candidate Act Descriptor and validated against applicable authority. [0257] A scoped execution capability is required for protected credential use or downstream effectuation, according to the governed boundary. [0258] The credential is not treated as unrestricted permission for unrelated operations. 9.4. 39. Protected State and Atomic Finality [0259] In another embodiment, the system maintains protected authorization-state records identifying grants, usage allowances, policy epochs, nonces, revocation state, and capability consumption. [0260] Required protected-state transitions are performed with the consistency necessary to prevent unauthorized duplicate consumption. [0261] Where an atomic finality commitment is required, protected state and validation-evidence dependencies are satisfied before capability usability. [0262] Crash recovery preserves operation-specific authorization state and distinguishes pending, reserved, confirmed-effective, denied, and indeterminate operations. Das Expires 19 April 2027 [Page 77] Internet-Draft Protected AI Execution Finality October 2026 9.5. 40. Multi-Agent Delegation [0263] In another embodiment, a primary agent delegates a bounded task to a subordinate agent. [0264] Delegation acceptance is governed by a Delegation Authority Object and corresponding protected capability. [0265] Consequential operations generated under the delegation remain subject to their own protected execution-finality conditions. [0266] Delegated computation does not create unrestricted downstream effectuation authority. 9.6. 41. Model-Path and Effectuation-Path Separation [0267] In another embodiment, the system separately governs model- computation admission and downstream consequential operations. [0268] Successful model admission does not independently authorize operations generated by the model. [0269] A model-generated tool request, network transmission, storage mutation, payment, or other governed operation is subjected to separate Candidate Act authorization and Finality Sink verification. [0270] Interruption of future model access does not automatically release an already buffered Candidate Act. 9.7. 42. Hardware-Assisted Finality [0271] In another embodiment, the Finality Sink comprises a hardware- associated controller. [0272] The controller may include a NIC, SmartNIC, DPU, accelerator controller, FPGA, ASIC, protected memory interface, or other suitable hardware mechanism. [0273] A Hardware Finality Latch prevents the governed operation from becoming effective until the required capability verifies. [0274] The arrangement may control network transmission, DMA, RDMA, accelerator transfer, storage commitment, or another hardware effectuation boundary. [0275] Hardware freshness and protected capability-consumption state may prevent unauthorized replay. Das Expires 19 April 2027 [Page 78] Internet-Draft Protected AI Execution Finality October 2026 9.8. 43. Confidential Governance and Key Authority [0276] In another embodiment, protected authorization operates within an attested confidential governance environment. [0277] Governance key material remains protected against unrestricted access by ordinary AI compute processes. [0278] An authenticated capability is released following operation- specific validation and may be conveyed to a hardware-associated Finality Sink. [0279] The Finality Sink verifies the required issuer attestation, operation context, protected state, and execution scope before effectuation. [0280] In another embodiment, user-controlled root-key material enables bounded protected data access without independently authorizing external disclosure or other consequential operations. 9.9. 44. Monitoring and Revocation [0281] In another embodiment, an isolated monitoring domain supplies authenticated workload-monitoring state. [0282] The PED evaluates the required monitoring condition when authorizing a Candidate Act. [0283] A scoped capability may be bound to the corresponding monitoring-state version. [0284] Revocation or invalidation of mandatory monitoring state causes affected subsequent operations to fail the required Finality Sink verification. [0285] Quarantine and recovery procedures preserve the actual effectuation status of earlier operations. 9.10. 45. Cross-Cloud Portability [0286] In another embodiment, the AI workload executes across multiple cloud, container, virtual-machine, and accelerator environments. [0287] The system authenticates the workload identity and required execution-context measurement. Das Expires 19 April 2027 [Page 79] Internet-Draft Protected AI Execution Finality October 2026 [0288] Protected authorization-state versions are maintained across affected workload scopes. [0289] Migration, failover, or snapshot recovery does not automatically restore stale, consumed, or revoked execution authority. [0290] Pending consequential operations are revalidated when the required execution context changes. 9.11. 46. Independent Downstream Finality [0291] In another embodiment, a workflow comprises multiple consequential operations associated with different Finality Sinks. [0292] Each governed operation receives authorization appropriate to its own effectuation boundary. [0293] A receiving-side Finality Sink reconstructs or verifies the actual operation before permitting a separately governed downstream consequence. [0294] An authorization to communicate, delegate, infer, or invoke an upstream service does not independently grant authority over a receiving-side database, payment, storage, or hardware operation. 9.12. 47. Technical Advantages [0295] Depending upon the particular embodiment and implemented protection mechanisms, the architecture may provide one or more of the following technical effects: (a) separation of computation from protected execution authority; (b) prevention of unauthorized consequential operations at controlled effectuation boundaries; (c) reduced opportunity for unauthorized operation substitution; (d) protected capability scope and replay control; (e) protected grant consumption and authorization-state consistency; (f) bounded credential and cryptographic key use; (g) enforced limits on delegated AI-agent operations; (h) separation of model computation from downstream effectuation; Das Expires 19 April 2027 [Page 80] Internet-Draft Protected AI Execution Finality October 2026 (i) hardware-enforced network and accelerator admission; (j) monitoring-state-dependent revocation; (k) attestation-bound confidential governance; (l) independent receiving-side authorization; (m) protection against stale authority after migration or snapshot restoration; (n) improved recovery handling for indeterminate operation outcomes; and (o) authenticated evidence of protected execution-finality decisions. [0296] The foregoing technical effects depend upon the enforcement interfaces, protected trust boundaries, mandatory predicates, and state mechanisms implemented in a particular embodiment. [0297] No single embodiment is required to include every component or alternative described herein unless expressly required under the specified enforcement profile. 9.13. 48. General Inventive Principle [0298] the architecture establishes a protected causal dependency between generation of a consequential operation and the authority required to make that operation effective. [0299] The requesting computational environment may generate or prepare an operation, but cannot independently confer the required protected execution authority. [0300] The operation remains non-effective until its applicable protected authorization conditions succeed. [0301] A scoped execution capability provides the required operation- specific execution enablement. [0302] The Finality Sink verifies that enablement against the actual operation before permitting its governed consequential effect. [0303] the architecture thereby provides an architecture in which computation and execution authority are technically distinguishable and in which required protected authority is enforced at the actual consequence-producing boundary. Das Expires 19 April 2027 [Page 81] Internet-Draft Protected AI Execution Finality October 2026 Computation is not authority to act. 10. Terminology and Definitions 10.1. 1. AI-Agent Execution Environment “AI-Agent Execution Environment” means an artificial-intelligence model, autonomous or semi-autonomous agent, tool-using model, planner, orchestrator, application, software process, container, virtual machine, cloud workload, or associated computing environment that generates, requests, prepares, stages, or processes a Candidate Act. The environment may perform computation and prepare operations but does not independently obtain authority to make a governed Candidate Act externally effective without satisfying the applicable protected execution-finality conditions. 10.2. 2. Proposed Operation and Candidate Act “Candidate Act” means any proposed, requested, generated, computed, derived, staged, buffered, prepared, simulated, selected, planned, delegated, sequenced, scheduled, conditionally generated, or otherwise pending operation that, if permitted to proceed, would produce an externally effective, operationally effective, network- effective, data-effective, model-effective, financially effective, legally effective, physically effective, or machine-effective consequence. A Candidate Act may include a tool invocation, API request, network transmission, storage commit, payment instruction, deployment, model update, or physical actuation, including applicable governed omission or non-renewal events. 10.3. 3. Externally Effective Operation “External Effectuation” means the transition of a Candidate Act from a Non-Effective State into a state of practical consequence. Such consequence may be physical, logical, network, financial, legal, operational, computational, cryptographic, data-related, radio, optical, memory-related, content-related, actuator-related, or cyber- physical. External Effectuation does not require an operation to leave the physical device or system. An internal memory write, model update, signing event, register activation, tool execution, or other consequential state transition may constitute External Effectuation. Das Expires 19 April 2027 [Page 82] Internet-Draft Protected AI Execution Finality October 2026 10.4. 4. Non-Effective State (NES) “Non-Effective State” means a technical state in which a Candidate Act has been generated, proposed, computed, buffered, prepared, staged, sealed, encrypted, queued, or otherwise made available within a system but has not become externally effective or otherwise acquired its governed practical consequence. “Non-Final State” expresses the corresponding condition before completion of the applicable finality decision. A Pending State is a form of Non-Effective State in which the Candidate Act awaits required validation, protected-state handling, evidence commitment, capability release, or Finality Sink verification. 10.5. 5. Mandatory Interception and Mediation “Mandatory Interception and Mediation” refers to the enforcement arrangement by which a governed Candidate Act is subjected to the applicable protected execution-finality controls before crossing its governed effectuation boundary. The operation may be held, denied, deferred, or permitted according to the required authorization conditions. A Non-Authoritative Mediator may prepare or route the operation but cannot independently supply the protected execution authority required for effectuation. 10.6. 6. Execution-Finality Boundary “Execution-Finality Boundary” refers to a Finality Boundary at or before which a Candidate Act would first become externally effective, operationally binding, practically usable, transmitted, rendered, committed, stored, settled, decrypted, signed, actuated, emitted, admitted, or otherwise consequential unless blocked. The boundary may be implemented at a network, storage, settlement, rendering, cryptographic-signing, computation-admission, output- release, or physical-actuation interface according to the applicable embodiment. 10.7. 7. Finality Sink “Finality Sink” means the technical effectuation boundary at which a Candidate Act would first become externally effective, practically usable, transmitted, committed, rendered, actuated, settled, stored, decrypted, signed, emitted, forwarded, admitted, energized, or otherwise given practical effect. Das Expires 19 April 2027 [Page 83] Internet-Draft Protected AI Execution Finality October 2026 The Finality Sink is distinct from the Finality Gate. Where the embodiment requires a scoped non-bearer capability, the Finality Sink verifies that capability and permits the finalizing operation only upon successful verification. Finality Gate: A protected technical enforcement mechanism positioned at, immediately before, or in non-bypassable control of a Finality Boundary, configured to determine whether a Candidate Act may cross that boundary by performing or enforcing protected validation and controlling the release, use, withholding, or denial of the required scoped execution capability. 10.8. 8. Protected Enforcement Domain (PED) and Cryptographically Isolated Enforcement Domain (CIED) “Protected Enforcement Domain” (PED) means a protected execution, authority, governance, or enforcement boundary configured to perform protected finality functions before a Candidate Act becomes externally effective. Such functions may include authority validation, protected-state handling, validation-evidence commitment, capability release, and fail-closed withholding. “Cryptographically Isolated Enforcement Domain” (CIED) means a stronger species of PED providing cryptographic isolation, protected key control, validation-logic integrity, protected mutable state, and associated resistance to unauthorized tampering, rollback, replay, or bypass. Every CIED may be a PED; not every PED must satisfy the stronger CIED requirements. 10.9. 9. Protected Isolation from Agent Control “Protected Isolation from Agent Control” refers to the separation of required validation logic, protected authorization state, and execution-capability release authority from unilateral control by the requesting AI agent or other non-authoritative component. The agent may propose operations, supply evidence, or request authorization but cannot independently override the protected validation and capability-release conditions. The isolation guarantees depend upon the applicable PED, CIED, hardware, firmware, software, or other protected enforcement implementation. Das Expires 19 April 2027 [Page 84] Internet-Draft Protected AI Execution Finality October 2026 10.10. 10. Non-Bypassable Governed Execution Path “Non-Bypassable Governed Execution Path” refers to an execution arrangement in which the applicable Finality Gate and Finality Sink control the governed effectuation interface so that a Candidate Act cannot obtain its specified consequential effect through that interface without satisfying the required protected finality conditions. The path may include host, network, storage, application, hardware, or downstream enforcement components. The non-bypassable property applies to the effectuation paths covered by the particular implementation and its specified enforcement requirements. 10.11. 11. Finality Sink Verification “Finality Sink Verification” means verification performed by a Finality Sink before effectuation to determine whether the required scoped non-bearer capability and its applicable Candidate Act, descriptor, validation-evidence, protected-state, freshness, policy, and sink-specific bindings are valid. Where the relevant embodiment requires such verification, the Finality Sink refuses effectuation if a mandatory capability or binding condition is absent, invalid, expired, revoked, replayed, consumed, or mismatched. Finality Sink Verification is a distinct functional requirement but does not necessarily require a physically separate component from the Protected Enforcement Domain or Finality Gate. 10.12. 12. Fail-Closed Enforcement “Fail-Closed Enforcement” means an execution-control property under which failure, absence, unavailability, inconsistency, expiry, revocation, or unsuccessful verification of a required protected authorization condition does not permit the governed Candidate Act to become externally effective. A timeout, crash, restart, communication failure, unavailable protected state, or enforcement-component failure does not create execution authority. An embodiment may permit separately authorized emergency, recovery, or Safe-Baseline operations without granting unrestricted permission to the original Candidate Act. Das Expires 19 April 2027 [Page 85] Internet-Draft Protected AI Execution Finality October 2026 10.13. 13. Authority Object “Authority Object” means a signed, MAC-protected, attested, sealed, quorum-approved, regulator-issued, operator-issued, enterprise- issued, TEE-issued, HSM-issued, machine-verifiable, or protected- domain-controlled object defining permitted scope, conditions, validity, revocation state, policy epoch, jurisdiction, purpose, target boundary, receipt requirement, or equivalent authorization context for one or more Candidate Acts. The term includes applicable specialized authority objects, including EASO, delegated authority objects, Self-Mutation Authority Objects, Sandbox Egress Authority Objects, Supply-Chain Authority Objects, and other forms expressly described in the corresponding embodiments. Possession of an Authority Object does not independently establish satisfaction of the required protected execution-finality conditions. 10.14. 14. Candidate Act Descriptor (CAD) “Candidate Act Descriptor” (CAD) means a canonical, deterministic, machine-readable, protected, cryptographic, or otherwise verifiable representation of a Candidate Act and its finality-relevant context before that Candidate Act becomes externally effective. A CAD may represent the act class, effect class, target boundary, destination, authority conditions, runtime context, policy epoch, freshness, nonce, receipt requirement, Finality Sink identity, permitted scope, or other information required for protected authorization. A Hash-Linked Candidate Act Descriptor (HCAD) is a specialized descriptor incorporating applicable cryptographic linkage or commitments. The descriptor is distinguishable from the Candidate Act itself. 10.15. 15. Canonical Descriptor and Equality Verification “Canonical Descriptor and Equality Verification” refers to deterministic representation and machine-verifiable comparison of a Candidate Act against its applicable authorized descriptor, commitment, or permitted execution scope. Canonicalization may include field ordering, type normalization, identifier normalization, destination normalization, encoding normalization, payload hashing, and binding to authority, freshness, policy, and Finality Sink context. Das Expires 19 April 2027 [Page 86] Internet-Draft Protected AI Execution Finality October 2026 Equivalent acts may produce corresponding canonical representations under the applicable rules, while materially different acts remain distinguishable. Verification may require exact descriptor correspondence or satisfaction of defined bounded-scope predicates. The requesting agent cannot independently authorize operation substitution. 10.16. 16. Authority Predicate and Protected Authorization Predicate “Authority Predicate” means a machine-evaluable condition, credential, claim, token, certificate, descriptor, proof, attestation, state value, policy value, cryptographic commitment, or equivalent condition required for authorization of a Candidate Act. Such predicates may concern identity, purpose, jurisdiction, validity, revocation, nonce, quota, policy epoch, ALF, AIF, RBD, attestation, human approval, authority quorum, Finality Sink identity, or protected-state consistency. “Protected Authorization Predicate” refers to an Authority Predicate evaluated or enforced through the applicable protected authorization mechanism. Only the predicates required by the corresponding embodiment are mandatory. 10.17. 17. Authorized Purpose and Execution Scope “Authorized Purpose” means the permitted operational purpose or objective applicable to a Candidate Act. “Execution Scope” means the bounded operations, resources, destinations, purposes, time intervals, usage conditions, and execution contexts within which the Candidate Act may receive execution authority. An Authorized Intent Envelope or Execution Authorization Scope Object (EASO) may define these conditions. Under the disclosed AIF matching rule, a Candidate Intent Descriptor may be authorized when equal to, narrower than, or contained within the Authorized Intent Envelope. An agent cannot independently widen the applicable authorized scope. Das Expires 19 April 2027 [Page 87] Internet-Draft Protected AI Execution Finality October 2026 10.18. 18. Protected Validation Evidence “Protected Validation Evidence” means a protected validation record, receipt, commitment, signature, sealed record, hash-chain entry, Merkle commitment, LAVR, denial receipt, failure receipt, or equivalent machine-verifiable evidence recording or establishing that required protected validation occurred, was attempted, or produced a specified result. Where the applicable embodiment requires evidence commitment as a prerequisite to capability release, that commitment is established before, or atomically with, capability availability. Protected Validation Evidence is distinct from the Authority Object, Candidate Act Descriptor, protected state, scoped execution capability, and Finality Sink. 10.19. 19. Ledger-Anchored Validation Receipt (LAVR) and Egress LAVR “Ledger-Anchored Validation Receipt” (LAVR) means a cryptographically signed or otherwise protected, tamper-evident validation artifact generated by, within, or under control of a Protected Enforcement Domain at or immediately before a Finality Boundary. It records the applicable Candidate Act or governed event, authorization context, validation outcome, and associated protected evidence. A LAVR may use sealed storage, append-only records, hash chains, Merkle commitments, or ledger anchoring, as supported by the embodiment. “Egress LAVR” means a LAVR associated with a governed egress operation, including the Sandbox Egress Finality Gate embodiment. A required Egress LAVR does not itself replace Sandbox Egress Capability verification. 10.20. 20. Zero-Knowledge Ledger-Anchored Validation Receipt (ZK-LAVR) “Zero-Knowledge Ledger-Anchored Validation Receipt” (ZK-LAVR) means a protected validation receipt configured to establish, through a zero- knowledge proof or supported privacy-preserving verification mechanism, that required execution-finality predicates were satisfied without disclosing specified underlying protected information. Such information may include AIF, ALF, RBD, biometric state, private context, model configuration, enterprise policy, or confidential workflow information. Das Expires 19 April 2027 [Page 88] Internet-Draft Protected AI Execution Finality October 2026 Supported implementations may include zero-knowledge proof systems or hybrid attestation-based constructions. The formal zero-knowledge guarantee depends upon the actual proof mechanism. A ZK-LAVR is validation evidence, not an unrestricted execution capability. 10.21. 21. Protected Evidence Commitment and Ordering “Protected Evidence Commitment and Ordering” refers to the protected execution-finality relationship under which required validation evidence and corresponding protected-state operations are committed before, or atomically with, availability of the applicable scoped non-bearer capability. Such commitment may comprise a LAVR, sealed record, cryptographic commitment, protected-state reference, or equivalent protected validation evidence. Capability availability remains dependent upon successful completion of the required validation and commitment operations. Evidence commitment does not require immediate public or external ledger publication. 10.22. 22. Scoped Execution Capability “Scoped Execution Capability” means a protected-domain-issued, protected-domain-controlled, or protected-domain-dependent technical execution-enabling condition required for a governed Candidate Act to become effective within its Permitted Effectuation Scope. The capability may comprise a cryptographic artifact, protected key, sealed handle, authenticated execution permit, hardware-enable condition, or equivalent protected mechanism. It may be bound to the Candidate Act, descriptor, authorization scope, protected state, validation receipt, freshness condition, or Finality Sink as required by the applicable embodiment. 10.23. 23. Non-Bearer Capability “Non-Bearer Capability” means a scoped execution-enabling capability whose possession, copying, transmission, storage, forwarding, replay, or presentation does not independently confer authority to effectuate a Candidate Act. Its use remains subject to the applicable protected authorization, scope, state, and Finality Sink verification requirements. Das Expires 19 April 2027 [Page 89] Internet-Draft Protected AI Execution Finality October 2026 A Non-Bearer Capability may be act-bound, descriptor-bound, sink- bound, time-bound, nonce-bound, receipt-bound, or protected-state- bound. Non-bearer status does not necessarily require physical non- copyability, single-use operation, or a particular hardware implementation unless expressly specified. 10.24. 24. Human Approval and Approval Artifact “Human Approval” means an authorization decision supplied by a human actor having the authority required for a particular Candidate Act or governed operation. “Approval Artifact” means a machine-verifiable representation of that decision, which may identify the approver, authorized role, Candidate Act or permitted operation class, decision, validity period, approval scope, and applicable policy conditions. Where required, Human Approval is an Authority Predicate validated by the Protected Enforcement Domain. Human Approval does not independently substitute for required protected validation, evidence commitment, capability release, or Finality Sink verification. 10.25. 25. Protected Policy State and Policy Epoch “Protected Policy State” means policy-related authorization information maintained, authenticated, validated, or controlled within an applicable protected enforcement mechanism and used to determine the permitted execution conditions of Candidate Acts. “Policy Epoch” means a bounded version, generation, time interval, authority-controlled state, registry version, or protected rule-set state associated with applicable authorization or governance rules. A Candidate Act or execution capability may be bound to the relevant Policy Epoch. Where current epoch verification is required, an invalid or superseded policy state does not independently authorize effectuation. Das Expires 19 April 2027 [Page 90] Internet-Draft Protected AI Execution Finality October 2026 10.26. 26. Runtime Execution Context “Runtime Context” means measured, observed, attested, sampled, reported, sealed, or otherwise machine-verifiable execution circumstances under which a Candidate Act is generated, processed, validated, or prepared for effectuation. Such circumstances may include model, software, hardware, process, enclave, network, memory, queue, controller, tool, retrieval, policy, sensor, route, or timing state. “Runtime Execution Context” refers to the subset of those circumstances relevant to the applicable protected authorization and Finality Sink verification. Runtime Context is distinguishable from Authority Context and Purpose Context. 10.27. 27. Nonce, Freshness, and Expiry “Nonce” means a value used within an applicable authorization or execution-finality procedure to distinguish an operation, authorization event, session, or protected state and support required replay-prevention or freshness conditions. “Freshness” refers to the verified current validity of an authorization artifact, protected state, policy epoch, nonce, timestamp, sequence, or other required execution condition. “Expiry” refers to termination of validity under the applicable temporal or protected-state restriction. Where required freshness cannot be established or validity has expired, the corresponding execution capability is withheld or rejected under the applicable fail-closed conditions. 10.28. 28. Revocation “Revocation” means an authorized withdrawal, cancellation, invalidation, or termination of previously established execution authority, an Authority Object, credential, approval, capability, policy authorization, or other protected governance condition. “Revocation-Aware Enforcement” requires verification that the relevant authority remains non-revoked at the execution-time boundary specified by the embodiment. Das Expires 19 April 2027 [Page 91] Internet-Draft Protected AI Execution Finality October 2026 Revocation may be represented by protected revocation state, revocation epochs, authenticated status records, or equivalent mechanisms. Where current non-revocation is mandatory, stale, unavailable, inconsistent, or unverifiable revocation information does not establish authority to proceed. 10.29. 29. Capability Consumption “Capability Consumption” means marking, retiring, consuming, invalidating, or cryptographically advancing a scoped non-bearer capability after a permitted finality event or attempted finality event, as specified by the applicable embodiment. Consumption may be bound to the Candidate Act or HCAD digest, Finality Sink, LAVR digest, nonce, policy epoch, validity window, capability sequence number, or protected governance-chain state. A consumed single-use capability cannot authorize another effectuation contrary to its permitted scope. Capabilities expressly permitting bounded multiple uses remain subject to their specified usage and protected-state restrictions. 10.30. 30. Atomic Protected-State Transition “Atomic Protected-State Transition” refers to a protected enforcement operation in which required authorization-state updates are performed with the consistency and ordering necessary to prevent unauthorized effectuation resulting from incomplete or inconsistent protected- state handling. Under the disclosed Atomic State Consumption and Atomic Finality Commit mechanisms, required validation, state consumption or update, validation-evidence commitment, and capability availability are coordinated as one protected finality transaction. Where atomic commitment is required, the relevant sub-operations commit together or fail together. A failed mandatory transaction cannot produce a usable execution capability. The mechanism does not necessarily require a single globally distributed database transaction. Das Expires 19 April 2027 [Page 92] Internet-Draft Protected AI Execution Finality October 2026 10.31. 31. Formal Candidate Act State Machine “Formal Candidate Act State Machine” means a bounded execution- finality state machine defining the permitted states and transitions of a Candidate Act before and during governed effectuation. Non-limiting states include Non-Final, Descriptor-Pending, Descriptor-Formed, Validation-Pending, Validation-Failed, Held, Quarantined, Escalated, Capability-Prepared, Capability-Released, Sink-Verified, Released, Denied, Revoked, Expired, and Zeroized. Transition to Released requires satisfaction of the applicable protected validation, state-handling, evidence-commitment, capability-release, and Finality Sink verification conditions. Capability preparation or release alone does not constitute external effectuation. 10.32. 32. Replay and Unauthorized Reuse “Anti-Replay Protection” means technical measures intended to prevent unauthorized reuse of a previously issued authorization artifact, governance artifact, protected validation receipt, scoped execution capability, or release approval. Such measures may include nonce verification, freshness checks, temporal validity, session binding, challenge-response verification, protected counters, capability consumption, governance-chain linkage, or protected-state advancement. An artifact previously valid for one Candidate Act, execution context, Finality Sink, or authorized usage condition does not independently authorize its reuse outside the permitted scope. 10.33. 33. Duplicate External Effect Prevention “Duplicate External Effect Prevention” refers to protected enforcement measures configured to prevent a governed Candidate Act from producing an additional consequential effect through unauthorized repetition, replay, retry, capability reuse, or duplicate submission. Such measures may employ capability-consumption state, protected nonces, operation identifiers, sink-specific usage records, monotonic counters, or equivalent protected state. Where single-effect authorization is required, the same consumed authorization cannot validly enable another effectuation event. Das Expires 19 April 2027 [Page 93] Internet-Draft Protected AI Execution Finality October 2026 This definition does not independently guarantee exactly-once delivery or completion across every external system. 10.34. 34. Crash, Retry, and Recovery “Crash, Retry, and Recovery” refers to the protected handling of interrupted, failed, restarted, repeated, or restored execution- finality operations. A crash, timeout, restart, communication failure, interrupted commitment, or recovery-mode transition does not independently grant authority to effectuate a Candidate Act. Where required, recovery preserves or re-establishes the applicable protected authorization state, evidence commitment, capability- consumption status, policy epoch, and Finality Sink verification conditions. An operation with uncertain completion status is not automatically authorized for another consequential execution. Recovery-only actions remain subject to their applicable protected authorization conditions. 10.35. 35. Audit Evidence “Audit Evidence” means a record, event, log, receipt, trace, commitment, or other machine-readable information documenting an operation, validation event, authorization decision, protected-state transition, denial, capability event, or effectuation outcome. Audit Evidence may be generated before, during, or after an operation. Ordinary post-event logging does not independently constitute Protected Validation Evidence or satisfy a required pre-effectuation commitment. Where an embodiment requires validation evidence as a prerequisite to capability release, the required protected evidence must participate in the execution-finality dependency rather than merely document the completed operation afterward. Das Expires 19 April 2027 [Page 94] Internet-Draft Protected AI Execution Finality October 2026 10.36. 36. Bounded-Time and Latency-Aware Enforcement “Bounded-Time and Latency-Aware Enforcement” refers to execution- finality arrangements in which protected authorization processing and Finality Sink verification are organized to satisfy applicable timing or performance constraints without removing mandatory authorization dependencies. Computationally intensive validation may occur at protected control points, while a Finality Sink performs compact, locally verifiable capability checks on a latency-sensitive path. Supported mechanisms may include protected caching, bounded capability windows, precomputed commitments, hardware verification, and batched validation. The applicable implementation determines actual timing guarantees. Latency optimization does not authorize a Candidate Act to bypass required finality verification. 10.37. 37. Algorithmic Logic Fingerprint (ALF) “Algorithmic Logic Fingerprint” (ALF) means a machine-verifiable logic-measurement artifact, fingerprint, digest, structural identifier, semantic identifier, logic-bound signature, approval artifact, measurement value, class identifier, or equivalent construct associated with Algorithmic Logic. An ALF may represent an approved model, computational workflow, tool graph, retrieval policy, orchestration configuration, runtime pipeline, transformation logic, or policy configuration. ALF validation determines whether the relevant logic or configuration corresponds to an approved condition at the applicable computation- admission, runtime, or execution-finality stage. ALF validation is an authorization predicate and does not independently constitute final execution authority. 10.38. 38. Algorithmic Intent Fingerprint (AIF) “Algorithmic Intent Fingerprint” (AIF) means a machine-verifiable representation of the bounded operational intent under which a Candidate Act is permitted to proceed. An AIF may represent authorized purpose, operation class, tool scope, data scope, destination, resource, jurisdiction, delegation, transaction limits, or other permitted operational conditions. Das Expires 19 April 2027 [Page 95] Internet-Draft Protected AI Execution Finality October 2026 A Candidate Intent Descriptor may satisfy the Authorized Intent Envelope through exact correspondence or permitted subset containment. AIF represents authorized operational purpose and scope, not an artificial-intelligence model's subjective psychological intent. It is distinct from ALF, which governs approved computational logic. 10.39. 39. Runtime Behavioral Descriptor (RBD) “Runtime Behavioral Descriptor” (RBD) means a bounded machine- verifiable representation of governance-relevant behavior observed during a particular execution or invocation. An RBD may represent tools invoked, resources accessed, documents read, applications accessed, APIs called, external content consumed, sub-agents spawned, permissions requested, connector usage, policy branches, runtime measurements, and output class. The RBD may be evaluated against approved logic, operational intent, protected policy, or other applicable execution-finality predicates. It need not disclose hidden model reasoning. RBD validation does not independently substitute for required capability issuance or Finality Sink verification. 10.40. 40. Tool and Workflow Graph “Tool and Workflow Graph” refers to a machine-representable structure identifying tools, computational operations, workflow stages, orchestration relationships, retrieval paths, execution dependencies, or permitted transitions associated with an AI-agent or computational process. Such a graph may be included in, referenced by, or cryptographically bound to an Algorithmic Logic Fingerprint, approved workflow configuration, or applicable Authority Object. Where graph authorization is required, a materially changed tool or workflow configuration must satisfy the corresponding protected validation conditions before a governed Candidate Act becomes effective. The graph is not itself an execution capability. Das Expires 19 April 2027 [Page 96] Internet-Draft Protected AI Execution Finality October 2026 10.41. 41. Provenance and Taint “Provenance” refers to machine-verifiable information concerning the source, origin, lineage, transformation, or influence of data, instructions, tool outputs, or other material contributing to a Candidate Act. “Taint” refers to a trust classification or restriction associated with content or execution context originating from an untrusted or lower-trust source. Provenance and taint information may be represented through protected descriptors, Connector Boundary Receipts, Instruction Taint Boundary Objects, or equivalent records. Such information may be evaluated as an authorization predicate. Untrusted content does not independently acquire authority to control tool execution, policy, memory, or external effectuation. 10.42. 42. Untrusted Input Influence “Untrusted Input Influence” refers to the contribution or attempted contribution of lower-trust information to an AI-generated instruction, decision, tool invocation, workflow modification, or Candidate Act. Such information may originate from retrieved documents, webpages, emails, tool responses, memory entries, files, or external data sources. An Instruction Taint Boundary Object (ITBO) may distinguish trusted instructions from untrusted content and restrict the promotion of evidence into execution authority. Where required, the protected enforcement mechanism validates the resulting Candidate Act independently of instructions contained in untrusted material. 10.43. 43. Self-Mutation “Self-Mutation” refers to an AI-agent-initiated or computationally generated modification of its model runtime, system prompt, tool- access policy, safety configuration, retrieval connector, memory policy, delegation policy, planner policy, adapter state, or workflow graph. The proposed modification may constitute a Candidate Self-Mutation Act. Das Expires 19 April 2027 [Page 97] Internet-Draft Protected AI Execution Finality October 2026 In the Self-Modification Finality Gate embodiment, the act remains non-effective until the PED validates the applicable Self-Mutation Authority Object and releases the required Self-Modification Capability. The corresponding activation boundary verifies the capability before making the modification effective. 10.44. 44. Delegation “Delegation” refers to a proposed transfer or assignment of a task, subtask, execution function, tool access, data access, memory access, workflow responsibility, or bounded authority from one agent or component to another. A governed delegation constitutes a Candidate Delegation Act. Where protected delegation finality is required, the PED validates the applicable Delegation Authority Object and releases a scoped Delegation Capability. The receiving agent or downstream workflow verifies the capability before accepting the governed delegation. Delegation does not independently enlarge the authority originally available to the delegating agent. 10.45. 45. Delegation Limits “Delegation Limits” refers to the restrictions applicable to authority delegated to a subordinate agent, specialist agent, tool agent, or downstream workflow. Such restrictions may include parent and child agent identities, delegated objective, permitted subtask, tool class, data scope, memory scope, time window, recursion depth, execution budget, prohibited operations, policy epoch, revocation state, and freshness conditions. Where the applicable embodiment requires these restrictions, the Delegation Authority Object and Delegation Capability bind the permitted delegated scope. An operation exceeding a mandatory delegation limit requires separate valid authority before effectuation. Das Expires 19 April 2027 [Page 98] Internet-Draft Protected AI Execution Finality October 2026 10.46. 46. Candidate Deployment Act “Candidate Deployment Act” means a proposed operation involving source-code merge, repository modification, build or CI/CD configuration, dependency update, package publication, artifact signing, infrastructure modification, release, or production deployment that is subject to protected execution-finality control. The Candidate Deployment Act may be represented by a descriptor identifying the relevant code, artifact, target environment, operation scope, policy epoch, freshness condition, and Finality Sink. In the Autonomous Code-Deployment Finality Gate embodiment, the deployment operation remains non-effective until the required protected authorization and release-capability conditions are satisfied. 10.47. 47. Supply-Chain Authority Object “Supply-Chain Authority Object” means an Authority Object defining the protected authorization conditions applicable to a Candidate Deployment Act or other governed software supply-chain operation. Its validation may involve the permitted repository, code changes, dependencies, build or deployment configuration, artifact identity, test and scanner results, required approvals, deployment target, policy state, and freshness conditions. Where required by the Autonomous Code-Deployment Finality Gate embodiment, the PED/CIED validates the Supply-Chain Authority Object, generates the applicable Deployment LAVR or ZK-LAVR, and releases a Scoped Release Capability. The deployment Finality Sink verifies the capability before effectuation. 10.48. 48. Screen-State Finality Object (SSFO) “Screen-State Finality Object” (SSFO) means a protected object created before a governed computer-use or graphical-user-interface action becomes externally effective. An SSFO may bind the contemporaneous screen-state hash, interface- element identity, geometric target region, OCR or semantic label, action type, application context, authorized user intent, risk class, destination or Finality Sink, expiry, nonce, and chain-root reference. Das Expires 19 April 2027 [Page 99] Internet-Draft Protected AI Execution Finality October 2026 The SSFO is distinct from an ordinary screenshot, accessibility-tree record, or user-interface log. The governed interface action proceeds only after the required SSFO validation and corresponding scoped capability verification at the applicable Finality Sink. 10.49. 49. Network Destination, Endpoint, and Route Scope “Network Destination, Endpoint, and Route Scope” refers to machine- verifiable restrictions governing where, how, or through which authorized interface a Candidate Network or Sandbox Egress Act may produce its permitted network consequence. The applicable scope may identify a destination, API endpoint, network route, interface, requesting workload, credential scope, command class, permitted operation, policy epoch, freshness condition, or Finality Sink. Where the corresponding embodiment requires these predicates, the PED/CIED validates the proposed network operation against the applicable Authority Object. A different destination, endpoint, or route is not authorized when it exceeds the validated scope. 10.50. 50. Credential Broker “Credential Broker” refers to an intermediary component or protected service involved in mediating, obtaining, providing, or controlling access to credentials used for a governed operation. A Credential Broker may form part of a sandbox-egress, application, network, or protected authorization path. Where credential access or use constitutes a governed Candidate Act, the applicable protected execution-finality conditions remain mandatory. The existence of a Credential Broker does not independently establish Candidate Act-specific authorization, protected receipt commitment, or Finality Sink verification. A particular credential-storage, surrogate-token, or just-in-time credential-substitution implementation is not mandatory under this definition. Das Expires 19 April 2027 [Page 100] Internet-Draft Protected AI Execution Finality October 2026 10.51. 51. Surrogate Credentials “Surrogate Credential” means a restricted credential reference, substitute identifier, or non-authoritative token used by an application or AI agent in place of an underlying protected credential. A Surrogate Credential may identify a credential-mediated operation without directly exposing the underlying secret to the requesting component. Where implemented, use of the underlying credential remains subject to the applicable authorization and protected execution-finality requirements. A Surrogate Credential is distinct from an Execution Handle, EASO, and Scoped Non-Bearer Capability unless the embodiment expressly establishes their functional relationship. 10.52. 52. Protected Credential Release “Protected Credential Release” refers to a protected authorization operation controlling the disclosure, application, signing use, or availability of credential material for a governed Candidate Act. The protected mechanism may validate the requesting identity, authorized purpose, operation, destination, credential scope, freshness, and applicable protected state. Where a scoped execution capability is required, the corresponding credential-mediated effect remains subject to the protected capability and Finality Sink verification conditions. Credential release does not necessarily require disclosure of the underlying secret to the requesting agent. 10.53. 53. Privileged Connector “Privileged Connector” means an intermediary component having controlled access to a protected resource, service, credential, application programming interface, or execution interface that is not directly available to the requesting AI agent. A Privileged Connector may perform operations on behalf of an agent within a defined authorization scope. Das Expires 19 April 2027 [Page 101] Internet-Draft Protected AI Execution Finality October 2026 Where a connector operation constitutes a governed Candidate Act, its effectuation remains subject to the applicable protected authorization and Finality Sink verification. The term does not inherently require a separate host process, particular privilege-separation mechanism, or surrogate-credential substitution. 10.54. 54. Service-Mesh and Proxy Finality Enforcement “Service-Mesh and Proxy Finality Enforcement” refers to an execution- finality arrangement in which a service mesh, sidecar proxy, ingress or egress controller, API gateway, workload proxy, or equivalent infrastructure component performs an applicable Finality Gate or Finality Sink function. A Candidate Act involving service-to-service communication, API transmission, network egress, or downstream service invocation is subjected to protected authorization. Where required, the infrastructure component verifies a scoped Execution-Enabling Capability bound to the relevant act, workload, destination, route, policy state, and freshness conditions before permitting effectuation. 10.55. 55. Protected Computation Admission “Protected Computation Admission” refers to a protected authorization mechanism controlling whether a proposed model invocation, inference operation, training operation, computation task, or other governed computational activity may begin or enter a specified execution environment. Admission may depend upon identity, approved ALF, permitted model or workflow, execution scope, policy state, and applicable attestation or freshness conditions. Where the corresponding embodiment requires a protected admission capability, computation is withheld until the capability verifies. Authorization to begin computation does not independently authorize a subsequent network transmission, output release, payment, deployment, or other separately governed consequential operation. Das Expires 19 April 2027 [Page 102] Internet-Draft Protected AI Execution Finality October 2026 10.56. 56. Model Authorization and External Execution Authorization “Model Authorization” refers to verification that a model, algorithmic logic, configuration, or computational workflow satisfies the applicable authority, integrity, provenance, or approved-ALF conditions. “External Execution Authorization” refers to verification that a particular Candidate Act is permitted to produce its governed consequential effect. These are distinguishable authorization functions. Successful Model Authorization does not independently confer authority to transmit generated data, invoke external tools, release credentials, commit transactions, or perform downstream operations where separate execution-finality validation is required. 10.57. 57. Candidate Commerce Act “Candidate Commerce Act” means a proposed commercial, marketplace, auction, advertising, pricing, recommendation, negotiation, purchase, payment, or inventory-related operation subject to protected execution-finality control. Such acts may include bids, purchases, offers, ranking changes, price adjustments, payment instructions, ad placements, and inventory allocations. In the Market-Intent and Auction-Integrity Finality Gate embodiment, the PED/CIED validates the applicable Market-Compliance Authority Object, generates a Market-Integrity LAVR or ZK-LAVR, and releases a Commerce Actuation Capability. The applicable commerce Finality Sink verifies the capability before the governed act becomes effective. 10.58. 58. Destination Resolution and Redirect Control “Destination Resolution and Redirect Control” refers to verification that the destination, endpoint, recipient, network route, or downstream effectuation target of a Candidate Act remains within its applicable authorized scope. Where required, a changed endpoint, destination, route, or redirected operation must satisfy the protected authorization conditions applicable to the operation actually presented for effectuation. Das Expires 19 April 2027 [Page 103] Internet-Draft Protected AI Execution Finality October 2026 A previous authorization does not automatically permit an unauthorized destination substitution. Specific DNS-resolution, IP-address comparison, redirect-chain inspection, or DNS-rebinding prevention mechanisms are additional implementation requirements when expressly claimed. 10.59. 59. Confidential Virtual Machine (Confidential VM) “Confidential Virtual Machine” means a virtualized execution environment employing hardware-supported or equivalent protected- computing mechanisms to protect specified workload code, data, memory, or execution state against adversaries within its defined threat model. A Confidential VM may provide protected runtime isolation, measured launch state, memory encryption, integrity protection, or attestation according to its implementation. A Confidential VM may host a Protected Enforcement Domain or a governed AI workload. Confidential computation does not, by itself, establish Candidate Act-specific authorization, protected validation-evidence commitment, scoped capability release, or Finality Sink verification. 10.60. 60. Hardware Attestation “Hardware Attestation” refers to a machine-verifiable assertion or evidence structure establishing specified hardware, firmware, software, workload, configuration, or protected-execution measurements under an applicable hardware-rooted trust mechanism. Attestation may be used to validate a Protected Enforcement Domain, confidential workload, hardware enforcement component, protected key state, or execution context. Attestation evidence may be incorporated into applicable Authority Predicates or capability-binding conditions. Successful attestation establishes only the properties covered by the verified evidence and trust assumptions; it does not independently authorize every Candidate Act executed within the attested environment. Das Expires 19 April 2027 [Page 104] Internet-Draft Protected AI Execution Finality October 2026 10.61. 61. Hardware Trust Root and Virtual Trusted Platform Module (vTPM) “Hardware Trust Root” means a hardware-protected source of cryptographic identity, key protection, measurement, attestation, or integrity verification used to establish trust in an applicable protected execution or enforcement mechanism. A hardware trust root may comprise a TPM, secure element, HSM, hardware security processor, or equivalent protected component. “Virtual Trusted Platform Module” (vTPM) refers to a virtualized interface providing TPM-related functions to a virtual machine, subject to the security and key-protection properties of its implementation. Use of a hardware trust root or vTPM does not independently establish Candidate Act-specific execution authority. 10.62. 62. Hardware Composite Algorithmic Logic Fingerprint (ALF) “Hardware Composite ALF” refers to a proposed implementation of a Composite Algorithmic Logic Fingerprint incorporating hardware- related measurements or execution conditions alongside applicable model, software, workflow, configuration, or policy measurements. Such information may include hardware execution mode, accelerator configuration, protected-domain attestation, software state, approved model state, and applicable runtime configuration. The resulting fingerprint may be evaluated against an approved ALF condition. Hardware measurement or ALF correspondence does not independently replace required protected authorization, scoped capability release, or Finality Sink verification. 10.63. 63. User-Controlled Root Key “User-Controlled Root Key” means a cryptographic root key, root secret, or equivalent protected keying authority whose permitted use, derivation, release, or revocation is controlled by an identified user or authorized user-controlled security mechanism. In an implementation employing such a key, subordinate cryptographic material may be derived, wrapped, or made available subject to the applicable key-access and authorization conditions. Das Expires 19 April 2027 [Page 105] Internet-Draft Protected AI Execution Finality October 2026 User control does not necessarily require exposing the root-key material to an application or AI agent. A User-Controlled Root Key is distinct from an Authority Object and does not independently authorize a Candidate Act to become externally effective. 10.64. 64. Derived and Wrapped Keys “Derived Key” means cryptographic key material produced from another secret or protected keying input through an applicable key-derivation mechanism. “Wrapped Key” means cryptographic key material protected through encryption or a key-wrapping mechanism for controlled storage, transfer, or use. In protected execution-finality embodiments, derived or wrapped keys may enable an authorized decryption, signing, transmission, release, or other governed operation. Where required, the protected mechanism binds key availability or use to the corresponding Candidate Act, protected authorization state, and Finality Sink verification. 10.65. 65. Cryptographic Authorization Commitment “Cryptographic Authorization Commitment” means a cryptographically protected representation associating specified authorization information with a Candidate Act, protected validation state, or execution-enablement condition. Such a commitment may bind a Candidate Act Descriptor, Authority Object reference, validated predicates, protected-state transition, policy epoch, nonce, receipt commitment, permitted execution scope, or Finality Sink identity. The commitment may comprise a cryptographic digest, MAC, signature, Merkle commitment, sealed record, or equivalent authenticated representation. A Cryptographic Authorization Commitment does not independently constitute an execution capability unless the applicable embodiment expressly assigns and enforces that function. Das Expires 19 April 2027 [Page 106] Internet-Draft Protected AI Execution Finality October 2026 10.66. 66. Hardware Freshness “Hardware Freshness” refers to a hardware-supported or hardware- protected condition used to establish the current validity, sequence, generation, or non-replayed status of execution-related authorization state. Hardware freshness may be represented through secure counters, hardware-backed nonces, monotonic state, protected measurements, trusted timing state, or equivalent protected values. Where required by the embodiment, a scoped execution capability may be bound to hardware freshness state. A stale, replayed, rolled-back, or unverifiable required freshness condition does not establish valid execution authority. 10.67. 67. Hardware Finality Latch “Hardware Finality Latch” refers to a hardware-enforced implementation of a Finality Latch that prevents a governed Candidate Act from crossing its Execution-Finality Boundary unless the required scoped execution capability or corresponding protected enablement condition is verified. The latch may control queue admission, DMA mapping, memory access, network forwarding, storage commitment, accelerator egress, RF activation, optical modulation, or another consequential interface. A Hardware Finality Latch may be implemented within a processor, accelerator, controller, NIC, SmartNIC, DPU, FPGA, ASIC, or equivalent enforcement component. Hardware presence alone does not establish that the relevant effectuation path is non-bypassable. 10.68. 68. Candidate Fabric Transfer Act “Candidate Fabric Transfer Act” means a proposed transfer, routing, switching, replication, multicast, DMA, or delivery operation involving AI computation state, tensors, activations, memory content, model outputs, or other governed information between compute, accelerator, memory, or fabric domains. The Candidate Fabric Transfer Act may be represented by a descriptor identifying the source, destination, transfer scope, relevant protected state, policy conditions, and fabric Finality Sink. Das Expires 19 April 2027 [Page 107] Internet-Draft Protected AI Execution Finality October 2026 Where the applicable embodiment requires protected fabric finality, the PED/CIED validates the Cross-Domain Fabric Authorization Object and releases the required Fabric Transfer Capability. The fabric Finality Sink verifies the capability before permitting the governed transfer. 10.69. 69. Virtual-Machine Snapshot Rollback “Virtual-Machine Snapshot Rollback” refers to restoration or attempted restoration of a virtual machine, container, application, model-runtime, or associated execution state to an earlier recorded state. In a protected execution-finality embodiment, rollback must not restore authorization previously consumed, revoked, expired, denied, or otherwise invalidated under mandatory protected-state conditions. Rollback protection may employ sealed state, monotonic counters, protected epochs, authenticated state continuity, or equivalent mechanisms. Where a required protected-state mismatch is detected, the affected Candidate Act remains non-effective pending valid protected recovery or renewed authorization. 10.70. 70. Migration, Recovery, and Failover “Migration, Recovery, and Failover” refers to movement, restoration, continuation, or transfer of a governed workload, protected execution function, authorization state, or Finality Sink responsibility between execution environments or components. Such events may include workload migration, component replacement, service restart, recovery from failure, or activation of a standby enforcement mechanism. Where protected execution-finality continuity is required, the receiving or restored environment must satisfy the applicable authority, policy, revocation, freshness, protected-state, capability-consumption, and Finality Sink conditions before permitting governed effectuation. Migration or failover does not independently create or restore execution authority. Das Expires 19 April 2027 [Page 108] Internet-Draft Protected AI Execution Finality October 2026 10.71. 71. Workload and Tenant Identity “Workload Identity” means a machine-verifiable identity associated with a computational workload, service, application, agent, process, virtual machine, container, model execution, or corresponding execution context. “Tenant Identity” means an identity associated with a logical or organizational tenant whose resources, data, policies, or execution authority are governed within a shared or distributed computing environment. Workload and Tenant Identities may form part of a Candidate Act Descriptor, Authority Object, Runtime Context, or protected authorization predicate. Successful identity verification does not independently confer authority to effectuate a Candidate Act. 10.72. 72. Cloud Control Plane “Cloud Control Plane” means a computing or orchestration layer responsible for configuring, scheduling, managing, deploying, or coordinating cloud workloads, infrastructure resources, permissions, network paths, or associated services. A Cloud Control Plane may prepare, request, transmit, or administer a Candidate Act or applicable authorization information. Where the operation is governed by protected execution-finality requirements, the Cloud Control Plane cannot independently substitute its administrative authority for the required protected validation and Finality Sink verification. Cloud administration permission does not automatically constitute authority for a particular external effect. 10.73. 73. Watchdog Monitoring State “Watchdog Monitoring State” refers to machine-verifiable information generated or maintained by a watchdog, runtime monitor, protected controller, security processor, or equivalent monitoring mechanism concerning the condition of a governed computing or enforcement component. Such information may concern availability, integrity, fault conditions, reset events, execution anomalies, or enforcement-path status. Das Expires 19 April 2027 [Page 109] Internet-Draft Protected AI Execution Finality October 2026 Where required by an embodiment, monitoring information may inform protected validation, denial, recovery, or quarantine decisions. A watchdog observation does not independently constitute an execution capability, and a watchdog failure does not create authority to bypass protected finality enforcement. 10.74. 74. Quarantine “Quarantine” means a restricted technical state or enforcement action in which a Candidate Act, output, workload, artifact, resource, or other governed operation is held, isolated, suppressed, or prevented from producing further unauthorized effects. Quarantine may occur before effectuation when protected validation fails or authorization remains unresolved. In an implementation supporting post-event containment, quarantine may also restrict subsequent activity following detection of an unauthorized or suspicious condition. Quarantine after an effect has occurred does not retroactively prevent that completed effect or independently satisfy a required pre-effectuation Finality Sink check. 10.75. 75. Multiple Finality Sinks “Multiple Finality Sinks” refers to an execution arrangement in which a workflow contains two or more distinct governed effectuation boundaries, each associated with a consequential operation or operation phase. Such boundaries may include network transmission, tool execution, database commitment, payment settlement, model-output release, or physical actuation. Where the applicable embodiment requires separate sink authorization, each Finality Sink verifies its own scoped execution capability or a capability expressly bound to that sink and phase. Authorization at one Finality Sink does not independently authorize effectuation at another. Das Expires 19 April 2027 [Page 110] Internet-Draft Protected AI Execution Finality October 2026 10.76. 76. Distributed Revocation “Distributed Revocation” refers to the propagation, synchronization, validation, or enforcement of revocation-related authorization state across multiple protected enforcement components, authority domains, workloads, or Finality Sinks. Such state may be represented through authenticated revocation records, protected revocation epochs, signed policy updates, short- lived authority windows, protected caches, or equivalent mechanisms. Where current non-revocation is mandatory, each applicable enforcement component verifies the revocation information required by its authorization rules. Unavailable, stale beyond the permitted freshness window, or invalid required revocation state does not create execution authority. 10.77. 77. Out-of-Band Monitoring and Inline Enforcement “Out-of-Band Monitoring” refers to observation, collection, analysis, or communication of governance-related information through a mechanism logically separate from the governed operation's principal effectuation path. “Inline Enforcement” refers to a mechanism positioned within, or in effective mandatory control of, a governed effectuation path so that the consequential operation depends upon satisfying the applicable enforcement conditions. Out-of-band information may inform protected authorization, policy updates, revocation, quarantine, or recovery. Observation or detection alone does not establish that an inline or otherwise non-bypassable Finality Sink prevented an external effect. The required prevention guarantee depends upon the actual enforcement arrangement. 10.78. 78. Cross-Component Authorization Consistency “Cross-Component Authorization Consistency” refers to the required correspondence of Candidate Act identity, authorization scope, protected policy state, execution epoch, revocation state, capability bindings, and effectuation conditions among components participating in a governed execution-finality sequence. Das Expires 19 April 2027 [Page 111] Internet-Draft Protected AI Execution Finality October 2026 Where the applicable embodiment requires such consistency, the protected enforcement mechanism verifies that an operation is not effectuated using incompatible or invalid required authorization states. Consistency may be maintained through authenticated commitments, protected state references, epoch verification, sink-specific capabilities, or equivalent protected mechanisms. The term does not independently require global consensus, instantaneous synchronization, or a single centralized authorization authority. Explanatory definitions of key technical words: 10.79. 1. Protected Enforcement Domain (PED) “Protected Enforcement Domain” (PED) means a protected execution, authority, governance, or enforcement boundary configured to perform or control one or more protected execution-finality functions associated with a Candidate Act, including applicable authorization- predicate validation, protected-state handling, validation-evidence generation or commitment, scoped execution-capability control, Finality Gate support, and fail-closed withholding. A PED may be implemented in hardware, firmware, software, a hypervisor, microkernel, TEE, HSM, secure enclave, secure element, protected controller, gateway, SmartNIC, DPU, FPGA, distributed protected authority arrangement, or equivalent protected environment, provided the required protected enforcement relationship is preserved. A PED may be physically separate from, integrated with, or colocated with other system components. A Cryptographically Isolated Enforcement Domain (CIED) is a stronger protected implementation with additional cryptographic-isolation properties. 10.80. 2. Finality Sink (FS) “Finality Sink” (FS) means a technical effectuation boundary at which a governed Candidate Act would first become externally effective, practically usable, transmitted, committed, rendered, stored, decrypted, signed, forwarded, admitted, settled, actuated, energized, or otherwise consequential. Das Expires 19 April 2027 [Page 112] Internet-Draft Protected AI Execution Finality October 2026 A Finality Sink may comprise a hardware, firmware, software, protocol, network, storage, database, payment, rendering, cryptographic, memory, accelerator, communication, or physical- control interface, provided the interface controls the relevant effectuation boundary. Where required by the applicable embodiment, the Finality Sink verifies a scoped execution capability or corresponding protected enablement condition before permitting effectuation. The Finality Sink may be integrated with or physically separate from the PED or Finality Gate, provided the applicable protected verification and non-bypassable effectuation requirements are satisfied. 10.81. 3. Candidate Act (CA) “Candidate Act” (CA) means a proposed, requested, generated, computed, derived, prepared, staged, buffered, selected, planned, delegated, scheduled, or otherwise pending operation that, if permitted to proceed, would produce a governed consequential effect. A Candidate Act may include an AI-generated output, tool invocation, API request, network transmission, file or database operation, model update, credential operation, computation-admission request, data or memory transfer, financial transaction, deployment, rendering event, communication, cryptographic operation, or physical actuation. Where applicable, a governed omission, timeout, non-renewal, or failure to maintain a required state may also constitute a Candidate Act. A Candidate Act does not independently become authorized or effective merely because it has been computed, generated, approved, authenticated, or prepared. 10.82. 4. Compute Plane (CP) “Compute Plane” (CP) means one or more computational components, environments, or execution resources configured to receive, process, generate, transform, prepare, or stage data, instructions, model outputs, execution requests, or Candidate Acts. The Compute Plane may comprise an AI model, autonomous agent, application, process, tool runtime, container, virtual machine, cloud workload, CPU, GPU, NPU, TPU, FPGA, accelerator, model-serving system, edge device, distributed compute cluster, or heterogeneous computing infrastructure. Das Expires 19 April 2027 [Page 113] Internet-Draft Protected AI Execution Finality October 2026 The Compute Plane may be local, remote, cloud-hosted, edge-hosted, virtualized, confidential, distributed, or physically integrated with protected enforcement components. For a governed Candidate Act, computation or operation preparation by the Compute Plane does not independently confer the protected authority required to cross the applicable Execution-Finality Boundary. Physical integration does not eliminate the distinct computation and authorization functions. 11. Detailed Execution-Finality Workflows 11.1. WF-01 — Universal Protected Execution-Finality Workflow for AI and Autonomous Computing Systems 11.1.1. WF-01.1 — Technical Field and Purpose The present workflow describes a computer-implemented execution- finality architecture configured to prevent a Candidate Act generated, selected, prepared, or initiated by an artificial- intelligence system or other computational component from becoming externally effective unless the applicable protected authorization and execution-enablement conditions have been satisfied. The workflow separates the ability to perform computation from the authority to cause a consequential operation. The architecture comprises a Compute Plane, a Candidate Act holding mechanism, a Candidate Act Descriptor, a Protected Enforcement Domain (PED), protected authorization state, protected validation evidence, a scoped non-bearer execution capability, and a Finality Sink controlling the applicable effectuation boundary. The described sequence may be implemented within a single node, device, chip, host, gateway, cloud workload, or protected controller, or across multiple cooperating components, provided that the required authorization and effectuation relationships are preserved. 11.1.2. WF-01.2 — Participating Technical Components In one non-limiting embodiment, the system comprises: Component CP-101 — Compute Plane A computational environment comprising one or more AI agents, models, processors, applications, tools, virtual machines, containers, accelerators, or associated execution resources configured to prepare operations. Das Expires 19 April 2027 [Page 114] Internet-Draft Protected AI Execution Finality October 2026 The Compute Plane may generate a proposed operation but does not independently control the protected capability required to effectuate that operation. Component HI-102 — Holding and Interception Mechanism A component configured to intercept, receive, stage, buffer, or otherwise hold a proposed operation before it crosses the governed execution-finality boundary. The mechanism may comprise a kernel broker, hypervisor-controlled interface, sandbox broker, protected queue, API gateway, network- egress proxy, file-operation broker, hardware output buffer, or equivalent interception component. Component DC-103 — Descriptor Construction Mechanism A component configured to obtain and represent the Candidate Act and its effectuation-relevant execution context using a deterministic machine-readable descriptor. The descriptor construction mechanism may be integrated with the interception mechanism or PED. Component PED-104 — Protected Enforcement Domain A protected authorization and enforcement environment configured to validate the applicable Candidate Act against required authority predicates, perform protected-state operations, generate or commit protected validation evidence, and control release or availability of a scoped execution capability. Component PS-105 — Protected State Store A protected, authenticated, or otherwise enforcement-controlled state mechanism holding applicable policy, freshness, nonce, quota, revocation, usage, validation-commitment, and capability-consumption information. The state store may be integrated within PED-104 or maintained through another protected arrangement satisfying the required security properties. Component EO-106 — Protected Validation Evidence Mechanism Das Expires 19 April 2027 [Page 115] Internet-Draft Protected AI Execution Finality October 2026 A protected mechanism for generating or committing a validation receipt, authenticated state record, sealed receipt, LAVR, AVR, cryptographic commitment, or equivalent protected evidence associated with the validation result. Component CR-107 — Capability Release Mechanism A mechanism controlled by PED-104 that generates, derives, activates, releases, or otherwise makes available the required scoped non-bearer execution capability following the applicable protected finality transaction. Component FS-108 — Finality Sink An effectuation interface configured to verify the required execution capability against the operation presented for effectuation and to refuse the operation unless the mandatory capability-verification conditions are satisfied. Component EF-109 — Effectuation Interface The controlled interface through which a verified Candidate Act produces its permitted consequence, including network transmission, tool invocation, API execution, file commitment, signing, credential use, storage modification, payment settlement, output release, memory transfer, or physical actuation. PED-104, CR-107, FS-108, and EF-109 may be colocated or distributed. Functional distinction does not require physical separation unless expressly specified. 11.1.3. WF-01.3 — System Initialization Before processing governed operations, the system establishes the applicable protected execution-finality configuration. The initialization procedure comprises: (a) identifying the operation classes subject to protected effectuation control; (b) identifying the corresponding Finality Sinks and effectuation boundaries; (c) establishing the applicable Authority Objects and authorization- predicate definitions; (d) initializing protected policy and revocation state; Das Expires 19 April 2027 [Page 116] Internet-Draft Protected AI Execution Finality October 2026 (e) establishing any required cryptographic capability-issuance or authentication keys; (f) establishing the trusted verification relationship between PED-104 and FS-108; (g) initializing required freshness, nonce, usage, and receipt- commitment state; and (h) configuring the governed execution path so that the Compute Plane cannot directly bypass the corresponding enforcement interface. In a cryptographic implementation, PED-104 may maintain a protected private capability-signing key while FS-108 maintains the corresponding authenticated verification key. In a single-node implementation, the protected authority and sink may instead employ a protected internal capability table, sealed state, or hardware-controlled enablement condition. The protected authority configuration is not writable by an untrusted agent merely because that agent can execute within CP-101. 11.1.4. WF-01.4 — Establishment of the Governed Execution Path The system configures each governed effectuation interface so that the Candidate Act cannot produce its specified consequence without passing through the applicable Finality Sink. For an illustrative sandbox-network embodiment, this may be implemented by placing the AI-agent runtime within an isolated network namespace lacking an independent external transmission route and directing permitted outbound operations through an enforcement- controlled network interface. The system may additionally restrict direct access to host sockets, raw network interfaces, privileged device nodes, credential stores, file-system mutation interfaces, and other effect-capable resources that would bypass the governed path. The actual interception mechanism is selected according to the operating system, hypervisor, network infrastructure, hardware interface, or execution substrate. For a single-node gateway embodiment, the same protected node may maintain the Candidate Act, validate its authority, commit evidence, release the capability, verify it at a local sink, and control the output interface. Das Expires 19 April 2027 [Page 117] Internet-Draft Protected AI Execution Finality October 2026 For a distributed embodiment, PED-104 and FS-108 communicate through an authenticated channel or verify an authenticated capability representation. A non-bypassable guarantee applies to the effectuation paths actually controlled by the implemented enforcement arrangement. 11.1.5. WF-01.5 — Generation of a Candidate Act CP-101 generates or prepares a proposed operation. Non-limiting operations include: (a) an HTTP request; (b) a tool invocation; (c) an application programming interface call; (d) a shell command; (e) a file write; (f) a credential-mediated service invocation; (g) a model-runtime or policy mutation; (h) a delegated agent operation; (i) a data or tensor transfer; (j) a transaction instruction; or (k) another operation capable of producing a governed consequence. The resulting proposed operation is designated Candidate Act CA-110. Generation of CA-110 does not itself constitute authorization to execute the operation. 11.1.6. WF-01.6 — Interception and Non-Effective Staging HI-102 receives or intercepts CA-110 before the operation reaches EF- 109. The interception mechanism assigns an operation identifier and places CA-110 into a Non-Effective State. Das Expires 19 April 2027 [Page 118] Internet-Draft Protected AI Execution Finality October 2026 The operation may be maintained as a queued request, retained command, buffered payload, pending tool invocation, protected transaction descriptor, inactive hardware operation, or equivalent staged representation. The system prevents the effectuation interface from processing the operation while the required protected validation conditions remain unresolved. A representative state record comprises: operation_id; candidate_act_reference; requesting_context; target_sink; status = NON_EFFECTIVE; created_at; applicable_policy_reference. The record may be maintained within protected state, a holding queue subject to protected release control, or another enforcement- controlled location. The underlying request payload may remain outside the PED where an authenticated descriptor or digest is sufficient for the required validation. 11.1.7. WF-01.7 — Construction of the Candidate Act Descriptor DC-103 obtains the effectuation-relevant attributes of CA-110 and constructs a Candidate Act Descriptor. The descriptor may contain: act_id; act_class; requesting_agent_or_workload; source_execution_context; Das Expires 19 April 2027 [Page 119] Internet-Draft Protected AI Execution Finality October 2026 operation_parameters; payload_digest; destination_or_resource; requested_effect; authority_object_reference; policy_epoch; finality_sink_id; finality_boundary_id; nonce; expiry; permitted_scope_reference. Only the fields required by the applicable embodiment need be included. Where a cryptographic descriptor is used, the descriptor is canonicalized under a defined deterministic encoding procedure. A non-limiting descriptor-binding expression is: D = CanonicalEncode_v(Fields(CA, X, F)) where: D denotes the canonical Candidate Act Descriptor; CA denotes the proposed Candidate Act; X denotes the effectuation-relevant runtime execution context; F denotes the applicable Finality Sink identity; Fields denotes extraction or assembly of the required descriptor fields; CanonicalEncode_v denotes a deterministic encoding procedure of specified version v. Das Expires 19 April 2027 [Page 120] Internet-Draft Protected AI Execution Finality October 2026 The version identifier permits the receiving verifier to interpret the same descriptor fields using the intended representation rules. An illustrative cryptographic descriptor digest is: hD = H("DAS-CA-v1" || D) where: hD denotes the descriptor digest; H denotes an approved cryptographic hash function; "DAS-CA-v1" denotes an illustrative domain-separation label; || denotes concatenation of encoded values. The particular hash algorithm and serialization method are implementation-dependent. The described mathematical representation is an illustrative implementation of the disclosed deterministic descriptor-binding function, not a mandatory cryptographic algorithm for every embodiment. 11.1.8. WF-01.8 — Acquisition of Applicable Authority PED-104 obtains or resolves one or more applicable Authority Objects. An Authority Object may identify the permitted operation class, purpose, destination, resource, authority issuer, requesting identity, execution scope, policy epoch, freshness requirements, revocation conditions, and other mandatory authorization predicates. The applicable Authority Object may be: (a) supplied to the PED through an authenticated interface; (b) retrieved from an authenticated authority store; (c) referenced by an Execution Handle; (d) associated with an Execution Authorization Scope Object; or (e) obtained from another protected source permitted by the embodiment. Das Expires 19 April 2027 [Page 121] Internet-Draft Protected AI Execution Finality October 2026 PED-104 verifies the required authenticity, scope, validity, and issuer conditions before treating the authority information as valid. A requesting agent cannot establish authorization merely by supplying a self-declared Authority Object. 11.1.9. WF-01.9 — Protected Authorization-Predicate Validation PED-104 evaluates the mandatory authorization predicates associated with CA-110. Such predicates may concern: (a) requesting agent or workload identity; (b) permitted operation class; (c) authorized purpose; (d) requested destination; (e) permitted execution scope; (f) applicable policy epoch; (g) revocation state; (h) nonce or freshness; (i) protected quota or usage allowance; (j) required human approval; (k) Algorithmic Logic Fingerprint; (l) Algorithmic Intent Fingerprint; (m) Runtime Behavioral Descriptor; (n) required attestation; or (o) other conditions required by the applicable Authority Object. For a conjunctive predicate set, validation may be expressed as: V = P1(D,A,S,X) AND P2(D,A,S,X) AND ... AND Pn(D,A,S,X) where: Das Expires 19 April 2027 [Page 122] Internet-Draft Protected AI Execution Finality October 2026 V denotes the protected validation result; P1 through Pn denote the mandatory authorization predicates; n denotes the number of required predicates; D denotes the Candidate Act Descriptor; A denotes the applicable Authority Object or authenticated authority context; S denotes the relevant protected authorization state; X denotes the required Runtime Context. V is true only when all mandatory predicates satisfy their respective validation rules. An embodiment employing a quorum, approved alternatives, or threshold conditions evaluates those conditions according to its corresponding protected policy rather than requiring literal conjunction of every possible predicate. If any mandatory condition fails or cannot be established, the system withholds the required execution authority. 11.1.10. WF-01.10 — Protected Authorization-State Operation When the applicable authorization predicates succeed, PED-104 performs the protected-state operation required for the Candidate Act. The protected-state operation may comprise: (a) consumption of a nonce; (b) reservation or decrement of quota; (c) protected usage-counter advancement; (d) recording of an authorized operation identifier; (e) verification or advancement of a state-generation value; (f) registration of a receipt commitment; (g) reservation of a capability instance; or Das Expires 19 April 2027 [Page 123] Internet-Draft Protected AI Execution Finality October 2026 (h) another protected authorization-state transition. Where an atomic protected-state transition is required, PED-104 prevents two concurrent requests from independently consuming the same restricted authorization state. For example, when a capability is limited to one authorized use, the protected state store may perform an atomic compare-and-update operation against the relevant operation and authorization-state version. If the required protected state cannot be updated consistently, capability issuance does not succeed. 11.1.11. WF-01.11 — Generation and Commitment of Protected Validation Evidence Following successful validation and in coordination with the required protected-state operation, EO-106 generates or commits Protected Validation Evidence. An illustrative record may contain: receipt_id; candidate_act_digest; validated_predicate_reference; authority_reference; protected_state_transition_digest; policy_epoch; freshness_reference; finality_sink_id; finality_boundary_id; decision = ALLOW; protected_domain_authentication. The evidence may comprise a signed receipt, protected register commitment, sealed record, LAVR, AVR, hash-chain entry, Merkle commitment, or another protected representation. Das Expires 19 April 2027 [Page 124] Internet-Draft Protected AI Execution Finality October 2026 The evidence is committed before, or atomically with, making the corresponding scoped non-bearer capability available. Where the implementation permits later external publication or ledger anchoring, the protected commitment is not delayed merely because publication has not yet occurred. An ordinary post-event audit record does not replace the mandatory pre-effectuation evidence commitment. 11.1.12. WF-01.12 — Protected Finality Transaction PED-104 establishes the required dependency between successful validation, protected-state handling, validation-evidence commitment, and capability availability. A non-limiting protected transaction is represented as: (S_next, R, Ready) = CommitFinality(D, A, S_current, F) where: S_current denotes the protected authorization state before the transaction; S_next denotes the protected authorization state after successful commitment; R denotes the committed protected validation evidence; Ready denotes a protected indication that all required pre-release conditions have completed; D denotes the validated Candidate Act Descriptor; A denotes the applicable authority context; F denotes the designated Finality Sink. The transaction succeeds only when its required state and evidence operations are consistent and committed under the selected protected implementation. The capability-release mechanism does not treat an incomplete or failed commitment as successful authorization. Das Expires 19 April 2027 [Page 125] Internet-Draft Protected AI Execution Finality October 2026 A protected transaction may be implemented through transactional storage, sealed-state machinery, a protected register protocol, an HSM-controlled procedure, or an equivalent protected arrangement. Where a transaction spans components that do not support a single atomic storage transaction, the capability remains unavailable until the required committed dependencies have been verified. 11.1.13. WF-01.13 — Generation of Scoped Non-Bearer Capability Upon successful completion of the required protected finality transaction, CR-107 creates or makes available a scoped non-bearer execution capability. In an illustrative signature-based implementation: C = Sign_skPED(Encode(hD, hR, F, Scope, Epoch, N, Expiry, CID)) where: C denotes the authenticated execution capability; Sign denotes digital-signature generation; skPED denotes a private signing key protected under control of PED- 104; Encode denotes the specified deterministic encoding procedure; hD denotes the authorized Candidate Act Descriptor digest; hR denotes the protected validation-evidence commitment digest; F denotes the authorized Finality Sink; Scope denotes the permitted effectuation scope; Epoch denotes the required policy or execution epoch; N denotes the capability freshness or nonce value; Expiry denotes the capability validity limit; CID denotes a unique capability identifier. These values are illustrative. The particular claim or embodiment determines which bindings are mandatory. Das Expires 19 April 2027 [Page 126] Internet-Draft Protected AI Execution Finality October 2026 The corresponding verification key is provisioned to the authorized Finality Sink. The capability is non-bearer under the described arrangement because successful presentation remains dependent upon verification against the required operation, sink, authorization state, freshness, scope, and consumption conditions. A signature alone does not establish non-bearer behavior unless the necessary contextual restrictions are actually enforced. 11.1.14. WF-01.14 — Transfer or Availability of the Capability The capability may be made available to FS-108 through: (a) an authenticated inter-component interface; (b) an authenticated protected queue; (c) a sealed shared-memory mechanism; (d) an internal protected capability table; (e) an authenticated response to an effectuation request; (f) a hardware-controlled capability register; or (g) another protected means supported by the embodiment. The system may transmit a compact capability representation rather than the entire validation evidence or original Candidate Act payload. The Compute Plane may receive a capability reference where appropriate, but such receipt does not permit the agent to alter the capability or bypass required sink-side verification. 11.1.15. WF-01.15 — Reconstruction or Verification at the Finality Sink Before permitting CA-110 to produce its governed effect, FS-108 obtains the operation actually presented at EF-109. The Finality Sink determines the relevant actual operation attributes and constructs or verifies the corresponding effectuation descriptor. Let: D_actual = CanonicalEncode_v(Fields(CA_actual, X_actual, F)) Das Expires 19 April 2027 [Page 127] Internet-Draft Protected AI Execution Finality October 2026 where: CA_actual denotes the operation actually presented for effectuation; X_actual denotes the relevant execution context at the sink; F denotes the Finality Sink performing verification; D_actual denotes the resulting effectuation descriptor. Where exact descriptor correspondence is required: H("DAS-CA-v1" || D_actual) = hD Where the authorization expressly permits bounded variations, the sink instead verifies the required exact bindings together with the applicable bounded-scope predicates. The Finality Sink must not regard an unauthorized change of target, payload, operation class, destination, scope, or other required descriptor field as valid merely because the requesting agent previously obtained an approval. 11.1.16. WF-01.16 — Capability Verification at the Finality Sink FS-108 verifies the scoped capability using the required authentication and state-verification mechanisms. In the illustrative signature-based implementation, verification comprises: (a) verifying the capability signature using an authenticated PED verification key; (b) verifying the authorized Finality Sink identity; (c) verifying the Candidate Act Descriptor or authorized operation scope; (d) checking the applicable policy epoch; (e) validating required expiry and freshness conditions; (f) checking the required revocation state; (g) verifying the protected validation-evidence reference; (h) verifying required protected usage or consumption state; and Das Expires 19 April 2027 [Page 128] Internet-Draft Protected AI Execution Finality October 2026 (i) confirming that the actual requested operation remains within the permitted effectuation scope. The authorization result may be expressed as: Permit = Auth(C) AND Match(C,D_actual) AND ScopeValid(C,F) AND StateValid(C,S_next,R) where: Permit denotes the Finality Sink's decision for the governed operation; Auth denotes verification of the required capability authenticity; Match denotes verification of exact descriptor correspondence or applicable bounded-scope matching; ScopeValid denotes verification of the permitted Finality Sink and execution scope; StateValid denotes verification of required protected state, receipt, freshness, revocation, and usage conditions. All mandatory conditions must be true for Permit to be true. A Finality Sink need not reproduce every computationally intensive upstream predicate when the capability and required protected commitments provide sufficient authenticated evidence of those earlier results. 11.1.17. WF-01.17 — Protected Capability Consumption Where the capability is single-use or usage-bounded, the Finality Sink performs or coordinates the protected consumption operation required by the applicable authorization. An illustrative protected capability-state record comprises: capability_id; authorized_act_digest; authorized_sink; remaining_uses; state_version; Das Expires 19 April 2027 [Page 129] Internet-Draft Protected AI Execution Finality October 2026 status. Before final effectuation, the Finality Sink verifies that the capability remains within its permitted usage state. The implementation may use a protected atomic compare-and-update operation, authenticated capability-consumption service, protected hardware counter, or equivalent state mechanism. For a single-use capability, a concurrent second attempt cannot independently succeed against the same available usage state. If the usage state is already consumed, revoked, exhausted, or otherwise invalid, the corresponding operation is refused. For operations whose external effect cannot be atomically committed together with local capability consumption, the system separately maintains the applicable pending, reserved, effective, failed, or indeterminate completion state. 11.1.18. WF-01.18 — Controlled External Effectuation If all mandatory Finality Sink verification conditions succeed, FS-108 enables only the operation and effectuation scope authorized by the verified capability. Examples include: (a) forwarding the authorized network request; (b) invoking the approved tool; (c) permitting a specified file operation; (d) releasing a credential for its authorized use; (e) committing an approved database operation; (f) applying an authorized model or policy modification; (g) admitting a permitted fabric transfer; or (h) enabling an authorized physical-control operation. The effectuation interface does not receive unrestricted authority to execute additional operations outside the verified scope. Das Expires 19 April 2027 [Page 130] Internet-Draft Protected AI Execution Finality October 2026 After the permitted effectuation event, the system records or updates the applicable protected completion and capability-consumption state. The exact meaning of successful external completion depends upon the controlled interface. Transmission acceptance by a local gateway, for example, does not automatically prove downstream processing or remote transaction completion. 11.1.19. WF-01.19 — Illustrative Network-Egress Implementation In one concrete implementation, an AI agent executes within an isolated sandbox and generates an HTTPS POST request to an authorized application programming interface. The sandbox lacks direct external network connectivity and can submit external requests only through an enforcement-controlled host egress broker. The broker retains the proposed request in a pending state and constructs a canonical descriptor identifying the requesting sandbox, request method, destination, resource path, request-body digest, applicable authority scope, policy epoch, and designated network Finality Sink. PED-104 authenticates the applicable Sandbox Egress Authority Object and validates the required operation, purpose, destination, policy, runtime-context, and freshness conditions. After successful validation, the PED performs the required protected- state transition, commits the corresponding validation evidence, and releases a Sandbox Egress Capability bound to the validated request and network-egress Finality Sink. The host egress interface verifies the capability against the actual request presented for transmission and the required current authorization state. If verification succeeds, the host egress interface transmits the authorized request. If the request method, destination, required request content, policy state, nonce, capability state, or other mandatory bound parameter differs from the authorized conditions, the interface refuses transmission unless renewed protected validation succeeds. The source sandbox cannot independently open an alternative external connection, and the protected egress authority cannot be replaced by an agent-controlled software approval. Das Expires 19 April 2027 [Page 131] Internet-Draft Protected AI Execution Finality October 2026 This example illustrates one implementation. Other governed effectuation interfaces may employ the same protected causal sequence with operation-specific descriptors and capability-verification mechanisms. 11.1.20. WF-01.20 — Failure, Timeout, and Denial Handling The protected execution-finality workflow operates fail-closed. A Candidate Act is not permitted to become effective when: (a) descriptor construction fails; (b) a required Authority Object is missing or invalid; (c) a mandatory authorization predicate fails; (d) protected state is unavailable or inconsistent; (e) a required protected-state update fails; (f) validation evidence cannot be committed; (g) the required capability cannot be released; (h) capability authentication fails; (i) the actual operation does not match the authorized scope; (j) required nonce, expiry, revocation, or policy conditions fail; (k) required usage state is exhausted or already consumed; or (l) Finality Sink verification cannot be established. Depending upon the applicable embodiment, the operation may be denied, retained in a pending state, quarantined, escalated for review, or directed to an independently authorized recovery procedure. Where an operation has already produced an external effect, subsequent denial cannot retroactively prevent that effect. An interrupted or indeterminate operation is not automatically reissued merely because a previous attempt timed out. Das Expires 19 April 2027 [Page 132] Internet-Draft Protected AI Execution Finality October 2026 11.1.21. WF-01.21 — Concurrency, Crash Recovery, and Duplicate-Effect Handling Where multiple Candidate Acts compete for shared protected authorization state, the PED performs the required state checks and updates with synchronization appropriate to the specified guarantees. Protected transactions may use atomic compare-and-swap operations, transaction isolation, monotonic counters, authenticated state machines, protected locks, or equivalent mechanisms. If processing fails before protected evidence commitment, no corresponding valid capability is released. If processing fails after evidence commitment but before capability delivery, the protected system determines the committed authorization state before deciding whether to return, retire, or regenerate an associated capability. If processing fails after the Finality Sink begins external effectuation, the system distinguishes an operation known to be incomplete from an operation whose completion status is unknown. Where the external interface supports transaction identifiers, idempotency keys, or completion queries, those mechanisms may support reconciliation. Where the external interface cannot establish whether an effect occurred, automatic replay is withheld unless the applicable protected recovery procedure establishes the required duplicate- effect prevention condition. This procedure does not assert unconditional exactly-once completion across arbitrary external systems. 11.1.22. WF-01.22 — Alternative Structural Implementations The described workflow may be implemented through different protected enforcement substrates. Single-node implementation: A protected controller, gateway, chip, or AI-serving node performs descriptor validation, protected-state handling, validation-evidence commitment, capability availability, and local Finality Sink verification. Separated implementation: A protected authority component performs validation and capability issuance, while a separate effectuation component verifies the capability before acting. Das Expires 19 April 2027 [Page 133] Internet-Draft Protected AI Execution Finality October 2026 Hardware-rooted implementation: A TEE, HSM, secure enclave, protected processor, SmartNIC, DPU, FPGA, ASIC, or corresponding hardware- controlled interface enforces the required protected state and capability-dependent effectuation conditions. Software-isolated implementation: A protected software or hypervisor- controlled arrangement implements the corresponding logical sequence within the security limitations of that enforcement substrate. Distributed implementation: Multiple protected components participate in authority, state, evidence, or sink verification, while the required protected authorization relationships are preserved through authenticated communication and state-consistency controls. These implementations need not provide identical resistance to privileged compromise, rollback, physical attack, or distributed failure. An embodiment expressly requiring hardware-rooted, cryptographically isolated, rollback-resistant, or threshold-distributed guarantees includes the additional mechanisms necessary to establish those properties. 11.1.23. WF-01.23 — Technical Result The workflow establishes a protected dependency between: (a) generation of a Candidate Act; (b) interception and Non-Effective State; (c) machine-verifiable descriptor binding; (d) protected authority-predicate validation; (e) required protected-state handling; (f) protected validation-evidence commitment; (g) scoped non-bearer execution-capability availability; (h) Finality Sink verification; and (i) controlled external effectuation. Das Expires 19 April 2027 [Page 134] Internet-Draft Protected AI Execution Finality October 2026 The resulting technical arrangement prevents the governed effectuation interface from treating agent computation, ordinary approval, request possession, or an upstream allow decision as sufficient execution authority. The architecture is defined by the required protected causal relationship rather than by the brand, operating system, processor architecture, cryptographic algorithm, cloud platform, or physical placement of its components. Computation is not authority to act. 11.2. WF-02 — Protected AI-Agent Sandbox Isolation, Mandatory Interception, and Host Egress Enforcement 11.2.1. WF-02.1 — Technical Purpose This embodiment provides a protected execution-finality system for governing operations initiated by an artificial-intelligence agent, agentic workflow, autonomous tool, or associated computational process executing within a sandboxed environment. The system prevents a governed operation from becoming effective at a host-system, network, file-system, application, credential, or other consequential interface unless the applicable Protected Enforcement Domain (PED) has validated the operation, established required protected validation evidence, and released a scoped Sandbox Egress Capability that is subsequently verified by the applicable Finality Sink. The sandbox may execute instructions, prepare requests, manipulate temporary data, generate commands, and perform other computation. Such activity does not independently confer authority to cross the governed execution-finality boundary. The embodiment is not limited to one operating system, container runtime, hypervisor, processor architecture, network protocol, or security-substrate implementation. 11.2.2. WF-02.2 — Participating Components In one non-limiting implementation, the system comprises: SE-201 — Sandboxed Execution Environment: An isolated agent runtime comprising a container, virtual machine, restricted process, tool runtime, browser automation runtime, notebook, serverless function, or equivalent environment. Das Expires 19 April 2027 [Page 135] Internet-Draft Protected AI Execution Finality October 2026 IM-202 — Interception and Mediation Component: A protected or enforcement-controlled mechanism receiving or intercepting governed operations before those operations produce host or external effects. HQ-203 — Non-Effective Holding Queue: A controlled staging facility maintaining intercepted operations or immutable representations thereof pending protected authorization. DC-204 — Descriptor Construction Component: A component responsible for constructing or validating a machine-verifiable Candidate Sandbox Egress Act Descriptor. PED-205 — Protected Enforcement Domain: A protected authority environment responsible for the applicable authorization predicates, protected-state handling, validation-evidence commitment, and scoped capability-release control. AS-206 — Protected Authorization-State Store: A protected mechanism storing applicable policy versions, authority references, nonce state, revocation state, usage conditions, validation commitments, and other required authorization state. EV-207 — Egress Validation-Evidence Component: A mechanism generating or committing an Egress LAVR, ZK-LAVR, or other protected validation evidence. CR-208 — Sandbox Egress Capability Mechanism: A component generating, deriving, registering, or releasing the scoped non-bearer capability required by the applicable egress operation. FS-209 — Host Finality Sink: An enforcement component that independently verifies the required capability before allowing the operation to produce its governed consequence. EF-210 — Effectuation Interface: The controlled host, network, file- system, tool-execution, credential, application, or other interface through which an authorized operation becomes effective. A component may perform more than one described function. The PED, Finality Gate, and Finality Sink are distinguishable functional roles and need not comprise physically separate devices. 11.2.3. WF-02.3 — Establishment of the Sandbox Trust Boundary Before governed operations are processed, SE-201 is configured to restrict direct access to the effectuation interfaces assigned to FS- 209. Das Expires 19 April 2027 [Page 136] Internet-Draft Protected AI Execution Finality October 2026 A non-limiting Linux implementation may employ: (a) user and mount namespaces; (b) a separate network namespace; (c) restricted filesystem mounts; (d) removal of unnecessary operating-system capabilities; (e) seccomp-based syscall restrictions or user-notification mediation; (f) a kernel security module, eBPF-based enforcement where suitable, or an operating-system policy broker; (g) restricted host-device access; (h) an authenticated host broker interface; and (i) a separately protected authority service. The sandbox is not provisioned with unrestricted host execution privileges, protected capability-signing keys, or unmediated access to governed host resources. The exact mechanisms depend upon the operating system and threat model. For a virtual-machine implementation, equivalent restrictions may be applied through a hypervisor-controlled device interface, virtual network switch, protected virtual-device queue, or isolated host- service broker. For a cloud implementation, equivalent controls may be implemented through a workload sandbox, network policy enforcement point, protected gateway, or service-mesh infrastructure, subject to the required bypass-prevention guarantees. 11.2.4. WF-02.4 — Identification of Governed Effectuation Paths Before enabling the sandbox, the system identifies the interfaces through which the agent can cause a governed consequential effect. A representative interface registry contains: The registry associates each governed operation class with the mechanism that prevents unverified effectuation. Das Expires 19 April 2027 [Page 137] Internet-Draft Protected AI Execution Finality October 2026 The system is configured so that an agent cannot bypass the registered enforcement path by selecting an alternative command, process, device, communication channel, or execution interface capable of producing the same governed effect. The implementation must verify its actual effectuation-path coverage. Merely maintaining a registry does not make an otherwise accessible interface non-bypassable. 11.2.5. WF-02.5 — Mandatory Mediation and Path-Coverage Condition Let: E denote the set of governed effectuation interfaces; P(e) denote the set of execution paths accessible to the sandbox that can reach a particular interface e; F(p) denote the required Finality Sink or protected finality- verification mechanism governing path p. The mandatory path-coverage condition is: For every e in E, and for every sandbox-accessible p in P(e), the governed effect may occur only after the applicable F(p) has successfully verified the required execution authority. This condition is evaluated within the defined trust model of the particular implementation. For example, routing HTTP traffic through an egress proxy is insufficient if the sandbox retains an unrestricted raw-network interface through which the same transmission may occur. Likewise, wrapping shell commands is insufficient if the sandbox can invoke an unrestricted alternative host-execution interface. In one implementation, alternative effectuation paths are removed. In another implementation, all permitted effectuation paths are mediated by the corresponding protected Finality Sink. 11.2.6. WF-02.6 — Agent Operation Generation An artificial-intelligence agent executes within SE-201 and generates a proposed operation. The operation may comprise: Das Expires 19 April 2027 [Page 138] Internet-Draft Protected AI Execution Finality October 2026 (a) a shell command; (b) a host process-launch request; (c) an application programming interface request; (d) a network transmission; (e) a persistent file modification; (f) a package installation; (g) a browser action; (h) a credential request; or (i) another governed host or external operation. The generated operation is classified as Candidate Sandbox Egress Act CA-211. Generation, formatting, or submission of CA-211 does not authorize it to cross the applicable effectuation boundary. 11.2.7. WF-02.7 — Interception Before Effectuation IM-202 intercepts CA-211 before the governed effect occurs. The interception mechanism may be implemented using one or more of: (a) a container-runtime hook; (b) a hypervisor trap; (c) an operating-system policy broker; (d) a kernel broker; (e) a seccomp filter or supported user-notification mechanism; (f) an eBPF-based enforcement component; (g) a file-system policy module; (h) a shell execution wrapper combined with mandatory host process mediation; (i) a browser automation controller; Das Expires 19 April 2027 [Page 139] Internet-Draft Protected AI Execution Finality October 2026 (j) a network-egress proxy; or (k) an API gateway. A syscall filter or kernel event hook may identify or block an operation without understanding its full application-level contents. Where authorization requires an HTTP method, application path, message body, or other higher-layer field, those fields are obtained through an appropriate trusted application-level broker or controlled protocol-processing component. For encrypted traffic, such inspection requires permitted decryption, trusted endpoint cooperation, or another technically suitable mechanism. A kernel-level packet hook alone is not assumed to reveal encrypted application content. 11.2.8. WF-02.8 — Non-Effective Staging and Immutable Request Representation Following interception, IM-202 places CA-211 into HQ-203. The operation is assigned an operation identifier and remains in a Non-Effective State. An illustrative operation record comprises: operation_id agent_identity sandbox_identity operation_class request_reference target_interface policy_epoch state_version status = PENDING created_at Das Expires 19 April 2027 [Page 140] Internet-Draft Protected AI Execution Finality October 2026 For operations containing mutable buffers, request bodies, command arguments, or file content, the mediation component may copy the effectuation-relevant material into a controlled staging buffer or create a verified immutable representation. The actual operation later presented for effectuation is checked against the protected authorization commitment. This prevents a requesting process from validating one operation and substituting materially different parameters between validation and execution. The implementation may retain large payloads outside PED-205, provided the relevant payload identity and integrity are bound to the authorization record and verified at effectuation. 11.2.9. WF-02.9 — Candidate Sandbox Egress Act Descriptor DC-204 constructs or validates a Candidate Sandbox Egress Act Descriptor. The descriptor may comprise: agent identity; sandbox identity; host identity; operation class; executable identity or command digest; command parameters; target file path or resource; network destination; API endpoint; credential scope; browser action; package identity; input provenance; Das Expires 19 April 2027 [Page 141] Internet-Draft Protected AI Execution Finality October 2026 tool identity; risk class; policy epoch; nonce; expiry; and Finality Sink identity. Where exact operation binding is required, the descriptor includes or securely references the effectuation-relevant parameters necessary to distinguish authorized from unauthorized operations. The descriptor may be canonicalized using a deterministic encoding procedure. For an illustrative implementation: D = Canonicalize(ID, OP, TARGET, PARAM, CONTEXT, EPOCH, SINK) where: D means the canonical Candidate Sandbox Egress Act Descriptor; ID means the requesting agent, sandbox, or workload identity; OP means the proposed operation class; TARGET means the intended destination or resource; PARAM means the operation parameters required for authorization; CONTEXT means the applicable runtime context; EPOCH means the required policy or authorization-state version; SINK means the designated Finality Sink identity. Only the fields mandated by the particular Authority Object and embodiment must participate in the corresponding binding. 11.2.10. WF-02.10 — Retrieval of Sandbox Egress Authority Object PED-205 obtains an applicable Sandbox Egress Authority Object from an authenticated authority source or protected state reference. Das Expires 19 April 2027 [Page 142] Internet-Draft Protected AI Execution Finality October 2026 The Authority Object identifies the permissions and restrictions applicable to CA-211. A non-limiting Authority Object may specify: (a) permitted sandbox or workload identities; (b) permitted command classes; (c) authorized destinations; (d) permitted file or resource scopes; (e) allowed tool and API classes; (f) applicable credential scopes; (g) permitted execution purpose; (h) required approval conditions; (i) applicable runtime or provenance restrictions; (j) quota and usage conditions; (k) policy epoch and revocation conditions; and (l) capability scope and validity restrictions. PED-205 verifies the Authority Object according to the required authentication and protected-state rules. The requesting agent cannot create execution authority merely by supplying an unauthorized policy statement or a self-signed approval artifact. 11.2.11. WF-02.11 — Protected Authorization-Predicate Validation PED-205 evaluates the Candidate Sandbox Egress Act against its applicable Authority Object and protected authorization state. The predicates may include: Purpose validation: Whether the proposed operation remains within the authorized sandbox purpose or applicable AIF envelope. Das Expires 19 April 2027 [Page 143] Internet-Draft Protected AI Execution Finality October 2026 Logic validation: Whether the operation corresponds to an approved ALF, container image, workflow, tool graph, command policy, or equivalent logic condition. Behavioral validation: Whether an applicable RBD or provenance record satisfies the required runtime-behavior conditions. Destination validation: Whether the requested target, resource, endpoint, or route remains within the permitted scope. Credential-scope validation: Whether any requested credential- mediated authority is permitted for the proposed operation. Policy validation: Whether the current required policy epoch and revocation conditions are satisfied. Freshness validation: Whether applicable nonce, expiry, sequence, or capability-use conditions are valid. Human authorization: Whether an authenticated, act-bound human approval is present when required. For a conjunctive predicate set: V = P1 AND P2 AND ... AND Pn where: V denotes the overall protected validation result; P1 through Pn denote the mandatory predicates selected for the particular Candidate Act; n denotes the number of mandatory predicates. V is true only if all required predicates succeed. Where alternative predicates or an approved quorum are permitted, their combination is evaluated according to the corresponding protected policy. ALF, AIF, and RBD evaluation are mandatory only when required under the specified enforcement profile or embodiment. 11.2.12. WF-02.12 — Protected Grant-State and Freshness Handling Upon successful predicate validation, PED-205 performs the protected- state operations required for CA-211. Das Expires 19 April 2027 [Page 144] Internet-Draft Protected AI Execution Finality October 2026 Such operations may include: (a) verifying the current policy epoch; (b) checking revocation state; (c) reserving or consuming an authorization nonce; (d) decrementing an applicable operation quota; (e) registering an operation-specific authorization grant; (f) recording a capability-use limit; (g) updating a protected receipt-chain state; or (h) performing another required protected authorization transition. Where an authorization permits only one consequential effect, the relevant protected-state transition is coordinated to prevent concurrent operations from independently consuming the same authorization. Where state consistency cannot be established, the system does not treat the transaction as successfully authorized. 11.2.13. WF-02.13 — Egress Validation-Evidence Commitment EV-207 generates or commits the Protected Validation Evidence required for CA-211. The evidence may comprise an Egress LAVR, ZK-LAVR, sealed validation record, authenticated state commitment, or another supported protected representation. An illustrative evidence record identifies: operation identifier; Candidate Act Descriptor digest; applicable Authority Object reference; validated predicate-set reference; protected-state transition; decision result; Das Expires 19 April 2027 [Page 145] Internet-Draft Protected AI Execution Finality October 2026 policy epoch; nonce or freshness state; designated Finality Sink; and protected authentication information. Where the corresponding claim requires pre-effectuation evidence commitment, the required evidence is committed before, or atomically with, capability availability. A conventional log generated only after host execution does not substitute for that protected dependency. The evidence may remain inside the PED or a protected state store and need not be immediately exported to an external ledger. 11.2.14. WF-02.14 — Sandbox Egress Capability Issuance Upon completion of the required protected finality transaction, CR-208 releases or makes available a scoped, non-bearer Sandbox Egress Capability. The capability may comprise: (a) an authenticated capability object; (b) a protected execution handle; (c) a sealed capability reference; (d) a signed operation permit; (e) a MAC-authenticated authorization artifact; (f) a protected capability-table entry; or (g) a hardware-controlled enablement condition. Where required by the embodiment, the capability is bound to: Candidate Act Descriptor; operation class; requester or sandbox identity; Das Expires 19 April 2027 [Page 146] Internet-Draft Protected AI Execution Finality October 2026 authorized destination; permitted scope; validation-evidence commitment; policy epoch; protected usage state; nonce or expiry; and Finality Sink identity. A capability is not regarded as non-bearer merely because it has a signature. The applicable Finality Sink must enforce the required scope, context, state, and other non-bearer verification conditions. 11.2.15. WF-02.15 — Independent Host Finality Sink Verification FS-209 receives the staged Candidate Act or a broker-controlled representation of the operation and obtains the applicable execution capability. Before effectuation, FS-209 verifies: (a) capability authenticity; (b) correspondence to CA-211 or its authorized operation class; (c) the requesting sandbox or execution-context binding; (d) the operation parameters required by the authorization; (e) the permitted destination or resource; (f) Finality Sink identity; (g) applicable policy and revocation state; (h) nonce, expiry, and protected usage restrictions; and (i) required validation-evidence commitment. A verification condition may be represented as: PERMIT = AUTH(C) AND MATCH(C, D_actual) AND SCOPE(C, F) AND STATE(C, S_current) Das Expires 19 April 2027 [Page 147] Internet-Draft Protected AI Execution Finality October 2026 where: C means the Sandbox Egress Capability; D_actual means the actual effectuation-relevant descriptor presented at the host interface; F means the applicable Finality Sink; S_current means the protected authorization state required at verification time; AUTH verifies required capability authenticity; MATCH verifies exact correspondence or applicable bounded-scope matching; SCOPE verifies the permitted operation and Finality Sink; STATE verifies required policy, revocation, freshness, receipt, and consumption conditions. The host operation is permitted only when PERMIT is true. 11.2.16. WF-02.16 — Host Shell and Executable-Specific Enforcement In one implementation, host-executable operations are mediated by a protected process-launch broker. The sandbox submits a structured command request comprising an executable identifier, argument vector, permitted environment, working directory, requested resources, and target host-execution context. The broker resolves the executable against the permitted executable identity or approved command class. Where exact executable binding is required, authorization may cover an authenticated executable digest, file identity, version, or other measured execution artifact. The requested arguments, environment variables, executable path, interpreter use, and target resources are validated according to the applicable Authority Object. The host process-launch interface verifies the corresponding Sandbox Egress Capability before invoking the controlled executable. Das Expires 19 April 2027 [Page 148] Internet-Draft Protected AI Execution Finality October 2026 A shell wrapper may prepare or submit the command but does not alone constitute mandatory enforcement when an alternative host-execution path remains accessible. Where shell interpretation is authorized, the effectuation-relevant command representation is captured and checked according to its actual execution semantics, rather than assuming that a displayed command string always identifies the executable operations that will result. 11.2.17. WF-02.17 — Persistent File and Host-State Mutation Enforcement In one implementation, the sandbox submits a proposed persistent-file operation to an enforcement-controlled file broker. The operation descriptor identifies the requested file operation, authorized resource scope, relevant content digest where required, and intended effectuation boundary. A proposed write may be staged in temporary storage that cannot modify the protected host target directly. The broker validates the operation and obtains the corresponding capability. Before the persistent effect, the Finality Sink verifies the capability against the actual destination and content or operation parameters required by the authorization. Where path substitution or filesystem races are relevant, the broker may use controlled directory handles, resolved file identities, protected filesystem operations, or equivalent mechanisms to prevent a path from changing to an unauthorized target between checking and use. For a staged replacement, the broker may use a controlled commit operation to move validated content into the authorized persistent target. If the requested target, content digest, authorization state, or other mandatory binding fails, the file operation is refused. The implementation also mediates alternative persistent-state mutation paths that would otherwise bypass the controlled broker. Das Expires 19 April 2027 [Page 149] Internet-Draft Protected AI Execution Finality October 2026 11.2.18. WF-02.18 — Network and API Egress Enforcement In a network-egress embodiment, the sandbox lacks direct access to unrestricted external network transmission. A controlled network broker or egress proxy receives the proposed transmission. The descriptor identifies the requesting workload, destination, permitted network or API operation, applicable route, policy state, and any required request parameters. PED-205 validates the proposed operation and establishes the corresponding protected evidence and Sandbox Egress Capability. Before forwarding, the egress Finality Sink verifies the capability against the actual request. Where destination or application-level fields are mandatory, the Finality Sink verifies those fields using a technically appropriate representation of the request. A destination change, redirect, connection reuse, or changed routing target is not accepted when it violates a required authorization binding. Detailed hostname, address-resolution, redirect-chain and endpoint- consistency alternatives are described further in Workflow WF-03. 11.2.19. WF-02.19 — Credential and Connector Boundary Where the Candidate Sandbox Egress Act requires credential-mediated authority, the sandbox may submit a protected credential-use request rather than obtaining unrestricted access to the underlying credential. The credential broker or connector interface verifies the applicable Sandbox Egress Capability before performing the credential-mediated consequential operation. Where the embodiment requires a separate credential-release or credential-effectuation Finality Sink, that interface verifies the operation-specific authority before applying the protected credential. The requesting agent's knowledge of a credential reference, connector name, service endpoint, or earlier approval does not independently authorize the credential-mediated effect. Das Expires 19 April 2027 [Page 150] Internet-Draft Protected AI Execution Finality October 2026 Detailed grant-state consumption, surrogate-reference substitution, credential protection, and privileged-connector implementations are described in WF-04 and WF-05. 11.2.20. WF-02.20 — Continuous Sandbox Egress and Micro-Receipts For a continuing sandbox session, the protected system may maintain a sequence of authorized egress operations rather than granting unrestricted authority for the entire session. Each governed command, API request, network transmission, or file operation may require a corresponding validation event and micro-LAVR or protected receipt-chain update. Let: R0 denote the initial protected receipt-chain state; Di denote the descriptor for operation i; Vi denote the protected validation result for operation i; Ri denote the protected receipt-chain state after operation i; H denote a cryptographic hash function; || denote concatenation of deterministically encoded values. An illustrative update is: Ri = H(R(i−1) || Di || Vi || Si) where Si denotes the required protected-state commitment associated with operation i. This expression represents a possible hash-linked receipt-chain implementation, not a mandatory format. When an applicable runtime-behavior or authority predicate fails, PED-205 withholds the next required Sandbox Egress Capability. Previously authorized effects are not retroactively undone, but subsequent unverified operations remain non-effective. 11.2.21. WF-02.21 — Runtime Drift, Revocation, and Policy Updates During an ongoing agent session, the applicable authorization conditions may change. Das Expires 19 April 2027 [Page 151] Internet-Draft Protected AI Execution Finality October 2026 A policy update, revocation event, exhausted quota, detected runtime- behavior deviation, invalidated tool class, or other required state transition may invalidate further capability use. PED-205 updates or consults the corresponding protected authorization state. Where required, the Finality Sink checks the current policy epoch, revocation state, and capability-consumption information before effectuation. A capability issued under a superseded authorization condition does not authorize a later operation where the changed condition is mandatory. An agent-proposed policy expansion does not independently change the protected policy. Such an expansion may constitute a separate Candidate Self-Mutation Act governed through WF-09. 11.2.22. WF-02.22 — Failure and Containment Handling The workflow operates fail-closed for mandatory protected authorization conditions. Failure conditions include: (a) unavailable interception service; (b) inability to hold the operation before effectuation; (c) invalid Candidate Act Descriptor; (d) missing or invalid Sandbox Egress Authority Object; (e) failed purpose or scope validation; (f) invalid provenance or runtime condition where required; (g) stale policy or revocation state; (h) failed protected-state transition; (i) failed validation-evidence commitment; (j) invalid or missing Sandbox Egress Capability; (k) Finality Sink identity mismatch; Das Expires 19 April 2027 [Page 152] Internet-Draft Protected AI Execution Finality October 2026 (l) operation substitution; or (m) failed required capability verification. The resulting response may comprise denial, continued staging, quarantine, simulation without the governed external effect, or an authorized escalation procedure. A human-review decision, denial log, or quarantine state does not independently release execution authority. If an operation has already produced a consequential effect, later quarantine prevents only subsequent governed effects; it does not erase or retroactively prevent the earlier effect. 11.2.23. WF-02.23 — Crash, Retry, and Capability-Reuse Handling Where a broker, sandbox, PED, or Finality Sink crashes before authorization completes, the pending operation remains subject to the required protected validation conditions. Where the protected evidence or capability state was already committed, the system consults the corresponding operation identifier, protected usage state, and completion status before deciding whether another execution attempt is permitted. A previously consumed single-use capability cannot authorize another effectuation. An operation having indeterminate completion status is not automatically replayed where such replay could cause an unauthorized duplicate external effect. Where supported by the external interface, idempotency keys, transaction identifiers, completion queries, or protected reconciliation procedures may be used. The particular embodiment determines the actual recovery guarantee. 11.2.24. WF-02.24 — Alternative Enforcement Implementations The disclosed functional sequence may be implemented through the following non-limiting alternatives. Container-based implementation: A restricted container executes the agent, while an enforcement-controlled host broker intercepts governed operations and cooperates with a protected authority and host Finality Sink. Das Expires 19 April 2027 [Page 153] Internet-Draft Protected AI Execution Finality October 2026 Hypervisor-based implementation: A virtual machine executes the agent, while a hypervisor-controlled device or service interface mediates governed effectuation requests. Kernel-mediated implementation: Operating-system policy mechanisms, syscall mediation, filesystem controls, and protected execution brokers enforce the applicable host boundaries. Proxy-based implementation: Governed network and service requests are directed through an enforcement-controlled proxy or gateway that verifies required capability bindings before forwarding. Hardware-assisted implementation: A SmartNIC, DPU, protected host controller, secure processor, or hardware-controlled interface prevents governed output until the required bounded capability condition is verified. Single-node implementation: A protected host or controller performs interception, validation, protected-state handling, evidence commitment, capability generation, and local Finality Sink verification within one protected node. Distributed implementation: A remotely located PED releases an authenticated capability that is verified by a separate host Finality Sink. The implementation substrate determines the strength of protection against privileged software, hypervisor compromise, hardware tampering, rollback, and other threats. A software-only mechanism does not automatically possess hardware- rooted security guarantees. 11.2.25. WF-02.25 — Technical Verification and Test Conditions A person having ordinary skill in the art may verify the described workflow through controlled tests including: Test A — Unauthorized destination: Submit an operation targeting a destination outside the permitted scope. The operation must not pass the governed Finality Sink. Test B — Changed operation: Validate one command or file operation, then present materially different required parameters. The Finality Sink must reject the mismatch. Das Expires 19 April 2027 [Page 154] Internet-Draft Protected AI Execution Finality October 2026 Test C — Missing capability: Present a governed operation without the required Sandbox Egress Capability. The effectuation interface must refuse it. Test D — Replay: Re-present a consumed single-use capability. The interface must reject use inconsistent with its protected consumption state. Test E — Policy revocation: Change a required policy or revocation state. Subsequent affected operations must fail unless reauthorized under valid current state. Test F — Alternative path: Attempt the same governed host effect through another accessible sandbox interface. The operation must remain mediated or be blocked. Test G — Concurrent requests: Submit concurrent operations using a single-use authorization state. The protected mechanism must prevent unauthorized duplicate consumption. Test H — Broker failure: Make the required interception or verification component unavailable. The corresponding governed effect must not become authorized through an unprotected fallback. Test I — Continuous session drift: Cause a required runtime authorization condition to become invalid during an ongoing session. Further affected egress capabilities must be withheld. These tests demonstrate the security properties of the implemented enforcement boundaries under the stated threat model. 11.2.26. WF-02.26 — Technical Effect The embodiment establishes a protected execution-finality relationship between the sandboxed Compute Plane and effect-capable host or external interfaces. The agent may compute, plan, prepare commands, request tools, or construct network operations, but cannot independently cause a governed effect through a controlled Finality Sink without satisfying the required authorization conditions. The protected relationship includes: (a) mandatory interception; (b) Non-Effective State staging; Das Expires 19 April 2027 [Page 155] Internet-Draft Protected AI Execution Finality October 2026 (c) Candidate Sandbox Egress Act Descriptor formation; (d) protected authority-predicate validation; (e) required protected-state handling; (f) Egress LAVR, ZK-LAVR, or equivalent protected evidence commitment; (g) scoped Sandbox Egress Capability availability; (h) independent Finality Sink verification; and (i) controlled effectuation or fail-closed withholding. The resulting architecture governs the transition from agent computation to host or external effectuation, rather than relying exclusively upon sandbox membership, ordinary permissions, an upstream approval decision, or post-event logging. Computation is not authority to act. 11.3. WF-03 — Network Authorization, Canonical Requests, Destination Resolution, Redirect Consistency, and Executable-Specific Egress Control 11.3.1. WF-03.1 — Technical Purpose This embodiment describes a computer-implemented network execution- finality arrangement configured to control network transmissions, application programming interface requests, connector-mediated operations, service-to-service calls, and other externally effective network operations prepared or initiated by an artificial- intelligence agent or associated computational workload. The embodiment addresses circumstances in which an operation may be authorized for a particular executable, requesting workload, destination, network route, protocol, request method, resource path, or execution context, but the operation actually presented for effectuation differs from the authorized operation because of name resolution, destination substitution, redirection, connection reuse, process substitution, request mutation, or a change in protected authorization state. Das Expires 19 April 2027 [Page 156] Internet-Draft Protected AI Execution Finality October 2026 The architecture maintains the proposed operation in a Non-Effective State until the applicable Protected Enforcement Domain (PED) establishes the required authorization conditions, commits protected validation evidence, and releases or makes available a scoped, non- bearer execution capability. The corresponding network Finality Sink independently verifies the capability against the actual operation and the applicable current authorization state before allowing transmission, forwarding, connection establishment, or another defined network effect. A capability authorizing one network operation does not independently authorize a different operation or effectuation boundary. 11.3.2. WF-03.2 — Participating Technical Components In a non-limiting embodiment, the system comprises: NE-301 — Agent Network Execution Environment An agent, tool, browser, application, container, virtual machine, or other workload capable of preparing network operations. NI-302 — Network Interception Component A component configured to intercept a proposed network operation before the governed network effectuation boundary. HQ-303 — Network Holding Queue An enforcement-controlled staging mechanism maintaining a proposed network operation in a Non-Effective State. DC-304 — Network Descriptor Construction Component A mechanism for constructing and canonicalizing an effectuation- relevant network operation descriptor. DR-305 — Destination Resolution Component A DNS resolver, protected resolver interface, destination- classification service, service-discovery mechanism, or equivalent component configured to identify a destination or its permitted resolution results. PED-306 — Protected Enforcement Domain Das Expires 19 April 2027 [Page 157] Internet-Draft Protected AI Execution Finality October 2026 A protected component configured to authenticate the applicable authority, validate the operation, maintain or verify protected authorization state, commit required evidence, and control scoped capability availability. AS-307 — Protected Authorization-State Store A protected mechanism maintaining applicable policy epochs, revocation state, operation identifiers, usage state, freshness conditions, and authorization commitments. EV-308 — Protected Egress Evidence Component A mechanism configured to generate or commit an Egress LAVR, ZK-LAVR, authenticated validation record, or equivalent protected evidence. CR-309 — Network Capability Release Component A protected component configured to generate, register, or make available the required scoped Network Egress Capability or Sandbox Egress Capability. NF-310 — Network Finality Sink An enforcement-controlled network interface, socket broker, proxy, API gateway, service-mesh component, network-forwarding controller, SmartNIC, DPU, or equivalent interface performing required verification before the governed network effect. CE-311 — Connection Effectuation Component A controlled mechanism configured to establish or use an authorized network connection or perform another permitted transmission. RM-312 — Redirect and Route Consistency Monitor An optional component configured to identify destination changes, redirections, connection reuse, or route changes that affect mandatory authorization bindings. EI-313 — Executable Identity Verification Component An optional component configured to bind the requesting executable, tool, process, workload, or approved execution logic to the applicable network authorization. Das Expires 19 April 2027 [Page 158] Internet-Draft Protected AI Execution Finality October 2026 The described functions may be implemented within one protected node or distributed across multiple cooperating components. The Finality Sink may be integrated with the network broker or located at a separate controlled network or receiving-side boundary. 11.3.3. WF-03.3 — Establishment of the Controlled Network Path Before the agent begins governed execution, the system configures the network environment so that the agent cannot independently perform the governed network effect through an unrestricted alternative interface. In one illustrative Linux implementation, the agent executes in a separate network namespace having no direct unrestricted route to external networks. The namespace may communicate with an enforcement-controlled host broker through a designated local IPC interface, virtual network interface, proxy endpoint, or equivalent mechanism. The host or infrastructure enforces restrictions against alternative direct transmission through raw sockets, unrestricted host networking, unauthorized tunnels, or other accessible paths that could circumvent the designated Finality Sink. In another embodiment, the interception mechanism comprises a virtual-machine network device, hypervisor-controlled virtual switch, cloud network gateway, service-mesh egress controller, SmartNIC, or DPU. The protected network architecture identifies the interfaces that can cause the relevant external effect and ensures that those interfaces are governed. A conventional proxy configuration that the agent can disable or bypass does not, by itself, establish non-bypassable enforcement. 11.3.4. WF-03.4 — Candidate Network Act Generation The agent prepares a proposed network operation, which may comprise: (a) an HTTP or HTTPS request; (b) a REST, GraphQL, RPC, or other API invocation; (c) a service-to-service request; (d) a WebSocket or other persistent-session operation; Das Expires 19 April 2027 [Page 159] Internet-Draft Protected AI Execution Finality October 2026 (e) a credential-mediated connector request; (f) a file upload or download; (g) a package or dependency retrieval; (h) an outbound notification; (i) a database or message-bus request; (j) a model-service invocation; or (k) another operation that would cause a governed network consequence. The proposed operation is classified as Candidate Network Act CNA- 314, which may constitute a Candidate Sandbox Egress Act. CNA-314 remains non-effective pending the applicable protected authorization and Finality Sink verification. 11.3.5. WF-03.5 — Capture of the Actual Request Representation NI-302 intercepts CNA-314 before network effectuation. For an application-level request, the interception component may capture or construct a structured request containing: operation_id; requesting_workload; executable_identity; protocol; request_method; scheme; authority_host; destination_port; resource_path; query_parameters; Das Expires 19 April 2027 [Page 160] Internet-Draft Protected AI Execution Finality October 2026 request_headers; request_body_digest; credential_scope; policy_epoch; finality_sink_id. Fields not required by the applicable authorization are optional. The interceptor obtains effectuation-relevant parameters from a controlled representation of the request rather than relying solely on an untrusted descriptive string supplied by the agent. For example, an agent's statement that a request is directed to an approved service does not establish the destination actually used by the network effectuation component. Where the operation payload can change before transmission, the system uses a controlled staging buffer, immutable reference, authenticated content digest, or equivalent binding. 11.3.6. WF-03.6 — Canonical Network Operation Descriptor DC-304 constructs a canonical representation of the operation. One illustrative representation is: Dnet = Canon_v(ID, EXE, PROTO, HOST, PORT, METHOD, PATH, BODY, ROUTE, EPOCH, SINK) where: Dnet denotes the canonical network operation descriptor; Canon_v denotes deterministic canonical encoding under specified version v; ID denotes the authenticated requesting identity or workload context; EXE denotes the executable, tool, process, or approved execution- logic identity where required; PROTO denotes the network or application protocol; HOST denotes the intended destination hostname or service identity; Das Expires 19 April 2027 [Page 161] Internet-Draft Protected AI Execution Finality October 2026 PORT denotes the applicable destination port; METHOD denotes the requested application operation or HTTP method where relevant; PATH denotes the applicable resource path and authorized query scope; BODY denotes the required request-body identity, digest, or permitted content class; ROUTE denotes the authorized network or service route where applicable; EPOCH denotes the applicable protected policy or authorization-state version; SINK denotes the designated Finality Sink identity. The representation distinguishes absent fields from empty fields and includes unambiguous lengths, types, and encoding rules. Where exact request equality is required, the same canonicalization version and field interpretation are used by the protected authorization component and the Finality Sink. An illustrative descriptor commitment is: hnet = H("DAS-NET-v1" || Encode(Dnet)) where: hnet denotes the network descriptor digest; H denotes a cryptographic hash function; Encode denotes the specified deterministic byte encoding; || denotes concatenation; "DAS-NET-v1" denotes an illustrative domain-separation label. The particular encoding and cryptographic algorithms are implementation choices and are not mandatory for every embodiment. 11.3.7. WF-03.7 — Request-Normalization Rules The system establishes normalization rules appropriate to the governed protocol. Das Expires 19 April 2027 [Page 162] Internet-Draft Protected AI Execution Finality October 2026 For HTTP operations, such rules may address: (a) scheme representation; (b) hostname case normalization where appropriate; (c) Internationalized Domain Name encoding; (d) destination-port normalization; (e) percent-encoded path interpretation; (f) duplicate or ambiguous request-header interpretation; (g) conflicting message-length indicators; (h) HTTP authority and Host-header consistency; (i) query-parameter handling; (j) request-body identity; and (k) protocol version and upgrade semantics. Normalization must preserve distinctions that affect authorization or actual request meaning. The system must not treat two requests as equivalent merely because a textual normalization procedure makes their displayed forms appear similar. Where the proxy and downstream server can interpret an ambiguous request differently, the implementation either rejects the ambiguity or uses a shared, authoritative parse of the operation that is actually transmitted. The authorization representation is therefore bound to the protocol semantics enforced by the chosen Finality Sink. 11.3.8. WF-03.8 — Destination Classification and Resolution DR-305 obtains the destination information required by the applicable Authority Object. For a hostname-based request, the resolution component may obtain one or more IP addresses through an approved resolver or service- discovery mechanism. Das Expires 19 April 2027 [Page 163] Internet-Draft Protected AI Execution Finality October 2026 The resolution result may include: hostname; canonical service identity; resolved_addresses; address_family; destination_port; resolution_generation; resolution_validity; service_discovery_context. In one implementation, the network authorization service classifies resolved addresses into policy-defined categories, including permitted public addresses, private-network addresses, loopback addresses, link-local addresses, cloud-service endpoints, or other restricted destination classes. Where destination restrictions are specified, the corresponding network permission depends upon the actual resolved or selected destination satisfying those restrictions. A permitted public hostname does not automatically authorize transmission to a prohibited private-network endpoint. A hostname classification may be combined with IP-address classification, destination service identity, permitted route, authenticated server identity, or another verified destination attribute. 11.3.9. WF-03.9 — Resolution-Dependent Authorization In an embodiment requiring destination-resolution consistency, protected authorization is associated with the relevant resolution state. Let: R(h,t) denote the set of network addresses returned by the approved destination-resolution mechanism for hostname h at validation time t. Let: Das Expires 19 April 2027 [Page 164] Internet-Draft Protected AI Execution Finality October 2026 Allowed(ip,A) denote whether address ip satisfies the destination restrictions specified by Authority Object A. Let: ip_selected denote the destination network address actually selected for the connection. The corresponding destination predicate may be expressed as: Pdest = Allowed(ip_selected,A) AND ResolutionValid(ip_selected,R(h,t),A) where: Pdest denotes the destination-authorization predicate; Allowed checks applicable address-class, address-range, service, or destination restrictions; ResolutionValid checks that the selected destination satisfies the authorized resolution or service-discovery conditions. The policy may authorize an exact address, an approved address set, a defined service identity, a permitted destination class, or another bounded destination scope. The system does not require an exact IP-address match when a broader authorized service class is expressly permitted and adequately enforced. If the selected destination fails a mandatory destination predicate, the network operation remains non-effective. 11.3.10. WF-03.10 — DNS Rebinding and Address-Substitution Handling In a more specific implementation, the system protects against destination changes occurring between authorization and connection establishment. For example, a hostname may initially resolve to an authorized public address and subsequently resolve to a prohibited private or loopback address. If the system authorizes the original hostname but transmits to a newly selected prohibited address without rechecking the applicable destination predicate, the effective destination may differ from the authorized destination. Das Expires 19 April 2027 [Page 165] Internet-Draft Protected AI Execution Finality October 2026 To prevent such substitution, the enforcement-controlled connection component verifies the destination actually selected for connection against the required protected authorization binding. The verification may occur: (a) immediately before the connection attempt; (b) through a protected resolver-to-connection handoff; (c) through an authenticated destination-selection record; (d) through a policy-controlled connection broker; or (e) through another arrangement that ensures correspondence between the authorized and actual destination. A DNS response alone does not establish the identity of the connected peer. Where the policy additionally requires server authentication, the system validates the corresponding authenticated endpoint identity. Where address translation, tunneling, service discovery, or routing intermediaries affect destination identity, the binding is defined at the network boundary the implementation actually controls. An implementation does not assert visibility of a final remote destination that is hidden behind an untrusted intermediary. 11.3.11. WF-03.11 — Executable-Specific Network Authorization EI-313 may bind the network operation to an approved executable, tool, agent runtime, workload, or other execution component. The applicable executable identity may comprise: (a) an authenticated executable digest; (b) a measured executable image; (c) an approved package or software identity; (d) an approved runtime or container image; (e) a process identity linked to a protected launch event; (f) a signed executable identity; Das Expires 19 April 2027 [Page 166] Internet-Draft Protected AI Execution Finality October 2026 (g) an ALF representing approved logic or tool configuration; or (h) a combination of required execution measurements. An illustrative executable authorization predicate is: Pexe = ExecApproved(EXE,A) AND ContextMatches(ID,EXE,X) where: Pexe denotes executable-specific authorization; EXE denotes the verified executable or tool identity; A denotes the applicable Authority Object; ID denotes the authenticated requesting identity; X denotes the relevant runtime execution context; ExecApproved verifies that the executable or logic identity is authorized for the requested operation; ContextMatches verifies that the operation originates from the execution context associated with the authorized identity. A caller-provided process name or executable path alone is not sufficient when the applicable embodiment requires authenticated executable identity. In one implementation, the host broker obtains process identity and executable measurements through a trusted operating-system interface or protected launch record. The system may associate authorization with an opened executable object, measured process image, or authenticated workload identity to reduce executable substitution between checking and use. Interpreters, dynamically loaded code, scripts, plug-ins, or modified runtime state may require additional measurement or scope conditions where those elements affect the applicable authorization. 11.3.12. WF-03.12 — Combined Executable and Destination Scope A network permission may require correspondence among: (a) the requesting workload; Das Expires 19 April 2027 [Page 167] Internet-Draft Protected AI Execution Finality October 2026 (b) the executable or approved logic class; (c) the destination; (d) the permitted operation; (e) the protected authorization state; and (f) the designated Finality Sink. For example, one approved agent tool may be permitted to retrieve public documentation, while a separate credential-bearing connector may be permitted to communicate only with a particular authenticated service. The permission granted to the first tool does not independently authorize the second tool's credential-bearing operation. Where required, the Protected Enforcement Domain verifies the executable-to-destination relationship before releasing the corresponding capability. A capability bound to one executable identity cannot be reused by another executable when that identity forms part of the mandatory authorization binding. 11.3.13. WF-03.13 — Protected Authority Validation PED-306 receives or reconstructs the canonical Candidate Network Act Descriptor and obtains the applicable Network Egress Authority Object or Sandbox Egress Authority Object. The PED evaluates required predicates that may include: (a) requester identity; (b) executable or logic identity; (c) authorized purpose; (d) destination hostname or service identity; (e) actual permitted address class; (f) port and transport protocol; (g) HTTP method or applicable API operation class; Das Expires 19 April 2027 [Page 168] Internet-Draft Protected AI Execution Finality October 2026 (h) resource path and query scope; (i) authorized network route; (j) permitted credential scope; (k) ALF, AIF, or RBD conditions where required; (l) provenance or influence restrictions where required; (m) policy epoch; (n) revocation conditions; (o) nonce, expiry, and usage restrictions; and (p) authorized Finality Sink identity. For a conjunctive policy: Vnet = Pidentity AND Pexe AND Pdest AND Pop AND Pscope AND Pstate where: Vnet denotes the protected network authorization result; Pidentity denotes the required workload or requester identity check; Pexe denotes executable or approved-logic identity validation where mandatory; Pdest denotes the required destination validation; Pop denotes permitted operation-type and request-parameter validation; Pscope denotes the applicable purpose and authority-scope validation; Pstate denotes freshness, revocation, policy-version, and protected- state validation. Predicates not required by the particular embodiment may be omitted according to the applicable Authority Object. When a mandatory predicate fails, no valid capability is made available for the rejected network operation. Das Expires 19 April 2027 [Page 169] Internet-Draft Protected AI Execution Finality October 2026 11.3.14. WF-03.14 — Protected Grant-State and Evidence Commitment Upon successful validation, PED-306 performs the protected-state operation required for the network act. Such an operation may comprise authorization-grant reservation, nonce consumption, usage-counter update, capability-state registration, or another required protected transition. EV-308 generates or commits the corresponding protected validation evidence before, or atomically with, capability availability, according to the applicable embodiment. A non-limiting protected evidence record comprises: receipt_id; operation_id; descriptor_digest; authority_reference; validated_policy_epoch; destination_scope_reference; executable_identity_reference; protected_state_transition; finality_sink_id; validation_result; protected_authentication. The evidence may be committed as an Egress LAVR, ZK-LAVR, authenticated record, sealed commitment, or equivalent protected validation representation. An ordinary proxy access log created after transmission does not substitute for a required protected pre-effectuation evidence commitment. Das Expires 19 April 2027 [Page 170] Internet-Draft Protected AI Execution Finality October 2026 11.3.15. WF-03.15 — Scoped Network Egress Capability CR-309 generates, registers, or releases the scoped network execution capability after completion of the required protected authorization transaction. In an illustrative authenticated-capability implementation, the capability contains or securely references: capability_id; operation_descriptor_digest; requesting_workload_id; executable_scope; destination_scope; operation_scope; route_scope; policy_epoch; revocation_state_reference; nonce; expiry; usage_limit; validation_evidence_digest; finality_sink_id. The capability may be represented through a signed structure, MAC- authenticated structure, protected capability table, hardware- controlled forwarding entry, or other protected enablement mechanism. The capability is non-bearer when the applicable Finality Sink enforces the required correspondence between the capability and the actual operation, requesting context, protected state, permitted sink, and usage condition. Das Expires 19 April 2027 [Page 171] Internet-Draft Protected AI Execution Finality October 2026 Possession of the capability bytes by an unrelated process does not independently authorize a different operation if the required non- bearer predicates are enforced. 11.3.16. WF-03.16 — Verification Immediately Before Network Effectuation NF-310 receives the proposed network operation and the associated capability or capability reference. Before permitting the governed network effect, NF-310 determines the effectuation-relevant properties of the request actually presented. The Finality Sink verifies: (a) the capability authentication; (b) the actual requesting execution context; (c) the applicable executable identity; (d) the actual destination and required resolution state; (e) the application operation and parameters; (f) the permitted route where required; (g) the current mandatory protected authorization state; (h) the required validation-evidence commitment; (i) freshness and capability-consumption conditions; and (j) the designated Finality Sink identity. An illustrative verification expression is: PermitNetwork = Auth(C) AND Match(C,Dactual) AND DestinationValid(C,Tactual) AND StateValid(C,S) AND SinkValid(C,F) where: PermitNetwork denotes permission to perform the governed network effect; C denotes the scoped network capability; Dactual denotes the actual operation descriptor; Das Expires 19 April 2027 [Page 172] Internet-Draft Protected AI Execution Finality October 2026 Tactual denotes the effectuation-relevant actual destination or target identity; S denotes the required protected authorization state; F denotes the current network Finality Sink; Auth verifies capability authenticity; Match verifies exact descriptor equality or expressly authorized bounded-scope matching; DestinationValid verifies the required target, route, and destination restrictions; StateValid verifies mandatory freshness, revocation, policy, and usage state; SinkValid verifies that the capability authorizes the particular Finality Sink. The governed operation proceeds only if PermitNetwork is true. 11.3.17. WF-03.17 — Redirection and Multi-Hop Request Control Where a network operation can trigger an HTTP redirect, service- discovery change, API relocation, or another destination change, the system evaluates whether the resulting operation remains within the authorized scope. In one implementation, the controlled request executor disables automatic redirect following unless the redirect-handling component performs the required verification. A redirect response proposing a new URL or endpoint is treated as either: (a) a bounded continuation of the original authorized operation, where the original capability expressly permits that class of destination and operation change; or (b) a new Candidate Network Act requiring a new or updated protected authorization event. The redirect-handling component determines the destination, protocol, method, resource path, request body, and credential scope applicable to the subsequent operation. Das Expires 19 April 2027 [Page 173] Internet-Draft Protected AI Execution Finality October 2026 Where a redirect changes the required authorized destination, request method, recipient, or credential-bearing context, the changed operation does not proceed under an incompatible previous authorization. A redirect from an approved public endpoint to an unauthorized internal service, local interface, cloud metadata endpoint, or different service identity is refused unless the applicable protected authorization permits the actual target. Credentials are not forwarded to a redirected endpoint merely because the original destination was authorized. For multiple redirects, each resulting transmission must satisfy the applicable authorization and effectuation conditions. The design does not assume that redirect validation at the first request automatically authorizes an entire future redirect chain. 11.3.18. WF-03.18 — Connection Reuse, HTTP Multiplexing, and Session Binding In an embodiment supporting persistent connections, multiple requests may share an established TCP, TLS, HTTP/2, HTTP/3, QUIC, or equivalent transport session. The authorization of the original connection does not automatically authorize every application operation subsequently transmitted through that connection. Where operation-specific authorization is required, each governed request, stream, message, or bounded transfer unit is associated with the corresponding protected authorization condition. If the transport supports connection reuse across multiple service authorities, the system verifies that the actual operation remains within its authorized destination and service-identity scope. Where a session-bound capability is used, the capability may identify: session_id; authorized_service_identity; source_workload; permitted_operation_class; Das Expires 19 April 2027 [Page 174] Internet-Draft Protected AI Execution Finality October 2026 policy_epoch; session_freshness; finality_sink_id. An approved session may support multiple operations only to the extent expressly authorized by its protected usage, scope, and freshness conditions. If operation-specific validation is mandatory, an existing authenticated connection cannot substitute for the required per- operation capability check. 11.3.19. WF-03.19 — Encrypted Traffic and Application-Layer Visibility The network Finality Sink may operate at a transport layer, application layer, or combination of layers. A transport-level enforcement component may verify network addresses, ports, routing metadata, connection identity, and other information available at its enforcement point. An application-level broker may additionally verify HTTP methods, URL paths, decoded request parameters, request-body digests, or credential-mediated operations where such information is available through a trusted interface. For end-to-end encrypted traffic, a network component that does not terminate or otherwise legitimately access the encrypted application session cannot independently inspect the concealed application fields. Where those fields form mandatory authorization predicates, the system uses a trusted application-level request broker, controlled TLS endpoint, authenticated client-side request representation, receiving-side verifier, or another suitable enforcement arrangement. If the required fields cannot be verified, the corresponding operation is withheld rather than presumed valid. The use of HTTPS, TLS, QUIC, or another secure transport does not independently establish that the transmitted operation has obtained protected execution-finality authorization. Das Expires 19 April 2027 [Page 175] Internet-Draft Protected AI Execution Finality October 2026 11.3.20. WF-03.20 — Proxy, Service-Mesh, and Network-Hardware Alternatives In one implementation, NF-310 comprises an application-level egress proxy. The proxy retains or receives the actual network operation, verifies the scoped capability, and forwards only the corresponding authorized request. In a cloud-native implementation, the network Finality Sink may comprise a service-mesh sidecar, egress controller, ingress controller, API gateway, workload proxy, or corresponding service-to- service enforcement component. The capability may be bound to a source workload identity, destination service identity, authenticated transport session, route, policy epoch, nonce, and validation-evidence reference. In a hardware-assisted implementation, a SmartNIC or DPU enforces an authenticated, scoped forwarding grant before permitting the corresponding network transfer. A hardware component operating below the application layer may rely on a trusted broker's authenticated operation classification where application-specific checks are required. In a receiving-side implementation, an API gateway or protected downstream service may act as the Finality Sink for service invocation or resource commitment. A source-side network Finality Sink and a receiving-side operation Finality Sink may control different consequential boundaries. Authorization for packet transmission does not necessarily establish authorization for the receiving service to commit a transaction. 11.3.21. WF-03.21 — Time-of-Check and Time-of-Use Protection The architecture prevents unauthorized substitution between protected validation and the actual network effectuation event. Potential substitutions include: (a) hostname resolution changes; (b) destination address replacement; (c) executable replacement; Das Expires 19 April 2027 [Page 176] Internet-Draft Protected AI Execution Finality October 2026 (d) changed request method; (e) modified resource path; (f) altered request body; (g) replaced credential scope; (h) route substitution; (i) reuse of an authorized transport session for a different operation; or (j) change in required policy or revocation state. Where exact binding is required, the Finality Sink compares the actual effectuation-relevant state with the validated descriptor commitment. An implementation may use immutable request buffers, protected request identifiers, kernel-managed object handles, authenticated session references, operation-specific capability entries, and protected state versions to preserve correspondence. Where the operation changes materially after authorization, the previous capability is rejected or renewed validation is required. The Finality Sink does not rely solely on the fact that an upstream component previously reported an allow decision. 11.3.22. WF-03.22 — Continuous Network Egress and Rolling Authorization For a long-running agent session, the system may require successive network operations to undergo separate protected validation events. Each operation may produce a corresponding micro-LAVR or update a protected receipt-chain state. A stream or transfer may be divided into bounded units, such as messages, requests, chunks, connection windows, or protocol-defined operation phases. Where an embodiment uses a rolling capability, the capability is bound to a permitted transfer unit or window. Das Expires 19 April 2027 [Page 177] Internet-Draft Protected AI Execution Finality October 2026 If the required destination, operation, workload identity, route, policy, freshness, or runtime-behavior condition becomes invalid, the PED withholds the next required capability or the Finality Sink rejects the affected operation. A previously transmitted unit is not retroactively withdrawn merely because a subsequent unit fails authorization. Such streaming authorization does not require inspecting every transmitted byte when the applicable authorized unit and its verified bounds are otherwise enforced. 11.3.23. WF-03.23 — Protected Capability Consumption and Retry Handling Where a network operation is authorized for a bounded number of uses, NF-310 performs or coordinates the required protected usage-state verification. A representative state machine comprises: PENDING; AUTHORIZED; RESERVED; EFFECTUATION_ATTEMPTED; CONFIRMED_EFFECTIVE; DENIED; INDETERMINATE. An operation may transition from AUTHORIZED to RESERVED when its required capability state is consumed or reserved. The system prevents two concurrent operations from independently consuming the same single-use authorization. If the network connection fails before the governed operation is transmitted, the implementation may permit protected recovery according to the applicable state rules. If a request may have reached the remote service but no completion response is received, the implementation records the relevant uncertainty. Das Expires 19 April 2027 [Page 178] Internet-Draft Protected AI Execution Finality October 2026 A retry does not automatically receive a new independently reusable capability where duplicate effectuation would violate the authorized operation scope. Where a remote system supports authenticated idempotency identifiers, transaction-status queries, or receiving-side finality enforcement, those mechanisms may be employed for recovery. The network gateway cannot generally determine whether every arbitrary remote service has performed an irreversible operation merely from the local transmission result. 11.3.24. WF-03.24 — Failure and Fail-Closed Conditions The protected network Finality Sink refuses effectuation when a required condition cannot be verified. Non-limiting denial conditions include: (a) absent capability; (b) invalid capability authentication; (c) unauthorized requester; (d) executable or tool identity mismatch; (e) operation-class mismatch; (f) destination mismatch; (g) unauthorized address class; (h) unauthorized redirect; (i) invalid route binding; (j) request-method or path mismatch; (k) request-body substitution; (l) stale policy epoch; (m) invalid revocation condition; (n) expired or replayed nonce; (o) exhausted usage state; Das Expires 19 April 2027 [Page 179] Internet-Draft Protected AI Execution Finality October 2026 (p) validation-evidence mismatch; (q) unavailable required protected state; (r) Finality Sink mismatch; or (s) failure to establish the required canonical operation correspondence. The system may retain the Candidate Network Act in a Non-Effective State, deny it, quarantine it, or submit it for a separately authorized review procedure. An ordinary network failure or denial log does not independently release execution authority. 11.3.25. WF-03.25 — Illustrative End-to-End API Egress Implementation In one concrete embodiment, an AI agent executes within an isolated container and proposes an HTTPS POST request to an authorized enterprise service. The agent does not possess an unrestricted external network route. The request is submitted to NI-302 through an authenticated host broker interface. The interception component creates an operation identifier, retains the proposed request in a controlled holding queue, and constructs a canonical descriptor containing the requesting workload identity, executable identity, HTTPS protocol, authorized hostname, permitted destination port, POST method, resource path, request-body digest, policy epoch, and network Finality Sink identity. DR-305 resolves the destination through an approved resolver and identifies the candidate network addresses. The protected authorization system verifies the required hostname, address-class, executable, method, resource, purpose, scope, policy, and freshness predicates. Following successful validation, the PED performs the required protected-state operation and commits a corresponding Egress LAVR or equivalent protected validation record. The PED then makes available an operation-scoped Sandbox Egress Capability. Das Expires 19 April 2027 [Page 180] Internet-Draft Protected AI Execution Finality October 2026 The network Finality Sink reconstructs or verifies the actual request and determines the destination selected for connection. The Finality Sink verifies that the operation-specific capability is authentic, that the request matches the authorized descriptor, that the actual destination is permitted, and that the mandatory current state conditions remain valid. If verification succeeds, the controlled egress component forwards the authorized request. If the destination has changed to a prohibited address, the request parameters have been modified, the executable identity is inconsistent, or the policy state is invalid, the egress component refuses the operation. If the remote service returns a redirect, the redirect handler evaluates the resulting request against the original bounded authorization or submits the resulting operation for renewed protected validation. The agent cannot independently transmit the redirected request through an alternative uncontrolled network path. This example illustrates an application-level egress embodiment and may be adapted to other protocols or effectuation interfaces according to their available verification semantics. 11.3.26. WF-03.26 — PHOSITA Verification and Negative Tests A person having ordinary skill in operating-system security, network proxies, API gateways, distributed authorization, cloud networking, or protected execution systems may test the described arrangement through the following non-limiting cases. Test 1 — Exact authorized request: Submit a request whose actual executable, destination, operation, protected state, and required bindings match the capability. The Finality Sink permits the scoped operation. Test 2 — Executable substitution: Present the same request from a different executable where executable identity is mandatory. The request is refused. Test 3 — Destination substitution: Replace the authorized destination with a prohibited target after validation. The Finality Sink refuses transmission. Das Expires 19 April 2027 [Page 181] Internet-Draft Protected AI Execution Finality October 2026 Test 4 — DNS rebinding: Cause a hostname previously associated with an allowed address to resolve or connect to a prohibited address. The destination-consistency predicate fails. Test 5 — Unauthorized redirect: Return an HTTP redirect to a destination outside the permitted scope. The redirected operation is withheld. Test 6 — Method or path change: Change an authorized HTTP operation to another effectuation-relevant method or resource. The descriptor verification fails where that field is mandatory. Test 7 — Request-body substitution: Replace a payload whose digest formed part of the authorization. The actual-operation binding fails. Test 8 — Connection reuse: Reuse an authenticated connection for an operation outside the bound scope. The subsequent operation is refused. Test 9 — Capability replay: Re-present a consumed single-use capability. The protected usage condition fails. Test 10 — Policy revocation: Advance a required revocation or policy epoch. An affected capability bound to incompatible earlier state is rejected. Test 11 — Proxy bypass: Attempt direct network transmission from the sandbox through another available interface. The alternative path is blocked or subjected to equivalent required Finality Sink verification. Test 12 — Encrypted opaque request: Present an encrypted request whose mandatory application-level fields are not verifiable at the selected enforcement component. The system refuses the operation unless a suitable trusted verification path is available. Test 13 — Indeterminate remote completion: Interrupt a connection after possible request delivery and attempt replay. The protected recovery procedure prevents an unauthorized duplicate effect. Test 14 — Concurrent authorization use: Attempt simultaneous effectuation using a single-use grant. The protected consumption mechanism permits no more than the authorized usage count. Das Expires 19 April 2027 [Page 182] Internet-Draft Protected AI Execution Finality October 2026 The tests may be implemented using controlled sandbox workloads, programmable network destinations, test proxies, simulated DNS responses, mock downstream services, fault injection, and protected- state inspection. 11.3.27. WF-03.27 — Alternative Authorization Granularity The protected network architecture may operate at different authorization granularities according to the security requirement and effectuation semantics. Per-request authorization: Each governed API request or transmission requires its own scoped capability. Per-message authorization: Each externally effective message in a persistent communication channel is separately authorized. Per-session authorization: A capability authorizes a defined session and bounded operation class under specified validity, usage, and revocation conditions. Per-transfer-window authorization: A bounded stream segment or transfer window is authorized using a rolling capability and protected usage state. Per-service authorization: A capability permits specified operations involving an authenticated service identity and permitted operation scope. Per-receiving-operation authorization: A receiving-side Finality Sink verifies an operation-specific capability before performing a governed downstream commit or consequential action. An embodiment requiring independent authorization of each consequential operation does not treat an unrestricted session-level allow decision as equivalent to operation-specific finality. 11.3.28. WF-03.28 — Structural and Security Variations The described functions may be distributed among the same or different protected components. In a single-node implementation, an enforcement-controlled gateway may stage a request, obtain protected authorization, commit evidence, register a scoped capability, and verify that capability at its own controlled forwarding interface. Das Expires 19 April 2027 [Page 183] Internet-Draft Protected AI Execution Finality October 2026 In a separated implementation, a protected authority service performs validation and capability issuance while a network gateway independently verifies the capability before transmission. In a confidential-computing implementation, a protected virtual- machine or enclave component may perform part of the authorization or request verification, while a host or hardware network Finality Sink controls effectuation. In a hardware-assisted implementation, a SmartNIC, DPU, or protected network controller may enforce a bounded route or forwarding authorization. In a receiving-side implementation, a remote gateway or service may perform its own operation-specific Finality Sink verification before completing a protected downstream action. The choice of software, hardware, firmware, virtualized, or distributed enforcement substrate does not remove the requirement to demonstrate that the governed effectuation path is actually controlled. 11.3.29. WF-03.29 — Technical Effect The embodiment establishes a protected causal relationship between the actual network operation and the authority required for that operation to cross a governed network effectuation boundary. The relationship comprises: (a) interception of a proposed network operation; (b) maintenance in a Non-Effective State; (c) construction of an effectuation-relevant Candidate Act Descriptor; (d) validation of the applicable authority, executable, purpose, destination, route, operation, and protected-state predicates; (e) required protected-state handling; (f) protected validation-evidence commitment; (g) scoped non-bearer capability availability; (h) independent verification against the actual network operation at the applicable Finality Sink; and Das Expires 19 April 2027 [Page 184] Internet-Draft Protected AI Execution Finality October 2026 (i) controlled effectuation or fail-closed refusal. The architecture prevents an upstream request approval, executable permission, DNS lookup, established network connection, authenticated transport session, or agent-generated instruction from independently substituting for the protected operation-specific execution authority required at the governed Finality Sink. Computation is not authority to act. 11.4. WF-04 — Transaction-Bound Agent Authorization, Protected Grant- State Consumption, Credential Broker, and Atomic Credential Effectuation 11.4.1. WF-04.1 — Technical Purpose This embodiment provides a computer-implemented protected execution- finality system for controlling credential-mediated operations generated or requested by an artificial-intelligence agent, agentic workflow, autonomous application, or other computational workload. The embodiment prevents an agent from independently converting possession of a credential reference, surrogate credential, connector identifier, service endpoint, or previously granted permission into unrestricted authority to perform a consequential external operation. A proposed credential-mediated operation is represented as a Candidate Act maintained in a Non-Effective State. A protected authorization mechanism validates the exact or bounded operation, establishes the required protected grant-state transition, commits the required authorization evidence, and releases or makes available a scoped execution-enablement artifact. A separately controlled credential-effectuation component or Finality Sink verifies the authorization against the operation actually presented for effectuation before applying the protected credential. The architecture separates: (a) computation and preparation of the proposed operation; (b) authorization of that particular operation; (c) protected ownership and application of credential material; and (d) effectuation of the authorized consequence. Das Expires 19 April 2027 [Page 185] Internet-Draft Protected AI Execution Finality October 2026 Successful authentication of the agent or existence of an earlier service permission does not independently authorize every subsequent credential-mediated operation. 11.4.2. WF-04.2 — Participating Components A non-limiting implementation comprises: AE-401 — Agent Execution Environment An agent, workflow, tool runtime, container, virtual machine, application, browser automation environment, or other computational component configured to request credential-mediated operations. IM-402 — Operation Interception Component An enforcement-controlled interface configured to receive proposed credential-mediated operations before they become externally effective. HQ-403 — Non-Effective Operation Holding Mechanism A controlled queue, staging buffer, protected operation record, pending request object, or equivalent mechanism retaining proposed operations pending authorization. NC-404 — Operation Normalization Component A component configured to construct a canonical operation descriptor representing the requested consequential act and its effectuation- relevant parameters. PED-405 — Protected Enforcement Domain A protected authorization component configured to validate the applicable Authority Object, operation descriptor, authorization predicates, and protected state. GS-406 — Protected Grant-State Store A protected store maintaining operation-specific authorization grants, authorization-state versions, reservation conditions, consumption state, validity intervals, revocation conditions, and corresponding evidence commitments. EV-407 — Protected Validation-Evidence Component Das Expires 19 April 2027 [Page 186] Internet-Draft Protected AI Execution Finality October 2026 A component configured to generate or commit protected authorization evidence, including a LAVR, Egress LAVR, authenticated receipt, sealed finality record, or equivalent protected representation. CR-408 — Scoped Capability Release Component A protected component configured to release or make available an operation-scoped, non-bearer execution capability. CS-409 — Protected Credential Store A protected credential repository, hardware security module, secure enclave, secret-management service, operating-system credential service, or equivalent protected key or credential facility. CE-410 — Credential-Effectuation Component A credential broker, privileged connector, authenticated proxy, host worker, secure signing service, gateway, or equivalent component having controlled access to credential-mediated operations. VS-411 — Execution-Verification Component A mechanism configured to verify correspondence between the operation presented for effectuation, its canonical authorization descriptor, current grant state, and scoped execution capability. FS-412 — Credential or External-Operation Finality Sink An enforcement-controlled boundary at which the protected credential is applied, released for bounded use, or made capable of producing the governed external operation. OS-413 — Protected Outcome-State Component A component maintaining operation-specific completion, denial, reservation, uncertainty, and recovery information. The components may be integrated within one protected host, implemented within hardware or firmware, or distributed across authenticated execution environments. The protected credential store, execution verifier, and Finality Sink may be colocated where their required independent functional verification and protected control are preserved. Das Expires 19 April 2027 [Page 187] Internet-Draft Protected AI Execution Finality October 2026 11.4.3. WF-04.3 — Credential and Authorization Separation Before processing credential-mediated operations, the system establishes two distinguishable authorities. The first is authority to request or prepare a proposed operation. The second is protected authority to apply credential material or invoke a credential-mediated effectuation interface for a validated operation. An AI agent may know: (a) a connector name; (b) an authorized service category; (c) a non-authoritative credential reference; (d) an available API endpoint; (e) a permitted task description; or (f) a previously approved operation class. Such knowledge or possession does not independently confer unrestricted use of the protected credential. Protected credential material may comprise an OAuth access token, API credential, private signing key, client certificate, service-account credential, authentication assertion, payment authorization credential, cloud-service credential, or equivalent authorization material. The selected implementation controls both access to the credential and its actual use. 11.4.4. WF-04.4 — Establishment of Protected Credential Custody CS-409 maintains the reusable protected credential outside the execution authority controlled by AE-401. In one implementation, CS-409 comprises a host-side secret-management service protected by operating-system isolation and authenticated service interfaces. Das Expires 19 April 2027 [Page 188] Internet-Draft Protected AI Execution Finality October 2026 In another implementation, the credential is held within a hardware security module, secure enclave, protected virtual machine, or equivalent protected boundary. Where a credential is exportable, the system restricts its delivery to an authorized credential-effectuation component. Where the credential is non-exportable, the protected store may perform an authorized signing, encryption, authentication, or other credential-backed operation without disclosing the underlying secret. The credential store associates protected material with metadata that may identify: credential_id; authorized_service; credential_scope; permitted_tenant; credential_version; revocation_epoch; validity_interval; permitted_executor; key_usage_class. Such metadata does not necessarily expose the underlying credential. 11.4.5. WF-04.5 — Non-Authoritative Credential Reference In an embodiment employing surrogate credentials, AE-401 receives a non-authoritative reference rather than reusable protected credential material. The reference may comprise: (a) an opaque credential identifier; (b) a connector-specific credential placeholder; (c) a session-associated surrogate reference; Das Expires 19 April 2027 [Page 189] Internet-Draft Protected AI Execution Finality October 2026 (d) a non-secret credential selection value; or (e) another identifier resolvable only through the protected credential-effectuation system. An illustrative agent-visible reference is: credential_ref = "service-credential-reference-17" The reference identifies a protected credential or permitted credential class but is not itself accepted by the external service as a reusable credential. The mapping between the reference and protected credential material is controlled by CE-410 or CS-409. Possession of the reference does not permit the agent to retrieve the underlying secret or to issue unrestricted operations. The reference may be bound to a tenant, workload, session, or permitted connector according to the applicable embodiment. 11.4.6. WF-04.6 — Candidate Credential-Mediated Act Generation AE-401 generates or prepares a proposed operation requiring credential-mediated authority. Such operations may include: (a) creating a cloud resource; (b) updating a customer record; (c) transmitting a confidential document; (d) initiating an authorized commerce transaction; (e) modifying an enterprise repository; (f) invoking a privileged API; (g) sending an authenticated communication; (h) publishing an artifact; (i) performing an authenticated service operation; or (j) another consequential credential-mediated request. Das Expires 19 April 2027 [Page 190] Internet-Draft Protected AI Execution Finality October 2026 The proposed operation is classified as Candidate Credential-Mediated Act CA-414. The operation may also constitute a Candidate Sandbox Egress Act under the broader sandbox-egress architecture. The agent's preparation of CA-414 does not independently authorize credential application or external effectuation. 11.4.7. WF-04.7 — Interception and Non-Effective State IM-402 receives CA-414 and places the operation into HQ-403. The operation is maintained as a pending, non-effective request. An illustrative staging record comprises: operation_id; agent_identity; workload_identity; credential_reference; connector_identity; requested_operation; destination_service; operation_parameters_reference; requested_permission_scope; policy_epoch; status = PENDING. The interception component prevents the operation from reaching a credential-effectuation interface capable of completing the governed act until the required protected conditions have been satisfied. The agent cannot bypass the interception mechanism by independently using the protected credential or invoking an unrestricted alternative privileged connector. Das Expires 19 April 2027 [Page 191] Internet-Draft Protected AI Execution Finality October 2026 11.4.8. WF-04.8 — Canonical Operation Descriptor NC-404 constructs a canonical descriptor representing the proposed consequential operation. The descriptor includes effectuation-relevant information required to distinguish authorized from unauthorized operations. A non-limiting descriptor comprises: operation_id; requesting_agent_identity; workload_identity; connector_identity; operation_class; destination_service; destination_endpoint; request_method; resource_identifier; operation_parameters; request_payload_digest; credential_scope; protected_grant_identifier; policy_epoch; revocation_epoch; nonce; expiry; finality_sink_identifier. Das Expires 19 April 2027 [Page 192] Internet-Draft Protected AI Execution Finality October 2026 The descriptor may additionally identify a human approval artifact, permitted purpose, provenance requirement, approved tool identity, or other mandatory authority condition. A deterministic encoding procedure produces the canonical representation. An illustrative mathematical expression is: D = Canon_v(ID, OP, T, P, K, X, E, F) where: D denotes the canonical operation descriptor; Canon_v denotes a deterministic encoding procedure with version identifier v; ID denotes the authenticated requesting identity; OP denotes the proposed operation class; T denotes the intended destination or effectuation target; P denotes the effectuation-relevant parameters; K denotes the required credential or permission scope; X denotes the requesting execution context; E denotes the applicable protected authorization-state epoch; F denotes the designated Finality Sink. The particular implementation defines which fields are mandatory. A cryptographic descriptor digest may be computed as: hD = H("DAS-CREDENTIAL-ACT-v1" || Encode(D)) where: hD denotes the descriptor digest; H denotes a cryptographic hash function; Encode denotes the specified deterministic byte encoding; Das Expires 19 April 2027 [Page 193] Internet-Draft Protected AI Execution Finality October 2026 || denotes concatenation; "DAS-CREDENTIAL-ACT-v1" denotes an illustrative domain-separation label. The encoding prevents ambiguous field boundaries or incompatible descriptor interpretations. 11.4.9. WF-04.9 — Normalization and Actual-Operation Correspondence The operation-normalization component interprets the request according to the effectuation semantics of the intended credential- mediated service. For an HTTP operation, the normalized representation may bind the intended service, request method, resource path, query parameters, authenticated tenant, request-body digest, and authorized credential scope. For a signing operation, the representation may bind the exact document or message digest and permitted signing purpose. For a database connector, the representation may bind the permitted statement class, target table, record identity, and approved mutation parameters. The operation descriptor identifies the attributes that materially determine the external effect. The authorization system does not rely solely upon a free-form natural-language description such as "update the account" or "send the approved information." Where a downstream executor could interpret the request differently from the authorizer, the system uses a shared canonical operation representation, an authenticated normalized request object, or a verified reconstruction procedure. An authorization for one operation cannot be reused for a materially different operation when the changed parameter is part of the mandatory authorization binding. 11.4.10. WF-04.10 — Protected Authority Object PED-405 obtains the Authority Object applicable to CA-414. The Authority Object may identify: Das Expires 19 April 2027 [Page 194] Internet-Draft Protected AI Execution Finality October 2026 (a) permitted agent or workload identities; (b) authorized purpose; (c) permitted connector or service; (d) allowed operation class; (e) resource and recipient restrictions; (f) credential scope; (g) transaction limits; (h) validity interval; (i) approved execution context; (j) required human approval; (k) applicable policy epoch; (l) protected revocation conditions; (m) nonce or usage restrictions; and (n) Finality Sink identity. Where a Sandbox Egress Authority Object applies, the protected validation may additionally evaluate the applicable AIF, ALF, RBD, destination, provenance, and runtime-behavior predicates. PED-405 verifies the required authenticity and state of the Authority Object. An earlier agent-facing approval or credential reference does not independently establish the protected authority required for CA-414. 11.4.11. WF-04.11 — Protected Authorization Predicates PED-405 evaluates the applicable authorization predicates. For a conjunctive authorization policy, the result may be expressed as: V = Pid AND Pop AND Ptarget AND Pscope AND Pgrant AND Pstate where: Das Expires 19 April 2027 [Page 195] Internet-Draft Protected AI Execution Finality October 2026 V denotes the protected authorization result; Pid verifies the requesting identity and execution context; Pop verifies the requested operation class; Ptarget verifies the intended destination, recipient, or target; Pscope verifies the permitted credential and authority scope; Pgrant verifies the applicable protected grant and usage conditions; Pstate verifies mandatory policy, revocation, freshness, and protected-state conditions. Additional predicates may include approval, provenance, ALF, AIF, RBD, tenant, quota, jurisdiction, or other conditions where required. V equals true only when every mandatory predicate succeeds. The implementation may support approved alternative or threshold predicates according to the applicable Authority Object. If a mandatory predicate fails, the protected system does not issue a valid credential-effectuation capability for the rejected operation. 11.4.12. WF-04.12 — Protected Authorization-Grant Record GS-406 maintains an operation-specific grant record. A representative record comprises: grant_id; operation_id; descriptor_digest; authorized_requester; authorized_connector; authorized_target; permitted_credential_scope; valid_from; Das Expires 19 April 2027 [Page 196] Internet-Draft Protected AI Execution Finality October 2026 valid_until; policy_epoch; revocation_epoch; usage_limit; remaining_uses; grant_state_version; finality_sink_id; validation_evidence_reference; status. The grant is associated with the particular operation descriptor or an expressly bounded operation class. The grant state is not equivalent to a general reusable credential. The grant may authorize one specific act, a limited number of acts, a defined session, or a restricted operation window, according to the applicable authorization. For a single-use consequential operation, the grant state includes a condition preventing more than one unauthorized consumption. 11.4.13. WF-04.13 — Protected Grant-State Reservation Before releasing the capability required for the operation, PED-405 establishes the protected grant-state transition. In a single-use embodiment, the system checks that: (a) the grant is valid; (b) the descriptor matches the grant; (c) the relevant policy and revocation state remain acceptable; (d) no incompatible reservation already exists; (e) the usage allowance remains available; and (f) the requested operation is within the permitted scope. Das Expires 19 April 2027 [Page 197] Internet-Draft Protected AI Execution Finality October 2026 Where the required conditions succeed, the system atomically reserves or consumes the authorized usage state. An illustrative operation is: CAS(G.state, AVAILABLE, RESERVED(operation_id, version + 1)) where: CAS denotes an atomic compare-and-swap or equivalent protected compare-and-update procedure; G denotes the applicable grant record; AVAILABLE denotes an unreserved valid grant state; RESERVED denotes a state preventing another incompatible operation from consuming the same authorization; operation_id denotes the candidate operation; version denotes the protected grant-state version. The state change succeeds only if the actual stored state corresponds to the required expected state. If the reservation fails, the capability is withheld and the system does not assume that the operation remains authorized. This procedure may be implemented through protected transactional storage, a secure monotonic state mechanism, an HSM-controlled state service, or equivalent protected machinery. 11.4.14. WF-04.14 — Concurrency and Double-Consumption Prevention Where two or more operations attempt to consume the same restricted grant, the protected state store serializes or otherwise coordinates the required consumption transition. For a single-use grant, at most one incompatible operation may establish the required valid reservation. Suppose two concurrent operations A and B reference the same authorization state version. Both may independently read the initial AVAILABLE state, but the protected compare-and-update procedure permits only one transition to the required RESERVED state. Das Expires 19 April 2027 [Page 198] Internet-Draft Protected AI Execution Finality October 2026 The losing request is denied, retried against updated protected state where permitted, or subjected to renewed authorization. The implementation does not treat two successful preliminary read checks as two valid grant consumptions. Where the authorization permits multiple uses, the protected mechanism enforces the corresponding usage budget or counter rather than requiring single use. 11.4.15. WF-04.15 — Protected Validation-Evidence Commitment Following successful validation and coordinated with the required grant-state transition, EV-407 generates or commits protected validation evidence. The evidence may identify: receipt_id; operation_id; descriptor_digest; grant_id; prior_grant_state_version; committed_grant_state_version; authorization_predicate_reference; credential_scope; finality_sink_id; policy_epoch; revocation_epoch; nonce; decision; protected_authentication. The evidence may comprise a LAVR, Egress LAVR, sealed receipt, authenticated commitment, or equivalent protected finality record. Das Expires 19 April 2027 [Page 199] Internet-Draft Protected AI Execution Finality October 2026 The required evidence is committed before, or atomically with, making the corresponding execution capability available. A log written merely after credential application does not replace mandatory pre-effectuation evidence commitment. 11.4.16. WF-04.16 — Protected Credential-Finality Transaction In one implementation, protected authorization, grant-state reservation, evidence commitment, and capability availability are coordinated through a protected finality transaction. An illustrative transaction is: (Snext, R, Ready) = CommitGrant(D, A, Scurrent, G, F) where: Snext denotes the protected state after successful commitment; R denotes the protected validation-evidence commitment; Ready denotes the protected result indicating that required pre- release conditions have been satisfied; D denotes the canonical operation descriptor; A denotes the applicable authenticated authority; Scurrent denotes the prior protected authorization state; G denotes the operation-specific grant; F denotes the intended Finality Sink. The transaction does not make an execution capability usable when the required protected commitment is absent or incomplete. In a two-phase implementation, the system first creates a protected PREPARED record and then commits the required protected-state and evidence relationships. Only the committed state supports the corresponding capability. This atomicity concerns the required protected authorization and capability-release dependency. It does not necessarily mean that an arbitrary remote external service participates in the same atomic storage transaction. Das Expires 19 April 2027 [Page 200] Internet-Draft Protected AI Execution Finality October 2026 11.4.17. WF-04.17 — Scoped Credential-Effectuation Capability CR-408 generates, registers, or releases an operation-scoped, non- bearer capability. In an illustrative authenticated implementation, the capability contains or securely references: capability_id; canonical_descriptor_digest; grant_id; grant_state_version; authorized_connector; authorized_credential_scope; authorized_destination; permitted_operation; validation_evidence_digest; policy_epoch; revocation_epoch; nonce; expiry; finality_sink_id. The capability may be cryptographically signed or MAC-authenticated, maintained as a protected capability-table entry, or implemented through another protected enablement mechanism. The capability is not an unrestricted bearer credential. Its use remains dependent upon the actual operation, permitted execution context, grant state, authorization scope, designated Finality Sink, and required freshness conditions. Das Expires 19 April 2027 [Page 201] Internet-Draft Protected AI Execution Finality October 2026 An entity possessing the capability representation cannot successfully employ it for a different operation when the required non-bearer checks are enforced. 11.4.18. WF-04.18 — Authenticated Credential-Executor Interface CE-410 communicates with PED-405, CS-409, or VS-411 through an authenticated inter-component interface. The interface may comprise an authenticated local IPC channel, protected host-service channel, mutually authenticated transport connection, secure enclave call, HSM session, or equivalent controlled communication path. Where the embodiment requires executor identity verification, the protected authorization system validates the identity or attestation of CE-410. The relevant identity may comprise: (a) an authenticated host-service identity; (b) a registered connector identity; (c) a verified workload identity; (d) a protected process identity; (e) a signed or measured executable identity; (f) a confidential-computing attestation measurement; or (g) another machine-verifiable executor identity. An attestation may be required where specified by the applicable Authority Object. The system does not assume that every connector requires hardware attestation. An unauthorized connector cannot invoke credential effectuation merely by copying an approved connector's name or submitting an agent-visible reference. 11.4.19. WF-04.19 — Independent Verification of the Actual Operation VS-411 obtains the operation actually presented by CE-410 for credential-mediated effectuation. Das Expires 19 April 2027 [Page 202] Internet-Draft Protected AI Execution Finality October 2026 It constructs or verifies the corresponding actual-operation descriptor. Let: Dactual = Canon_v(ActualRequest, ExecutorContext, TargetSink) where: Dactual denotes the descriptor representing the operation actually presented for effectuation; Canon_v denotes the specified deterministic canonicalization procedure; ActualRequest denotes the effectuation-relevant request fields; ExecutorContext denotes the authenticated requesting executor and workload context; TargetSink denotes the applicable credential or external-operation Finality Sink. Where exact descriptor equality is mandatory: H(Dactual) = hD where H denotes the specified cryptographic hash function and hD denotes the validated descriptor digest using the same agreed encoding and domain separation. Where bounded variations are expressly authorized, the verifier checks the required exact fields together with the permitted bounded- scope conditions. The verifier additionally checks the current protected grant-state version and applicable usage, revocation, expiry, and freshness conditions. The existence of an earlier protected allow decision does not eliminate this verification step. 11.4.20. WF-04.20 — Finality Sink Verification Predicate The final credential-effectuation authorization may be represented as: PermitCredential = Das Expires 19 April 2027 [Page 203] Internet-Draft Protected AI Execution Finality October 2026 Auth(C) AND Match(C,Dactual) AND GrantValid(C,G) AND ExecutorValid(C,E) AND ScopeValid(C,K,T) AND StateValid(C,S) AND SinkValid(C,F) where: PermitCredential denotes permission to apply the protected credential for the governed operation; C denotes the scoped execution capability; Dactual denotes the actual-operation descriptor; G denotes the current protected grant-state record; E denotes the verified credential-executor identity; K denotes the authorized credential scope; T denotes the actual effectuation target; S denotes the required protected policy, revocation, freshness, and usage state; F denotes the applicable Finality Sink; Auth verifies capability authenticity; Match verifies required descriptor correspondence; GrantValid verifies the required grant reservation or consumption state; ExecutorValid verifies the executor identity or attestation required by the embodiment; ScopeValid verifies permitted credential use, operation class, and destination; Das Expires 19 April 2027 [Page 204] Internet-Draft Protected AI Execution Finality October 2026 StateValid verifies mandatory protected authorization state; SinkValid verifies the authorized Finality Sink identity. The credential-effectuation operation proceeds only when PermitCredential is true. 11.4.21. WF-04.21 — Protected Credential Selection and Release Upon successful Finality Sink verification, CE-410 resolves the authorized credential reference against CS-409. The resolved credential must correspond to the validated service, credential scope, tenant, operation class, and required grant state. The protected credential store may return: (a) a narrowly scoped credential; (b) a short-lived delegated credential; (c) an operation-bound credential-use authorization; (d) a protected signing result; (e) a non-exportable cryptographic operation result; or (f) an internally applied credential operation. The choice depends upon the selected credential technology. Where the embodiment requires that reusable protected credential material remain outside the agent environment, CE-410 does not return the reusable secret to AE-401. Credential selection or release for an authorized operation does not permit applying that credential to a different operation. 11.4.22. WF-04.22 — Surrogate Credential Substitution Variant In a surrogate-credential embodiment, the agent constructs an operation using a non-authoritative credential placeholder. The placeholder is resolved only within an authenticated, trusted credential-effectuation component after the required authorization conditions have succeeded. An illustrative sequence is: Das Expires 19 April 2027 [Page 205] Internet-Draft Protected AI Execution Finality October 2026 AE-401 submits a proposed operation identifying a surrogate credential reference. IM-402 intercepts and stages the operation. NC-404 constructs the canonical operation descriptor. PED-405 validates the applicable Authority Object and protected grant state. GS-406 performs the required protected reservation or consumption. EV-407 commits the protected validation evidence. CR-408 releases the scoped execution capability. VS-411 verifies the actual operation against the capability and protected grant state. CE-410 resolves the surrogate credential reference within its protected execution boundary. CE-410 applies the authorized real credential to the corresponding validated operation. FS-412 permits the governed effect only after its required verification succeeds. The surrogate itself is not treated as execution authority. If the operation differs from the authorized descriptor, the credential is not applied. If the credential has been revoked or its scope has changed incompatibly, the operation is rejected or revalidated. The real credential is not returned to the sandboxed agent. 11.4.23. WF-04.23 — Binding Credential Substitution to the Exact Request Where a credential is inserted into an HTTP or API request after protected authorization, the implementation distinguishes ordinary application request fields from the protected credential field to be supplied by CE-410. The canonical request descriptor may bind: Das Expires 19 April 2027 [Page 206] Internet-Draft Protected AI Execution Finality October 2026 (a) the requesting workload; (b) the authenticated connector identity; (c) the destination service; (d) the HTTP method; (e) the resource path; (f) the effectuation-relevant request-body digest; (g) the authorized credential scope; (h) the protected grant-state version; and (i) the designated Finality Sink. The protected credential field may be represented by a credential- reference identifier and required scope, rather than its undisclosed secret bytes. CE-410 is permitted to replace only the designated credential placeholder or protected authentication field. The remaining mandatory effectuation-relevant request fields remain bound to the authorized descriptor. The final outgoing request is checked for unauthorized mutation before transmission. Where the remote protocol requires a signature or authentication value over the completed request, the signature or authentication material is produced for the validated request under the permitted credential scope. An implementation does not assume that arbitrary credential insertion leaves every protocol's request semantics unchanged. 11.4.24. WF-04.24 — Redirect and Credential-Leakage Prevention Where the credential-mediated operation involves network transmission, the Finality Sink verifies the applicable destination before applying or transmitting credential material. A redirect, destination substitution, service-identity mismatch, routing change, or unauthorized connector substitution is evaluated against the original authorized operation. Das Expires 19 April 2027 [Page 207] Internet-Draft Protected AI Execution Finality October 2026 If the new target is outside the permitted credential scope, the credential is not forwarded. In a protected proxy implementation, redirect following may be disabled unless the resulting operation is separately validated or expressly permitted within a bounded authorization. The protected component must not transmit reusable credential material to an unauthorized destination merely because the original operation had been approved. This destination consistency mechanism may operate together with Workflow WF-03. 11.4.25. WF-04.25 — Atomic Credential Application and Effectuation Boundary The term atomic credential application refers, in this embodiment, to a protected relationship among the required grant-state transition, operation-specific authorization commitment, capability verification, and credential-use enablement. For example, CE-410 may maintain a controlled request state in which the credential cannot be applied until VS-411 verifies a committed authorization record and its associated capability. The request is then passed to the designated Finality Sink through an enforcement-controlled path. Where the credential-use operation itself is performed within an HSM or protected signing module, the module may require the validated operation digest and authorization reference before producing the signature. Where the credential is used to transmit a request to a remote service, local protected authorization commitment and remote transaction completion are not presumed to form one globally atomic transaction. The implementation may use a protected reservation before transmission and an outcome-state update after receiving suitable completion evidence. The absence of a remote completion response does not prove that the remote operation failed. Das Expires 19 April 2027 [Page 208] Internet-Draft Protected AI Execution Finality October 2026 11.4.26. WF-04.26 — Protected Effectuation Outcome State OS-413 maintains an operation-specific outcome record. An illustrative state machine comprises: PENDING; VALIDATING; AUTHORIZED; RESERVED; EFFECTUATION_IN_PROGRESS; CONFIRMED_EFFECTIVE; DENIED; INDETERMINATE. A Candidate Act initially enters PENDING. Successful authorization may advance it to AUTHORIZED. A valid protected grant reservation may advance it to RESERVED. Invocation of the controlled credential-effectuation interface may advance it to EFFECTUATION_IN_PROGRESS. Where sufficient completion evidence is obtained, the operation may transition to CONFIRMED_EFFECTIVE. Where a mandatory condition fails before effectuation, the operation may be marked DENIED. Where external completion cannot be established after a possible effectuation attempt, the operation is marked INDETERMINATE. The system distinguishes a reserved authorization from a confirmed external consequence. The protected outcome record may identify: operation_id; grant_id; Das Expires 19 April 2027 [Page 209] Internet-Draft Protected AI Execution Finality October 2026 capability_id; external_transaction_reference; effectuation_attempt_count; last_known_completion_state; protected_state_version; recovery_requirement. 11.4.27. WF-04.27 — Crash Recovery and Duplicate-Effect Prevention If PED-405 fails before the protected grant-state and evidence commitment is established, no externally usable capability is made available for the incomplete transaction. If the protected commitment succeeds but capability delivery fails, the system consults the committed authorization state before deciding whether the original capability can be recovered or safely retired. If CE-410 fails before applying the protected credential, the system reconciles the reserved grant state and validates whether the corresponding operation can be resumed. If CE-410 fails after transmitting a credential-mediated request but before receiving a response, OS-413 records an indeterminate completion condition where appropriate. A subsequent attempt using the same operation identifier is evaluated against the protected outcome state. Where a previously completed operation would be duplicated by replay, a new authorization is withheld unless an applicable recovery predicate establishes that the additional attempt is permitted. A downstream idempotency key, transaction-status query, authenticated receipt, or receiving-side Finality Sink may support reconciliation where available. The system does not assert unconditional exactly-once completion across arbitrary remote services lacking suitable completion or idempotency facilities. Das Expires 19 April 2027 [Page 210] Internet-Draft Protected AI Execution Finality October 2026 11.4.28. WF-04.28 — Human Approval as a Protected Predicate Where the operation requires human authorization, the proposed credential-mediated operation remains non-effective pending receipt of an applicable approval artifact. The approval artifact may identify the requesting user or operator, the operation descriptor, permitted recipient, credential scope, transaction limit, validity interval, and authorization-state reference. PED-405 verifies the artifact according to the required authority conditions. An approval for one operation does not independently authorize a materially different operation. The approval artifact is an input to protected validation and does not itself substitute for the required grant-state commitment, scoped capability, and Finality Sink verification. 11.4.29. WF-04.29 — Multiple Credential and Effectuation Boundaries A governed workflow may contain more than one consequential credential-related boundary. For example, one boundary may authorize a protected signing operation while another controls network transmission of the signed request. A further receiving-side boundary may control whether the remote service commits the requested transaction. Where separate Finality Sinks are required, each sink verifies the scoped capability or the capability expressly bound to its permitted stage. Authorization to generate a signature does not automatically authorize transmission to every destination. Authorization to transmit a signed request does not automatically establish receiving-side authority to commit a separate consequential operation. Where the selected embodiment uses one protected component to perform multiple Finality Sink functions, the component enforces the required operation-specific conditions for each governed effect. Das Expires 19 April 2027 [Page 211] Internet-Draft Protected AI Execution Finality October 2026 11.4.30. WF-04.30 — Illustrative End-to-End Enterprise API Implementation In a concrete non-limiting embodiment, an AI agent is authorized to assist an enterprise user with creating invoices through an external accounting service. The agent runs within an isolated execution environment and does not possess the accounting service's reusable API credential. Instead, the agent is provided with a non-authoritative credential reference identifying the permitted accounting connector. The agent prepares an HTTP POST operation directed to an invoice- creation endpoint. The operation includes a recipient identifier, currency, invoice amount, item description, and an authorized tenant context. The request is intercepted before network transmission. The interception component places the operation in a Non-Effective State and constructs a canonical descriptor including the requesting workload identity, connector identity, destination service, POST operation, recipient, amount, invoice data digest, credential scope, policy epoch, and Finality Sink identity. The PED obtains the applicable Authority Object and validates the requested operation. The predicates may include: (a) whether the requesting agent is permitted to use the accounting connector; (b) whether the invoice-recipient scope is authorized; (c) whether the requested amount is within the permitted limit; (d) whether the operation remains within the authorized user purpose; (e) whether the required approval artifact is valid; (f) whether the credential scope permits invoice creation; (g) whether the current policy and revocation conditions remain valid; and Das Expires 19 April 2027 [Page 212] Internet-Draft Protected AI Execution Finality October 2026 (h) whether the corresponding grant has sufficient remaining usage authority. Upon successful validation, the protected grant-state store atomically reserves the operation-specific grant. The protected validation-evidence mechanism commits an authenticated record binding the operation descriptor, authorized scope, grant- state version, and designated Finality Sink. The capability-release component then makes available an operation- scoped non-bearer execution capability. The privileged accounting connector authenticates to the protected authority and presents the actual invoice-creation operation to the execution verifier. The execution verifier compares the operation with the validated descriptor and checks the current protected grant state. If all required conditions succeed, the connector retrieves or uses the protected accounting credential. The connector applies the credential only to the validated invoice- creation request and transmits that request through the governed network Finality Sink. If the recipient changes, amount changes outside the permitted authorization, credential scope becomes invalid, or protected grant state no longer corresponds to the committed transaction, the operation is refused. If the accounting service returns a confirmed invoice identifier, the protected outcome-state record may be updated to CONFIRMED_EFFECTIVE. If the network response is lost after possible request transmission, the operation is marked INDETERMINATE until an authorized reconciliation procedure establishes the applicable result. The agent cannot resolve the credential reference into the reusable protected API credential or independently create a different invoice through the governed connector. 11.4.31. WF-04.31 — Alternative Credential Implementations The described protected credential-effectuation relationship may be implemented through different credential technologies. Das Expires 19 April 2027 [Page 213] Internet-Draft Protected AI Execution Finality October 2026 OAuth-based implementation: A protected connector applies an access token whose service, scope, validity, and permitted operation satisfy the protected authorization conditions. API-key implementation: The reusable API key is maintained outside the agent environment, and an authenticated executor applies it only after operation-specific authorization. Hardware signing implementation: An HSM performs a signing operation for an authorized message digest after required capability verification. Mutual-TLS implementation: A protected component uses a client authentication key or certificate within the authorized connection and service scope. Short-lived delegated credential implementation: A protected component obtains a restricted credential valid for the specific authorized operation, resource, or interval. Confidential-VM implementation: Credential processing occurs within an attested confidential workload, subject to the required protected authorization and effectuation conditions. Single-node implementation: A protected controller implements grant- state reservation, evidence commitment, capability checking, and credential application within one protected node. Distributed implementation: The PED and privileged connector operate on different nodes and exchange authenticated operation-specific authorization information. These alternatives do not require identical cryptographic protocols or hardware substrates, but each implementation must enforce the security properties required by its corresponding claim. 11.4.32. WF-04.32 — PHOSITA Verification and Negative Tests A person having ordinary skill in distributed authorization, API security, cryptography, secret management, transactional storage, cloud infrastructure, or trusted execution systems may verify the embodiment through controlled tests. Test 1 — Authorized operation: Submit an operation matching the authorized descriptor and protected grant state. Credential-mediated effectuation is permitted. Das Expires 19 April 2027 [Page 214] Internet-Draft Protected AI Execution Finality October 2026 Test 2 — Surrogate without authority: Present a valid-looking credential reference without the required operation-specific authorization. Effectuation is refused. Test 3 — Destination substitution: Change the target service after authorization. The credential is not applied to the unauthorized destination. Test 4 — Parameter substitution: Modify a required transaction parameter. Descriptor correspondence fails. Test 5 — Wrong connector: Present the capability through an unauthorized executor when executor identity is mandatory. Effectuation is refused. Test 6 — Concurrent grant consumption: Submit two requests against a single-use grant. The protected state mechanism prevents unauthorized duplicate consumption. Test 7 — Stale grant version: Present a capability referencing an incompatible earlier grant-state version. Verification fails. Test 8 — Revoked credential: Revoke or invalidate a mandatory credential or authority condition. Affected operations are refused pending valid reauthorization. Test 9 — Credential leakage: Inspect agent-visible responses, logs, and accessible process state to verify that reusable protected credentials are not exposed by the selected implementation. Test 10 — Connector bypass: Attempt direct invocation of the protected credential service without the required authenticated executor and operation-specific capability. The request is refused. Test 11 — Crash before protected commit: Interrupt the protected authorization transaction before commitment. No valid externally usable capability becomes available. Test 12 — Crash after transmission: Interrupt the connector after possible external effectuation. The operation enters an appropriate indeterminate or reconciled state rather than automatically receiving unrestricted retry authority. Test 13 — Redirect: Attempt to forward a protected credential to a redirected unauthorized destination. The transmission is refused. Das Expires 19 April 2027 [Page 215] Internet-Draft Protected AI Execution Finality October 2026 Test 14 — Replayed capability: Re-present a consumed single-use capability. The protected consumption predicate rejects unauthorized reuse. Test 15 — Human approval mismatch: Supply approval for a different operation or recipient. The protected authorization predicate fails. Test 16 — Remote reconciliation: Simulate a lost response to a transaction supported by a remote idempotency identifier. Verify that retry or reconciliation follows the protected operation-state rules without causing an unauthorized duplicate effect. 11.4.33. WF-04.33 — Technical Result The embodiment establishes a protected operation-specific dependency between: (a) a proposed credential-mediated Candidate Act; (b) interception and Non-Effective State staging; (c) canonical operation-descriptor construction; (d) protected authority-predicate validation; (e) protected authorization-grant state; (f) required atomic reservation or consumption; (g) protected validation-evidence commitment; (h) operation-scoped non-bearer capability availability; (i) independent executor and actual-operation verification; (j) controlled protected credential use; (k) Finality Sink enforcement; and (l) protected effectuation-outcome handling. The resulting architecture prevents an agent from converting possession of a credential reference, connector name, reusable service permission, or earlier allow decision into unrestricted execution authority. Protected credential custody and protected operation-specific execution authority remain distinguishable. Das Expires 19 April 2027 [Page 216] Internet-Draft Protected AI Execution Finality October 2026 The architecture permits different software, firmware, hardware, cryptographic, and distributed implementations while retaining the applicable protected finality dependency. Computation is not authority to act. Credential possession or reference is not authority to effectuate an unvalidated operation. 11.5. WF-05 — Privileged Connector Isolation, Authenticated Inter- Component Communication, Independent Executor Verification, and Cross-Component Finality Consistency 11.5.1. WF-05.1 — Technical Purpose This embodiment describes a protected execution-finality architecture for governing consequential operations requested by an artificial- intelligence agent and performed through one or more privileged connectors, protected host workers, service gateways, credential brokers, application programming interfaces, or equivalent effect- capable execution components. The architecture separates the computational environment preparing a proposed operation from the privileged component capable of effectuating that operation. A proposed operation is classified as a Candidate Act and maintained in a Non-Effective State until the required protected authorization predicates, protected-state conditions, validation-evidence commitment, and scoped execution-capability requirements have been satisfied. A privileged connector does not treat a request from an agent, possession of a credential reference, an earlier authorization result, or access to an authenticated communication channel as sufficient authority to perform an externally effective operation. Instead, the connector independently verifies an operation-specific authorization commitment, execution-enablement artifact, or scoped capability against the operation actually presented for effectuation and the applicable current protected state. Where multiple protected components participate, the system maintains the required consistency of Candidate Act identity, authorization scope, policy state, capability-consumption state, and effectuation- boundary identity. Das Expires 19 April 2027 [Page 217] Internet-Draft Protected AI Execution Finality October 2026 The protected arrangement prevents an untrusted agent from using a privileged connector as a means of circumventing execution-finality enforcement. 11.5.2. WF-05.2 — Participating Technical Components In a non-limiting embodiment, the system comprises: AE-501 — Agent Execution Environment An artificial-intelligence agent, model runtime, autonomous workflow, container, virtual machine, tool runtime, or associated computational environment configured to generate proposed operations. IB-502 — Interception and Request Broker An enforcement-controlled component configured to receive proposed operations from AE-501 and prevent unauthorized direct invocation of effect-capable interfaces. HQ-503 — Non-Effective Holding Mechanism A queue, staged-request object, protected request record, immutable operation buffer, or equivalent controlled mechanism retaining a Candidate Act before effectuation. DC-504 — Operation Descriptor Component A mechanism configured to construct or verify a canonical Candidate Act Descriptor. PED-505 — Protected Enforcement Domain A protected component configured to validate authority predicates, maintain or verify protected state, commit required evidence, and authorize availability of a scoped execution capability. PS-506 — Protected Authorization-State Store A component maintaining the applicable policy epoch, grant state, revocation information, nonce state, operation-specific commitments, usage state, and capability-consumption information. EV-507 — Protected Validation-Evidence Component A mechanism for generating or committing a LAVR, Egress LAVR, AVR, sealed validation record, authenticated commitment, or other protected authorization evidence. Das Expires 19 April 2027 [Page 218] Internet-Draft Protected AI Execution Finality October 2026 CR-508 — Scoped Capability Release Mechanism A mechanism configured to generate, register, or release a scoped non-bearer Execution-Enabling Capability. AC-509 — Authenticated Inter-Component Communication Interface A protected local or remote communication facility configured to authenticate the communicating components and maintain the integrity of exchanged authorization information. PC-510 — Privileged Connector Execution Component A component having controlled access to a service, protected credential, host operation, database, API, network interface, or other effect-capable resource that is not directly available to AE- 501. IV-511 — Independent Execution Verifier A mechanism associated with PC-510 or its effectuation interface, configured to verify operation-specific authorization before performing the governed operation. CS-512 — Protected Credential or Resource Store An optional HSM, secure enclave, protected secret store, resource- control service, or equivalent protected component. FS-513 — Connector Finality Sink The technical boundary at which the connector's proposed operation would become externally effective. OS-514 — Protected Operation-Outcome Store A protected mechanism maintaining completion, reservation, denial, revocation, and indeterminate-effectuation information. SC-515 — Cross-Component State-Consistency Mechanism A protected mechanism configured to maintain or verify the required correspondence of operation identity, authorization state, capability scope, and finality conditions among participating components. These components may be physically separated, colocated, or combined within a protected node, provided the required protected authority and effectuation-verification relationships remain satisfied. Das Expires 19 April 2027 [Page 219] Internet-Draft Protected AI Execution Finality October 2026 11.5.3. WF-05.3 — Establishment of the Agent-to-Connector Trust Boundary Before enabling governed agent operations, the system establishes a trust boundary between AE-501 and PC-510. The agent may prepare operations and submit requests, but does not possess unrestricted authority to: (a) invoke arbitrary privileged host operations; (b) read or export protected connector credentials; (c) modify the protected authorization state; (d) replace protected capability-verification code; (e) impersonate an authenticated connector; (f) access unrestricted external service interfaces; or (g) bypass an applicable Finality Sink. In a host-based implementation, the agent and privileged connector may execute as separate processes with distinct operating-system identities, namespaces, security labels, service privileges, or resource-access permissions. In a virtual-machine implementation, the agent and connector may operate in separate guest, host, enclave, or hypervisor-controlled domains. In a distributed implementation, the agent and connector may run on separate computing nodes and communicate through authenticated interfaces. Physical separation is not required where an implementation provides the protected logical boundaries necessary to enforce the specified relationship. 11.5.4. WF-05.4 — Privileged Connector Security Configuration PC-510 is configured with only the resource authority necessary for its permitted connector functions. A non-limiting connector configuration may define: connector_id; Das Expires 19 April 2027 [Page 220] Internet-Draft Protected AI Execution Finality October 2026 connector_software_identity; authorized_workload_classes; permitted_service_identities; permitted_operation_classes; permitted_resource_scope; credential_reference_allowlist; network_destination_allowlist; authorized_authority_issuer; accepted_policy_epoch; finality_sink_id; required_verification_mode. The connector does not automatically acquire unrestricted authority over all resources available to its host. Where a connector has access to several service credentials, its protected credential-selection mechanism restricts which credential may be applied to a particular authorized operation. In a more restrictive implementation, different connector processes are assigned different credentials, service destinations, or execution privileges. The system may prohibit an untrusted agent from creating a new privileged connector or modifying the connector's permitted resource scope without a separate protected authorization event. 11.5.5. WF-05.5 — Authentication of Inter-Component Communication AC-509 establishes an authenticated communication relationship among participating components. For components on the same host, the communication facility may employ an operating-system-controlled local socket, authenticated IPC channel, protected shared-memory interface, secure enclave call, or equivalent mechanism. Das Expires 19 April 2027 [Page 221] Internet-Draft Protected AI Execution Finality October 2026 Where operating-system peer credentials are used, the receiving component obtains peer identity information from the trusted operating-system communication interface rather than accepting a caller-supplied identity string as authoritative. For a Linux-based implementation, a local Unix-domain socket may provide operating-system peer-credential information. The implementation may additionally verify the associated service identity, process lifetime, security label, cgroup identity, or protected workload measurement where required. For remotely separated components, the system may use mutually authenticated TLS, authenticated service identities, cryptographically authenticated messages, hardware-backed identities, or an equivalent protected communication protocol. A transport authentication mechanism proves only the properties established by that mechanism. It does not independently establish authorization for the requested consequential operation. 11.5.6. WF-05.6 — Connector Identity and Attestation Each privileged connector may have a registered execution identity. The identity may comprise: (a) an authenticated operating-system service identity; (b) a protected process identity; (c) a workload identity; (d) a signed software identity; (e) a measured executable digest; (f) a confidential-computing attestation measurement; (g) a hardware-backed service identity; or (h) an equivalent machine-verifiable connector identity. Where hardware attestation is required, an attestation report may identify a measured executable, protected workload configuration, firmware version, security configuration, or other required measured state. An illustrative attestation verification condition is: Das Expires 19 April 2027 [Page 222] Internet-Draft Protected AI Execution Finality October 2026 AttestValid = SignatureValid AND MeasurementApproved AND ChallengeFresh AND IdentityBound where: AttestValid denotes the result of connector-attestation verification; SignatureValid verifies the authentication of the attestation evidence and the applicable trust chain; MeasurementApproved verifies the required software or workload measurement; ChallengeFresh verifies that the attestation evidence corresponds to an acceptable freshness challenge or protected state; IdentityBound verifies that the attested component is the connector participating in the intended operation. Attestation is mandatory only where required by the applicable Authority Object or specified embodiment. An authenticated identity alone does not authorize the connector to perform every operation. 11.5.7. WF-05.7 — Candidate Connector Act Generation AE-501 generates a proposed operation directed to a privileged connector. The proposed operation may comprise: (a) invoking an enterprise application API; (b) requesting an authenticated network transmission; (c) updating a cloud resource; (d) creating or modifying a database record; (e) applying a protected signing credential; (f) modifying a managed repository; (g) dispatching an authorized notification; (h) performing a payment or commerce operation; Das Expires 19 April 2027 [Page 223] Internet-Draft Protected AI Execution Finality October 2026 (i) invoking a host-side worker; or (j) another effect-capable connector operation. The proposed operation is classified as Candidate Connector Act CA- 516. The classification identifies that the act, if completed, would produce a governed consequential effect. The agent's ability to generate CA-516 does not independently confer the authority required for its completion. 11.5.8. WF-05.8 — Mandatory Interception and Non-Effective Staging IB-502 receives or intercepts CA-516 before the privileged connector completes the governed operation. The operation is retained in HQ-503. An illustrative staged operation record comprises: operation_id; agent_identity; workload_identity; requested_connector_id; requested_operation; target_service; operation_parameters_reference; credential_reference; authority_reference; policy_epoch; status = NON_EFFECTIVE. The privileged connector does not execute the operation merely because the request is present in the queue. Das Expires 19 April 2027 [Page 224] Internet-Draft Protected AI Execution Finality October 2026 Where the operation contains mutable data, the broker creates a controlled representation or immutable snapshot of effectuation- relevant parameters. The agent cannot modify the staged operation after authorization in a manner that changes the consequential effect without causing a new correspondence check or renewed authorization. 11.5.9. WF-05.9 — Construction of an Operation-Specific Canonical Descriptor DC-504 obtains the required Candidate Act attributes and constructs a canonical descriptor. A non-limiting descriptor comprises: operation_id; requesting_agent_identity; workload_identity; connector_identity; executor_identity; operation_class; target_service_identity; destination_or_resource; request_parameters; payload_digest; credential_scope; authorized_purpose; authority_object_reference; grant_state_version; policy_epoch; revocation_epoch; Das Expires 19 April 2027 [Page 225] Internet-Draft Protected AI Execution Finality October 2026 nonce; expiry; finality_sink_identity. The descriptor may be produced using a deterministic serialization procedure. An illustrative expression is: D = Canon_v(ACT, AGENT, EXEC, TARGET, PARAM, SCOPE, STATE, SINK) where: D denotes the canonical Candidate Act Descriptor; Canon_v denotes deterministic canonicalization under encoding version v; ACT denotes the proposed operation; AGENT denotes the authenticated requesting agent or workload identity; EXEC denotes the intended privileged executor identity; TARGET denotes the destination, recipient, resource, or service; PARAM denotes effectuation-relevant operation parameters; SCOPE denotes the applicable execution and credential scope; STATE denotes the required authorization-state version; SINK denotes the designated Finality Sink identity. Only fields required by the applicable authority and specified embodiment must be included. The descriptor is constructed so that materially different operations cannot be treated as identical merely because their natural-language descriptions are similar. 11.5.10. WF-05.10 — Cryptographic Authorization Commitment In a cryptographic implementation, the protected system creates an operation-specific commitment over the canonical descriptor. Das Expires 19 April 2027 [Page 226] Internet-Draft Protected AI Execution Finality October 2026 An illustrative commitment is: hD = H("DAS-CONNECTOR-v1" || Encode(D)) where: hD denotes the operation-descriptor commitment; H denotes a cryptographic hash function; Encode denotes the specified deterministic byte encoding; || denotes concatenation of encoded values; "DAS-CONNECTOR-v1" denotes an illustrative domain-separation label. The commitment may be incorporated into a protected validation receipt, authorization-state record, scoped execution capability, or authenticated communication object. The same canonicalization version and mandatory field interpretation are used by the authorizing and verifying components. Where an intermediate component is expressly permitted to transform a request, the authorization identifies the permitted transformation and preserves a verifiable relationship between the original and transformed operation. An unauthorized transformation causes the required descriptor correspondence to fail. 11.5.11. WF-05.11 — Protected Authority Validation PED-505 obtains the applicable Authority Object and protected authorization state. The Authority Object may identify: (a) permitted requesting agents; (b) permitted connector identities; (c) approved operation classes; (d) authorized services and resources; (e) applicable credential scopes; Das Expires 19 April 2027 [Page 227] Internet-Draft Protected AI Execution Finality October 2026 (f) permitted operation parameters; (g) required human approval; (h) authorized purpose; (i) applicable ALF, AIF, or RBD conditions; (j) policy and revocation requirements; (k) nonce, expiry, and usage restrictions; and (l) designated Finality Sink identity. The PED authenticates the Authority Object and evaluates its mandatory predicates. An illustrative validation expression is: V = Pagent AND Pconnector AND Poperation AND Pscope AND Pstate where: V denotes the protected authorization result; Pagent verifies the requesting agent or workload identity; Pconnector verifies the permitted connector identity; Poperation verifies the proposed operation and its effectuation- relevant parameters; Pscope verifies the permitted authority, credential, destination, and resource scope; Pstate verifies required freshness, policy, revocation, and usage conditions. Additional predicates are evaluated where required. Failure of a mandatory condition prevents release of the corresponding execution authority. 11.5.12. WF-05.12 — Protected Grant-State Validation and Consumption PS-506 maintains or obtains the operation-specific authorization state. Das Expires 19 April 2027 [Page 228] Internet-Draft Protected AI Execution Finality October 2026 Where an operation requires a single-use or bounded-use grant, the PED verifies the applicable grant identifier, descriptor commitment, authorized scope, validity interval, remaining usage count, and current protected state. Where required, a protected reservation or consumption transition is performed before capability availability. An illustrative transition is: AVAILABLE → RESERVED(operation_id, state_version) The transition is protected against unauthorized concurrent consumption. If the grant is already exhausted, reserved incompatibly, revoked, or invalid, the required capability is withheld. A connector cannot create a new protected grant merely by claiming that an earlier permission existed. 11.5.13. WF-05.13 — Protected Validation-Evidence Commitment Following successful validation, EV-507 generates or commits the applicable protected validation evidence. An illustrative protected record contains: receipt_id; operation_id; canonical_descriptor_digest; authority_object_reference; validated_predicate_reference; protected_grant_state; authorized_connector_id; policy_epoch; revocation_state_reference; finality_sink_id; Das Expires 19 April 2027 [Page 229] Internet-Draft Protected AI Execution Finality October 2026 protected_authentication. The evidence may comprise a LAVR, Egress LAVR, AVR, sealed validation record, authenticated commitment, or equivalent protected representation. Where the applicable claim requires protected evidence commitment before or atomically with capability availability, the system enforces that ordering. A connector does not treat a conventional post-execution audit log as a substitute for the required protected validation commitment. 11.5.14. WF-05.14 — Operation-Scoped Execution Capability Upon successful completion of the applicable protected finality transaction, CR-508 generates, registers, or makes available a scoped execution capability. An illustrative authenticated capability contains or securely references: capability_id; operation_descriptor_digest; authorization_receipt_digest; authorized_agent_identity; authorized_executor_identity; authorized_connector_id; authorized_resource; permitted_operation; credential_scope; policy_epoch; revocation_epoch; grant_state_version; nonce; Das Expires 19 April 2027 [Page 230] Internet-Draft Protected AI Execution Finality October 2026 expiry; usage_limit; finality_sink_id. The capability may be implemented as a signed structure, MAC- authenticated authorization object, protected table entry, sealed handle, or equivalent protected enablement artifact. Where a connector identity is mandatory, the capability is not usable by a different executor solely because that executor possesses the capability representation. Where Finality Sink identity is mandatory, the capability does not authorize another sink merely because the operation appears similar. 11.5.15. WF-05.15 — Protected Capability Delivery PED-505 or CR-508 makes the execution capability available through AC-509. In a local implementation, the capability may be delivered through an authenticated IPC message. In a remote implementation, it may be transmitted through a mutually authenticated channel or obtained from a protected capability- verification service. In a single-node implementation, the capability may be represented by an internal protected authorization-table entry that PC-510 references. The communication may include: operation_id; descriptor_digest; capability_id; capability_or_reference; authorization_state_version; receipt_commitment_reference; intended_connector_id; Das Expires 19 April 2027 [Page 231] Internet-Draft Protected AI Execution Finality October 2026 intended_finality_sink_id. The receiving component verifies that the message originates from an authorized component. The connector does not treat an unauthenticated agent-provided copy of an apparent capability as sufficient execution authority. 11.5.16. WF-05.16 — Independent Executor Verification Before performing the consequential operation, IV-511 independently verifies the authorization. The verification is performed at, or in mandatory control of, the privileged execution interface. The verifier obtains or reconstructs the actual operation descriptor from the operation that PC-510 is prepared to perform. The verifier evaluates: (a) capability authenticity; (b) authorized connector identity; (c) authenticated requesting context; (d) correspondence to the actual operation; (e) permitted destination or resource; (f) applicable credential scope; (g) policy and revocation state; (h) protected grant-state version; (i) required freshness and nonce conditions; (j) capability-consumption state; (k) required validation-evidence commitment; and (l) designated Finality Sink identity. The verification does not rely solely upon a previous statement that another component approved the operation. Das Expires 19 April 2027 [Page 232] Internet-Draft Protected AI Execution Finality October 2026 11.5.17. WF-05.17 — Independent Verification Predicate An illustrative executor-side verification condition is: PermitExecutor = Auth(C) AND Match(C,Dactual) AND ExecutorBound(C,E) AND GrantValid(C,G) AND StateValid(C,S) AND SinkBound(C,F) where: PermitExecutor denotes permission for the connector to perform the governed operation; C denotes the scoped execution capability; Dactual denotes the descriptor reconstructed from the operation actually presented; E denotes the authenticated privileged executor identity; G denotes the protected grant-state record; S denotes the required current authorization state; F denotes the designated Finality Sink; Auth verifies capability authenticity; Match verifies exact or expressly permitted bounded correspondence with the actual operation; ExecutorBound verifies the permitted executor identity or attestation; GrantValid verifies the required grant reservation, version, and usage conditions; Das Expires 19 April 2027 [Page 233] Internet-Draft Protected AI Execution Finality October 2026 StateValid verifies the mandatory policy, revocation, freshness, and protected-state conditions; SinkBound verifies the permitted effectuation boundary. The connector proceeds only if PermitExecutor is true. Where one protected component performs both authorization and local effectuation, the required verification may be implemented as a distinct protected verification operation within that component. Independent verification describes the required enforcement function and does not necessarily require a separate physical computer. 11.5.18. WF-05.18 — Cross-Component Authorization Consistency Where multiple components participate in one governed operation, the system ensures that each participating enforcement component verifies the authorization attributes required for its role. For example, the PED, credential broker, privileged connector, network gateway, and receiving-side Finality Sink may each require correspondence to the same underlying Candidate Act. A representative common authorization commitment comprises: operation_id; canonical_descriptor_digest; authority_object_reference; authorization_state_version; policy_epoch; revocation_epoch; permitted_operation_scope; authorized_finality_boundary; protected_validation_receipt_reference. Each component validates the common commitment and any additional component-specific restrictions. Das Expires 19 April 2027 [Page 234] Internet-Draft Protected AI Execution Finality October 2026 Where different components use separate capability artifacts, those artifacts are cryptographically or otherwise protectedly bound to the same underlying authorized operation and to their respective permitted execution boundaries. The system does not infer authorization for one component solely from another component's successful verification. 11.5.19. WF-05.19 — Mathematical Cross-Component Consistency Condition Let: D denote the authorized canonical Candidate Act Descriptor; hD denote its authenticated commitment; Cj denote the execution-enablement artifact verified by component j; Ej denote the authenticated execution identity of component j; Fj denote the effectuation boundary governed by component j; Sj denote the protected authorization state required by component j; j denote a component index from 1 through m; m denote the number of participating enforcement components. For a component requiring the common descriptor commitment, the local consistency condition may be represented as: Consistent(j) = Auth(Cj) AND DescriptorBound(Cj,hD) AND ComponentBound(Cj,Ej) AND BoundaryBound(Cj,Fj) AND StateValid(Cj,Sj) where: Auth verifies the authenticity of the component's authorization artifact; Das Expires 19 April 2027 [Page 235] Internet-Draft Protected AI Execution Finality October 2026 DescriptorBound verifies correspondence to the common authorized operation; ComponentBound verifies the authorized execution component; BoundaryBound verifies the component's permitted effectuation boundary; StateValid verifies the required protected authorization state. For an operation requiring verification by all designated components: PermitFinal = Consistent(1) AND Consistent(2) AND ... AND Consistent(m) This mathematical expression models a conjunctive multi-component authorization arrangement. Where components verify distinct stages or operations, the applicable authorization dependencies are specified for those stages rather than assuming that every component verifies every unrelated operation. The existence of a common descriptor commitment does not itself establish distributed-state consistency. The implementation also enforces the required state-version, revocation, freshness, and consumption conditions. 11.5.20. WF-05.20 — Protection Against Cross-Component State Drift Authorization state may change while an operation progresses among components. Examples include: (a) policy revision; (b) revocation of agent authority; (c) connector identity change; (d) credential revocation; (e) grant consumption; (f) destination substitution; (g) workload replacement; Das Expires 19 April 2027 [Page 236] Internet-Draft Protected AI Execution Finality October 2026 (h) expiration of an execution capability; or (i) change in required Finality Sink identity. To prevent authorization under incompatible state, each applicable Finality Sink verifies its required current state or an acceptable protected state commitment immediately before effectuation. For a strict revocation guarantee, the enforcement arrangement may require an online protected-state check, an authenticated revocation fence, or another mechanism that prevents acceptance of a capability after the relevant invalidating transition. Where bounded-staleness authorization is expressly permitted, the system enforces the specified validity interval and freshness limits. If required state cannot be obtained or verified, the affected operation is withheld. The system does not assume that eventually consistent caches provide instantaneous revocation across all nodes. 11.5.21. WF-05.21 — Authorization Epoch and Revocation Fence In one implementation, the protected authorization state includes an execution or policy epoch. A capability is bound to the epoch that formed part of its required authorization. A protected policy or revocation change advances the relevant epoch or another authenticated state-generation value. Before effectuation, the Finality Sink compares the capability-bound epoch with the epoch permitted by current protected state. An illustrative condition is: EpochValid = AcceptedEpoch(C.epoch, CurrentState) where: EpochValid denotes whether the capability's bound epoch remains acceptable; C.epoch denotes the epoch referenced by the capability; Das Expires 19 April 2027 [Page 237] Internet-Draft Protected AI Execution Finality October 2026 CurrentState denotes the protected policy and revocation state consulted by the verifier; AcceptedEpoch denotes the protected rule determining whether the bound epoch is currently valid. The rule need not require literal equality where an embodiment expressly permits an authorized transition window. For immediate invalidation requirements, the relevant sink must receive or verify the revocation fence before allowing another affected operation. A component unable to establish the required state does not treat a stale cached allow decision as sufficient. 11.5.22. WF-05.22 — Protection Against the Confused-Deputy Condition A privileged connector may have greater resource access than the agent that requests its services. An unauthorized agent could attempt to exploit this difference by persuading the connector to use its privileged authority for an operation outside the agent's permitted scope. The protected execution-finality mechanism prevents such authority substitution by requiring the connector to verify: (a) who requested the operation; (b) which operation was actually authorized; (c) which resources and credentials are permitted; (d) which protected grant authorizes the effect; (e) whether the grant remains valid; and (f) whether the actual effectuation boundary corresponds to the authorization. For example, an agent permitted to read a document through a restricted connector cannot use that connector's broader host privileges to modify unrelated enterprise records merely by constructing a different API request. The connector verifies operation-specific authority rather than relying solely upon its own service-account privileges. Das Expires 19 April 2027 [Page 238] Internet-Draft Protected AI Execution Finality October 2026 11.5.23. WF-05.23 — Credential and Resource Isolation Where PC-510 requires a credential, the credential may be maintained within CS-512 or a separately protected credential service. The connector obtains or uses the credential only in accordance with the applicable scoped authorization. The agent may possess a credential reference but cannot independently retrieve or apply unrestricted reusable credential material. In a non-exportable key embodiment, CS-512 performs a protected cryptographic operation after the required authorization conditions have been established. In an API-token embodiment, PC-510 applies a protected token to the validated service request through its controlled effectuation interface. Where a credential can be used against multiple services or tenants, the connector enforces the narrower operation-specific scope required by the corresponding capability. Detailed credential substitution and protected grant-state consumption are described in WF-04. 11.5.24. WF-05.24 — Final Operation Binding and Mutation Prevention The protected architecture verifies that the operation presented by PC-510 immediately before effectuation remains consistent with the authorized operation. For an API request, the connector may retain an immutable operation object comprising the selected destination, resource, method, permitted headers, body digest, authenticated tenant context, and credential scope. The connector derives its actual-operation descriptor from that controlled object. If a request transformation is required, such as inserting a protected credential, the implementation defines the permitted transformation and verifies that no unauthorized effectuation- relevant field has changed. If a request is modified after authorization in a manner outside the permitted scope, the capability cannot authorize the changed request. Das Expires 19 April 2027 [Page 239] Internet-Draft Protected AI Execution Finality October 2026 The system may employ protected immutable buffers, authenticated message objects, locked operation descriptors, controlled request construction, or other mechanisms appropriate to the execution environment. 11.5.25. WF-05.25 — Multiple Effectuation Boundaries A connector-mediated workflow may involve several consequential boundaries. For example: (a) the credential broker may authorize use of a protected signing key; (b) the connector may prepare an authenticated external request; (c) the network gateway may control actual transmission; and (d) a receiving service may control final database commitment. Each boundary may require its own capability or an expressly bounded authorization artifact that independently verifies against the relevant operation and sink. In a single-sink embodiment, one enforcement-controlled connector may perform the complete governed effectuation sequence. In a multi-sink embodiment, authorization to sign a request does not automatically authorize transmission through a different network boundary. Likewise, authorization to transmit does not independently authorize a receiving system to commit an unrelated or materially different operation. The system identifies the effectuation boundary actually controlled by each Finality Sink. 11.5.26. WF-05.26 — Illustrative End-to-End Privileged Connector Implementation In one concrete embodiment, an enterprise AI agent proposes creation of a customer-support record through a protected cloud application connector. The agent executes in an isolated container without direct access to the enterprise service's reusable API credential. Das Expires 19 April 2027 [Page 240] Internet-Draft Protected AI Execution Finality October 2026 The agent prepares an operation identifying the intended service, authorized tenant, customer reference, record type, request parameters, and permitted operation class. The operation is submitted to IB-502 and retained as CA-516 in a Non- Effective State. DC-504 constructs the canonical operation descriptor and binds the requesting workload, designated connector, target service, request parameters, authorization-state version, and Finality Sink identity. PED-505 obtains the applicable Authority Object. The protected validation verifies that: (a) the agent is permitted to request the operation; (b) the connector is approved for the target service; (c) the requested record type and resource scope are authorized; (d) the operation remains within its permitted purpose; (e) the protected policy and revocation conditions are valid; (f) the required credential scope is permitted; and (g) the protected grant remains available for the operation. PS-506 performs the required protected grant-state operation. EV-507 commits a validation record binding the canonical descriptor, grant state, and authorized connector. CR-508 releases an operation-specific capability bound to the protected commitment, executor identity, target service, authorization state, and designated Finality Sink. PC-510 receives the staged operation through an authenticated inter- component interface. The connector authenticates its own service identity or presents the required attestation evidence to the relevant verifier. IV-511 reconstructs the actual operation descriptor and verifies the capability against the current required protected state. Das Expires 19 April 2027 [Page 241] Internet-Draft Protected AI Execution Finality October 2026 Upon successful verification, the connector obtains or applies the protected service credential through CS-512. The connector prepares the authorized external API request without exposing reusable credential material to the AI agent. FS-513 independently verifies the required execution capability before the corresponding governed external service invocation. If the agent substitutes a different customer, operation type, target service, credential scope, or unauthorized request parameter, the required descriptor correspondence fails. If the connector's registered identity has changed incompatibly or its protected authorization state has been revoked, the operation is withheld. After the governed effectuation attempt, OS-514 records the appropriate confirmed, denied, or indeterminate outcome. The connector does not treat successful host authentication or possession of the service credential as authority to perform unrelated operations. 11.5.27. WF-05.27 — Alternative Host and Distributed Implementations Single-host implementation: The agent and connector execute as isolated processes. An authenticated local IPC interface transfers operation references and authorization artifacts. A protected host broker enforces the required Finality Sink checks. Hypervisor implementation: The agent executes within a guest VM, while the privileged connector resides in a protected host or service domain. A virtual-device or authenticated inter-domain interface mediates requests. Confidential-computing implementation: The connector or governance service operates within an attested confidential workload. The required attestation state is bound to the protected authorization conditions. Distributed implementation: The PED, connector, and effectuation gateway reside on separate nodes and communicate over authenticated channels. Each relevant effectuation component verifies the operation-specific commitment and required state. Das Expires 19 April 2027 [Page 242] Internet-Draft Protected AI Execution Finality October 2026 Service-mesh implementation: A workload proxy, sidecar, ingress controller, or egress gateway performs the applicable finality verification for service-to-service operations. Hardware-assisted implementation: A SmartNIC, DPU, protected network gateway, or other hardware-controlled interface verifies the required capability before enabling the governed output. Protected signing implementation: An HSM or secure enclave performs the authorized cryptographic operation without exporting the protected private key. Receiving-side implementation: A trusted receiving service independently verifies the operation-specific capability before applying the governed database, service, payment, or other consequential operation. These alternatives have different trust assumptions and enforcement strengths. They do not automatically provide equivalent resistance to privileged compromise, rollback, remote-node failure, or hardware attacks. 11.5.28. WF-05.28 — Failure, Timeout, and Recovery Handling The protected system operates fail-closed for mandatory authorization and verification conditions. A proposed connector operation is withheld when: (a) the connector identity cannot be authenticated; (b) mandatory attestation fails; (c) the requesting workload is unauthorized; (d) the actual operation differs from the validated operation; (e) the protected capability is missing or invalid; (f) the required grant-state version is inconsistent; (g) the capability has expired or been consumed; (h) required revocation state is unavailable or invalid; (i) the target service is unauthorized; (j) the required credential scope is invalid; Das Expires 19 April 2027 [Page 243] Internet-Draft Protected AI Execution Finality October 2026 (k) a participating component presents an incompatible authorization commitment; (l) a required receipt commitment cannot be verified; or (m) the corresponding Finality Sink verification fails. If a connector crashes before effectuation, the system consults the protected operation and capability state before authorizing further activity. If the connector crashes after possible external effectuation, the system distinguishes confirmed completion from indeterminate completion. An uncertain operation is not automatically replayed when doing so could cause an unauthorized duplicate effect. An authenticated receiving-side receipt, external idempotency mechanism, transaction-status query, or protected recovery procedure may assist with reconciliation. The workflow does not assume that arbitrary external services support globally atomic transactions or unconditional exactly-once execution. 11.5.29. WF-05.29 — PHOSITA Verification and Negative Tests A person having ordinary skill in operating-system security, distributed systems, protected credential management, authenticated IPC, API gateways, or cloud-native infrastructure may verify the embodiment through the following tests. Test 1 — Authorized connector operation: A valid agent request, connector identity, grant state, and scoped capability permit the authorized operation. Test 2 — Missing capability: A connector request lacking the required capability is refused. Test 3 — Unauthorized executor: A different process or service attempts to use a capability bound to another executor. Verification fails where executor binding is required. Test 4 — Identity spoofing: An untrusted caller supplies an approved connector name without authenticated identity evidence. The request is refused. Das Expires 19 April 2027 [Page 244] Internet-Draft Protected AI Execution Finality October 2026 Test 5 — Stale attestation: A connector presents an outdated or invalid required attestation. The attestation predicate fails. Test 6 — Operation substitution: The request body or effectuation- relevant resource changes after authorization. Descriptor verification fails. Test 7 — Credential-scope misuse: A connector attempts to apply a protected credential outside the authorized resource or service scope. Credential effectuation is refused. Test 8 — Cross-tenant substitution: A request is redirected to another tenant when tenant identity is mandatory. The authorization binding fails. Test 9 — Concurrent grant consumption: Two incompatible operations attempt to consume one single-use grant. The protected state mechanism prevents unauthorized double consumption. Test 10 — Cross-component epoch mismatch: A Finality Sink receives a capability bound to an incompatible policy or revocation epoch. Verification fails. Test 11 — Component restart: A privileged connector restarts with a changed required execution identity or measurement. Previously bound capabilities are rejected unless the protected authorization permits the new context. Test 12 — Lost protected-state service: The connector cannot establish a mandatory current protected-state condition. The operation remains non-effective. Test 13 — Unauthorized alternate route: The agent attempts to invoke the protected resource without passing through the governed connector or Finality Sink. The attempted bypass is prevented through the selected enforcement mechanism. Test 14 — Capability replay: A previously consumed operation-specific capability is presented again. The protected consumption condition refuses unauthorized reuse. Test 15 — Partial external completion: A connector crashes after possible request delivery. The operation is placed into an appropriate protected completion or recovery state instead of automatically generating an unrestricted duplicate attempt. Das Expires 19 April 2027 [Page 245] Internet-Draft Protected AI Execution Finality October 2026 Test 16 — Multi-sink verification: A capability restricted to one Finality Sink is presented at another governed boundary. It is rejected unless the applicable authorization expressly permits that boundary. Test 17 — Inconsistent authorization commitments: Two participating protected components receive commitments representing different required Candidate Act parameters. The final consequential operation remains withheld until consistency is restored through an authorized procedure. Test 18 — Revocation during a distributed operation: A protected revocation transition invalidates an outstanding capability. A Finality Sink requiring current revocation information refuses further effectuation under the invalidated state. Such tests may be performed using isolated agent processes, mock connectors, protected authorization services, authenticated IPC endpoints, simulated policy changes, test credentials, and controlled external-service interfaces. 11.5.30. WF-05.30 — Technical Effect The embodiment establishes a protected technical dependency between: (a) agent generation of a proposed connector operation; (b) mandatory interception; (c) Non-Effective State staging; (d) canonical Candidate Act Descriptor binding; (e) protected authority-predicate validation; (f) protected grant-state handling; (g) required validation-evidence commitment; (h) scoped non-bearer capability availability; (i) authenticated connector identity or attestation where required; (j) independent executor-side operation verification; (k) cross-component authorization consistency; (l) controlled credential or resource use; Das Expires 19 April 2027 [Page 246] Internet-Draft Protected AI Execution Finality October 2026 (m) Finality Sink verification; and (n) permitted effectuation or fail-closed refusal. The system prevents the authority held by a privileged connector from becoming unrestricted authority delegated to the artificial- intelligence agent. The system further prevents participating components from authorizing and effectuating materially different operations through inconsistent descriptors, incompatible authorization-state versions, stale grants, or improperly transferred capabilities. The essential protected dependency may be implemented through software isolation, firmware, cryptographic protection, hardware- rooted enforcement, or distributed protected components, subject to the guarantees required by the particular embodiment. Computation is not authority to act. Connector privilege is not transferable execution authority. A component's earlier approval is not a substitute for verification of the actual consequential operation at its applicable Finality Sink. 11.6. WF-06 — Untrusted-Input Provenance, Process-Lineage Influence Propagation, Taint-State Authorization Degradation, and Protected Egress Finality 11.6.1. WF-06.1 — Technical Purpose This embodiment provides a computer-implemented protected execution- finality system configured to prevent untrusted information encountered by an artificial-intelligence agent, application, tool, process, subprocess, or session from being promoted into unauthorized execution authority. The system maintains machine-verifiable provenance and influence information identifying the origin, trust classification, and permitted use of data or instructions encountered during execution. In certain embodiments, influence state is maintained at a context- unit or Candidate Act level. In further embodiments, the influence state is associated with an execution process, subprocess, thread group, agent session, workload, or execution lineage and propagated to subsequent execution contexts according to protected propagation rules. Das Expires 19 April 2027 [Page 247] Internet-Draft Protected AI Execution Finality October 2026 The propagated state influences the authorization conditions applicable to subsequent Candidate Acts. An operation previously eligible for a broader execution scope may become subject to narrower permissions, additional protected validation requirements, or denial following a defined interaction with untrusted information. The resulting system prevents an agent or its descendant execution contexts from obtaining execution authority inconsistent with a required protected influence state. The system distinguishes observation of untrusted information from authorization to obey instructions contained in that information. Untrusted material may be used as evidence, task data, or bounded computational input where permitted, but cannot independently override higher-trust instructions, modify protected authority, or authorize a consequential operation. 11.6.2. WF-06.2 — Participating Technical Components In one non-limiting embodiment, the system comprises: AE-601 — Agent Execution Environment An artificial-intelligence agent, model runtime, tool-execution environment, process, container, virtual machine, or autonomous workflow configured to receive and process information. IS-602 — Input and Source Classification Component A component configured to classify incoming data according to its authenticated source, provenance, trust tier, content class, and applicable instruction-authority restrictions. CB-603 — Connector Boundary Component A protected or enforcement-controlled retrieval, tool-response, application, or data-ingestion interface configured to record relevant source and retrieval-boundary information. IT-604 — Instruction Taint Boundary Object Manager A protected mechanism configured to construct, store, or verify an Instruction Taint Boundary Object (ITBO), including applicable instruction hierarchy, context trust classifications, taint rules, and trust-elevation conditions. Das Expires 19 April 2027 [Page 248] Internet-Draft Protected AI Execution Finality October 2026 LM-605 — Protected Lineage-State Manager A component configured to maintain or verify the influence state associated with a process, subprocess, session, agent runtime, or corresponding execution lineage. EM-606 — Execution-Event Monitor A mechanism configured to observe or mediate defined execution events, including data ingestion, process creation, session continuation, tool dispatch, IPC, or other events relevant to the protected influence-state rules. PS-607 — Protected State Store A protected or enforcement-controlled state mechanism maintaining lineage identities, influence records, authorization-state versions, policy epochs, and relevant receipt commitments. DC-608 — Candidate Act Descriptor Component A component configured to construct a Candidate Act Descriptor containing or referencing required provenance and influence information. PED-609 — Protected Enforcement Domain A protected authorization component configured to evaluate applicable Authority Objects, ITBO conditions, influence-state predicates, execution scope, and current protected authorization state. EV-610 — Protected Evidence Component A mechanism configured to generate or commit protected validation evidence, including an applicable LAVR, Egress LAVR, or authenticated validation commitment. CR-611 — Capability Release Component A protected mechanism configured to release or make available a scoped non-bearer execution capability following satisfaction of the required predicates. FS-612 — Finality Sink An enforcement-controlled interface configured to verify the required execution capability and applicable influence-state binding before allowing the consequential operation. Das Expires 19 April 2027 [Page 249] Internet-Draft Protected AI Execution Finality October 2026 RC-613 — Protected Recovery and Revalidation Component An optional mechanism configured to manage authorized state reset, fresh execution contexts, trust elevation, revocation, and recovery. The components may be colocated or distributed, provided that the required protected state and effectuation dependencies are maintained. 11.6.3. WF-06.3 — Instruction Trust Hierarchy The system establishes an applicable instruction trust hierarchy. In an embodiment using an ITBO, the hierarchy may distinguish: (a) constitutional or root authority conditions, where present; (b) provider or model-safety instructions; (c) operator, enterprise, or developer instructions; (d) authorized user instructions; (e) authorized tool outputs having bounded operational meaning; and (f) retrieved evidence, webpages, files, emails, external messages, document content, and other lower-trust information. The specific hierarchy may differ according to the application and Authority Object. A lower-trust content unit does not independently modify or supersede a higher-trust authority condition. For example, text retrieved from a webpage may provide factual information relevant to a user's task, but a command embedded in that webpage cannot independently expand the agent's tool permissions or authorize transmission of protected information. The ITBO identifies which content sources may provide evidence, which may supply bounded parameters, and which, if any, may exercise instruction authority under an expressly authorized trust-elevation condition. 11.6.4. WF-06.4 — Source and Context-Unit Identification Incoming information may comprise: Das Expires 19 April 2027 [Page 250] Internet-Draft Protected AI Execution Finality October 2026 (a) user instructions; (b) webpages; (c) retrieved documents; (d) email messages; (e) tool responses; (f) API responses; (g) package metadata; (h) source-code comments; (i) repository files; (j) vector-database records; (k) model-generated outputs; (l) browser document-object-model content; (m) clipboard content; (n) OCR or extracted document text; (o) memory records; or (p) another agent's message. Each relevant input is associated with a source reference or context- unit identifier. An illustrative context-unit record comprises: context_unit_id; source_identity; source_type; content_digest; retrieval_event_id; connector_identity; Das Expires 19 April 2027 [Page 251] Internet-Draft Protected AI Execution Finality October 2026 trust_tier; taint_classification; instruction_authority_flag; evidence_only_flag; tool_control_restriction; memory_write_restriction; permitted_data_scope; policy_epoch; freshness_reference. The record may identify the original content by digest or protected reference rather than retaining complete plaintext. A source-provided declaration of trust is not treated as independently authoritative unless the applicable authentication conditions have been satisfied. 11.6.5. WF-06.5 — Connector Boundary Receipt Where information is obtained through a governed retrieval or connector boundary, CB-603 may generate or obtain a Connector Boundary Receipt (CBR). The CBR associates retrieved information with the relevant retrieval request, source identity, admitted or excluded content, authorized retrieval scope, and applicable provenance or taint conditions. An illustrative CBR record may contain: cbr_id; retrieval_operation_id; connector_identity; source_reference; retrieved_object_digest; source_class; Das Expires 19 April 2027 [Page 252] Internet-Draft Protected AI Execution Finality October 2026 trust_tier; admission_result; taint_classification; permitted_use_scope; policy_epoch; protected_authentication. The CBR establishes evidence concerning the governed retrieval boundary. It does not, by itself, authorize instructions contained within the retrieved material to modify protected authority. For example, the retrieval of a webpage may be authorized, while execution of a shell command appearing in that webpage remains unauthorized. 11.6.6. WF-06.6 — Construction of the Instruction Taint Boundary Object IT-604 constructs or verifies the ITBO applicable to the agent session or execution context. A representative ITBO includes or securely references: instruction_hierarchy_digest; higher_authority_digest; approved_user_instruction_scope; context_trust_map; evidence_content_root; connector_receipt_references; trust_elevation_rules; taint_propagation_rules; prohibited_instruction_promotions; injection_classification_state; Das Expires 19 April 2027 [Page 253] Internet-Draft Protected AI Execution Finality October 2026 policy_epoch; revocation_epoch; nonce; protected_authentication. The ITBO is maintained under control of the applicable PED or other protected authority. An agent cannot create instruction authority merely by rewriting a context label, fabricating a source identity, or declaring an external document to be trusted. Where cryptographically protected, the ITBO may comprise a signed object, authenticated commitment, protected record, Merkle-rooted trust map, or equivalent representation. The specific cryptographic encoding depends upon the selected implementation. 11.6.7. WF-06.7 — Influence-State Representation in an implementation supporting enforcement point 25, LM-605 maintains a protected influence state associated with an execution context. Let: p denote an identified process, subprocess, agent session, or other monitored execution context; t denote a logical event or state version; L(p,t) denote the protected influence state associated with p at version t. The influence state may be represented as a set of influence labels rather than a single Boolean taint bit. Illustrative labels include: UNTRUSTED_WEB_CONTENT; UNTRUSTED_EMAIL_CONTENT; EXTERNAL_TOOL_RESPONSE; Das Expires 19 April 2027 [Page 254] Internet-Draft Protected AI Execution Finality October 2026 UNVERIFIED_INSTRUCTION_ATTEMPT; SENSITIVE_DATA_EXPOSURE; UNTRUSTED_CODE_INPUT; UNKNOWN_PROVENANCE; TRUST_ELEVATION_PENDING. The labels describe source influence and applicable restrictions. Their presence does not necessarily establish that malicious behavior has occurred. An illustrative protected lineage record comprises: lineage_identity; parent_lineage_identity; workload_identity; execution_identity; process_generation; session_identity; influence_labels; source_receipt_references; state_version; policy_epoch; last_protected_event; protected_authentication. The influence-state record is maintained outside direct modification authority controlled by the untrusted agent. 11.6.8. WF-06.8 — Secure Execution-Lineage Identity The system identifies the process or session to which an influence state belongs. Das Expires 19 April 2027 [Page 255] Internet-Draft Protected AI Execution Finality October 2026 In a process-based implementation, a lineage identity may be derived from a combination of: (a) process identifier; (b) process-namespace identity; (c) process creation generation or start reference; (d) authenticated parent identity; (e) container or workload identity; (f) executable identity; (g) execution-session identifier; and (h) an authenticated event reference. The system does not rely solely upon an operating-system process identifier where that identifier can be reused after a process terminates. A logical lineage identifier may be assigned at process creation and retained across authorized execution-state transitions. Where multiple threads share a common process address space or relevant agent context, the embodiment may maintain a shared influence state for the thread group. The particular lineage granularity is selected according to the execution and threat model. 11.6.9. WF-06.9 — Initial Influence-State Assignment When a new execution context is established, LM-605 assigns an initial protected influence state. The initial state may depend upon: (a) the authenticated workload identity; (b) the creating execution context; (c) inherited influence state; (d) initial process inputs; Das Expires 19 April 2027 [Page 256] Internet-Draft Protected AI Execution Finality October 2026 (e) restored session or memory state; (f) approved workflow configuration; and (g) the applicable protected policy. A newly created process is not automatically treated as free from untrusted influence merely because it has a new process identifier. A genuinely fresh execution context having no inherited untrusted inputs may receive a policy-defined baseline state. A child process created from an influenced parent receives the state required by the protected propagation rules. A restored workload receives an influence state consistent with its protected session and recovery information. 11.6.10. WF-06.10 — Defined Untrusted-Information Interaction Events EM-606 identifies events that may modify an execution context's protected influence state. A defined interaction event may comprise: (a) receiving an external tool result; (b) reading retrieved webpage content; (c) ingesting an email or document; (d) incorporating a retrieved chunk into an AI model context; (e) parsing an untrusted configuration or package manifest; (f) receiving an IPC message containing lower-trust material; (g) loading untrusted code or a script; (h) importing untrusted memory content; (i) receiving an agent message having an applicable lower-trust classification; or (j) another policy-defined information-consumption event. A mere attempted read need not be treated identically to successful ingestion unless the applicable policy requires that treatment. Das Expires 19 April 2027 [Page 257] Internet-Draft Protected AI Execution Finality October 2026 The event monitor distinguishes, where technically possible, data discovery, attempted access, successful receipt, actual consumption, and subsequent use. Where the implementation cannot reliably determine actual semantic influence, the policy may conservatively classify receipt or availability within an execution context as sufficient to trigger the corresponding influence state. The selected rule is specified by the implementation rather than presumed. 11.6.11. WF-06.11 — Protected Influence-State Update When a defined interaction event occurs, LM-605 updates the protected influence state. Let: L(p,t) denote the influence-label set for execution context p before event t; e denote the observed or mediated event; Labels(e) denote the influence labels assigned to event e; U denote the protected update function. The next influence state may be expressed as: L(p,t+1) = U(L(p,t), Labels(e)) In a conservative accumulating-label implementation: L(p,t+1) = L(p,t) ∪ Labels(e) where: ∪ denotes set union. The operation preserves existing applicable influence labels and adds labels associated with the newly observed event. For example, a process that has incorporated untrusted webpage content may acquire the UNTRUSTED_WEB_CONTENT label. A later read of an untrusted email may additionally add UNTRUSTED_EMAIL_CONTENT. Das Expires 19 April 2027 [Page 258] Internet-Draft Protected AI Execution Finality October 2026 The label update does not itself authorize or deny every possible operation. Instead, the resulting protected influence state becomes an input to applicable authorization predicates. 11.6.12. WF-06.12 — Process Creation and Descendant Propagation In an embodiment supporting process-lineage influence propagation, EM-606 monitors or mediates a defined process-creation event. Such events may comprise process fork, supported clone operations, subprocess creation, worker creation, agent-worker spawning, container-child creation, or equivalent execution branching. When a child execution context is created, LM-605 establishes a protected lineage record associating the child with its parent. Let: p denote a parent execution context; q denote a newly created child execution context; L(p,t) denote the parent's protected influence state; Lspawn denote any additional influence labels applicable to the creation event; L(q,t+1) denote the child's initial protected influence state. A non-limiting inheritance rule is: L(q,t+1) = L(p,t) ∪ Lspawn Under this rule, the child inherits the influence restrictions applicable to the parent at the protected creation boundary. The creation of a child process does not automatically restore a broader authorization scope that was unavailable to the parent. If a higher-assurance implementation requires particular source categories, credentials, session data, or shared-memory inputs to remain associated with the child, those bindings are included in the protected lineage record. Das Expires 19 April 2027 [Page 259] Internet-Draft Protected AI Execution Finality October 2026 11.6.13. WF-06.13 — Process Execution and Image Replacement Some operating systems permit a process to replace its executable image while retaining a process identity or selected resources. In such an embodiment, an executable-image replacement does not automatically erase protected influence state. A new executable identity may be measured or authenticated, but the existing lineage influence state remains applicable unless a protected reset or state-transition rule authorizes a different result. For example, an agent runtime that has incorporated untrusted webpage instructions cannot restore a broader execution authorization simply by launching a shell or replacing its own executable image. Where an execution transition deliberately creates a new isolated context with no inherited untrusted state, the applicable protected authority validates that isolation and state reset before assigning the new baseline. 11.6.14. WF-06.14 — Session, Agent, and Worker-Lineage Propagation The influence-state mechanism is not limited to conventional operating-system processes. In an AI agent implementation, the relevant execution context may comprise: (a) an agent session; (b) a tool-execution session; (c) an agent worker; (d) a subordinate agent; (e) a model-context instance; (f) a workflow branch; (g) a serverless invocation; (h) a browser automation context; or (i) another logical execution unit. Das Expires 19 April 2027 [Page 260] Internet-Draft Protected AI Execution Finality October 2026 Where a workflow spawns another agent or worker and transfers influenced context, the protected system associates the receiving execution context with the applicable source lineage. A newly created subordinate agent does not become authorized to disregard a required influence restriction merely because it executes in another process or container. Delegated execution authority remains subject to the scope restrictions of the corresponding Delegation Authority Object and the relevant downstream Candidate Act authorization. 11.6.15. WF-06.15 — IPC, Shared Memory, and Cross-Process Information Transfer The implementation may propagate influence state when information is transferred between execution contexts. Relevant mechanisms include: (a) authenticated IPC messages; (b) operating-system pipes; (c) local socket communication; (d) shared-memory regions; (e) file-descriptor transfer; (f) controlled file reads; (g) message queues; (h) tool-response channels; (i) connector responses; and (j) equivalent data-transfer mechanisms. Where a receiving process ingests information carrying an applicable influence label, LM-605 updates the receiver's protected influence state according to the selected propagation rule. A data-transfer record may identify: source_lineage_id; Das Expires 19 April 2027 [Page 261] Internet-Draft Protected AI Execution Finality October 2026 destination_lineage_id; transfer_event_id; data_reference; source_influence_state; transfer_class; policy_epoch; protected_state_version. An implementation relying on operating-system instrumentation must account for the information-transfer paths it actually supports. A kernel event alone does not necessarily reveal application-level meaning or prove whether particular data influenced an AI model's reasoning. Where complete fine-grained tracking is unavailable, the system may conservatively mark the receiving context as influenced and apply the corresponding protected authorization restrictions. 11.6.16. WF-06.16 — Protected Event-Update Ordering In a concurrent execution environment, information ingestion and process creation may occur close together. The implementation prevents an unauthorized gap in which a child process receives influenced data but is assigned an incompatible broader authorization state. In one embodiment, lineage creation and influence-state inheritance are coordinated through a protected event-generation mechanism. The event-generation value is advanced when a protected influence- state transition occurs. A child-lineage record identifies the parent state version used for inheritance. If the required parent-state version cannot be established, the child is assigned a conservative restricted state or the relevant authorization is withheld pending reconciliation. Das Expires 19 April 2027 [Page 262] Internet-Draft Protected AI Execution Finality October 2026 The system may use protected locks, atomic compare-and-update operations, serialized event processing, or another concurrency mechanism appropriate to the protected state store. A child process does not acquire broader authority merely because the corresponding lineage-state update was delayed. 11.6.17. WF-06.17 — Influence-Based Authorization Degradation The protected influence state modifies the authorization scope or validation requirements applicable to later Candidate Acts. Let: BaseScope(p,a) denote the execution scope otherwise available to execution context p for Candidate Act a; InfluenceScope(L,a) denote the restrictions applicable to act a under influence state L; EffectiveScope(p,a) denote the actual scope available after applying those restrictions. A non-limiting rule is: EffectiveScope(p,a) = BaseScope(p,a) ∩ InfluenceScope(L(p),a) where: ∩ denotes the intersection of permitted operation sets. Accordingly, the effective authorization scope cannot exceed either the original permitted scope or the scope permitted by the protected influence restrictions. For example, a policy may permit an agent to retrieve public information under ordinary authorization conditions. After the agent ingests untrusted content containing an instruction to transmit protected files, a subsequent sensitive file-export operation may require additional protected approval or be prohibited. A lower-risk operation, such as producing a bounded summary, may remain permitted if the corresponding predicates succeed. The system does not require every tainted process to be permanently denied every operation. Das Expires 19 April 2027 [Page 263] Internet-Draft Protected AI Execution Finality October 2026 11.6.18. WF-06.18 — Removal of a Broader Authorization Lane In one specific implementation, the protected policy defines a restricted automatic authorization lane for particular operation classes. Such a lane may be available only when required source-influence, workload, operation, and protected-state conditions are satisfied. Upon detecting a defined untrusted-information interaction, LM-605 updates the influence state. The updated influence state causes subsequent operations to become ineligible for the broader lane where the protected policy so requires. A representative rule is: AutoLaneEligible(p,a) = BaseEligible(p,a) AND CleanForClass(L(p),a) AND StateCurrent(p) where: AutoLaneEligible denotes eligibility for the restricted automatic authorization lane; BaseEligible denotes whether the operation otherwise qualifies for that lane; CleanForClass denotes whether the current influence state satisfies the required conditions for the operation class; StateCurrent denotes whether the required protected state and policy epoch remain valid. If AutoLaneEligible is false, the operation is not permitted through that lane. The operation may be denied or subjected to a different protected authorization procedure, including explicit approval where permitted. Das Expires 19 April 2027 [Page 264] Internet-Draft Protected AI Execution Finality October 2026 Even when a lane is available, the corresponding Finality Sink remains subject to the execution-capability requirements imposed by the applicable embodiment. 11.6.19. WF-06.19 — Candidate Act Formation Following Untrusted Input An influenced process or agent may propose a subsequent consequential operation. Examples include: (a) a shell command; (b) a network request; (c) a credential-mediated connector call; (d) a memory write; (e) a model or workflow mutation; (f) a database update; (g) an autonomous purchase; (h) a delegated-agent task; (i) a file operation; or (j) another externally effective act. The operation is classified as Candidate Act CA-614. The Candidate Act Descriptor includes or securely references the required source-lineage and influence-state information. An illustrative descriptor comprises: candidate_act_id; requesting_workload; requesting_lineage_id; operation_class; destination; Das Expires 19 April 2027 [Page 265] Internet-Draft Protected AI Execution Finality October 2026 operation_parameters; input_provenance_root; taint_lineage_reference; ITBO_reference; CBR_reference; influence_state_version; policy_epoch; authority_reference; finality_sink_id. The Candidate Act remains in a Non-Effective State until the required protected validation is complete. 11.6.20. WF-06.20 — Candidate Act Provenance and Influence Validation PED-609 receives or reconstructs the Candidate Act Descriptor and the required protected influence-state references. The PED evaluates whether the act depends upon an unauthorized promotion of lower-trust content into execution authority. The validation may distinguish: (a) data used as evidence; (b) data used as permitted operation parameters; (c) content used as an instruction; (d) content attempting to modify authority; (e) content influencing a protected credential operation; (f) content attempting to alter workflow or policy state; and (g) content whose influence cannot be established to the level required by the applicable authority. Das Expires 19 April 2027 [Page 266] Internet-Draft Protected AI Execution Finality October 2026 A retrieved document may be permitted to supply factual information for summarization without being permitted to command the agent to send credentials or modify protected policy. Where the act depends on an unauthorized instruction source, the ITBO predicate fails. Where the required provenance or influence state cannot be verified, the affected act remains non-effective. 11.6.21. WF-06.21 — Instruction Taint Boundary Predicate The protected ITBO predicate evaluates whether the Candidate Act is consistent with the permitted instruction hierarchy and influence restrictions. Let: D denote the Candidate Act Descriptor; I denote the applicable protected ITBO; L denote the protected influence state; A denote the applicable Authority Object; S denote the required protected authorization state. An illustrative predicate is: Ptaint = AllowedInfluence(D,I,L,A,S) where: Ptaint denotes the taint and instruction-authority validation result; AllowedInfluence denotes the protected procedure that evaluates whether the sources influencing the proposed act may legitimately contribute to that operation. The predicate may return true for an authorized summarization of untrusted material while returning false for an unauthorized command derived from the same material. This distinguishes the presence of untrusted input from unauthorized reliance upon that input as execution authority. Das Expires 19 April 2027 [Page 267] Internet-Draft Protected AI Execution Finality October 2026 Where probabilistic prompt-injection classifiers are used, their results may form part of the predicate inputs, but do not independently release the execution capability. 11.6.22. WF-06.22 — Protected Trust Elevation Some lower-trust content may legitimately need to contribute instructions or operation parameters within an authorized scope. In an embodiment employing the original DAS Trust Elevation Token mechanism, a protected authority issues or verifies a token authorizing a defined elevation. The token may bind: source_identity; content_digest; requested_trust_tier; permitted_instruction_scope; permitted_tool_scope; permitted_act_class; authority_issuer; CBR_reference; session_authority_reference; policy_epoch; revocation_epoch; nonce; expiry. PED-609 verifies the token against the corresponding source content, required issuer authority, requested elevation scope, and current protected state. Successful elevation applies only within the permitted bounds. Das Expires 19 April 2027 [Page 268] Internet-Draft Protected AI Execution Finality October 2026 A token authorizing one document's structured routing information does not automatically elevate all content read by the same process. Trust elevation does not permit violation of mandatory higher-tier authority constraints. 11.6.23. WF-06.23 — Protected Revalidation and Influence-State Reset In certain embodiments, a protected recovery procedure may permit the creation of a new execution context or the reclassification of a bounded context after satisfying specified conditions. Such conditions may include: (a) termination of the influenced execution context; (b) creation of a fresh isolated workload; (c) removal of inherited untrusted context from the new workload; (d) verification of the new workload's identity or configuration; (e) re-establishment of protected authority; (f) reconciliation of pending Candidate Acts; (g) advancement of an authorization-state version; and (h) issuance of new scoped capabilities where permitted. An agent cannot restore broader authority merely by clearing a user- space taint flag, changing its process name, restarting a tool, or copying its own state into a newly spawned process. Where the required clean-context conditions cannot be established, the corresponding restricted influence state remains applicable. 11.6.24. WF-06.24 — Binding Influence State to the Scoped Execution Capability Following successful protected validation, PED-609 performs the required protected-state and validation-evidence commitment operations. The corresponding scoped non-bearer execution capability may be bound to: candidate_act_digest; Das Expires 19 April 2027 [Page 269] Internet-Draft Protected AI Execution Finality October 2026 requesting_lineage_id; influence_state_version; ITBO_commitment; CBR_reference; authorization_scope; policy_epoch; revocation_epoch; nonce; expiry; finality_sink_id. An illustrative capability commitment is: C = Auth_PED(D, Lversion, Iroot, Scope, Epoch, F, N) where: C denotes the authenticated execution capability or protected capability reference; Auth_PED denotes an authenticated capability-generation procedure controlled by the PED; D denotes the authorized Candidate Act Descriptor or its digest; Lversion denotes the protected influence-state version associated with the validated operation; Iroot denotes the required ITBO or context-trust commitment; Scope denotes the permitted execution scope; Epoch denotes the applicable protected policy epoch; F denotes the authorized Finality Sink; N denotes a nonce or other required freshness value. Das Expires 19 April 2027 [Page 270] Internet-Draft Protected AI Execution Finality October 2026 The particular authentication mechanism may employ a signature, MAC, sealed capability, protected register, or equivalent enforcement- controlled artifact. The capability remains subject to the relevant Finality Sink verification. 11.6.25. WF-06.25 — Prevention of Stale Broader-Authority Reuse If a process's influence state changes after a capability has been prepared or issued, the system determines whether the changed state invalidates a mandatory capability condition. For example, a capability may have been authorized while a process satisfied a restricted clean-context condition. The process subsequently ingests untrusted instructions, causing the protected influence-state version to advance. Where the capability requires the earlier clean-context condition, the capability is no longer accepted for effectuation under the incompatible state. An illustrative verification rule is: StateMatch = Compatible(C.lineage_version, CurrentLineageState) AND PolicyCurrent(C.policy_epoch) AND ScopeStillValid(C,CurrentLineageState) where: StateMatch denotes whether the capability remains valid under the required protected influence and authorization state; C.lineage_version denotes the influence-state version bound to the capability; CurrentLineageState denotes the current protected lineage state; PolicyCurrent verifies the applicable policy epoch condition; ScopeStillValid verifies that the capability's permitted operation remains authorized under the current required influence restrictions. Das Expires 19 April 2027 [Page 271] Internet-Draft Protected AI Execution Finality October 2026 A changed lineage-state version does not necessarily invalidate every capability if the applicable policy expressly permits compatible state transitions. Where the changed state removes the authority required for the act, the Finality Sink rejects the affected capability. 11.6.26. WF-06.26 — Independent Finality Sink Verification FS-612 receives the Candidate Act and its corresponding execution capability. The Finality Sink verifies the required operation, execution context, authority scope, protected state, and influence-state binding. An illustrative finality predicate is: Permit = Auth(C) AND ActMatch(C,Dactual) AND InfluenceValid(C,Lcurrent) AND ScopeValid(C,A) AND StateValid(C,S) AND SinkValid(C,F) where: Permit denotes permission to perform the governed consequential operation; Auth verifies capability authenticity; ActMatch verifies correspondence with the actual Candidate Act; InfluenceValid verifies the required protected lineage and influence- state conditions; ScopeValid verifies the permitted operation under the Authority Object; StateValid verifies the required policy, revocation, freshness, and capability-consumption state; Das Expires 19 April 2027 [Page 272] Internet-Draft Protected AI Execution Finality October 2026 SinkValid verifies the applicable Finality Sink identity; Dactual denotes the operation actually presented for effectuation; Lcurrent denotes the required current protected influence state; S denotes protected authorization state; F denotes the Finality Sink performing verification. If any mandatory condition fails, the Candidate Act remains non- effective through the governed execution path. 11.6.27. WF-06.27 — Concrete Process-Lineage Example In one illustrative implementation, an AI agent runs within an isolated container and is authorized to summarize public webpages. The agent's protected authorization policy permits web retrieval and bounded summarization. Certain sensitive operations, including credential-backed document export and privileged host modification, require separate authorization and are not permitted solely through the ordinary retrieval workflow. The agent retrieves a webpage through a controlled browser or retrieval connector. The retrieved material contains an embedded instruction directing the agent to transmit a confidential local file to an external destination. The retrieval component records the source identity and content digest. The protected ITBO classifies the material as lower-trust evidence- only content and records the attempted instruction-authority promotion. The protected influence-state manager updates the agent session's influence state with the applicable untrusted-web-content and instruction-attempt labels. The agent subsequently creates a child tool process to perform a proposed action. Das Expires 19 April 2027 [Page 273] Internet-Draft Protected AI Execution Finality October 2026 The protected lineage manager associates the child process with the parent's protected influence state. The inherited state does not permit the child to regain a broader execution scope merely by executing in a separate process. The child attempts to invoke a connector that would transmit the confidential file. The connector request is intercepted and classified as a Candidate Sandbox Egress Act. The Candidate Act Descriptor identifies the requested operation, destination, file reference, requesting workload, child-lineage identity, influence-state reference, policy epoch, and applicable Finality Sink. The PED obtains the relevant Authority Object, ITBO, source- provenance information, and protected lineage record. The protected validation determines that the attempted file transmission relies upon untrusted content acting outside its authorized evidence role and that the requested operation is outside the applicable authority scope. The protected predicate fails. No valid scoped execution capability is released for the rejected operation. The network or connector Finality Sink therefore refuses the proposed transmission. The agent may continue performing a permitted summary of the webpage if the corresponding authorized operation satisfies its own required protected predicates. The system does not equate reading the webpage with authorization to obey instructions embedded in it. 11.6.28. WF-06.28 — Process-Lineage Implementation Variants The influence-state mechanism may be implemented through several alternative technical arrangements. Das Expires 19 April 2027 [Page 274] Internet-Draft Protected AI Execution Finality October 2026 Kernel-assisted variant: Operating-system event hooks, kernel security modules, process-creation mediation, or suitable eBPF mechanisms provide event information or enforcement for selected file, process, socket, and IPC operations. A protected state service maintains the corresponding authorization-relevant lineage state. Hypervisor-assisted variant: A hypervisor or protected virtual- machine service associates execution contexts and selected information-transfer events with protected lineage records. Application-runtime variant: A trusted agent runtime or tool broker records retrieval, context ingestion, tool invocation, worker creation, and session propagation events. Connector-mediated variant: All governed retrieval and connector- response interfaces assign protected provenance records and update the consuming workload's influence state. Hybrid variant: Application-level provenance tracking is combined with operating-system event monitoring and protected effectuation gating. Session-based variant: The influence state is associated with an AI session, model context, or tool-execution session rather than an individual operating-system process. These implementations may provide different levels of granularity and completeness. A low-level process monitor does not automatically establish semantic attribution of individual model outputs. The embodiment therefore specifies the events and data paths on which its influence guarantee depends. 11.6.29. WF-06.29 — Completeness and Conservative Attribution In certain implementations, the system may not be able to identify precisely which model token, webpage sentence, or memory fragment causally influenced a generated action. Where exact causal attribution is unavailable, the system may conservatively maintain influence labels for all lower-trust material admitted into the relevant model context or execution lineage. For example, a session that incorporates an untrusted document may be treated as influenced by that document for subsequent operations governed by the corresponding policy. Das Expires 19 April 2027 [Page 275] Internet-Draft Protected AI Execution Finality October 2026 The system may permit lower-risk actions without requiring complete causal-source proof, while requiring stronger provenance verification or separate authorization for sensitive consequences. An embodiment claiming comprehensive process-lineage tracking must also address relevant data-ingestion and transfer paths, including shared memory, inherited file descriptors, persistent files, workload restoration, IPC, and alternative tool channels. If a required monitoring path is unavailable or untrusted, the protected enforcement mechanism withholds the affected authority or applies the designated conservative restrictions. The system does not claim perfect semantic influence attribution merely from process-level monitoring. 11.6.30. WF-06.30 — Crash, Restart, and Lineage-State Continuity Protected influence state is maintained so that an untrusted process cannot restore broader authorization by crashing or restarting. Where process identifiers are reused, the lineage manager distinguishes different process generations. Where a virtual machine or container is restored from a snapshot, the implementation reconciles the restored execution context with the protected lineage and authorization state. Previously invalidated or consumed capabilities are not restored merely because a saved runtime image contains an older representation. A restarted process or recovered agent session receives the influence state required by the applicable protected recovery rules. Where a required lineage state cannot be reconstructed consistently, subsequent affected Candidate Acts remain non-effective pending protected revalidation. 11.6.31. WF-06.31 — Failure and Fail-Closed Handling The system refuses an affected Candidate Act when a mandatory influence or authority condition cannot be verified. Non-limiting failures include: (a) missing required provenance; Das Expires 19 April 2027 [Page 276] Internet-Draft Protected AI Execution Finality October 2026 (b) invalid CBR authentication; (c) inconsistent ITBO; (d) unauthorized instruction elevation; (e) missing protected lineage state; (f) unverifiable parent-child relationship; (g) failed required influence-state propagation; (h) stale lineage-state version; (i) unauthorized authority-scope expansion; (j) unavailable required protected event state; (k) incompatible policy epoch; (l) invalid capability; (m) operation mismatch; or (n) failed Finality Sink verification. Where permitted, the operation may be retained for review, denied, quarantined, or subjected to a separately authorized revalidation procedure. A prompt-injection classifier result, ordinary audit record, or process taint flag does not independently authorize a consequential operation. 11.6.32. WF-06.32 — PHOSITA Verification and Negative Tests The described implementation may be evaluated through controlled process, session, provenance, and authorization tests. Test 1 — Authorized evidence use: Supply an untrusted document for summarization. Verify that the document may be used as permitted evidence without obtaining instruction authority. Test 2 — Embedded instruction attack: Include an instruction to transmit protected data in lower-trust content. Verify that the required ITBO predicate rejects the unauthorized Candidate Act. Das Expires 19 April 2027 [Page 277] Internet-Draft Protected AI Execution Finality October 2026 Test 3 — Process inheritance: Cause an influenced parent process to create a child. Verify that the required influence labels are inherited. Test 4 — Subprocess execution: Cause an influenced process to invoke a shell or replace its executable image. Verify that the required lineage restrictions are not automatically cleared. Test 5 — IPC propagation: Transfer lower-trust information to another process through a monitored IPC channel. Verify the required receiving-lineage update. Test 6 — Session propagation: Spawn a subordinate agent or tool session with influenced context. Verify the required state association. Test 7 — Authorization degradation: Attempt an operation previously eligible for a broader authorization lane after a disqualifying influence event. Verify that the broader lane is unavailable. Test 8 — Valid trust elevation: Supply a protected Trust Elevation Token covering a specific permitted source and operation. Verify authorization only within the token's scope. Test 9 — Invalid trust elevation: Modify the content or requested elevation scope. Verify token rejection. Test 10 — Agent-controlled taint reset: Attempt to clear the influence state through an untrusted agent-controlled interface. Verify that protected state remains authoritative. Test 11 — Process identifier reuse: Terminate a process and create another with a reused process identifier. Verify that lineage generation prevents identity confusion. Test 12 — Concurrent ingestion and spawn: Cause untrusted information ingestion concurrently with child creation. Verify that the protected state protocol prevents an unauthorized broader child scope. Test 13 — Capability-state race: Issue a capability, then update the influence state before effectuation. Verify that the Finality Sink enforces the required current state. Test 14 — Snapshot restoration: Restore an earlier execution snapshot and attempt to reuse an invalidated capability. Verify refusal under protected state. Das Expires 19 April 2027 [Page 278] Internet-Draft Protected AI Execution Finality October 2026 Test 15 — Monitoring failure: Disable a monitoring component needed for a mandatory influence predicate. Verify fail-closed handling of the affected operation. Test 16 — Bounded permitted action: Following ingestion of untrusted material, propose an operation permitted under the restricted scope. Verify that successful protected validation may still authorize that operation. Test 17 — Cross-lineage capability misuse: Present an operation- specific capability from another execution lineage. Verify rejection where lineage identity is mandatory. Test 18 — Downstream Finality Sink: Verify that the actual externally effective operation cannot proceed merely because an upstream process or model completed computation. These tests may use isolated processes, mock retrieval sources, controlled prompts, process-creation instrumentation, protected lineage records, test connectors, and fault-injection facilities. 11.6.33. WF-06.33 — Technical Effect The embodiment establishes protected control over the relationship between untrusted information, subsequent computation, execution- lineage state, and externally effective operations. The protected relationship may comprise: (a) source identification; (b) context-unit trust classification; (c) CBR creation or verification; (d) ITBO establishment; (e) protected influence-state maintenance; (f) process or session lineage association; (g) defined information-interaction detection; (h) protected influence-state propagation; (i) authorization-scope degradation; (j) prevention of unauthorized instruction promotion; Das Expires 19 April 2027 [Page 279] Internet-Draft Protected AI Execution Finality October 2026 (k) Candidate Act provenance binding; (l) protected predicate validation; (m) required protected-state and validation-evidence commitment; (n) scoped execution-capability release; and (o) independent Finality Sink verification. The system prevents the mere ingestion of lower-trust information, creation of a child process, continuation of an agent session, or transfer of influenced context from independently expanding the authority applicable to subsequent consequential operations. The embodiment also distinguishes the use of untrusted material as authorized evidence from its unauthorized use as an instruction or execution-authority source. The applicable protection is established by protected authorization and finality verification, rather than by a prompt warning, heuristic classification, or process label alone. Computation is not authority to act. Untrusted content is not instruction authority merely because an agent has read it. Process creation does not independently restore execution authority restricted by protected influence state. 11.7. WF-07 — Protected Browser Automation, Computer-Use Actions, Screen-State Finality Object, and GUI Effectuation Control 11.7.1. WF-07.1 — Technical Purpose This embodiment provides a computer-implemented protected execution- finality system for controlling consequential graphical user- interface operations proposed by an artificial-intelligence agent, browser-control agent, multimodal model, robotic process automation system, desktop automation component, or other computer-use execution environment. A graphical action may become consequential through a mouse click, touchscreen input, keystroke, form submission, browser command, accessibility operation, terminal command, or equivalent input event. Das Expires 19 April 2027 [Page 280] Internet-Draft Protected AI Execution Finality October 2026 The architecture prevents a proposed governed graphical operation from becoming effective merely because the agent possesses permission to control a browser, desktop, application, virtual display, or operating-system input interface. Instead, the proposed operation is classified as a Candidate Act and maintained in a Non-Effective State. A Protected Enforcement Domain validates the proposed operation against the contemporaneous screen state, semantic target identity, geometric target location, application context, applicable Authority Object, protected policy state, and required freshness conditions. The protected system generates a Screen-State Finality Object (SSFO), commits the required validation evidence, and releases or makes available a scoped, non-bearer screen-action capability. A GUI Finality Sink independently verifies the capability and required current screen-state conditions immediately before permitting the governed action. The embodiment addresses stale screenshots, target substitution, coordinate hallucination, interface movement, malicious overlays, spoofed accessibility data, focus changes, user-interface race conditions, and unauthorized promotion of visible page content into execution authority. 11.7.2. WF-07.2 — Participating Technical Components In one non-limiting implementation, the system comprises: AE-701 — Computer-Use Agent Execution Environment An artificial-intelligence agent, browser-use runtime, GUI automation system, virtual-machine session, multimodal agent, or associated tool configured to propose graphical actions. IM-702 — GUI Action Interception Component An enforcement-controlled component configured to receive proposed interface actions before they are dispatched through a governed input or application-command interface. HQ-703 — Non-Effective Action Holding Mechanism A staging queue or protected action record maintaining the proposed graphical operation pending authorization. Das Expires 19 April 2027 [Page 281] Internet-Draft Protected AI Execution Finality October 2026 SC-704 — Screen-State Capture Component A component configured to obtain a contemporaneous representation of the relevant graphical interface. SM-705 — Semantic Interface Measurement Component A component configured to obtain or verify structured information concerning interface elements, including their identifiers, roles, labels, visibility, geometry, enabled state, and application context. HT-706 — Geometric Hit-Test Component A mechanism configured to determine which interface element would receive the proposed graphical input. DC-707 — Screen-Action Descriptor Component A component configured to construct a canonical descriptor of the proposed interface action. PED-708 — Protected Enforcement Domain A protected authorization component configured to validate screen- state, semantic, geometric, purpose, risk, authority, and freshness predicates. PS-709 — Protected Authorization-State Store A mechanism maintaining applicable policy epochs, user authorization, revocation state, nonce state, operation identifiers, and capability- consumption information. SO-710 — Screen-State Finality Object Component A protected mechanism configured to construct, authenticate, and maintain the SSFO or its protected commitment. EV-711 — Protected Validation-Evidence Component A mechanism configured to generate or commit an applicable LAVR, AVR, authenticated validation record, or equivalent protected evidence. CR-712 — Screen-Action Capability Release Component A mechanism configured to release or make available the scoped non- bearer capability associated with the validated action. Das Expires 19 April 2027 [Page 282] Internet-Draft Protected AI Execution Finality October 2026 FS-713 — GUI Finality Sink An enforcement-controlled browser, operating-system, application, terminal, or input-dispatch boundary configured to verify the required capability before performing the governed interface action. AD-714 — Controlled Action Dispatcher A mechanism configured to dispatch the permitted input event or application command through the verified interface. OS-715 — Protected Action-Outcome State Component A component configured to maintain action completion, denial, replay, or indeterminate-outcome information. UA-716 — Trusted User Authorization Component An optional protected interface for obtaining explicit user confirmation required for high-risk graphical operations. The components may be implemented within one protected node or distributed among a browser runtime, operating system, hypervisor, trusted UI subsystem, protected controller, or other authenticated execution components. 11.7.3. WF-07.3 — Identification of the GUI Effectuation Boundary The system first identifies where a proposed computer-use action becomes consequential. The applicable interface may comprise: (a) a browser automation action dispatcher; (b) an operating-system input dispatcher; (c) an accessibility action interface; (d) a terminal command gateway; (e) an application command controller; (f) a mobile-device UI automation interface; (g) a virtual or remote desktop input gateway; (h) a secure UI controller; Das Expires 19 April 2027 [Page 283] Internet-Draft Protected AI Execution Finality October 2026 (i) a file-selection or file-operation dialog; (j) a payment or purchase-confirmation interface; or (k) another interface capable of producing a governed operation. A proposed click may first become effective as an input event at a GUI boundary. A subsequent network request, database commitment, payment or other downstream consequence may have its own separate Finality Sink. The architecture identifies the boundary actually controlled by FS- 713. A GUI input capability does not automatically substitute for an additional downstream execution capability where the corresponding operation requires separate finality enforcement. 11.7.4. WF-07.4 — Mandatory GUI Action Mediation Before enabling governed computer-use operations, the system configures the execution environment so that AE-701 cannot independently dispatch restricted graphical actions through an alternative unverified path. In a browser implementation, the agent may be restricted to an enforcement-controlled browser automation interface. In a desktop implementation, the agent may be prohibited from directly invoking unrestricted operating-system input-injection facilities. In a mobile implementation, the protected mediation mechanism may control the relevant accessibility action, UI automation, or secure- input interface. In a remote-desktop implementation, the input-control channel may terminate at an authenticated remote-action gateway that performs the required verification. The system also governs alternative action channels capable of producing the same consequential effect, such as direct script execution, DOM-triggered commands, browser extensions, application APIs, or tool calls, according to the relevant effectuation-path requirements. Das Expires 19 April 2027 [Page 284] Internet-Draft Protected AI Execution Finality October 2026 A protected GUI gate does not establish universal non-bypassability if the agent retains an unrestricted alternative interface capable of performing the same governed operation. 11.7.5. WF-07.5 — Candidate GUI Action Generation AE-701 generates a proposed action. Non-limiting examples include: (a) clicking a button; (b) tapping a touchscreen target; (c) submitting a form; (d) entering information into an application field; (e) pressing a keyboard shortcut; (f) selecting a file; (g) confirming a purchase; (h) changing an account permission; (i) submitting an email; (j) running a terminal command; (k) approving an application dialog; (l) deleting an account; (m) modifying a cloud resource through a dashboard; or (n) performing another computer-use operation. The proposed operation is designated Candidate GUI Act CA-717. Generation of CA-717 does not independently authorize the action. 11.7.6. WF-07.6 — Interception and Non-Effective Staging IM-702 intercepts CA-717 before the governed effectuation interface receives the input. The proposed action is retained in HQ-703. Das Expires 19 April 2027 [Page 285] Internet-Draft Protected AI Execution Finality October 2026 A non-limiting pending-action record comprises: operation_id; agent_identity; session_identity; application_identity; window_identity; proposed_action_type; declared_target; proposed_coordinates; declared_semantic_intent; requested_effect_class; authority_reference; policy_epoch; status = NON_EFFECTIVE. The agent may revise or cancel the proposed action while it remains non-effective. A materially changed proposed action requires corresponding descriptor validation rather than silently inheriting authority from the earlier proposal. 11.7.7. WF-07.7 — Contemporaneous Screen-State Capture SC-704 captures or measures the relevant interface state before authorization. The captured state may comprise: (a) a full-screen image; (b) an active-window image; (c) a screenshot of the target region; Das Expires 19 April 2027 [Page 286] Internet-Draft Protected AI Execution Finality October 2026 (d) a browser-tab rendering measurement; (e) a terminal-screen measurement; (f) a secure-compositor measurement; (g) a framebuffer digest; (h) a Merkleized screen-tile map; or (i) an equivalent protected visual-state representation. A protected capture record may comprise: screen_capture_id; screen_digest; capture_generation; active_window_id; application_id; display_id; viewport_geometry; display_scaling; scroll_position; focus_state; policy_epoch; nonce; capture_freshness_reference. The capture is associated with the interface context relevant to the proposed action. The protected system does not assume that an arbitrary screenshot supplied by the agent accurately represents the current effectuation interface. Das Expires 19 April 2027 [Page 287] Internet-Draft Protected AI Execution Finality October 2026 Where stronger integrity is required, the screen-state measurement is obtained from an authenticated rendering or display subsystem. 11.7.8. WF-07.8 — Screen-State Digest An illustrative screen-state digest may be computed as: Hs = H("DAS-SCREEN-v1" || Encode(Frame, Geometry, Window, Generation)) where: Hs denotes the screen-state digest; H denotes an approved cryptographic hash function; Encode denotes a deterministic byte-encoding procedure; Frame denotes the captured or measured screen pixels or protected screen-state reference; Geometry denotes the relevant viewport and display-coordinate configuration; Window denotes the authenticated active-window or display context; Generation denotes the protected screen-state version or capture generation; || denotes concatenation. The screen-state digest may instead be computed over a bounded rendered region or an authenticated Merkle-root representation where the applicable policy permits such granularity. Where unrelated dynamic interface regions change frequently, the system may define a protected target-region measurement rather than requiring exact equality of every pixel of the entire display. Any permitted exclusion must not omit information necessary to verify the target's visibility, geometry, identity, or consequential effect. 11.7.9. WF-07.9 — Semantic Interface Measurement SM-705 obtains structured information concerning the relevant application interface. Depending upon the implementation, this may comprise: Das Expires 19 April 2027 [Page 288] Internet-Draft Protected AI Execution Finality October 2026 (a) a DOM tree; (b) an accessibility tree; (c) a browser rendering tree; (d) an application view hierarchy; (e) a terminal command context; (f) a secure UI descriptor; (g) an operating-system automation tree; (h) a mobile accessibility representation; or (i) another semantic interface-state object. The semantic representation may include: element_id; semantic_role; accessible_label; visible_text; element_state; bounding_region; z_order; focus_state; application_identity; browser_origin; document_identity; form_identity; event_target_reference; semantic_generation. Das Expires 19 April 2027 [Page 289] Internet-Draft Protected AI Execution Finality October 2026 Where required, the representation is authenticated or measured by a trusted browser, accessibility, compositor, application, or protected execution component. An agent-supplied semantic label is not independently treated as proof of the interface's actual meaning. 11.7.10. WF-07.10 — Semantic-State Commitment The semantic interface representation may be canonicalized and hashed. An illustrative expression is: Hm = H("DAS-SEMANTIC-v1" || Encode(Tree, Target, Context, Version)) where: Hm denotes the semantic-state digest; Tree denotes the relevant semantic-interface representation; Target denotes the selected element identity and state; Context denotes the application, origin, focus, and window context; Version denotes the semantic-state generation or authenticated version; H, Encode, and || retain their previously defined meanings. The protected system associates Hm with the corresponding rendered screen-state measurement. The relationship permits the PED to determine whether the semantic target presented for authorization corresponds to the actual interface state within the specified trust assumptions. 11.7.11. WF-07.11 — Coordinate-System Normalization Graphical input locations may be represented in physical display pixels, logical desktop pixels, browser viewport coordinates, document coordinates, element-relative coordinates, or another coordinate system. DC-707 identifies the coordinate system used by the agent and the one used by the actual input dispatcher. Das Expires 19 April 2027 [Page 290] Internet-Draft Protected AI Execution Finality October 2026 An illustrative transformation is: p_dispatch = T(p_agent) where: p_agent denotes the proposed action location in the agent's coordinate system; T denotes the specified coordinate transformation; p_dispatch denotes the corresponding location in the input dispatcher's coordinate system. The transformation may account for: (a) display scaling; (b) device-pixel ratio; (c) browser zoom; (d) viewport offset; (e) scroll position; (f) window placement; (g) nested frame geometry; (h) element transforms; (i) display rotation; and (j) remote-desktop scaling. The transformation parameters are included in, or bound to, the protected screen-state representation where required. If the relevant coordinate transformation cannot be established, the operation remains non-effective. 11.7.12. WF-07.12 — Geometric Target Verification HT-706 identifies the interface element expected to receive the proposed input. For a rectangular target region: Das Expires 19 April 2027 [Page 291] Internet-Draft Protected AI Execution Finality October 2026 R = [xmin, xmax] × [ymin, ymax] where: R denotes the target bounding region; xmin and xmax denote the horizontal boundaries; ymin and ymax denote the vertical boundaries; × denotes the Cartesian product of coordinate intervals. For a proposed pointer location p = (x,y), basic region membership may be evaluated as: Inside(p,R) = (xmin ≤ x ≤ xmax) AND (ymin ≤ y ≤ ymax) where: Inside(p,R) denotes whether the proposed coordinate lies within the region. However, region membership alone is not sufficient when overlapping elements, transforms, clipping, transparent overlays, or event- dispatch rules can change the actual receiving target. The implementation therefore determines the actual effective hit target using a trusted hit-test procedure appropriate to the rendering environment. For irregular targets, the implementation may use point-in-polygon testing, compositor hit testing, DOM hit testing, or another suitable procedure. 11.7.13. WF-07.13 — Semantic-Geometric Equivalence The protected system compares the declared semantic action with the actual target of the proposed input. Let: I denote the declared semantic intent; Das Expires 19 April 2027 [Page 292] Internet-Draft Protected AI Execution Finality October 2026 Ehit denote the element that would actually receive the input; Role(Ehit) denote the verified semantic or functional role of the target; AllowedRole(I) denote the role or effect class authorized by the applicable Authority Object. A representative predicate is: Pgeom = TargetValid(Ehit) AND RoleMatch(Role(Ehit),AllowedRole(I)) where: Pgeom denotes the semantic-geometric validation result; TargetValid verifies the target's required visibility, enabled state, focus relationship, and geometric eligibility; RoleMatch verifies correspondence to the intended authorized semantic operation. For example, a proposed action described as selecting “Save” fails when the protected hit test identifies a “Delete” control. Likewise, an action described as canceling a payment fails if the effective target is a payment-confirmation control. The protected system does not authorize an input based solely on the agent's declared interpretation of the screen. 11.7.14. WF-07.14 — Overlay, Z-Order, and Occlusion Verification A target may geometrically occupy the proposed coordinate but be partially or completely obscured by another interface element. Accordingly, the protected system may verify: (a) the effective z-order; (b) target visibility; (c) clipping boundaries; (d) active-window identity; (e) iframe and embedded-frame relationships; Das Expires 19 April 2027 [Page 293] Internet-Draft Protected AI Execution Finality October 2026 (f) overlay elements; (g) hit-test routing; (h) focus state; and (i) event-dispatch context. Where the actual receiving element differs from the validated semantic target, the semantic-geometric predicate fails. An application-controlled overlay or malicious browser extension cannot be treated as harmless merely because the underlying button occupies the expected coordinates. If the selected rendering environment cannot provide trustworthy target identity, the implementation may require additional verification or refuse the affected high-risk action. 11.7.15. WF-07.15 — Hardware-Rendered and Semantic Coherence In stronger embodiments, the protected system verifies correspondence between rendering evidence and semantic interface evidence. The applicable measurements may originate from a protected compositor, hardware-adjacent framebuffer, trusted rendering process, secure UI subsystem, or equivalent component. The verification may compare: (a) rendered target appearance; (b) semantic element identity; (c) bounding geometry; (d) target role; (e) visible label; (f) effective hit-test result; (g) application identity; and (h) target enabled or disabled state. Das Expires 19 April 2027 [Page 294] Internet-Draft Protected AI Execution Finality October 2026 A rendered button showing “Delete Account” is not automatically treated as an authorized “Save” action merely because an untrusted accessibility label claims otherwise. Likewise, a semantic element identified as a payment confirmation is not accepted if the actual rendered or interactive target is a different control. Where semantic and rendering evidence cannot be reconciled under the required trust rules, the PED withholds the applicable capability. No universal inference that pixels alone prove the true downstream semantics of an arbitrary untrusted application is assumed. 11.7.16. WF-07.16 — Screen-Action Descriptor DC-707 constructs a canonical Screen-Action Descriptor. An illustrative descriptor contains: action_id; agent_identity; session_identity; application_identity; browser_origin; window_identity; screen_state_digest; semantic_state_digest; target_element_identity; target_bounding_region; z_order_state; focus_state; proposed_coordinates; coordinate_transform_reference; Das Expires 19 April 2027 [Page 295] Internet-Draft Protected AI Execution Finality October 2026 action_type; action_parameters; declared_semantic_intent; verified_effect_class; risk_class; authority_reference; user_approval_reference; policy_epoch; nonce; expiry; finality_sink_id. The descriptor binds the proposed action to the interface state upon which authorization depends. A descriptor authorized for one target does not automatically authorize another target, even if both targets are located in the same application window. 11.7.17. WF-07.17 — Construction of the Screen-State Finality Object SO-710 generates a Screen-State Finality Object from the required screen, semantic, action, and authority information. An illustrative representation is: SSFO = AuthPED(Hs, Hm, Da, Target, Risk, Authority, Epoch, Nonce, F) where: SSFO denotes the protected Screen-State Finality Object; AuthPED denotes the cryptographic or otherwise protected authentication procedure controlled by the PED; Hs denotes the screen-state digest; Hm denotes the semantic-state digest; Das Expires 19 April 2027 [Page 296] Internet-Draft Protected AI Execution Finality October 2026 Da denotes the canonical Screen-Action Descriptor or its digest; Target denotes the verified target element or region; Risk denotes the applicable action-risk class; Authority denotes the required authenticated authority context; Epoch denotes the protected policy or execution epoch; Nonce denotes a freshness or replay-prevention value; F denotes the applicable GUI Finality Sink identity. The SSFO may be implemented using an authenticated record, protected register state, signed object, Merkle commitment, sealed structure, or equivalent protected representation. The SSFO is distinct from an ordinary screenshot, agent-generated description, or post-event interaction log. 11.7.18. WF-07.18 — Application Context and Target-Origin Validation For browser actions, the PED may verify the browser origin, active tab, document identity, iframe origin, form identity, and applicable destination. For native applications, corresponding conditions may identify the application executable, authenticated window, process identity, command class, and resource context. For mobile applications, the conditions may identify the foreground application, active view, secure prompt, and permitted action scope. For remote desktops, the system may verify the remote session identity, displayed frame generation, target window, and controlled remote-input interface. An action prepared for one application, origin, or window is not independently authorized for another. If a browser navigation, tab switch, application replacement, or focus change invalidates a mandatory binding, the corresponding action requires revalidation. Das Expires 19 April 2027 [Page 297] Internet-Draft Protected AI Execution Finality October 2026 11.7.19. WF-07.19 — Purpose and Risk-Class Validation PED-708 evaluates the actual proposed operation against the applicable Authority Object and risk policy. A risk class may identify operations such as: (a) navigation without consequential state mutation; (b) bounded data retrieval; (c) local temporary editing; (d) persistent file mutation; (e) message transmission; (f) credential entry or release; (g) account-permission change; (h) purchase or payment approval; (i) deletion of persistent information; (j) software installation; (k) privileged command execution; or (l) another governed effect class. The applicable predicates depend upon the effect class and authorized purpose. A lower-risk operation may require a smaller mandatory predicate set, while a higher-risk operation may require stronger target attestation, additional protected state, or explicit user confirmation. Risk classification does not eliminate the Finality Sink verification requirement for a governed Candidate Act. 11.7.20. WF-07.20 — Protected Human Authorization Where explicit human authorization is required, UA-716 obtains an approval artifact through a trusted authorization interface. The approval artifact may bind: Das Expires 19 April 2027 [Page 298] Internet-Draft Protected AI Execution Finality October 2026 user_identity; approved_action_digest; screen_state_digest; target_identity; application_identity; destination; recipient; transaction_amount; approved_effect_class; policy_epoch; nonce; expiry. The authorization may be produced through a trusted UI confirmation, passkey ceremony, secure prompt, hardware confirmation, or equivalent mechanism. The PED verifies that the approval applies to the actual Candidate GUI Act. A generic approval for “continue” does not authorize a materially different recipient, transaction amount, application context, or action target where those parameters are mandatory. Human approval does not independently bypass protected validation or Finality Sink verification. 11.7.21. WF-07.21 — Protected Predicate Evaluation PED-708 evaluates the required screen-action authorization predicates. A representative conjunctive predicate is: Vui = Pscreen Das Expires 19 April 2027 [Page 299] Internet-Draft Protected AI Execution Finality October 2026 AND Psemantic AND Pgeometry AND Pcontext AND Ppurpose AND Prisk AND Pauthority AND Pfresh where: Vui denotes the protected UI authorization result; Pscreen validates the required current rendered-screen state; Psemantic validates the semantic interface representation; Pgeometry validates geometric correspondence and the actual effective target; Pcontext validates the application, origin, window, and focus context; Ppurpose validates the authorized user purpose and operation scope; Prisk validates the required risk-class conditions; Pauthority validates applicable Authority Objects and approvals; Pfresh validates nonce, expiry, policy epoch, revocation state, and other required freshness conditions. Each predicate is applied according to the selected embodiment and Authority Object. When any mandatory predicate fails, the PED withholds execution authority. 11.7.22. WF-07.22 — Protected State and Validation-Evidence Commitment Upon successful validation, PED-708 performs the required protected state operations. Das Expires 19 April 2027 [Page 300] Internet-Draft Protected AI Execution Finality October 2026 Such operations may include: (a) nonce reservation or consumption; (b) authorization-state version advancement; (c) policy-epoch validation; (d) bounded action-budget consumption; (e) user-approval consumption; (f) protected usage-state reservation; and (g) recording an SSFO commitment. EV-711 generates or commits the required protected validation evidence. An illustrative evidence record comprises: receipt_id; candidate_action_digest; SSFO_digest; screen_state_digest; semantic_state_digest; verified_target; authority_reference; predicate_result_reference; protected_state_transition; policy_epoch; nonce; finality_sink_id; protected_authentication. Das Expires 19 April 2027 [Page 301] Internet-Draft Protected AI Execution Finality October 2026 Where the applicable embodiment requires evidence commitment before, or atomically with, capability availability, the implementation preserves that ordering. The SSFO and validation record may remain protected internally rather than requiring publication to an external ledger. 11.7.23. WF-07.23 — Scoped Screen-Action Capability CR-712 releases or makes available a scoped non-bearer Screen-Action Capability only after the required protected finality transaction succeeds. An illustrative capability includes or securely references: capability_id; candidate_action_digest; SSFO_digest; screen_state_digest; semantic_state_digest; authorized_action_type; target_element_identity; authorized_target_region; application_identity; authorized_effect_class; approval_reference; policy_epoch; nonce; expiry; usage_limit; finality_sink_id. Das Expires 19 April 2027 [Page 302] Internet-Draft Protected AI Execution Finality October 2026 The capability is bound to the corresponding action and screen-state requirements. Possession of the capability representation does not authorize a different target, application, effect class, or Finality Sink when those conditions are mandatory. The capability may be represented by an authenticated artifact, protected handle, capability-table entry, secure dispatcher token, or equivalent bounded enablement mechanism. 11.7.24. WF-07.24 — Immediate Pre-Dispatch Verification FS-713 receives the proposed action and its corresponding capability. Before dispatching the governed input event, FS-713 verifies: (a) capability authenticity; (b) correspondence to the proposed action; (c) current required screen-state measurement; (d) current semantic target identity; (e) effective hit-test result; (f) application and active-window identity; (g) required browser-origin or application context; (h) focus state; (i) action type and parameters; (j) user authorization where required; (k) policy epoch and revocation state; (l) nonce, expiry, and consumption conditions; and (m) designated Finality Sink identity. An illustrative decision expression is: PermitUI = Auth(C) Das Expires 19 April 2027 [Page 303] Internet-Draft Protected AI Execution Finality October 2026 AND ScreenMatch(C,Sactual) AND TargetMatch(C,Tactual) AND ContextMatch(C,Xactual) AND StateValid(C,P) AND SinkValid(C,F) where: PermitUI denotes permission to dispatch the governed UI action; C denotes the scoped Screen-Action Capability; Sactual denotes the current required screen state; Tactual denotes the effective input target; Xactual denotes the current application, window, focus, and execution context; P denotes the relevant protected policy and authorization state; F denotes the designated GUI Finality Sink; Auth verifies required capability authenticity; ScreenMatch verifies correspondence with the authorized screen-state measurement; TargetMatch verifies the semantic and geometric target conditions; ContextMatch verifies the required application and execution context; StateValid verifies mandatory freshness, revocation, approval, and consumption state; SinkValid verifies the intended Finality Sink. The action is dispatched only if PermitUI is true. 11.7.25. WF-07.25 — Time-of-Check and Time-of-Use Protection A graphical interface may change between the time at which an agent observes a screen and the time at which its proposed action is executed. Das Expires 19 April 2027 [Page 304] Internet-Draft Protected AI Execution Finality October 2026 Potential changes include: (a) moving buttons; (b) new overlays; (c) modal dialogs; (d) focus changes; (e) browser navigation; (f) iframe replacement; (g) responsive-layout changes; (h) dynamic content insertion; (i) application-window substitution; and (j) delayed remote-desktop rendering. The Finality Sink therefore verifies the required current state immediately before input dispatch. In a stronger implementation, the protected UI action transaction coordinates final state verification, capability consumption, and controlled input dispatch under a protected state or input-dispatch synchronization mechanism. For example, a trusted browser action broker may compare the current target-generation identifier, reserve the authorization, and dispatch the action against that exact authenticated target before allowing an incompatible intervening target mutation. Where the interface cannot provide such atomicity, the implementation must use another sufficiently protective verification and synchronization arrangement for the specified guarantee. A check performed several seconds earlier does not automatically establish current target validity at the instant of effectuation. 11.7.26. WF-07.26 — Protected Capability Consumption Where the capability is single-use, the GUI Finality Sink consumes or reserves the applicable protected usage state before permitting the governed input event. Das Expires 19 April 2027 [Page 305] Internet-Draft Protected AI Execution Finality October 2026 An illustrative transition is: AUTHORIZED → RESERVED → DISPATCHED where: AUTHORIZED denotes a valid capability awaiting permitted use; RESERVED denotes protected consumption or reservation of the capability; DISPATCHED denotes that the controlled input action was submitted to the applicable GUI effectuation boundary. If the input event is refused before dispatch, the operation may enter a protected denial or recovery state. If the event is dispatched but its downstream consequence remains unknown, the system does not automatically treat that event as never having occurred. The protected operation outcome is maintained separately from the authorization state. 11.7.27. WF-07.27 — Browser Form Submission Example In one concrete embodiment, an AI agent is authorized to prepare an email through a browser-based enterprise application. The agent prepares a recipient address, subject, message body, and proposed Send action. The browser automation action is intercepted before submission. The system constructs a Candidate GUI Act Descriptor identifying the recipient, applicable message-content digest, authorized browser origin, application identity, Send control, intended effect class, and applicable Finality Sink. SC-704 captures the relevant contemporaneous browser screen state. SM-705 obtains the semantic identity of the recipient field, message body, and Send control from the applicable trusted browser or UI measurement interface. HT-706 determines which control would receive the proposed click. Das Expires 19 April 2027 [Page 306] Internet-Draft Protected AI Execution Finality October 2026 The PED verifies that the actual target corresponds to Send rather than Delete, Archive, Forward, or another operation. Where required, the PED also verifies that the recipient and message content correspond to the approved operation. The PED commits the required validation evidence and releases a screen-action capability bound to the SSFO. Immediately before dispatch, the GUI Finality Sink checks the current screen, target, application, and authorization state. If the target has moved, a modal overlay has appeared, the recipient has changed outside the authorized scope, or another mandatory condition has become invalid, the action is refused. If verification succeeds, the controlled dispatcher performs the authorized Send action. Where the consequential network transmission or receiving-side message acceptance is separately governed, the corresponding network or service Finality Sink also performs its required verification. The GUI authorization does not automatically establish final remote delivery merely because the browser accepted the click. 11.7.28. WF-07.28 — Payment-Confirmation and High-Risk Action Example In another embodiment, a computer-use agent prepares an authorized purchase through a graphical checkout interface. The Candidate GUI Act identifies: (a) the merchant or service; (b) the intended transaction; (c) transaction amount and currency; (d) applicable recipient or payee; (e) the confirmation control; (f) the authorized user purpose; (g) the contemporaneous screen and semantic state; and (h) the payment-confirmation Finality Sink. Das Expires 19 April 2027 [Page 307] Internet-Draft Protected AI Execution Finality October 2026 The system measures the checkout interface and verifies that the proposed action targets the intended confirmation control. A user approval artifact, where required, binds the transaction parameters and screen-state reference. The PED validates the merchant, amount, recipient, applicable authority scope, risk class, current policy, and freshness conditions. After protected state and evidence commitment, a scoped capability is made available. The GUI Finality Sink verifies the capability immediately before the confirmation input. If the displayed amount, merchant, effective target, active application, or required user authorization differs from the validated conditions, the confirmation action is withheld. Where payment execution or settlement involves a separate consequential boundary, a payment Finality Sink performs its own required authorization verification. This avoids treating permission to click a button as unconditional permission to settle an unrelated transaction. 11.7.29. WF-07.29 — Terminal and Native-Application Variations The same protected finality arrangement may govern terminal commands and native application actions. For terminal execution, the descriptor may bind the proposed command, target terminal session, executable or command class, relevant arguments, current focus, authorized purpose, and host execution Finality Sink. A keystroke that would cause execution of a destructive command is withheld unless the required protected capability verifies. For native desktop applications, the system may verify the application identity, active window, accessibility target, relevant geometry, and actual command interface. For mobile applications, it may verify the foreground application, permitted view, action target, secure UI state, and applicable user authorization. Das Expires 19 April 2027 [Page 308] Internet-Draft Protected AI Execution Finality October 2026 For remote desktops, it may associate the action with an authenticated remote-session identity, captured remote frame, relevant input-coordinate transformation, and controlled remote-input dispatcher. The implementation identifies and protects the actual input or command boundary at which the proposed operation becomes effective. 11.7.30. WF-07.30 — Failure and Fail-Closed Handling The protected system refuses the affected GUI operation when any mandatory condition fails. Non-limiting failure conditions include: (a) missing or invalid screen capture; (b) stale screen state; (c) unverifiable semantic interface state; (d) semantic-geometric target mismatch; (e) obscured or substituted action target; (f) unauthorized browser-origin change; (g) focus or active-window mismatch; (h) invalid coordinate transformation; (i) unauthorized action class; (j) invalid or stale user approval; (k) expired SSFO; (l) policy-epoch or revocation mismatch; (m) capability replay; (n) unavailable required protected state; (o) failed validation-evidence commitment; or (p) failed GUI Finality Sink verification. Das Expires 19 April 2027 [Page 309] Internet-Draft Protected AI Execution Finality October 2026 The proposed operation remains in a Non-Effective State, is denied, or is redirected to an explicitly authorized review procedure. The protected system may generate a denial receipt identifying the relevant mismatch. Such a denial receipt does not itself authorize the rejected action. 11.7.31. WF-07.31 — Agent Context Correction After Denial Where an action is refused, the system may communicate the denial result to the agent through a controlled feedback channel. The feedback may identify: operation_id; denial_class; expected_target; observed_target; screen_state_version; required_revalidation; protected_denial_reference. The agent may use this information to update its current plan or obtain a new screen observation. For example, if the agent proposes a click on a stale button position, the protected system may indicate that the screen state changed and that a new action descriptor is required. The agent must not treat a rejected action as having succeeded. In embodiments employing protected context correction, the denial state is incorporated into the agent's subsequent execution context before further affected tool or computer-use actions proceed. 11.7.32. WF-07.32 — Alternative Structural Implementations Browser automation implementation: An enforcement-controlled browser action broker verifies an SSFO-bound capability before performing a governed click, form submission, navigation, or script-mediated action. Das Expires 19 April 2027 [Page 310] Internet-Draft Protected AI Execution Finality October 2026 Operating-system implementation: A protected input dispatcher mediates designated keyboard, pointer, or accessibility actions. Trusted compositor implementation: A secure compositor or hardware- adjacent rendering source produces trusted screen measurements and supports final target verification. Hypervisor implementation: A virtual machine supplies proposed computer-use actions to a protected host or virtual-device controller. Remote-desktop implementation: An authenticated remote-input gateway verifies action capabilities against the relevant remote screen generation and session identity. Mobile implementation: A protected mobile UI automation or accessibility interface mediates governed actions. Single-node implementation: The screen-state capture, PED, capability mechanism, and GUI Finality Sink operate within one protected device or node. Distributed implementation: A protected authority performs validation remotely, while a local or receiving-side GUI Finality Sink verifies the resulting capability before executing the governed action. These implementations may have different levels of resistance to malicious applications, compromised accessibility frameworks, display spoofing, privileged software compromise, or hardware attack. A software-only screenshot comparison does not automatically provide the guarantees of a hardware-rooted screen measurement. 11.7.33. WF-07.33 — PHOSITA Verification and Negative Tests A person having ordinary skill in browser automation, GUI security, operating-system input mediation, accessibility frameworks, trusted rendering systems, or protected execution may verify the embodiment through the following tests. Test 1 — Correct authorized target: The current screen, semantic identity, target geometry, and capability match. The authorized input is dispatched. Test 2 — Coordinate hallucination: The proposed coordinate does not intersect the declared target. The action is refused. Das Expires 19 April 2027 [Page 311] Internet-Draft Protected AI Execution Finality October 2026 Test 3 — Changed layout: The target moves after authorization. The required screen-state or target correspondence fails. Test 4 — Overlay attack: An overlay becomes the effective input target. The actual hit-test mismatch prevents the governed action. Test 5 — Focus theft: Another window receives focus before input dispatch. The required application-context predicate fails. Test 6 — Browser navigation: The browser navigates to a different origin or document. An incompatible SSFO is rejected. Test 7 — Accessibility spoofing: The semantic label does not correspond to the required rendered or effective target. The coherence predicate fails where mandatory. Test 8 — Stale screenshot: A previously captured screen state is presented after a relevant interface change. The action is withheld. Test 9 — Wrong action type: A capability authorizing a click is presented for an unauthorized keyboard or submission operation. Verification fails. Test 10 — Approval mismatch: A human approval bound to a different recipient, amount, or screen state is presented. The required approval predicate fails. Test 11 — Capability replay: A single-use screen-action capability is presented after consumption. The protected usage condition fails. Test 12 — Race condition: The UI target changes between validation and dispatch. The required final state-verification or synchronization mechanism prevents an incompatible action. Test 13 — Browser-extension substitution: An extension modifies the target or effective operation after authorization. The corresponding mandatory binding fails. Test 14 — Alternate automation path: The agent attempts to perform the same governed operation through a direct script or unrestricted input mechanism. The bypass path is blocked or subjected to equivalent required finality verification. Test 15 — Remote-desktop scaling: Display scaling changes the actual target coordinate. The protected coordinate transformation or target verification detects the mismatch. Das Expires 19 April 2027 [Page 312] Internet-Draft Protected AI Execution Finality October 2026 Test 16 — Denial context correction: Following refusal, the agent receives the required denial state and does not assume successful completion. Test 17 — High-risk operation: A payment or deletion action lacks required bound user authorization. The protected capability is withheld. Test 18 — Multiple Finality Sinks: A GUI action capability is used at an unrelated downstream transaction boundary. The downstream verifier refuses it unless separately authorized. Test 19 — Protected capture failure: The trusted screen-state measurement is unavailable. The affected action remains non- effective. Test 20 — Concurrent GUI actions: Multiple agents or sessions attempt conflicting high-risk operations against the same screen or state. The required protected generation, capability-use, and synchronization conditions prevent unauthorized dispatch. These tests may use controlled browsers, synthetic GUI applications, accessibility-tree instrumentation, protected input brokers, simulated overlays, deliberate focus changes, and fault-injection facilities. 11.7.34. WF-07.34 — Technical Effect The embodiment establishes a protected dependency between: (a) generation of a proposed GUI or computer-use action; (b) interception and Non-Effective State staging; (c) contemporaneous rendered-screen capture; (d) semantic interface measurement; (e) geometric target verification; (f) semantic-geometric equivalence; (g) relevant application and focus-state verification; (h) protected Authority Object and risk-predicate validation; (i) required user authorization; Das Expires 19 April 2027 [Page 313] Internet-Draft Protected AI Execution Finality October 2026 (j) generation of a Screen-State Finality Object; (k) protected-state handling and evidence commitment; (l) scoped non-bearer screen-action capability availability; (m) independent verification immediately before input dispatch; and (n) controlled action effectuation or fail-closed refusal. The resulting architecture prevents a proposed interface action from becoming effective through the governed execution path solely because an agent has identified a coordinate, received a screenshot, inferred a target label, obtained ordinary browser-control permission, or received a general human approval. The protected authorization binds the proposed consequential action to the required actual screen, semantic target, application context, authority state, and Finality Sink. Computation is not authority to act. A screen observation is not authority to click. An authorized interface target must still correspond to the target actually presented for effectuation. 11.8. WF-08 — Autonomous Commerce, Purchase Authorization, Payment Instructions, Protected Spending Constraints, and Commerce Finality Sink Enforcement 11.8.1. WF-08.1 — Technical Purpose This embodiment provides a computer-implemented protected execution- finality system for controlling consequential commercial operations generated, prepared, negotiated, selected, or initiated by an artificial-intelligence agent, marketplace application, autonomous purchasing system, pricing agent, auction agent, recommendation engine, advertising agent, or other computational component. The system prevents a proposed commercial act from becoming effective merely because an agent generated an offer, selected a merchant, recommended a product, calculated a price, prepared a payment instruction, obtained an ordinary account credential, or received an earlier authorization decision. Das Expires 19 April 2027 [Page 314] Internet-Draft Protected AI Execution Finality October 2026 The proposed commercial operation is represented as a Candidate Commerce Act and maintained in a Non-Effective State until the required protected authority predicates have been validated, required protected authorization state has been established, protected validation evidence has been committed, and a scoped Commerce Actuation Capability has been released or made available. A Commerce Finality Sink verifies the capability against the actual commercial operation and applicable current protected state before permitting the governed consequence. The architecture may govern purchases, payment instructions, bids, offers, negotiations, inventory allocations, rankings, advertisements, pricing updates, subscription activations, and other commercially consequential operations. The applicable effectuation boundary depends upon the operation. A payment authorization, network submission, marketplace acceptance, ranking publication, inventory commitment, and financial settlement may constitute different technical effects and may require separate Finality Sinks. 11.8.2. WF-08.2 — Participating Technical Components In one non-limiting embodiment, the system comprises: CA-801 — Commerce Agent Execution Environment An artificial-intelligence agent, purchasing assistant, buyer agent, seller agent, pricing agent, marketplace agent, auction agent, recommendation service, advertising service, or associated computational workflow. IM-802 — Commerce Act Interception Component An enforcement-controlled mechanism configured to intercept a proposed commercial operation before its governed consequence occurs. HQ-803 — Non-Effective Commerce Holding Mechanism A protected or enforcement-controlled queue, staged transaction, pending bid, retained offer, inactive pricing update, or equivalent operation-holding facility. DC-804 — Commerce Descriptor Construction Component A component configured to represent the proposed commercial operation using an effectuation-relevant Candidate Commerce Act Descriptor. Das Expires 19 April 2027 [Page 315] Internet-Draft Protected AI Execution Finality October 2026 MA-805 — Market-Compliance Authority Object Store An authenticated source of applicable commercial authority, user mandate, marketplace rules, operation limits, and other protected authorization conditions. PED-806 — Protected Enforcement Domain A protected component configured to validate the Candidate Commerce Act against the applicable Authority Object, authorized purpose, Algorithmic Logic Fingerprint, Runtime Behavioral Descriptor, spending constraints, policy state, revocation state, and other required predicates. PS-807 — Protected Commercial Authorization-State Store A protected mechanism configured to maintain transaction authorizations, remaining spending limits, bid budgets, reserved amounts, nonce state, capability usage, policy epochs, and required completion or revocation information. EV-808 — Market-Integrity Validation-Evidence Component A mechanism configured to generate or commit a Market-Integrity LAVR, ZK-LAVR, authenticated authorization receipt, or equivalent protected validation record. CR-809 — Commerce Actuation Capability Mechanism A protected component configured to release or make available a scoped non-bearer capability for the validated commercial operation. FS-810 — Commerce Finality Sink An enforcement-controlled marketplace, auction, payment, ranking, inventory, advertising, transaction, settlement, or other commercial effectuation interface configured to verify the capability before the governed act becomes effective. EF-811 — Commerce Effectuation Component A marketplace execution engine, payment gateway, order service, bidding engine, ranking-publication service, inventory-commit service, or another component that performs the authorized consequential operation. OS-812 — Protected Commercial Outcome-State Component Das Expires 19 April 2027 [Page 316] Internet-Draft Protected AI Execution Finality October 2026 A mechanism configured to record authorization reservation, submitted operations, confirmed commercial effects, denials, cancellations, and indeterminate outcomes. UA-813 — User Mandate and Approval Component A component configured to obtain an authenticated user-defined commercial objective, spending constraint, purchase mandate, or transaction-specific approval. MC-814 — Merchant or Counterparty Verification Component An optional mechanism configured to verify merchant identities, counterparty classifications, authenticated offers, transaction terms, or other required commercial attributes. RC-815 — Reconciliation and Recovery Component An optional component configured to reconcile ambiguous or interrupted commercial effects through protected state and authenticated external transaction evidence. The components may be physically colocated or distributed among protected computing environments, payment services, marketplace controllers, cloud services, HSMs, secure enclaves, trusted gateways, or equivalent enforcement substrates. 11.8.3. WF-08.3 — Identification of the Commercial Effectuation Boundary The system identifies the boundary at which the particular commercial operation becomes effective. Examples include: (a) submission of a legally or operationally binding purchase order; (b) acceptance of an auction bid; (c) commitment of a negotiated offer; (d) publication of a ranking change; (e) release of an advertisement; (f) application of a pricing update; (g) reservation or commitment of inventory; Das Expires 19 April 2027 [Page 317] Internet-Draft Protected AI Execution Finality October 2026 (h) issuance of a payment authorization request; (i) capture of a payment; (j) initiation of a transfer instruction; or (k) final settlement at an applicable financial system. A commercial workflow may include multiple effectuation boundaries. For example, placing an order and capturing a payment may be separate events. Likewise, a card-network authorization hold does not necessarily constitute completed settlement. The corresponding Authority Object identifies the operation and the effectuation boundary governed by the particular Commerce Actuation Capability. The system does not assume that authorization at one boundary automatically authorizes every subsequent commercial consequence. 11.8.4. WF-08.4 — Establishment of the Governed Commerce Path Before permitting autonomous commerce operations, the system identifies the interfaces through which the commerce agent can create a governed consequence. Such interfaces may comprise: (a) an authenticated marketplace API; (b) a payment-service provider; (c) an auction submission interface; (d) a merchant checkout controller; (e) a commerce connector; (f) an order-management service; (g) a pricing or ranking publication interface; (h) an inventory-commitment engine; or (i) a financial transaction gateway. Das Expires 19 April 2027 [Page 318] Internet-Draft Protected AI Execution Finality October 2026 The implementation prevents the agent from bypassing the applicable Finality Sink through an alternative unrestricted interface capable of completing the same governed operation. For example, routing purchases through a protected commerce broker is insufficient if the agent retains an unrestricted credential allowing direct purchase submission outside that broker. The protected system therefore controls credential use, executable interfaces, connector invocation, host egress, or receiving-side acceptance as required by the selected enforcement architecture. 11.8.5. WF-08.5 — User Mandate Formation UA-813 obtains the user's authorized commercial objective and any applicable constraints. A non-limiting commercial mandate may identify: user_identity; authorized_agent_identity; commercial_purpose; permitted_product_or_service_class; approved_counterparty_class; permitted_merchant_identity; maximum_item_price; maximum_total_price; currency; spending_budget; quantity_limit; permitted_tax_and_fee_scope; delivery_requirements; refund_requirements; warranty_requirements; Das Expires 19 April 2027 [Page 319] Internet-Draft Protected AI Execution Finality October 2026 subscription_permission; recurrence_restrictions; validity_interval; approval_threshold; policy_epoch. The user mandate may be derived from an explicit instruction, authenticated preference, approved enterprise policy, or other authorized source. A natural-language instruction may be translated into machine- verifiable predicates. Where the translation is ambiguous concerning a mandatory commercial restriction, the system obtains clarification, applies a defined conservative constraint, or withholds the affected operation. The agent's own interpretation does not independently expand the user's authorization. 11.8.6. WF-08.6 — Protected Mandate Corridor In a mandate-corridor embodiment, the user's authorized commercial scope is represented as a protected set of permissible transactions. Let: M denote the user-authorized mandate; a denote a proposed commercial operation; Corridor(M) denote the set of commercial operations permitted under the mandate. A proposed operation satisfies the mandate only when: a ∈ Corridor(M) where: ∈ denotes set membership. The mandate corridor may restrict: Das Expires 19 April 2027 [Page 320] Internet-Draft Protected AI Execution Finality October 2026 (a) item or service class; (b) merchant identity or category; (c) price; (d) currency; (e) quantity; (f) warranty; (g) delivery conditions; (h) refund conditions; (i) subscription or recurring-payment conditions; (j) bundling; (k) jurisdiction; (l) permitted payment method; and (m) other defined commercial parameters. The protected mandate is stored or authenticated under the control of the applicable PED or protected authority system. The commerce agent may receive a reference or bounded execution handle without obtaining authority to rewrite the protected mandate. 11.8.7. WF-08.7 — Candidate Commerce Act Generation CA-801 generates or obtains a proposed commercial operation. The operation may comprise: (a) an item purchase; (b) an auction bid; (c) an offer; (d) a counteroffer; (e) an autonomous negotiation response; Das Expires 19 April 2027 [Page 321] Internet-Draft Protected AI Execution Finality October 2026 (f) a price update; (g) a recommendation publication; (h) an advertisement placement; (i) a ranking change; (j) a payment instruction; (k) an inventory allocation; (l) a subscription activation; or (m) another commercially consequential operation. The operation is designated Candidate Commerce Act CCA-816. CCA-816 does not independently become binding, chargeable, transmitted, published, committed, or settled merely because the agent generated it. 11.8.8. WF-08.8 — Mandatory Interception and Non-Effective Staging IM-802 intercepts CCA-816 before the identified commercial effectuation boundary. The operation is maintained in HQ-803 as a non-effective candidate. An illustrative holding record comprises: operation_id; agent_identity; commercial_operation_class; marketplace_identity; merchant_reference; item_or_service_reference; proposed_amount; currency; quantity; Das Expires 19 April 2027 [Page 322] Internet-Draft Protected AI Execution Finality October 2026 authority_reference; policy_epoch; target_finality_sink; status = NON_EFFECTIVE. The staged representation is protected against unauthorized mutation of effectuation-relevant parameters after authorization. Where the original proposed operation changes materially, the protected authorization is reconsidered according to the applicable descriptor-binding rules. 11.8.9. WF-08.9 — Candidate Commerce Act Descriptor DC-804 constructs a machine-verifiable Candidate Commerce Act Descriptor. A non-limiting descriptor comprises: candidate_act_id; buyer_agent_identity; seller_agent_identity; marketplace_identity; auction_identity; merchant_identity; counterparty_identity; item_or_service_class; item_or_service_identifier; quantity; unit_price; bid_amount; total_amount; Das Expires 19 April 2027 [Page 323] Internet-Draft Protected AI Execution Finality October 2026 currency; taxes; fees; delivery_charge; discount; ranking_position; recommendation_target; payment_instrument_reference; consumer_protection_class; jurisdiction; market_rule_class; negotiation_history_digest; spending_limit; bid_limit; policy_epoch; nonce; expiry; finality_sink_identity. Only the fields required by the particular operation and Authority Object are mandatory. The descriptor is constructed to distinguish materially different commercial consequences. An authorization for a one-time purchase does not automatically authorize a recurring subscription. An authorization for one merchant does not automatically authorize another merchant where merchant identity is mandatory. Das Expires 19 April 2027 [Page 324] Internet-Draft Protected AI Execution Finality October 2026 11.8.10. WF-08.10 — Canonical Commercial Descriptor In a cryptographic implementation, the relevant commerce parameters are encoded deterministically. An illustrative expression is: Dcommerce = Canon_v(B, M, ITEM, Q, PRICE, TOTAL, CUR, TERMS, PURPOSE, EPOCH, SINK) where: Dcommerce denotes the canonical Candidate Commerce Act Descriptor; Canon_v denotes deterministic canonicalization under version v; B denotes the authenticated buyer or requesting agent identity; M denotes the merchant or counterparty identity; ITEM denotes the purchased item, service, or commercial object; Q denotes quantity; PRICE denotes unit price or other relevant price parameters; TOTAL denotes the applicable total amount; CUR denotes currency; TERMS denotes relevant delivery, recurrence, warranty, refund, and other commercial terms; PURPOSE denotes the authorized commercial objective; EPOCH denotes the protected policy or authorization-state version; SINK denotes the intended Commerce Finality Sink. An illustrative digest is: hC = H("DAS-COMMERCE-v1" || Encode(Dcommerce)) where: hC denotes the commerce descriptor digest; H denotes an approved cryptographic hash function; Das Expires 19 April 2027 [Page 325] Internet-Draft Protected AI Execution Finality October 2026 Encode denotes the selected deterministic byte encoding; || denotes concatenation; "DAS-COMMERCE-v1" denotes an illustrative domain-separation label. The encoding distinguishes different currencies, amount units, operation classes, merchants, recipients, and recurring-payment conditions. 11.8.11. WF-08.11 — Exact Monetary Representation In one implementation, monetary amounts are represented as integers using a specified currency unit or exponent rather than unspecified binary floating-point values. For example, a currency having two decimal minor units may represent a charge through an integer minor-unit amount together with its currency code. The corresponding descriptor identifies: currency_code; currency_exponent; unit_amount_minor; quantity; tax_amount_minor; fee_amount_minor; shipping_amount_minor; discount_amount_minor; total_amount_minor. The required total is computed using checked integer arithmetic and an explicitly defined rounding procedure where rounding is needed. An illustrative equation is: Total = (UnitAmount × Quantity) + Tax + Fee + Shipping − Discount where: Das Expires 19 April 2027 [Page 326] Internet-Draft Protected AI Execution Finality October 2026 Total denotes the complete authorized transaction amount in the defined minor units; UnitAmount denotes the item or service price per unit; Quantity denotes the authorized quantity; Tax denotes applicable taxes; Fee denotes additional charges; Shipping denotes delivery charges; Discount denotes applicable reductions. All terms are evaluated in a consistent currency and amount representation. If a currency conversion is required, the exchange rate, reference source, conversion time, rounding method, and permitted exchange-rate variance may form part of the applicable authority predicates. A transaction exceeding the authorized total limit after required taxes and charges are included is not treated as valid merely because its displayed item price remains below the limit. 11.8.12. WF-08.12 — Merchant and Counterparty Verification MC-814 obtains or verifies the merchant or counterparty attributes required by the protected mandate. Such attributes may include: (a) authenticated merchant identity; (b) permitted merchant category; (c) merchant account or settlement recipient; (d) marketplace identity; (e) business or counterparty classification; (f) payment-service provider identity; (g) signed offer identity; (h) jurisdiction or market-rule classification; and Das Expires 19 April 2027 [Page 327] Internet-Draft Protected AI Execution Finality October 2026 (i) other applicable conditions. Where required, an authenticated merchant offer is bound to a merchant identity, transaction terms, nonce, validity interval, and offer identifier. A merchant-provided display name is not automatically treated as equivalent to an authenticated payment recipient. Where the identity or recipient cannot be verified to the level required by the applicable Authority Object, the Candidate Commerce Act remains non-effective. 11.8.13. WF-08.13 — Merchant Offer and Settlement-Descriptor Formation In an implementation involving autonomous negotiation, a merchant system may generate an offer comprising: merchant_id; offer_id; product_or_service_id; quantity; base_price; taxes; fees; shipping; warranty_terms; refund_terms; delivery_terms; subscription_terms; offer_expiry; merchant_authentication. The buyer agent may propose acceptance or a counteroffer. Das Expires 19 April 2027 [Page 328] Internet-Draft Protected AI Execution Finality October 2026 Before a binding acceptance or settlement request is permitted, the final commercial payload is canonicalized into a Candidate Settlement Act Descriptor. The descriptor binds the actual merchant, item or service, amount, fees, recurrence conditions, permitted purpose, and relevant authority state. An earlier quote does not authorize a final transaction having materially different settlement terms. 11.8.14. WF-08.14 — Protected Market-Compliance Authority Object PED-806 obtains or verifies the applicable Market-Compliance Authority Object. The object may identify: (a) user consent; (b) spending limits; (c) bid limits; (d) permitted product or service classes; (e) approved merchant or counterparty classes; (f) applicable price or discount constraints; (g) approved ranking or recommendation conditions; (h) prohibited coordination conditions; (i) advertising disclosure rules; (j) jurisdictional restrictions; (k) protected payment authorization conditions; (l) recurrence restrictions; (m) settlement limits; (n) protected policy and revocation state; (o) freshness requirements; and Das Expires 19 April 2027 [Page 329] Internet-Draft Protected AI Execution Finality October 2026 (p) designated Finality Sink identity. The Market-Compliance Authority Object is an authority input to the PED and is not independently created or modified by an untrusted commercial agent. 11.8.15. WF-08.15 — AIF, ALF, and RBD Validation In embodiments requiring Algorithmic Intent Fingerprint, Algorithmic Logic Fingerprint, or Runtime Behavioral Descriptor validation, PED-806 evaluates the corresponding evidence. The Algorithmic Intent Fingerprint (AIF) represents the authorized commercial purpose or mandate corridor, including permitted purchase, bid, negotiation, payment, pricing, recommendation, or advertising objectives. The Algorithmic Logic Fingerprint (ALF) represents the approved market workflow, auction algorithm, ranking algorithm, pricing process, recommendation logic, commerce execution graph, or payment- initiation process. The Runtime Behavioral Descriptor (RBD) records relevant observed events, which may include: counterparties_contacted; bids_observed; price_changes; ranking_signals_used; negotiation_messages; recommendation_triggers; advertising_signals; self_preferencing_indicators; policy_trigger_events; transaction_attempts; quota_usage. Das Expires 19 April 2027 [Page 330] Internet-Draft Protected AI Execution Finality October 2026 The PED verifies the predicates required by the relevant Authority Object. A risk score or anomaly classifier may provide evidence, but does not automatically establish that prohibited conduct occurred. Where a particular behavioral condition is mandatory, its decision rule and required evidence are defined by the corresponding protected policy. 11.8.16. WF-08.16 — Protected Commercial Authorization Predicates The PED evaluates the applicable commercial predicates. For an illustrative purchase transaction: Vcommerce = Pidentity AND Ppurpose AND Pmerchant AND Pitem AND Pamount AND Pterms AND Pbudget AND Pstate AND Psink where: Vcommerce denotes the protected commerce-validation result; Pidentity verifies the authorized agent or user identity; Ppurpose verifies the authorized commercial objective; Pmerchant verifies the required merchant or counterparty; Pitem verifies the product or service scope; Das Expires 19 April 2027 [Page 331] Internet-Draft Protected AI Execution Finality October 2026 Pamount verifies the permitted price and complete amount; Pterms verifies relevant delivery, warranty, refund, and recurrence conditions; Pbudget verifies the applicable remaining spending limit; Pstate verifies mandatory policy, revocation, freshness, and usage state; Psink verifies the designated Commerce Finality Sink. Additional predicates may apply to jurisdiction, approval, ALF, AIF, RBD, market rules, or other requirements. Each mandatory predicate must succeed. An operation failing any required predicate is not granted the capability necessary for effectuation. 11.8.17. WF-08.17 — Protected Spending-Budget State PS-807 maintains a protected record of the applicable spending budget or transaction allowance. An illustrative budget record comprises: budget_id; authorized_user; authorized_agent_scope; currency; total_limit; committed_amount; reserved_amount; remaining_available_amount; policy_epoch; state_version; revocation_status. Das Expires 19 April 2027 [Page 332] Internet-Draft Protected AI Execution Finality October 2026 The system distinguishes amounts already committed from amounts reserved for pending operations. For a simple single-currency budget: Available = Limit − Committed − Reserved where: Available denotes the amount available for additional authorized operations; Limit denotes the applicable total spending allowance; Committed denotes amounts accounted as completed under the defined accounting rules; Reserved denotes amounts allocated to pending authorized operations. The representation assumes the same currency and amount units for all terms. A multi-currency budget requires an applicable conversion and valuation rule. 11.8.18. WF-08.18 — Atomic Budget Reservation Before issuing an execution capability requiring a protected spending reservation, the PED performs an atomic or otherwise protected reservation operation. Let: A denote the complete authorized amount for the proposed operation; Available denote the protected remaining amount; V denote the current protected budget-state version. The reservation is permitted only if: A ≤ Available and the required authorization conditions remain valid. The protected store then performs a conditional update against the expected state version. Das Expires 19 April 2027 [Page 333] Internet-Draft Protected AI Execution Finality October 2026 An illustrative transition is: (Budget[V], Reserved) → (Budget[V+1], Reserved+A) The transition is committed only when the current protected state corresponds to the expected state and sufficient allowance remains available. If another concurrent operation has already reserved the relevant funds or budget, a stale operation fails its conditional update and is re-evaluated under current protected state. A preliminary balance check alone does not authorize concurrent spending beyond the protected limit. 11.8.19. WF-08.19 — Spending and Authorization-State Consistency Where multiple agents or workers share the same commercial budget, the protected state system prevents unauthorized duplicate reservation or consumption. For example, two agents may simultaneously prepare purchases that would individually satisfy a displayed remaining budget but together exceed the allowed total. The protected conditional state-update procedure ensures that both operations cannot independently succeed against the same outdated budget state. Where the required authorization spans multiple protected stores, the selected embodiment employs the necessary authenticated reservation, transaction, or consistency procedure. The system does not assume that two independently updated eventually consistent counters provide a strict global spending ceiling. If the mandatory budget state cannot be established, capability issuance is withheld. 11.8.20. WF-08.20 — Protected Commerce Validation Evidence Following successful authorization and coordinated with the required protected-state transition, EV-808 generates or commits a Market- Integrity LAVR, ZK-LAVR, or equivalent protected validation record. An illustrative record comprises: Das Expires 19 April 2027 [Page 334] Internet-Draft Protected AI Execution Finality October 2026 receipt_id; candidate_commerce_act_digest; market_authority_object_digest; AIF_validation_result; ALF_validation_result; RBD_validation_result; merchant_identity_reference; total_amount_commitment; budget_reservation_reference; policy_epoch; nonce; revocation_state; finality_sink_id; protected_authentication. The required protected evidence is committed before, or atomically with, availability of the corresponding Commerce Actuation Capability. A conventional payment receipt produced after a transaction is completed does not independently establish that the required pre- effectuation authorization evidence existed. 11.8.21. WF-08.21 — Privacy-Preserving Market Validation Where the applicable embodiment uses a ZK-LAVR, the protected system may prove satisfaction of selected market predicates without revealing protected commercial strategy or private transaction attributes. For example, a proof may establish that: (a) a transaction amount is within an authenticated spending limit; (b) the proposed item is within an approved product class; Das Expires 19 April 2027 [Page 335] Internet-Draft Protected AI Execution Finality October 2026 (c) the merchant belongs to a permitted category; (d) the protected budget state satisfies the required reservation condition; and (e) the proposed operation corresponds to an authenticated authorization commitment. The proof may expose only the public inputs required by the relevant verifier. In an illustrative proof construction: Proof = Prove(PublicInputs, PrivateWitness) where: Proof denotes a cryptographic proof; Prove denotes the selected zero-knowledge proof-generation algorithm; PublicInputs denote authenticated public commitments, policy identifiers, the act digest, and the designated sink; PrivateWitness denotes protected commercial attributes, authority inputs, and state evidence required to establish the specified predicate relation. The corresponding verifier executes: Verify(Proof, PublicInputs) A valid proof establishes only the predicate relation actually encoded in its verification circuit or proof statement. It does not automatically prove commercial fairness, absence of collusion, or compliance with every applicable law unless the necessary properties are accurately represented and verified. 11.8.22. WF-08.22 — Commerce Actuation Capability Following completion of the required protected finality transaction, CR-809 generates or makes available a scoped non-bearer Commerce Actuation Capability. The capability may contain or securely reference: capability_id; Das Expires 19 April 2027 [Page 336] Internet-Draft Protected AI Execution Finality October 2026 candidate_commerce_act_digest; authorized_agent_identity; merchant_or_counterparty_identity; product_or_service_scope; authorized_amount; currency; transaction_class; recurrence_restriction; budget_reservation_id; market_validation_receipt_digest; policy_epoch; nonce; expiry; usage_limit; finality_sink_id. The capability may be represented through a signed artifact, MAC- authenticated object, protected handle, secure capability-table entry, hardware-controlled grant, or another protected enablement mechanism. Where exact transaction binding is required, the capability authorizes the corresponding transaction rather than a general unrestricted spending permission. The capability is not bearer authority merely because the holder can present its representation. The required operation, sink, identity, scope, state, and usage restrictions must still verify. 11.8.23. WF-08.23 — Commerce Finality Sink Verification Before allowing the governed commerce act, FS-810 verifies the operation and its corresponding capability. Das Expires 19 April 2027 [Page 337] Internet-Draft Protected AI Execution Finality October 2026 The Finality Sink obtains or reconstructs the actual effectuation- relevant commercial descriptor. Verification may include: (a) capability authenticity; (b) buyer or requesting-agent identity; (c) merchant or recipient identity; (d) product or service scope; (e) quantity; (f) price and currency; (g) applicable taxes and fees; (h) recurring-payment conditions; (i) authorized commercial purpose; (j) policy epoch; (k) revocation and freshness state; (l) budget-reservation or usage state; (m) receipt commitment; (n) designated Finality Sink identity; and (o) any additional mandatory predicates. An illustrative finality decision is: PermitCommerce = Auth(C) AND Match(C,Dactual) AND MandateValid(C,M) AND BudgetValid(C,B) AND StateValid(C,S) Das Expires 19 April 2027 [Page 338] Internet-Draft Protected AI Execution Finality October 2026 AND SinkValid(C,F) where: PermitCommerce denotes permission to perform the governed commerce act; C denotes the Commerce Actuation Capability; Dactual denotes the commercial operation actually presented for effectuation; M denotes the authenticated user mandate; B denotes the protected budget or reservation state; S denotes the mandatory policy, freshness, revocation, and consumption state; F denotes the designated Commerce Finality Sink; Auth verifies capability authenticity; Match verifies the actual-operation correspondence; MandateValid verifies the commercial scope required by the mandate; BudgetValid verifies required protected budget state; StateValid verifies current mandatory authorization conditions; SinkValid verifies the designated effectuation boundary. Only an operation satisfying every required condition is permitted. 11.8.24. WF-08.24 — Purchase, Payment Authorization, Capture, and Settlement A purchase may involve multiple consequential technical operations. A non-limiting sequence includes: The agent proposes a purchase. The PED validates the Candidate Purchase Act. The protected system reserves the authorized spending amount. Das Expires 19 April 2027 [Page 339] Internet-Draft Protected AI Execution Finality October 2026 The required validation evidence is committed. A purchase or payment-instruction capability is released. The purchase-order or payment-initiation Finality Sink verifies the capability. An authorized order or payment instruction is submitted. A remote payment system may create a payment authorization or hold. A later payment-capture operation may occur. A separate settlement operation may complete at an applicable financial interface. The system may govern one or several of these stages. Where multiple stages are governed, each stage may require its own Candidate Act Descriptor, scoped capability, and Finality Sink verification. An authorization to place an order does not automatically authorize a different later charge. Likewise, a payment authorization response is not always equivalent to completed settlement. The scope of each capability is defined by the actual financial operation it authorizes. 11.8.25. WF-08.25 — Controlled Payment Credential Application Where the commerce act requires a payment credential, the protected system may employ a credential broker or controlled payment- effectuation component. The AI agent may receive a payment-method reference rather than unrestricted access to reusable payment credential material. The applicable credential-effectuation component verifies the transaction-specific Commerce Actuation Capability before using the protected payment credential. The authorization may bind: payment_instrument_reference; Das Expires 19 April 2027 [Page 340] Internet-Draft Protected AI Execution Finality October 2026 merchant_id; recipient_account_or_token; amount; currency; transaction_type; operation_id; policy_epoch; nonce; finality_sink_id. A credential usable for one authorized merchant or payment operation is not thereby authorized for a different recipient, amount, or recurring-payment instruction. Where the payment processor performs additional authorization, the system treats that processor's result according to the actual transaction stage rather than assuming that credential presentation alone establishes final payment completion. The detailed protected credential-release mechanisms are described in WF-04. 11.8.26. WF-08.26 — Merchant Offer Changes and Settlement Consistency A merchant may alter an offer between the initial agent negotiation and final payment. The changed terms may include: (a) price; (b) taxes; (c) delivery charge; (d) item quantity; (e) substitution of another product; (f) warranty conditions; Das Expires 19 April 2027 [Page 341] Internet-Draft Protected AI Execution Finality October 2026 (g) refund conditions; (h) bundling; (i) subscription enrollment; or (j) settlement recipient. Before the governed final operation, the Finality Sink verifies whether the actual transaction remains within the authorized mandate and descriptor binding. Where an offer changes beyond the permitted scope, a new or updated Candidate Commerce Act is required. The system does not treat an earlier approval of a product category as unconditional permission to accept every later price or transaction term. 11.8.27. WF-08.27 — Autonomous Auction and Bid Control In an auction embodiment, an AI bidding agent proposes a bid within a defined authorized strategy. The proposed bid is intercepted before submission to the auction engine. A Candidate Commerce Act Descriptor may bind: auction_id; bidder_identity; item_class; bid_amount; currency; auction_round; bid_limit; remaining_budget; counterparty_class; policy_epoch; Das Expires 19 April 2027 [Page 342] Internet-Draft Protected AI Execution Finality October 2026 nonce; expiry; auction_finality_sink_id. The PED validates the bid against applicable spending limits, auction rules, approved workflow logic, and required runtime-behavior conditions. After successful protected-state reservation and Market-Integrity LAVR commitment, a Commerce Actuation Capability is released. The auction Finality Sink verifies the capability before accepting or submitting the bid. Where each bid is separately consequential, each bid requires its own protected authorization or an expressly bounded rolling authorization covering the permitted bid sequence. An earlier authorized bid does not automatically authorize a higher bid outside the applicable limit. 11.8.28. WF-08.28 — Continuous Commerce and Micro-Validation For autonomous auctions, negotiations, dynamic pricing, advertising or ranking sequences, the system may maintain a series of protected validation events. A sequence may comprise: CA1, CA2, ..., CAn where: CAi denotes the Candidate Commerce Act at step i; i denotes the step index; n denotes the number of acts in the sequence. Each governed act may be associated with a micro-LAVR or an authenticated rolling authorization-state update. A non-limiting receipt-chain relation is: Ri = H(R(i−1) || Di || Vi || Si) Das Expires 19 April 2027 [Page 343] Internet-Draft Protected AI Execution Finality October 2026 where: Ri denotes the protected receipt commitment after act i; R(i−1) denotes the previous protected receipt commitment; Di denotes the act descriptor; Vi denotes the protected validation result; Si denotes the required protected-state commitment; H denotes the selected cryptographic hash function; || denotes concatenation. If the applicable RBD indicates a prohibited coordination condition, unauthorized counterparty change, limit exhaustion, or other mandatory violation, the PED withholds additional Commerce Actuation Capabilities. Previously completed effects are recorded according to their actual outcome state rather than assumed to be reversible. 11.8.29. WF-08.29 — Ranking, Recommendation, and Advertising Effectuation The commerce architecture may also control commercial acts that do not directly move money. For a ranking or recommendation operation, the Candidate Commerce Act may identify: ranking_model_or_workflow; content_or_item_id; proposed_position; recommendation_target; publisher_or_marketplace_id; advertising_disclosure_class; approved_purpose; policy_epoch; Das Expires 19 April 2027 [Page 344] Internet-Draft Protected AI Execution Finality October 2026 finality_sink_id. The PED evaluates the required market-rule, authorized-purpose, ALF, RBD, and applicable protected-state predicates. Following required evidence commitment, a Commerce Actuation Capability is released. The ranking-publication or recommendation-release Finality Sink verifies the capability before making the proposed ranking or recommendation effective. Where an applicable policy prohibits self-preferencing or undisclosed sponsored placement, the relevant decision predicate requires the evidence needed to establish that restriction under the selected policy. A system does not claim to have formally proven the absence of all market manipulation merely because it applies an ordinary classifier or ranking-policy check. 11.8.30. WF-08.30 — Protected Commerce Outcome-State Machine OS-812 maintains a protected outcome record associated with each consequential commercial act. An illustrative state machine comprises: PENDING; VALIDATING; AUTHORIZED; RESERVED; SUBMITTED; CONFIRMED_EFFECTIVE; DENIED; CANCELLED; INDETERMINATE. PENDING denotes an operation awaiting protected authorization. Das Expires 19 April 2027 [Page 345] Internet-Draft Protected AI Execution Finality October 2026 VALIDATING denotes an operation undergoing the required protected checks. AUTHORIZED denotes successful authorization before the required effectuation attempt. RESERVED denotes an operation whose bounded authorization or spending allowance has been reserved. SUBMITTED denotes a request transmitted through the governed interface. CONFIRMED_EFFECTIVE denotes an effect established by evidence meeting the applicable completion predicate. DENIED denotes refusal before the corresponding governed effect. CANCELLED denotes termination of a pending operation under authorized cancellation conditions. INDETERMINATE denotes an operation whose external completion status cannot currently be established. A payment authorization, capture, settlement and refund may have distinct operation and outcome records. The system does not label an operation settled merely because it was submitted or accepted for processing. 11.8.31. WF-08.31 — Protected Spending Reservation Release Where a pending transaction is definitively denied or canceled before effectuation, the system may release its corresponding protected budget reservation. The release occurs only after verifying the protected operation state and applicable recovery conditions. Where the external service may already have effected a payment or order, the system does not automatically restore the full spending allowance merely because a local process timed out. For an indeterminate payment, the reservation may remain allocated or be handled through a separately defined protected reconciliation rule. This prevents a series of ambiguous transactions from independently consuming the same apparent remaining budget. Das Expires 19 April 2027 [Page 346] Internet-Draft Protected AI Execution Finality October 2026 11.8.32. WF-08.32 — Duplicate Purchase and Payment Protection The system associates each consequential commerce operation with an operation identifier and applicable protected authorization state. The Finality Sink verifies usage or consumption conditions before performing the governed effect. A single-use Commerce Actuation Capability cannot be independently consumed more than the permitted number of times. For remote payment or marketplace interfaces supporting idempotency identifiers, the controlled connector may bind the idempotency identifier to the protected operation identifier. Where a transaction submission times out, the recovery component consults the protected outcome state and any authenticated remote transaction information before permitting another attempt. If completion remains indeterminate, the system withholds an independently reusable authorization unless a protected recovery predicate establishes that the proposed additional attempt will not cause an unauthorized duplicate effect. The architecture does not assert unconditional exactly-once execution at arbitrary remote payment systems. 11.8.33. WF-08.33 — Concrete Autonomous Purchase Example In one illustrative embodiment, an AI purchasing assistant receives an authenticated user instruction to purchase an approved office accessory within a specified maximum total amount. The user's mandate defines: (a) the permitted product class; (b) the authorized quantity; (c) the maximum complete purchase price; (d) the permitted currency; (e) acceptable merchant or marketplace conditions; (f) relevant delivery requirements; (g) a prohibition against unauthorized recurring subscriptions; and Das Expires 19 April 2027 [Page 347] Internet-Draft Protected AI Execution Finality October 2026 (h) the applicable authorization validity period. The mandate is recorded or authenticated under control of PED-806. The agent searches a marketplace and receives candidate product information. The agent selects a proposed product and prepares a purchase request. The merchant returns a proposed offer containing the item identity, quantity, unit price, applicable taxes, delivery charge, payment terms, and merchant identity. IM-802 intercepts the proposed purchase before the order or payment becomes effective. DC-804 constructs the Candidate Commerce Act Descriptor. PED-806 verifies the merchant identity, authorized purpose, product class, quantity, total price, currency, recurrence restriction, and applicable protected-state conditions. PS-807 checks the remaining spending allowance and performs the required protected reservation. EV-808 commits the Market-Integrity LAVR or equivalent protected validation record. CR-809 releases a Commerce Actuation Capability bound to the transaction descriptor, merchant identity, complete authorized amount, policy epoch, nonce, and designated Finality Sink. The checkout or payment interface receives the actual operation presented for effectuation. FS-810 verifies that the actual merchant, item, amount, currency, terms, protected reservation, and capability remain valid. If the merchant adds an unauthorized recurring subscription, changes the recipient, or increases the complete price outside the mandate, the Finality Sink refuses the operation. If all required predicates succeed, the controlled commerce interface submits the authorized operation. OS-812 subsequently records the supported completion state based on the actual external result. Das Expires 19 April 2027 [Page 348] Internet-Draft Protected AI Execution Finality October 2026 A lost response does not independently authorize an additional purchase. 11.8.34. WF-08.34 — Example of Merchant-Agent Manipulation In another embodiment, a merchant-side agent proposes a product substitution or additional fee during autonomous negotiation. The buyer agent may regard the altered proposal as commercially acceptable based on generated reasoning. However, the protected user mandate restricts the permitted product class, maximum amount, recurrence conditions, and merchant scope. The final settlement descriptor is reconstructed from the actual proposed transaction payload. The PED compares the final settlement descriptor against the protected mandate corridor. If the substituted product, fee, bundle, recurring obligation, or recipient violates the applicable mandate, the required authorization predicate fails. No valid Commerce Actuation Capability is released for the incompatible transaction. Where the substituted operation has already received an earlier capability but a mandatory bound parameter changes before effectuation, the Finality Sink refuses the changed operation. The agent's decision to accept the revised terms cannot independently override the protected user mandate. 11.8.35. WF-08.35 — Failure and Fail-Closed Handling The protected system withholds an affected Candidate Commerce Act when a mandatory condition cannot be verified. Failures may include: (a) invalid user mandate; (b) unauthorized merchant; (c) counterparty identity mismatch; (d) prohibited item or service substitution; Das Expires 19 April 2027 [Page 349] Internet-Draft Protected AI Execution Finality October 2026 (e) spending-limit violation; (f) incompatible currency; (g) changed taxes or additional fees outside permitted bounds; (h) unauthorized recurring-payment condition; (i) invalid transaction purpose; (j) required approval mismatch; (k) unavailable protected budget state; (l) concurrent reservation conflict; (m) invalid Market-Integrity LAVR; (n) expired or revoked Commerce Actuation Capability; (o) capability replay; (p) unauthorized Finality Sink substitution; (q) missing mandatory settlement-state evidence; or (r) failure of the required Finality Sink verification. The operation may be denied, retained as non-effective, escalated for authorized review, or converted into a non-binding recommendation where such handling is permitted. An operation already confirmed externally effective is not retroactively prevented by a subsequent denial or quarantine event. 11.8.36. WF-08.36 — Implementation Alternatives Marketplace gateway implementation: A protected gateway controls order submission and verifies operation-specific Commerce Actuation Capabilities. Payment gateway implementation: A payment-instruction interface verifies a capability bound to the merchant, amount, currency, payment instrument scope, and protected authorization state. Auction implementation: A bidding engine verifies a capability before admitting the applicable bid. Das Expires 19 April 2027 [Page 350] Internet-Draft Protected AI Execution Finality October 2026 Ranking implementation: A ranking-publication service verifies a capability before releasing the ranking change. Advertising implementation: An ad-placement gateway verifies a capability before committing or publishing a governed placement. Inventory implementation: An inventory-management service verifies a capability before making the governed allocation effective. Hardware-rooted implementation: An HSM, secure enclave, SmartNIC, DPU, protected payment controller, or equivalent mechanism enforces the required capability-dependent operation. Receiving-side implementation: A marketplace, payment service, or transaction processor independently verifies an authenticated authorization artifact before accepting the governed consequential operation. Single-node implementation: The protected authority and Commerce Finality Sink operate within one enforcement-controlled commerce node. Distributed implementation: The PED and Commerce Finality Sink operate on separate nodes and maintain the required authorization- state and capability-verification relationship through authenticated mechanisms. The implementation need not use identical cryptographic hardware or operating-system substrates, but must provide the enforcement guarantees required by the corresponding claim. 11.8.37. WF-08.37 — PHOSITA Verification and Negative Tests A person having ordinary skill in payment systems, marketplace architecture, auction platforms, distributed transaction systems, cryptography, or protected execution may verify the embodiment through controlled tests. Test 1 — Authorized purchase: Submit a transaction matching the protected mandate and available budget. Verify successful authorization and capability-dependent effectuation. Test 2 — Price increase: Increase the transaction price beyond the authorized limit. Verify refusal. Test 3 — Added fees: Add unauthorized taxes, delivery charges, or service fees that violate the total-amount constraint. Verify refusal. Das Expires 19 April 2027 [Page 351] Internet-Draft Protected AI Execution Finality October 2026 Test 4 — Merchant substitution: Change the required merchant or payment recipient. Verify descriptor mismatch. Test 5 — Subscription conversion: Convert a one-time purchase into a recurring payment. Verify failure of the protected recurrence predicate. Test 6 — Product substitution: Replace the approved item with a product outside the authorized scope. Verify refusal. Test 7 — Currency mismatch: Change the currency without valid protected authorization. Verify failure. Test 8 — Concurrent purchases: Submit two transactions competing for the same limited budget. Verify that the protected reservation mechanism prevents spending beyond the permitted amount. Test 9 — Missing capability: Present a payment instruction without the required Commerce Actuation Capability. Verify refusal at the Finality Sink. Test 10 — Capability replay: Reuse a consumed single-use commerce capability. Verify that protected usage-state verification rejects unauthorized reuse. Test 11 — Policy revocation: Revoke the required authority before effectuation. Verify that the affected Finality Sink refuses further operation under the invalid state. Test 12 — Changed payment instrument: Substitute a payment method outside the authorized scope. Verify refusal. Test 13 — Lost remote response: Simulate a timeout after a payment request may have reached the processor. Verify that the operation enters an appropriate protected reconciliation state. Test 14 — Duplicate charge attempt: Repeat a transaction using the same protected authorization. Verify that usage controls or authorized idempotency mechanisms prevent unauthorized duplicate effectuation. Test 15 — Auction bid escalation: Submit a bid exceeding the permitted bid corridor. Verify withholding of the commerce capability. Test 16 — Continuous auction: Cause a mandatory RBD or budget condition to fail during a sequence of bids. Verify withholding of further required capabilities. Das Expires 19 April 2027 [Page 352] Internet-Draft Protected AI Execution Finality October 2026 Test 17 — Ranking substitution: Present a different required ranking or recommendation target after validation. Verify rejection at the publication Finality Sink. Test 18 — Approval mismatch: Supply a user approval artifact for a different amount or merchant. Verify refusal. Test 19 — Unavailable protected budget state: Interrupt access to a mandatory protected budget record. Verify fail-closed capability issuance. Test 20 — Multiple effectuation boundaries: Verify that authority to submit an order does not automatically permit an independently governed later capture or settlement operation. Test 21 — Merchant offer drift: Alter an authenticated offer after authorization. Verify the required final settlement-descriptor comparison. Test 22 — Recovery after cancellation: Verify that a pending budget reservation is released only under an authorized protected recovery procedure. Test 23 — Indeterminate transaction: Simulate an operation whose completion cannot be established. Verify that the system does not automatically assume either successful settlement or absence of effect. Test 24 — Unauthorized direct connector: Attempt to submit the commercial operation through a different unrestricted interface. Verify that the governed path remains blocked or equivalently mediated. 11.8.38. WF-08.38 — Technical Effect The embodiment establishes a protected execution-finality dependency between: (a) an authorized commercial mandate; (b) a proposed Candidate Commerce Act; (c) interception and Non-Effective State; (d) effectuation-relevant transaction-descriptor construction; (e) Market-Compliance Authority Object validation; Das Expires 19 April 2027 [Page 353] Internet-Draft Protected AI Execution Finality October 2026 (f) applicable AIF, ALF, and RBD verification; (g) merchant, counterparty, amount, and transaction-scope validation; (h) protected budget and usage-state handling; (i) required validation-evidence commitment; (j) scoped non-bearer Commerce Actuation Capability availability; (k) independent verification at the corresponding Commerce Finality Sink; and (l) controlled effectuation or fail-closed withholding. The system prevents an autonomous commerce agent from converting its ability to search, recommend, negotiate, bid, price, plan, or prepare a payment into unrestricted authority to produce a legally, economically, operationally, or settlement-relevant consequence. The system also distinguishes a protected budget reservation from a completed commercial effect, and distinguishes authorization for one commercial stage from authorization for another independently governed stage. Computation is not authority to act. An agent's decision to buy is not authority to charge. An authorized amount or merchant cannot be silently replaced at the actual Commerce Finality Sink. 11.9. WF-09 — Protected Agent Self-Modification, Policy-Digest Transitions, Developer Approval, and Mutation-Activation Finality 11.9.1. WF-09.1 — Technical Purpose This embodiment provides a computer-implemented execution-finality system for governing modifications proposed by an artificial- intelligence agent to its own execution environment, authority configuration, behavioral policy, model configuration, workflow, or other operational state. The system prevents an artificial-intelligence agent from independently expanding, weakening, replacing, disabling, or circumventing applicable execution-authority restrictions merely by generating or applying a new configuration. Das Expires 19 April 2027 [Page 354] Internet-Draft Protected AI Execution Finality October 2026 A proposed modification is classified as a Candidate Self-Mutation Act and maintained in a Non-Effective State. A Protected Enforcement Domain (PED) validates the proposed modification against a Self-Mutation Authority Object, the currently effective protected configuration, authorized mutation classes, approved safety conditions, applicable evaluation evidence, required developer approval, policy and revocation state, and other mandatory predicates. Upon successful validation and the required protected-state and evidence-commitment operations, the PED releases or makes available a scoped Self-Modification Capability. A mutation-activation Finality Sink independently verifies the capability against the actual proposed modification, current pre- mutation state, required post-mutation state, and applicable activation context before making the modification effective. The resulting arrangement separates the computational ability to propose a self-modification from the protected authority required to activate that modification. 11.9.2. WF-09.2 — Participating Technical Components In a non-limiting embodiment, the system comprises: AE-901 — Agent Execution Environment An artificial-intelligence agent, model runtime, autonomous coding agent, planning system, tool runtime, or associated computational environment capable of preparing or proposing modifications. MI-902 — Mutation Interception Component An enforcement-controlled mechanism configured to intercept proposed modifications before activation. MS-903 — Non-Effective Mutation Staging Mechanism A protected or enforcement-controlled staging area maintaining proposed configuration changes without making them effective. DC-904 — Mutation Descriptor Construction Component A component configured to construct a canonical Candidate Self- Mutation Act Descriptor identifying the proposed transition. Das Expires 19 April 2027 [Page 355] Internet-Draft Protected AI Execution Finality October 2026 CS-905 — Configuration State Store A version-controlled mechanism maintaining effective and staged configuration artifacts, associated measurements, and transition records. AO-906 — Self-Mutation Authority Object Store An authenticated source of applicable mutation authority, permitted mutation classes, safety restrictions, approval requirements, and protected state conditions. PED-907 — Protected Enforcement Domain A protected component configured to perform authorization-predicate validation, required protected-state handling, and control over mutation-capability issuance. ES-908 — Evaluation and Regression-Evidence Component A mechanism configured to produce, authenticate, or verify required evaluation results, regression-test evidence, safety-baseline comparisons, and related measurements. UA-909 — Developer or Operator Authorization Component A component configured to obtain and authenticate an approval artifact from an authorized developer, administrator, operator, or other permitted authority. PS-910 — Protected Authorization-State Store A protected mechanism maintaining policy epochs, revocation state, nonce state, authorization commitments, capability usage, and mutation-transition state. EV-911 — Protected Validation-Evidence Component A mechanism configured to generate or commit the required protected validation evidence, including a LAVR, AVR, authenticated receipt, or equivalent protected commitment. CR-912 — Self-Modification Capability Mechanism A protected mechanism configured to generate, register, release, or make available a scoped non-bearer Self-Modification Capability. FS-913 — Mutation-Activation Finality Sink Das Expires 19 April 2027 [Page 356] Internet-Draft Protected AI Execution Finality October 2026 An enforcement-controlled interface configured to verify the Self- Modification Capability before activating the proposed modification. AM-914 — Protected Activation Manager A policy manager, agent orchestrator, model server, tool gateway, retrieval-policy controller, memory manager, adapter loader, or equivalent component that performs the authorized state transition. RC-915 — Protected Recovery and Revocation Component A component configured to govern cancellation, recovery, rollback, revocation, and revalidation of mutation operations. OS-916 — Mutation Outcome-State Store A mechanism maintaining protected information identifying the state and result of each proposed mutation. The components may be physically integrated or distributed, provided that the applicable protected authority and activation-verification dependencies remain enforceable. 11.9.3. WF-09.3 — Establishment of the Mutation Trust Boundary Before autonomous agent operation, the system establishes a boundary between agent-controlled computation and protected mutation authority. AE-901 may generate configuration files, policies, proposed prompts, tool graphs, adapter artifacts, workflow modifications, or other candidate mutation material. However, the agent does not possess unrestricted authority to write the effective configuration consumed by the governed runtime. The effective configuration may be held in protected storage, an access-controlled policy store, a signed configuration registry, a protected runtime table, or an equivalent enforcement-controlled mechanism. The agent's access to a proposed configuration or staging artifact does not independently make that configuration effective. AM-914 accepts an effective-state transition only through the applicable mutation-activation Finality Sink. Das Expires 19 April 2027 [Page 357] Internet-Draft Protected AI Execution Finality October 2026 Where the operation could be performed through alternative administrative interfaces, those interfaces are disabled, restricted, or subjected to equivalent protected activation requirements. The system does not assume that ordinary file permissions alone establish non-bypassable mutation control when the agent possesses another route capable of changing the effective configuration. 11.9.4. WF-09.4 — Identification of Governed Mutation Classes The system identifies modifications that require protected execution- finality control. Non-limiting mutation classes include: (a) execution-policy modification; (b) tool-access-policy modification; (c) system-instruction or system-message modification; (d) safety-policy modification; (e) retrieval-policy modification; (f) memory-policy modification; (g) delegation-policy modification; (h) planner-policy modification; (i) model-configuration modification; (j) adapter installation or replacement; (k) model-runtime configuration change; (l) workflow-graph modification; (m) tool-permission expansion; (n) execution-budget modification; (o) connector authorization change; (p) policy removal or disablement; (q) protected authority-reference replacement; and Das Expires 19 April 2027 [Page 358] Internet-Draft Protected AI Execution Finality October 2026 (r) another modification affecting future governed behavior or execution authority. An ordinary temporary data transformation need not constitute a governed self-mutation unless the applicable policy identifies the resulting state change as consequential. Where a proposed operation comprises both a configuration mutation and an external tool operation, the implementation identifies the separate consequential boundaries that require authorization. 11.9.5. WF-09.5 — Candidate Self-Mutation Act Generation AE-901 generates a proposed modification to its execution environment or associated policy state. The proposed modification is designated Candidate Self-Mutation Act CSM-917. A non-limiting example comprises an agent proposing to modify its tool policy to permit a previously restricted API operation. Another example comprises installing a newly generated tool or adapter. A further example comprises changing a system instruction, retrieval scope, memory permission, delegation limit, or safety-policy rule. The agent may generate an explanation, test result, proposed patch, candidate configuration, or modification rationale. Such generated material may be evaluated, but it does not independently authorize the mutation. 11.9.6. WF-09.6 — Mandatory Mutation Interception MI-902 intercepts the proposed modification before it reaches the corresponding effective-state activation interface. In one implementation, the agent submits the proposed mutation through an authenticated configuration-change broker. In another implementation, mutation requests are intercepted at a policy manager, model loader, adapter loader, agent orchestrator, workflow controller, tool gateway, or memory-management interface. The interception mechanism identifies the mutation class, requesting agent, target configuration, and intended activation boundary. Das Expires 19 April 2027 [Page 359] Internet-Draft Protected AI Execution Finality October 2026 The proposed operation is assigned a mutation identifier. An illustrative mutation record comprises: mutation_id; requesting_agent_identity; affected_runtime_identity; mutation_class; target_configuration_reference; proposed_artifact_reference; authority_reference; policy_epoch; activation_sink_id; status = NON_EFFECTIVE. The mutation is not applied to the active runtime merely because its proposed configuration has been accepted into the staging mechanism. 11.9.7. WF-09.7 — Non-Effective Mutation Staging MS-903 retains the proposed mutation in a staging location separate from the effective configuration used by the governed runtime. The staged material may comprise: (a) an immutable configuration object; (b) a proposed policy document; (c) a candidate workflow graph; (d) a candidate tool-permission graph; (e) a proposed adapter artifact; (f) a candidate system-instruction configuration; (g) a proposed retrieval-permission table; Das Expires 19 April 2027 [Page 360] Internet-Draft Protected AI Execution Finality October 2026 (h) a memory-policy revision; (i) a signed candidate release bundle; or (j) an equivalent inactive configuration representation. The staging mechanism permits the proposed modification to undergo analysis, testing, approval, and protected validation without granting it active execution authority. Where the staged object is referenced by digest, the system verifies that the object actually activated corresponds to the validated content. A mutable staging file is not treated as an immutable authorization target unless its integrity is protected or reverified at activation. 11.9.8. WF-09.8 — Pre-Mutation State Measurement CS-905 obtains a machine-verifiable representation of the currently effective configuration. The representation may contain: runtime_identity; configuration_id; configuration_generation; current_policy_digest; current_tool_graph_digest; current_workflow_digest; current_model_configuration_digest; current_safety_baseline_reference; current_ALF; current_policy_epoch; current_revocation_epoch. The particular fields depend upon the mutation class and the applicable Authority Object. Das Expires 19 April 2027 [Page 361] Internet-Draft Protected AI Execution Finality October 2026 A protected configuration-generation value may be maintained to distinguish successive configurations having similar names or file paths. The current configuration measurement is obtained from the authoritative effective-state mechanism rather than solely from an agent-supplied description. 11.9.9. WF-09.9 — Proposed Post-Mutation State Measurement The system constructs or verifies a representation of the proposed post-mutation configuration. An illustrative post-mutation record contains: proposed_configuration_id; proposed_configuration_digest; proposed_tool_graph_digest; proposed_workflow_digest; proposed_model_configuration_digest; proposed_safety_configuration; proposed_ALF; mutation_class; affected_runtime_identity; target_activation_boundary. The proposed configuration is measured using the same defined representation rules applicable to its configuration class. Where a configuration consists of multiple files or components, the measurement may comprise an authenticated manifest, Merkle-root commitment, signed bundle, or another deterministic composite representation. The measurement binds the actual proposed artifacts rather than merely recording a human-readable description of the proposed change. Das Expires 19 April 2027 [Page 362] Internet-Draft Protected AI Execution Finality October 2026 11.9.10. WF-09.10 — Canonical Mutation Descriptor DC-904 constructs a canonical Candidate Self-Mutation Act Descriptor. A non-limiting descriptor comprises: mutation_id; requesting_agent_identity; affected_runtime_identity; mutation_class; pre_mutation_configuration_digest; post_mutation_configuration_digest; pre_mutation_ALF; post_mutation_ALF; changed_permission_scope; affected_tool_graph; affected_retrieval_scope; affected_memory_scope; affected_delegation_scope; required_approval_class; evaluation_evidence_reference; safety_baseline_reference; policy_epoch; revocation_epoch; nonce; expiry; mutation_activation_sink_id. Das Expires 19 April 2027 [Page 363] Internet-Draft Protected AI Execution Finality October 2026 Only the fields required by the applicable mutation are mandatory. An illustrative descriptor expression is: Dmut = Canon_v(ID, R, K, Hpre, Hpost, Delta, E, N, F) where: Dmut denotes the canonical Candidate Self-Mutation Act Descriptor; Canon_v denotes a deterministic canonicalization procedure of version v; ID denotes the requesting agent or authorized workload identity; R denotes the affected runtime or configuration identity; K denotes the mutation class; Hpre denotes the pre-mutation configuration digest; Hpost denotes the proposed post-mutation configuration digest; Delta denotes the effectuation-relevant difference between the configurations; E denotes the applicable protected policy epoch; N denotes the required nonce or freshness value; F denotes the mutation-activation Finality Sink identity. The descriptor may be authenticated by a cryptographic commitment: hmut = H("DAS-SELF-MUTATION-v1" || Encode(Dmut)) where: hmut denotes the mutation descriptor digest; H denotes an approved cryptographic hash function; Encode denotes the specified deterministic byte encoding; || denotes concatenation. The cryptographic algorithms and domain-separation label are illustrative implementation choices. Das Expires 19 April 2027 [Page 364] Internet-Draft Protected AI Execution Finality October 2026 11.9.11. WF-09.11 — Configuration Difference and Authority Expansion Analysis The system computes or verifies the difference between the effective configuration and proposed configuration. For an implementation representing permitted operations as sets: Pbefore denotes the set of operations permitted by the current policy; Pafter denotes the set of operations permitted by the proposed policy. The newly permitted operation set is: Expansion = Pafter \ Pbefore where: \ denotes set difference. The operations removed from the previous permission set are: Restriction = Pbefore \ Pafter The effective mutation may contain both expansions and restrictions. For example, a proposed policy may disable one tool while enabling another. The protected validation identifies the relevant permission changes rather than assuming that the overall modification is safe because some restrictions have been added. Where policies depend upon context, purpose, time, destination, workload identity, or resource scope, the permitted-operation set is interpreted over the corresponding complete authorization context. A simple textual difference between two policy documents is not necessarily sufficient to establish their effective security difference. Where the effective permission relation cannot be determined with the assurance required by the policy, the mutation is denied or subjected to a separately authorized validation procedure. Das Expires 19 April 2027 [Page 365] Internet-Draft Protected AI Execution Finality October 2026 11.9.12. WF-09.12 — Self-Mutation Authority Object PED-907 obtains the applicable Self-Mutation Authority Object from AO-906. The Authority Object may specify: (a) requesting workload identity; (b) authorized mutation purpose; (c) permitted mutation classes; (d) prohibited mutation classes; (e) current policy digest; (f) proposed policy digest or permitted post-state conditions; (g) allowed authority expansion; (h) applicable safety baseline; (i) regression-test requirements; (j) evaluation requirements; (k) pre-mutation ALF; (l) post-mutation ALF; (m) applicable AIF; (n) applicable RBD or Reasoning Trace Descriptor; (o) developer or operator approval requirements; (p) permitted runtime or tool scope; (q) policy epoch; (r) revocation state; (s) nonce and expiry; (t) protected validation-evidence requirements; and (u) designated mutation-activation Finality Sink. Das Expires 19 April 2027 [Page 366] Internet-Draft Protected AI Execution Finality October 2026 The requesting agent cannot modify the Authority Object merely by altering its own proposed policy file. The Authority Object is authenticated and evaluated against the required protected state. 11.9.13. WF-09.13 — Protected Baseline and Mutation-Class Validation PED-907 determines whether the proposed mutation belongs to a permitted mutation class and preserves the required protected safety and authority conditions. For example, a modification that changes an approved tool's descriptive metadata may be permitted without expanding its effectuation authority. A modification that adds external network access, enables credential use, disables a protected broker, or modifies the Finality Sink verification requirement may require stronger authorization or be prohibited. The PED verifies that the proposed configuration does not remove a mandatory enforcement dependency required by the applicable protected policy. A protected safety baseline may identify required controls including: mandatory_interception; protected_authority_separation; validation_evidence_commitment; capability_scope_binding; finality_sink_verification; revocation_check; fail_closed_behavior. A proposed policy modification cannot bypass these mandatory conditions by redefining an unrestricted execution operation as a benign operation class. Das Expires 19 April 2027 [Page 367] Internet-Draft Protected AI Execution Finality October 2026 11.9.14. WF-09.14 — AIF, ALF, and Runtime-Behavior Validation Where required by the applicable Authority Object, PED-907 validates the Algorithmic Intent Fingerprint (AIF), Algorithmic Logic Fingerprint (ALF), or Runtime Behavioral Descriptor (RBD) associated with the mutation. The AIF may identify the authorized purpose of the proposed self- modification. The ALF may represent the relevant approved workflow, executable configuration, policy graph, tool graph, model configuration, adapter state, or other approved algorithmic logic. The RBD may identify observed runtime behavior leading to the proposed modification. The system may compare ALF measurements before and after the mutation. A changed ALF does not automatically imply an unauthorized change; instead, the new ALF must satisfy the applicable approved post- mutation condition. Where the modification includes model or workflow changes whose full behavior cannot be formally determined, the PED applies the specified measurable predicates, evidence requirements, and approved uncertainty handling. The embodiment does not assume that a fingerprint alone mathematically proves every future behavior of an arbitrary AI model. 11.9.15. WF-09.15 — Evaluation and Regression-Evidence Generation ES-908 performs or obtains evaluation evidence required for the proposed mutation. The evidence may include: (a) regression-test results; (b) tool-permission tests; (c) retrieval-permission tests; (d) safety-policy compatibility tests; (e) protected authority-boundary tests; Das Expires 19 April 2027 [Page 368] Internet-Draft Protected AI Execution Finality October 2026 (f) model-configuration integrity measurements; (g) prohibited-operation tests; (h) workflow-graph validation; (i) deployment compatibility checks; and (j) other required evaluation results. The evaluation environment may use a controlled staging runtime that does not possess unrestricted production execution authority. A non-limiting evaluation-evidence record comprises: evaluation_id; mutation_id; candidate_configuration_digest; test_suite_digest; test_environment_measurement; evaluation_result_digest; required_test_results; safety_baseline_reference; evaluator_identity; evaluation_timestamp_or_freshness; protected_authentication. The validation binds the evaluation evidence to the exact staged candidate configuration. 11.9.16. WF-09.16 — Regression and Safety Evidence Verification PED-907 verifies the authenticity and applicability of required evaluation evidence. Verification may include: (a) whether the evaluated artifact matches the proposed mutation; Das Expires 19 April 2027 [Page 369] Internet-Draft Protected AI Execution Finality October 2026 (b) whether the required test suite was used; (c) whether the evaluator satisfies the applicable identity or attestation conditions; (d) whether mandatory regression tests passed; (e) whether the approved safety baseline remains satisfied; (f) whether prohibited operation classes remain restricted; (g) whether the test evidence is fresh enough for the selected policy; and (h) whether the proposed authority expansion is permitted. An illustrative condition is: Peval = ArtifactMatch AND TestsSatisfied AND BaselineValid AND EvidenceAuthentic where: Peval denotes the evaluation predicate; ArtifactMatch verifies correspondence between the evaluated and proposed artifacts; TestsSatisfied verifies the mandatory test conditions; BaselineValid verifies the applicable safety-baseline conditions; EvidenceAuthentic verifies the required evidence authenticity. A regression-test digest does not independently prove that every possible failure has been excluded. It establishes the relationship to a defined evaluation procedure and its verified results. 11.9.17. WF-09.17 — Developer or Operator Approval Where developer or operator authorization is required, UA-909 obtains an authenticated approval artifact. The approval may be associated with: approval_id; Das Expires 19 April 2027 [Page 370] Internet-Draft Protected AI Execution Finality October 2026 approver_identity; mutation_id; pre_mutation_digest; post_mutation_digest; approved_mutation_class; authorized_scope_change; affected_runtime_identity; evaluation_evidence_digest; policy_epoch; nonce; expiry; approval_authentication. An approval artifact may be signed by an approved developer key, generated through an authenticated administrative service, recorded in a protected approval system, or obtained through another mechanism satisfying the applicable authority requirements. The PED verifies that the approver possesses the necessary authority for the particular mutation. A general approval to improve the agent does not independently authorize an unrestricted tool-permission expansion. Likewise, approval of one post-mutation policy digest does not authorize activation of a different configuration. 11.9.18. WF-09.18 — Developer Approval as a Protected Predicate An illustrative approval predicate is: Papproval = ApproverValid AND MutationMatch AND ScopeMatch AND ApprovalCurrent where: Papproval denotes the protected approval-validation result; Das Expires 19 April 2027 [Page 371] Internet-Draft Protected AI Execution Finality October 2026 ApproverValid verifies the authenticated approver and required approval authority; MutationMatch verifies correspondence to the proposed mutation and relevant pre- and post-state commitments; ScopeMatch verifies the approved mutation class and authority change; ApprovalCurrent verifies nonce, expiry, epoch, and revocation conditions. Approval is required only where specified by the applicable Authority Object or claim. Successful approval does not itself cause activation. The proposed modification must still complete the required protected validation, evidence commitment, scoped capability release, and mutation-activation Finality Sink verification. 11.9.19. WF-09.19 — Overall Protected Mutation Validation PED-907 evaluates the required authorization predicates. For a conjunctive authorization embodiment: Vmut = Pidentity AND Pclass AND Pprestate AND Ppoststate AND Psafety AND Peval AND Papproval AND Pepoch AND Prevocation where: Das Expires 19 April 2027 [Page 372] Internet-Draft Protected AI Execution Finality October 2026 Vmut denotes the protected mutation-validation result; Pidentity verifies the requesting execution context; Pclass verifies the permitted mutation class; Pprestate verifies the applicable current configuration; Ppoststate verifies the proposed configuration and permitted scope; Psafety verifies mandatory safety and enforcement conditions; Peval verifies required evaluation evidence; Papproval verifies developer approval where required; Pepoch verifies the applicable protected policy epoch; Prevocation verifies required current revocation conditions. Only the predicates required by the applicable Authority Object are evaluated as mandatory. Where any required condition fails, the PED withholds the Self- Modification Capability. An approved alternative or threshold authorization policy is evaluated according to its expressly defined protected predicate rules. 11.9.20. WF-09.20 — Protected Mutation-State Record PS-910 maintains an operation-specific protected mutation record. An illustrative record comprises: mutation_id; requesting_workload_identity; target_runtime_identity; pre_configuration_digest; post_configuration_digest; mutation_class; Das Expires 19 April 2027 [Page 373] Internet-Draft Protected AI Execution Finality October 2026 authorized_scope_change; approval_reference; evaluation_evidence_reference; policy_epoch; revocation_epoch; nonce; state_version; validation_commitment; capability_id; activation_sink_id; status. A proposed mutation may occupy one of the following states: PROPOSED; STAGED; VALIDATING; VALIDATED; COMMITTED; ACTIVATION_RESERVED; ACTIVE; DENIED; REVOKED; INDETERMINATE. A mutation in PROPOSED, STAGED, VALIDATING, VALIDATED, or COMMITTED state does not automatically mean that the proposed configuration is active. Das Expires 19 April 2027 [Page 374] Internet-Draft Protected AI Execution Finality October 2026 The effective runtime configuration changes only through the applicable protected activation procedure. 11.9.21. WF-09.21 — Protected Validation-Evidence Commitment Following successful validation, EV-911 generates or commits the required protected validation evidence. The evidence may include: receipt_id; mutation_descriptor_digest; Self-Mutation_Authority_Object_reference; pre_configuration_digest; post_configuration_digest; approved_mutation_class; AIF_or_ALF_validation_reference; evaluation_evidence_digest; developer_approval_reference; protected_state_transition; policy_epoch; revocation_epoch; nonce; finality_sink_id; protected_authentication. The evidence may comprise a LAVR, authenticated validation record, sealed commitment, or equivalent protected representation. The required evidence is committed before, or atomically with, capability availability. A post-activation audit log does not replace a required protected pre-activation validation-evidence commitment. Das Expires 19 April 2027 [Page 375] Internet-Draft Protected AI Execution Finality October 2026 11.9.22. WF-09.22 — Scoped Self-Modification Capability Upon successful completion of the required protected finality transaction, CR-912 releases or makes available a Self-Modification Capability. An illustrative capability contains or securely references: capability_id; mutation_descriptor_digest; pre_configuration_digest; post_configuration_digest; authorized_mutation_class; affected_runtime_identity; permitted_scope_change; evaluation_evidence_commitment; approval_commitment; validation_evidence_digest; policy_epoch; revocation_epoch; nonce; expiry; usage_limit; activation_sink_id. The capability may comprise a signed authorization artifact, MAC- authenticated representation, sealed handle, protected capability- table entry, or equivalent protected enablement mechanism. The capability is scoped to the applicable mutation and activation boundary. Das Expires 19 April 2027 [Page 376] Internet-Draft Protected AI Execution Finality October 2026 Where mandatory, a capability issued for one policy transition cannot be used for another transition, even if both modifications were proposed by the same agent. The capability remains non-bearer when the receiving activation mechanism enforces the required operation, runtime, configuration, scope, state, and consumption bindings. 11.9.23. WF-09.23 — Verification at the Mutation-Activation Finality Sink FS-913 receives the staged mutation and its associated capability or protected capability reference. Before activation, the Finality Sink obtains the actual current configuration and the actual proposed post-mutation artifact. The Finality Sink verifies: (a) capability authenticity; (b) requesting or affected runtime identity; (c) authorized mutation class; (d) actual pre-mutation configuration digest; (e) actual proposed post-mutation configuration digest; (f) authorized scope change; (g) required evaluation and approval commitments; (h) current protected policy and revocation state; (i) nonce, expiry, and usage conditions; (j) required validation-evidence commitment; and (k) designated mutation-activation boundary identity. A capability authorizing one configuration transition is not treated as sufficient authorization for a different configuration. 11.9.24. WF-09.24 — Activation Predicate The Finality Sink may evaluate: Das Expires 19 April 2027 [Page 377] Internet-Draft Protected AI Execution Finality October 2026 PermitMutation = Auth(C) AND PreMatch(C,Hcurrent) AND PostMatch(C,Hcandidate) AND ScopeValid(C,Delta) AND StateValid(C,S) AND SinkValid(C,F) where: PermitMutation denotes permission to activate the proposed mutation; C denotes the Self-Modification Capability; Hcurrent denotes the authoritative digest of the currently effective configuration; Hcandidate denotes the digest of the staged artifact actually proposed for activation; Delta denotes the actual authority-relevant configuration change; S denotes the required protected authorization state; F denotes the mutation-activation Finality Sink; Auth verifies capability authenticity; PreMatch verifies the authorized pre-mutation configuration; PostMatch verifies the authorized proposed post-mutation configuration; ScopeValid verifies the permitted mutation class and authority changes; StateValid verifies required policy, revocation, freshness, approval, evidence, and consumption state; SinkValid verifies the intended activation boundary. The mutation proceeds only if PermitMutation is true. Das Expires 19 April 2027 [Page 378] Internet-Draft Protected AI Execution Finality October 2026 11.9.25. WF-09.25 — Atomic or Ordered Protected Activation The activation mechanism establishes that the proposed configuration becomes effective only after the required protected authorization conditions have succeeded. In one implementation, the system maintains an authoritative active- configuration pointer and a protected configuration-generation value. The staged configuration is prepared without changing the active pointer. The Finality Sink performs the required verification against the current protected state. The activation manager conditionally updates the authoritative configuration reference from the validated pre-mutation state to the validated post-mutation state. An illustrative transition is: CAS(ActiveState, (Hpre, Epre), (Hpost, Epost)) where: CAS denotes an atomic compare-and-update operation or an equivalent protected conditional transition; ActiveState denotes the authoritative effective configuration and epoch record; Hpre denotes the required current configuration digest; Epre denotes the required current configuration epoch; Hpost denotes the authorized post-mutation configuration digest; Epost denotes the resulting authorized configuration epoch. The transition succeeds only if the actual current state corresponds to the expected pre-mutation state. The implementation performs the required capability-consumption, evidence, and active-configuration operations under a protected ordering protocol. Das Expires 19 April 2027 [Page 379] Internet-Draft Protected AI Execution Finality October 2026 Where the protected mechanism cannot coordinate every operation through one atomic storage transaction, the new configuration remains unavailable for governed use until the required committed activation dependency is established. 11.9.26. WF-09.26 — Runtime Policy Publication and Reader Consistency In a concurrent agent system, several runtime components may read policy information while a mutation is being activated. The implementation prevents an unauthorized mixture of old and new policy fields from being treated as a valid configuration. In one embodiment, the activation manager publishes a complete, immutable policy snapshot under a new protected generation identifier. Readers obtain the relevant policy snapshot through an atomic pointer or protected configuration-handle transition. An active request may be bound to the policy generation under which it was admitted, subject to required current revocation and finality conditions. Where the mutation invalidates outstanding authority, the affected execution interfaces enforce the resulting policy-state transition before admitting subsequent governed operations. A runtime does not acquire authority to perform an otherwise prohibited operation merely because different configuration fields were read at different times during activation. 11.9.27. WF-09.27 — Mutation Activation and Actual Runtime Verification After the protected activation transition succeeds, AM-914 applies the authorized configuration through the governed activation interface. For a tool-policy mutation, the active tool gateway uses the new verified permission configuration. For a retrieval-policy mutation, the retrieval broker uses the authorized source or data-access scope. For a memory-policy mutation, the memory manager applies the verified memory-access or persistence rules. Das Expires 19 April 2027 [Page 380] Internet-Draft Protected AI Execution Finality October 2026 For a workflow-graph mutation, the orchestrator activates the approved workflow graph. For a model-configuration mutation, the model runtime loads or selects the authorized configuration. For an adapter mutation, the model loader activates the approved adapter artifact under the required configuration and measurement conditions. The activation manager verifies that the runtime state actually made effective corresponds to the authorized post-mutation state. If the required verification fails, the transition is not recorded as successfully active. Where a partial side effect has occurred, the system follows the protected failure or recovery procedure rather than assuming that the attempted activation produced no consequence. 11.9.28. WF-09.28 — Runtime Revocation and Epoch Advancement A protected policy mutation may change the authorization context applicable to future operations. The system determines whether the activated mutation requires advancement of a policy epoch, execution epoch, revocation generation, or another protected authorization-state identifier. Where the resulting policy invalidates outstanding capabilities, the relevant Finality Sinks reject capabilities that no longer satisfy the required current state. A capability issued under an earlier policy remains valid only to the extent permitted by the current mandatory authorization conditions. For a strict revocation guarantee, the affected effectuation boundaries require a current protected state check, authenticated revocation fence, or equivalent enforcement mechanism that prevents acceptance of incompatible stale capabilities. A delayed cache update is not treated as adequate for immediate revocation unless the implementation provides the required protected synchronization or withholding behavior. Das Expires 19 April 2027 [Page 381] Internet-Draft Protected AI Execution Finality October 2026 11.9.29. WF-09.29 — Policy Mutation and Outstanding Candidate Acts A policy change may occur while previously generated Candidate Acts remain pending. The system distinguishes: (a) Candidate Acts generated under the earlier policy but not yet authorized; (b) Candidate Acts having completed protected validation but not yet become effective; (c) Candidate Acts having obtained scoped capabilities but not yet crossed their Finality Sinks; and (d) Candidate Acts already confirmed effective. Pending or unverified acts are re-evaluated to the extent required by the new protected policy and revocation state. Where the resulting policy invalidates an earlier capability, the applicable Finality Sink refuses effectuation under that capability. An effect already completed is not retroactively undone by a subsequent policy mutation. If the system requires cancellation or compensation of earlier effects, such an operation is represented and authorized according to its own consequential effectuation requirements. 11.9.30. WF-09.30 — Distributed Policy Mutation In a distributed agent system, the affected configuration may be consumed by multiple runtimes, tool gateways, model servers, or execution nodes. An embodiment may use authenticated policy-generation records and protected activation commitments. The policy mutation is prepared for the designated deployment scope. Each affected component obtains or verifies the authorized post- mutation configuration and applicable protected policy generation. Where synchronized activation is mandatory, the system employs a suitable protected coordination or commit protocol. Das Expires 19 April 2027 [Page 382] Internet-Draft Protected AI Execution Finality October 2026 Where immediate global synchronization is not required, a component that cannot establish the required current authorization state withholds affected operations until its policy view satisfies the applicable freshness and version conditions. A distributed policy update does not automatically provide globally atomic behavior merely because it uses signed configuration files or authenticated messages. The implementation specifies the policy visibility and revocation guarantees that its protected protocol actually enforces. 11.9.31. WF-09.31 — Self-Modification Versus Downstream Effectuation Successful authorization of a self-modification does not independently authorize every consequential operation that may later be generated by the modified agent. For example, activating a tool policy that permits use of a specified API class does not automatically authorize an arbitrary network transmission or credential-mediated operation. A subsequent governed Candidate Act remains subject to its applicable Authority Object, protected validation, scoped capability and Finality Sink verification. Likewise, authorization to load a model adapter does not itself authorize unrestricted release of model outputs or external tool invocations. The mutation-activation boundary and downstream execution-finality boundaries may therefore comprise distinct protected enforcement events. 11.9.32. WF-09.32 — Concrete Tool-Policy Mutation Example In one illustrative implementation, an AI coding agent executes in a sandbox with read-only access to a source-code repository. The agent determines that completion of an authorized task would benefit from creating a repository issue through an external service. The current effective tool policy permits repository reading but does not permit the required write-capable connector operation. The agent proposes changing its tool policy to permit issue creation through a designated connector. Das Expires 19 April 2027 [Page 383] Internet-Draft Protected AI Execution Finality October 2026 The mutation interception component receives the proposed change and places it in a Non-Effective State. The proposed policy is staged separately from the active tool-policy store. DC-904 constructs a Candidate Self-Mutation Act Descriptor identifying the agent, affected tool gateway, current policy digest, proposed policy digest, proposed new permission, approved mutation class, policy epoch, and mutation-activation Finality Sink. ES-908 performs the applicable tests and checks whether the change preserves required existing safety restrictions. Where developer approval is mandatory, UA-909 obtains an authenticated approval bound to the exact pre- and post-mutation policy digests. PED-907 verifies the Self-Mutation Authority Object and applicable evaluation, approval, scope, policy, revocation, and freshness predicates. The PED confirms that the proposed permission expansion is limited to the approved connector and operation class. The required protected state and validation evidence are committed. CR-912 releases a Self-Modification Capability bound to the proposed tool-policy transition. FS-913 reconstructs the actual current and proposed policy measurements immediately before activation. If the current policy, proposed policy, scope, approval, and required protected state correspond to the capability, the protected activation manager performs the authorized conditional transition. The tool gateway begins using the new policy generation only after the required protected activation conditions succeed. If the agent modifies the staged policy to add credential export, broad shell access, or another unapproved permission, the post- mutation digest or scope verification fails. The mutation is refused. Das Expires 19 April 2027 [Page 384] Internet-Draft Protected AI Execution Finality October 2026 Even after successful activation of the restricted issue-creation permission, each consequential connector invocation remains subject to its separately applicable protected execution-finality authorization. 11.9.33. WF-09.33 — Adapter and Model-Configuration Mutation Example In another embodiment, an AI agent proposes loading or replacing a model adapter. The proposed adapter is stored in a staging area and assigned an authenticated artifact digest. The Candidate Self-Mutation Act identifies: (a) the requesting agent; (b) the affected model runtime; (c) the current model or adapter configuration; (d) the proposed adapter artifact; (e) the permitted mutation class; (f) the required evaluation evidence; (g) the applicable ALF and safety conditions; (h) the current policy epoch; and (i) the model-activation Finality Sink. The PED validates the relevant Authority Object and required model- integrity or configuration conditions. The required protected evidence is committed and the scoped capability becomes available. The model loader verifies the capability against the actual staged artifact and current runtime configuration before activation. Where required, the model runtime retains the existing effective adapter until the authorized new configuration has been successfully verified and activated. Das Expires 19 April 2027 [Page 385] Internet-Draft Protected AI Execution Finality October 2026 A differently measured adapter cannot be substituted under the earlier capability merely because its filename or human-readable description is unchanged. Where the adapter modifies future outputs or tool behavior, subsequent externally effective operations remain subject to their own applicable finality controls. 11.9.34. WF-09.34 — Rollback, Recovery, and Failure Handling The system operates fail-closed for mandatory mutation-authorization conditions. If a required predicate fails before capability issuance, no valid Self-Modification Capability is released. If protected evidence commitment fails, activation authority is withheld. If the effective configuration changes after validation but before activation, the pre-mutation state verification fails unless the transition is expressly permitted. If a component crashes before activation, the proposed configuration remains staged or is recovered according to the protected mutation- state record. If a component crashes during activation, the protected recovery procedure determines whether the resulting configuration was committed, rejected, partially applied, or remains indeterminate. A rollback operation that changes the effective configuration may itself constitute a governed configuration mutation. Recovery may restore a previously approved configuration only after satisfying the required protected recovery authority and state conditions. Restoring an old configuration snapshot does not independently restore expired, consumed, revoked, or superseded execution authority. 11.9.35. WF-09.35 — Protected Mutation Outcome State OS-916 maintains a protected mutation outcome record. The record may comprise: Das Expires 19 April 2027 [Page 386] Internet-Draft Protected AI Execution Finality October 2026 mutation_id; pre_configuration_digest; post_configuration_digest; approval_reference; evaluation_reference; capability_id; protected_state_version; activation_attempt_count; actual_activation_generation; outcome_status; recovery_reference. Possible outcomes include: ACTIVATED; DENIED; CANCELLED; REVOKED; ROLLED_BACK; INDETERMINATE. The outcome record distinguishes authorization to activate from actual successful activation. Where the activated configuration is used by multiple components, the implementation also records or verifies the activation status necessary for the selected distributed consistency guarantee. A mutation is not declared globally active merely because one component received an activation request. Das Expires 19 April 2027 [Page 387] Internet-Draft Protected AI Execution Finality October 2026 11.9.36. WF-09.36 — PHOSITA Verification and Negative Tests A person having ordinary skill in AI-agent runtimes, software configuration management, operating-system security, policy enforcement, distributed systems, model serving, or protected authorization may verify the embodiment through controlled tests. Test 1 — Authorized policy change: Submit a mutation matching a permitted class, valid evaluation evidence, protected approval and current state. Verify capability-dependent activation. Test 2 — Unauthorized tool expansion: Propose unrestricted network access where only a bounded connector permission is authorized. Verify rejection. Test 3 — Pre-mutation mismatch: Change the effective policy after validation but before activation. Verify failure of the required pre-state comparison. Test 4 — Post-mutation substitution: Replace the staged configuration after authorization. Verify failure of the authorized post-state digest comparison. Test 5 — Incorrect approval: Present an approval artifact covering a different mutation. Verify refusal. Test 6 — Missing developer approval: Attempt a mutation requiring approval without the corresponding valid artifact. Verify withholding. Test 7 — Regression failure: Supply evaluation evidence showing failure of a required test. Verify denial. Test 8 — Evaluation-artifact mismatch: Present valid test results for a different configuration. Verify rejection. Test 9 — Prohibited mutation class: Attempt to disable a required enforcement mechanism. Verify refusal under the applicable protected policy. Test 10 — Capability replay: Reuse a consumed single-use Self- Modification Capability. Verify that its protected usage condition fails. Test 11 — Policy-epoch change: Advance a required policy epoch before activation. Verify denial or protected revalidation of the stale mutation. Das Expires 19 April 2027 [Page 388] Internet-Draft Protected AI Execution Finality October 2026 Test 12 — Revocation: Revoke a mandatory approval or authority condition before activation. Verify refusal. Test 13 — Concurrent mutation: Submit two incompatible transitions based on the same pre-state. Verify that the protected activation protocol prevents both from independently succeeding. Test 14 — Hot-swap consistency: Activate a policy while concurrent runtime requests execute. Verify that each affected request uses a configuration state satisfying the required protected consistency rule. Test 15 — Partial activation failure: Interrupt the activation process. Verify that an incomplete transition does not automatically create authorized effectuation under an inconsistent state. Test 16 — Configuration rollback: Restore an earlier policy snapshot and attempt use of superseded capabilities. Verify rejection where the current protected authorization state invalidates them. Test 17 — Alternative activation path: Attempt to modify the effective policy through a direct file write, administrative API, or unmediated loader. Verify that the governed activation path cannot be bypassed. Test 18 — Model adapter substitution: Replace the adapter artifact after evaluation. Verify that the actual artifact measurement no longer matches the capability. Test 19 — Distributed stale policy: Delay an authorized policy update at one runtime node. Verify that the node refuses affected operations where current-state verification is required. Test 20 — Downstream operation after mutation: Activate a permitted tool-policy change and attempt a separately governed external action. Verify that the action still requires its own scoped execution authorization. Test 21 — Unauthorized safety-baseline weakening: Propose a modification that removes a mandatory safety control. Verify failure of the protected baseline predicate. Test 22 — Agent-controlled approval forgery: Present an approval generated solely by the untrusted agent without the required authority authentication. Verify rejection. Test 23 — Expired mutation capability: Present a capability after the required expiry condition. Verify refusal. Das Expires 19 April 2027 [Page 389] Internet-Draft Protected AI Execution Finality October 2026 Test 24 — Incorrect Finality Sink: Present a capability at another activation interface outside its permitted scope. Verify refusal. Test 25 — Protected recovery: Simulate a crash following authorization but before confirmed activation. Verify that the protected mutation-state record governs the subsequent recovery decision. These tests may be performed using isolated policy managers, synthetic configuration manifests, agent tool gateways, test model loaders, authenticated developer approval services, protected state stores, and controlled fault-injection systems. 11.9.37. WF-09.37 — Alternative Technical Implementations Single-node implementation: The PED, policy store, capability mechanism, and mutation-activation Finality Sink operate within one protected controller or host. Separated implementation: A protected authority component validates the mutation, while a separate policy manager or model runtime independently verifies the capability before activation. Container implementation: An isolated agent prepares configuration changes, while an enforcement-controlled host policy service retains exclusive authority over the effective runtime configuration. Hypervisor implementation: A virtual machine proposes a mutation that is activated only through a protected hypervisor or host-service interface. Confidential-computing implementation: The protected authority or activation manager operates within an attested confidential workload, subject to the required attestation and protected-state predicates. Hardware-rooted implementation: A secure enclave, HSM, trusted processor, or protected firmware controller controls relevant cryptographic keys, activation commitments, or configuration- enablement conditions. Distributed cloud implementation: A protected governance service issues mutation capabilities to multiple workload policy managers that verify the applicable protected state and activation scope. Model-runtime implementation: A model server or adapter loader verifies the mutation capability before activating a modified model configuration. Das Expires 19 April 2027 [Page 390] Internet-Draft Protected AI Execution Finality October 2026 Agent-orchestration implementation: An orchestrator verifies the capability before activating a changed workflow graph, planning policy, or delegation configuration. Policy-gateway implementation: A protected tool or API gateway verifies the capability before publishing or applying modified permission rules. The implementations may employ different operating systems, storage mechanisms, cryptographic primitives, and isolation substrates, provided that the required protected mutation-finality dependency is maintained. 11.9.38. WF-09.38 — Technical Effect The embodiment establishes a protected causal dependency between: (a) generation of a proposed self-modification; (b) mandatory mutation interception; (c) Non-Effective State staging; (d) identification of pre- and post-mutation configurations; (e) canonical Candidate Self-Mutation Act Descriptor construction; (f) protected Self-Mutation Authority Object validation; (g) permitted mutation-class and safety-baseline verification; (h) applicable AIF, ALF, RBD, and evaluation verification; (i) developer or operator approval where required; (j) protected authorization-state handling; (k) required validation-evidence commitment; (l) scoped Self-Modification Capability availability; (m) independent verification at the mutation-activation Finality Sink; (n) atomic or ordered protected activation; and (o) current policy, revocation, and downstream effectuation enforcement. Das Expires 19 April 2027 [Page 391] Internet-Draft Protected AI Execution Finality October 2026 The resulting architecture prevents an autonomous agent from treating its ability to generate, recommend, test, package, or stage a modification as authority to activate that modification. The architecture also prevents a protected approval for one configuration transition from being reused to activate a materially different configuration. A mutation to the agent's execution environment does not independently confer authorization to perform future consequential operations outside their separately governed execution-finality boundaries. The protected relationship may be implemented through software, hardware, firmware, cryptographic, virtualized, or distributed protected enforcement mechanisms according to the specified security guarantees. Computation is not authority to act. The authority to propose a new policy is not authority to activate it. Developer approval is an authorization predicate, not a substitute for protected capability verification at the mutation-activation Finality Sink. 11.10. WF-10 — Protected Multi-Agent Delegation, Parent–Child Authority Derivation, Recursive Delegation Limits, and Sub-Agent Acceptance Finality 11.10.1. WF-10.1 — Technical Purpose This embodiment provides a computer-implemented protected execution- finality system for controlling delegation of tasks, context, tools, resources, and execution authority among artificial-intelligence agents, autonomous workflows, specialist agents, coding agents, retrieval agents, scheduling agents, tool agents, security agents, and other local or remote automated execution components. The embodiment prevents a primary artificial-intelligence agent from independently conferring executable authority upon another agent merely by creating a subordinate process, transmitting an instruction, generating a task object, assigning an objective, invoking a remote-agent interface, or supplying a credential or tool reference. Das Expires 19 April 2027 [Page 392] Internet-Draft Protected AI Execution Finality October 2026 A proposed delegation is classified as a Candidate Delegation Act maintained in a Non-Effective State. A Protected Enforcement Domain (PED) validates the proposed delegation against the applicable Parent Mandate Object, Delegation Authority Object, parent authorization state, intended child-agent identity, permitted objective, tool scope, data scope, memory scope, execution budget, time window, recursion constraints, revocation state, and other required authorization predicates. Following successful protected validation, required protected-state handling, and validation-evidence commitment, the PED releases or makes available a scoped, non-bearer Delegation Capability. A delegation-acceptance Finality Sink independently verifies the capability before admitting the subordinate agent into an executable delegated-authority state. The delegated authority is bounded by the validated parent authority and does not independently authorize unrelated or broader consequential operations. Subsequent governed downstream operations remain subject to their corresponding protected execution-finality requirements. 11.10.2. WF-10.2 — Participating Technical Components In one non-limiting implementation, the system comprises: PA-1001 — Parent Agent Execution Environment An artificial-intelligence agent, supervisor agent, orchestrator, application, workflow, or computational component configured to propose delegation. DI-1002 — Delegation Interception Component An enforcement-controlled mechanism configured to intercept proposed delegations before the relevant authority or execution handoff becomes effective. HQ-1003 — Non-Effective Delegation Holding Mechanism A controlled queue or staged delegation record maintaining the proposed handoff pending validation. PM-1004 — Parent Mandate Store Das Expires 19 April 2027 [Page 393] Internet-Draft Protected AI Execution Finality October 2026 An authenticated source of the original user, organization, workflow, or other applicable parent authority. DC-1005 — Delegation Descriptor Construction Component A mechanism configured to construct a canonical Candidate Delegation Act Descriptor. AR-1006 — Agent Identity and Capability Registry A protected or authenticated source identifying approved subordinate agents and their relevant execution, security, tool, data, memory, and communication properties. CE-1007 — Context Handoff Escrow A protected mechanism configured to hold, classify, minimize, redact, or otherwise control information proposed for transfer to the subordinate agent. AT-1008 — Authority Attenuation Component A protected mechanism configured to derive a bounded delegated- authority scope from the applicable parent authority and proposed delegation. BM-1009 — Protected Budget and Recursion-State Manager A protected component configured to manage delegation depth, resource limits, cumulative usage, reservations, and applicable child- authority allocations. PED-1010 — Protected Delegation Enforcement Domain A protected authority component configured to validate the proposed delegation and control the required protected finality transaction. PS-1011 — Protected Delegation-State Store A mechanism maintaining relevant policy, revocation, nonce, grant, capability-consumption, and delegation-lineage information. EV-1012 — Delegation Validation-Evidence Component A mechanism configured to generate or commit a Delegation LAVR, authenticated validation record, or equivalent protected evidence. CR-1013 — Delegation Capability Release Component Das Expires 19 April 2027 [Page 394] Internet-Draft Protected AI Execution Finality October 2026 A protected mechanism configured to generate, register, or make available the scoped Delegation Capability. FS-1014 — Delegation-Acceptance Finality Sink A protected or enforcement-controlled boundary through which a subordinate agent receives executable delegated authority. SA-1015 — Subordinate Agent Execution Environment A local or remote agent runtime configured to accept and execute a validated delegated task within its authorized scope. RA-1016 — Return Artifact Admission Gate An optional protected mechanism configured to validate a subordinate agent's returned information or artifacts before they become effective within the parent workflow. OS-1017 — Protected Delegation Outcome-State Component A mechanism maintaining delegation acceptance, active execution, completion, revocation, denial, and recovery information. DS-1018 — Downstream Execution-Finality Subsystem A protected subsystem configured to govern consequential operations subsequently proposed by the subordinate agent. The components may be implemented within one node or distributed across authenticated computing environments. 11.10.3. WF-10.3 — Establishment of the Parent Authority Boundary Before delegation is permitted, PM-1004 maintains or obtains the Parent Mandate Object corresponding to PA-1001. The Parent Mandate Object establishes the upper authorization bound under which the parent agent operates. A representative record may contain: parent_mandate_id; authorized_principal; parent_agent_identity; Das Expires 19 April 2027 [Page 395] Internet-Draft Protected AI Execution Finality October 2026 authorized_objective; permitted_purpose_classes; permitted_tool_classes; permitted_data_sources; permitted_memory_scope; permitted_output_classes; permitted_recipients; resource_budget; spending_budget; execution_time_limit; delegation_permission; maximum_delegation_depth; permitted_subagent_classes; jurisdiction_scope; approval_requirements; policy_epoch; revocation_epoch; nonce; expiry; authority_authentication. The Parent Mandate Object is authenticated according to the applicable authority rules. The parent agent cannot expand this authority by generating a new task instruction or changing its own interpretation of the mandate. Das Expires 19 April 2027 [Page 396] Internet-Draft Protected AI Execution Finality October 2026 11.10.4. WF-10.4 — Delegation as a Separately Governed Consequential Act The system distinguishes preparation of a delegated task from transfer of executable delegated authority. A parent agent may calculate a subtask, prepare a prompt, identify a suitable specialist, or construct a workflow branch without yet granting the subordinate agent effective authority. The following operations may constitute governed delegation boundaries: (a) creation of an executable child-agent task; (b) remote-agent invocation; (c) activation of a subordinate workflow; (d) release of a tool lease; (e) transfer of an executable memory handle; (f) release of protected task context; (g) assignment of a bounded execution budget; (h) controlled credential delegation; (i) authorization of recursive delegation; or (j) another handoff by which a subordinate component obtains authority to act. The precise boundary is identified by the applicable execution environment. A proposed delegation remains non-effective until the required capability verification succeeds at that boundary. 11.10.5. WF-10.5 — Candidate Delegation Act Generation PA-1001 generates a proposed delegation to SA-1015. The proposed delegation may identify: (a) the intended subordinate agent; Das Expires 19 April 2027 [Page 397] Internet-Draft Protected AI Execution Finality October 2026 (b) the delegated objective; (c) a subtask description; (d) proposed tools; (e) data to be shared; (f) memory references; (g) required execution resources; (h) proposed budget; (i) permitted output; (j) requested delegation depth; (k) time constraints; and (l) relevant authority references. The proposed operation is classified as Candidate Delegation Act CDA- 1019. The parent agent's creation of CDA-1019 does not establish authority for SA-1015 to execute the proposed task. 11.10.6. WF-10.6 — Interception and Non-Effective Delegation Staging DI-1002 intercepts CDA-1019 before the corresponding executable handoff. The proposed task and associated transfer references are retained in HQ-1003. An illustrative pending delegation record comprises: delegation_id; parent_agent_id; proposed_child_agent_id; subtask_reference; context_payload_reference; Das Expires 19 April 2027 [Page 398] Internet-Draft Protected AI Execution Finality October 2026 requested_tool_scope; requested_data_scope; requested_memory_scope; requested_budget; requested_recursion_depth; parent_mandate_reference; policy_epoch; status = NON_EFFECTIVE. The subordinate agent does not receive executable authority merely because this record exists. Where the implementation governs context delivery as part of delegation, the proposed context also remains held until the corresponding release conditions succeed. 11.10.7. WF-10.7 — Canonical Candidate Delegation Act Descriptor DC-1005 constructs a machine-verifiable descriptor identifying the proposed delegation and its effectuation-relevant attributes. A representative descriptor comprises: delegation_id; parent_agent_identity; child_agent_identity; parent_mandate_digest; delegated_objective; subtask_digest; requested_tool_scope; requested_data_scope; requested_memory_scope; Das Expires 19 April 2027 [Page 399] Internet-Draft Protected AI Execution Finality October 2026 context_payload_commitment; requested_budget; requested_time_window; recursion_depth; permitted_output_class; return_artifact_route; policy_epoch; revocation_epoch; nonce; expiry; delegation_finality_sink_id. The descriptor distinguishes authority to assign a bounded subtask from authority to transfer unrestricted parent context or resources. Where cryptographic binding is required, the descriptor is encoded using a deterministic canonicalization procedure. 11.10.8. WF-10.8 — Mathematical Descriptor Construction An illustrative canonical delegation descriptor is: Ddel = Canon_v(P, C, O, T, D, M, B, R, E, F) where: Ddel denotes the canonical delegation descriptor; Canon_v denotes deterministic canonical encoding under version v; P denotes the authenticated parent-agent identity; C denotes the intended child-agent identity; O denotes the delegated objective; T denotes the proposed tool and execution scope; Das Expires 19 April 2027 [Page 400] Internet-Draft Protected AI Execution Finality October 2026 D denotes the permitted data and context scope; M denotes the proposed memory-access scope; B denotes the proposed resource and execution budget; R denotes the recursion and further-delegation restrictions; E denotes the applicable authorization-state epoch; F denotes the delegation-acceptance Finality Sink. The descriptor may be committed as: hdel = H("DAS-DELEGATION-v1" || Encode(Ddel)) where: hdel denotes the descriptor digest; H denotes a cryptographic hash function; Encode denotes the selected deterministic encoding; || denotes concatenation; "DAS-DELEGATION-v1" denotes an illustrative domain-separation label. The particular encoding and cryptographic algorithms are implementation choices. 11.10.9. WF-10.9 — Subordinate Agent Identity Verification AR-1006 supplies authenticated information about the proposed subordinate agent. A representative registry entry includes: agent_id; agent_owner; agent_service_identity; model_or_runtime_class; permitted_tool_classes; Das Expires 19 April 2027 [Page 401] Internet-Draft Protected AI Execution Finality October 2026 permitted_data_classes; memory_policy; data_retention_policy; network_communication_policy; jurisdiction_scope; approved_ALF_reference; attestation_reference; security_class; revocation_state; registry_authentication. PED-1010 verifies the registry information required by the applicable Delegation Authority Object. A remote agent cannot acquire higher authority merely by describing itself as trusted, secure, specialized, or enterprise-approved. Where a particular runtime attestation is mandatory, the protected system verifies the corresponding measurement and freshness conditions. Registry admission and runtime attestation do not independently confer authority for the proposed delegated task. 11.10.10. WF-10.10 — Delegation Authority Object PED-1010 obtains or constructs the applicable Delegation Authority Object under protected authority rules. The object identifies the permitted delegation and its restrictions. An illustrative object contains: parent_agent_id; child_agent_id; delegated_objective; Das Expires 19 April 2027 [Page 402] Internet-Draft Protected AI Execution Finality October 2026 permitted_subtask_class; permitted_tool_set; permitted_data_scope; permitted_memory_scope; permitted_execution_budget; permitted_time_window; permitted_recursion_depth; prohibited_operation_classes; permitted_external_communication; output_artifact_scope; return_route; authorized_purpose; AIF_reference; ALF_reference; policy_epoch; revocation_epoch; nonce; expiry; LAVR_requirement; protected_authentication. The delegated authority must satisfy the restrictions imposed by the Parent Mandate Object and other applicable protected authority conditions. Where mandatory, the protected system rejects any proposed child authority exceeding the parent's authorized scope. Das Expires 19 April 2027 [Page 403] Internet-Draft Protected AI Execution Finality October 2026 11.10.11. WF-10.11 — Authority Attenuation Principle The authority made available to a subordinate agent is derived from the valid parent authority and is restricted to the permitted delegated objective. Let: Aparent denote the complete set of authority-relevant operations available to the parent; Arequest denote the authority requested for the proposed delegation; Achild denote the authority permitted for the child. An illustrative attenuation rule is: Achild = Aparent ∩ Arequest ∩ Apolicy where: ∩ denotes set intersection; Apolicy denotes the operations permitted by the applicable protected delegation policy. Consequently: Achild ⊆ Aparent where: ⊆ denotes subset inclusion. This means the child cannot receive a governed operation permission outside the parent's applicable authority through this delegation. The expression is interpreted over the complete authorization context, including purposes, recipients, tools, data, resources, validity, and other mandatory conditions. A simple comparison of tool names alone does not establish complete authority attenuation. 11.10.12. WF-10.12 — Multi-Dimensional Delegated Scope Delegated authority may be represented as a structured vector: Das Expires 19 April 2027 [Page 404] Internet-Draft Protected AI Execution Finality October 2026 A = (P, T, D, M, B, W, R, O) where: P denotes permitted purposes; T denotes permitted tools and operation classes; D denotes permitted data sources and data categories; M denotes permitted memory access; B denotes budget or resource allowances; W denotes the permitted time window; R denotes recursion or further-delegation rights; O denotes permitted output and recipient classes. The child authorization is attenuated component by component. For set-valued dimensions, the protected system applies the corresponding subset restriction. For numerical budgets, the child allocation cannot exceed the parent's remaining permitted allocation. For time windows, the child's permitted interval must remain within the applicable parent interval. For recursion rights, the child cannot receive greater remaining delegation depth than the parent is allowed to transfer. A delegated-authority comparison must use the rules appropriate to each dimension rather than treating all properties as ordinary integers. 11.10.13. WF-10.13 — Protected Context Handoff Escrow CE-1007 receives the context proposed for transmission to the child agent. The proposed context may comprise: (a) task instructions; (b) conversation extracts; Das Expires 19 April 2027 [Page 405] Internet-Draft Protected AI Execution Finality October 2026 (c) retrieved documents; (d) tool outputs; (e) temporary files; (f) memory items; (g) source-code fragments; (h) database records; (i) user information; (j) enterprise records; (k) credential references; or (l) other task-related information. The escrow evaluates the context against the delegated purpose and permitted data scope. Where required, it removes unrelated information, applies redaction, restricts source references, replaces direct resource access with bounded handles, and withholds prohibited secrets or memory. The context received by the child is limited to the authorized handoff. A broad parent context window does not automatically constitute an authorized child context. 11.10.14. WF-10.14 — Context Minimization and Integrity Binding The protected handoff may include a context commitment. An illustrative record comprises: context_escrow_id; delegation_id; permitted_context_item_references; content_digests; source_provenance_references; Das Expires 19 April 2027 [Page 406] Internet-Draft Protected AI Execution Finality October 2026 sensitivity_labels; redaction_transform_digest; permitted_use_scope; policy_epoch; nonce; protected_authentication. The resulting commitment binds the context actually released to the authorized delegation. If the parent modifies the context payload after validation, the required context correspondence fails. Where the child's delegated authority depends on the contents or data categories of the handoff, the receiving component verifies those conditions before accepting the context. A hash of a document does not independently establish that its content is safe or authorized. Source classification and permitted- use validation remain separate required operations. 11.10.15. WF-10.15 — Tool-Scope Attenuation AT-1008 determines which tools may be used by the child agent. Let: Tparent denote the parent's authorized tool set; Trequested denote the tools requested for the child; Tallowed denote tools permitted by the applicable delegation policy. The child tool set is: Tchild = Tparent ∩ Trequested ∩ Tallowed The child receives only the resulting bounded tool scope. For example, a parent agent authorized to perform read-only repository analysis cannot obtain new repository write authority merely by delegating to a coding agent that ordinarily possesses write-capable tools. Das Expires 19 April 2027 [Page 407] Internet-Draft Protected AI Execution Finality October 2026 If the child runtime has broader native tool privileges, the delegated session is launched or mediated with the required restricted tool lease. The actual tool interfaces must enforce the restriction. A tool- scope label alone does not prevent access to an unrestricted alternative tool path. 11.10.16. WF-10.16 — Credential and Memory Authority Attenuation The child may receive restricted credential references or memory handles only where the applicable parent authority and Delegation Authority Object permit them. A delegated credential reference does not independently release the underlying reusable credential. A memory handle may be bound to a specified data subset, purpose, validity period, child identity, and protected access mechanism. Where a parent lacks authority to access a memory resource or protected credential, it cannot acquire such authority merely by asking a more privileged child agent to retrieve or use that resource. The privileged resource interface performs its own required protected authorization verification. Any consequential credential-mediated operation remains subject to the corresponding Finality Sink. 11.10.17. WF-10.17 — Protected Budget Allocation BM-1009 maintains the protected resource allowances applicable to the parent and child delegation. The budget may include: (a) computational expenditure; (b) model-token usage; (c) tool-call count; (d) network-request count; (e) financial spending; Das Expires 19 April 2027 [Page 408] Internet-Draft Protected AI Execution Finality October 2026 (f) cloud-resource consumption; (g) storage quota; (h) execution time; (i) delegated-agent count; and (j) recursion allowance. Where multiple dimensions apply, the budget is represented as a vector having units and interpretation rules for each dimension. A child does not receive an unrestricted copy of the parent's total remaining budget merely because it was spawned by the parent. 11.10.18. WF-10.18 — Atomic Child Budget Reservation For a budget dimension requiring strict allocation, the protected state manager reserves the child's allocation against the parent's remaining unallocated allowance. Let: Btotal denote the parent's permitted budget for the relevant dimension; Bused denote already consumed budget; Breserved denote budget allocated to pending or active child operations; Brequest denote the amount requested for the new child. The delegation may reserve the requested budget only if: Brequest ≤ Btotal − Bused − Breserved All values are interpreted in the same resource units. Where the rule succeeds, BM-1009 performs a protected conditional state transition. The reservation is associated with the child delegation identifier and protected authorization-state version. Das Expires 19 April 2027 [Page 409] Internet-Draft Protected AI Execution Finality October 2026 If two sibling delegations compete for the same remaining budget, their protected reservations are synchronized to prevent both from independently consuming the same availability. This prevents an agent from increasing its effective resource allowance merely by spawning several child agents. 11.10.19. WF-10.19 — Cumulative Budget Containment For multiple active children, a strict cumulative allocation invariant may be expressed as: Bused + Σ Bchild_reserved ≤ Btotal where: Σ denotes summation across the active child reservations; Bchild_reserved denotes the corresponding protected reservation for each child. The invariant applies independently to each protected budget dimension for which strict cumulative containment is required. Where a resource provider maintains a different accounting mechanism, the protected implementation reconciles that mechanism with the authorization guarantee actually claimed. An eventually consistent budget display alone is not sufficient to establish a strict simultaneous spending ceiling. If the required protected budget state is unavailable or inconsistent, further affected delegation authority is withheld. 11.10.20. WF-10.20 — Recursive Delegation Constraint The Delegation Authority Object identifies whether the subordinate agent may delegate further. The authorization may specify: delegation_allowed; maximum_depth; remaining_depth; permitted_descendant_classes; Das Expires 19 April 2027 [Page 410] Internet-Draft Protected AI Execution Finality October 2026 permitted_child_tools; permitted_child_data_scope; permitted_child_budget; no_subdelegation_flag; required_fresh_validation; policy_epoch. Each proposed further delegation is classified as another Candidate Delegation Act. The child cannot create a further executable delegation merely by spawning another process, sending a task message, or calling a remote agent. Where no further delegation is permitted, the corresponding execution interfaces refuse such handoffs. 11.10.21. WF-10.21 — Mathematical Recursion-Depth Control Let: dparent denote the remaining recursion allowance available to the parent for the proposed handoff; dchild denote the remaining recursion allowance assigned to the child. In an illustrative depth-limited embodiment: dchild ≤ dparent − 1 provided dparent is at least 1. Where dparent equals zero, no further delegated child authority may be issued under that recursion allowance. The protected system may additionally limit the total number of child agents, maximum branching factor, execution budget, or cumulative delegation events. A recursion-depth restriction alone does not establish a bound on total agent proliferation if an agent may create unlimited siblings. Das Expires 19 April 2027 [Page 411] Internet-Draft Protected AI Execution Finality October 2026 Accordingly, the protected system enforces each additional mandatory branching, count, or resource constraint specified by the Authority Object. 11.10.22. WF-10.22 — Parent–Child Authority Lineage PS-1011 maintains a protected delegation-lineage record. An illustrative record comprises: delegation_id; parent_delegation_id; root_mandate_id; parent_agent_identity; child_agent_identity; delegation_depth; delegated_scope_digest; budget_reservation_id; context_escrow_commitment; policy_epoch; revocation_epoch; capability_id; status. The record links each child delegation to the corresponding parent authority. Where a descendant proposes a further delegation, PED-1010 validates the new proposal against the relevant current parent authority and protected lineage state. The existence of a prior parent capability does not permit creating an unrelated descendant capability. A protected descendant authority is bounded by all mandatory ancestor restrictions applicable to that delegation chain. Das Expires 19 April 2027 [Page 412] Internet-Draft Protected AI Execution Finality October 2026 11.10.23. WF-10.23 — Purpose Continuity and Prohibited Authority Laundering PED-1010 verifies that the proposed delegation remains within the authorized purpose. Examples of prohibited authority expansion may include: (a) a research agent delegating to a purchasing agent to complete a transaction without purchase authority; (b) a read-only coding agent delegating to a deployment agent without deployment authority; (c) a document summarization agent delegating to a connector that transmits confidential records without export authority; (d) an agent without credential permission delegating to a child having broader credential access; or (e) a child using another agent as an indirect proxy for a prohibited operation. The protected validation evaluates the actual delegated operation and permitted purpose rather than solely the descriptive names assigned to the parent and child. A child agent's independent access to an external service does not enlarge the authority conferred through the governed delegation. 11.10.24. WF-10.24 — ALF, AIF, Provenance, and Runtime Validation Where required by the Authority Object, PED-1010 validates applicable Algorithmic Logic Fingerprint, Algorithmic Intent Fingerprint, Runtime Behavioral Descriptor, provenance, or other protected evidence. The AIF may identify the parent's authorized purpose and the permitted delegated objective. The ALF may identify an approved child runtime, tool graph, execution policy, or workflow configuration. The RBD may identify relevant runtime behavior including unexplained repeated delegation, prohibited tool use, task drift, or attempted scope expansion. Das Expires 19 April 2027 [Page 413] Internet-Draft Protected AI Execution Finality October 2026 Where untrusted content influenced the proposed delegation, the applicable protected provenance and instruction-authority restrictions are evaluated. Such predicates do not independently release a Delegation Capability. They form part of the protected authorization requirements for the particular delegation. 11.10.25. WF-10.25 — Protected Delegation Validation Predicate An illustrative conjunctive delegation-validation condition is: Vdel = Pparent AND Pchild AND Ppurpose AND Ptools AND Pdata AND Pmemory AND Pbudget AND Precursion AND Pstate where: Vdel denotes the protected delegation-validation result; Pparent verifies the applicable parent mandate and authority; Pchild verifies the intended child identity and required eligibility; Ppurpose verifies the permitted delegated objective; Ptools verifies delegated tool scope; Pdata verifies the permitted context and data scope; Pmemory verifies delegated memory permissions; Das Expires 19 April 2027 [Page 414] Internet-Draft Protected AI Execution Finality October 2026 Pbudget verifies the required protected resource allocation; Precursion verifies further-delegation limits; Pstate verifies policy, revocation, nonce, freshness, and other required protected authorization state. Additional predicates may include AIF, ALF, RBD, jurisdiction, approval, retention, output scope, and authenticated runtime conditions. All mandatory predicates must succeed. If a required condition fails, the system does not release executable delegated authority for the rejected proposal. 11.10.26. WF-10.26 — Constrained Delegation Decision A proposed delegation may be partly permissible but overbroad. In one embodiment, PED-1010 may calculate a narrower delegation that remains within the parent authority. The constrained result may: (a) reduce the delegated tool set; (b) restrict data or memory access; (c) limit the execution budget; (d) shorten the permitted time window; (e) remove credential-related permissions; (f) prohibit external communications; (g) disable recursive delegation; (h) limit the output class; (i) require an isolated runtime; or (j) require additional protected approval. The resulting constrained delegation is represented by a new or updated protected descriptor and Delegation Authority Object. Das Expires 19 April 2027 [Page 415] Internet-Draft Protected AI Execution Finality October 2026 The child accepts only the actual approved constrained scope. The system does not silently treat an overbroad original request as authorized merely because some portion of it would have been permissible. 11.10.27. WF-10.27 — Protected Delegation-State Commitment Following successful validation, PED-1010 performs the protected state operation required for the delegation. Such operations may include: (a) reserving a delegation identifier; (b) reserving the permitted child budget; (c) decrementing an applicable delegation-count allowance; (d) updating recursion state; (e) recording the permitted child identity; (f) recording protected context commitments; (g) consuming a nonce; (h) establishing the child-authority version; or (i) registering the authorized delegation capability. The protected mechanism prevents incompatible concurrent delegations from consuming the same restricted authority state. Where the required protected state cannot be committed consistently, the system withholds the corresponding capability. 11.10.28. WF-10.28 — Delegation LAVR Commitment EV-1012 generates or commits a Delegation LAVR or equivalent protected validation record. An illustrative Delegation LAVR contains: receipt_id; parent_mandate_digest; Das Expires 19 April 2027 [Page 416] Internet-Draft Protected AI Execution Finality October 2026 delegation_descriptor_digest; delegation_authority_object_digest; parent_identity; child_identity; child_registry_reference; context_escrow_commitment; delegated_tool_scope_digest; delegated_budget_state_reference; recursion_rule_reference; validation_result; protected_state_transition; policy_epoch; revocation_epoch; nonce; finality_sink_id; protected_authentication. The required evidence is committed before, or atomically with, making the corresponding Delegation Capability available. Where privacy requires it, the receipt may expose only authenticated commitments or bounded compliance results rather than disclosing private task data. An ordinary event log written after the child has already received unrestricted execution authority does not substitute for a required protected pre-delegation commitment. 11.10.29. WF-10.29 — Delegation Capability Generation CR-1013 generates, registers, or makes available a scoped, non-bearer Delegation Capability. Das Expires 19 April 2027 [Page 417] Internet-Draft Protected AI Execution Finality October 2026 An illustrative authenticated capability is: Cdel = Sign_skPED(Encode(hdel, hA, hR, Child, Scope, Budget, Depth, Epoch, Nonce, Expiry, F)) where: Cdel denotes the Delegation Capability; Sign denotes a digital-signature procedure; skPED denotes a private signing key protected under control of the PED; Encode denotes deterministic encoding; hdel denotes the canonical delegation descriptor digest; hA denotes the applicable parent and delegated-authority commitment; hR denotes the protected Delegation LAVR commitment; Child denotes the authorized subordinate-agent identity; Scope denotes the permitted delegated objective, tools, data, memory, and operation classes; Budget denotes the authorized resource allocation or its protected reference; Depth denotes the permitted recursion restrictions; Epoch denotes the applicable policy or delegation-authority epoch; Nonce denotes the applicable freshness value; Expiry denotes the capability validity limit; F denotes the delegation-acceptance Finality Sink. The signature-based representation is illustrative. Equivalent implementations may employ protected capability tables, MAC-authenticated objects, sealed handles, hardware-controlled grants, or other suitable protected mechanisms. Das Expires 19 April 2027 [Page 418] Internet-Draft Protected AI Execution Finality October 2026 11.10.30. WF-10.30 — Delegation Capability Delivery The Delegation Capability may be delivered or made available through: (a) an authenticated local agent-runtime interface; (b) a protected sub-agent spawning service; (c) an A2A task-creation gateway; (d) a remote-agent invocation broker; (e) an authenticated service-mesh interface; (f) a protected workflow scheduler; (g) a task queue having protected admission rules; (h) a context-handoff broker; or (i) another controlled delegation interface. The delivery mechanism binds the capability to the authorized child and task context. The parent agent cannot enlarge the capability by appending additional instructions, tools, context, or budget requests. A capability permitting one child invocation cannot independently authorize an unrelated subsequent child invocation. 11.10.31. WF-10.31 — Independent Delegation-Acceptance Verification FS-1014 verifies the Delegation Capability before making the delegated authority effective. Verification may include: (a) capability authenticity; (b) parent-authority reference; (c) child identity; (d) delegated objective; (e) actual task descriptor; Das Expires 19 April 2027 [Page 419] Internet-Draft Protected AI Execution Finality October 2026 (f) permitted context commitment; (g) tool scope; (h) data and memory scope; (i) budget allocation; (j) recursion restrictions; (k) policy and revocation state; (l) nonce, expiry, and usage state; (m) Delegation LAVR reference; and (n) designated Finality Sink identity. The receiving runtime does not treat a parent-generated task message as sufficient authority. Where a required field differs from the authorized delegation, the handoff is refused or revalidated. 11.10.32. WF-10.32 — Delegation Acceptance Predicate An illustrative delegation-acceptance condition is: PermitDelegate = Auth(Cdel) AND ChildMatch(Cdel,Cactual) AND TaskMatch(Cdel,Dactual) AND ScopeValid(Cdel) AND BudgetValid(Cdel,Bcurrent) AND StateValid(Cdel,Scurrent) AND SinkValid(Cdel,F) where: PermitDelegate denotes authorization to make the delegation effective; Das Expires 19 April 2027 [Page 420] Internet-Draft Protected AI Execution Finality October 2026 Auth verifies capability authenticity; ChildMatch verifies the actual receiving agent identity; TaskMatch verifies the actual delegated task against the authorized descriptor; ScopeValid verifies permitted tools, data, memory, purpose, and recursion scope; BudgetValid verifies required protected budget and reservation state; StateValid verifies mandatory policy, revocation, nonce, freshness, and consumption conditions; SinkValid verifies the designated delegation boundary; Cactual denotes the actual receiving child-agent identity; Dactual denotes the actual delegation descriptor presented at acceptance; Bcurrent denotes the protected budget state; Scurrent denotes the required current authorization state; F denotes the delegation-acceptance Finality Sink. The proposed delegation becomes effective only if PermitDelegate is true. 11.10.33. WF-10.33 — Controlled Child-Agent Activation After successful acceptance verification, the protected runtime may: (a) create the authorized child-agent task; (b) enable the designated subordinate process; (c) release the permitted context subset; (d) activate the restricted tool lease; (e) make available permitted memory handles; (f) establish the child execution budget; and (g) register the resulting delegation lineage. Das Expires 19 April 2027 [Page 421] Internet-Draft Protected AI Execution Finality October 2026 Where these operations themselves have separate governed effectuation boundaries, the implementation performs the corresponding required verification at those boundaries. The child is initialized with the permitted delegated authority rather than an unrestricted copy of the parent's execution authority. Where the child runtime cannot enforce the required restrictions, the protected system does not treat mere receipt of a signed capability as sufficient to establish non-bypassable delegated control. 11.10.34. WF-10.34 — Separation of Delegation and Downstream Effectuation Successful verification of a Delegation Capability permits the bounded delegation specified by that capability. It does not independently authorize an arbitrary subsequent tool invocation, network transmission, credential release, file modification, purchase, deployment, or other consequential operation proposed by the child. For example, a child agent may be authorized to analyze a repository without receiving authority to commit code. A procurement child may be authorized to compare offers without receiving authority to issue a purchase instruction. A retrieval child may be authorized to read specified documents without obtaining authority to transmit those documents externally. Each separately governed consequential operation remains subject to its applicable protected validation and Finality Sink verification. 11.10.35. WF-10.35 — Recursive Child Delegation Where a child proposes delegation to another agent, the proposal becomes a new Candidate Delegation Act. The protected system obtains the current child authority as the parent authorization context for the proposed descendant. The next Delegation Authority Object is derived from the valid child scope, remaining resources, and applicable recursion restrictions. The protected state manager verifies the delegation lineage and applicable ancestor constraints. Das Expires 19 April 2027 [Page 422] Internet-Draft Protected AI Execution Finality October 2026 A descendant cannot obtain a broader scope by bypassing its immediate parent and referring directly to an earlier root mandate without the required authority. Where recursion is prohibited, the corresponding child-to-descendant handoff remains non-effective. Where recursion is permitted, the newly proposed handoff independently completes the required protected delegation-finality sequence. 11.10.36. WF-10.36 — Revocation and Descendant Authority A protected revocation may affect a parent agent, a child agent, a delegation chain, a particular tool scope, or a protected authority epoch. Where descendant authority depends upon a revoked parent mandate or delegation condition, the corresponding protected revocation rule invalidates affected child authority. The system may maintain a parent-delegation identifier or authenticated ancestor-authority commitment permitting affected descendants to be identified or validated. At a required downstream Finality Sink, a child capability is accepted only when its mandatory parent or delegation-state conditions remain valid. Where immediate invalidation is required, the enforcement arrangement employs the necessary protected state check, authenticated revocation fence, or equivalent mandatory synchronization mechanism. An eventually consistent revocation feed does not independently establish instantaneous rejection throughout all nodes. 11.10.37. WF-10.37 — Return Artifact as a Separate Candidate Act A subordinate agent may produce a result comprising: (a) a text answer; (b) a retrieved document; (c) a code patch; (d) a structured data object; Das Expires 19 April 2027 [Page 423] Internet-Draft Protected AI Execution Finality October 2026 (e) a purchase recommendation; (f) a legal or commercial draft; (g) a tool result; (h) a generated file; (i) a proposed workflow modification; or (j) another output artifact. In an embodiment employing a Return Artifact Admission Gate, the returned material is classified as a Candidate Return Artifact Act. The artifact is held before admission into the parent agent's active context, protected memory, output channel, tool-execution path, or downstream decision state. Completion of the delegated computation does not independently confer authority for the returned artifact to produce a consequential effect. 11.10.38. WF-10.38 — Return Artifact Verification RA-1016 validates the returned artifact against the applicable delegated authority. The validation may include: (a) child identity; (b) delegation identifier; (c) permitted output class; (d) source provenance; (e) data-disclosure restrictions; (f) required tool-use receipts; (g) permitted memory sources; (h) instruction-authority restrictions; (i) authorized purpose; Das Expires 19 April 2027 [Page 424] Internet-Draft Protected AI Execution Finality October 2026 (j) policy state; and (k) return-destination scope. Where required, the return artifact is associated with an authenticated descriptor and applicable validation evidence. An artifact attempting to introduce unauthorized instructions, privileged tool requests, credential material, or authority expansion is refused or restricted according to the protected policy. A returned recommendation to purchase does not itself constitute purchase authorization. A returned code patch does not itself constitute deployment authorization. 11.10.39. WF-10.39 — Return Artifact Admission Capability Upon successful protected return-artifact validation, the relevant protected enforcement mechanism may release or make available a Return Artifact Admission Capability. The capability may bind: delegation_id; child_agent_id; return_artifact_digest; permitted_output_class; allowed_parent_context; permitted_storage_scope; policy_epoch; nonce; expiry; return_admission_sink_id. The return-admission Finality Sink verifies the capability before the artifact enters the corresponding governed parent-state or effectuation interface. Das Expires 19 April 2027 [Page 425] Internet-Draft Protected AI Execution Finality October 2026 Where only bounded evidence use is authorized, the parent may be permitted to read or summarize the artifact without receiving authority to execute instructions contained within it. The return artifact does not expand the original parent mandate. 11.10.40. WF-10.40 — Concrete Parent–Child Research Example In one illustrative implementation, an enterprise user authorizes a primary AI agent to prepare a research summary using specified public and internal documents. The parent mandate permits bounded document retrieval, analysis, and summarization. It does not authorize payment initiation, arbitrary external document export, or modification of production systems. The parent agent determines that a subordinate research agent could analyze part of the material. The parent prepares a Candidate Delegation Act specifying the child identity, research subtask, requested document references, read-only tools, execution budget, permitted output class, and prohibition on further delegation. DI-1002 intercepts the proposal before the child agent receives executable authority. DC-1005 constructs the canonical delegation descriptor. PED-1010 verifies the Parent Mandate Object and the proposed subordinate-agent registry entry. AT-1008 derives a restricted tool scope excluding payment, deployment, and unrestricted shell operations. CE-1007 prepares a bounded context package containing only the documents permitted for the research subtask. BM-1009 reserves the permitted token and tool-use budget and records the prohibited recursion condition. PED-1010 validates the applicable purpose, identity, scope, budget, policy, and freshness predicates. EV-1012 commits the required Delegation LAVR. Das Expires 19 April 2027 [Page 426] Internet-Draft Protected AI Execution Finality October 2026 CR-1013 makes available a scoped Delegation Capability bound to the child, task, context commitment, budget, non-recursion condition, and designated Finality Sink. FS-1014 independently verifies the capability before the child runtime accepts the task. The child then executes with the permitted context and tools. If the child proposes an unauthorized external document transfer, the corresponding downstream Finality Sink refuses that operation unless separately authorized. The child produces a research summary. RA-1016 validates the returned artifact before permitting it to enter the parent's governed context or output path. The successful delegation does not enlarge the parent agent's original authority. 11.10.41. WF-10.41 — Concrete Recursive Delegation Example In another implementation, a primary engineering agent delegates a code-analysis subtask to a specialist child. The parent mandate permits at most two levels of downstream delegation and imposes a shared tool-call budget. The first delegated child receives a capability with one remaining permitted delegation level. The child proposes a further bounded handoff to a source-code analysis agent. The new Candidate Delegation Act is intercepted and validated against the first child's current authority and remaining budget. The protected system reserves the descendant's allowance and verifies that the requested tool set remains within the permitted scope. A new Delegation LAVR and capability are established. The second-level child accepts the task only after the corresponding Finality Sink verifies the capability. If that child attempts further delegation beyond the remaining depth, the recursion predicate fails. Das Expires 19 April 2027 [Page 427] Internet-Draft Protected AI Execution Finality October 2026 If the first child attempts to spawn multiple descendants whose combined reservations exceed the shared budget, the protected budget state prevents incompatible allocations. If a descendant proposes code deployment, the delegation capability does not substitute for the separately required deployment authorization. 11.10.42. WF-10.42 — Controlled Remote-Agent Implementation In a remote-agent embodiment, the parent agent proposes an authenticated task to an external automated service. The protected delegation system validates the receiving agent identity, permitted service, data-retention conditions, task scope, context package, tool permissions, budget, and required policy state. The task is transmitted through an enforcement-controlled A2A gateway or equivalent broker. The capability may be embedded within or cryptographically associated with the task-creation request. The remote receiving component verifies the authorization before creating the executable task or releasing protected task context. If the remote service does not enforce the required scoped restrictions, the deployment must use another controllable enforcement arrangement or limit the claim to the boundaries actually protected. The architecture does not assume that sending a signed authorization to an arbitrary third-party agent makes all of that agent's internal execution paths non-bypassable. 11.10.43. WF-10.43 — Failure and Fail-Closed Handling The protected system refuses an affected delegation when a mandatory condition cannot be established. Examples include: (a) invalid parent authority; (b) unauthorized delegated purpose; (c) unknown or revoked child identity; Das Expires 19 April 2027 [Page 428] Internet-Draft Protected AI Execution Finality October 2026 (d) unauthorized tool scope; (e) prohibited context disclosure; (f) invalid memory-access scope; (g) insufficient execution budget; (h) exceeded recursion depth; (i) incompatible policy epoch; (j) invalid authority or registry authentication; (k) unavailable protected state; (l) failed validation-evidence commitment; (m) missing or invalid Delegation Capability; (n) mismatch between authorized and actual child; (o) task or context substitution; (p) expired capability; (q) unauthorized duplicate capability use; or (r) failed delegation-acceptance Finality Sink verification. The proposed handoff remains non-effective, is denied, or is directed through a separately authorized review procedure. A denial record does not independently authorize child execution. 11.10.44. WF-10.44 — Crash, Retry, and Delegation Recovery OS-1017 maintains a protected delegation outcome record. A non-limiting state machine comprises: PROPOSED; STAGED; VALIDATING; AUTHORIZED; Das Expires 19 April 2027 [Page 429] Internet-Draft Protected AI Execution Finality October 2026 BUDGET_RESERVED; INVOCATION_PENDING; ACTIVE; COMPLETED; DENIED; REVOKED; INDETERMINATE. Where a failure occurs before protected commitment, no corresponding valid capability is released. Where commitment succeeds but child activation has not been confirmed, the recovery mechanism examines the protected delegation and capability state. Where a remote task may already have been accepted, the system does not automatically create another independently authorized child task without evaluating possible duplication. The recovery procedure may employ authenticated task identifiers, receiving-side status queries, idempotency records, protected capability-consumption state, or equivalent mechanisms. Budget reservations are released or reconciled only under the applicable protected completion or cancellation rules. A failed local response does not prove that the remote child was never activated. 11.10.45. WF-10.45 — Alternative Technical Implementations Local supervisor implementation: A protected agent runtime or orchestration broker verifies Delegation Capabilities before enabling subordinate workflow nodes. Containerized implementation: Each child agent executes within a sandbox whose permitted tools, resources, and external effects are bounded by the delegated scope. Hypervisor implementation: A protected host or hypervisor-controlled service mediates subordinate virtual-machine activation and authority transfer. Das Expires 19 April 2027 [Page 430] Internet-Draft Protected AI Execution Finality October 2026 Distributed-agent implementation: A protected gateway controls A2A or equivalent remote-agent task admission and context release. Tool-protocol implementation: An authenticated tool or connector broker verifies the delegation capability before transferring executable task authority to an agent-like service. Confidential-computing implementation: A TEE or confidential workload protects relevant mandate state, delegated authority records, and capability-generation keys. Hardware-assisted implementation: A secure processor, HSM, SmartNIC, DPU, or protected gateway controls specified child-task, credential, or communication enablement conditions. Single-node implementation: The PED, delegation-acceptance gate, capability mechanism, and child runtime operate within one protected computing node. Multi-authority implementation: Where the applicable embodiment requires more than one authority, the delegated authorization is validated against the defined multi-authority predicate before capability availability. These alternatives may provide different degrees of resistance to privileged compromise, runtime substitution, rollback, external-agent noncooperation, or distributed-state inconsistency. 11.10.46. WF-10.46 — PHOSITA Verification and Negative Tests A person having ordinary skill in AI-agent orchestration, distributed systems, access-control systems, cryptographic capabilities, trusted execution, or protected workflow management may test the implementation as follows. Test 1 — Authorized delegation: A valid parent mandate and attenuated child scope permit capability-dependent child admission. Test 2 — Parent scope expansion: The proposed child authority exceeds the parent's authority. Delegation is refused. Test 3 — Tool laundering: The child is requested to use a tool prohibited to the parent. The requested authority is withheld. Test 4 — Memory laundering: A child is requested to access memory unavailable to the parent. The required authorization fails. Das Expires 19 April 2027 [Page 431] Internet-Draft Protected AI Execution Finality October 2026 Test 5 — Context over-disclosure: The parent proposes transferring unrelated protected data. The escrow excludes or refuses the unauthorized content. Test 6 — Child identity substitution: A capability issued for one child is presented by another. Verification fails. Test 7 — Task substitution: The delegated objective is changed after authorization. Descriptor correspondence fails. Test 8 — Context substitution: The transmitted context differs from the protected commitment. The handoff is refused where exact binding is mandatory. Test 9 — Budget over-allocation: Concurrent child reservations exceed a protected shared budget. The state mechanism rejects incompatible allocations. Test 10 — Recursion-depth violation: A child attempts further delegation after its permitted depth is exhausted. The handoff is refused. Test 11 — Sibling proliferation: The parent spawns many children to evade a common agent-count or resource limit. Protected cumulative limits prevent unauthorized expansion. Test 12 — Expired capability: A capability is presented outside its required validity interval. The child admission fails. Test 13 — Capability replay: A consumed single-use delegation capability is presented again. Protected usage-state verification fails. Test 14 — Parent revocation: The parent mandate is revoked. Descendant operations requiring that authority fail their protected state checks. Test 15 — Child revocation: The child registry or delegated authority is invalidated. Further affected operations are refused. Test 16 — ALF mismatch: The target runtime fails a mandatory approved-logic condition. Delegation is withheld. Test 17 — Untrusted task injection: Lower-trust content attempts to induce a delegation beyond the authorized purpose. The required authority or provenance predicate fails. Das Expires 19 April 2027 [Page 432] Internet-Draft Protected AI Execution Finality October 2026 Test 18 — Direct remote-agent call: The parent attempts to bypass the delegation broker through an alternative uncontrolled interface. The governed path is blocked or subjected to equivalent finality enforcement. Test 19 — Tool-call laundering: The parent disguises the delegation as an ordinary tool invocation. The protected operation classification identifies the corresponding governed delegation boundary. Test 20 — Unauthorized child transaction: A child with valid research delegation attempts a payment. The payment Finality Sink refuses effectuation absent separate authorization. Test 21 — Return artifact injection: A child returns an artifact containing unauthorized instructions. The applicable return- admission gate rejects or restricts it. Test 22 — Return data leakage: A returned artifact contains data outside the permitted source or output scope. The protected admission predicate fails. Test 23 — Remote invocation timeout: The handoff response is lost after possible task acceptance. Recovery uses protected outcome state rather than automatically authorizing duplicate execution. Test 24 — Budget-state outage: Required protected budget state becomes unavailable. New affected delegations remain non-effective. Test 25 — Parent-to-child state race: Parent authority changes between delegation validation and child acceptance. The required state-verification condition prevents incompatible admission. Test 26 — Wrong Finality Sink: A capability is presented at an unauthorized agent-acceptance interface. Verification fails. Test 27 — Context-minimization check: The released child context is verified to contain only the approved context items or transformations. Test 28 — Single-node equivalence: Delegation authority and child acceptance operate in one protected node while maintaining the required protected validation and finality-verification functions. The tests may be performed using mock parent and child agents, protected task registries, controlled handoff gateways, quota stores, context escrow services, local process supervisors, remote task endpoints, and fault-injection mechanisms. Das Expires 19 April 2027 [Page 433] Internet-Draft Protected AI Execution Finality October 2026 11.10.47. WF-10.47 — Technical Effect The embodiment establishes a protected execution-finality dependency between: (a) a Parent Mandate Object; (b) a proposed Candidate Delegation Act; (c) mandatory interception and Non-Effective State; (d) a canonical Delegation Intent Descriptor; (e) authenticated child-agent identity; (f) bounded delegated-purpose and tool authorization; (g) context and memory minimization; (h) protected resource-budget allocation; (i) recursion and descendant-authority restrictions; (j) protected authorization-state validation; (k) required Delegation LAVR commitment; (l) scoped non-bearer Delegation Capability availability; (m) independent delegation-acceptance Finality Sink verification; (n) bounded child execution; (o) separately governed downstream effectuation; and (p) protected admission of returned artifacts where applicable. The architecture prevents a parent AI agent from manufacturing broader authority through agent spawning, remote-task invocation, tool handoff, unrestricted context transmission, shared credential access, budget multiplication, or recursive delegation. The protected system permits legitimate multi-agent cooperation while maintaining the applicable parent-authority boundaries. A Delegation Capability authorizes only its expressly bounded handoff and does not confer unrestricted authority over subsequent consequential operations. Das Expires 19 April 2027 [Page 434] Internet-Draft Protected AI Execution Finality October 2026 Computation is not authority to act. The authority to assign a task is not authority to expand the recipient's permissions. Delegation of computation does not independently delegate unrestricted execution authority. 11.11. WF-11 — Protected Autonomous Code Changes, Artifact Signing, Software Supply-Chain Authorization, Agent-Generated Skill Deployment, and Progressive Release Finality 11.11.1. WF-11.1 — Technical Purpose This embodiment describes a computer-implemented protected execution- finality architecture for governing software modifications, repository operations, executable artifacts, supply-chain changes, signing operations, and deployment instructions generated, selected, or requested by an artificial-intelligence agent or associated autonomous computational workload. The system prevents a governed software change from becoming effective at a repository merge interface, artifact-signing service, package registry, build-finalization interface, deployment controller, infrastructure activation interface, or other designated release boundary without satisfaction of the applicable protected execution-finality conditions. An AI coding agent may generate source code, modify dependencies, prepare build instructions, create executable packages, construct deployment manifests, propose repository changes, or recommend production rollouts. Such computation does not independently authorize the corresponding merge, signature, publication, installation, deployment, or activation. The proposed consequential operation is classified as a Candidate Deployment Act and maintained in a Non-Effective State until the applicable Protected Enforcement Domain (PED/CIED) validates the required Supply-Chain Authority Object, performs required protected- state operations, generates or commits protected validation evidence, and releases or makes available a Scoped Release Capability. The applicable release Finality Sink independently verifies that capability against the actual operation before permitting the authorized effect. Das Expires 19 April 2027 [Page 435] Internet-Draft Protected AI Execution Finality October 2026 The workflow distinguishes: (a) generation of software or deployment instructions; (b) preparation and validation of build or release artifacts; (c) protected authorization of a particular consequential release operation; (d) use of protected signing, publishing, or activation authority; (e) verification at the actual release Finality Sink; and (f) subsequent software execution or deployment progression, where independently governed. The architecture is applicable to AI coding assistants, autonomous software agents, DevOps agents, continuous-integration systems, continuous-deployment systems, autonomous infrastructure controllers, package managers, software registries, agent skill systems, and other software supply-chain environments. 11.11.2. WF-11.2 — Participating Technical Components In one non-limiting implementation, the system comprises the following components. AE-1101 — Autonomous Development Execution Environment An AI coding agent, software-development assistant, autonomous DevOps agent, code-generation model, build-planning system, tool-using agent, or corresponding computational environment configured to propose software changes. IM-1102 — Deployment Interception Component An enforcement-controlled interface configured to intercept a proposed consequential software or deployment operation before the corresponding release boundary is crossed. HQ-1103 — Non-Effective Deployment Holding Mechanism A controlled staging mechanism retaining a proposed deployment operation, immutable artifact reference, pending merge request, publication request, signing request, or deployment instruction until required protected authorization succeeds. DC-1104 — Candidate Deployment Act Descriptor Component Das Expires 19 April 2027 [Page 436] Internet-Draft Protected AI Execution Finality October 2026 A mechanism configured to construct or verify a canonical, machine- readable representation of the proposed deployment act and its finality-relevant context. PED-1105 — Protected Enforcement Domain A protected authorization component configured to authenticate the applicable Supply-Chain Authority Object, evaluate required execution predicates, perform protected authorization-state operations, commit required validation evidence, and control release of deployment- execution authority. SA-1106 — Supply-Chain Authority Object Store An authenticated or protected authority source maintaining the permitted repository, branch, changed-file scope, software purpose, workflow conditions, dependency restrictions, review requirements, signing conditions, deployment environment, and applicable release authority. PS-1107 — Protected Deployment-State Store A protected mechanism maintaining applicable policy epochs, authorized deployment records, artifact identities, validation commitments, nonce state, capability-usage state, release-stage state, revocation conditions, and other mandatory authorization information. EV-1108 — Deployment Validation-Evidence Component A mechanism configured to generate or commit a Deployment LAVR, ZK- LAVR, authenticated validation record, sealed commitment, or equivalent protected validation evidence. CR-1109 — Scoped Release Capability Mechanism A protected component configured to generate, derive, register, activate, or release the scoped execution capability required by a governed release operation. KS-1110 — Protected Signing or Activation-Key Component An optional HSM, secure enclave, protected key service, trusted controller, or equivalent protected component maintaining production signing, publication, or activation authority. FS-1111 — Release Finality Sink Das Expires 19 April 2027 [Page 437] Internet-Draft Protected AI Execution Finality October 2026 An enforcement-controlled repository manager, merge controller, signing service, package registry, build-finalization interface, deployment orchestrator, infrastructure controller, or equivalent technical boundary that verifies required release authority before effectuation. RM-1112 — Runtime and Rollout Monitoring Component An optional component configured to provide required deployment telemetry, runtime behavioral measurements, anomaly evidence, rollout-stage status, and policy-state information. OS-1113 — Deployment Outcome-State Component A protected mechanism maintaining completed, denied, staged, reserved, interrupted, revoked, rolled-back, or indeterminate deployment-effectuation information. SC-1114 — Release-State Consistency Component A mechanism configured to verify required correspondence among the validated artifact, authorized deployment stage, protected policy epoch, capability state, target environment, and actual release operation. The components may be implemented within one node, across multiple authenticated services, within a protected controller, through software-isolated components, or using hardware-rooted enforcement. The PED, Finality Gate, and Finality Sink perform distinguishable functions but need not comprise physically separate devices where the applicable protected verification relationships are maintained. 11.11.3. WF-11.3 — Establishment of the Software Supply-Chain Trust Boundary Before governed software modifications are permitted to become effective, the system establishes a trust boundary between AE-1101 and the repository, signing, publication, and deployment interfaces controlled by FS-1111. The agent may prepare and submit software changes but does not independently possess unrestricted authority to: (a) merge into a protected repository branch; (b) alter protected release policies; Das Expires 19 April 2027 [Page 438] Internet-Draft Protected AI Execution Finality October 2026 (c) use a production artifact-signing key; (d) publish to a protected package registry; (e) activate an unapproved executable skill; (f) replace approved build or deployment instructions; (g) promote a container image into a protected environment; (h) modify infrastructure resources outside the applicable authority scope; (i) override protected test or review requirements; or (j) invoke an alternative release path that bypasses the designated finality controls. In one implementation, an AI agent operates within a sandboxed development environment that has permission to create local code changes but lacks direct authority over protected production release interfaces. The agent submits proposed consequential operations to IM-1102. A non-authoritative intermediary may transport or prepare a release request, but cannot independently create the protected release capability. 11.11.4. WF-11.4 — Identification of Governed Release Boundaries The system identifies the operations that are governed as consequential release events. Non-limiting boundaries include: (a) protected source-code branch merge; (b) repository reference or release-tag mutation; (c) signing of an executable artifact; (d) signing of a production container image; (e) admission of a package into a protected registry; (f) publication of a software release; Das Expires 19 April 2027 [Page 439] Internet-Draft Protected AI Execution Finality October 2026 (g) promotion of an artifact between deployment environments; (h) application of an infrastructure-as-code modification; (i) activation of a production workload; (j) installation or activation of an AI-agent skill; (k) modification of production CI/CD instructions; (l) release of an update to a protected device or service; and (m) execution of a production rollback where the rollback itself is governed. Each boundary is associated with a release Finality Sink or another protected finality-verification mechanism. The system distinguishes multiple release boundaries when the corresponding effects are separate. For example, authorization to merge source code does not automatically authorize production artifact signing or deployment. 11.11.5. WF-11.5 — Mandatory Interception and Release-Path Coverage The system configures each governed release path so that the relevant consequential effect depends upon the required finality verification. In a repository implementation, this may include protected branch controls and a repository merge service accepting only release operations that pass the applicable capability-verification procedure. In an artifact-signing implementation, the signing key remains inaccessible to the untrusted agent and unauthorized CI/CD components. In a deployment implementation, the production deployment controller accepts only operations satisfying the applicable protected release- capability conditions. A build pipeline that merely calls a validation script is insufficient to establish non-bypassability if the agent can invoke a separate signing or deployment interface that performs the same protected effect without verification. Das Expires 19 April 2027 [Page 440] Internet-Draft Protected AI Execution Finality October 2026 The actual implementation therefore identifies and controls all agent-accessible release paths capable of producing the governed effect. Non-bypassability is evaluated against the specified threat model and the interfaces actually controlled by the implementation. 11.11.6. WF-11.6 — Generation of the Candidate Deployment Act AE-1101 receives an authorized development task or proposed operational objective. The agent may generate: (a) a source-code modification; (b) a dependency update; (c) a build-script change; (d) a CI/CD configuration modification; (e) a deployment manifest; (f) an infrastructure-as-code modification; (g) a software package or executable artifact; (h) an agent-generated skill or plugin; (i) a container image; (j) a production release instruction; or (k) another proposed software supply-chain operation. The corresponding consequential request is classified as Candidate Deployment Act CDA-1115. Generation of CDA-1115 does not independently authorize the act to produce a protected repository, signing, publication, or deployment effect. 11.11.7. WF-11.7 — Interception and Non-Effective Staging IM-1102 intercepts CDA-1115 before the governed release effect occurs. Das Expires 19 April 2027 [Page 441] Internet-Draft Protected AI Execution Finality October 2026 The proposed operation is placed within HQ-1103. An illustrative staging record comprises: operation_id; requesting_agent_id; repository_id; branch_id; proposed_commit_reference; artifact_reference; requested_release_operation; target_environment; requested_finality_sink; policy_epoch; created_at; status = NON_EFFECTIVE. The system may store the corresponding source change, build output, or artifact bytes in controlled temporary storage while retaining an immutable or authenticated reference for authorization. The staging mechanism prevents the proposed operation from reaching the protected release interface until the required authorization conditions are established. A locally successful build or test does not itself advance the Candidate Deployment Act into an effective release state. 11.11.8. WF-11.8 — Construction of the Candidate Deployment Act Descriptor DC-1104 constructs a machine-readable Candidate Deployment Act Descriptor identifying the effectuation-relevant attributes of CDA- 1115. A non-limiting descriptor comprises: Das Expires 19 April 2027 [Page 442] Internet-Draft Protected AI Execution Finality October 2026 operation_id; requesting_agent_identity; repository_identity; branch_identity; commit_digest; diff_digest; changed_file_classes; dependency_changes; CI_CD_changes; build_script_changes; infrastructure_resource_changes; secret_handling_changes; network_egress_changes; privileged_API_changes; test_status; scanner_status; review_state; artifact_digest; package_identity; release_environment; deployment_target; agent_identity; approver_identity; authorized_purpose_reference; Das Expires 19 April 2027 [Page 443] Internet-Draft Protected AI Execution Finality October 2026 policy_epoch; revocation_epoch; nonce; expiry; release_stage; finality_sink_identity. The particular Authority Object and specified embodiment determine which fields are mandatory. The descriptor distinguishes the proposed software change from the authority to make that change effective. 11.11.9. WF-11.9 — Deterministic Descriptor Encoding In a cryptographic implementation, the descriptor is encoded using a defined deterministic serialization procedure. An illustrative representation is: Ddeploy = Canon_v(REPO, BRANCH, COMMIT, DIFF, ARTIFACT, OP, TARGET, ENV, X, EPOCH, SINK) where: Ddeploy denotes the canonical deployment descriptor; Canon_v denotes deterministic canonical encoding under version v; REPO denotes the authenticated repository identity; BRANCH denotes the affected repository branch; COMMIT denotes the applicable commit digest; DIFF denotes the required source-change digest; ARTIFACT denotes the artifact or package identity; OP denotes the requested consequential operation; TARGET denotes the intended deployment or release target; Das Expires 19 April 2027 [Page 444] Internet-Draft Protected AI Execution Finality October 2026 ENV denotes the release environment; X denotes applicable runtime, review, and validation context; EPOCH denotes the applicable authorization-state version; and SINK denotes the designated release Finality Sink. An illustrative descriptor commitment is: hDeploy = H("DAS-DEPLOY-v1" || Encode(Ddeploy)) where H is a cryptographic hash function and the quoted label identifies the illustrative domain of the commitment. The encoder uses unambiguous field representations and consistent digest interpretation. The same encoding rules are applied when FS-1111 reconstructs or verifies the actual release operation. The particular encoding and hash algorithm are implementation choices rather than mandatory requirements of every embodiment. 11.11.10. WF-11.10 — Acquisition of the Supply-Chain Authority Object PED-1105 obtains the applicable Supply-Chain Authority Object from SA-1106. The Authority Object may identify: (a) authorized repositories and branches; (b) permitted source-code paths; (c) allowed dependency classes; (d) permitted build and deployment operations; (e) authorized software-development purpose; (f) required ALF or approved workflow; (g) required test and scanner results; (h) code-review and human-approval requirements; (i) protected signing requirements; Das Expires 19 April 2027 [Page 445] Internet-Draft Protected AI Execution Finality October 2026 (j) permitted release environments; (k) authorized deployment targets; (l) release time windows; (m) permitted rollback procedures; (n) policy epoch and revocation requirements; and (o) applicable Finality Sink identities. PED-1105 verifies the authenticity, applicability, validity, and required current authorization state of the Authority Object. An agent-generated assertion that a release is safe or approved does not independently establish protected release authority. 11.11.11. WF-11.11 — Authorized Development Purpose Validation PED-1105 evaluates whether CDA-1115 remains within the authorized development or deployment purpose. Where applicable, the Algorithmic Intent Fingerprint (AIF) represents the approved software-development objective and its permitted operating scope. The validation compares the proposed software change with the authorized task. For example, authority to repair a logging defect does not automatically authorize the agent to modify production credential controls or network security policies. The proposed operation may satisfy the authorized intent condition through exact correspondence or a narrower permitted scope, according to the applicable AIF matching rules. An unauthorized widening of the task causes the corresponding protected purpose predicate to fail. 11.11.12. WF-11.12 — Approved Logic and Workflow Validation Where required, PED-1105 validates the applicable Algorithmic Logic Fingerprint (ALF). The ALF may represent an approved: Das Expires 19 April 2027 [Page 446] Internet-Draft Protected AI Execution Finality October 2026 (a) code-generation workflow; (b) source-review workflow; (c) test pipeline; (d) build pipeline; (e) dependency-resolution process; (f) software-packaging process; (g) signing workflow; (h) package-publication process; or (i) deployment process. The PED verifies that the relevant executing workflow corresponds to the approved logic or configuration under the applicable authority rules. A change to a protected build or review pipeline may require separate authorization because the modification can change the technical procedure through which future artifacts are approved. ALF validation is a required authorization predicate only when specified by the applicable Authority Object or embodiment. It does not independently replace release capability issuance and Finality Sink verification. 11.11.13. WF-11.13 — Runtime Behavioral and Provenance Validation Where required, PED-1105 evaluates a Runtime Behavioral Descriptor (RBD) associated with the development operation. The RBD may record: (a) source files accessed; (b) tools invoked; (c) build commands executed; (d) dependencies introduced; (e) external repositories consulted; Das Expires 19 April 2027 [Page 447] Internet-Draft Protected AI Execution Finality October 2026 (f) retrieved source material; (g) test commands performed; (h) scanners executed; (i) review events; (j) CI/CD changes; (k) privileged operations requested; (l) external content sources influencing code generation; and (m) relevant runtime deviations. The protected system may additionally evaluate provenance or taint information associated with code generated from untrusted external inputs. Untrusted retrieved content does not independently authorize changes to deployment policy, protected signing configuration, production infrastructure, or privileged execution scope. A required provenance failure prevents the corresponding release capability from being made available. 11.11.14. WF-11.14 — Changed-File and Dependency-Scope Validation PED-1105 compares the proposed change against the permitted file and dependency scope. The evaluation may consider: (a) modified repository paths; (b) newly created executable files; (c) deleted security controls; (d) modified dependency manifests; (e) new package sources; (f) modified lockfiles; (g) executable dependency-installation hooks; Das Expires 19 April 2027 [Page 448] Internet-Draft Protected AI Execution Finality October 2026 (h) build-time scripts; (i) privileged library usage; and (j) changes to software integrity or verification logic. Where exact changed-file restrictions are required, the validated descriptor binds the relevant file identities or change digest. A modification outside the permitted authority scope is rejected or subjected to separately authorized review. The system does not assume that a change remains acceptable merely because ordinary compilation or unit tests succeed. 11.11.15. WF-11.15 — Credential, Privilege, and Network-Egress Change Validation PED-1105 evaluates whether the proposed modification changes protected operational permissions. Applicable changes may include: (a) adding credential-reading logic; (b) changing secret-management interfaces; (c) introducing credential export paths; (d) modifying authentication controls; (e) widening operating-system privileges; (f) changing production network destinations; (g) creating new outbound communication capabilities; (h) modifying firewall or egress rules; (i) changing privileged APIs; (j) changing deployment-service identities; and (k) replacing protected release-verification logic. Where such changes fall outside the authorized scope, the protected system withholds the required release capability. Das Expires 19 April 2027 [Page 449] Internet-Draft Protected AI Execution Finality October 2026 An agent cannot manufacture permission for its own privileged code change merely by editing the ordinary policy file that would otherwise reject the operation. 11.11.16. WF-11.16 — Test, Scan, Review, and Approval Validation The protected authority evaluates the test, scanner, review, and approval results required by the applicable Supply-Chain Authority Object. Such requirements may include: (a) unit-test completion; (b) integration-test completion; (c) static analysis; (d) dynamic analysis; (e) dependency vulnerability scanning; (f) secret detection; (g) software bill of materials verification; (h) artifact provenance validation; (i) build attestation; (j) required code review; and (k) authenticated human approval. The PED determines whether each mandatory requirement has been satisfied for the actual Candidate Deployment Act. A scanner result associated with an earlier commit is not treated as valid for a materially different artifact when exact artifact correspondence is required. An approval for one repository, change, or deployment target does not authorize a different operation outside the approved scope. 11.11.17. WF-11.17 — Protected Release Authorization Predicate PED-1105 evaluates the required release predicates. Das Expires 19 April 2027 [Page 450] Internet-Draft Protected AI Execution Finality October 2026 For an illustrative conjunctive authorization policy: Vdeploy = Ppurpose AND Pworkflow AND Pchange AND Partifact AND Prelease AND Pstate where: Vdeploy denotes the protected deployment-validation result; Ppurpose verifies authorized development purpose; Pworkflow verifies the applicable approved ALF or workflow; Pchange verifies the permitted code, dependency, configuration, privilege, and infrastructure modifications; Partifact verifies the applicable source, build, and artifact identity; Prelease verifies required tests, scans, reviews, approvals, target, and release scope; and Pstate verifies required policy, revocation, freshness, and protected-state conditions. Additional predicates may be imposed by the applicable Authority Object. Where approved alternative or threshold conditions are specified, the protected system evaluates those according to the authorized combination rules rather than requiring literal conjunction of all possible predicates. A failure of any mandatory predicate prevents successful release authorization. 11.11.18. WF-11.18 — Protected Deployment-State Reservation Following successful predicate validation, PED-1105 performs the protected-state operation required for CDA-1115. The operation may comprise: (a) reserving the authorization for a particular release act; (b) consuming or registering an authorization nonce; (c) advancing a protected release counter; Das Expires 19 April 2027 [Page 451] Internet-Draft Protected AI Execution Finality October 2026 (d) recording the validated artifact digest; (e) checking the current policy epoch; (f) registering the approved deployment stage; (g) consuming a single-use release grant; (h) verifying non-revocation; or (i) performing another required protected authorization transition. For a single-use release grant, an illustrative transition is: AVAILABLE → RESERVED(operation_id, artifact_digest, state_version) The transition is performed using protected transactional storage, a secure compare-and-update mechanism, a hardware-protected counter, or an equivalent state mechanism. Where multiple requests compete for one restricted release grant, the protected mechanism prevents unauthorized concurrent consumption. If the required state transition cannot be established consistently, the release capability is withheld. 11.11.19. WF-11.19 — Deployment Validation-Evidence Commitment After successful authorization and in coordination with the protected-state transition, EV-1108 generates or commits the applicable protected validation evidence. The evidence may comprise a Deployment LAVR, ZK-LAVR, sealed validation record, authenticated commitment, or equivalent protected representation. An illustrative evidence record contains: receipt_id; candidate_deployment_act_id; deployment_descriptor_digest; repository_identity; commit_digest; Das Expires 19 April 2027 [Page 452] Internet-Draft Protected AI Execution Finality October 2026 artifact_digest; authority_object_reference; validated_predicate_reference; test_and_review_state_reference; protected_state_transition; authorized_release_environment; policy_epoch; nonce; finality_sink_id; decision; protected_authentication. Where the applicable embodiment requires pre-effectuation evidence commitment, the protected commitment is completed before, or atomically with, capability availability. Ordinary CI/CD audit logs created after a release do not independently substitute for this required protected authorization dependency. 11.11.20. WF-11.20 — Privacy-Preserving Deployment Validation Variant Where deployment rules, enterprise source policies, private scanner findings, proprietary workflow measurements, or protected review criteria must remain confidential, the PED/CIED may employ a ZK-LAVR. In an embodiment using an actual zero-knowledge proof construction, the validation evidence may establish satisfaction of defined release predicates without exposing specified confidential predicate inputs. The protected release capability remains conditional upon the proof, commitment, and required authorization state being valid. A ZK-LAVR is not itself an unrestricted release credential. The precise zero-knowledge guarantee depends upon the implemented proof system and its established security assumptions. Das Expires 19 April 2027 [Page 453] Internet-Draft Protected AI Execution Finality October 2026 Where a hybrid attestation mechanism is used instead, the system claims only the confidentiality and verification properties actually provided by that implementation. 11.11.21. WF-11.21 — Protected Deployment-Finality Transaction The PED coordinates the required validation, protected-state handling, evidence commitment, and capability-availability conditions. An illustrative protected finality transaction is: (Snext, Rdeploy, Ready) = CommitDeployment(Ddeploy, A, Scurrent, F) where: Snext denotes the successfully committed protected deployment state; Rdeploy denotes the protected deployment-validation evidence; Ready denotes the protected indication that required release prerequisites are satisfied; Ddeploy denotes the validated Candidate Deployment Act Descriptor; A denotes the authenticated Supply-Chain Authority Object; Scurrent denotes the protected authorization state before commitment; and F denotes the designated release Finality Sink. The transaction does not produce an externally usable release capability if a mandatory protected-state or evidence-commitment operation remains incomplete. The protected transaction may be implemented using transactional state, an HSM-controlled authorization procedure, sealed storage, authenticated release-state machinery, or equivalent protected mechanisms. This transaction does not presume that an arbitrary external package registry or deployment target participates in one globally atomic database transaction. Das Expires 19 April 2027 [Page 454] Internet-Draft Protected AI Execution Finality October 2026 11.11.22. WF-11.22 — Scoped Release Capability Generation After successful completion of the required protected deployment- finality transaction, CR-1109 generates, registers, or makes available a Scoped Release Capability. In an illustrative cryptographic implementation: Crelease = Sign_skPED(Encode(hDeploy, hR, Repo, Commit, Artifact, Target, Env, F, Epoch, Nonce, Expiry, CID)) where: Crelease denotes the Scoped Release Capability; Sign_skPED denotes signature generation using a signing key controlled by the PED; hDeploy denotes the deployment descriptor digest; hR denotes the committed deployment-validation evidence digest; Repo denotes the authorized repository; Commit denotes the validated commit identity; Artifact denotes the authorized artifact identity; Target denotes the authorized deployment target; Env denotes the authorized release environment; F denotes the applicable release Finality Sink; Epoch denotes the required policy or authorization epoch; Nonce denotes the required freshness value; Expiry denotes the capability validity limit; and CID denotes the capability identifier. The particular artifact representation, cryptographic signature scheme, encoding format, and key substrate depend upon the selected implementation. The capability is not treated as non-bearer merely because it is cryptographically signed. Das Expires 19 April 2027 [Page 455] Internet-Draft Protected AI Execution Finality October 2026 The receiving release Finality Sink enforces the required artifact, operation, environment, scope, state, and consumption restrictions before permitting effectuation. 11.11.23. WF-11.23 — Artifact and Commit Binding in the implementation described by enforcement point 44, the Scoped Release Capability is bound to: (a) commit digest; (b) artifact digest; (c) repository identity; (d) branch identity; (e) deployment target; (f) release environment; (g) policy epoch; (h) nonce; and (i) expiry. The Finality Sink obtains the actual repository, commit, artifact, destination, and environment involved in the requested consequential operation. The protected verification procedure compares those values against the capability's mandatory bindings. Where exact artifact correspondence is required, substitution of a different artifact digest causes verification failure. Where the actual deployment target differs from the authorized target, the release is refused unless renewed authorization permits the changed operation. The authorization is therefore associated with the artifact and effectuation operation actually presented, rather than merely with the agent's earlier statement that a deployment was approved. Das Expires 19 April 2027 [Page 456] Internet-Draft Protected AI Execution Finality October 2026 11.11.24. WF-11.24 — Binding Source Changes to Built Artifacts In an implementation involving separate source and build stages, the system maintains a verifiable relationship between the authorized source change and the artifact submitted for signing or deployment. The relationship may use: (a) an authenticated source commit; (b) an approved build definition; (c) an artifact digest; (d) a build-attestation record; (e) a signed provenance statement; (f) a protected source-to-artifact mapping; or (g) another machine-verifiable build identity mechanism. Where a claim or authority condition requires correspondence between the validated commit and the deployed artifact, the protected system verifies the required relationship. The presence of an artifact digest alone does not establish that the artifact was produced from an approved source commit. If the build result changes materially, the previous authorization is insufficient where the required artifact binding no longer matches. 11.11.25. WF-11.25 — Protected Artifact-Signing and Publication Keys In the stronger hardware-protected embodiment corresponding to enforcement point 45, KS-1110 retains one or more protected release keys. Such keys may include: (a) a production artifact-signing key; (b) a package-publication key; (c) a protected container-signing key; (d) an artifact-activation key; or Das Expires 19 April 2027 [Page 457] Internet-Draft Protected AI Execution Finality October 2026 (e) a deployment-enablement key. KS-1110 may comprise a hardware security module, secure enclave, or equivalent protected key-control environment satisfying the applicable claim limitations. The untrusted coding agent and ordinary CI/CD controller do not receive unrestricted access to the protected release key. A signing or activation request is processed only after the required corresponding Scoped Release Capability has been verified. The protected component validates the requested key usage, artifact identity, operation scope, release context, and required authorization state. A key existing within an HSM does not by itself establish deployment- finality security. The required capability-dependent key-use restriction must actually be enforced. 11.11.26. WF-11.26 — Hardware-Latched Release Procedure A hardware-latched release implementation may operate as follows. First, the AI agent generates a proposed artifact or deployment instruction. Second, the deployment interception component holds the corresponding release request. Third, PED-1105 validates the Candidate Deployment Act against its applicable Supply-Chain Authority Object. Fourth, the PED completes the required protected-state and evidence- commitment operations. Fifth, CR-1109 makes available the corresponding Scoped Release Capability. Sixth, KS-1110 or the designated release-verification component authenticates the capability and verifies the required artifact, key- use, environment, policy, freshness, and Finality Sink bindings. Seventh, the protected key operation is enabled only for the validated release act. Eighth, the artifact-signing or deployment-enablement operation proceeds within the permitted scope. Das Expires 19 April 2027 [Page 458] Internet-Draft Protected AI Execution Finality October 2026 If the required authorization or capability verification fails, the protected signing or activation key remains unavailable for the requested operation. In a non-exportable-key implementation, the protected module may perform the approved signing operation without exposing the underlying private key. The architecture thereby prevents the ordinary CI/CD controller from treating possession of a key reference or signing-service endpoint as unrestricted production release authority. 11.11.27. WF-11.27 — Independent Verification at the Release Finality Sink FS-1111 obtains the actual consequential release request and the corresponding Scoped Release Capability or authenticated capability reference. Before effectuation, the Finality Sink verifies: (a) capability authenticity; (b) required deployment descriptor correspondence; (c) repository and branch identity; (d) commit digest; (e) artifact digest; (f) requested release-operation class; (g) actual deployment target; (h) release environment; (i) designated Finality Sink identity; (j) required policy and revocation state; (k) nonce and expiry conditions; (l) required validation-evidence commitment; and (m) applicable capability-usage or consumption state. An illustrative verification predicate is: Das Expires 19 April 2027 [Page 459] Internet-Draft Protected AI Execution Finality October 2026 PermitRelease = Auth(C) AND Match(C,Dactual) AND ArtifactValid(C,Aactual) AND TargetValid(C,Tactual) AND StateValid(C,S) AND SinkValid(C,F) where: C denotes the Scoped Release Capability; Dactual denotes the actual deployment operation descriptor; Aactual denotes the actual artifact; Tactual denotes the actual deployment target; S denotes the required protected authorization state; and F denotes the release Finality Sink. The governed release operation proceeds only when all mandatory verification predicates succeed. The Finality Sink does not rely solely upon an upstream CI/CD system reporting that tests, reviews, or approvals were successful. 11.11.28. WF-11.28 — Finality-Specific Release Operations The release Finality Sink may be implemented at different consequential boundaries. Repository merge: The controlled merge interface verifies the capability before updating the protected repository reference. Artifact signing: The signing service verifies the capability before producing the protected signature. Package publication: The package registry admission interface verifies the capability before making the package available through the governed registry. Build finalization: The protected build interface verifies applicable release authority before admitting a build result into the designated authoritative artifact state. Production deployment: The deployment controller verifies the capability before applying the protected workload change. Das Expires 19 April 2027 [Page 460] Internet-Draft Protected AI Execution Finality October 2026 Infrastructure activation: The infrastructure controller verifies the applicable capability before applying the governed configuration or resource mutation. The authorization and effectuation semantics depend upon the selected boundary. A successful repository merge does not automatically establish authorization for later production deployment. 11.11.29. WF-11.29 — Agent-Generated Skill and Plugin Deployment in the implementation described by enforcement point 46, CDA-1115 comprises a proposed installation, activation, publication, or execution enablement of an agent-generated skill, plugin, tool package, script, executable artifact, or associated agent capability. An AI agent may generate a skill containing: (a) executable instructions; (b) a tool manifest; (c) new API integrations; (d) filesystem access requirements; (e) credential-use requirements; (f) network destinations; (g) dependency changes; (h) runtime execution permissions; or (i) modifications to the approved agent tool graph. The proposed skill remains non-effective at its governed installation or activation boundary pending protected authorization. PED-1105 validates the skill against: (a) the authorized purpose; (b) approved tool graph or ALF; (c) dependency changes; Das Expires 19 April 2027 [Page 461] Internet-Draft Protected AI Execution Finality October 2026 (d) privileged API use; (e) permitted execution scope; and (f) other applicable authority predicates. A skill-generated request to increase its own permissions does not independently authorize the requested scope expansion. The protected system distinguishes permission to generate a skill package from permission to activate the skill within a particular agent execution environment. 11.11.30. WF-11.30 — Skill Installation and Activation Finality In one implementation, the protected agent runtime maintains a skill installation or activation interface controlled by a designated Finality Sink. The AI agent produces a skill package and corresponding manifest. The proposed installation or activation request is intercepted and staged. The system constructs a Candidate Deployment Act Descriptor identifying the skill artifact, requesting agent, package digest, permitted tool graph, dependency set, requested permissions, target agent runtime, applicable policy epoch, and activation Finality Sink. PED-1105 validates the applicable Supply-Chain Authority Object and mandatory runtime predicates. Upon successful protected validation, the required deployment evidence is committed and a Scoped Release Capability is issued or made available. The activation Finality Sink verifies the capability against the actual skill package and requested permissions. The protected interface permits installation or activation only when the required verification succeeds. If the skill requests a privileged API, dependency, destination, or tool permission outside the authorized scope, the operation remains non-effective unless separately authorized. Das Expires 19 April 2027 [Page 462] Internet-Draft Protected AI Execution Finality October 2026 Where activation changes the agent's approved runtime configuration, the corresponding self-modification controls described in WF-09 may also apply. 11.11.31. WF-11.31 — Separation of Skill Activation from Later Tool Execution Successful installation or activation of an approved skill does not automatically authorize every consequential operation later requested through that skill. The skill may generate a subsequent Candidate Act requiring network access, credential application, file mutation, database commitment, payment execution, or another protected effectuation operation. Each separately governed downstream act remains subject to the corresponding protected authorization and Finality Sink verification. The Scoped Release Capability used to activate the skill is not automatically reusable as a general Sandbox Egress Capability or credential-effectuation capability. This prevents software-installation authorization from being converted into unrestricted downstream operational authority. 11.11.32. WF-11.32 — Progressive Deployment and Stage-Specific Authority in the implementation described by enforcement point 47, a deployment comprises multiple governed release stages. Non-limiting stages include: (a) development build; (b) protected test environment; (c) staging environment; (d) canary release; (e) limited production rollout; (f) progressive rollout; (g) blue-green deployment; (h) full production release; and Das Expires 19 April 2027 [Page 463] Internet-Draft Protected AI Execution Finality October 2026 (i) authorized rollback or recovery. The PED evaluates the authority applicable to each governed stage. A capability for one stage does not automatically authorize progression into another independently governed stage. A stage-specific capability may bind: deployment_id; artifact_digest; stage_id; source_environment; target_environment; permitted_rollout_scope; policy_epoch; runtime_state_reference; nonce; expiry; finality_sink_id. The corresponding stage Finality Sink verifies the applicable capability before enabling that deployment stage. 11.11.33. WF-11.33 — Stage-Associated Micro-LAVRs and Rollout Capabilities For a staged release, the PED may generate stage-associated protected validation evidence, including micro-LAVRs. An illustrative stage record comprises: deployment_id; stage_id; artifact_digest; Das Expires 19 April 2027 [Page 464] Internet-Draft Protected AI Execution Finality October 2026 prior_stage_reference; stage_validation_result; runtime_telemetry_reference; policy_epoch; protected_state_version; next_stage_scope; finality_sink_id. After successful validation of the applicable release conditions, the PED issues or makes available a corresponding scoped rollout capability. The deployment controller verifies the capability before advancing to the next protected rollout stage. Where the applicable embodiment requires receipt-chain continuity, the next-stage authorization is associated with the protected evidence and state of the preceding stage. The capability does not automatically authorize arbitrary expansion of deployment scope. 11.11.34. WF-11.34 — Runtime Drift and Rollout Interruption RM-1112 obtains relevant runtime telemetry and behavioral evidence during a staged deployment. Such evidence may include: (a) service failure rates; (b) security-policy violations; (c) unauthorized network behavior; (d) abnormal credential use; (e) unexpected privileged operations; (f) changed deployment configuration; (g) artifact-integrity failures; Das Expires 19 April 2027 [Page 465] Internet-Draft Protected AI Execution Finality October 2026 (h) runtime behavioral deviation; (i) revocation events; and (j) applicable protected policy-state changes. The PED evaluates telemetry, RBD information, policy state, and required anomaly conditions. Where a mandatory runtime-drift, policy-validity, or revocation condition fails, the PED withholds the subsequent scoped rollout capability. The next governed stage remains non-effective. Withholding the next capability prevents further protected deployment progression, but does not automatically reverse deployment effects already completed in earlier stages. Where rollback is required, rollback is performed through its applicable separately authorized procedure. 11.11.35. WF-11.35 — Rollout Progression Predicate For a staged deployment, an illustrative progression predicate is: PermitStage(i+1) = StageValid(i) AND ArtifactValid(i+1) AND TelemetryValid(i) AND PolicyValid(i+1) AND AuthorityValid(i+1) where: PermitStage(i+1) denotes authorization to progress to the next governed stage; StageValid(i) verifies the required completion or authorization state of the prior stage; ArtifactValid(i+1) verifies the artifact identity applicable to the requested stage; TelemetryValid(i) verifies the runtime conditions required from the preceding stage; PolicyValid(i+1) verifies the applicable current policy and revocation conditions; and AuthorityValid(i+1) verifies the required protected authorization for the next stage. Das Expires 19 April 2027 [Page 466] Internet-Draft Protected AI Execution Finality October 2026 Where additional conditions are mandatory, they are incorporated into the authorization procedure. If the predicate fails, the corresponding rollout capability is withheld. The deployment controller cannot treat a previous stage's successful release as unrestricted authority for all later stages. 11.11.36. WF-11.36 — Protected Capability Consumption and Duplicate- Release Prevention Where a release capability permits only one governed effectuation, FS-1111 performs or coordinates the required protected capability- consumption operation. A representative capability-state record comprises: capability_id; deployment_id; artifact_digest; authorized_release_sink; release_stage; remaining_uses; state_version; status. The system verifies that the capability remains valid and within its authorized usage allowance immediately before effectuation. For a single-use capability, the protected mechanism prevents a second incompatible execution from independently consuming the same grant. Where the authorized release permits bounded multiple uses, the applicable usage restrictions are enforced through protected state. A consumed capability does not authorize another release contrary to its permitted scope. Das Expires 19 April 2027 [Page 467] Internet-Draft Protected AI Execution Finality October 2026 The capability-consumption procedure does not itself guarantee that every remote deployment has completed successfully or exactly once. 11.11.37. WF-11.37 — Policy Updates, Revocation, and Artifact Invalidation During development or deployment, the applicable authority conditions may change. Non-limiting events include: (a) revocation of a software release approval; (b) invalidation of an artifact signature; (c) supersession of a permitted policy epoch; (d) discovery of a prohibited dependency; (e) withdrawal of an authorized deployment environment; (f) compromise of a signing credential; (g) revocation of an agent's development authority; or (h) detection of unauthorized runtime behavior. The PED updates or consults the applicable protected authorization state. Where current authorization verification is required, a capability associated with invalid or superseded state cannot authorize further effectuation. Revocation of future deployment authority does not automatically undo an already completed repository merge, publication, or production state change. Any resulting withdrawal, rollback, or recovery operation is governed according to its own effectuation requirements. 11.11.38. WF-11.38 — Time-of-Check and Time-of-Use Protection The architecture maintains the required correspondence between the validated deployment act and the operation actually presented at the Finality Sink. Potential substitutions include: Das Expires 19 April 2027 [Page 468] Internet-Draft Protected AI Execution Finality October 2026 (a) replacing the source commit; (b) altering the built artifact; (c) changing the target repository; (d) changing the destination branch; (e) replacing a container image; (f) changing the deployment environment; (g) modifying a package manifest; (h) changing the skill permissions; (i) substituting a signing-key identifier; (j) changing the release stage; or (k) using a capability after an incompatible policy-state update. Where a required field differs, the prior capability is rejected unless the modification falls within an expressly authorized bounded scope. The Finality Sink obtains the actual effectuation-relevant attributes through an authenticated or otherwise controlled representation. The system does not rely solely upon a release description supplied by the requesting agent. 11.11.39. WF-11.39 — Crash, Timeout, and Deployment Recovery The system distinguishes failures occurring at different stages of the protected deployment-finality procedure. Failure before validation commitment: No valid release capability becomes available for an incomplete mandatory authorization transaction. Failure after protected commitment but before capability delivery: The protected system consults committed authorization and capability state before restoring, reissuing, or retiring the associated capability. Das Expires 19 April 2027 [Page 469] Internet-Draft Protected AI Execution Finality October 2026 Failure before a protected signing operation: The system determines whether the signing capability remains valid and whether the protected key operation has occurred. Failure after possible signing or publication: The corresponding outcome may be indeterminate until suitable authoritative completion evidence is obtained. Failure after deployment initiation: The system distinguishes an operation known not to have taken effect from an operation that may already have changed a production environment. The protected outcome-state component may maintain: PENDING; VALIDATING; AUTHORIZED; RESERVED; SIGNING_IN_PROGRESS; PUBLICATION_IN_PROGRESS; DEPLOYMENT_IN_PROGRESS; CONFIRMED_EFFECTIVE; DENIED; REVOKED; ROLLED_BACK; INDETERMINATE. An uncertain release is not automatically replayed when doing so could create an unauthorized duplicate or conflicting effect. Where the target supports idempotency identifiers, release-status queries, signed publication receipts, deployment-generation values, or protected completion acknowledgments, such mechanisms may support authorized reconciliation. Das Expires 19 April 2027 [Page 470] Internet-Draft Protected AI Execution Finality October 2026 11.11.40. WF-11.40 — Illustrative Autonomous Code-Deployment Example In one concrete implementation, an AI coding agent is authorized to correct an application defect. The authorized task permits modification of specified application- source files but does not permit changes to production credential management, deployment policy, or external network-egress restrictions. The agent prepares a code modification and proposes merging the corresponding commit into a protected repository branch. IM-1102 intercepts the merge operation. HQ-1103 maintains the Candidate Deployment Act in a Non-Effective State. DC-1104 constructs a descriptor identifying the repository, branch, commit digest, changed-file digest, permitted task, affected artifacts, required test results, policy epoch, and merge Finality Sink. PED-1105 obtains the Supply-Chain Authority Object. The PED validates that the changed files are within the authorized scope. The PED additionally verifies the required test, scanner, review, and runtime-behavior predicates. Following successful validation, the protected system commits the required deployment evidence and makes available a Scoped Release Capability. The repository merge Finality Sink reconstructs the actual merge operation and verifies the capability. If the actual commit and repository target match the validated authority, the protected merge is permitted. If the agent substitutes a commit introducing an unauthorized credential-export function, the required descriptor or authorization predicates fail. The protected merge remains blocked. Das Expires 19 April 2027 [Page 471] Internet-Draft Protected AI Execution Finality October 2026 A subsequent production deployment is treated as another governed consequential operation where the applicable deployment boundary requires separate release authority. 11.11.41. WF-11.41 — Illustrative Agent-Generated Skill Example An autonomous AI agent generates a new tool skill intended to retrieve documentation from an approved service. The generated skill includes executable code, a tool manifest, dependency information, and requested runtime permissions. The agent proposes activating the skill. The skill activation request is intercepted and classified as a Candidate Deployment Act. The applicable descriptor identifies the skill digest, approved purpose, dependency changes, requested network destinations, privileged API requirements, approved tool graph, policy epoch, and activation Finality Sink. PED-1105 validates the skill against the Supply-Chain Authority Object. If the generated skill requests unrestricted filesystem access or an unauthorized external destination, the protected authorization fails. If the required predicates succeed, the protected system commits the applicable validation evidence and releases the corresponding Scoped Release Capability. The skill activation Finality Sink verifies the capability against the actual skill package and permitted runtime scope. Only the authorized skill activation becomes effective. A later network request generated by the activated skill remains subject to the applicable sandbox-egress finality procedure. 11.11.42. WF-11.42 — Illustrative Progressive Production Rollout An AI DevOps agent proposes deployment of a validated software artifact into production. The Supply-Chain Authority Object permits a staged deployment beginning with a limited canary environment. Das Expires 19 April 2027 [Page 472] Internet-Draft Protected AI Execution Finality October 2026 The PED validates the initial deployment request, commits the required protected evidence, and releases a capability authorizing the canary stage. The deployment Finality Sink verifies the artifact digest, canary target, policy epoch, protected state, and scoped rollout capability. The canary deployment proceeds. RM-1112 obtains the runtime telemetry required for the next-stage decision. If the telemetry satisfies the applicable protected predicates, PED-1105 may commit a stage-associated micro-LAVR and release the next-stage rollout capability. If an unauthorized network behavior, invalid policy state, revoked artifact approval, or required runtime drift condition is detected, the PED withholds the subsequent capability. The rollout controller cannot proceed to the next governed deployment stage without the required capability verification. Already completed canary effects are not falsely treated as retroactively prevented. 11.11.43. WF-11.43 — Failure and Fail-Closed Conditions The protected release Finality Sink refuses the governed consequential operation when any mandatory condition is absent, invalid, inconsistent, expired, revoked, or unverifiable. Non-limiting failure conditions include: (a) missing Supply-Chain Authority Object; (b) invalid repository identity; (c) unauthorized changed-file scope; (d) invalid commit or artifact digest; (e) unauthorized dependency change; (f) prohibited credential-handling modification; (g) unauthorized privileged API use; Das Expires 19 April 2027 [Page 473] Internet-Draft Protected AI Execution Finality October 2026 (h) unauthorized network-egress change; (i) failed required tests; (j) missing required scanner results; (k) invalid review or approval artifact; (l) failed protected authorization-state transition; (m) failed required Deployment LAVR or ZK-LAVR commitment; (n) missing Scoped Release Capability; (o) invalid capability authentication; (p) unauthorized signing-key use; (q) deployment-target substitution; (r) invalid release environment; (s) stale policy or revocation state; (t) capability replay or exhausted usage state; (u) unauthorized skill permissions; (v) runtime drift invalidating further rollout authority; (w) Finality Sink mismatch; or (x) unavailability of required protected verification machinery. The operation may remain staged, be denied, be quarantined, be restricted to a non-production test environment, or be escalated through a separately authorized review procedure. A failed authorization does not automatically create permission to execute through an unprotected fallback. 11.11.44. WF-11.44 — Alternative Technical Implementations The workflow may be implemented using different protected enforcement arrangements. Repository-controlled implementation: A protected repository merge interface requires valid operation-specific release authority. Das Expires 19 April 2027 [Page 474] Internet-Draft Protected AI Execution Finality October 2026 CI/CD implementation: A build or release pipeline is constrained by an independently protected deployment authorization component. Artifact-registry implementation: A protected registry admission interface verifies the scoped capability before publishing or promoting an artifact. Hardware-signing implementation: An HSM or secure enclave performs the governed signing operation only after required capability verification. Container deployment implementation: A protected container deployment controller verifies release authority before admitting the selected artifact into the authorized environment. Agent skill implementation: A protected agent-runtime installation or activation interface verifies authority before admitting newly generated executable skills. Cloud implementation: A protected cloud deployment interface governs production resource mutation and artifact activation. Single-node implementation: The protected authorization and release- sink verification functions operate within one protected controller. Distributed implementation: A protected authority component releases authenticated capability information that is independently verified by a remote signing, publication, or deployment service. Progressive-deployment implementation: Successive deployment stages require stage-associated authorization evidence and bounded rollout capabilities. Different implementations may provide different resistance to privileged software compromise, rollback, hardware tampering, service compromise, or distributed failure. An implementation must demonstrate the non-bypassable release-path control required by its particular specified security guarantee. 11.11.45. WF-11.45 — PHOSITA Verification and Negative Tests A person having ordinary skill in software supply-chain security, autonomous coding systems, DevOps infrastructure, cryptography, trusted computing, release engineering, or distributed authorization may verify the arrangement through controlled technical tests. Das Expires 19 April 2027 [Page 475] Internet-Draft Protected AI Execution Finality October 2026 Test 1 — Authorized repository merge: Submit a merge operation matching the required authority, descriptor, commit, and protected state. The release Finality Sink permits the specified merge. Test 2 — Unauthorized branch: Attempt to merge the validated commit into a different protected branch. Verification fails where the branch identity is a mandatory binding. Test 3 — Commit substitution: Replace the approved commit with an unapproved commit. The Finality Sink rejects the operation. Test 4 — Artifact substitution: Replace the approved build artifact while retaining the original release capability. Required artifact correspondence fails. Test 5 — Unauthorized dependency: Introduce a prohibited dependency change. The protected authorization predicate fails. Test 6 — Credential-handling modification: Insert an unauthorized credential-export operation into the code delta. The required software-change validation rejects the proposed release. Test 7 — CI/CD bypass: Attempt production deployment through an alternative accessible pipeline that omits the required release verification. The operation is blocked or governed by an equivalent protected Finality Sink. Test 8 — Missing test evidence: Present a release lacking mandatory test or scanner results. No valid corresponding release capability is issued. Test 9 — Approval mismatch: Supply approval for a different commit or target environment. Protected authorization fails. Test 10 — Missing release capability: Invoke the governed signing or deployment interface without the required capability. Effectuation is refused. Test 11 — Unauthorized HSM key use: Attempt to sign an unapproved artifact directly through the protected signing interface. The key- use operation fails. Test 12 — Wrong signing purpose: Present a capability for an incompatible signing or publication operation. Required key-use binding fails. Das Expires 19 April 2027 [Page 476] Internet-Draft Protected AI Execution Finality October 2026 Test 13 — Skill permission escalation: Attempt to activate an agent- generated skill requesting unauthorized privileged permissions. Protected validation refuses activation. Test 14 — Tool-graph mismatch: Alter the skill's approved tool graph before activation. Required logic or scope correspondence fails. Test 15 — Deployment-target substitution: Present an otherwise valid capability for a different production environment. The Finality Sink refuses the operation. Test 16 — Policy revocation: Invalidate the required release authority after preliminary validation. A subsequent affected finality operation is refused unless valid current authorization is established. Test 17 — Replay: Reuse a consumed single-use release capability. The protected usage-state predicate rejects unauthorized reuse. Test 18 — Concurrent release: Submit competing release operations against a single restricted authorization. The protected-state mechanism prevents unauthorized double consumption. Test 19 — Rollout drift: Produce a runtime condition violating mandatory next-stage predicates. The PED withholds the subsequent rollout capability. Test 20 — Stage skipping: Attempt to advance directly to a stage lacking the required authorization. The corresponding Finality Sink refuses progression. Test 21 — Crash before commitment: Interrupt the protected finality transaction before its required commitment. No valid corresponding release capability becomes available. Test 22 — Crash after possible publication: Interrupt publication after the external registry may have accepted the artifact. Recovery distinguishes confirmed, incomplete, and indeterminate status instead of blindly repeating the operation. Test 23 — Protected component failure: Make the required PED or release verifier unavailable. The governed operation does not become authorized through an unprotected fallback. Test 24 — Source-to-artifact mismatch: Present an artifact whose required build provenance does not correspond to the authorized source commit. The protected release check fails. Das Expires 19 April 2027 [Page 477] Internet-Draft Protected AI Execution Finality October 2026 Test 25 — Skill activation versus tool use: Activate an approved skill, then request an unauthorized consequential tool operation. The later operation remains subject to its own applicable finality authorization. Test 26 — Single-node implementation: Execute the protected release sequence within one controller while verifying that the required protected authority and release-finality functions remain distinct and enforced. Test 27 — Distributed release verification: Issue a capability at one protected authority node and present it at a separately controlled deployment Finality Sink. The sink verifies the actual release operation and required authorization state. Test 28 — Artifact signing versus production deployment: Authorize an artifact-signing act, then attempt deployment without the separately required deployment capability. The deployment Finality Sink refuses the operation. Test 29 — Signing key compromise boundary: Attempt release from a compromised ordinary CI/CD controller without the protected signing or activation authorization. The required protected key-use or deployment-verification mechanism refuses the governed operation under the assumed threat model. Test 30 — Unauthorized rollback: Attempt to restore an earlier artifact using a deployment capability not authorizing the rollback operation. The applicable protected release predicate fails. The tests may employ mock AI coding agents, controlled source repositories, temporary package registries, test HSM interfaces, reproducible build fixtures, deployment simulators, container controllers, protected authorization-state services, release- verification hooks, and fault-injection mechanisms. The observed technical guarantees must be evaluated against the actual implemented trust and enforcement boundaries. 11.11.46. WF-11.46 — Claim-Specific Technical Support Enforcement Point 43 The workflow supports the proposed protected autonomous code- deployment architecture through: (a) AE-1101 generating software or infrastructure changes; Das Expires 19 April 2027 [Page 478] Internet-Draft Protected AI Execution Finality October 2026 (b) IM-1102 intercepting consequential release operations; (c) DC-1104 forming the Candidate Deployment Act Descriptor; (d) PED-1105 validating the applicable Supply-Chain Authority Object, approved purpose, workflow, changed-file scope, dependencies, privileged changes, test and review state, and release conditions; (e) EV-1108 generating or committing the required Deployment LAVR or ZK-LAVR; (f) CR-1109 releasing the Scoped Release Capability; and (g) FS-1111 verifying the capability before the governed release effect. Enforcement Point 44 WF-11.23 provides explicit binding of commit digest, artifact digest, repository identity, branch identity, deployment target, release environment, policy epoch, nonce, and expiry. Unauthorized artifact or target substitution causes release verification failure. Enforcement Point 45 WF-11.25 and WF-11.26 provide the protected HSM or secure-enclave signing-key variant. Protected key use remains dependent upon verification of the applicable Scoped Release Capability. Enforcement Point 46 WF-11.29 through WF-11.31 provide agent-generated skill, plugin, tool-package, and executable-artifact installation or activation finality. The applicable protected validation checks authorized purpose, approved tool graph, dependencies, privileged API use, and execution scope. Enforcement Point 47 Das Expires 19 April 2027 [Page 479] Internet-Draft Protected AI Execution Finality October 2026 WF-11.32 through WF-11.35 provide stage-associated protected validation evidence, scoped rollout capabilities, and withholding of subsequent-stage authorization when required runtime-drift, policy- state, or revocation predicates fail. 11.11.47. WF-11.47 — Technical Effect The disclosed workflow establishes a protected execution-finality dependency between: (a) generation of an AI-proposed software or deployment operation; (b) interception before the governed release boundary; (c) maintenance of the Candidate Deployment Act in a Non-Effective State; (d) construction of a machine-verifiable deployment descriptor; (e) authentication of the Supply-Chain Authority Object; (f) protected validation of authorized purpose, workflow, software modifications, privileges, dependencies, tests, scans, approvals, and target environment; (g) required protected deployment-state handling; (h) protected Deployment LAVR, ZK-LAVR, or equivalent validation- evidence commitment; (i) Scoped Release Capability availability; (j) independent verification of the actual artifact, commit, target, and release context at the designated Finality Sink; (k) controlled signing, publication, merge, activation, or deployment effectuation; (l) protected capability-use and recovery handling; and (m) stage-specific authorization of subsequent deployment progression. The system prevents an autonomous coding agent from treating successful code generation, possession of repository credentials, passing of preliminary tests, possession of a signing-service reference, or an earlier approval as sufficient authority to cause a governed production release. Das Expires 19 April 2027 [Page 480] Internet-Draft Protected AI Execution Finality October 2026 The stronger protected-signing embodiment withholds the relevant key- use authority until required protected release verification succeeds. The progressive-deployment embodiment prevents unauthorized advancement to a subsequent stage when mandatory runtime or policy conditions are no longer valid. The agent may generate code, artifacts, skills, and deployment plans, but the governed consequential operation becomes effective only upon satisfaction of its applicable protected execution-finality requirements. Computation is not authority to act. Code generation is not deployment authorization. Artifact possession is not signing authority. Approval of one release stage is not unrestricted authority for subsequent deployment. 11.12. WF-12 — Protected Cloud-Native Service-Mesh Execution, Sidecar- Proxy Finality, Workload-to-Service Authorization, Route-Bound Capabilities, and Non-Bypassable Cloud Effectuation 11.12.1. WF-12.1 — Technical Purpose This embodiment describes a computer-implemented protected execution- finality architecture for governing consequential operations generated by artificial-intelligence workloads operating within cloud-native, containerized, virtualized, serverless, microservice, or distributed computing environments. The system prevents a governed operation from producing an external network, service, application programming interface, message- delivery, or downstream workflow effect unless the applicable Protected Enforcement Domain (PED/CIED) validates the required authorization predicates, establishes required protected validation evidence, and releases or makes available a scoped Execution-Enabling Capability. The corresponding infrastructure-level Finality Sink verifies the scoped Execution-Enabling Capability against the operation actually presented for effectuation and the applicable workload, service, route, session, policy, revocation, freshness, and protected-state conditions. Das Expires 19 April 2027 [Page 481] Internet-Draft Protected AI Execution Finality October 2026 An artificial-intelligence workload may generate an API request, prepare an inter-service message, construct a database operation, select a downstream workflow, or produce an output payload. Such computation does not independently confer execution authority to transmit, forward, invoke, deliver, or commit the proposed operation. The proposed operation is classified as a Candidate Act and maintained in a Non-Effective State until the required protected execution-finality conditions succeed. The embodiment distinguishes: (a) computation and preparation within the AI workload; (b) infrastructure-level interception and mandatory mediation; (c) protected authorization outside unilateral workload control; (d) construction and validation of a Candidate Act Descriptor; (e) protected authorization-state handling and validation-evidence commitment; (f) issuance or availability of a scoped Execution-Enabling Capability; (g) independent verification at a service-mesh or cloud infrastructure Finality Sink; and (h) controlled effectuation or fail-closed refusal. The workflow is applicable to Kubernetes environments, container orchestration platforms, service meshes, API gateways, ingress and egress controllers, workload proxies, service-to-service communication systems, cloud network gateways, message-bus interfaces, serverless platforms, and other distributed execution environments. The disclosed architecture is not dependent upon a particular cloud provider, service-mesh vendor, container runtime, processor architecture, or communication protocol. 11.12.2. WF-12.2 — Participating Technical Components In one non-limiting implementation, the system comprises the following components. Das Expires 19 April 2027 [Page 482] Internet-Draft Protected AI Execution Finality October 2026 CW-1201 — Cloud AI Workload Execution Environment An artificial-intelligence agent, model, orchestration service, application process, container, pod, virtual machine, serverless runtime, or corresponding cloud-hosted execution environment configured to generate proposed consequential operations. IM-1202 — Infrastructure-Level Interception Component A service-mesh proxy, sidecar proxy, ingress controller, egress controller, API gateway, workload proxy, network policy enforcement point, or equivalent component configured to intercept governed operations before the relevant finality boundary. HQ-1203 — Non-Effective Operation Holding Mechanism A controlled staging mechanism retaining a proposed operation, immutable request representation, buffered payload, message, or authenticated operation reference pending protected authorization. DC-1204 — Cloud Candidate Act Descriptor Component A component configured to construct or verify a canonical machine- readable representation of the proposed operation and its effectuation-relevant context. WI-1205 — Workload Identity Verification Component A mechanism configured to establish the authenticated identity of the requesting workload, container, pod, service account, process, or corresponding execution context. SI-1206 — Destination Service Identity Component A mechanism configured to establish the destination service identity, authenticated endpoint, permitted service class, or other required destination identity. PED-1207 — Protected Enforcement Domain A protected component configured to validate authority predicates, maintain or verify protected state, generate or commit required validation evidence, and control release of scoped execution capabilities. AS-1208 — Protected Authorization-State Store Das Expires 19 April 2027 [Page 483] Internet-Draft Protected AI Execution Finality October 2026 A protected mechanism maintaining authority references, policy epochs, revocation epochs, nonce state, capability-consumption state, route permissions, validation commitments, and other mandatory authorization information. EV-1209 — Cloud Validation-Evidence Component A component configured to generate or commit an AVR, LAVR, authenticated validation record, sealed commitment, or equivalent protected validation evidence. CR-1210 — Execution-Enabling Capability Mechanism A protected component configured to generate, register, derive, release, activate, or otherwise make available a scoped Execution- Enabling Capability associated with the validated Candidate Act. FS-1211 — Cloud Infrastructure Finality Sink An enforcement-controlled proxy, gateway, network controller, service-mesh component, message interceptor, or equivalent interface configured to verify the scoped capability before permitting the governed effect. RM-1212 — Route and Session Verification Component A mechanism configured to verify applicable destination routes, source-to-destination service relationships, authenticated transport sessions, and route-consistency requirements. EF-1213 — Cloud Effectuation Interface The controlled interface through which the authorized operation produces its governed network, service, message, API, or downstream workflow consequence. OS-1214 — Protected Operation-Outcome Component A mechanism maintaining applicable operation-completion, denial, reservation, failure, revocation, and indeterminate-outcome information. SC-1215 — Cross-Component Authorization Consistency Mechanism A mechanism configured to verify required correspondence among the Candidate Act, workload identity, destination service identity, protected policy state, capability scope, network route, and Finality Sink. Das Expires 19 April 2027 [Page 484] Internet-Draft Protected AI Execution Finality October 2026 The components may be colocated, distributed among authenticated services, integrated into a protected gateway, or implemented within separate cloud infrastructure components. The PED, Finality Gate, and Finality Sink retain their distinguishable functional roles even when implemented within the same physical or virtualized component. 11.12.3. WF-12.3 — Establishment of the Cloud Workload Trust Boundary Before governed operations are processed, CW-1201 is configured so that it cannot independently cross the protected effectuation boundaries assigned to FS-1211. The cloud workload may perform computation, inference, data transformation, request construction, temporary storage, and internal preparation. However, it does not independently control the protected capability required for the governed external effect. In a container-based implementation, the workload may execute within a pod or container having restricted network interfaces and resource privileges. The environment may use: (a) container network isolation; (b) protected network-policy enforcement; (c) service-mesh traffic redirection; (d) controlled egress gateways; (e) restricted host networking; (f) operating-system or hypervisor-enforced routing controls; (g) authenticated service-to-service communication; (h) workload identity verification; and (i) protected authority services outside unilateral agent control. These mechanisms establish the intended interception relationship only when the actual implementation prevents unmediated alternative effectuation paths. Das Expires 19 April 2027 [Page 485] Internet-Draft Protected AI Execution Finality October 2026 Merely configuring an optional proxy does not establish non- bypassable enforcement if the workload retains another unrestricted route capable of producing the same governed consequence. 11.12.4. WF-12.4 — Identification of Governed Cloud Effectuation Boundaries The system identifies the classes of cloud operations requiring protected finality control. Non-limiting classes include: (a) outbound HTTP or HTTPS requests; (b) REST, GraphQL, RPC, or other API invocations; (c) service-to-service calls; (d) application programming interface responses that release governed data; (e) message-bus writes or message publication; (f) database requests; (g) downstream workflow invocations; (h) tool-service calls; (i) model-service requests; (j) authenticated inter-service communication; (k) cross-tenant data transfers; (l) outbound notifications; and (m) other externally effective cloud operations. Each governed effectuation class is associated with an applicable Finality Sink. A source-side network Finality Sink may control transmission from one workload. A receiving-side Finality Sink may separately control a database commit, message acceptance, or downstream business operation. Das Expires 19 April 2027 [Page 486] Internet-Draft Protected AI Execution Finality October 2026 The system does not automatically equate authorization of a network transmission with authorization of a later irreversible receiving- side effect. 11.12.5. WF-12.5 — Mandatory Interception and Path-Coverage Requirement The infrastructure identifies the execution paths through which CW-1201 can produce each governed effect. For each governed effectuation interface, the implementation requires either: (a) removal or technical restriction of paths that bypass the applicable Finality Sink; or (b) equivalent protected capability verification on every permitted path capable of producing the governed effect. An illustrative mandatory mediation condition is: For every governed effectuation interface e and every workload- accessible path p capable of reaching e, the governed effect may occur only after the required Finality Sink verification succeeds. The actual enforcement mechanism may use a controlled virtual network interface, mandatory workload proxy, hypervisor-managed networking, cloud gateway, network policy enforcement, or another suitable technical arrangement. The workload cannot establish unrestricted network transmission merely by selecting another library, executable, socket interface, network namespace, sidecar configuration, service endpoint, or direct connection path where such a route would bypass the required protected finality verification. This requirement is evaluated against the implementation's declared trust and threat model. 11.12.6. WF-12.6 — Candidate Cloud Act Generation CW-1201 generates or prepares a proposed consequential cloud operation. For example, an AI agent may prepare an authenticated service request to update an enterprise record. The proposed operation may identify: Das Expires 19 April 2027 [Page 487] Internet-Draft Protected AI Execution Finality October 2026 requesting_workload; destination_service; requested_operation; resource_identifier; request_parameters; payload_reference; credential_scope; network_route; policy_context. The operation is classified as Candidate Cloud Act CCA-1216. Generation of CCA-1216 does not authorize its transmission or downstream effectuation. The workload may construct the complete request, but the protected infrastructure controls whether it can cross the applicable finality boundary. 11.12.7. WF-12.7 — Infrastructure Interception Before Effectuation IM-1202 intercepts CCA-1216 before the governed consequential operation occurs. The interception mechanism may comprise: (a) a local sidecar proxy; (b) a service-mesh gateway; (c) an ingress or egress controller; (d) a cloud API gateway; (e) a network policy enforcement point; (f) a workload proxy; (g) a protected network forwarding controller; Das Expires 19 April 2027 [Page 488] Internet-Draft Protected AI Execution Finality October 2026 (h) a message-bus interceptor; or (i) an equivalent infrastructure-level mediation component. The interceptor receives the proposed operation or obtains a controlled representation of it. The operation is assigned an identifier and routed into the applicable holding mechanism. The requesting AI workload cannot treat mere acceptance by the interceptor as authorization for external effectuation. 11.12.8. WF-12.8 — Non-Effective Staging and Immutable Request Representation HQ-1203 places CCA-1216 into a Non-Effective State. An illustrative operation record comprises: operation_id; source_workload_id; source_container_id; requested_service_id; operation_class; request_reference; destination_reference; requested_route; policy_epoch; revocation_epoch; finality_sink_id; status = NON_EFFECTIVE. For requests containing mutable buffers, message bodies, or other effectuation-relevant parameters, the interception component may retain an immutable representation or authenticated digest. Das Expires 19 April 2027 [Page 489] Internet-Draft Protected AI Execution Finality October 2026 The system ensures that the operation subsequently presented for finality verification corresponds to the operation validated by the PED. A source workload cannot validate one request and substitute materially different mandatory parameters before transmission without causing a verification failure or renewed authorization. 11.12.9. WF-12.9 — Workload and Service Identity Establishment WI-1205 establishes the authenticated requesting workload identity. The identity may comprise: (a) an authenticated workload identity; (b) a service-account identity; (c) an authenticated container or pod identity; (d) a virtual-machine identity; (e) a protected process identity; (f) a verified service certificate identity; (g) a hardware-attested workload identity where required; or (h) an equivalent machine-verifiable execution identity. SI-1206 determines the intended destination service identity. Such identity may comprise an authenticated service name, certificate identity, service-discovery identity, endpoint identity, or other permitted service reference. The system distinguishes a caller-supplied service name from an identity authenticated by the actual infrastructure. Authentication of a workload or service does not independently establish authorization for every operation between those components. 11.12.10. WF-12.10 — Construction of the Candidate Cloud Act Descriptor DC-1204 constructs a canonical Candidate Act Descriptor for CCA-1216. An illustrative descriptor comprises: Das Expires 19 April 2027 [Page 490] Internet-Draft Protected AI Execution Finality October 2026 operation_id; source_workload_identity; source_container_identity; source_service_identity; destination_service_identity; destination_endpoint; operation_class; application_protocol; request_method; resource_path; request_payload_digest; authorized_network_route; transport_session_reference; authorized_behavioral_logic_class; purpose_class; policy_epoch; revocation_epoch; nonce; expiry; validation_record_requirement; finality_sink_identity. Only attributes required by the applicable Authority Object or specified embodiment are mandatory. The descriptor identifies the concrete operation and its required authorization context rather than granting general permission to the source workload. Das Expires 19 April 2027 [Page 491] Internet-Draft Protected AI Execution Finality October 2026 11.12.11. WF-12.11 — Canonical Descriptor Encoding In a cryptographic implementation, the descriptor is encoded using deterministic field representation. An illustrative expression is: Dcloud = Canon_v(W, S, OP, TARGET, ROUTE, SESSION, X, EPOCH, F) where: Dcloud denotes the canonical cloud operation descriptor; Canon_v denotes deterministic encoding under version v; W denotes the authenticated source workload identity; S denotes the destination service identity; OP denotes the requested operation and required parameters; TARGET denotes the destination endpoint or service target; ROUTE denotes the authorized network or service route; SESSION denotes applicable transport-session context; X denotes other mandatory execution-context information; EPOCH denotes applicable protected authorization-state versions; and F denotes the designated Finality Sink identity. An illustrative descriptor digest is: hCloud = H("DAS-CLOUD-ACT-v1" || Encode(Dcloud)) where H denotes a cryptographic hash function. The selected encoding defines field types, lengths, ordering, canonical identifiers, and treatment of absent or optional fields. The authorization component and Finality Sink employ corresponding interpretation rules. The specific encoding and digest algorithms are non-limiting implementation choices. Das Expires 19 April 2027 [Page 492] Internet-Draft Protected AI Execution Finality October 2026 11.12.12. WF-12.12 — Acquisition of Applicable Cloud Authority PED-1207 obtains the authenticated Authority Object applicable to CCA-1216. The Authority Object may identify: (a) permitted source workload identities; (b) permitted destination service identities; (c) authorized operation classes; (d) permitted resources and API methods; (e) approved behavioral-logic classes; (f) permitted purpose classes; (g) applicable tenant or jurisdictional scope; (h) authorized network routes; (i) required session authentication; (j) credential restrictions; (k) applicable policy epoch; (l) revocation requirements; (m) nonce, usage, or expiration conditions; and (n) required Finality Sink identity. The PED verifies the authenticity and current validity of the Authority Object. The requesting workload cannot independently widen the protected authority by modifying an ordinary application-side routing configuration or supplying its own unauthorized permission statement. 11.12.13. WF-12.13 — Behavioral-Logic and Runtime Validation Where required, PED-1207 validates the applicable Runtime Behavioral Descriptor (RBD), Algorithmic Logic Fingerprint (ALF), or corresponding approved behavioral-logic class. Das Expires 19 April 2027 [Page 493] Internet-Draft Protected AI Execution Finality October 2026 The validation may determine whether the proposed operation originates from: (a) an approved agent workflow; (b) an authorized tool class; (c) an approved service interaction; (d) a permitted API invocation; (e) an authorized runtime configuration; or (f) a computational process satisfying the required measured conditions. Where the approved purpose class is a mandatory predicate, the PED also verifies correspondence to the authorized purpose. A workload that has permission to invoke one service does not automatically acquire authority to invoke a different service or execute an unrelated operation class. ALF, AIF, and RBD are evaluated only where required by the applicable embodiment. They do not independently substitute for protected capability availability or Finality Sink verification. 11.12.14. WF-12.14 — Destination and Network-Route Validation PED-1207 validates the intended destination and route against the applicable Authority Object. The required checks may include: (a) destination service identity; (b) destination endpoint; (c) permitted network route; (d) source-to-destination service relationship; (e) application protocol; (f) requested operation class; Das Expires 19 April 2027 [Page 494] Internet-Draft Protected AI Execution Finality October 2026 (g) applicable destination restrictions; (h) service-discovery state; and (i) network-policy conditions. A proposed route to an authorized service does not authorize an arbitrary alternative destination. Where resolution, redirects, or service-discovery changes affect mandatory destination predicates, the actual effectuation path must satisfy those predicates. The detailed network canonicalization and destination-substitution procedures may employ the mechanisms described in WF-03. 11.12.15. WF-12.15 — Protected Authorization-Predicate Evaluation PED-1207 evaluates the required predicates associated with CCA-1216. For an illustrative conjunctive policy: Vcloud = Pworkload AND Pservice AND Poperation AND Proute AND Plogic AND Pstate where: Vcloud denotes the protected cloud authorization result; Pworkload verifies the required source workload identity; Pservice verifies the destination service identity; Poperation verifies the requested operation and its relevant parameters; Proute verifies the permitted network or service route; Plogic verifies the applicable approved behavioral-logic or purpose condition; and Pstate verifies required policy, revocation, freshness, usage, and protected-state conditions. Predicates not required by the applicable Authority Object may be omitted. Das Expires 19 April 2027 [Page 495] Internet-Draft Protected AI Execution Finality October 2026 Where an authorized threshold or alternative validation rule applies, the PED evaluates the corresponding protected combination. Failure of a mandatory predicate prevents release of the required execution authority. 11.12.16. WF-12.16 — Protected Authorization-State Handling Upon successful validation, PED-1207 performs the protected authorization-state operation required for the Candidate Cloud Act. Such operations may include: (a) verifying the applicable policy epoch; (b) validating current revocation state; (c) reserving an operation-specific grant; (d) consuming or registering a nonce; (e) updating a usage counter; (f) recording a validated service identity; (g) registering an authorized route; (h) reserving an execution capability; or (i) recording a protected validation-state reference. Where a single-use authorization is required, protected state prevents incompatible concurrent requests from independently consuming the same grant. Where a session or usage window authorizes multiple operations, the permitted number, duration, and scope of those operations remain bounded by the applicable authority. A failed mandatory protected-state transition prevents successful capability issuance. 11.12.17. WF-12.17 — Protected Cloud Validation-Evidence Commitment EV-1209 generates or commits the required protected validation evidence. Das Expires 19 April 2027 [Page 496] Internet-Draft Protected AI Execution Finality October 2026 The evidence may comprise an AVR, LAVR, sealed validation record, authenticated state commitment, or equivalent protected artifact. An illustrative validation record contains: receipt_id; candidate_act_id; descriptor_digest; source_workload_id; destination_service_id; authorized_route; authority_object_reference; validated_predicate_reference; policy_epoch; revocation_epoch; nonce; protected_state_transition; finality_sink_id; decision; protected_authentication. Where the embodiment requires pre-effectuation commitment, the validation evidence is committed before, or atomically with, capability availability. An ordinary proxy log recorded after transmission does not replace the protected authorization commitment when that commitment is a required finality dependency. The evidence may remain in protected storage and need not be immediately published to an external ledger. Das Expires 19 April 2027 [Page 497] Internet-Draft Protected AI Execution Finality October 2026 11.12.18. WF-12.18 — Protected Cloud-Finality Transaction The PED establishes the required relationship among successful predicate validation, protected-state handling, validation-evidence commitment, and scoped capability availability. An illustrative transaction is: (Snext, Rcloud, Ready) = CommitCloudFinality(Dcloud, A, Scurrent, F) where: Snext denotes the successfully committed protected authorization state; Rcloud denotes the corresponding protected validation evidence; Ready denotes the indication that the required authorization prerequisites have completed; Dcloud denotes the validated Candidate Cloud Act Descriptor; A denotes the authenticated Authority Object; Scurrent denotes the prior protected authorization state; and F denotes the designated cloud Finality Sink. The capability-release mechanism does not regard an incomplete mandatory transaction as successful authorization. Where the participating components cannot share one atomic storage transaction, the scoped capability remains unavailable until the required committed dependencies are verifiably established. 11.12.19. WF-12.19 — Scoped Execution-Enabling Capability Generation Following successful completion of the applicable protected finality transaction, CR-1210 generates or makes available a scoped Execution- Enabling Capability. The capability may contain or securely reference: capability_id; candidate_act_descriptor_digest; source_workload_identity; Das Expires 19 April 2027 [Page 498] Internet-Draft Protected AI Execution Finality October 2026 source_container_identity; destination_service_identity; authorized_operation; authorized_network_route; transport_session_binding; policy_epoch; revocation_epoch; nonce; expiry; usage_limit; protected_validation_record_digest; finality_sink_identity. In one illustrative signature-based implementation: Ccloud = Sign_skPED(Encode(hCloud, hR, W, S, Route, Session, Scope, Epoch, Rev, N, Expiry, F)) where: Ccloud denotes the scoped Execution-Enabling Capability; hCloud denotes the Candidate Act Descriptor digest; hR denotes the protected validation-record digest; W denotes the required source workload identity; S denotes the authorized destination service identity; Route denotes the applicable permitted route; Session denotes the required transport-session binding; Scope denotes the authorized operation scope; Epoch denotes the policy epoch; Das Expires 19 April 2027 [Page 499] Internet-Draft Protected AI Execution Finality October 2026 Rev denotes applicable revocation-state reference; N denotes the nonce; Expiry denotes the validity limit; and F denotes the designated Finality Sink. The particular representation may comprise a signature, MAC, sealed capability reference, protected capability-table entry, or equivalent protected execution-enablement mechanism. Possession of the capability representation does not independently authorize effectuation outside its enforced operation, workload, service, route, state, and sink bindings. 11.12.20. WF-12.20 — Source Workload and Service Identity Binding in the implementation described by enforcement point 59, the scoped capability is bound to one or more of the following: (a) source workload identity; (b) source container identity; (c) destination service identity; (d) authorized network route; (e) mutually authenticated transport session; (f) policy epoch; (g) revocation epoch; (h) nonce; and (i) protected validation-record digest. The applicable Finality Sink verifies the bindings required for the particular operation. Where source workload identity is mandatory, a different workload cannot use the same capability merely by presenting its bytes. Where destination service identity is mandatory, the capability cannot authorize transmission to another service. Das Expires 19 April 2027 [Page 500] Internet-Draft Protected AI Execution Finality October 2026 Where transport-session identity is mandatory, the capability is valid only within the authorized session conditions. The authorization remains subject to the actual protected-state and non-bearer verification requirements. 11.12.21. WF-12.21 — Mutually Authenticated Transport-Session Binding In a service-mesh implementation, the source workload and destination service may communicate over mutually authenticated TLS or an equivalent authenticated transport. The transport session provides evidence of the authenticated communicating identities under the selected trust model. The protected execution-finality system may additionally bind the scoped capability to the authenticated session or a protected session reference. A non-limiting session record comprises: session_id; source_service_identity; destination_service_identity; authenticated_peer_reference; session_generation; policy_epoch; session_freshness; authorized_operation_scope; finality_sink_id. Where the authorization requires a particular session, the Finality Sink verifies that the actual request belongs to the required authenticated session. An authenticated mTLS session does not independently authorize every application operation transmitted through that session. Das Expires 19 April 2027 [Page 501] Internet-Draft Protected AI Execution Finality October 2026 If the embodiment requires per-request authorization, each governed request must satisfy the applicable operation-specific capability conditions. 11.12.22. WF-12.22 — Capability Delivery to the Infrastructure Finality Sink The scoped capability may be delivered or made available to FS-1211 through: (a) an authenticated local IPC interface; (b) a protected sidecar-control interface; (c) an authenticated service-mesh control channel; (d) a protected capability-verification service; (e) a sealed capability table; (f) an authenticated proxy metadata channel; (g) a hardware-controlled network authorization entry; or (h) another supported protected mechanism. The receiving component verifies that the capability originates from the authorized protected authority mechanism. An agent-controlled request header or arbitrary application metadata is not treated as authoritative capability evidence merely because it contains a valid-looking identifier. The delivery mechanism preserves the required correspondence between the authorized Candidate Act and the operation subsequently presented at the Finality Sink. 11.12.23. WF-12.23 — Independent Cloud Finality Sink Verification Before transmission, forwarding, connection establishment, service invocation, or message delivery, FS-1211 independently verifies the required execution authority. The Finality Sink obtains or reconstructs the actual operation context. The verification may include: Das Expires 19 April 2027 [Page 502] Internet-Draft Protected AI Execution Finality October 2026 (a) capability authenticity; (b) Candidate Act Descriptor correspondence; (c) authenticated source workload identity; (d) source container identity where required; (e) destination service identity; (f) actual requested operation; (g) destination endpoint; (h) authorized network route; (i) transport-session binding; (j) applicable policy epoch; (k) revocation state; (l) nonce and expiry; (m) protected validation-record commitment; (n) capability usage state; and (o) Finality Sink identity. The Finality Sink refuses the operation if any mandatory verification condition fails. The verifier does not rely solely upon the AI workload's assertion that the operation has already been approved. 11.12.24. WF-12.24 — Cloud Finality Verification Predicate An illustrative Finality Sink authorization condition is: PermitCloud = Auth(C) AND Match(C,Dactual) AND WorkloadValid(C,Wactual) AND ServiceValid(C,Sactual) AND RouteValid(C,Ractual) AND StateValid(C,P) AND SinkValid(C,F) where: PermitCloud denotes permission to perform the governed cloud effect; Das Expires 19 April 2027 [Page 503] Internet-Draft Protected AI Execution Finality October 2026 C denotes the scoped Execution-Enabling Capability; Dactual denotes the actual operation descriptor; Wactual denotes the authenticated source workload identity; Sactual denotes the actual destination service identity; Ractual denotes the selected network or service route; P denotes the required current protected authorization state; and F denotes the applicable Finality Sink. Auth verifies capability authenticity. Match verifies required descriptor equality or authorized bounded- scope correspondence. WorkloadValid verifies the required source identity. ServiceValid verifies the permitted destination service. RouteValid verifies the authorized route. StateValid verifies mandatory policy, revocation, freshness, validation-record, and usage conditions. SinkValid verifies the intended Finality Sink identity. The governed effect is permitted only when all mandatory conditions succeed. 11.12.25. WF-12.25 — Controlled Service-Mesh Effectuation Upon successful Finality Sink verification, the infrastructure component permits only the operation authorized by the validated capability. Such effectuation may comprise: (a) establishing an authorized outbound mTLS connection; (b) forwarding a controlled API request; (c) transmitting an authorized API response; (d) routing a service-to-service request; Das Expires 19 April 2027 [Page 504] Internet-Draft Protected AI Execution Finality October 2026 (e) delivering an authorized message; (f) writing to an approved message-bus interface; (g) invoking an approved downstream workflow; or (h) forwarding another governed operation within its permitted scope. The Finality Sink does not grant unrestricted authority for additional operations outside the validated capability. Successful forwarding at the source boundary establishes the permitted source-side network effect, not necessarily completion of an independent downstream database or business transaction. 11.12.26. WF-12.26 — Service-Mesh Bypass Prevention in the implementation described by enforcement point 60, the cloud execution environment prevents the governed AI workload from transmitting a Candidate Act through an alternative direct network or service interface that bypasses required Finality Sink capability verification. In one container-based implementation, the workload lacks an unrestricted network route to governed destinations. An authorized sidecar or gateway is the controlled route to those destinations. The implementation additionally addresses direct host networking, unauthorized socket access, alternative network namespaces, bypassing the proxy through another service interface, and other accessible paths capable of producing the same governed effect. Where the platform permits multiple network paths, each path capable of producing the governed effect is either technically blocked or subjected to equivalent required capability verification. A process merely being configured to use a proxy does not establish non-bypassability. The system verifies path coverage through appropriate configuration inspection, negative testing, and enforcement-boundary evaluation. 11.12.27. WF-12.27 — Unauthorized Service Substitution A cloud workload may prepare a request for an approved destination service and subsequently attempt to redirect it to another service. Das Expires 19 April 2027 [Page 505] Internet-Draft Protected AI Execution Finality October 2026 Potential substitutions include: (a) changing the destination service identifier; (b) replacing the target endpoint; (c) changing the requested route; (d) selecting a different service-discovery result; (e) altering the authenticated destination identity; (f) redirecting traffic to a different tenant; (g) changing the API operation; or (h) reusing a connection for a different service. Where the substituted attribute forms part of a mandatory authorization binding, the existing capability is insufficient for the changed operation. The Finality Sink verifies the actual destination service or permitted service class before effectuation. If the new destination is outside the authorized scope, the operation is refused or requires renewed protected validation. 11.12.28. WF-12.28 — Route and Policy-State Mismatch in the implementation described by enforcement point 61, FS-1211 refuses an operation upon detecting a mandatory route or policy inconsistency. Relevant conditions include: (a) expired capability; (b) revoked authority; (c) unauthorized service substitution; (d) source-workload mismatch; (e) destination mismatch; (f) replay condition; or Das Expires 19 April 2027 [Page 506] Internet-Draft Protected AI Execution Finality October 2026 (g) route inconsistent with the authorized execution scope. The Finality Sink evaluates the corresponding mandatory capability and protected-state bindings. An otherwise valid capability does not authorize a route that violates its required network or service restrictions. Where current policy-epoch verification is mandatory, a capability bound to an incompatible superseded epoch does not authorize further effectuation. Where required revocation state is unavailable or unverifiable, the operation remains non-effective. 11.12.29. WF-12.29 — Multi-Hop Service Invocation In a distributed cloud workflow, one authorized service request may initiate additional service-to-service operations. For example: Service A may invoke Service B. Service B may invoke Service C. Service C may request a database commit. The initial capability may authorize the A-to-B operation without independently authorizing every downstream operation. Where the application requires separate protected finality at subsequent boundaries, each downstream operation is treated as a distinct Candidate Act or as an expressly bounded authorized continuation. The receiving service or downstream Finality Sink verifies the capability applicable to its own consequential operation. The system does not assume that a valid source-side transmission capability establishes authorization for an unrelated later storage commit, payment, credential application, or infrastructure mutation. 11.12.30. WF-12.30 — Message-Bus and Asynchronous Workflow Control In an asynchronous cloud embodiment, the Candidate Act may comprise a message publication or downstream workflow dispatch. Das Expires 19 April 2027 [Page 507] Internet-Draft Protected AI Execution Finality October 2026 The message-bus producer submits the proposed operation to an enforcement-controlled interface. The corresponding descriptor may bind: (a) producer workload identity; (b) destination topic or queue; (c) message class; (d) message payload digest; (e) authorized recipient or consumer class; (f) policy epoch; (g) freshness conditions; and (h) the designated publication Finality Sink. The Finality Sink verifies the scoped capability before permitting the governed message publication. Where a consumer later performs a separate consequential action, the consumer-side effectuation boundary may require its own protected authorization. Publication of a message does not automatically establish that the receiving application is authorized to commit every downstream operation represented by that message. 11.12.31. WF-12.31 — Continuous Service Sessions and Rolling Capabilities For long-running AI workloads, the system may process multiple governed service requests within one authenticated session. The applicable authority may permit: (a) per-request capabilities; (b) per-message capabilities; (c) bounded session capabilities; (d) scoped transfer-window capabilities; or Das Expires 19 April 2027 [Page 508] Internet-Draft Protected AI Execution Finality October 2026 (e) limited multi-use service-operation capabilities. Each authorization form remains subject to its defined operation, workload, service, route, usage, and freshness conditions. Where per-operation validation is mandatory, an earlier allowed request does not authorize an unrelated subsequent request merely because both share the same mTLS connection. The PED may update protected validation evidence for successive authorized operations. If a mandatory runtime, policy, revocation, or route condition becomes invalid, the PED withholds further affected capabilities or the Finality Sink rejects their use. 11.12.32. WF-12.32 — Capability Consumption and Replay Protection Where the applicable capability is single-use or usage-bounded, FS-1211 performs or coordinates the required protected usage-state operation. A representative capability-state record comprises: capability_id; candidate_act_digest; authorized_source_workload; authorized_destination_service; authorized_route; usage_limit; remaining_uses; protected_state_version; status. A single-use capability is prevented from authorizing another incompatible consequential operation after valid consumption. A replayed capability is rejected when its protected usage state no longer permits effectuation. Das Expires 19 April 2027 [Page 509] Internet-Draft Protected AI Execution Finality October 2026 Where multiple uses are expressly authorized, the applicable counter, window, or session restrictions remain enforceable. The selected implementation determines how consumption is coordinated across distributed proxy instances. 11.12.33. WF-12.33 — Distributed Service-Mesh State Consistency Where different proxies, gateways, protected authorities, or Finality Sinks participate in the same operation, the system maintains the required consistency of authorization information. Such information may include: (a) Candidate Act identity; (b) source workload identity; (c) destination service identity; (d) authorized route; (e) policy epoch; (f) revocation epoch; (g) validation-record digest; (h) capability identifier; (i) protected usage state; and (j) designated Finality Sink. The participating components exchange authenticated commitments or consult protected state sufficient to establish the required correspondence. Where required consistency cannot be established, the affected operation remains blocked. The architecture does not assume that globally instantaneous synchronization or one distributed database transaction is necessary for every deployment. The actual implementation provides consistency appropriate to its claimed authorization and effectuation guarantees. Das Expires 19 April 2027 [Page 510] Internet-Draft Protected AI Execution Finality October 2026 11.12.34. WF-12.34 — Policy Updates and Revocation During Runtime During an active cloud-agent session, protected policy state may change. Examples include: (a) revocation of an agent's service permission; (b) removal of a permitted destination service; (c) restriction of an authorized network route; (d) withdrawal of a credential scope; (e) invalidation of an approved workflow; (f) expiry of a service authorization; (g) workload identity revocation; and (h) update of the applicable protected policy epoch. PED-1207 updates or consults the corresponding protected authorization state. Where the changed condition is mandatory for the operation, an earlier capability cannot independently authorize effectuation under incompatible current state. The Finality Sink verifies the current conditions required by the applicable authorization. A live network-policy update and an operation-specific protected capability check are distinguishable mechanisms. Updating a policy does not itself establish that a particular Candidate Act has obtained valid finality authorization. 11.12.35. WF-12.35 — Credential and Privileged Connector Integration Where the service-mesh operation requires protected credential application, the request may be routed through an authorized credential broker or privileged connector. The workload may possess only a restricted credential reference. Das Expires 19 April 2027 [Page 511] Internet-Draft Protected AI Execution Finality October 2026 The corresponding protected authorization determines whether the actual credential-mediated operation is permitted. Where a separate credential-effectuation Finality Sink is required, that boundary verifies the applicable capability before protected credential use. The service-mesh Finality Sink may separately verify the authorization required for network transmission. The credential broker cannot independently enlarge the permitted service operation merely because it possesses a reusable credential. The detailed protected grant-state and connector mechanisms may be implemented as described in WF-04 and WF-05. 11.12.36. WF-12.36 — Crash, Retry, and Incomplete Service Effectuation The system maintains fail-closed behavior across applicable cloud infrastructure failures. Interception failure: An unavailable mandatory interception component does not create authorization to use an uncontrolled alternate path. PED failure: The Candidate Act remains non-effective if required protected authorization cannot be established. Evidence-commitment failure: No valid corresponding capability becomes available when mandatory commitment has failed. Capability-delivery failure: The protected system consults committed state before determining whether an existing capability can be recovered or retired. Proxy failure before transmission: The system determines whether the proposed operation remains eligible for authorized continuation. Failure after possible transmission: The operation may enter an indeterminate completion state when downstream delivery or execution cannot be established. A timeout does not necessarily prove that the downstream service failed to perform the operation. The system does not automatically replay an operation when doing so could cause an unauthorized duplicate consequence. Das Expires 19 April 2027 [Page 512] Internet-Draft Protected AI Execution Finality October 2026 Where available, authenticated operation identifiers, downstream idempotency services, completion receipts, or receiving-side Finality Sinks may support reconciliation. 11.12.37. WF-12.37 — Illustrative Cloud-Native Service-Mesh Implementation In one concrete implementation, an AI agent executes within a Kubernetes pod. The agent prepares an HTTPS request to an approved internal enterprise service. The pod is configured so that the governed outbound request must pass through an enforcement-controlled service-mesh sidecar or egress gateway. The request is intercepted and maintained in a pending, Non-Effective State. DC-1204 constructs a canonical descriptor identifying the source workload, source container, authenticated destination service, requested HTTP operation, target resource, payload digest, authorized route, policy epoch, nonce, and designated Finality Sink. PED-1207 obtains the applicable Authority Object. The PED validates the required workload, destination, operation, approved workflow, route, policy, revocation, and freshness predicates. The protected mechanism performs the required authorization-state operation and commits a corresponding AVR, LAVR, or equivalent protected validation record. CR-1210 then makes available a scoped Execution-Enabling Capability. The sidecar or egress gateway obtains the actual operation and verifies its correspondence with the capability. If the required predicates succeed, the controlled interface forwards the approved request. If the destination service, source workload, required route, or policy state differs from the authorized context, the operation is refused. Das Expires 19 April 2027 [Page 513] Internet-Draft Protected AI Execution Finality October 2026 The AI workload cannot transmit the prohibited request through an accessible alternate path that bypasses mandatory verification. This illustrates infrastructure-level control of the transition from AI computation to cloud service effectuation. 11.12.38. WF-12.38 — Illustrative Service Substitution Attack An AI workload receives permission to invoke an approved documentation-retrieval service. The authorized capability identifies the permitted service identity and operation scope. The workload subsequently attempts to use the same capability to transmit information to a different internal service. The infrastructure Finality Sink authenticates the actual destination identity. The destination does not satisfy the capability's mandatory service binding. The request is refused. The earlier approval remains insufficient because the proposed externally effective operation differs from the validated operation. 11.12.39. WF-12.39 — Illustrative Alternative Network-Path Attack An agent executes in a container whose normal application traffic is routed through a protected service-mesh proxy. The agent attempts to bypass the proxy by invoking a different networking interface or using another available execution route. In the specified non-bypassable implementation, the alternative route is either inaccessible or controlled by an equivalent required Finality Sink. The unverified operation therefore cannot produce the governed network effect. If an unrestricted bypass path remains accessible and can effectuate the governed operation, the implementation does not satisfy the specified bypass-prevention guarantee. Das Expires 19 April 2027 [Page 514] Internet-Draft Protected AI Execution Finality October 2026 This test distinguishes mere proxy deployment from mandatory execution-finality mediation. 11.12.40. WF-12.40 — Alternative Technical Implementations The protected cloud-native architecture may be implemented through different infrastructure arrangements. Sidecar implementation: A sidecar proxy intercepts governed service traffic and verifies the applicable capability. Service-mesh gateway implementation: A shared gateway performs the controlled effectuation function for multiple workloads. Ingress-controller implementation: An ingress component verifies protected authorization before admitting a governed service invocation. Egress-controller implementation: A controlled egress interface verifies the required capability before allowing outbound transmission. API-gateway implementation: An API gateway verifies the capability against the actual operation and service identity. Workload-proxy implementation: A protected proxy associated with an individual workload enforces authorized destinations and operations. Message-bus implementation: A controlled message-publication interface prevents unauthorized message delivery. Cloud-network-controller implementation: An infrastructure-controlled forwarding component enforces scoped network capability conditions. Hardware-assisted implementation: A SmartNIC, DPU, or other protected network device enforces the required forwarding authorization for the governed network effect. Single-node implementation: One protected node performs authorization, state handling, evidence commitment, capability release, and local Finality Sink verification. Distributed implementation: The PED and Finality Sink operate on separate authenticated nodes. The choice of deployment substrate does not remove the requirement for actual control over the governed effectuation path. Das Expires 19 April 2027 [Page 515] Internet-Draft Protected AI Execution Finality October 2026 11.12.41. WF-12.41 — Failure and Fail-Closed Conditions The system refuses the governed cloud operation when any mandatory condition is absent, invalid, expired, revoked, inconsistent, replayed, or unverifiable. Non-limiting denial conditions include: (a) unavailable required interception; (b) invalid Candidate Act Descriptor; (c) missing Authority Object; (d) source workload identity mismatch; (e) source container mismatch where required; (f) unauthorized destination service; (g) unauthorized operation class; (h) invalid behavioral-logic condition; (i) unauthorized network route; (j) invalid mTLS session binding where required; (k) stale policy epoch; (l) invalid revocation state; (m) expired capability; (n) replayed nonce; (o) exhausted capability usage; (p) failed protected-state transition; (q) failed validation-evidence commitment; (r) missing Execution-Enabling Capability; (s) invalid capability authentication; (t) Finality Sink mismatch; Das Expires 19 April 2027 [Page 516] Internet-Draft Protected AI Execution Finality October 2026 (u) route substitution; (v) service substitution; or (w) inability to establish required current authorization conditions. The operation may remain held, be denied, be quarantined, or be submitted to a separately authorized review procedure. No mandatory failure condition creates unrestricted fallback authority. 11.12.42. WF-12.42 — PHOSITA Verification and Negative Tests A person having ordinary skill in cloud security, service-mesh engineering, container orchestration, network policy, distributed authorization, cryptography, or protected execution may verify the architecture through controlled tests. Test 1 — Authorized service request: Submit a request matching all required protected identity, operation, route, state, and capability bindings. The Finality Sink permits the scoped operation. Test 2 — Missing capability: Present a governed request without the required Execution-Enabling Capability. The Finality Sink refuses effectuation. Test 3 — Source workload substitution: Reuse a capability through another workload where workload identity is mandatory. Verification fails. Test 4 — Container identity mismatch: Present the capability from an incompatible container context where that binding is required. The operation is refused. Test 5 — Service identity substitution: Redirect the operation to another destination service. Required service identity verification fails. Test 6 — Route substitution: Change the requested network route to one outside the permitted authorization scope. The Finality Sink refuses the request. Test 7 — mTLS session mismatch: Attempt to reuse a session-bound capability through an incompatible authenticated transport session. Verification fails. Das Expires 19 April 2027 [Page 517] Internet-Draft Protected AI Execution Finality October 2026 Test 8 — Expired capability: Present the capability after its validity interval. The operation remains non-effective. Test 9 — Revocation: Revoke a mandatory authorization condition before effectuation. The affected request is refused. Test 10 — Policy epoch mismatch: Advance the required policy epoch and present an incompatible earlier capability. The Finality Sink refuses the operation. Test 11 — Replay: Re-present a consumed single-use capability. Protected usage-state verification fails. Test 12 — Direct network bypass: Attempt to transmit the governed operation outside the designated proxy. The route is blocked or subjected to equivalent finality verification. Test 13 — Unauthorized host network: Attempt to access unrestricted host networking from the workload. The governed effect remains subject to the required enforcement boundary. Test 14 — Alternative service interface: Attempt the same consequential service operation through another accessible interface. The implementation prevents unmediated effectuation. Test 15 — Request mutation: Change a mandatory application operation or payload parameter after protected validation. Actual-operation correspondence fails. Test 16 — Destination resolution change: Substitute an unauthorized destination during connection establishment. The applicable destination predicate fails. Test 17 — Session reuse: Reuse an authenticated connection for an operation outside the permitted scope. The subsequent operation is refused. Test 18 — Concurrent capability use: Attempt concurrent use of a single-use authorization. Protected state prevents unauthorized duplicate consumption. Test 19 — PED failure: Make the required protected authorization component unavailable. The governed operation remains blocked. Test 20 — Proxy failure: Disable the mandatory proxy component. The system does not enable an unprotected alternative route. Das Expires 19 April 2027 [Page 518] Internet-Draft Protected AI Execution Finality October 2026 Test 21 — Evidence failure: Interrupt required validation-evidence commitment. No valid corresponding capability is made available. Test 22 — Unauthorized service-to-service continuation: Authorize one service call and attempt an unrelated downstream operation without its separately required authority. The corresponding downstream Finality Sink refuses the operation. Test 23 — Message-bus publication: Attempt publication to a topic outside the permitted scope. Protected finality verification fails. Test 24 — Credential scope substitution: Attempt to apply a credential outside the validated service and operation scope. The governed credential or network effect is refused. Test 25 — Multi-tenant scope mismatch: Present a capability bound to another tenant where tenant identity is a mandatory authorization condition. Verification fails. Test 26 — Crash after possible delivery: Interrupt a request after potential downstream receipt. Recovery records or reconciles the uncertain outcome rather than automatically creating another unrestricted execution attempt. Test 27 — Distributed authorization consistency: Issue a capability at one protected authority node and verify it at another node. The Finality Sink rejects inconsistent mandatory policy, state, or operation bindings. Test 28 — Single-node verification: Implement the authorization and Finality Sink functions within one protected node and verify that the governed operation still cannot bypass required capability-dependent effectuation. Test 29 — Service-mesh configuration tampering: Attempt to modify ordinary routing configuration to create an unauthorized path. The protected infrastructure prevents the governed effect from bypassing finality verification. Test 30 — Receiving-side consequence distinction: Permit an authorized source-side transmission while withholding separate authorization required for a downstream database commit. The receiving-side operation remains non-effective. Das Expires 19 April 2027 [Page 519] Internet-Draft Protected AI Execution Finality October 2026 The tests may be implemented using controlled cloud workloads, test containers, temporary service meshes, mock authenticated services, programmable network routes, synthetic message-bus endpoints, protected authorization-state services, network fault injection, policy-state changes, and capability-verification instrumentation. The tests establish only those guarantees demonstrated by the particular implementation and its defined threat model. 11.12.43. WF-12.43 — Claim-Specific Technical Support Enforcement Point 58 — Protected Service-Mesh Effectuation System The workflow describes: (a) CW-1201 hosting the cloud AI workload; (b) IM-1202 providing infrastructure-level interception through a service-mesh proxy, sidecar proxy, gateway, or equivalent controller; (c) interception of service, API, network, message-bus, database- request, or downstream workflow operations before governed effectuation; (d) PED-1207 validating Candidate Act Descriptor, workload identity, service identity, authorized destination, route, approved behavioral logic, policy state, and revocation state; (e) EV-1209 establishing protected validation evidence; (f) CR-1210 releasing the scoped Execution-Enabling Capability; and (g) FS-1211 verifying that capability before permitting the governed operation. Enforcement Point 59 — Service Identity and Session Binding WF-12.20 and WF-12.21 provide explicit capability binding to the required workload, container, destination service, route, authenticated transport session, policy epoch, revocation epoch, nonce, and validation-record reference. Enforcement Point 60 — Service-Mesh Bypass Prevention WF-12.3 through WF-12.5 and WF-12.26 provide mandatory interception and alternative-path prevention. Das Expires 19 April 2027 [Page 520] Internet-Draft Protected AI Execution Finality October 2026 The implementation blocks or equivalently mediates accessible paths capable of producing the same governed effect. Enforcement Point 61 — Fail-Closed Route and Policy Mismatch WF-12.27 and WF-12.28 provide refusal conditions for expired capability, revoked authority, unauthorized service substitution, source-workload mismatch, destination mismatch, replay, and route inconsistency. 11.12.44. WF-12.44 — Technical Effect The workflow establishes a protected execution-finality relationship between: (a) an AI workload generating a Candidate Act; (b) mandatory cloud infrastructure interception; (c) maintenance of the operation in a Non-Effective State; (d) construction of a canonical Candidate Act Descriptor; (e) authenticated workload and destination-service identity; (f) protected validation of operation, behavior, destination, route, policy, revocation, and freshness predicates; (g) required protected-state handling; (h) protected validation-evidence commitment; (i) scoped Execution-Enabling Capability availability; (j) independent Finality Sink verification against the actual cloud operation; (k) controlled transmission, forwarding, service invocation, or message delivery; and (l) fail-closed withholding when any mandatory authorization condition fails. The architecture prevents a cloud-hosted AI workload from converting mere service identity, network connectivity, possession of a credential, membership in a service mesh, or ordinary application permission into unrestricted authority to produce a governed consequential operation. Das Expires 19 April 2027 [Page 521] Internet-Draft Protected AI Execution Finality October 2026 The same protected finality principle may be implemented through a sidecar, gateway, service mesh, network controller, API proxy, message interceptor, or another infrastructure enforcement component, provided the actual effectuation path is controlled. A service-mesh proxy is not automatically a protected Finality Sink merely because it forwards traffic. The required security property arises when the infrastructure component cannot permit the governed operation without verifying the applicable scoped Execution-Enabling Capability and mandatory protected authorization conditions. Computation is not authority to act. Service authentication is not authorization of every service operation. Network connectivity is not authority to produce an external effect. An upstream policy decision does not replace the required Finality Sink verification. 11.13. WF-13 — Protected Pre-Computation Model Admission, Algorithmic Logic Fingerprint Verification, Runtime Behavioral Governance, Model-Loader Authorization, and Separate Downstream Execution Finality 11.13.1. WF-13.1 — Technical Purpose This embodiment describes a computer-implemented protected computation-admission architecture configured to govern whether a proposed artificial-intelligence computation may enter a designated model-execution environment. The system controls proposed inference operations, agent requests, tool-enabled model computations, retrieval-enabled invocations, memory-enabled computations, model-loading operations, and other governed computation-start events. The technical objective is to prevent a requesting agent, application, orchestration component, or model client from initiating a governed model computation merely because it possesses an application programming interface credential, authenticated session, service permission, or general authorization to access a computing platform. Das Expires 19 April 2027 [Page 522] Internet-Draft Protected AI Execution Finality October 2026 A proposed computation request is classified as a Candidate Computation Admission Act and retained in a Pending Admission State. The request does not cross the governed computation-admission boundary unless a Protected Governance Domain validates the applicable computation context against an Approved Algorithmic Logic Fingerprint Condition and makes available a corresponding computation-start authorization artifact. The admission component verifies the artifact against the actual proposed computation and applicable protected state. This embodiment distinguishes: (a) authentication of the requesting client; (b) authorization of the proposed computation; (c) integrity and approval of the selected model, workflow, and configuration; (d) issuance or validation of computation-start authority; (e) verification at the computation-admission boundary; (f) runtime behavioral governance following admission; and (g) separate authorization of consequential external operations generated by the admitted computation. Authorization to begin computation does not automatically confer authority to produce an externally effective tool call, network transmission, credential use, file modification, financial operation, deployment, or physical actuation. The architecture is applicable to model-serving systems, inference gateways, AI orchestration platforms, autonomous-agent runtimes, protected model loaders, accelerator runtimes, retrieval-augmented generation systems, enterprise model services, and other AI computing environments. 11.13.2. WF-13.2 — Participating Technical Components In one non-limiting implementation, the system comprises the following components. CE-1301 — Computation Requesting Environment Das Expires 19 April 2027 [Page 523] Internet-Draft Protected AI Execution Finality October 2026 A requesting application, AI agent, model client, orchestrator, service, workflow, or other component configured to propose a governed computation. RA-1302 — Request Admission Component An enforcement-controlled interface positioned between CE-1301 and a designated model-execution service, configured to intercept proposed computation requests before the governed computation-start boundary. HQ-1303 — Pending Admission Holding Mechanism A controlled staging facility maintaining a proposed computation request or authenticated representation in a Pending Admission State. DC-1304 — Governed Computation-Context Descriptor Component A mechanism configured to construct or verify a machine-readable representation of the proposed computation request and its relevant model, policy, workflow, purpose, and execution context. PGD-1305 — Protected Governance Domain A protected authorization environment configured to authenticate applicable authority information, evaluate the Approved Algorithmic Logic Fingerprint Condition, validate required protected state, and control computation-start authorization. PGD-1305 may constitute a Protected Enforcement Domain (PED) or a Cryptographically Isolated Enforcement Domain (CIED), according to the particular security requirements. ALF-1306 — Approved Algorithmic Logic Fingerprint Verification Component A protected or authenticated mechanism configured to determine whether the proposed model, workflow, execution configuration, or logic class satisfies the required approved ALF condition. AS-1307 — Protected Computation Authority Store A protected or authenticated mechanism maintaining approved model identities, ALF conditions, policy epochs, revocation information, workload permissions, authorized computation scopes, and other required authority state. EV-1308 — Computation Validation-Evidence Component Das Expires 19 April 2027 [Page 524] Internet-Draft Protected AI Execution Finality October 2026 An optional or required protected mechanism, according to the particular embodiment, configured to generate or commit computation- admission evidence. CR-1309 — Computation-Start Authorization Component A protected mechanism configured to generate, derive, validate, register, or make available the computation-start authorization artifact. MA-1310 — Model Admission Finality Sink An enforcement-controlled interface configured to verify the computation-start authorization artifact before permitting the governed computation to begin. ML-1311 — Model Loader and Runtime Activation Component A model loader, model registry interface, checkpoint loader, adapter loader, accelerator-runtime initializer, or equivalent component controlling admission of the approved model state into the governed computation environment. RB-1312 — Runtime Behavioral Measurement Component A mechanism configured to collect or construct a Runtime Behavioral Descriptor (RBD) or other applicable runtime observations after admission or during a permitted computation. EF-1313 — Downstream Execution-Finality Subsystem A separately applicable protected finality arrangement configured to govern externally effective Candidate Acts generated by an admitted computation. OS-1314 — Protected Computation Outcome-State Component A mechanism maintaining admission decisions, protected state, denial conditions, authorization usage, revocation, and applicable computation-outcome information. The components may be colocated or distributed across protected software services, model-serving gateways, confidential computing environments, secure enclaves, hardware controllers, or other suitable execution substrates. Das Expires 19 April 2027 [Page 525] Internet-Draft Protected AI Execution Finality October 2026 11.13.3. WF-13.3 — Establishment of the Computation Admission Boundary Before a governed model computation begins, the system establishes a technical admission boundary between the requesting component and the corresponding model-execution service. The admission boundary may be positioned at: (a) a model-serving gateway; (b) an inference request broker; (c) a protected model loader; (d) an authenticated model registry; (e) an accelerator-runtime initializer; (f) a checkpoint-loading interface; (g) an adapter activation interface; (h) a protected orchestration service; (i) a model-compute scheduling interface; or (j) an equivalent computation-admission point. Where the model-execution service is governed by mandatory pre- computation authorization, the requesting environment cannot independently bypass the admission component using another accessible model-loading, inference, or compute-initialization path. A model-serving endpoint that merely performs optional application- level checks does not establish non-bypassable admission when an alternative unrestricted execution path remains available. The actual implementation identifies the computation-start interfaces within the protected admission scope and controls their effectuation. 11.13.4. WF-13.4 — Identification of Governed Computation-Start Events The system identifies computation events that require protected admission. Such events may include: (a) initiating an inference request; Das Expires 19 April 2027 [Page 526] Internet-Draft Protected AI Execution Finality October 2026 (b) invoking an agentic model workflow; (c) loading a protected model checkpoint; (d) activating an adapter or model extension; (e) beginning a tool-enabled model computation; (f) initiating retrieval-enabled inference; (g) initiating memory-enabled inference; (h) activating a model-serving runtime; (i) selecting an approved model variant; (j) allocating governed accelerator execution resources; or (k) another defined computation-start event. The protected policy determines which operations are subject to admission control. An operation that has already begun computation cannot be described as prevented at computation start merely because a subsequent runtime check rejects its later output. Pre-computation admission and downstream execution-finality control are therefore separate, identifiable functions. 11.13.5. WF-13.5 — Generation of the Candidate Computation Admission Act CE-1301 generates or submits a proposed computation request. The request may contain: request_id; requesting_client_identity; agent_identity; requested_model; requested_model_version; proposed_workflow; Das Expires 19 April 2027 [Page 527] Internet-Draft Protected AI Execution Finality October 2026 authorized_purpose_reference; tool_configuration; retrieval_configuration; memory_configuration; policy_context; requested_compute_endpoint; session_context. The proposed operation is classified as Candidate Computation Admission Act CCA-1315. The request represents an intention to initiate computation but does not independently establish the protected authority required to begin the governed operation. 11.13.6. WF-13.6 — Pending Admission State RA-1302 intercepts CCA-1315 before the corresponding computation- start effect. The request is placed into HQ-1303. An illustrative pending admission record comprises: operation_id; requesting_identity; requested_model_reference; requested_workflow_reference; computation_context_reference; requested_compute_endpoint; policy_epoch; nonce; created_at; Das Expires 19 April 2027 [Page 528] Internet-Draft Protected AI Execution Finality October 2026 status = PENDING_ADMISSION. The request remains pending until the required computation-start authorization conditions are satisfied. An application-layer timeout, operator preference, orchestration approval, or permissive fallback does not independently establish protected computation-start authority. If a mandatory authorization condition cannot be established, the admission component refuses or continues holding the requested computation. 11.13.7. WF-13.7 — Governed Computation-Context Descriptor DC-1304 constructs a Governed Computation-Context Descriptor representing the proposed computation request. The descriptor identifies at least the requested model or model class, applicable execution purpose, proposed workflow or policy context, and the protected computation-admission boundary. Additional fields may include: requesting_agent_identity; tenant_identity; model_identifier; model_version; checkpoint_digest; adapter_digest; workflow_class; tool_policy_reference; retrieval_policy_reference; memory_policy_reference; safety_policy_reference; authorized_purpose; Das Expires 19 April 2027 [Page 529] Internet-Draft Protected AI Execution Finality October 2026 jurisdiction_condition; requested_compute_endpoint; authorized_destination_context; policy_epoch; revocation_epoch; nonce; expiry; admission_sink_identity. The particular claim and Authority Object determine which additional fields are mandatory. The descriptor is distinguishable from the computation request itself and from the computation-start authorization artifact. 11.13.8. WF-13.8 — Canonical Computation Descriptor Formation In an illustrative cryptographic implementation, the computation descriptor is encoded deterministically. A non-limiting representation is: Dcompute = Canon_v(ID, MODEL, WORKFLOW, PURPOSE, POLICY, CONTEXT, EPOCH, SINK) where: Dcompute denotes the canonical computation-context descriptor; Canon_v denotes deterministic encoding under version v; ID denotes the requesting identity or workload context; MODEL denotes the requested model and required model measurements; WORKFLOW denotes the proposed computational workflow; PURPOSE denotes the authorized execution purpose; POLICY denotes the applicable tool, retrieval, memory, and safety- policy context; Das Expires 19 April 2027 [Page 530] Internet-Draft Protected AI Execution Finality October 2026 CONTEXT denotes required runtime and computation-environment parameters; EPOCH denotes the protected policy or authorization-state version; and SINK denotes the designated computation-admission boundary. An illustrative descriptor digest is: hCompute = H("DAS-COMPUTE-v1" || Encode(Dcompute)) where H denotes an approved cryptographic hash function and Encode denotes the selected deterministic serialization. The particular hash function, encoding procedure, and domain- separation label are implementation choices. Where exact descriptor correspondence is required, the authorizing component and admission verifier employ compatible field definitions and canonicalization rules. 11.13.9. WF-13.9 — Acquisition of Applicable Computation Authority PGD-1305 obtains the applicable authority information from AS-1307 or another authenticated authority source. The authority may define: (a) authorized requesting clients; (b) permitted model identities; (c) approved model versions; (d) approved checkpoint or adapter state; (e) permitted ALF conditions; (f) authorized workflow classes; (g) permitted computation purpose; (h) tool and retrieval restrictions; (i) memory-access conditions; (j) required safety-policy configuration; Das Expires 19 April 2027 [Page 531] Internet-Draft Protected AI Execution Finality October 2026 (k) jurisdiction or tenant restrictions; (l) policy and revocation requirements; (m) nonce or usage restrictions; and (n) permitted computation-admission boundaries. The Protected Governance Domain verifies the required authenticity, scope, and current validity of the authority information. A requesting application cannot independently create protected authorization merely by naming a permitted model or presenting a self-declared approved configuration. 11.13.10. WF-13.10 — Approved Algorithmic Logic Fingerprint Condition ALF-1306 evaluates whether the proposed computation context satisfies the applicable Approved Algorithmic Logic Fingerprint Condition. The ALF may represent an approved: (a) model identity; (b) model checkpoint; (c) adapter configuration; (d) orchestration workflow; (e) tool-access graph; (f) retrieval policy; (g) memory policy; (h) safety-policy configuration; (i) computational pipeline; or (j) approved class of algorithmic behavior. The Protected Governance Domain determines whether the proposed configuration corresponds to an approved fingerprint, measurement, or permitted logic class. Das Expires 19 April 2027 [Page 532] Internet-Draft Protected AI Execution Finality October 2026 ALF validation may use an exact digest match, approved class membership, authenticated measurement, permitted composite condition, or another machine-verifiable correspondence rule supported by the embodiment. Successful model identity verification alone does not necessarily prove that the entire workflow satisfies its required approved ALF condition. The applicable policy establishes which measurements are mandatory. 11.13.11. WF-13.11 — Composite ALF and Multi-Component Model Configuration In an embodiment employing a Composite ALF, the authorization may depend upon several aspects of the computational environment. A composite measurement may represent: (a) base model identity; (b) checkpoint digest; (c) adapter state; (d) system or instruction configuration; (e) tool policy; (f) retrieval policy; (g) memory policy; (h) safety policy; and (i) orchestration workflow. An illustrative composite reference is: CompositeALF = H(Encode(ModelState, AdapterState, ToolPolicy, RetrievalPolicy, MemoryPolicy, SafetyPolicy, WorkflowState)) This formula is a non-limiting implementation example. The required Composite ALF may include fewer or additional measurements according to the applicable authorized model condition. Das Expires 19 April 2027 [Page 533] Internet-Draft Protected AI Execution Finality October 2026 If a mandatory configuration measurement changes, the previously approved ALF condition must be reevaluated according to the protected policy. The system does not assume that identical base-model weights imply identical authorization for every possible tool, retrieval, memory, or safety configuration. 11.13.12. WF-13.12 — Authorized Purpose and Context Validation The Protected Governance Domain evaluates whether the proposed computation remains within the authorized purpose and execution scope. Where applicable, an Algorithmic Intent Fingerprint (AIF) represents the permitted operational intent. The validation may determine whether: (a) the proposed computation purpose is authorized; (b) the model class is permitted for that purpose; (c) the requesting tenant is within scope; (d) the intended destination or output context is permitted; (e) the proposed tool or retrieval configuration remains within the authorized workflow; and (f) the applicable jurisdictional requirements are satisfied. An approved model may be authorized for one purpose but not for another. Authorization to perform one class of computation does not automatically authorize every related or subsequent model invocation. 11.13.13. WF-13.13 — Protected Pre-Computation Authorization Predicate PGD-1305 evaluates the required admission predicates. An illustrative conjunctive predicate is: Vadmit = Pidentity AND Pmodel AND PALF AND Ppurpose AND Pcontext AND Pstate where: Das Expires 19 April 2027 [Page 534] Internet-Draft Protected AI Execution Finality October 2026 Vadmit denotes the protected computation-admission decision; Pidentity verifies the requesting identity; Pmodel verifies the permitted model or model class; PALF verifies the Approved Algorithmic Logic Fingerprint Condition; Ppurpose verifies the authorized computation purpose; Pcontext verifies the required workflow, policy, and execution- context conditions; and Pstate verifies applicable policy, revocation, freshness, nonce, and protected-state conditions. Where approved alternative or threshold conditions apply, the Protected Governance Domain evaluates the authorized combination rather than requiring every possible predicate to be conjunctive. Failure of any mandatory predicate prevents successful computation- start authorization. 11.13.14. WF-13.14 — Protected Authorization-State Handling Where required by the embodiment, PGD-1305 performs protected authorization-state operations before making computation-start authority available. Such operations may include: (a) verification of the current policy epoch; (b) consultation of required revocation state; (c) reservation of a computation-admission grant; (d) consumption or registration of a nonce; (e) checking the computation quota; (f) registration of a model-admission identifier; (g) protection against replay; or (h) another mandatory state transition. Das Expires 19 April 2027 [Page 535] Internet-Draft Protected AI Execution Finality October 2026 Where a computation grant has a restricted usage allowance, the protected mechanism coordinates state updates to prevent unauthorized duplicate admission. If the required protected-state operation fails, the system does not treat the proposed computation as authorized. 11.13.15. WF-13.15 — Computation-Admission Validation Evidence Where the applicable embodiment requires protected validation evidence, EV-1308 generates or commits an authenticated record representing the computation-admission decision. A non-limiting record comprises: validation_record_id; computation_descriptor_digest; approved_alf_reference; authority_object_reference; validated_model_reference; policy_epoch; nonce; protected_state_reference; admission_boundary_id; decision; protected_authentication. The record may be implemented as an authenticated validation artifact, sealed record, protected commitment, AVR, LAVR, or equivalent mechanism where the corresponding embodiment supports it. Where evidence commitment is a prerequisite to computation-start authority, the required evidence is committed before, or atomically with, availability of the corresponding authorization artifact. Das Expires 19 April 2027 [Page 536] Internet-Draft Protected AI Execution Finality October 2026 enforcement point 54 itself does not independently impose every protected receipt or state-consumption limitation used in the broader execution-finality architecture. Such additional conditions apply where required by the selected embodiment. 11.13.16. WF-13.16 — Computation-Start Authorization Artifact Upon successful satisfaction of the applicable protected computation- admission conditions, CR-1309 generates, validates, or makes available the computation-start authorization artifact. The artifact may contain or securely reference: authorization_id; computation_descriptor_digest; approved_alf_reference; authorized_model_identifier; checkpoint_reference; adapter_reference; authorized_workflow_scope; tool_scope; retrieval_scope; memory_scope; authorized_purpose; tenant_scope; policy_epoch; revocation_reference; nonce; expiry; admission_boundary_id. In an illustrative authenticated implementation: Das Expires 19 April 2027 [Page 537] Internet-Draft Protected AI Execution Finality October 2026 Cstart = Sign_skPGD(Encode(hCompute, ALFref, ModelRef, Scope, Epoch, Nonce, Expiry, Sink)) where: Cstart denotes the computation-start authorization artifact; Sign_skPGD denotes signature generation under a key protected by the governance domain; hCompute denotes the canonical computation descriptor digest; ALFref denotes the approved ALF reference; ModelRef denotes the authorized model identity; Scope denotes the permitted computation scope; Epoch denotes the applicable protected policy epoch; Nonce denotes the required freshness value; Expiry denotes the authorized validity limit; and Sink denotes the protected computation-admission boundary. The selected implementation may instead use a MAC-authenticated record, protected capability table, sealed authorization reference, hardware enablement condition, or equivalent machine-verifiable authorization mechanism. The artifact is not an unrestricted credential for arbitrary model execution. 11.13.17. WF-13.17 — Model and Workflow Measurement Binding in the implementation described by enforcement point 55, the computation-start authorization artifact is bound to at least one of: (a) model identifier; (b) checkpoint hash; (c) adapter digest; (d) approved workflow class; (e) tool-policy reference; Das Expires 19 April 2027 [Page 538] Internet-Draft Protected AI Execution Finality October 2026 (f) retrieval-policy reference; (g) memory-policy reference; (h) safety-policy reference; (i) purpose class; (j) jurisdiction condition; (k) tenant identity; (l) destination context; (m) policy epoch; or (n) nonce. The Protected Governance Domain validates the mandatory bindings before issuing or approving the artifact. The request-admission component verifies the applicable bindings before permitting computation. Where the selected model or workflow configuration differs materially from the authorized state, the original artifact does not independently authorize execution. 11.13.18. WF-13.18 — Independent Computation-Admission Verification MA-1310 receives or obtains the computation-start authorization artifact and the proposed computation request. Before forwarding or admitting the request, the admission interface verifies: (a) artifact authenticity; (b) required computation-descriptor correspondence; (c) approved ALF condition; (d) requested model identity; (e) required checkpoint or adapter identity; (f) permitted workflow scope; Das Expires 19 April 2027 [Page 539] Internet-Draft Protected AI Execution Finality October 2026 (g) authorized purpose; (h) required policy and revocation state; (i) applicable nonce and expiry; (j) usage or replay restrictions; and (k) designated computation-admission boundary. The admission interface determines whether the actual proposed computation matches the authorized computation context. It does not rely solely upon an earlier assertion that the requesting client is authenticated or that its API credential is valid. 11.13.19. WF-13.19 — Computation Admission Verification Predicate An illustrative verification expression is: PermitCompute = Auth(Cstart) AND Match(Cstart,Dactual) AND ALFValid(Cstart,Mactual) AND ScopeValid(Cstart,Xactual) AND StateValid(Cstart,S) AND SinkValid(Cstart,F) where: PermitCompute denotes permission to begin the governed computation; Cstart denotes the computation-start authorization artifact; Dactual denotes the actual computation-context descriptor; Mactual denotes the selected model or required workflow measurement; Xactual denotes the relevant execution context; S denotes applicable protected authorization state; and F denotes the designated computation-admission interface. Auth verifies artifact authenticity. Match verifies required descriptor correspondence. ALFValid verifies the approved model or workflow condition. ScopeValid verifies the authorized computation scope. Das Expires 19 April 2027 [Page 540] Internet-Draft Protected AI Execution Finality October 2026 StateValid verifies required policy, revocation, freshness, and usage conditions. SinkValid verifies the designated admission boundary. The computation request is admitted only if every mandatory predicate succeeds. 11.13.20. WF-13.20 — Protected Model-Loader Admission in the implementation described by enforcement point 56, MA-1310 is associated with ML-1311. The model loader may comprise: (a) a model registry; (b) a model checkpoint loader; (c) an adapter loader; (d) an accelerator-runtime initializer; (e) a protected model activation controller; (f) a model-serving runtime; (g) an authenticated model-state manager; or (h) an equivalent loading or activation interface. The model weights, adapters, execution state, or accelerator-resident model state are not activated for the governed computation until the computation-start authorization artifact verifies against the approved model state. The implementation distinguishes loading or staging model bytes from activating them for the governed computation. A model may be stored or prepared without necessarily being authorized for use in the particular execution context. 11.13.21. WF-13.21 — Model Loader Verification Sequence In a non-limiting implementation, the protected model loader performs the following sequence. First, it receives or resolves the proposed model identity. Das Expires 19 April 2027 [Page 541] Internet-Draft Protected AI Execution Finality October 2026 Second, it obtains the applicable checkpoint, adapter, or required configuration measurements. Third, it retrieves or verifies the corresponding approved ALF condition. Fourth, it obtains the computation-start authorization artifact. Fifth, it verifies the artifact's authenticity and mandatory computation-context bindings. Sixth, it checks required current policy, revocation, freshness, and usage state. Seventh, it compares the actual model state against the approved model condition. Eighth, it permits activation of the approved model state only if all mandatory authorization conditions succeed. If the required conditions fail, the governed model-activation interface remains disabled or refuses the requested computation. The system does not treat the presence of model weights in memory as sufficient evidence of authorization to execute them. 11.13.22. WF-13.22 — Accelerator and Model-State Activation In an accelerator-backed implementation, ML-1311 may control the transition from prepared model state into executable model state. The model may be staged in storage, host memory, protected loading buffers, or another non-active representation before admission. Upon successful verification, the model loader permits the required activation operation. Possible implementations include: (a) an authenticated model-loader authorization hook; (b) protected runtime initialization; (c) a model-registry admission controller; (d) an accelerator scheduling interface; (e) a protected checkpoint activation procedure; Das Expires 19 April 2027 [Page 542] Internet-Draft Protected AI Execution Finality October 2026 (f) an adapter-activation interface; or (g) an equivalent model-computation enablement mechanism. Where model activation or computation admission requires a hardware- controlled condition, the implementation must actually enforce that condition at the selected boundary. Software admission alone does not automatically provide protection against a privileged attacker able to bypass that software boundary. 11.13.23. WF-13.23 — Runtime Behavioral Descriptor Formation After successful admission, RB-1312 may collect governance-relevant runtime information associated with the computation. An RBD may represent: (a) tools invoked; (b) retrieval endpoints accessed; (c) memory resources used; (d) workflow transitions; (e) policy branches selected; (f) connector usage; (g) generated tool requests; (h) resource-access patterns; (i) external content consumed; (j) model or configuration changes; and (k) other applicable runtime observations. The RBD represents observed runtime behavior. An RBD measuring behavior during a computation cannot ordinarily serve as evidence of behavior that has not yet occurred at the initial computation-start boundary. Accordingly, pre-computation ALF verification and subsequent runtime RBD validation are temporally distinguishable operations. Das Expires 19 April 2027 [Page 543] Internet-Draft Protected AI Execution Finality October 2026 The initial admission may depend on previously available runtime evidence, but observations arising only after the computation begins are evaluated at an appropriate later checkpoint or effectuation boundary. 11.13.24. WF-13.24 — Runtime Behavioral Drift and Continued Governance Where the computation is subject to runtime governance, the protected system may compare the observed RBD against the authorized ALF, AIF, workflow envelope, or other applicable protected predicates. Relevant deviations may include: (a) invocation of an unauthorized tool; (b) retrieval from an unapproved data source; (c) use of a prohibited memory scope; (d) unexpected connector access; (e) material change in the approved workflow; (f) unauthorized model or adapter modification; (g) violation of the permitted purpose; or (h) an incompatible protected policy-state change. If a mandatory runtime condition fails, the system may restrict further computation admission, revoke a bounded runtime authorization, withhold subsequent operation capabilities, or apply another supported fail-closed enforcement action. A runtime behavioral alarm does not automatically prove that an earlier external effect was prevented. The effect of the monitoring decision depends upon the actual controlled boundary and whether the corresponding consequential operation was still non-effective when enforcement occurred. 11.13.25. WF-13.25 — Pre-Computation and Runtime Authorization Separation The system distinguishes at least three authorization stages. Pre-computation admission: Whether the model and workflow may begin the governed computation under the applicable Approved ALF Condition. Das Expires 19 April 2027 [Page 544] Internet-Draft Protected AI Execution Finality October 2026 Runtime governance: Whether the continuing computation remains within required behavioral, policy, workflow, and operational constraints. External execution finality: Whether a particular consequential act resulting from the computation may become effective. The same Protected Governance Domain may participate in multiple stages. However, successful authorization at an earlier stage does not automatically discharge a separate mandatory authorization condition at a later stage. This distinction prevents approval of a model or computation from becoming unrestricted authority over external tools, services, credentials, data, or physical systems. 11.13.26. WF-13.26 — Separate Downstream Execution Authority in the implementation described by enforcement point 57, EF-1313 governs externally effective operations generated after successful computation admission. A model may be admitted to execute inference and subsequently generate: (a) a tool invocation; (b) an external API request; (c) a credential-mediated operation; (d) a network transmission; (e) a persistent file modification; (f) a database commit; (g) a software deployment; (h) a payment instruction; or (i) another consequential operation. The generated operation constitutes a separate Candidate Act. Das Expires 19 April 2027 [Page 545] Internet-Draft Protected AI Execution Finality October 2026 The computation-start authorization artifact does not independently substitute for the required protected execution-finality authority applicable to that Candidate Act. The separate operation remains subject to protected validation, applicable protected-state and evidence conditions, scoped execution- capability availability, and Finality Sink verification as required by its corresponding embodiment. 11.13.27. WF-13.27 — Downstream Finality Verification Sequence For an admitted model computation that generates a protected external operation, the system may perform the following sequence. First, the model computes an output or tool instruction. Second, the output is classified as a Candidate Act. Third, an appropriate interception component prevents the act from becoming effective. Fourth, an effectuation-specific Candidate Act Descriptor is constructed. Fifth, the applicable PED validates the required operation, authority, purpose, destination, policy, provenance, and runtime predicates. Sixth, the PED performs required protected-state operations. Seventh, required protected validation evidence is committed. Eighth, the corresponding scoped execution capability is made available. Ninth, the applicable Finality Sink verifies the capability against the actual proposed consequential operation. Tenth, only the validated and authorized effect is permitted. The downstream Finality Sink may comprise a network interface, credential broker, tool executor, storage commit controller, API gateway, deployment controller, payment switch, actuator, or another protected effectuation boundary. The required security relationship is determined by the particular downstream operation and claim. Das Expires 19 April 2027 [Page 546] Internet-Draft Protected AI Execution Finality October 2026 11.13.28. WF-13.28 — Example: Approved Model, Unauthorized Tool Operation An AI agent requests permission to execute an approved model using an authorized checkpoint and permitted inference workflow. The Protected Governance Domain verifies the approved ALF condition and makes available a valid computation-start authorization artifact. The admission component verifies the artifact. The model begins computation. During execution, the model generates a request to transmit confidential information to an unauthorized external endpoint. Although the model was correctly admitted to compute, the proposed transmission is a separate Candidate Act. The network finality subsystem constructs the effectuation-relevant descriptor. The protected authority determines that the requested destination violates a mandatory authorization predicate. The required network capability is withheld. The network Finality Sink does not permit the unauthorized transmission. The initial model-admission authorization remains distinct from the failed downstream execution authorization. 11.13.29. WF-13.29 — Example: Unauthorized Adapter Substitution An application proposes a computation using an approved base model. The computation-start artifact is bound to the base model and an approved adapter digest. After authorization, the requesting environment attempts to substitute a different adapter before activation. The model loader obtains the actual adapter measurement. The measurement does not match the mandatory authorized adapter state. Das Expires 19 April 2027 [Page 547] Internet-Draft Protected AI Execution Finality October 2026 The computation-admission verification fails. The governed model activation is refused unless a new valid authorization permits the changed model context. An approved base model does not independently authorize arbitrary adapter substitutions where adapter state is a required condition. 11.13.30. WF-13.30 — Example: Retrieval-Policy Modification A governed retrieval-enabled model request is authorized under an approved retrieval policy. The approved ALF condition includes the applicable retrieval-policy reference. Before computation admission, the requester attempts to replace the retrieval configuration with a broader source set. The Protected Governance Domain or admission verifier determines that the actual proposed computation context no longer satisfies the required approved policy condition. The computation-start artifact is withheld or rejected. Where retrieval configuration changes during an already admitted computation, the system applies the corresponding runtime or retrieval-boundary authorization rather than assuming that the original admission check automatically governs every later retrieval. 11.13.31. WF-13.31 — Authorization Refresh and Policy Epoch Changes The applicable model or computation authority may change before or during a governed session. Such events may include: (a) revocation of an approved model; (b) withdrawal of an approved checkpoint; (c) invalidation of an adapter; (d) modification of required safety-policy state; (e) change in a permitted tool graph; (f) revocation of a requesting tenant; Das Expires 19 April 2027 [Page 548] Internet-Draft Protected AI Execution Finality October 2026 (g) expiry of a computation authorization; or (h) advancement of the protected policy epoch. Where a current authorization-state check is mandatory, a stale computation-start artifact cannot independently authorize another computation-start event. Where an active computation is subject to continued runtime or downstream effectuation controls, the system enforces the corresponding current-state conditions at the specified checkpoints. Revocation cannot retroactively prevent computation that has already occurred. 11.13.32. WF-13.32 — Replay and Unauthorized Reuse Prevention Where computation-start authorization is nonce-bound, usage-bounded, session-bound, or otherwise restricted, the admission mechanism verifies the corresponding protected state. An illustrative authorization record comprises: authorization_id; computation_descriptor_digest; approved_alf_reference; authorized_model_identity; permitted_session; policy_epoch; nonce; remaining_uses; expiry; status. An artifact authorizing one computation event does not automatically authorize an unrelated event when the relevant authorization conditions prohibit reuse. Das Expires 19 April 2027 [Page 549] Internet-Draft Protected AI Execution Finality October 2026 Where a single-use computation-start artifact is required, the protected state mechanism prevents unauthorized concurrent or repeated admission using the same grant. Where bounded repeated use is expressly permitted, the corresponding validity and usage limits are enforced. 11.13.33. WF-13.33 — Crash, Restart, and Recovery The system distinguishes failures before and after governed computation admission. Failure before protected authorization: The request remains pending or denied. No valid computation-start artifact becomes available for an incomplete mandatory authorization procedure. Failure after authorization but before admission: The protected system evaluates the committed authorization and usage state before restoring or reissuing the artifact. Failure during model activation: The model loader determines whether activation completed and whether renewed admission verification is required. Failure after computation begins: A restart or replacement runtime must satisfy the applicable model, policy, authorization, and freshness conditions before any newly governed computation-start event proceeds. Failure after a downstream consequential operation: The downstream operation follows its own protected outcome and recovery procedure. A restart does not automatically reestablish previously revoked, expired, or consumed execution authority. The exact recovery guarantees depend upon the implemented protected state and the controlled model-execution interface. 11.13.34. WF-13.34 — Alternative Structural Implementations The protected computation-admission relationship may be implemented through several technical arrangements. Inference-gateway implementation: An authenticated gateway verifies computation-start authority before forwarding a request to a model service. Das Expires 19 April 2027 [Page 550] Internet-Draft Protected AI Execution Finality October 2026 Protected model-loader implementation: The loader prevents activation of unauthorized model state. Model-registry implementation: A protected registry admission service restricts selection or activation of model artifacts. Accelerator-runtime implementation: A controlled runtime initializer requires the corresponding computation-start authorization before admitting the governed model computation. Confidential-computing implementation: Protected authorization and model-state verification operate within a confidential VM, enclave, or protected computation environment according to its security properties. Single-node implementation: The requesting workload, protected governance function, and admission verifier are colocated while retaining their required functional authorization separation. Distributed implementation: The Protected Governance Domain and model-execution service operate on separate nodes and exchange authenticated computation-start authorization information. Multi-model implementation: A protected admission gateway authorizes specified models or model classes according to their individual authority and approved ALF requirements. Runtime-governed implementation: Pre-computation admission is supplemented by RBD checks and separately enforced consequential- operation finality. Different substrates need not provide identical protection against privileged host compromise, hardware compromise, rollback, model substitution, or service bypass. The implementation must enforce the actual security properties required under the specified enforcement profile. 11.13.35. WF-13.35 — Failure and Fail-Closed Conditions The request-admission component refuses a governed computation-start operation when a mandatory condition is absent, invalid, expired, revoked, inconsistent, replayed, or unverifiable. Non-limiting denial conditions include: (a) missing computation-start authorization artifact; Das Expires 19 April 2027 [Page 551] Internet-Draft Protected AI Execution Finality October 2026 (b) invalid artifact authentication; (c) unauthorized requesting identity; (d) invalid model identity; (e) unauthorized checkpoint; (f) adapter digest mismatch; (g) failed Approved ALF Condition; (h) unauthorized workflow class; (i) invalid tool-policy reference; (j) unauthorized retrieval policy; (k) invalid memory-policy condition; (l) invalid safety-policy condition; (m) unauthorized purpose; (n) jurisdiction mismatch where required; (o) tenant identity mismatch; (p) unauthorized computation endpoint; (q) stale policy epoch; (r) invalid revocation state; (s) expired or replayed nonce; (t) exhausted usage state; (u) failed mandatory protected-state operation; (v) failed required validation-evidence commitment; (w) computation-descriptor mismatch; (x) admission-sink mismatch; or (y) unavailable required protected verification. Das Expires 19 April 2027 [Page 552] Internet-Draft Protected AI Execution Finality October 2026 The system may retain the request in Pending Admission State, deny admission, quarantine an unapproved model artifact, or use a separately authorized recovery procedure. No mandatory failure condition creates authority to begin computation through an unprotected fallback. 11.13.36. WF-13.36 — PHOSITA Verification and Negative Tests A person having ordinary skill in machine-learning systems, model- serving infrastructure, trusted computing, AI orchestration, distributed authorization, cryptography, or accelerator runtimes may verify the described architecture through controlled tests. Test 1 — Approved model admission: Submit a request satisfying all mandatory model, ALF, purpose, policy, and artifact conditions. The admission component permits the governed computation. Test 2 — Missing authorization artifact: Present a valid client credential without computation-start authorization. Admission is refused. Test 3 — Unauthorized model: Request a model outside the approved class. The required ALF or model authorization condition fails. Test 4 — Checkpoint substitution: Replace the approved checkpoint with an unauthorized checkpoint. Mandatory model-state correspondence fails. Test 5 — Adapter substitution: Change the required adapter digest after authorization. Admission is refused. Test 6 — Tool-policy mismatch: Present a workflow containing an unauthorized tool configuration. The applicable ALF condition fails. Test 7 — Retrieval-policy mismatch: Widen a mandatory approved retrieval policy. Protected validation refuses the incompatible computation. Test 8 — Memory-policy mismatch: Change the mandatory memory-access configuration outside authorized scope. Admission fails. Test 9 — Safety-policy modification: Substitute a configuration that no longer satisfies the approved safety-policy condition. The authorization is rejected. Test 10 — Purpose mismatch: Request an otherwise approved model for an unauthorized purpose. Admission fails. Das Expires 19 April 2027 [Page 553] Internet-Draft Protected AI Execution Finality October 2026 Test 11 — Tenant substitution: Reuse a tenant-bound artifact from another tenant. The applicable identity or scope predicate fails. Test 12 — Computation endpoint substitution: Attempt use of the authorization at a different protected admission boundary where boundary binding is mandatory. Verification fails. Test 13 — Policy epoch change: Present an artifact bound to an incompatible previous policy epoch. Admission is refused. Test 14 — Revoked model: Revoke a mandatory model approval. Subsequent governed admission is denied. Test 15 — Expired artifact: Present an expired computation-start authorization. Admission fails. Test 16 — Replay: Reuse a consumed single-use authorization artifact. Protected usage verification rejects unauthorized reuse. Test 17 — Concurrent admission: Submit concurrent requests against one restricted authorization. The protected mechanism prevents unauthorized duplicate consumption. Test 18 — Model-loader bypass: Attempt activation through an alternative model-loading interface. The operation is blocked or subjected to equivalent required admission verification. Test 19 — Unverified checkpoint loading: Stage model weights without valid authorization and attempt to activate them. The governed activation boundary refuses the operation. Test 20 — ALF measurement mismatch: Modify a mandatory computation- logic measurement. Protected validation fails. Test 21 — Runtime behavioral drift: After valid admission, cause a mandatory runtime behavioral condition to fail. The applicable runtime enforcement withholds further affected authorization. Test 22 — Unauthorized downstream network request: Admit an approved model, then generate an unauthorized external request. The separate network Finality Sink refuses the operation. Test 23 — Unauthorized downstream tool call: Admit an approved computation, then propose an unauthorized consequential tool operation. The tool-execution Finality Sink refuses the operation. Das Expires 19 April 2027 [Page 554] Internet-Draft Protected AI Execution Finality October 2026 Test 24 — Credential-use separation: Verify that computation-start authorization alone does not enable unrestricted protected credential use. Test 25 — Crash before authorization: Interrupt the mandatory protected admission procedure before commitment. No valid corresponding artifact becomes available. Test 26 — Crash after authorization: Interrupt the admission interface after successful protected authorization. Recovery consults the corresponding protected state rather than granting unrestricted reuse. Test 27 — Policy update during computation: Change a mandatory authorization condition and verify the appropriate runtime or subsequent effectuation enforcement. Test 28 — Single-node admission: Implement protected admission within one node and verify that requesting computation cannot bypass the mandatory authorization boundary. Test 29 — Distributed admission: Issue computation-start authority at a protected governance service and verify it at a remote model- serving interface. Invalid bindings are rejected. Test 30 — Downstream finality distinction: Successfully authorize model computation while independently withholding a separate Candidate Act capability. Confirm that computation admission does not cause the unauthorized external effect. These tests may be performed using controlled inference services, mock AI agents, protected model-loader hooks, test registries, synthetic checkpoints, adapter substitutions, authenticated policy stores, programmable admission interfaces, runtime-behavior instrumentation, and fault injection. The tests establish only the security properties demonstrated by the actual implementation and its stated threat model. 11.13.37. WF-13.37 — Claim-Specific Technical Support Enforcement Point 54 — Protected Pre-Computation Model Admission System This workflow provides: (a) CE-1301 representing a requesting client, AI agent, or application; Das Expires 19 April 2027 [Page 555] Internet-Draft Protected AI Execution Finality October 2026 (b) RA-1302 positioned before a model-execution service; (c) interception of governed computation requests; (d) DC-1304 constructing the governed computation-context descriptor; (e) PGD-1305 validating the Approved Algorithmic Logic Fingerprint Condition; (f) CR-1309 generating or validating the computation-start authorization artifact; (g) HQ-1303 retaining the request in Pending Admission State; (h) MA-1310 refusing admission when required artifact or context verification fails; and (i) separation of ordinary client authentication from protected computation-start authority. Enforcement Point 55 — Model and Workflow Measurement Binding WF-13.7 through WF-13.11 and WF-13.17 provide the required model, checkpoint, adapter, workflow, policy, purpose, jurisdiction, tenant, destination, epoch, or nonce bindings. Enforcement Point 56 — Protected Model-Loader Admission WF-13.20 through WF-13.22 describe the model-loader, registry, checkpoint, adapter, or accelerator-runtime admission mechanism and require the computation-start artifact to verify before the governed model state is activated. Enforcement Point 57 — Separate Downstream Execution Authority WF-13.25 through WF-13.28 establish the separation between authorization to begin computation and authorization to produce a subsequent consequential effect. The downstream Candidate Act is subject to its own protected finality sequence. 11.13.38. WF-13.38 — Technical Effect The workflow establishes a protected computation-admission dependency between: (a) generation of a proposed model computation; Das Expires 19 April 2027 [Page 556] Internet-Draft Protected AI Execution Finality October 2026 (b) mandatory interception before the governed computation-start boundary; (c) retention in Pending Admission State; (d) construction of a governed computation-context descriptor; (e) authentication of applicable computation authority; (f) protected verification of the Approved Algorithmic Logic Fingerprint Condition; (g) required purpose, workflow, model-state, policy, revocation, and freshness checks; (h) computation-start authorization artifact generation or validation; (i) independent verification at the computation-admission boundary; (j) controlled admission of the authorized model or computation; (k) applicable runtime behavioral governance; and (l) separate execution-finality authorization of downstream consequential Candidate Acts. The system prevents a client or autonomous agent from treating an API credential, authenticated session, approved model name, or ordinary inference permission as sufficient authority to initiate a governed computation without satisfying the required approved ALF and computation-start authorization conditions. The stronger model-loader embodiment prevents the governed model weights, checkpoint, adapter, or accelerator state from becoming active for the requested computation without successful protected admission verification. The downstream finality subsystem separately determines whether a generated tool invocation, network request, file modification, credential operation, or other consequential act may become effective. Computation is not authority to act. Authentication is not protected computation-start authorization. Das Expires 19 April 2027 [Page 557] Internet-Draft Protected AI Execution Finality October 2026 An approved model does not automatically authorize every execution configuration. Authorization to compute is not authorization to produce an external consequence. 11.14. WF-14 — Protected Model-Path and Downstream Effectuation-Path Dual Authorization, Inference-to-Act Context Binding, Streaming Output Control, Multi-Sink Classification, and Remote Finality Verification 11.14.1. WF-14.1 — Technical Purpose This embodiment describes a computer-implemented execution-finality architecture providing two distinguishable protected authorization functions associated with artificial-intelligence computation and consequential operations derived from that computation. A first protected authorization function controls admission of a proposed inference or agent-computation request through a governed model-access path. A second protected authorization function controls whether a particular consequential operation generated, selected, prepared, or derived from the admitted computation is permitted to cross its applicable execution-finality boundary. The architecture prevents authorization of a model invocation from being treated as sufficient authorization for subsequent network transmission, tool invocation, credential use, database modification, payment execution, software deployment, persistent storage operation, actuator command, or other externally effective operation. The first protected boundary verifies computation-admission authority associated with the requested model, workload, execution purpose, and approved computation context. The second protected boundary treats each governed consequential operation as a Candidate Act and maintains it in a Non-Effective State until an applicable Protected Enforcement Domain validates its operation-specific authorization context, commits required protected validation evidence, and releases or makes available a scoped execution capability. A downstream Finality Sink verifies the scoped capability against the actual operation and current applicable authorization state before permitting effectuation. Das Expires 19 April 2027 [Page 558] Internet-Draft Protected AI Execution Finality October 2026 The two authorization functions may be implemented through separate components, colocated protected services, one protected node, or distributed infrastructure. However, successful verification at the model-access gate does not replace the separately required verification at the downstream Finality Sink. The architecture further addresses: (a) binding of computation-admission context to a downstream Candidate Act; (b) protection against unauthorized conversion of model output into execution authority; (c) streaming model outputs and partially generated tool commands; (d) continued withholding of buffered operations after model-access interruption; (e) classification of multiple distinct consequential operations and their respective Finality Sinks; (f) independent receiving-side verification; (g) protection against time-of-check and time-of-use substitution; (h) protected authorization-state changes, revocation, and replay; and (i) failure, crash recovery, and uncertain downstream completion. 11.14.2. WF-14.2 — Participating Technical Components In one non-limiting implementation, the system comprises the following components. ME-1401 — Model-Execution Environment A model-serving system, inference environment, model runtime, agent- computation service, accelerator-backed model engine, or equivalent component configured to receive and process governed model- computation requests. MG-1402 — Protected Model-Access Gate Das Expires 19 April 2027 [Page 559] Internet-Draft Protected AI Execution Finality October 2026 An enforcement-controlled interface positioned on the governed path to ME-1401, configured to verify computation-admission authority before permitting a model invocation. AC-1403 — Computation-Admission Authorization Component A protected component configured to authenticate the requesting workload, requested model, approved execution context, purpose, and required policy state. AR-1404 — Protected Computation-Admission Record A protected or authenticated record representing authorization of a particular computation, model context, or bounded computation session. AE-1405 — Agent or Tool Execution Environment An AI-agent runtime, orchestration process, tool execution environment, application, workflow controller, or associated computational component configured to receive model outputs and prepare consequential operations. OC-1406 — Protected Operation-Classification Component A mechanism configured to identify externally effective operations arising from admitted computation and represent those operations as Candidate Acts. HQ-1407 — Non-Effective Candidate Act Holding Mechanism An enforcement-controlled mechanism configured to hold a proposed consequential operation before it crosses the applicable effectuation boundary. DC-1408 — Candidate Act Descriptor Component A mechanism configured to obtain or construct the effectuation- relevant descriptor of a downstream Candidate Act. PED-1409 — Protected Enforcement Domain A protected authorization component configured to validate the concrete operation, applicable authority, current protected state, intended effectuation boundary, and other required predicates. PS-1410 — Protected Authorization-State Store Das Expires 19 April 2027 [Page 560] Internet-Draft Protected AI Execution Finality October 2026 A protected mechanism maintaining applicable operation grants, policy epochs, revocation state, nonces, capability usage, validation commitments, and computation-to-operation authorization references. EV-1411 — Protected Evidence-Commitment Component A mechanism configured to generate or commit operation-specific protected validation evidence before, or atomically with, availability of the required operation-specific execution capability. CR-1412 — Scoped Execution-Capability Component A protected mechanism configured to generate, register, derive, release, or otherwise make available the required operation-specific execution capability. SC-1413 — Inference-to-Act Context Binding Component A mechanism configured to associate an admitted model-computation context with a subsequently generated Candidate Act without converting admission authority into effectuation authority. SM-1414 — Streaming Output and Partial-Action Controller An enforcement-controlled mechanism configured to classify and hold partial outputs, tool-call fragments, command representations, and completed or bounded consequential operations. FC-1415 — Effectuation Boundary Classification Component A mechanism configured to identify the appropriate Finality Sink or Finality Sinks for each consequential operation in an agentic workflow. FS-1416 — Downstream Finality Sink An effectuation interface configured to independently verify the operation-specific capability before allowing the Candidate Act to become effective. RV-1417 — Remote Actual-Operation Verification Component An optional or required remote-side verifier configured to reconstruct or verify the Candidate Act presented at a receiving service, gateway, database, payment system, connector, or physical- control interface. OS-1418 — Protected Operation-Outcome Component Das Expires 19 April 2027 [Page 561] Internet-Draft Protected AI Execution Finality October 2026 A mechanism maintaining pending, authorized, reserved, denied, confirmed-effective, revoked, expired, or indeterminate effectuation states. RC-1419 — Revocation and Authorization-Consistency Component A protected mechanism configured to maintain or verify the required relationship among computation-admission state, downstream authority, capability usage, policy epochs, and applicable Finality Sinks. The described components may be implemented within one physical node or across multiple authenticated and protected components. The model-access gate and downstream Finality Sink remain separate enforcement functions even where their software or hardware implementations are integrated. 11.14.3. WF-14.3 — Establishment of Two Governed Authorization Boundaries The system establishes two authorization boundaries. Boundary A — Model-Computation Admission Boundary Boundary A controls whether a particular model or agent computation may begin through the governed model-execution path. The model-access gate verifies computation-admission authority before permitting the requested inference or computation. Boundary B — Consequential Effectuation Boundary Boundary B controls whether an operation generated, selected, or prepared from the admitted computation may become externally effective. The downstream Finality Sink verifies the operation-specific execution capability before effectuation. The boundaries control different technical events. Successful admission at Boundary A permits only the governed computation within its authorized scope. It does not automatically enable a subsequent operation at Boundary B. Das Expires 19 April 2027 [Page 562] Internet-Draft Protected AI Execution Finality October 2026 Likewise, interruption or revocation at Boundary A does not by itself establish that an already generated operation has been denied, consumed, cancelled, or prevented at Boundary B. The system therefore requires explicit enforcement at the downstream effectuation boundary whenever the consequential operation is subject to protected finality. 11.14.4. WF-14.4 — Model-Path Trust Boundary MG-1402 is positioned on a governed path to ME-1401. The model-access gate may be implemented through: (a) a model-serving gateway; (b) an inference admission controller; (c) a protected model loader; (d) an authenticated model-access broker; (e) an accelerator-admission controller; (f) a protected runtime interface; (g) a network or infrastructure controller positioned on the selected model path; or (h) an equivalent protected mechanism. The requesting agent or client cannot independently bypass the required computation-admission verification through another path within the specified governed model-access scope. A physical network device positioned on a model-access path is not automatically established to control every other downstream effectuation interface. The implementation must identify the model paths actually governed by the device. Where a stronger claim requires the gate to be mandatory for all model access within a defined environment, the implementation must enforce that coverage rather than merely monitor one optional access route. Das Expires 19 April 2027 [Page 563] Internet-Draft Protected AI Execution Finality October 2026 11.14.5. WF-14.5 — Downstream Effectuation Trust Boundary The system separately identifies the interfaces through which the admitted computation may produce consequential effects. Such interfaces may include: (a) external network egress; (b) authenticated API invocation; (c) tool execution; (d) protected credential use; (e) database commitment; (f) payment execution; (g) software deployment; (h) persistent memory mutation; (i) message delivery; (j) actuator control; (k) storage finalization; (l) model-output release; or (m) another governed effectuation interface. Each governed operation is associated with an applicable downstream Finality Sink. The downstream execution path is configured so that the requesting agent cannot cause the specified consequential effect through an accessible alternative interface without satisfying the required protected finality conditions. The model-access gate may provide an earlier authorization or monitoring control, but the actual non-bypassability of downstream effectuation depends upon the downstream enforcement arrangement. Das Expires 19 April 2027 [Page 564] Internet-Draft Protected AI Execution Finality October 2026 11.14.6. WF-14.6 — Generation of the Proposed Inference Request A requesting agent, application, or other computational component prepares a proposed inference request. A non-limiting request contains: inference_request_id; requesting_workload_id; requested_model_id; model_version; approved_execution_context; requested_computation_purpose; workflow_reference; tool_configuration_reference; policy_epoch; session_reference; model_access_gate_id. The proposed request is presented to MG-1402. The request does not independently authorize computation merely because the agent has generated it or possesses a valid application- level authentication credential. 11.14.7. WF-14.7 — Protected Computation-Admission Validation AC-1403 validates the mandatory computation-admission predicates. These may include: (a) authenticated workload identity; (b) authorized model identity; (c) permitted inference operation; (d) approved execution purpose; Das Expires 19 April 2027 [Page 565] Internet-Draft Protected AI Execution Finality October 2026 (e) required ALF or model-configuration condition; (f) applicable workflow scope; (g) protected policy epoch; (h) revocation state; (i) nonce or freshness; and (j) permitted model-access boundary. An illustrative predicate is: Vadmission = Pworkload AND Pmodel AND Ppurpose AND Pcontext AND Pstate where: Vadmission denotes the protected computation-admission result; Pworkload verifies requesting workload identity; Pmodel verifies the requested model; Ppurpose verifies the authorized computation purpose; Pcontext verifies the approved computation context; and Pstate verifies the required current authorization state. Additional predicates may apply according to the particular embodiment. Where any mandatory predicate fails, the protected model-access gate refuses the governed computation request. 11.14.8. WF-14.8 — Protected Computation-Admission Record Following successful admission authorization, the system may generate or maintain a Protected Computation-Admission Record AR-1404. in the implementation described by enforcement point 69, the record comprises: (a) model identity; (b) workload identity; Das Expires 19 April 2027 [Page 566] Internet-Draft Protected AI Execution Finality October 2026 (c) approved execution context; (d) policy epoch; and (e) authorization-state identifier. Additional fields may include: computation_id; model_configuration_digest; approved_alf_reference; authorized_purpose; session_id; admission_time; nonce; expiry; model_access_gate_id; protected_authentication. The record is authenticated or maintained under applicable protected- state control. The record represents the authorization conditions established for the admitted computation. It is not treated as a general execution capability authorizing arbitrary external operations. 11.14.9. WF-14.9 — Admission Record Authentication and Binding In an illustrative cryptographic implementation, the computation- admission record may be represented as: Radmit = AuthRecord(ModelID, WorkloadID, Context, Epoch, AuthStateID, SessionID, Nonce) where: Radmit denotes the protected computation-admission record; Das Expires 19 April 2027 [Page 567] Internet-Draft Protected AI Execution Finality October 2026 ModelID denotes the authorized model; WorkloadID denotes the requesting workload identity; Context denotes the approved computation context; Epoch denotes the applicable policy epoch; AuthStateID denotes the protected authorization-state reference; SessionID denotes the applicable inference-session identifier; and Nonce denotes the required freshness value. An illustrative authenticated commitment is: hAdmit = H("DAS-MODEL-ADMIT-v1" || Encode(Radmit)) The commitment may be included in or referenced by a later operation- specific authorization context. However, possession or successful verification of hAdmit does not independently release the capability necessary for a downstream effect. The cryptographic encoding is an implementation example and does not impose one particular hash algorithm or record format on every embodiment. 11.14.10. WF-14.10 — Controlled Model Computation Following successful verification at MG-1402, the authorized inference or agent computation may proceed. ME-1401 processes the permitted computation request. The model may generate: (a) natural-language output; (b) structured data; (c) a tool invocation; (d) an API request; (e) a command; Das Expires 19 April 2027 [Page 568] Internet-Draft Protected AI Execution Finality October 2026 (f) a workflow transition; (g) a proposed network transmission; (h) a transaction instruction; (i) an actuation instruction; or (j) another output or operation representation. The model output does not automatically acquire protected downstream execution authority merely because the computation was validly admitted. Where the model output does not cross a separately governed consequential boundary, the corresponding downstream execution- finality procedure may not be required. Where the output would cause a governed consequence, the appropriate downstream authorization procedure is mandatory. 11.14.11. WF-14.11 — Identification of the Consequential Operation OC-1406 receives or observes the model-derived operation. The component determines whether the output: (a) remains internal computational data; (b) constitutes a non-effective proposal; (c) requests a governed tool or service operation; (d) would cause an externally effective network or storage effect; (e) would initiate a protected transaction; (f) would change an operational system state; or (g) would otherwise cross a defined execution-finality boundary. A consequential operation is classified as Candidate Act CA-1420. The classification identifies the operation requiring protected effectuation authorization. A completed model computation is not automatically classified as an externally effective operation merely because it produced data. Das Expires 19 April 2027 [Page 569] Internet-Draft Protected AI Execution Finality October 2026 The applicable classification depends upon the effect being controlled. 11.14.12. WF-14.12 — Non-Effective State for the Derived Candidate Act OC-1406 submits CA-1420 to HQ-1407. The corresponding operation remains in a Non-Effective State. An illustrative staging record comprises: candidate_act_id; source_inference_id; source_admission_record_reference; requesting_workload_id; operation_class; target_effectuation_boundary; destination_reference; payload_reference; policy_epoch; status = NON_EFFECTIVE. The staged operation cannot produce its governed consequence while mandatory downstream authorization remains unresolved. The holding mechanism may retain an immutable operation representation or authenticated digest sufficient to preserve the effectuation-relevant parameters. The agent's ability to formulate the operation is distinct from its authority to release it. 11.14.13. WF-14.13 — Inference-to-Act Context Binding in the implementation described by enforcement point 69, SC-1413 establishes a verifiable relationship between the admitted computation and its resulting Candidate Act. The relationship may include: Das Expires 19 April 2027 [Page 570] Internet-Draft Protected AI Execution Finality October 2026 (a) computation-admission record digest; (b) model identity; (c) workload identity; (d) inference-session identity; (e) approved execution context; (f) protected policy epoch; (g) authorization-state identifier; (h) Candidate Act identifier; and (i) Candidate Act Descriptor digest. A non-limiting association is: Bcontext = H(Encode(hAdmit, CandidateActID, hAct, ContextRef, Epoch)) where: Bcontext denotes the inference-to-act context commitment; hAdmit denotes the protected admission-record digest; CandidateActID denotes the resulting Candidate Act identity; hAct denotes the Candidate Act Descriptor digest; ContextRef denotes applicable execution-context information; and Epoch denotes required authorization-state context. The protected system may verify this association as one of the downstream authorization predicates. The association establishes provenance or context correspondence, not independent authority to effectuate the Candidate Act. 11.14.14. WF-14.14 — Downstream Candidate Act Descriptor DC-1408 constructs or verifies the descriptor for CA-1420. The descriptor identifies the operation actually proposed for consequential execution. Das Expires 19 April 2027 [Page 571] Internet-Draft Protected AI Execution Finality October 2026 A non-limiting descriptor comprises: candidate_act_id; operation_class; source_workload_id; source_inference_reference; computation_admission_reference; source_tool_or_agent_id; actual_operation_parameters; destination_or_recipient; requested_effect; payload_digest; authorized_purpose; required_authority_object; protected_policy_epoch; revocation_epoch; nonce; expiry; validation_evidence_requirement; finality_sink_id. The descriptor is specific to the consequential operation, not merely to the model that generated it. Where exact operation binding is required, effectuation-relevant changes to the destination, payload, recipient, operation type, or scope result in a different descriptor or failed authorization correspondence. Das Expires 19 April 2027 [Page 572] Internet-Draft Protected AI Execution Finality October 2026 11.14.15. WF-14.15 — Canonical Operation Descriptor In an illustrative implementation: Dact = Canon_v(ACT, SOURCE, TARGET, PARAM, CONTEXT, EPOCH, SINK) where: Dact denotes the canonical Candidate Act Descriptor; ACT denotes the actual proposed operation class; SOURCE denotes the authenticated requesting workload and source execution context; TARGET denotes the destination, recipient, or effectuation target; PARAM denotes effectuation-relevant parameters; CONTEXT denotes the required inference and runtime context; EPOCH denotes the protected authorization-state version; and SINK denotes the designated Finality Sink identity. An illustrative descriptor commitment is: hAct = H("DAS-DOWNSTREAM-ACT-v1" || Encode(Dact)) where H denotes a cryptographic hash function. The selected encoding must preserve distinctions required by the applicable authorization. The same relevant field interpretation is used by the protected authorizer and downstream Finality Sink. 11.14.16. WF-14.16 — Acquisition of Operation-Specific Execution Authority PED-1409 obtains or resolves the Authority Object applicable to CA- 1420. The authority may specify: (a) authorized operation class; (b) requesting agent or workload identity; Das Expires 19 April 2027 [Page 573] Internet-Draft Protected AI Execution Finality October 2026 (c) permitted recipient or destination; (d) authorized purpose; (e) resource or transaction scope; (f) approved tool or connector; (g) applicable policy epoch; (h) revocation conditions; (i) nonce or usage limits; (j) required human approval; (k) relevant provenance or runtime conditions; (l) required inference-to-act context binding; and (m) designated Finality Sink. The Protected Enforcement Domain authenticates the applicable authority information. The computation-admission record may provide a required contextual input. It does not replace the separate Authority Object or protected authorization conditions applicable to the downstream Candidate Act. 11.14.17. WF-14.17 — Protected Downstream Authorization Predicates PED-1409 evaluates the operation-specific authorization predicates. An illustrative conjunctive predicate is: Vact = Poperation AND Pscope AND Ptarget AND Pcontext AND Pstate AND Psink where: Vact denotes the protected downstream authorization result; Poperation verifies the proposed consequential operation; Pscope verifies the permitted authority and purpose scope; Das Expires 19 April 2027 [Page 574] Internet-Draft Protected AI Execution Finality October 2026 Ptarget verifies the intended recipient, resource, or destination; Pcontext verifies mandatory inference-to-act and runtime context; Pstate verifies policy, revocation, freshness, usage, and protected- state conditions; and Psink verifies the designated effectuation boundary. The applicable embodiment determines which additional predicates are required. A valid computation-admission record may contribute to Pcontext. However: Vact is not inferred merely from Vadmission. Successful model admission and successful downstream execution authorization are separate decisions. 11.14.18. WF-14.18 — Protected Authorization-State Handling Following successful operation-specific validation, PED-1409 performs the protected-state operations required for CA-1420. Such operations may include: (a) reserving an operation-specific authorization grant; (b) consuming or registering a nonce; (c) updating a usage counter; (d) verifying the applicable policy epoch; (e) verifying current revocation state; (f) recording the Candidate Act Descriptor digest; (g) registering the intended Finality Sink; (h) establishing a protected receipt reference; or (i) performing another required protected-state transition. Das Expires 19 April 2027 [Page 575] Internet-Draft Protected AI Execution Finality October 2026 Where a single-use consequential operation is authorized, the protected state mechanism prevents unauthorized concurrent reuse of that authorization. If a mandatory protected-state operation fails, the corresponding execution capability is withheld. 11.14.19. WF-14.19 — Protected Operation-Specific Evidence Commitment EV-1411 generates or commits operation-specific validation evidence. An illustrative record contains: receipt_id; candidate_act_id; candidate_act_descriptor_digest; computation_admission_reference; validated_authority_reference; protected_state_transition; policy_epoch; revocation_epoch; nonce; finality_sink_id; validation_result; protected_authentication. The protected evidence may comprise a LAVR, AVR, sealed validation record, authenticated commitment, or equivalent protected representation. Under enforcement point 68, the required operation-specific validation record is committed before, or atomically with, availability of the corresponding operation-specific execution capability. The record is distinct from the earlier computation-admission record. Das Expires 19 April 2027 [Page 576] Internet-Draft Protected AI Execution Finality October 2026 An audit record created only after the external effect does not independently satisfy the required pre-capability commitment. 11.14.20. WF-14.20 — Protected Downstream Finality Transaction The PED establishes a protected causal dependency among successful operation validation, required protected-state handling, validation- evidence commitment, and capability availability. An illustrative transaction is: (Snext, Ract, Ready) = CommitActFinality(Dact, A, Scurrent, F) where: Snext denotes committed protected authorization state; Ract denotes committed operation-specific validation evidence; Ready denotes completion of required pre-release conditions; Dact denotes the validated consequential operation descriptor; A denotes applicable authenticated operation authority; Scurrent denotes prior protected authorization state; and F denotes the intended downstream Finality Sink. The operation-specific capability does not become valid for effectuation where a mandatory state or evidence dependency remains incomplete. This protected transaction does not necessarily require an arbitrary remote receiving service to participate in one globally atomic database transaction. 11.14.21. WF-14.21 — Operation-Specific Execution Capability Following successful completion of the required protected finality transaction, CR-1412 releases or makes available an operation- specific execution capability. In an illustrative cryptographic implementation: Cact = Sign_skPED(Encode(hAct, hRact, Bcontext, Scope, Epoch, Nonce, Expiry, F, CID)) Das Expires 19 April 2027 [Page 577] Internet-Draft Protected AI Execution Finality October 2026 where: Cact denotes the operation-specific execution capability; Sign_skPED denotes authenticated capability generation under PED- controlled key material; hAct denotes the Candidate Act Descriptor digest; hRact denotes the committed validation-evidence digest; Bcontext denotes the required inference-to-act association where applicable; Scope denotes permitted effectuation scope; Epoch denotes the required policy epoch; Nonce denotes applicable freshness; Expiry denotes capability validity; F denotes the authorized downstream Finality Sink; and CID denotes a capability identifier. The capability may alternatively comprise a protected table entry, MAC-authenticated permit, sealed handle, or hardware-controlled execution condition. Its non-bearer properties depend upon actual enforcement of required scope, state, context, usage, and sink bindings. 11.14.22. WF-14.22 — Independent Downstream Finality Sink Verification Before permitting CA-1420 to produce its consequential effect, FS-1416 obtains the actual operation presented for effectuation. The Finality Sink constructs or verifies the corresponding effectuation-relevant descriptor. The verification includes applicable checks of: (a) capability authenticity; (b) concrete operation correspondence; (c) authorized destination or recipient; Das Expires 19 April 2027 [Page 578] Internet-Draft Protected AI Execution Finality October 2026 (d) permitted effectuation scope; (e) required inference-to-act context; (f) policy epoch; (g) revocation state; (h) nonce or expiration; (i) validation-evidence commitment; (j) protected usage or consumption state; and (k) designated Finality Sink identity. The Finality Sink refuses the operation when any mandatory verification condition fails. An earlier successful model-access check is not treated as a substitute for this verification. 11.14.23. WF-14.23 — Downstream Finality Verification Predicate An illustrative effectuation predicate is: PermitEffect = Auth(Cact) AND Match(Cact,Dactual) AND ScopeValid(Cact,F) AND StateValid(Cact,S) AND EvidenceValid(Cact,Ract) where: PermitEffect denotes permission to effectuate the Candidate Act; Cact denotes the scoped operation-specific capability; Dactual denotes the operation actually presented; F denotes the designated Finality Sink; S denotes the required current protected authorization state; and Ract denotes the protected operation-specific validation evidence. Auth verifies capability authenticity. Match verifies required exact or bounded operation correspondence. Das Expires 19 April 2027 [Page 579] Internet-Draft Protected AI Execution Finality October 2026 ScopeValid verifies authorized operation scope and sink identity. StateValid verifies protected policy, revocation, freshness, and usage conditions. EvidenceValid verifies the required protected validation-state commitment. The Candidate Act becomes effective only when all mandatory verification conditions succeed. 11.14.24. WF-14.24 — Distinction Between Model Authorization and Effectuation Authorization The model-access gate verifies authorization of model computation. The downstream Finality Sink verifies authorization of a particular consequential operation. These mechanisms may share authenticated context or protected authority infrastructure. However, the following implications are not presumed: ModelAccessAllowed does not imply EffectuationAllowed. ModelAccessRevoked does not prove that every previously generated Candidate Act has been cancelled. ModelInferenceStopped does not prove that an already transmitted consequential operation was prevented. DownstreamCapabilityVerified does not prove that an unrelated later Candidate Act is authorized. Each claim of prevention depends upon the actual controlled effectuation boundary and the required authorization state for that boundary. 11.14.25. WF-14.25 — Revocation of Model Access in the implementation described by enforcement point 68, revocation of model-access authorization prevents further governed model computation through the applicable protected model-access gate. A revocation event may invalidate: (a) a model-session grant; Das Expires 19 April 2027 [Page 580] Internet-Draft Protected AI Execution Finality October 2026 (b) a permitted model identity; (c) an approved workflow configuration; (d) a requesting workload's model-access scope; or (e) another required computation-admission condition. MG-1402 consults the required current authorization state before permitting another governed model-computation event. A revoked model-access grant does not independently establish the completion status of previously generated Candidate Acts. Those Candidate Acts remain subject to their respective downstream authorization and Finality Sink conditions. 11.14.26. WF-14.26 — Already Generated and Buffered Candidate Acts An AI model may have already generated a tool command, payment instruction, API request, or other consequential operation before its model access is interrupted. The operation may remain buffered or queued within AE-1405 or HQ- 1407. The interruption of additional model inference does not itself authorize that operation for release. The buffered operation remains a Candidate Act in a Non-Effective State until the required downstream validation and Finality Sink verification succeed. Where model-access revocation is also expressly defined as a downstream authorization predicate, the downstream authority checks that condition. Where the downstream authorization is independently valid under the applicable policy, the system evaluates the Candidate Act according to the actual governing authority rules rather than assuming that every model-access interruption automatically revokes every other authorization. The two authority domains remain distinguishable. Das Expires 19 April 2027 [Page 581] Internet-Draft Protected AI Execution Finality October 2026 11.14.27. WF-14.27 — Model-Path Interruption and External-Effect Timing The system distinguishes three event classes. Event A — Inference interruption before a new operation is generated The protected model-access gate prevents further governed model computation, subject to its controlled path and implementation. Event B — Inference interruption after a Candidate Act has been generated but before effectuation The existing Candidate Act remains governed by the downstream Finality Sink. The model interruption does not replace required effectuation authorization. Event C — Inference interruption after an external operation has already become effective The interruption cannot retroactively prevent the completed effect. It may restrict subsequent inference or further operations according to the applicable enforcement mechanisms. The architecture therefore does not claim that control over model access alone guarantees prevention of every downstream consequence. The actual downstream Finality Sink must control the effectuation boundary applicable to the consequential operation. 11.14.28. WF-14.28 — Streaming Model Output and Partial-Action Classification in the implementation described by enforcement point 70, ME-1401 may generate a sequence of partial outputs instead of a complete result in one operation. Such outputs may include: (a) token-by-token model responses; (b) incremental structured output; (c) streaming tool-call arguments; (d) partially decoded commands; (e) partial API request bodies; Das Expires 19 April 2027 [Page 582] Internet-Draft Protected AI Execution Finality October 2026 (f) fragments of executable instructions; (g) intermediate workflow instructions; (h) partial financial operation parameters; (i) incremental actuator-control information; or (j) another partially generated consequential representation. SM-1414 determines whether a fragment constitutes: (i) non-consequential intermediate data; (ii) an incomplete Candidate Act requiring additional assembly; (iii) a completed bounded Candidate Act capable of producing a consequential effect; or (iv) an independently effective operation requiring immediate protected authorization. A streaming fragment is not assumed harmless merely because the model has not finished its complete response. 11.14.29. WF-14.29 — Non-Effective Buffering of Streaming Operations Where a partial model output may become consequential, the system controls its progression to the effectuation interface. An illustrative fragment record contains: stream_id; source_inference_id; fragment_sequence; fragment_reference; fragment_digest; candidate_act_id; assembly_state; authorized_effect_class; Das Expires 19 April 2027 [Page 583] Internet-Draft Protected AI Execution Finality October 2026 policy_epoch; finality_sink_id; status. An incomplete command may remain buffered until sufficient information exists to identify the corresponding Candidate Act. Where a bounded fragment is itself a consequential operation, it is separately subjected to the applicable protected finality procedure. The system does not require every model token to obtain an independent execution capability when those tokens remain internal computational data. The protected authorization granularity corresponds to the actual governed consequence. 11.14.30. WF-14.30 — Completed or Bounded Candidate Act Formation SM-1414 assembles or classifies streaming output into a completed or bounded Candidate Act. For example, a model may produce fragments forming an API request: Fragment 1 identifies the service. Fragment 2 identifies the requested operation. Fragment 3 identifies the recipient. Fragment 4 identifies the consequential payload. The system does not permit the assembled request to be transmitted merely because earlier fragments were generated within an admitted model session. The completed request is represented through a Candidate Act Descriptor. The applicable PED validates the concrete operation and releases the corresponding scoped capability only after the required protected conditions succeed. Das Expires 19 April 2027 [Page 584] Internet-Draft Protected AI Execution Finality October 2026 Where the authorization allows a bounded stream of repeated operations, each independently effective unit or permitted transfer window remains subject to its expressly authorized scope and usage conditions. 11.14.31. WF-14.31 — Partial-Action Finality Predicate For a governed consequential fragment or completed streaming act, an illustrative predicate is: PermitFragment = CompleteOrBounded(CA) AND AuthorityValid(CA) AND CapabilityValid(CA,F) AND StateValid(CA,S) where: PermitFragment denotes permission to effectuate the relevant fragment or bounded operation; CompleteOrBounded verifies that the operation has a sufficiently defined effectuation representation under the applicable authorization rules; AuthorityValid verifies the required protected authorization predicates; CapabilityValid verifies the applicable scoped capability at the designated Finality Sink; and StateValid verifies required current protected state. An incomplete or ambiguous operation is not treated as authorized when mandatory effectuation-relevant attributes cannot be determined. A completed operation whose required authorization conditions fail remains non-effective. 11.14.32. WF-14.32 — Multi-Sink Effectuation Classification in the implementation described by enforcement point 71, an agentic workflow may generate multiple consequential operations. For example: (a) a network transmission; (b) an authenticated tool invocation; (c) a persistent database write; Das Expires 19 April 2027 [Page 585] Internet-Draft Protected AI Execution Finality October 2026 (d) a payment instruction; and (e) an infrastructure activation command. FC-1415 identifies the relevant effectuation boundary for each operation. The classification may produce: CandidateAct_1 → Network Finality Sink; CandidateAct_2 → Tool-Execution Finality Sink; CandidateAct_3 → Database-Commit Finality Sink; CandidateAct_4 → Payment Finality Sink; CandidateAct_5 → Infrastructure-Control Finality Sink. Each operation is associated with its applicable authorization scope, protected state, and capability-verification requirements. The same model invocation or agent workflow may therefore produce several independently governed Candidate Acts. 11.14.33. WF-14.33 — Multi-Sink Authorization Independence Authorization for one Candidate Act does not automatically establish authorization for a different operation or Finality Sink. An illustrative condition is: Permit(CA_i, FS_i) = ValidCapability(CA_i, FS_i) AND RequiredStateValid(CA_i) where: CA_i denotes consequential operation i; FS_i denotes the corresponding Finality Sink; ValidCapability verifies the operation-specific capability under the applicable sink bindings; and RequiredStateValid verifies the required protected authorization state. Das Expires 19 April 2027 [Page 586] Internet-Draft Protected AI Execution Finality October 2026 A capability permitting network transmission does not inherently authorize a receiving database commit. A capability permitting document signing does not inherently authorize transmission of the signed document. A capability permitting a tool invocation does not inherently authorize a payment initiated by that tool. Where a capability expressly authorizes multiple bounded phases, each designated phase and Finality Sink enforces the applicable scope and state conditions. 11.14.34. WF-14.34 — Receiving-Side and Remote Finality Sink in the implementation described by enforcement point 72, FS-1416 may comprise: (a) a receiving service; (b) a remote execution gateway; (c) a protected database-commit interface; (d) a payment execution interface; (e) a hardware actuator; (f) a trusted connector; or (g) another remote or downstream consequential boundary. The receiving-side Finality Sink obtains or reconstructs the Candidate Act actually presented for effectuation. The Finality Sink verifies the operation-specific capability and required protected validation-state commitment. It does not rely solely upon an upstream agent or gateway asserting that the operation was approved. The receiving-side verifier may be implemented through protected service logic, an authenticated gateway, transaction controller, trusted hardware interface, or other enforcement arrangement satisfying the applicable non-bypassable requirements. Das Expires 19 April 2027 [Page 587] Internet-Draft Protected AI Execution Finality October 2026 11.14.35. WF-14.35 — Remote Actual-Operation Reconstruction RV-1417 determines the effectuation-relevant attributes of the remote operation. These may include: (a) actual operation type; (b) recipient or target; (c) destination service identity; (d) transaction parameters; (e) resource identifier; (f) requested state transition; (g) payload digest; (h) protected authorization-state version; (i) authorized execution scope; and (j) receiving Finality Sink identity. A non-limiting reconstructed descriptor is: Dremote = Canon_v(OperationActual, RecipientActual, ParametersActual, StateActual, SinkActual) where: Dremote denotes the actual remote operation descriptor; OperationActual denotes the requested operation; RecipientActual denotes the actual receiving entity; ParametersActual denotes the effectuation-relevant parameters; StateActual denotes applicable receiving-side authorization state; and SinkActual denotes the receiving Finality Sink. Das Expires 19 April 2027 [Page 588] Internet-Draft Protected AI Execution Finality October 2026 The verifier compares the reconstructed descriptor with the applicable authenticated capability commitment. Where exact correspondence is required, a mismatch causes denial. Where the original authorization expressly permits bounded variations, the verifier checks those variations against the defined permitted scope. 11.14.36. WF-14.36 — Receiving-Side Verification Predicate An illustrative remote verification condition is: PermitRemote = Auth(C) AND Match(C,Dremote) AND ReceiptValid(C,R) AND StateValid(C,Sremote) AND SinkValid(C,Fremote) where: PermitRemote denotes permission to perform the remote consequential operation; C denotes the operation-specific capability; Dremote denotes the reconstructed actual Candidate Act Descriptor; R denotes the required protected validation evidence; Sremote denotes current authorization state required at the receiving side; and Fremote denotes the designated receiving Finality Sink. The operation is refused where a mandatory parameter differs, including an unauthorized: (a) destination; (b) recipient; (c) operation type; (d) protected-state version; or (e) execution scope. The receiving service does not automatically accept a valid-looking upstream authorization artifact when the actual effectuation context fails a mandatory binding. Das Expires 19 April 2027 [Page 589] Internet-Draft Protected AI Execution Finality October 2026 11.14.37. WF-14.37 — Illustrative End-to-End AI-Agent Transaction In one concrete embodiment, an AI agent uses an authorized model to prepare a financial transfer request. The proposed model invocation is submitted to MG-1402. The model-access gate verifies the requesting workload, model identity, approved computation context, and required policy state. The request is admitted to ME-1401. The model generates a proposed transfer involving a specified recipient, amount, currency, and payment service. OC-1406 classifies the proposed transfer as a Candidate Act. HQ-1407 retains the transfer in a Non-Effective State. DC-1408 constructs an operation-specific descriptor identifying the actual recipient, amount, currency, execution purpose, authority scope, policy epoch, and payment Finality Sink. PED-1409 authenticates the applicable transaction authority and validates the mandatory predicates. The PED performs required protected authorization-state operations. EV-1411 commits the operation-specific validation evidence. CR-1412 makes available a scoped execution capability bound to the transaction and designated payment Finality Sink. The payment execution interface independently obtains the actual transaction information. The payment Finality Sink verifies the scoped capability against the recipient, amount, current protected state, evidence reference, and required usage conditions. Only the matching authorized transaction is permitted. If the model subsequently loses access to the inference service, that event does not independently establish that the payment was cancelled or completed. The payment interface continues to enforce the authorization rules applicable to the actual pending transaction. Das Expires 19 April 2027 [Page 590] Internet-Draft Protected AI Execution Finality October 2026 11.14.38. WF-14.38 — Illustrative Model-Interruption Attack An autonomous agent obtains valid model-access authorization. The model generates a proposed operation to transmit protected enterprise data. The proposed transmission is buffered. A security watchdog subsequently detects suspicious runtime behavior and revokes further model access. The model-access gate stops additional governed inference. However, the buffered transmission remains present within the downstream execution environment. If that buffered transmission could reach an unrestricted network interface, interruption of model access alone would not prove prevention of the external transmission. Under the specified dual-authorization architecture, the buffered operation remains non-effective until the network Finality Sink verifies its operation-specific execution capability. If the capability is missing, invalid, revoked, expired, or inconsistent with the actual transmitted request, the network Finality Sink refuses transmission. The outcome demonstrates the difference between stopping further model computation and preventing a particular downstream effect. 11.14.39. WF-14.39 — Illustrative Multi-Sink Workflow An AI agent performs a workflow involving: (a) retrieving permitted source information; (b) generating a proposed database update; (c) requesting a payment; and (d) issuing an external notification. The model-access gate authorizes the required computation. The protected operation-classification component identifies separate Candidate Acts for the governed consequential stages. Das Expires 19 April 2027 [Page 591] Internet-Draft Protected AI Execution Finality October 2026 The applicable Finality Sinks may comprise: (a) network egress for the retrieval or outbound request; (b) database-commit interface for the persistent update; (c) payment execution interface for the transfer; and (d) communication gateway for the notification. Each consequential operation receives its own required protected authorization. A capability permitting the database update cannot independently authorize the payment. Likewise, successful payment authorization does not automatically authorize transmission of unrelated protected data through the notification gateway. The workflow progresses according to its applicable operation- specific authorization conditions. 11.14.40. WF-14.40 — Protected Capability Consumption and Replay Prevention Where the operation-specific capability is single-use or usage- bounded, the downstream Finality Sink performs or coordinates the required protected capability-consumption procedure. A representative state record comprises: capability_id; candidate_act_digest; source_inference_reference; authorized_effect_class; finality_sink_id; remaining_uses; state_version; status. Das Expires 19 April 2027 [Page 592] Internet-Draft Protected AI Execution Finality October 2026 The protected consumption mechanism prevents incompatible concurrent operations from independently consuming the same restricted authorization. A previously consumed single-use capability is rejected upon unauthorized replay. Where bounded repeated use is expressly permitted, the corresponding scope, validity, and usage restrictions are enforced. A computation-admission record or model-session identifier does not substitute for the protected consumption state required for a downstream operation. 11.14.41. WF-14.41 — Crash, Retry, and Recovery The system distinguishes failures at the model-access boundary from failures at the downstream effectuation boundary. Failure before model admission: Further governed computation does not begin without the required computation-admission authority. Failure after model admission but before Candidate Act generation: No downstream consequential operation is inferred merely from the existence of the admission record. Failure after Candidate Act generation but before protected evidence commitment: The act remains non-effective and no valid corresponding downstream capability is made available. Failure after protected evidence commitment but before capability delivery: The system consults the committed authorization and capability state before recovery or reissuance. Failure after downstream capability availability but before effectuation: The Finality Sink verifies current protected authorization and consumption state before any permitted continuation. Failure after possible remote effectuation: The system distinguishes a confirmed completed operation from a failed or indeterminate operation. An operation having uncertain completion status is not automatically replayed when unauthorized duplicate effectuation could result. Das Expires 19 April 2027 [Page 593] Internet-Draft Protected AI Execution Finality October 2026 Where available, remote idempotency records, authenticated completion receipts, transaction-status queries, or protected receiving-side state may support reconciliation. The architecture does not assert unconditional exactly-once completion across arbitrary remote systems. 11.14.42. WF-14.42 — Alternative Structural Implementations The dual-boundary architecture may be implemented through several non-limiting arrangements. Single-node implementation: A protected server performs model-access authorization and downstream act-finality verification through distinguishable functions within the same node. Separated-server implementation: A model-access gateway controls inference while another protected authority and Finality Sink govern external operations. Confidential-computing implementation: The computation environment or protected authority operates inside a confidential VM, secure enclave, or equivalent protected domain, with separate enforcement at the downstream effectuation interface. Hardware-assisted implementation: A SmartNIC, DPU, or protected network controller may govern a designated model or network access path, while a separate payment, storage, tool, or actuator Finality Sink controls the corresponding downstream consequential operation. Receiving-side implementation: A remote gateway or protected service verifies operation-specific authority before completing the governed receiving-side operation. Streaming implementation: A model-output controller buffers partial outputs until their corresponding bounded consequential acts satisfy the required finality checks. Multi-agent implementation: A parent agent or sub-agent may generate a Candidate Act, but the delegated task or computation context does not independently authorize the consequential operation. Multi-sink implementation: A complex workflow uses different Finality Sinks for network, storage, financial, tool-execution, or physical effects. The selected implementation determines the actual trust boundary, bypass resistance, revocation latency, and failure assumptions. Das Expires 19 April 2027 [Page 594] Internet-Draft Protected AI Execution Finality October 2026 A hardware model-access gate does not automatically provide downstream effectuation guarantees for interfaces it does not control. 11.14.43. WF-14.43 — Failure and Fail-Closed Conditions The system refuses the governed operation when a mandatory condition is absent, invalid, expired, revoked, replayed, inconsistent, or unverifiable. Non-limiting conditions include: (a) missing model-computation admission authority; (b) invalid workload identity; (c) unauthorized requested model; (d) invalid approved computation context; (e) revoked model-access authorization; (f) missing Candidate Act Descriptor; (g) failed downstream operation classification; (h) unavailable required Non-Effective State holding mechanism; (i) invalid inference-to-act context where required; (j) invalid operation-specific Authority Object; (k) unauthorized destination or recipient; (l) prohibited operation type; (m) failed protected-state transition; (n) failed required validation-evidence commitment; (o) missing operation-specific execution capability; (p) invalid capability authentication; (q) policy epoch mismatch; (r) invalid revocation state; Das Expires 19 April 2027 [Page 595] Internet-Draft Protected AI Execution Finality October 2026 (s) expired nonce; (t) replayed or consumed capability; (u) unauthorized Finality Sink substitution; (v) mismatch between actual remote operation and authorized descriptor; (w) incomplete streaming operation where complete parameters are mandatory; (x) unavailable required receiving-side state; (y) failed downstream capability verification; or (z) failure of the mandatory enforcement path. The corresponding Candidate Act remains non-effective, denied, quarantined, or subject to a separately authorized recovery or escalation process. An interruption of model inference does not create authority to release buffered downstream operations. 11.14.44. WF-14.44 — PHOSITA Verification and Negative Tests A person having ordinary skill in AI model-serving systems, agent orchestration, distributed authorization, cryptography, network security, transaction processing, or protected computing may test the architecture through the following cases. Test 1 — Authorized model request: Present a computation request satisfying the required model, workload, context, and policy conditions. The model-access gate admits the computation. Test 2 — Unauthorized model request: Request a prohibited model. The model-access gate refuses computation. Test 3 — Downstream missing capability: Successfully admit the model, then submit a consequential operation without an operation-specific capability. The downstream Finality Sink refuses the operation. Test 4 — Inference-to-act mismatch: Associate a Candidate Act with an incompatible computation-admission record where that binding is mandatory. Protected authorization fails. Das Expires 19 April 2027 [Page 596] Internet-Draft Protected AI Execution Finality October 2026 Test 5 — Destination substitution: Authorize one network recipient and present a different destination at the Finality Sink. Verification fails. Test 6 — Operation substitution: Authorize a read operation and attempt a write operation using the same capability. Required operation correspondence fails. Test 7 — Model interruption with buffered act: Interrupt further model inference after an external operation has been buffered. Confirm that the buffered act remains subject to downstream capability verification. Test 8 — Streaming partial command: Present an incomplete command that lacks required effectuation parameters. The operation is withheld. Test 9 — Completed streaming command: Assemble an authorized bounded Candidate Act and verify its corresponding capability before effectuation. Test 10 — Streaming payload mutation: Modify a required command or payload field after authorization. The Finality Sink rejects the mismatch. Test 11 — Multiple Finality Sinks: Authorize a network transmission and attempt to reuse the capability for a database commit. The database Finality Sink refuses unauthorized reuse. Test 12 — Remote recipient mismatch: Present the capability to a remote executor operating on a different recipient. Remote verification fails. Test 13 — Remote protected-state mismatch: Present a valid-looking capability referencing an incompatible protected-state version. Effectuation is refused. Test 14 — Model-access revocation: Revoke the model-access grant. Further governed inference is blocked, while existing Candidate Acts remain governed by their downstream authorization conditions. Test 15 — Policy-epoch mismatch: Present a downstream capability inconsistent with the current mandatory policy epoch. The Finality Sink refuses it. Test 16 — Capability replay: Reuse a consumed single-use operation capability. Protected usage verification rejects the attempt. Das Expires 19 April 2027 [Page 597] Internet-Draft Protected AI Execution Finality October 2026 Test 17 — Concurrent operation attempts: Submit two incompatible effects using the same restricted authorization state. The protected mechanism prevents unauthorized double consumption. Test 18 — Wrong Finality Sink: Present a capability bound to one sink at a different sink. Required sink binding fails. Test 19 — Receiving-side descriptor reconstruction: Submit a remote operation with authorized parameters. Verify that the receiving service independently reconstructs and checks the corresponding operation descriptor. Test 20 — Model gate bypass: Attempt access to the governed model service through an alternate route. The admission requirement remains enforced within the specified path coverage. Test 21 — Downstream path bypass: Attempt to effectuate the consequential operation through an alternative execution interface. The required Finality Sink cannot be bypassed under the specified threat model. Test 22 — Upstream allow-only design: Provide a successful model- access authorization but no separate valid downstream execution capability. The consequential operation remains blocked. Test 23 — Quarantine after completed effect: Trigger model quarantine after a remote operation has already completed. Confirm that the system does not falsely report the previous effect as prevented. Test 24 — Crash before evidence commitment: Interrupt the protected downstream transaction before required commitment. No valid operation-specific capability becomes available. Test 25 — Crash after possible remote execution: Interrupt communication after the receiving service may have completed the operation. Recovery distinguishes indeterminate status from confirmed failure. Test 26 — Multi-hop workflow: Authorize an upstream network effect and attempt an unrelated downstream commit without its required capability. The downstream Finality Sink refuses it. Test 27 — Single-node dual authorization: Implement both authorization functions within one protected node and verify that model-admission authorization does not bypass downstream effectuation checks. Das Expires 19 April 2027 [Page 598] Internet-Draft Protected AI Execution Finality October 2026 Test 28 — Distributed dual authorization: Place the model-access gate and receiving-side Finality Sink on separate nodes. Verify that each independently enforces its required authority. Test 29 — Protected context substitution: Change the computation- admission reference attached to a Candidate Act. Required authenticated context binding fails. Test 30 — Failure of model-path controls: Disable the model-access gate after an already generated Candidate Act exists. Verify that the downstream Finality Sink continues to enforce the applicable protected execution-finality requirements independently of model-path availability. The tests may employ simulated inference gateways, AI-agent runtimes, controllable tool executors, model-output stream generators, protected authorization services, mock payment systems, test databases, receiving-side gateways, programmable Finality Sinks, and fault-injection mechanisms. The observed guarantees depend upon the actual implemented enforcement paths and protected-state mechanisms. 11.14.45. WF-14.45 — Claim-Specific Technical Support Enforcement Point 68 — Model-Path and Effectuation-Path Dual Authorization System The workflow describes: (a) ME-1401 receiving governed model-computation requests; (b) MG-1402 verifying computation-admission authorization; (c) AE-1405 generating consequential operations from admitted computation; (d) OC-1406 and HQ-1407 classifying and holding resulting Candidate Acts; (e) PED-1409 validating the concrete operation descriptor, authority, protected policy state, and intended effectuation boundary; (f) EV-1411 committing operation-specific validation evidence before, or atomically with, capability availability; (g) CR-1412 releasing the required scoped operation-specific capability; Das Expires 19 April 2027 [Page 599] Internet-Draft Protected AI Execution Finality October 2026 (h) FS-1416 independently verifying the capability before effectuation; (i) separation between model-access authorization and downstream execution authorization; and (j) preservation of downstream authorization requirements after model-access interruption or revocation. Enforcement Point 69 — Inference-to-Act Context Binding WF-14.8, WF-14.9, and WF-14.13 provide a protected computation- admission record comprising model identity, workload identity, approved execution context, policy epoch, and authorization-state identifier. The record is cryptographically associated with the downstream Candidate Act without replacing operation-specific execution authority. Enforcement Point 70 — Streaming Output and Partial-Action Control WF-14.28 through WF-14.31 describe streaming outputs, tool-call fragments, partial command representations, completed or bounded Candidate Act formation, and withholding of consequential fragments until the required downstream capability verifies. Interruption of future inference does not automatically authorize release of previously buffered operations. Enforcement Point 71 — Multi-Sink Effectuation Classification WF-14.32 and WF-14.33 classify consequential operations according to their applicable effectuation boundaries. A capability for one operation or Finality Sink does not independently authorize another operation or sink. Enforcement Point 72 — Remote Effectuation Verification WF-14.34 through WF-14.36 describe receiving-side reconstruction or verification of the actual Candidate Act and verification against the operation-specific capability and required protected validation-state commitment. Unauthorized changes to recipient, destination, operation type, protected-state version, or execution scope cause refusal where those fields are mandatory. Das Expires 19 April 2027 [Page 600] Internet-Draft Protected AI Execution Finality October 2026 11.14.46. WF-14.46 — Technical Effect The disclosed workflow establishes two protected authorization relationships. The first governs admission of a proposed model computation. The second governs the transition of a model-derived Candidate Act into an externally effective operation. The operative protected sequence includes: (a) generation of a proposed inference request; (b) verification of computation-admission authority at the model- access gate; (c) creation of an authenticated computation-admission context; (d) controlled model computation; (e) classification of consequential operations derived from the computation; (f) maintenance of each governed Candidate Act in a Non-Effective State; (g) construction of an operation-specific Candidate Act Descriptor; (h) protected validation of actual operation, execution authority, policy state, scope, and designated Finality Sink; (i) required protected-state handling; (j) protected validation-evidence commitment; (k) release or availability of the operation-specific execution capability; (l) independent verification at the downstream effectuation boundary; (m) capability-consumption and replay-prevention handling where required; and (n) controlled external effectuation or fail-closed withholding. Das Expires 19 April 2027 [Page 601] Internet-Draft Protected AI Execution Finality October 2026 The architecture prevents authorization to access an AI model from being treated as unrestricted authority to carry out actions derived from that model. The streaming embodiment prevents consequential fragments or buffered operations from escaping the required downstream authorization merely because inference was interrupted or a partial output was generated. The multi-sink embodiment preserves separate authorization for separate consequential boundaries. The remote verification embodiment requires the receiving Finality Sink to verify the concrete operation presented for effectuation instead of merely relying upon upstream approval. A model-access choke point may prevent further governed inference, but it is not presumed to control every downstream network, database, payment, deployment, or physical-actuation interface. The stronger protected effectuation guarantee arises from the actual downstream capability-dependent Finality Sink verification. Computation is not authority to act. Authorization to access a model is not authorization to execute its output. Stopping future inference is not equivalent to preventing an already prepared external operation. An upstream authorization does not replace downstream execution- finality verification. 11.15. WF-15 — Protected Cross-Domain AI-Fabric Transfer Finality, GPU/TPU/NPU Accelerator Isolation, Hardware-Latched DMA and Interconnect Admission, Continuous Tensor-Stream Authorization, Hardware Freshness, and Line-Rate Capability Verification 11.15.1. WF-15.1 — Technical Purpose This embodiment describes a computer-implemented, hardware-assisted protected execution-finality architecture for governing the transfer, replication, routing, switching, copying, export, admission, or delivery of artificial-intelligence computation state between compute, accelerator, memory, network-fabric, or other protected execution domains. Das Expires 19 April 2027 [Page 602] Internet-Draft Protected AI Execution Finality October 2026 The technical objective is to prevent an accelerator or associated computational workload from converting its ability to generate or possess computation data into unrestricted authority to transfer that data across a governed fabric-finality boundary. The protected computation data may comprise: (a) model parameters; (b) tensors; (c) key-value cache data; (d) gradients; (e) activations; (f) embeddings; (g) inference context; (h) checkpoint state; (i) model intermediate results; (j) accelerator-resident memory content; (k) agent-generated tool or control representations; or (l) other governed artificial-intelligence computation data. A proposed cross-domain transfer is classified as a Candidate Fabric Transfer Act. The Candidate Fabric Transfer Act remains in a Non-Effective State until the applicable Protected Enforcement Domain (PED/CIED) validates the required Cross-Domain Fabric Authorization Object, performs applicable protected authorization-state operations, generates or commits protected transfer-validation evidence, and releases or makes available a scoped Fabric Transfer Capability. A hardware-associated fabric Finality Sink independently verifies the capability before enabling the governed transfer. The transfer cannot cross its controlled effectuation boundary when the required capability is absent, invalid, expired, revoked, replayed, consumed, or inconsistent with the authorized operation. Das Expires 19 April 2027 [Page 603] Internet-Draft Protected AI Execution Finality October 2026 The architecture separates: (a) accelerator computation; (b) possession of computation data; (c) preparation of a cross-domain transfer; (d) protected authorization of the specific transfer; (e) release of bounded transfer authority; and (f) actual hardware-associated admission, forwarding, switching, copying, or delivery. Computation is not authority to transfer. 11.15.2. WF-15.2 — Participating Technical Components In one non-limiting embodiment, the system comprises: AC-1501 — Source Accelerator or Compute Domain A GPU, TPU, NPU, CPU, FPGA, AI accelerator, accelerator partition, compute node, confidential workload, or equivalent component producing or holding governed computation data. DC-1502 — Destination Compute or Memory Domain A destination accelerator, memory region, compute node, network domain, protected workload, processing partition, or other receiving domain. FI-1503 — Fabric Transfer Interception Component A NIC, SmartNIC, DPU, accelerator interconnect controller, fabric switch, memory-fabric gateway, optical interconnect controller, accelerator-management component, or equivalent mechanism configured to intercept or prevent an unverified transfer. HQ-1504 — Non-Effective Transfer Holding Mechanism A controlled buffer, DMA descriptor queue, fabric admission queue, protected memory region, sealed output store, inactive transfer descriptor, or other mechanism maintaining a proposed transfer before effectuation. DF-1505 — Candidate Fabric Transfer Descriptor Component Das Expires 19 April 2027 [Page 604] Internet-Draft Protected AI Execution Finality October 2026 A component configured to construct or verify a machine-readable descriptor of the proposed transfer and its effectuation-relevant context. PED-1506 — Protected Enforcement Domain A protected component configured to authenticate the applicable Cross-Domain Fabric Authorization Object, validate required authority predicates, perform or verify protected-state operations, commit required validation evidence, and control Fabric Transfer Capability availability. AS-1507 — Cross-Domain Fabric Authority Store An authenticated or protected mechanism maintaining permitted source and destination domains, data classifications, workload relationships, routes, transfer limits, jurisdiction conditions, policy state, and other authorized fabric-transfer conditions. PS-1508 — Protected Fabric Authorization-State Store A protected mechanism maintaining authorization grants, nonce state, revocation state, fabric epochs, hardware freshness, transfer quotas, capability usage, validation commitments, and required fabric-state references. EV-1509 — Fabric Validation-Evidence Component A mechanism generating or committing a Fabric Transfer LAVR, ZK-LAVR, authenticated validation record, sealed receipt, or equivalent protected evidence. CR-1510 — Fabric Transfer Capability Mechanism A protected component configured to generate, register, derive, release, or activate a bounded Fabric Transfer Capability. HL-1511 — Hardware Finality Latch A hardware-controlled enabling or admission mechanism preventing the governed transfer from entering or crossing the relevant fabric interface until required authorization verification succeeds. FS-1512 — Fabric Finality Sink Das Expires 19 April 2027 [Page 605] Internet-Draft Protected AI Execution Finality October 2026 A hardware-associated admission queue, fabric lane, switching pipeline, DMA controller, accelerator memory-access controller, network-forwarding interface, optical controller, or cross-domain delivery boundary that verifies the required capability before effectuation. HF-1513 — Hardware Freshness Component A protected counter, fabric sequence number, trusted time source, switch-state generation, boot epoch, or equivalent hardware-protected state mechanism. RM-1514 — Continuous Transfer and Route Monitor A mechanism configured to observe or validate transfer-unit progression, authorized workload graph, transfer size, destination, and route state. FV-1515 — Fast-Path Capability Verification Component A bounded-time local verifier that checks an authenticated fabric admission entry, protected capability lookup, sequence number, route grant, or equivalent transfer-enablement state. OS-1516 — Fabric Transfer Outcome-State Component A protected mechanism maintaining pending, reserved, admitted, completed, denied, revoked, expired, or indeterminate transfer status. The described functions may be integrated into one protected accelerator controller or distributed across multiple accelerator, memory, fabric, network, or hardware security components. Functional distinction does not necessarily require a physically separate component for every identified role. 11.15.3. WF-15.3 — Establishment of the Accelerator and Fabric Trust Boundaries The system establishes one or more protected boundaries between computation domains capable of generating or holding protected data and the interfaces capable of transferring that data to another domain. A governed transfer boundary may comprise: (a) accelerator memory to host memory; Das Expires 19 April 2027 [Page 606] Internet-Draft Protected AI Execution Finality October 2026 (b) one accelerator to another accelerator; (c) accelerator memory to an external network interface; (d) device-local memory to shared fabric memory; (e) a PCIe or CXL transfer interface; (f) an accelerator-to-interconnect boundary; (g) a protected tensor store to a remote computation node; (h) a DMA or RDMA transfer interface; (i) a switch ingress or egress pipeline; (j) an optical interconnect interface; or (k) another consequential cross-domain delivery boundary. The source compute domain may possess and operate on protected data without possessing authority to transfer it through the governed boundary. The system identifies all effectuation paths relevant to the specified transfer class. Where a mandatory non-bypassable property is required, the source workload cannot circumvent the protected interface using an alternative device, queue, DMA mapping, fabric route, host-copy operation, or direct network interface capable of producing the same governed effect. Actual path coverage must be enforced through suitable hardware, firmware, hypervisor, memory-protection, IOMMU, switch-control, or other mechanisms appropriate to the implementation. 11.15.4. WF-15.4 — Hardware-Assisted Enforcement Configuration In an implementation using accelerator and fabric hardware, the system configures the selected transfer interfaces so that the requesting workload cannot independently enable protected cross- domain movement. An illustrative configuration may comprise: (a) restricted DMA mappings; Das Expires 19 April 2027 [Page 607] Internet-Draft Protected AI Execution Finality October 2026 (b) protected accelerator memory regions; (c) fabric-switch admission rules; (d) protected queue-pair creation; (e) controlled memory-window permissions; (f) device-side transfer authorization; (g) protected interconnect route entries; (h) hardware-controlled output buffers; (i) protected device security registers; or (j) a hardware transfer-enable latch. The actual implementation determines whether an operation is blocked at submission, queue admission, descriptor consumption, memory mapping, routing, switching, or data delivery. The presence of a hardware component does not independently establish non-bypassability. The component must control the relevant transfer path and enforce the required authorization relationship. 11.15.5. WF-15.5 — Definition of the Governed Transfer Effect For this embodiment, a Candidate Fabric Transfer Act becomes effective when the specified protected computation data crosses the governed fabric-finality boundary or acquires the corresponding authorized delivery or access consequence. The applicable effect may comprise: (a) DMA copying into another memory protection domain; (b) fabric switching to another accelerator; (c) RDMA transfer to a remote compute node; (d) release from protected accelerator memory; (e) activation of an authorized memory mapping; (f) forwarding through a protected fabric route; Das Expires 19 April 2027 [Page 608] Internet-Draft Protected AI Execution Finality October 2026 (g) replication of governed tensor state; or (h) another defined transfer consequence. An operation does not have to leave a physical server to become externally effective. A transfer from one protected GPU memory partition into a differently authorized memory domain may constitute a governed consequential effect. The authorization boundary is selected according to the actual security and data-governance requirement. 11.15.6. WF-15.6 — Generation of the Candidate Fabric Transfer Act AC-1501 executes an AI computation, training operation, inference process, or other permitted workload. The workload proposes transfer of protected computation data to DC- 1502. An illustrative request identifies: transfer_id; source_compute_domain; destination_compute_domain; source_memory_region; destination_memory_region; computation_data_class; transfer_operation; data_reference; transfer_size; fabric_route; workload_identity; policy_epoch. Das Expires 19 April 2027 [Page 609] Internet-Draft Protected AI Execution Finality October 2026 The proposed operation is classified as Candidate Fabric Transfer Act CFTA-1517. The classification does not imply that the transfer has been authorized. The transfer remains subject to protected validation and fabric Finality Sink verification. 11.15.7. WF-15.7 — Interception and Non-Effective Transfer Staging FI-1503 intercepts or controls CFTA-1517 before the governed transfer occurs. HQ-1504 maintains the proposed transfer in a Non-Effective State. An illustrative pending transfer record comprises: transfer_id; source_domain_id; destination_domain_id; source_buffer_reference; destination_buffer_reference; transfer_operation; transfer_size; candidate_descriptor_reference; policy_epoch; fabric_sink_id; status = NON_EFFECTIVE. The source data may remain resident within accelerator memory. Alternatively, the system may retain an inactive transfer descriptor, blocked DMA command, disabled queue entry, or authenticated buffer reference. The arrangement prevents the transfer operation from becoming effective while mandatory authorization conditions remain unresolved. Das Expires 19 April 2027 [Page 610] Internet-Draft Protected AI Execution Finality October 2026 Merely recording the transfer request in a queue is insufficient if another accessible interface can perform the same protected transfer without verification. 11.15.8. WF-15.8 — Candidate Fabric Transfer Act Descriptor Formation DF-1505 constructs a descriptor representing the proposed transfer and its effectuation-relevant context. The descriptor identifies at least: (a) source compute domain; (b) destination compute domain; (c) computation-data class; (d) requested transfer operation; and (e) applicable fabric-finality boundary. The descriptor may also identify: source_accelerator_measurement; destination_accelerator_measurement; workload_identity; tenant_identity; model_identity; tensor_class; memory_region; transfer_size; collective_operation_type; fabric_route; switch_identity; jurisdiction; approved_workload_graph_reference; Das Expires 19 April 2027 [Page 611] Internet-Draft Protected AI Execution Finality October 2026 runtime_transfer_envelope; policy_epoch; nonce; expiry; fabric_finality_sink_identity. Only fields required by the corresponding Authority Object or specified embodiment are mandatory. The descriptor distinguishes the actual requested cross-domain transfer from a general authorization to execute the source AI workload. 11.15.9. WF-15.9 — Canonical Transfer Descriptor Encoding In an illustrative cryptographic implementation, DF-1505 encodes the descriptor deterministically. A non-limiting expression is: Dfabric = Canon_v(SRC, DST, DATA, OP, REGION, SIZE, ROUTE, CONTEXT, EPOCH, F) where: Dfabric denotes the canonical fabric-transfer descriptor; Canon_v denotes deterministic canonical encoding under version v; SRC denotes the verified source domain; DST denotes the destination domain; DATA denotes the protected computation-data class or identity; OP denotes the requested transfer operation; REGION denotes the relevant protected memory region; SIZE denotes the authorized transfer size or bound; ROUTE denotes the required fabric route; Das Expires 19 April 2027 [Page 612] Internet-Draft Protected AI Execution Finality October 2026 CONTEXT denotes applicable workload, accelerator, tenant, and runtime context; EPOCH denotes protected authorization-state information; and F denotes the designated fabric Finality Sink. An illustrative commitment is: hFabric = H("DAS-FABRIC-TRANSFER-v1" || Encode(Dfabric)) where H denotes a cryptographic hash function. The selected encoder maintains unambiguous field interpretation and preserves distinctions affecting authorization. The protected authorizer and Finality Sink employ corresponding interpretation rules. The formula is a non-limiting implementation elaboration. 11.15.10. WF-15.10 — Acquisition of Cross-Domain Fabric Authority PED-1506 obtains or resolves the applicable Cross-Domain Fabric Authorization Object from AS-1507. The Authority Object may identify: (a) authorized source domains; (b) authorized destination domains; (c) permitted computation-data classifications; (d) approved workload identities; (e) permitted tenant relationships; (f) approved workload or collective-operation graphs; (g) permitted memory regions; (h) transfer-size limits; (i) permitted fabric routes; (j) jurisdictional restrictions; Das Expires 19 April 2027 [Page 613] Internet-Draft Protected AI Execution Finality October 2026 (k) runtime transfer envelopes; (l) authorized switch or interconnect classes; (m) required hardware measurements; (n) policy epochs; (o) revocation and freshness requirements; and (p) permitted fabric Finality Sinks. The PED authenticates the Authority Object and verifies its applicability to the proposed transfer. The requesting AI workload cannot independently widen cross-domain authority merely by selecting a different memory address, route, queue, or transfer descriptor. 11.15.11. WF-15.11 — Source-Domain Authority Validation PED-1506 verifies the authority associated with the source compute domain. The validation may require: (a) authenticated source workload identity; (b) permitted source accelerator; (c) source security-domain identity; (d) authorized tensor or memory region; (e) approved model or workload class; (f) required accelerator attestation; (g) permitted source data classification; and (h) applicable protected authorization state. Where exact source accelerator measurement is required, the protected mechanism verifies the authenticated measurement rather than relying upon an untrusted software description. Das Expires 19 April 2027 [Page 614] Internet-Draft Protected AI Execution Finality October 2026 A workload permitted to compute on an accelerator does not automatically acquire authority to export every tensor or memory region held by that accelerator. 11.15.12. WF-15.12 — Destination-Domain Authority Validation PED-1506 separately evaluates the proposed destination domain. The validation may require: (a) authenticated destination identity; (b) permitted destination accelerator or memory controller; (c) authorized receiving workload; (d) permitted tenant; (e) destination memory protection state; (f) permitted data classification; (g) destination jurisdiction; (h) approved receiving model or computation class; and (i) required attestation or protected-state predicates. A valid source-domain authorization does not establish destination- domain authorization merely because the source can address or connect to the destination. The transfer is refused when the actual destination does not satisfy a mandatory receiving-domain predicate. 11.15.13. WF-15.13 — Computation-Data Classification The protected system identifies the category or classification of data proposed for transfer. The classification may distinguish: (a) model weights; (b) model parameters; (c) gradients; Das Expires 19 April 2027 [Page 615] Internet-Draft Protected AI Execution Finality October 2026 (d) activation tensors; (e) key-value cache state; (f) embeddings; (g) intermediate inference results; (h) checkpoint material; (i) privileged model state; (j) personal or regulated data; (k) confidential enterprise data; and (l) other protected computation information. Where data classification forms part of mandatory authorization, the PED verifies that the proposed data class is permitted for the destination and operation. A general permission to exchange model parameters does not automatically authorize transmission of protected inference context or confidential key-value cache data. 11.15.14. WF-15.14 — Approved Workload Graph and Transfer Envelope Where required, the PED evaluates the proposed operation against an approved workload graph or runtime transfer envelope. The graph may identify: (a) authorized participating accelerators; (b) permitted compute nodes; (c) approved dataflow edges; (d) allowed collective-operation classes; (e) permitted source-destination relationships; (f) authorized tensor classes; (g) expected transfer phases; (h) maximum transfer size; Das Expires 19 April 2027 [Page 616] Internet-Draft Protected AI Execution Finality October 2026 (i) permitted fabric paths; and (j) other bounded workflow relationships. A runtime transfer envelope may define acceptable transfer units, sizes, timing windows, destination groups, sequence rules, or data- class restrictions. The PED validates the proposed transfer under the applicable graph and envelope conditions. A transfer outside the authorized graph is not permitted merely because it is technically routable through the fabric. 11.15.15. WF-15.15 — Fabric Route and Switch Validation The protected system verifies the selected fabric route when route identity is a mandatory authorization predicate. The applicable route may comprise: (a) a NIC or SmartNIC path; (b) a DPU-controlled network segment; (c) an accelerator interconnect; (d) an NVLink-class or equivalent accelerator fabric; (e) a PCIe or CXL path; (f) an optical interconnect; (g) a memory-fabric gateway; (h) a switch pipeline; or (i) another permitted transfer path. The descriptor or Authority Object may identify exact routes, permitted path classes, switch identities, route epochs, or approved destination sets. Where the actual selected route differs from the required authorized route, the previous authorization does not automatically remain valid. Das Expires 19 April 2027 [Page 617] Internet-Draft Protected AI Execution Finality October 2026 The Finality Sink verifies the route attributes available and required at its controlled boundary. The system does not presume visibility of intermediate hardware or remote routing state that the implementation cannot authenticate. 11.15.16. WF-15.16 — Protected Fabric Authorization Predicate PED-1506 evaluates the mandatory authorization predicates applicable to CFTA-1517. An illustrative conjunctive predicate is: Vfabric = Psource AND Pdestination AND Pdata AND Pgraph AND Proute AND Penvelope AND Pstate where: Vfabric denotes the protected transfer-authorization result; Psource verifies source-domain authority; Pdestination verifies destination-domain authority; Pdata verifies computation-data classification; Pgraph verifies the approved workload graph; Proute verifies the authorized fabric route; Penvelope verifies required transfer-size, phase, and runtime conditions; and Pstate verifies current policy, revocation, freshness, and protected authorization state. Where additional hardware measurements or jurisdiction conditions are mandatory, they are included in the protected validation procedure. Where threshold or approved alternative authorization conditions apply, the PED evaluates them according to the applicable protected policy. Failure of any mandatory predicate prevents issuance or availability of the corresponding Fabric Transfer Capability. Das Expires 19 April 2027 [Page 618] Internet-Draft Protected AI Execution Finality October 2026 11.15.17. WF-15.17 — Protected Fabric Authorization-State Handling Following successful protected predicate validation, PED-1506 performs the required protected-state operations. Such operations may include: (a) verification of the current fabric policy epoch; (b) verification of revocation state; (c) reservation of a transfer grant; (d) allocation of a bounded transfer allowance; (e) consumption or registration of a nonce; (f) registration of a permitted source-destination pair; (g) advancement of a fabric sequence number; (h) protected transfer quota handling; (i) registration of a route grant; (j) reservation of a capability identifier; or (k) another required authorization-state transition. Where a restricted grant is single-use, protected state prevents two incompatible transfers from independently consuming the same authorization. Where the transfer is explicitly bounded across multiple units, the protected system maintains the corresponding usage, sequence, or transfer-window restrictions. A failed mandatory state transition prevents successful capability availability. 11.15.18. WF-15.18 — Fabric Transfer Validation Evidence EV-1509 generates or commits the protected validation evidence required for the transfer. The evidence may comprise a Fabric Transfer LAVR, ZK-LAVR, authenticated validation record, sealed state commitment, or equivalent protected representation. Das Expires 19 April 2027 [Page 619] Internet-Draft Protected AI Execution Finality October 2026 An illustrative record comprises: receipt_id; transfer_id; candidate_fabric_descriptor_digest; source_domain_id; destination_domain_id; authorized_data_class; workload_graph_reference; authorized_route_reference; transfer_envelope_reference; policy_epoch; protected_state_transition; nonce; fabric_finality_sink_id; decision; protected_authentication. Where required by the embodiment, validation evidence is committed before, or atomically with, capability availability. A conventional transfer-completion log generated after data delivery does not substitute for mandatory pre-effectuation validation- evidence commitment. The receipt may remain inside protected storage or a protected fabric state mechanism. Immediate external-ledger publication is not necessary unless separately required by the particular embodiment. Das Expires 19 April 2027 [Page 620] Internet-Draft Protected AI Execution Finality October 2026 11.15.19. WF-15.19 — Protected Fabric Finality Transaction PED-1506 coordinates validation, protected-state handling, evidence commitment, and capability availability. An illustrative protected transaction is: (Snext, Rfabric, Ready) = CommitFabricFinality(Dfabric, A, Scurrent, F) where: Snext denotes successfully committed protected fabric-authorization state; Rfabric denotes the protected Fabric Transfer validation evidence; Ready denotes the protected indication that the mandatory capability- release prerequisites have succeeded; Dfabric denotes the validated transfer descriptor; A denotes the authenticated Cross-Domain Fabric Authorization Object; Scurrent denotes prior protected authorization state; and F denotes the designated fabric Finality Sink. The capability-release mechanism does not treat an incomplete mandatory transaction as successful authorization. The implementation may employ protected transactional state, an HSM- controlled state service, an authenticated fabric controller, secure counters, or equivalent protected mechanisms. Where several components participate, the required authorization dependencies must be verifiably committed before the resulting capability becomes usable. 11.15.20. WF-15.20 — Scoped Fabric Transfer Capability Following successful protected authorization, CR-1510 makes available a scoped Fabric Transfer Capability. The capability may contain or securely reference: capability_id; Das Expires 19 April 2027 [Page 621] Internet-Draft Protected AI Execution Finality October 2026 candidate_fabric_descriptor_digest; source_domain_id; destination_domain_id; workload_identity; data_class; source_memory_region; destination_memory_region; permitted_transfer_operation; transfer_size_limit; approved_route; workload_graph_reference; policy_epoch; revocation_epoch; hardware_freshness_reference; nonce; expiry; remaining_usage; validation_evidence_digest; fabric_finality_sink_id. The capability may comprise: (a) a cryptographically signed authorization artifact; (b) a MAC-authenticated transfer permit; (c) a protected capability-table entry; (d) an authenticated DMA descriptor; Das Expires 19 April 2027 [Page 622] Internet-Draft Protected AI Execution Finality October 2026 (e) a protected queue-pair capability; (f) a hardware forwarding grant; (g) a sealed transfer handle; or (h) an equivalent protected execution-enablement condition. Possession of the capability representation alone does not independently authorize transfer outside the required operation, domain, route, protected-state, usage, and Finality Sink bindings. 11.15.21. WF-15.21 — Illustrative Cryptographic Capability Representation A non-limiting signature-based implementation may use: Cfabric = Sign_skPED(Encode(hFabric, hR, SRC, DST, DATA, OP, ROUTE, LIMIT, EPOCH, HF, NONCE, EXPIRY, F)) where: Cfabric denotes the authenticated Fabric Transfer Capability; Sign_skPED denotes signing under a PED-controlled private key; hFabric denotes the authorized transfer-descriptor digest; hR denotes the validation-evidence commitment digest; SRC denotes the source compute-domain binding; DST denotes the destination compute-domain binding; DATA denotes the permitted computation-data class; OP denotes the authorized transfer operation; ROUTE denotes the permitted route; LIMIT denotes transfer-size or usage restrictions; EPOCH denotes the required policy epoch; HF denotes the hardware-freshness binding; NONCE denotes the capability freshness value; Das Expires 19 April 2027 [Page 623] Internet-Draft Protected AI Execution Finality October 2026 EXPIRY denotes the capability validity limit; and F denotes the designated fabric Finality Sink. The selected implementation may avoid asymmetric signature verification on each transfer unit by using an authenticated protected capability entry established through a higher-cost authorization procedure. The cryptographic representation is illustrative and does not impose a mandatory algorithm or serialization format on all implementations. 11.15.22. WF-15.22 — Independent Verification at the Fabric Finality Sink FS-1512 obtains the actual transfer descriptor, protected transfer entry, hardware context, or effectuation-relevant operation information. Before admitting the transfer, the Finality Sink verifies: (a) capability authenticity; (b) source-domain binding; (c) destination-domain binding; (d) data-class scope; (e) permitted transfer operation; (f) memory-region restrictions; (g) transfer size or window; (h) required fabric route; (i) policy epoch; (j) revocation conditions; (k) nonce and expiry; (l) required hardware freshness; (m) protected validation-evidence reference; (n) usage or consumption state; and Das Expires 19 April 2027 [Page 624] Internet-Draft Protected AI Execution Finality October 2026 (o) fabric Finality Sink identity. The Finality Sink verifies the operation that is actually presented rather than relying exclusively upon an earlier software assertion that the transfer was permitted. The governed transfer remains blocked when a mandatory verification condition fails. 11.15.23. WF-15.23 — Fabric Finality Verification Predicate An illustrative verification predicate is: PermitFabric = Auth(C) AND Match(C,Dactual) AND DomainsValid(C,SRC,DST) AND RouteValid(C,Ractual) AND StateValid(C,P) AND FreshnessValid(C,H) AND SinkValid(C,F) where: PermitFabric denotes permission to perform the governed transfer; C denotes the Fabric Transfer Capability; Dactual denotes the actual fabric-transfer descriptor; SRC and DST denote actual source and destination domains; Ractual denotes the actual relevant transfer route; P denotes the required protected authorization state; H denotes applicable hardware-freshness state; and F denotes the designated fabric Finality Sink. Auth verifies capability authenticity. Match verifies exact descriptor correspondence or expressly permitted bounded-scope matching. DomainsValid verifies the authorized source and destination. RouteValid verifies the applicable route restrictions. StateValid verifies required policy, revocation, evidence, and usage state. FreshnessValid verifies hardware freshness when mandatory. Das Expires 19 April 2027 [Page 625] Internet-Draft Protected AI Execution Finality October 2026 SinkValid verifies the authorized Finality Sink. All mandatory conditions must succeed before the governed transfer is admitted. 11.15.24. WF-15.24 — Hardware-Latched Transfer Admission in the implementation described by enforcement point 50, HL-1511 maintains the governed transfer interface in a hardware-disabled, non-admitting, or otherwise non-effective state until the required Fabric Transfer Capability verifies. The controlled interface may comprise: (a) a fabric lane; (b) a switch admission entry; (c) a DMA queue; (d) an optical path; (e) a memory-access interface; (f) an accelerator transfer interface; (g) a protected queue pair; or (h) a hardware-controlled forwarding entry. In one implementation, the transfer request may be staged in an inactive DMA descriptor. The hardware controller prevents the descriptor from becoming eligible for execution until the authenticated transfer capability is verified. In another implementation, the fabric switch does not admit the relevant route or forwarding entry until protected capability verification succeeds. The hardware latch permits only the specified bounded transfer. A software allow decision that the hardware controller is free to ignore or bypass does not satisfy the specified hardware-latched effectuation requirement. Das Expires 19 April 2027 [Page 626] Internet-Draft Protected AI Execution Finality October 2026 11.15.25. WF-15.25 — Hardware-Latch Activation Sequence A non-limiting hardware-latched transfer sequence comprises: First, the source accelerator generates or prepares protected computation data. Second, a transfer request is submitted to the fabric interception component. Third, the proposed transfer is retained in a Non-Effective State. Fourth, the Candidate Fabric Transfer Act Descriptor is formed. Fifth, the PED authenticates the Cross-Domain Fabric Authorization Object. Sixth, the PED validates the mandatory source, destination, data- class, workload-graph, route, transfer-envelope, policy, and freshness predicates. Seventh, required protected-state operations and Fabric Transfer validation-evidence commitment are completed. Eighth, the PED releases or activates the bounded Fabric Transfer Capability. Ninth, the hardware-associated Finality Sink verifies the capability against the actual transfer. Tenth, the hardware latch enables the authorized admission, routing, copying, switching, or delivery operation. Eleventh, the hardware or associated protected controller enforces the applicable size, route, usage, and freshness restrictions. Twelfth, the transfer capability is consumed, advanced, retired, or maintained within its permitted bounded-use state according to the authorization. If required verification fails at the hardware Finality Sink, the controlled transfer interface remains disabled or non-admitting for the rejected operation. 11.15.26. WF-15.26 — Continuous Tensor and Memory-Transfer Validation in the implementation described by enforcement point 51, a governed transfer may comprise a sequence of transfer units. Das Expires 19 April 2027 [Page 627] Internet-Draft Protected AI Execution Finality October 2026 A transfer unit may be: (a) a packet; (b) a DMA block; (c) a tensor slice; (d) a memory page; (e) a collective-operation phase; (f) a transfer window; (g) an accelerator communication chunk; or (h) another bounded data-transfer unit. The system may associate a protected validation receipt, rolling Fabric Transfer Capability, or corresponding authenticated authorization state with each required unit or window. An earlier authorized unit does not automatically permit later units outside the expressly authorized transfer scope. The system enforces the granularity required by the applicable embodiment. Per-byte verification is not mandatory where the claim and protected authority permit bounded transfer units and the corresponding hardware enforces their limits. 11.15.27. WF-15.27 — Rolling Transfer Authorization State In one implementation, the system maintains a rolling transfer-state record. A non-limiting record comprises: transfer_id; current_window; authorized_route; source_domain_id; destination_domain_id; Das Expires 19 April 2027 [Page 628] Internet-Draft Protected AI Execution Finality October 2026 authorized_data_class; maximum_transfer_size; remaining_transfer_allowance; last_sequence_number; policy_epoch; hardware_freshness_reference; capability_id; validation_evidence_reference; status. A subsequent transfer unit is admitted only when its required authorization state remains valid. An illustrative state progression is: WINDOW_PENDING → WINDOW_AUTHORIZED → WINDOW_ADMITTED → WINDOW_CONSUMED. Where a bounded authorization supports several units, the protected system decrements or advances the corresponding usage allowance. An unauthorized window cannot independently consume or inherit the authority of another window. 11.15.28. WF-15.28 — Continuous Transfer Monitoring and Drift Detection RM-1514 evaluates required transfer conditions during an ongoing fabric operation. Such conditions may include: (a) authorized route continuity; (b) permitted destination; (c) transfer-size constraints; (d) expected tensor or data class; (e) approved workload graph; Das Expires 19 April 2027 [Page 629] Internet-Draft Protected AI Execution Finality October 2026 (f) collective-operation phase; (g) policy epoch; (h) hardware sequence state; (i) revocation state; or (j) other applicable transfer-envelope predicates. If a mandatory route, destination, size, graph, or protected-state condition becomes invalid, the system withholds subsequent transfer authorization or the Finality Sink rejects the affected transfer unit. The enforcement mechanism does not retroactively prevent transfer units already delivered. Its prevention guarantee applies to the subsequent units whose admission remains under the applicable protected finality control. 11.15.29. WF-15.29 — Transfer-Size and Workload-Graph Anomaly Handling In a continuous-transfer embodiment, the authorized workload graph may specify permitted communication relationships and expected data movement. For example, a training collective operation may permit defined exchanges among an approved set of accelerators. The Candidate Fabric Transfer Act Descriptor identifies the required operation class, transfer participants, data class, and bounded transfer size. If a workload attempts to: (a) send protected data to an unauthorized accelerator; (b) exceed a mandatory transfer-size limit; (c) perform an unapproved collective operation; (d) use an unauthorized memory region; (e) change the permitted destination; or (f) select a prohibited fabric route, Das Expires 19 April 2027 [Page 630] Internet-Draft Protected AI Execution Finality October 2026 the corresponding protected predicate fails. The system withholds the required capability or denies admission of the affected transfer unit. An anomaly detector's observation alone does not establish prevention if the hardware has already admitted the transfer. The applicable security guarantee depends upon the finality check being enforced before the controlled transfer unit becomes effective. 11.15.30. WF-15.30 — Hardware-Freshness Binding in the implementation described by enforcement point 52, the Fabric Transfer Capability is bound to a hardware-freshness value. The freshness value may derive from: (a) an accelerator counter; (b) a fabric sequence number; (c) secure switch state; (d) a trusted clock; (e) a secure monotonic counter; (f) a boot epoch; or (g) protected device state. An illustrative freshness record comprises: device_id; boot_epoch; fabric_epoch; secure_counter; sequence_number; policy_epoch; freshness_generation. Das Expires 19 April 2027 [Page 631] Internet-Draft Protected AI Execution Finality October 2026 The protected authorization mechanism associates the required hardware-freshness state with the issued capability. FS-1512 verifies the corresponding required freshness condition before admitting the transfer. A capability valid under a previous hardware generation does not automatically authorize transfer under a different or rolled-back state. 11.15.31. WF-15.31 — Hardware-Freshness Verification Procedure In an illustrative implementation, the protected system performs the following procedure. First, HF-1513 provides an authenticated or hardware-protected freshness reference. Second, PED-1506 associates the reference with the Candidate Fabric Transfer Act and applicable protected state. Third, the resulting Fabric Transfer Capability incorporates or securely references the required freshness condition. Fourth, FS-1512 obtains the current freshness state from the designated trusted hardware or protected state source. Fifth, the Finality Sink compares the required capability freshness against the applicable current state. Sixth, the hardware interface admits the transfer only if the freshness predicate succeeds together with the other mandatory capability checks. An illustrative predicate is: FreshnessValid = EpochMatch AND CounterValid AND SequenceValid AND NotRevoked where each term applies only when required by the particular embodiment. A counter rollback, boot-epoch mismatch, replayed transfer sequence, or invalid protected generation causes the applicable freshness predicate to fail. Das Expires 19 April 2027 [Page 632] Internet-Draft Protected AI Execution Finality October 2026 11.15.32. WF-15.32 — Prevention of Replay Across Device Reset A hardware reset or restart may change the state of an accelerator, switch, NIC, DPU, or memory controller. A previously valid capability must not become usable outside its permitted state merely because volatile registers or queues were restored. In an implementation requiring rollback resistance, the protected system binds capability validity to an authenticated boot epoch, monotonic counter, or other persistent protected freshness mechanism. After reset, the Finality Sink verifies that the presented capability corresponds to the current authorized generation. Capabilities referring to an incompatible earlier generation are rejected. Where persistent protected state cannot be established, the system does not assume that replay resistance remains intact solely because a capability contains a timestamp or software-generated nonce. 11.15.33. WF-15.33 — Cold-Path Authority Validation in the implementation described by enforcement point 53, the protected system separates comparatively higher-cost authority validation from latency-sensitive transfer admission. The cold path may perform: (a) Authority Object authentication; (b) source and destination attestation; (c) workload-graph evaluation; (d) data-classification validation; (e) jurisdiction or tenant-policy evaluation; (f) protected revocation-state validation; (g) higher-cost cryptographic verification; (h) protected transfer-state reservation; (i) validation-evidence commitment; and Das Expires 19 April 2027 [Page 633] Internet-Draft Protected AI Execution Finality October 2026 (j) scoped Fabric Transfer Capability issuance. The cold path may be implemented in a PED, CIED, secure control processor, protected DPU service, HSM, or authenticated remote authority. Its result is not an unrestricted authorization for arbitrary future transfers. The permitted scope, route, usage, freshness, and Finality Sink conditions remain bounded and enforceable at the fast path. 11.15.34. WF-15.34 — Bounded-Time Local Fabric Verification The fast path comprises the hardware-associated Finality Sink or local protected fabric enforcement interface. The fast path may verify a compact authenticated admission record using: (a) a protected hardware lookup entry; (b) a sequence counter; (c) a short-lived authentication tag; (d) a bounded route grant; (e) an authenticated DMA descriptor; (f) a queue-pair capability; (g) a hardware transfer-enable entry; or (h) an equivalent local transfer-admission record. The local verifier determines whether the actual requested transfer remains within the scope and state established through the protected cold-path authorization. The implementation may avoid performing expensive policy evaluation for each packet or tensor slice where a properly bounded capability is sufficient. However, the local capability verification remains mandatory before the governed transfer unit is admitted. Das Expires 19 April 2027 [Page 634] Internet-Draft Protected AI Execution Finality October 2026 The actual bounded-time and line-rate performance characteristics depend upon the implemented hardware and workload. 11.15.35. WF-15.35 — Local Capability-Table Implementation In one illustrative implementation, the PED installs an authenticated transfer-admission entry into a protected hardware table. An entry may comprise: capability_id; source_domain_id; destination_domain_id; permitted_queue_id; authorized_data_class; memory_region_scope; route_id; maximum_transfer_bytes; remaining_transfer_bytes; valid_policy_epoch; valid_hardware_epoch; next_sequence_number; expiry; receipt_commitment_reference; status. The fabric Finality Sink obtains the relevant entry and verifies the actual transfer against its required fields. If verification succeeds, the hardware admits only the bounded transfer specified by the entry. A mismatch in the destination, queue, route, size, freshness, or required state causes the transfer to be refused. Das Expires 19 April 2027 [Page 635] Internet-Draft Protected AI Execution Finality October 2026 The protected table cannot be modified unilaterally by the requesting AI workload under the applicable threat model. 11.15.36. WF-15.36 — Time-of-Check and Time-of-Use Protection The architecture maintains correspondence between the transfer that was authorized and the transfer actually presented for fabric effectuation. Potential substitutions include: (a) changing the destination accelerator; (b) modifying the source memory region; (c) replacing a DMA descriptor; (d) changing transfer size; (e) altering the tensor or data class; (f) modifying the route; (g) substituting a queue pair; (h) changing the workload identity; (i) replaying an earlier fabric sequence; or (j) using a capability under incompatible protected state. Where exact transfer binding is required, the Finality Sink verifies the actual fields against the authorized descriptor commitment. Where bounded variation is permitted, the interface verifies the specified bounds. The system does not rely solely upon an upstream assertion that a DMA command was previously approved. 11.15.37. WF-15.37 — Protected Capability Consumption Where the Fabric Transfer Capability is single-use, usage-bounded, size-bounded, or window-bounded, the Finality Sink performs or coordinates the corresponding protected consumption operation. A representative capability-state record comprises: Das Expires 19 April 2027 [Page 636] Internet-Draft Protected AI Execution Finality October 2026 capability_id; authorized_transfer_digest; source_domain_id; destination_domain_id; remaining_uses; remaining_bytes; last_sequence; hardware_epoch; state_version; status. For a single-use capability, a second incompatible transfer cannot independently consume the same authorization state. For a size-bounded capability, the hardware or protected controller enforces the permitted data allowance. For a rolling transfer capability, the system advances the protected window or sequence state according to the authorized progression rules. A completed transfer cannot be undone merely by invalidating a capability afterward. 11.15.38. WF-15.38 — Crash, Timeout, Reset, and Recovery The system distinguishes interruptions at different stages of the protected fabric-finality sequence. Failure before protected validation: The proposed transfer remains non-effective. Failure before required evidence commitment: No valid corresponding Fabric Transfer Capability becomes available. Failure after protected commitment but before capability installation: The protected system reconciles the committed authorization state before reusing, recovering, or retiring the capability. Das Expires 19 April 2027 [Page 637] Internet-Draft Protected AI Execution Finality October 2026 Failure before hardware admission: The transfer remains subject to the required current capability verification. Failure after partial transfer admission: The system determines which bounded units may have crossed the controlled boundary. Failure after device reset: The relevant hardware freshness and protected capability-consumption state are verified before further admission. Failure after possible remote delivery: The operation may remain indeterminate until suitable receiving-side completion evidence is available. A retry does not automatically obtain unrestricted authorization to retransmit protected computation data. Where supported, transfer identifiers, protected sequence counters, hardware completion queues, authenticated acknowledgments, or receiving-side admission records may support reconciliation. The system does not assert unconditional exactly-once transfer completion across arbitrary hardware fabrics. 11.15.39. WF-15.39 — Illustrative GPU-to-GPU Tensor Transfer In one concrete implementation, a confidential AI training workload executes across two accelerator domains. A first GPU produces a tensor that must be transferred to a second GPU for the next authorized computation stage. The tensor remains resident in the source accelerator memory. The transfer is submitted to an enforcement-controlled fabric interface. FI-1503 intercepts the proposed transfer. HQ-1504 maintains an inactive transfer descriptor. DF-1505 constructs the Candidate Fabric Transfer Act Descriptor identifying the source GPU, destination GPU, tensor class, source memory region, transfer size, route, approved workload graph, current policy epoch, and designated fabric Finality Sink. PED-1506 obtains the Cross-Domain Fabric Authorization Object. Das Expires 19 April 2027 [Page 638] Internet-Draft Protected AI Execution Finality October 2026 The PED validates the source-domain authority, destination-domain authority, approved tensor class, graph relationship, route, transfer envelope, policy state, and required freshness conditions. The protected system performs the required authorization-state operation and commits a Fabric Transfer LAVR or equivalent protected validation record. CR-1510 makes available the corresponding Fabric Transfer Capability. The interconnect controller reconstructs or verifies the actual transfer attributes. The fabric Finality Sink verifies the capability against the actual source, destination, tensor scope, route, memory region, size, freshness, and protected state. If the required conditions succeed, the hardware latch admits the bounded transfer. If the destination GPU or requested memory region differs from the authorized scope, the transfer remains blocked. The source GPU's ability to compute the tensor does not independently confer authority to transfer it. 11.15.40. WF-15.40 — Illustrative DMA-Bypass Attempt An AI workload is prohibited from exporting a protected accelerator tensor into an unrestricted host memory region. The normal software interface refuses the transfer. The workload then attempts to use an alternative DMA descriptor or device queue. In the specified non-bypassable hardware-assisted implementation, the relevant memory mappings, queues, and transfer interfaces are controlled by the protected fabric enforcement arrangement. The unauthorized descriptor cannot cause the governed transfer without the required capability verification. If an alternative DMA-capable interface remains accessible and can export the tensor without passing the required enforcement, the implementation does not satisfy the specified non-bypassable transfer guarantee. Das Expires 19 April 2027 [Page 639] Internet-Draft Protected AI Execution Finality October 2026 This test distinguishes ordinary software permission checking from actual protected hardware control of the effectuation path. 11.15.41. WF-15.41 — Illustrative Continuous Tensor-Stream Rollout A distributed inference workload generates a sequence of key-value cache transfer units for a cooperating accelerator. The applicable Cross-Domain Fabric Authorization Object permits transfers only between approved accelerator domains over a specified fabric route and within a bounded transfer envelope. The PED validates the initial transfer authorization and establishes protected rolling-capability state. The fabric Finality Sink verifies the required capability before admitting each governed transfer unit or authorized transfer window. During the sequence, the source workload attempts to redirect the next transfer unit to another destination accelerator. RM-1514 detects or the Finality Sink directly identifies the destination change through its required transfer-context verification. The changed destination does not satisfy the current authorization binding. The next transfer unit is withheld. Previously delivered transfer units remain completed effects. The original authorization does not automatically permit continuation over the substituted destination. 11.15.42. WF-15.42 — Illustrative Hardware Freshness and Replay Attack An accelerator interconnect controller receives a Fabric Transfer Capability bound to a specified protected hardware epoch and sequence counter. The capability permits one transfer of a protected tensor block. The corresponding fabric Finality Sink verifies the capability and permits the authorized transfer. The protected usage or sequence state advances. Das Expires 19 April 2027 [Page 640] Internet-Draft Protected AI Execution Finality October 2026 An attacker subsequently resubmits the earlier capability, including after an attempted device-state rollback. The Finality Sink obtains the required current protected hardware- freshness state. The earlier capability no longer satisfies the mandatory freshness or consumption conditions. The replayed transfer is refused. The result depends upon the freshness source being protected against the rollback or reset behavior considered within the implementation's threat model. 11.15.43. WF-15.43 — Alternative Technical Implementations The protected fabric-transfer architecture may be implemented through different technical substrates. GPU memory-controller implementation: A protected memory interface prevents unauthorized release of accelerator-resident tensors into another governed memory domain. Accelerator-interconnect implementation: A fabric controller verifies bounded transfer authority before allowing accelerator-to-accelerator communication. DMA/IOMMU implementation: A protected DMA admission interface and corresponding memory mappings prevent unverified transfers into unauthorized memory regions. SmartNIC implementation: A protected forwarding controller verifies the required Fabric Transfer Capability before network transmission. DPU implementation: A protected DPU control domain establishes bounded transfer authority, while its controlled data path verifies and enforces the authorized transfer. Fabric-switch implementation: A switch pipeline maintains protected forwarding or admission entries corresponding to scoped transfer capabilities. Optical-interconnect implementation: A protected optical path controller enforces required transfer-admission authorization before enabling the governed optical transfer. Das Expires 19 April 2027 [Page 641] Internet-Draft Protected AI Execution Finality October 2026 Confidential accelerator implementation: Protected accelerator memory and authenticated transfer interfaces maintain the required finality relationship across confidential-computing boundaries. Single-node implementation: The PED, protected-state component, capability mechanism, and fabric Finality Sink operate within one protected accelerator or controller. Distributed implementation: A protected authority issues or registers a Fabric Transfer Capability that is independently verified by an authenticated remote fabric or receiving-side component. Cold-path/fast-path implementation: Higher-cost authorization occurs through a protected controller, while a local hardware mechanism enforces compact capability checks on the latency-sensitive transfer path. The selected implementation determines the actual guarantees against privileged host compromise, firmware compromise, device reset, hardware tampering, fabric routing attacks, and unauthorized alternative transfer paths. A software-only implementation does not automatically provide hardware-latched protection. 11.15.44. WF-15.44 — Failure and Fail-Closed Conditions The fabric Finality Sink refuses the governed transfer when a mandatory condition is absent, invalid, expired, revoked, replayed, inconsistent, or unverifiable. Non-limiting refusal conditions include: (a) missing Cross-Domain Fabric Authorization Object; (b) invalid source-domain authority; (c) invalid destination-domain authority; (d) unauthorized computation-data class; (e) source or destination accelerator measurement mismatch; (f) workload or tenant identity mismatch; (g) unauthorized memory region; (h) transfer-size violation; Das Expires 19 April 2027 [Page 642] Internet-Draft Protected AI Execution Finality October 2026 (i) unapproved collective-operation class; (j) invalid workload graph; (k) unauthorized fabric route; (l) switch-identity mismatch; (m) jurisdictional mismatch where mandatory; (n) invalid runtime transfer envelope; (o) stale policy epoch; (p) invalid revocation state; (q) failed protected-state transition; (r) failed required Fabric Transfer LAVR or ZK-LAVR commitment; (s) missing Fabric Transfer Capability; (t) invalid capability authentication; (u) unauthorized capability reuse; (v) expired or replayed nonce; (w) hardware-freshness mismatch; (x) incompatible boot or fabric epoch; (y) exhausted transfer allowance; (z) designated Finality Sink mismatch; or (aa) unavailable required hardware verification machinery. The corresponding transfer remains blocked, held, or otherwise non- effective. An implementation may separately authorize safe recovery or a reduced-scope operation, but failure of the original required authorization does not create unrestricted transfer permission. Das Expires 19 April 2027 [Page 643] Internet-Draft Protected AI Execution Finality October 2026 11.15.45. WF-15.45 — PHOSITA Verification and Negative Tests A person having ordinary skill in accelerator architecture, GPU security, hardware fabrics, DMA/RDMA systems, SmartNICs, DPUs, protected computing, cryptography, and high-performance AI infrastructure may verify the described architecture through controlled testing. Test 1 — Authorized transfer: Submit a transfer satisfying the required source, destination, data-class, route, state, and capability conditions. The fabric Finality Sink admits the bounded transfer. Test 2 — Missing capability: Present an otherwise valid transfer descriptor without the required Fabric Transfer Capability. Hardware-associated admission is refused. Test 3 — Source substitution: Present a capability from an unauthorized source accelerator. Required source-domain verification fails. Test 4 — Destination substitution: Redirect a validated tensor transfer to an unauthorized destination accelerator. Destination verification fails. Test 5 — Tenant mismatch: Attempt cross-tenant transfer outside the authorized scope. Protected validation refuses the operation. Test 6 — Tensor-class mismatch: Substitute a protected tensor class not authorized by the capability. Transfer admission fails. Test 7 — Memory-region substitution: Change the source or destination memory region where region identity is mandatory. Finality Sink verification rejects the change. Test 8 — Transfer-size anomaly: Exceed the authorized transfer-size or byte allowance. Hardware admission rejects the unauthorized excess. Test 9 — Collective-operation mismatch: Attempt an unapproved collective-operation type. Required workload-graph validation fails. Test 10 — Fabric-route substitution: Change the transfer route outside the authorized scope. The Finality Sink refuses the transfer. Das Expires 19 April 2027 [Page 644] Internet-Draft Protected AI Execution Finality October 2026 Test 11 — Switch mismatch: Attempt transfer through an unauthorized fabric switch where switch identity is mandatory. Verification fails. Test 12 — Hardware latch: Present a transfer while the protected hardware admission condition remains disabled. No governed transfer occurs. Test 13 — Authorized latch release: Supply a valid bounded capability and verify that the hardware enables only the permitted transfer. Test 14 — DMA bypass: Attempt an alternate DMA path around the controlled interface. The transfer is blocked or subjected to equivalent mandatory finality verification. Test 15 — Host-memory export: Attempt to copy accelerator-resident protected data into an unauthorized host memory region. The governed transfer is refused. Test 16 — Continuous transfer: Transfer several authorized bounded units while verifying the applicable rolling capability or window state. Test 17 — Route drift: Change the destination route between transfer windows. Further unauthorized units are withheld. Test 18 — Graph deviation: Introduce a source-destination relationship outside the approved workload graph. The next affected transfer is refused. Test 19 — Transfer-window replay: Reuse an earlier consumed transfer- window authorization. Protected sequence or usage verification fails. Test 20 — Hardware-counter replay: Re-present a capability bound to an earlier protected hardware-counter value. Verification fails where freshness advancement is mandatory. Test 21 — Device reset: Reset the device and attempt to reuse authority bound to an incompatible earlier boot epoch. Required freshness verification fails. Test 22 — Policy revocation: Revoke the mandatory transfer permission before admission. The affected operation remains blocked. Test 23 — Concurrent grant consumption: Submit competing transfers against one restricted authorization. Protected state prevents unauthorized double consumption. Das Expires 19 April 2027 [Page 645] Internet-Draft Protected AI Execution Finality October 2026 Test 24 — Evidence failure: Interrupt mandatory Fabric Transfer validation-evidence commitment. No valid corresponding transfer capability becomes available. Test 25 — Cold-path/fast-path separation: Perform higher-cost authority validation outside the latency-sensitive path and verify that every governed transfer still requires its applicable local admission check. Test 26 — Protected lookup tampering: Attempt to alter a hardware capability-table entry from an unauthorized software context. The protected table rejects the modification under the declared threat model. Test 27 — Expired route grant: Present a transfer after the capability's mandatory validity period has expired. Local verification refuses admission. Test 28 — Crash after partial transfer: Interrupt a multi-unit transfer and verify that the protected recovery procedure distinguishes completed units from pending or indeterminate units. Test 29 — Single-node finality: Implement validation and transfer enforcement within one protected device while preserving the required authorization and effectuation functions. Test 30 — Distributed fabric finality: Issue transfer authorization from a protected authority node and independently verify it at a remote fabric or receiving-side Finality Sink. Test 31 — Alternate accelerator interface: Attempt the same governed data movement through another available accelerator API or device interface. The operation remains mediated or blocked. Test 32 — Revocation during streaming: Revoke a mandatory authorization condition during an ongoing bounded transfer. Subsequent affected transfer units are withheld according to the specified authorization granularity. Test 33 — Unauthorized capability reuse across sinks: Present a capability issued for one fabric Finality Sink at another protected interface. Required sink binding fails. Test 34 — Cold-path outage: Make the protected authority unavailable while the fast path receives a new transfer outside any valid existing bounded grant. The fast path refuses unauthorized admission. Das Expires 19 April 2027 [Page 646] Internet-Draft Protected AI Execution Finality October 2026 Test 35 — Actual-operation descriptor substitution: Validate one DMA descriptor, replace mandatory fields before effectuation, and verify that the hardware-associated Finality Sink rejects the mismatch. The tests may employ accelerator emulators, controlled GPU workloads, DMA test devices, IOMMU test environments, programmable fabric switches, SmartNIC/DPU development platforms, protected authorization-state services, hardware counters, transfer-sequence instrumentation, and fault-injection facilities. The verification establishes only the properties implemented and demonstrated under the specified trust model. 11.15.46. WF-15.46 — Claim-Specific Technical Support Enforcement Point 48 — Protected Cross-Domain AI-Fabric Transfer Finality System The workflow describes: (a) AC-1501 and DC-1502 representing source and destination compute, accelerator, or memory domains; (b) FI-1503 providing hardware-associated transfer interception; (c) HQ-1504 maintaining the proposed cross-domain transfer in a Non- Effective State; (d) DF-1505 constructing a Candidate Fabric Transfer Act Descriptor; (e) PED-1506 validating the Cross-Domain Fabric Authorization Object, source and destination authority, data classification, approved workload graph, fabric route, transfer envelope, and policy state; (f) EV-1509 generating or committing a Fabric Transfer LAVR, ZK-LAVR, or other applicable protected evidence; (g) CR-1510 releasing or making available the scoped Fabric Transfer Capability; (h) FS-1512 independently verifying the capability before governed transfer admission; and (i) refusal when required capability or authorization conditions fail. Enforcement Point 49 — Fabric Transfer Descriptor Granularity Das Expires 19 April 2027 [Page 647] Internet-Draft Protected AI Execution Finality October 2026 WF-15.8 through WF-15.9 identify the source and destination accelerator measurements, workload and tenant identities, model identity, tensor class, memory region, transfer size, collective- operation type, fabric route, switch identity, jurisdiction, policy epoch, nonce, expiry, and fabric Finality Sink identity. Enforcement Point 50 — Hardware-Latched Transfer Admission WF-15.24 through WF-15.25 describe hardware-disabled or non-admitting fabric lanes, switch entries, DMA queues, optical paths, memory interfaces, and accelerator transfer interfaces that become enabled only upon required capability verification. Enforcement Point 51 — Continuous Tensor or Memory-Transfer Validation WF-15.26 through WF-15.29 describe bounded packets, blocks, tensor slices, memory pages, collective-operation phases, and transfer windows; rolling capabilities or protected receipts; and withholding of subsequent units upon mandatory route, destination, size, or workload-graph violations. Enforcement Point 52 — Hardware-Freshness Binding WF-15.30 through WF-15.32 describe binding to accelerator counters, sequence numbers, secure switch state, trusted time, monotonic counters, boot epochs, or protected device state and rejection of replay outside the authorized freshness context. Enforcement Point 53 — Separated Cold-Path Validation and Line-Rate Finality WF-15.33 through WF-15.35 describe higher-cost protected authorization away from the latency-sensitive path and mandatory bounded local checks through protected lookup entries, sequence counters, short-lived authentication tags, route grants, DMA descriptors, and queue-pair capabilities. 11.15.47. WF-15.47 — Technical Effect The disclosed workflow establishes a protected causal relationship between: (a) AI computation producing protected accelerator-resident data; (b) preparation of a proposed cross-domain transfer; (c) interception before the governed fabric-finality boundary; Das Expires 19 April 2027 [Page 648] Internet-Draft Protected AI Execution Finality October 2026 (d) maintenance of the Candidate Fabric Transfer Act in a Non- Effective State; (e) construction of a transfer-specific descriptor; (f) authentication of the Cross-Domain Fabric Authorization Object; (g) protected validation of source authority, destination authority, data classification, workload graph, transfer envelope, fabric route, policy state, and required hardware freshness; (h) protected authorization-state handling; (i) Fabric Transfer LAVR, ZK-LAVR, or equivalent protected evidence commitment; (j) scoped Fabric Transfer Capability availability; (k) independent capability verification at the hardware-associated fabric Finality Sink; (l) hardware-latched admission of only the authorized transfer; (m) protected rolling authorization where continuous transfers are governed; and (n) fail-closed withholding when any mandatory authorization condition is absent or invalid. The architecture prevents an AI accelerator from treating possession of model parameters, tensors, gradients, embeddings, key-value caches, inference context, or other protected computation data as sufficient authority to transfer that data across an independently governed domain boundary. The hardware-latched embodiment places the required transfer- enablement condition within, or in mandatory control of, the actual hardware transfer path. The continuous-transfer embodiment prevents authorization of one bounded unit from becoming unrestricted permission for subsequent unauthorized transfer units. The hardware-freshness embodiment restricts replay or reuse of an earlier authorization outside its permitted device-state context. Das Expires 19 April 2027 [Page 649] Internet-Draft Protected AI Execution Finality October 2026 The cold-path/fast-path embodiment allows more computationally expensive authorization to occur outside a latency-sensitive transfer path while retaining mandatory bounded capability verification before the governed transfer is admitted. Computation is not authority to act. Possession of a tensor is not authority to transfer it. An authorized compute workload is not automatically an authorized cross-domain data sender. Hardware connectivity is not protected transfer authorization. Cold-path approval does not replace mandatory verification at the fabric Finality Sink. 11.16. WF-16 — Distributed Hardware-Watchdog Execution Interlock, Protected Monitoring-State Attestation, Multi-Sink Revocation Fencing, Fail-Closed Monitoring Failure, and Effectuation-State- Preserving Quarantine 11.16.1. WF-16.1 — Technical Purpose This embodiment describes a computer-implemented protected execution- finality architecture in which an out-of-band monitoring domain cooperates with a Protected Enforcement Domain and a plurality of independently enforceable Finality Sinks to govern consequential operations generated or requested by an artificial-intelligence execution environment. The system distinguishes observation of an artificial-intelligence workload from authority to permit a consequential operation. An out-of-band security component may detect execution anomalies, integrity failures, unauthorized tool activities, authority-scope deviations, or other monitored conditions. However, the monitoring component's observation or detection does not independently constitute execution authorization. Instead, a protected monitoring-state record represents the applicable measured or evaluated condition of the monitored workload. A Protected Enforcement Domain receives and validates the monitoring- state record and evaluates it together with the operation-specific authority conditions of a proposed Candidate Act. Das Expires 19 April 2027 [Page 650] Internet-Draft Protected AI Execution Finality October 2026 Where the required conditions succeed, the protected system establishes the applicable authorization-state transition, commits required protected validation evidence, and releases or makes available an execution-enabling capability bound to the Candidate Act, monitoring-state version, protected authorization state, and designated Finality Sink. Each applicable Finality Sink independently verifies the required capability and monitoring-state condition before permitting the governed operation to become effective. If the mandatory monitoring state becomes stale, revoked, unavailable, inconsistent, or invalid, the affected Finality Sink refuses effectuation. The architecture separates: (a) artificial-intelligence computation; (b) out-of-band observation and anomaly detection; (c) protected monitoring-state authentication; (d) operation-specific protected authorization; (e) scoped execution-capability issuance; (f) independent effectuation-boundary verification; (g) revocation and prevention of further unauthorized operations; (h) quarantine of the affected workload or resource; and (i) preservation of accurate operation-completion and recovery state. The system does not presume that a watchdog stopping future inference or quarantining a workload retroactively prevents an operation that has already become effective. Monitoring is not execution authority. 11.16.2. WF-16.2 — Participating Technical Components In one non-limiting embodiment, the system comprises: AE-1601 — Artificial-Intelligence Execution Domain Das Expires 19 April 2027 [Page 651] Internet-Draft Protected AI Execution Finality October 2026 An AI-agent runtime, model-serving environment, agentic workflow, autonomous process, tool-execution environment, container, virtual machine, accelerator workload, or corresponding computing domain configured to generate or process consequential operations. WM-1602 — Out-of-Band Monitoring Domain A monitoring and security component operating outside the unilateral execution authority controlled by AE-1601. The component may comprise a protected processor, data processing unit, secure controller, isolated accelerator, hardware-assisted monitor, or equivalent independent security mechanism. MC-1603 — Monitoring-State Collection Component A component configured to collect or obtain permitted execution measurements, status information, policy observations, integrity events, behavioral indicators, or associated monitoring evidence. MG-1604 — Protected Monitoring-State Generator A mechanism configured to produce a protected monitoring-state record representing the relevant monitored workload condition. MS-1605 — Protected Monitoring-State Store A protected or authenticated mechanism maintaining monitoring-state identifiers, versions, validity conditions, enforcement-state indicators, and associated authenticity or freshness information. DC-1606 — Candidate Act Descriptor Component A mechanism configured to construct or verify a machine-readable representation of a consequential operation requested by AE-1601. HQ-1607 — Non-Effective Candidate Act Holding Mechanism An enforcement-controlled queue, buffer, pending request object, inactive command, or equivalent mechanism retaining a proposed consequential operation before effectuation. PED-1608 — Protected Enforcement Domain A protected authority component configured to evaluate the applicable Candidate Act Descriptor, Authority Object, monitoring-state version, protected authorization state, and required runtime conditions. Das Expires 19 April 2027 [Page 652] Internet-Draft Protected AI Execution Finality October 2026 PS-1609 — Protected Authorization-State Store A protected mechanism maintaining policy epochs, revocation versions, operation-specific grants, nonce state, capability usage, authorization-state references, and required validation commitments. EV-1610 — Protected Validation-Evidence Component A mechanism configured to generate or commit an operation-specific protected validation record, LAVR, authenticated receipt, sealed commitment, or equivalent evidence. CR-1611 — Execution-Enabling Capability Mechanism A protected component configured to issue, register, activate, or otherwise make available a scoped execution capability bound to the applicable Candidate Act and required monitoring-state version. RF-1612 — Protected Revocation-Fence Component A mechanism configured to advance or invalidate applicable monitoring-state and authorization versions and to prevent capabilities bound to superseded mandatory state from enabling subsequent consequential operations. FS-1613 — Network Finality Sink A protected network interface, egress controller, gateway, NIC, SmartNIC, DPU-controlled forwarding interface, or equivalent effectuation boundary. FS-1614 — Tool and API Finality Sink A protected tool executor, API gateway, function executor, connector, or equivalent effectuation interface. FS-1615 — Credential and Storage Finality Sink A protected credential-use interface, database commit controller, persistent storage interface, or equivalent consequential boundary. FS-1616 — Additional Effectuation Finality Sink A payment interface, accelerator-output controller, physical actuator, device interface, or other independently governed effectuation boundary. QC-1617 — Quarantine Controller Das Expires 19 April 2027 [Page 653] Internet-Draft Protected AI Execution Finality October 2026 A component configured to impose authorized restrictions on agent computation, tool invocation, infrastructure access, network activity, or other specified workload functions. OS-1618 — Protected Operation-Outcome Store A protected mechanism maintaining pending, reserved, confirmed- effective, denied, revoked, quarantined, or indeterminate operation states. RC-1619 — Recovery and State-Revalidation Component A protected mechanism configured to determine whether failed or unavailable monitoring-state conditions can be restored through authorized revalidation or recovery. SC-1620 — Cross-Component State-Consistency Component A mechanism configured to maintain or verify the required correspondence among monitoring-state versions, Candidate Act identities, policy epochs, capability states, and the Finality Sinks participating in governed effectuation. The components may be physically separated, colocated, integrated into one protected hardware node, or distributed across multiple authenticated execution and enforcement environments. The out-of-band monitoring function need not itself be the Finality Sink. The corresponding security guarantee depends upon the required protected monitoring condition being enforced at the actual consequential boundary. 11.16.3. WF-16.3 — Establishment of the Monitoring and Execution Trust Boundaries Before governed AI operations are processed, the system establishes a trust boundary between AE-1601 and WM-1602. The AI execution environment may perform computation, produce model outputs, prepare commands, select tools, and request consequential operations. However, it cannot unilaterally: (a) modify authenticated monitoring-state records; Das Expires 19 April 2027 [Page 654] Internet-Draft Protected AI Execution Finality October 2026 (b) advance or roll back protected monitoring-state versions; (c) create valid protected monitoring attestations; (d) override required revocation conditions; (e) issue unrestricted execution capabilities; (f) replace protected Finality Sink verification logic; (g) bypass mandatory monitoring-state-dependent authorization; or (h) restore previously invalidated execution authority merely by restarting the workload. WM-1602 may obtain monitoring information through protected telemetry, authenticated execution reports, hardware measurements, secured system interfaces, or another suitable mechanism. The selected implementation determines the monitoring domain's actual visibility and trust properties. Out-of-band placement alone does not establish that the monitoring component observes every relevant workload event. The architecture enforces only the monitoring conditions and effectuation interfaces actually covered by the implementation. 11.16.4. WF-16.4 — Definition of Out-of-Band Monitoring For this embodiment, out-of-band monitoring refers to observation, measurement, collection, or evaluation occurring through a component logically isolated from the monitored workload's unilateral execution authority. The monitoring mechanism may observe: (a) workload integrity; (b) software or model configuration; (c) unauthorized tool activity; (d) agent policy violations; (e) runtime behavioral anomalies; (f) unexpected privilege use; Das Expires 19 April 2027 [Page 655] Internet-Draft Protected AI Execution Finality October 2026 (g) prohibited communication patterns; (h) abnormal infrastructure access; (i) protected component availability; (j) watchdog resets; (k) hardware fault conditions; or (l) other governance-relevant execution state. The monitoring domain may support protective decisions by producing authenticated monitoring evidence. However, an out-of-band observation is not automatically an inline enforcement action. A condition observed after a consequential operation completes cannot retroactively prevent that operation. Accordingly, the protected system treats monitoring-state information as an input to mandatory operation-specific effectuation authorization when the corresponding claim requires prevention before external effect. 11.16.5. WF-16.5 — Identification of Governed Consequential Boundaries The system identifies the classes of consequential operations for which monitoring-state-dependent authorization is mandatory. These may include: (a) external network transmission; (b) API dispatch; (c) privileged credential application; (d) persistent storage commitment; (e) tool execution; (f) payment instruction; (g) accelerator-state export; (h) device actuation; and Das Expires 19 April 2027 [Page 656] Internet-Draft Protected AI Execution Finality October 2026 (i) other protected effectuation operations. in the implementation described by enforcement point 62, at least two distinct effectuation classes are governed by independently enforceable Finality Sinks. For example, the same AI workload may be permitted to generate both network requests and persistent database mutations. The corresponding network Finality Sink and database Finality Sink separately verify the execution authority required for their own effectuation interfaces. Authorization for one effectuation class does not automatically authorize another class. 11.16.6. WF-16.6 — Mandatory Effectuation-Path Coverage The protected system configures the governed effectuation interfaces so that the AI workload cannot complete a specified consequential operation through an accessible bypass path that omits required Finality Sink verification. A representative arrangement may include: (a) sandboxed workload execution; (b) restricted host access; (c) mandatory network-egress mediation; (d) controlled privileged tool execution; (e) protected credential custody; (f) governed database-write interfaces; (g) hardware-associated accelerator export controls; and (h) protected actuator or device interfaces. The system identifies each effectuation path capable of producing the governed consequence. If an operation can bypass the selected Finality Sink through another available interface, the implementation must restrict or equivalently mediate that alternative path to establish the specified enforcement property. Das Expires 19 April 2027 [Page 657] Internet-Draft Protected AI Execution Finality October 2026 A watchdog that merely reports suspicious execution does not provide non-bypassable effectuation control. 11.16.7. WF-16.7 — Monitoring-State Collection MC-1603 obtains monitoring information associated with AE-1601. An illustrative observation record comprises: workload_id; monitor_id; execution_domain_id; software_measurement; runtime_policy_reference; observation_class; observation_value; observation_time; monitor_sequence; monitor_health_state. The selected monitoring mechanism determines which measurements are available and their trustworthiness. For example, a protected hardware monitor may obtain device or infrastructure state not directly writable by the AI workload. A software monitor may observe process events or tool invocations, subject to its operating-system isolation and visibility limitations. The system does not assume that all monitoring implementations can inspect encrypted application payloads, hidden model reasoning, or every downstream operation. Required authorization predicates are selected according to information that the implementation can actually authenticate or verify. Das Expires 19 April 2027 [Page 658] Internet-Draft Protected AI Execution Finality October 2026 11.16.8. WF-16.8 — Protected Monitoring-State Record MG-1604 constructs a protected monitoring-state record. in the implementation described by enforcement point 62, the record includes: (a) workload identity; (b) monitoring-state version; (c) validity condition; and (d) enforcement-state indicator. An illustrative record comprises: monitor_record_id; workload_identity; monitoring_domain_identity; monitoring_state_version; policy_epoch; observation_digest; measured_execution_condition; enforcement_state; valid_from; valid_until; sequence_number; nonce; revocation_reference; protected_authentication. The enforcement-state indicator may identify a policy-defined state such as: Das Expires 19 April 2027 [Page 659] Internet-Draft Protected AI Execution Finality October 2026 MONITOR_VALID; MONITOR_RESTRICTED; MONITOR_REVOKED; MONITOR_UNAVAILABLE; MONITOR_RECOVERY_PENDING; or MONITOR_QUARANTINED. These labels are illustrative implementation states rather than mandatory terminology for every embodiment. The protected state identifies whether the record may satisfy the required monitoring predicate of a particular Candidate Act. A record identifying a healthy workload does not independently grant unrestricted authority over all consequential operations. 11.16.9. WF-16.9 — Monitoring-State Versioning The system associates each protected monitoring-state record with a version, generation, protected sequence, or equivalent authenticated state identifier. An illustrative progression is: M_v → M_(v+1) where: M_v denotes the earlier protected monitoring state; and M_(v+1) denotes the later protected monitoring state. Version advancement may occur when: (a) a new monitoring evaluation is committed; (b) a relevant policy violation is detected; (c) a protected execution state changes; (d) a workload enters quarantine; (e) monitoring authority is revoked; Das Expires 19 April 2027 [Page 660] Internet-Draft Protected AI Execution Finality October 2026 (f) a protected monitoring component is restarted under a new authenticated generation; or (g) another required monitoring-state transition occurs. The versioning mechanism must distinguish a current authorized state from a superseded state when the corresponding claim requires that distinction. An untrusted workload cannot independently restore an earlier monitoring-state version to recover invalidated execution authority. 11.16.10. WF-16.10 — Hardware-Attested Monitoring State in the implementation described by enforcement point 63, the monitoring-state record comprises a cryptographically authenticated measurement or attestation generated by WM-1602. A non-limiting attested record may include: monitoring_domain_id; protected_hardware_identity; workload_id; measurement_digest; monitoring_state_version; enforcement_state; sequence_number; freshness_nonce; validity_interval; attestation_signature; attestation_chain_reference. The Protected Enforcement Domain verifies the required authenticity, workload association, version or sequence, and freshness. A cryptographic signature alone does not prove that the record describes the correct workload or current monitoring state. Das Expires 19 April 2027 [Page 661] Internet-Draft Protected AI Execution Finality October 2026 The corresponding verification includes the required relationship between the attested monitoring component and the workload whose operations are being authorized. 11.16.11. WF-16.11 — Protected Attestation Verification PED-1608 evaluates the monitoring-state attestation. An illustrative predicate is: MonitorAttestValid = SignatureValid AND WorkloadBound AND VersionValid AND FreshnessValid AND MonitorAuthorized where: SignatureValid verifies the authenticated monitoring record; WorkloadBound verifies association with the correct AI execution domain; VersionValid verifies the required monitoring-state generation; FreshnessValid verifies the authorized validity interval or sequence; MonitorAuthorized verifies that the record originated from an accepted monitoring authority. The protected system additionally checks applicable revocation or policy state when mandatory. If the record cannot establish a required predicate, it is not treated as valid authorization evidence. The implementation's trust in hardware attestation extends only to the properties covered by the attested measurement and the applicable trust chain. 11.16.12. WF-16.12 — Candidate Act Generation AE-1601 generates or requests a consequential operation. The operation may comprise: (a) an HTTPS request; (b) an API invocation; (c) a shell or tool command; Das Expires 19 April 2027 [Page 662] Internet-Draft Protected AI Execution Finality October 2026 (d) a credential-mediated service call; (e) a database write; (f) an artifact deployment; (g) an accelerator memory transfer; (h) a payment instruction; or (i) an actuator command. The proposed operation is classified as Candidate Act CA-1621. Generation of CA-1621 does not independently confer execution authority. The existence of a valid monitoring-state record also does not independently authorize the operation. The Candidate Act remains subject to its operation-specific authority and Finality Sink conditions. 11.16.13. WF-16.13 — Interception and Non-Effective Staging The applicable interception mechanism receives CA-1621 before the operation crosses its governed effectuation boundary. HQ-1607 maintains CA-1621 in a Non-Effective State. An illustrative staging record comprises: candidate_act_id; workload_id; operation_class; operation_reference; target_finality_sink; monitoring_state_reference; policy_epoch; status = NON_EFFECTIVE. Das Expires 19 April 2027 [Page 663] Internet-Draft Protected AI Execution Finality October 2026 Where the Candidate Act includes mutable parameters, the system retains an immutable operation representation or authenticated digest sufficient to verify the actual effectuation request. The agent cannot independently release the operation merely because the watchdog has reported a normal monitoring condition. Protected authorization remains mandatory. 11.16.14. WF-16.14 — Candidate Act Descriptor Formation DC-1606 constructs a canonical Candidate Act Descriptor representing the consequential operation. An illustrative descriptor comprises: candidate_act_id; requesting_workload_identity; operation_class; target_resource; destination_or_recipient; operation_parameters; payload_digest; authorized_purpose; authority_object_reference; monitoring_state_version; monitoring_record_reference; policy_epoch; revocation_epoch; nonce; expiry; finality_sink_id. Das Expires 19 April 2027 [Page 664] Internet-Draft Protected AI Execution Finality October 2026 Only attributes required by the applicable Authority Object or specified embodiment are mandatory. The descriptor identifies the specific requested operation rather than merely identifying the monitored AI workload. 11.16.15. WF-16.15 — Canonical Descriptor and Monitoring-State Binding In an illustrative cryptographic implementation: Dwatch = Canon_v(W, ACT, TARGET, PARAM, MONITOR, EPOCH, F) where: Dwatch denotes the canonical Candidate Act Descriptor; Canon_v denotes deterministic encoding under version v; W denotes the authenticated workload identity; ACT denotes the proposed consequential operation; TARGET denotes its destination or resource; PARAM denotes effectuation-relevant parameters; MONITOR denotes the required monitoring-state reference and version; EPOCH denotes protected policy and authorization-state information; and F denotes the designated Finality Sink. An illustrative digest is: hWatch = H("DAS-WATCHDOG-ACT-v1" || Encode(Dwatch)) where H denotes a cryptographic hash function. The encoding must distinguish mandatory operation and monitoring- state attributes without ambiguous interpretation. The selected algorithms and serialization format are illustrative implementation choices. Das Expires 19 April 2027 [Page 665] Internet-Draft Protected AI Execution Finality October 2026 11.16.16. WF-16.16 — Acquisition of Operation-Specific Authority PED-1608 obtains the Authority Object applicable to CA-1621. The Authority Object may specify: (a) authorized workload identity; (b) permitted operation class; (c) authorized purpose; (d) permitted destination or resource; (e) applicable protected monitoring-state requirements; (f) accepted monitoring-state versions; (g) required attestation or freshness conditions; (h) permitted Finality Sink; (i) policy epoch; (j) revocation conditions; (k) nonce or usage restrictions; (l) human approval where required; and (m) additional operation-specific authorization predicates. PED-1608 verifies the Authority Object and the required protected monitoring record. The watchdog's detection state is treated as an authorization input, not as an unrestricted execution permission. 11.16.17. WF-16.17 — Combined Monitoring and Operation Authorization PED-1608 evaluates the mandatory predicates required for CA-1621. An illustrative predicate is: Vwatch = Pworkload AND Poperation AND Pscope AND Pmonitor AND Pstate AND Psink where: Das Expires 19 April 2027 [Page 666] Internet-Draft Protected AI Execution Finality October 2026 Vwatch denotes the protected authorization result; Pworkload verifies the requesting workload; Poperation verifies the actual consequential operation; Pscope verifies its permitted destination, resource, purpose, and execution scope; Pmonitor verifies the required monitoring-state record and version; Pstate verifies policy, revocation, nonce, freshness, and protected authorization state; and Psink verifies the designated Finality Sink. The system evaluates additional predicates where required. Successful monitoring-state validation does not automatically establish the remaining predicates. A valid operation-specific Authority Object does not override a failed mandatory monitoring-state condition. All mandatory conditions must succeed before the required execution capability becomes available. 11.16.18. WF-16.18 — Protected Authorization-State Transition Upon successful protected validation, PED-1608 performs the required authorization-state operation. Such operations may include: (a) verifying the current monitoring-state version; (b) checking revocation state; (c) reserving an operation-specific grant; (d) consuming or registering a nonce; (e) updating an operation quota; (f) recording the protected monitoring-state reference; (g) establishing a capability-use restriction; Das Expires 19 April 2027 [Page 667] Internet-Draft Protected AI Execution Finality October 2026 (h) registering the Candidate Act Descriptor digest; or (i) performing another required protected-state transition. Where a grant permits only one consequential operation, protected state prevents incompatible concurrent requests from independently consuming that grant. Where the monitoring state becomes invalid during the authorization transaction, the implementation ensures that the resulting capability does not become usable contrary to the required current-state conditions. Failure of a mandatory protected-state transition prevents successful capability availability. 11.16.19. WF-16.19 — Protected Validation-Evidence Commitment EV-1610 generates or commits the protected validation evidence required for CA-1621. The evidence may comprise: (a) a LAVR; (b) an authenticated validation receipt; (c) a sealed authorization record; (d) a protected hash-chain commitment; (e) a Merkle commitment; (f) a protected state reference; or (g) another supported validation-evidence mechanism. An illustrative record contains: receipt_id; candidate_act_id; descriptor_digest; workload_id; monitoring_state_version; Das Expires 19 April 2027 [Page 668] Internet-Draft Protected AI Execution Finality October 2026 monitoring_record_digest; authority_object_reference; protected_state_transition; policy_epoch; revocation_epoch; finality_sink_id; authorization_result; protected_authentication. Where the corresponding embodiment requires pre-effectuation commitment, the evidence is committed before, or atomically with, availability of the scoped execution capability. An ordinary post-event monitoring log does not substitute for required protected pre-effectuation validation evidence. 11.16.20. WF-16.20 — Protected Watchdog-Finality Transaction The PED coordinates the required validation, state handling, evidence commitment, and capability availability. An illustrative transaction is: (Snext, Rwatch, Ready) = CommitWatchdogFinality(Dwatch, A, Mv, Scurrent, F) where: Snext denotes committed protected authorization state; Rwatch denotes protected validation evidence; Ready denotes satisfaction of mandatory pre-release conditions; Dwatch denotes the Candidate Act Descriptor; A denotes applicable authenticated authority; Mv denotes the validated monitoring-state version; Scurrent denotes prior protected authorization state; and Das Expires 19 April 2027 [Page 669] Internet-Draft Protected AI Execution Finality October 2026 F denotes the designated Finality Sink. The capability-release mechanism does not treat an incomplete mandatory commitment as successful authorization. The transaction may be implemented through protected storage, authenticated state machines, HSM-controlled procedures, or equivalent protected state mechanisms. Where the operation spans multiple services, the capability remains unavailable until the required protected dependencies are verified. 11.16.21. WF-16.21 — Monitoring-State-Bound Execution Capability CR-1611 generates or makes available a scoped execution capability. An illustrative capability contains or securely references: capability_id; candidate_act_descriptor_digest; authorized_workload_id; monitoring_state_version; monitoring_record_digest; authorized_operation_scope; policy_epoch; revocation_epoch; nonce; expiry; usage_limit; protected_validation_record_digest; finality_sink_id. In a non-limiting cryptographic implementation: Cwatch = Sign_skPED(Encode(hWatch, hR, Mv, Scope, Epoch, Rev, Nonce, Expiry, F)) Das Expires 19 April 2027 [Page 670] Internet-Draft Protected AI Execution Finality October 2026 where: Cwatch denotes the scoped capability; Sign_skPED denotes capability authentication under PED-controlled key material; hWatch denotes the Candidate Act Descriptor digest; hR denotes the committed validation-evidence digest; Mv denotes the required monitoring-state version; Scope denotes the authorized operation scope; Epoch denotes the policy epoch; Rev denotes the applicable revocation-state reference; Nonce denotes freshness; Expiry denotes validity; and F denotes the designated Finality Sink. The capability may alternatively be implemented as a protected table entry, sealed handle, authenticated execution permit, or hardware enablement condition. Its usability remains dependent upon the actual operation, mandatory monitoring version, protected state, and applicable Finality Sink verification. 11.16.22. WF-16.22 — Multiple Independently Enforceable Finality Sinks in the implementation described by enforcement point 62, the protected architecture includes independently enforceable Finality Sinks associated with two or more consequential operation classes. A representative configuration may comprise: Network Finality Sink: Verifies the required capability before permitting governed external transmission. Tool/API Finality Sink: Verifies the required capability before dispatching a privileged tool or API operation. Das Expires 19 April 2027 [Page 671] Internet-Draft Protected AI Execution Finality October 2026 Credential Finality Sink: Verifies the required capability before applying protected credential material. Storage Finality Sink: Verifies the required capability before committing persistent data. Payment Finality Sink: Verifies the required capability before issuing a protected financial operation. Accelerator Finality Sink: Verifies the required capability before protected model-state or tensor export. Actuator Finality Sink: Verifies the required capability before enabling a governed physical-control operation. Each applicable Finality Sink independently verifies the authorization conditions required by its own effectuation interface. An approval or capability for one effectuation class is not automatically sufficient for another. The monitoring-state record may be shared among multiple authorization decisions, but each governed consequential operation remains subject to the appropriate operation-specific capability and Finality Sink checks. 11.16.23. WF-16.23 — Independent Finality Sink Verification Before permitting CA-1621 to become effective, the designated Finality Sink reconstructs or verifies the actual operation presented for effectuation. The Finality Sink verifies: (a) capability authenticity; (b) Candidate Act Descriptor correspondence; (c) authorized workload identity; (d) permitted operation class; (e) destination or resource restrictions; (f) required monitoring-state version; (g) applicable monitoring-state validity; Das Expires 19 April 2027 [Page 672] Internet-Draft Protected AI Execution Finality October 2026 (h) current required policy epoch; (i) revocation state; (j) nonce and expiry; (k) protected validation-evidence reference; (l) capability usage or consumption state; and (m) designated Finality Sink identity. The operation is refused when a mandatory verification condition is absent or invalid. The Finality Sink does not treat a generic watchdog statement that the workload is healthy as sufficient authorization for a concrete external effect. 11.16.24. WF-16.24 — Monitoring-State-Aware Sink Predicate An illustrative effectuation predicate is: PermitSink = Auth(C) AND Match(C,Dactual) AND MonitorValid(C,Mcurrent) AND StateValid(C,S) AND SinkValid(C,F) where: PermitSink denotes permission to effectuate the Candidate Act; C denotes the scoped execution capability; Dactual denotes the actual effectuation descriptor; Mcurrent denotes the monitoring-state version and status required at the Finality Sink; S denotes current protected authorization state; and F denotes the Finality Sink. Auth verifies capability authenticity. Match verifies exact or expressly authorized bounded operation correspondence. MonitorValid verifies the mandatory monitoring-state version, freshness, and enforcement-state conditions. Das Expires 19 April 2027 [Page 673] Internet-Draft Protected AI Execution Finality October 2026 StateValid verifies required policy, revocation, validation evidence, and usage state. SinkValid verifies the designated effectuation boundary. The operation becomes effective only when every mandatory predicate succeeds. 11.16.25. WF-16.25 — Watchdog-Detected Violation in the implementation described by enforcement point 64, WM-1602 detects a governance-relevant condition such as: (a) execution-policy violation; (b) authority-scope deviation; (c) unauthorized tool activity; (d) runtime-behavior anomaly; (e) unauthorized privilege escalation; (f) attempted execution-path bypass; (g) invalid protected workload measurement; or (h) another monitored condition specified by the applicable security policy. The monitoring domain records or authenticates the detected condition. The detected condition is submitted to the protected monitoring-state and revocation machinery. The corresponding action may include advancement of the protected monitoring-state version, revocation of affected authorization, restriction of further capability issuance, or quarantine. The system does not presume that every detected anomaly necessarily indicates an already completed unauthorized external effect. 11.16.26. WF-16.26 — Protected Revocation-Fence Advancement RF-1612 advances the protected monitoring-state or revocation version. Das Expires 19 April 2027 [Page 674] Internet-Draft Protected AI Execution Finality October 2026 An illustrative transition is: MONITOR_VERSION = v → v+1 where the new state invalidates capabilities that are no longer permitted under the applicable protected monitoring policy. A corresponding revocation record may contain: workload_id; previous_monitoring_version; new_monitoring_version; revocation_reason; effective_policy_epoch; affected_operation_classes; affected_finality_sinks; revocation_sequence; protected_authentication. The revocation mechanism prevents an affected capability bound to an incompatible earlier state from being accepted for a new governed consequential operation. The revocation fence is effective only to the extent that the participating Finality Sinks actually verify the required current state or an authorized freshness-bounded equivalent. A revocation record stored only in a monitoring log does not independently prevent effectuation. 11.16.27. WF-16.27 — Enforcement of Superseded Monitoring Versions Each affected Finality Sink verifies whether the capability's monitoring-state version remains acceptable under the current required authorization state. An illustrative condition is: MonitorVersionValid = AcceptedVersion(C.monitor_version, CurrentProtectedMonitorState) Das Expires 19 April 2027 [Page 675] Internet-Draft Protected AI Execution Finality October 2026 where: AcceptedVersion denotes the authorized version-verification rule; C.monitor_version denotes the monitoring-state version bound to the capability; and CurrentProtectedMonitorState denotes the applicable protected monitoring-state reference. Where exact current-version matching is required, a capability bound to a superseded version is rejected. Where a protected authority permits a bounded freshness interval, the Finality Sink verifies the corresponding authorized validity rule. An expired or revoked version is not treated as acceptable merely because the capability was previously valid. The implementation must account for distributed propagation delay and the actual freshness guarantees required by the claim. 11.16.28. WF-16.28 — Prevention Despite Continued or Interrupted Model Access in the implementation described by enforcement point 65, model-access control is distinguishable from downstream Finality Sink enforcement. An AI model may successfully complete an earlier inference operation and produce a Candidate Act. A watchdog may subsequently detect an execution anomaly and interrupt further model access. The already generated Candidate Act remains subject to downstream Finality Sink verification. Likewise, where the model remains available for permitted inference, the downstream Finality Sink may independently refuse a consequential operation because its monitoring-state or operation-specific authorization conditions are invalid. The architecture therefore does not require a model-access interruption to be the sole means of preventing external effects. A model-access gate may control further inference. Das Expires 19 April 2027 [Page 676] Internet-Draft Protected AI Execution Finality October 2026 A downstream Finality Sink controls the actual governed consequential operation. The two functions remain distinct. 11.16.29. WF-16.29 — Monitoring-State Unavailability in the implementation described by enforcement point 66, the protected system determines whether a mandatory monitoring-state record is unavailable. Unavailability may arise from: (a) hardware watchdog failure; (b) DPU or security-controller reset; (c) loss of authenticated monitoring communication; (d) monitoring-state storage failure; (e) expired monitoring attestation; (f) broken monitoring-state continuity; (g) protected verification service outage; or (h) another specified monitoring infrastructure failure. Where current monitoring state is mandatory for an affected consequential operation, unavailability does not create permission to proceed. The PED withholds the corresponding new execution capability or the Finality Sink refuses it until an authorized recovery or revalidation condition succeeds. An unmonitored fallback path is not treated as safe solely because the monitoring component is unavailable. 11.16.30. WF-16.30 — Stale and Inconsistent Monitoring-State Handling The system evaluates whether the monitoring record is stale, inconsistent, or outside the permitted freshness interval. An illustrative predicate is: Das Expires 19 April 2027 [Page 677] Internet-Draft Protected AI Execution Finality October 2026 MonitoringAcceptable = Authentic(M) AND VersionValid(M) AND Fresh(M) AND WorkloadMatch(M) AND EnforcementStateValid(M) where: M denotes the monitoring-state record. Authentic verifies its required authentication. VersionValid verifies monitoring-state version. Fresh verifies its validity interval or protected sequence. WorkloadMatch verifies association with the correct monitored workload. EnforcementStateValid verifies that the monitoring-state indicator permits the requested operation under the applicable policy. If a mandatory predicate fails, the affected Candidate Act remains non-effective. The protected system may request fresh monitoring evidence, use another separately authorized monitoring source, or enter a protected recovery procedure. The absence of monitoring evidence is not interpreted as proof of a healthy workload. 11.16.31. WF-16.31 — Protected Monitoring Recovery RC-1619 coordinates recovery from invalid or unavailable monitoring state. The recovery procedure may require: (a) authentication of the recovered monitoring component; (b) verification of protected hardware or software measurements; (c) establishment of a fresh monitoring generation; (d) verification of workload identity; (e) restoration or reconciliation of protected state; (f) confirmation of current policy and revocation conditions; Das Expires 19 April 2027 [Page 678] Internet-Draft Protected AI Execution Finality October 2026 (g) invalidation of incompatible earlier monitoring records; and (h) renewed operation-specific authorization. The protected recovery procedure does not automatically restore previously consumed, denied, expired, or revoked execution authority. A fresh monitoring-state record may permit new authorization evaluations when its mandatory predicates succeed. It does not automatically release a pending Candidate Act without the required operation-specific capability and Finality Sink verification. 11.16.32. WF-16.32 — Quarantine Initiation in the implementation described by enforcement point 67, QC-1617 receives a protected quarantine command or an authenticated quarantine-state reference. The quarantine command may arise from: (a) a monitoring-policy violation; (b) invalid workload attestation; (c) revoked authorization state; (d) an unsafe runtime condition; (e) a protected operator decision; (f) a security-controller decision; or (g) another authorized containment condition. The quarantine command identifies the affected workload, execution domain, resources, permitted containment scope, and required enforcement targets. An illustrative quarantine record comprises: quarantine_id; workload_id; quarantine_reason; Das Expires 19 April 2027 [Page 679] Internet-Draft Protected AI Execution Finality October 2026 monitoring_state_version; policy_epoch; affected_operation_classes; affected_interfaces; quarantine_start; authorized_recovery_reference; protected_authentication. The quarantine record is an enforcement-state artifact, not an unrestricted capability authorizing unrelated rollback or replay operations. 11.16.33. WF-16.33 — Quarantine Enforcement QC-1617 may restrict: (a) further model inference; (b) tool execution; (c) external network transmission; (d) credential-mediated operations; (e) privileged connector access; (f) infrastructure control; (g) artifact deployment; (h) accelerator-state export; or (i) other governed workload functions. The applicable containment mechanism may use: (a) protected process suspension; (b) sandbox restriction; (c) network-egress blocking; Das Expires 19 April 2027 [Page 680] Internet-Draft Protected AI Execution Finality October 2026 (d) credential revocation; (e) protected service-access controls; (f) hardware forwarding restrictions; (g) workload isolation; (h) protected execution-policy changes; or (i) another authorized containment mechanism. The quarantine's actual prevention guarantee depends upon which future effects the selected enforcement interfaces can block. Quarantine does not retroactively undo a completed transmission, payment, storage commitment, or physical actuation. 11.16.34. WF-16.34 — Preservation of Effectuation State During Quarantine OS-1618 preserves operation-specific status when quarantine occurs. An illustrative state model comprises: PENDING; VALIDATING; AUTHORIZED; RESERVED; EFFECTUATION_ATTEMPTED; CONFIRMED_EFFECTIVE; DENIED; REVOKED; QUARANTINED; INDETERMINATE. The system distinguishes: Das Expires 19 April 2027 [Page 681] Internet-Draft Protected AI Execution Finality October 2026 Pending Candidate Acts: Operations that have not yet crossed the governed effectuation boundary and remain subject to required authorization. Confirmed-Effective Operations: Operations for which suitable evidence establishes completion of the specified consequential effect. Indeterminate Operations: Operations that may have crossed the effectuation boundary but whose completion cannot be established. The quarantine mechanism does not rewrite a confirmed-effective operation into a prevented operation. It also does not assume that an indeterminate operation failed. Pending operations remain non-effective unless separately authorized under applicable current conditions. 11.16.35. WF-16.35 — No Automatic Rollback or Replay Authority A quarantine command does not independently authorize: (a) rollback of a completed transaction; (b) cancellation of a previously completed payment; (c) repeated execution of an uncertain operation; (d) replay of an already consumed capability; (e) restoration of revoked permissions; (f) deletion of protected evidence; (g) completion of an unverified Candidate Act; or (h) another consequential recovery operation. Where rollback or recovery produces a governed consequential effect, the operation may itself constitute a new Candidate Act. The applicable protected authority validates its scope, required state, and effectuation boundary. A previously valid capability does not automatically authorize an unrelated rollback or repeated effectuation. Das Expires 19 April 2027 [Page 682] Internet-Draft Protected AI Execution Finality October 2026 11.16.36. WF-16.36 — Cross-Component Monitoring-State Consistency Where multiple Finality Sinks participate, SC-1620 verifies the required correspondence among their monitoring and authorization states. The relevant state may include: (a) monitored workload identity; (b) monitoring-state version; (c) monitoring-state validity; (d) protected revocation epoch; (e) applicable policy epoch; (f) Candidate Act identity; (g) operation-specific capability identity; (h) protected validation-evidence reference; (i) usage or consumption state; and (j) Finality Sink identity. The implementation may use authenticated version records, protected revocation services, signed state updates, protected local caches, or equivalent mechanisms. A participating Finality Sink must not treat an invalid required state as valid merely because another component has not yet received an update. Where freshness-bounded caching is expressly permitted, the implementation enforces the required validity interval. When mandatory consistency cannot be established, the affected operation remains blocked. The embodiment does not automatically require globally instantaneous synchronization or a single centralized authority. Das Expires 19 April 2027 [Page 683] Internet-Draft Protected AI Execution Finality October 2026 11.16.37. WF-16.37 — Illustrative Network and Storage Dual-Sink System In one concrete implementation, an AI agent executes within a protected cloud workload. WM-1602 operates as an isolated security component monitoring the workload. The agent prepares two consequential operations: First, an outbound HTTPS request. Second, a persistent database modification. The network request is associated with FS-1613. The database modification is associated with FS-1615. MG-1604 generates a protected monitoring-state record identifying the monitored workload, monitoring-state version, validity interval, and enforcement-state indicator. For each Candidate Act, PED-1608 validates the applicable operation- specific Authority Object and required current monitoring state. Following successful authorization, the protected system commits the required evidence and makes available a scoped capability for the particular operation and Finality Sink. The network Finality Sink verifies the capability applicable to the HTTPS request. The storage Finality Sink separately verifies the capability applicable to the database modification. Authorization of the network request does not independently authorize the database commit. If the monitoring-state version becomes invalid before the database Finality Sink permits commitment, the database operation is refused under the mandatory state rules. The earlier network effect is not falsely treated as prevented if it was already transmitted. Das Expires 19 April 2027 [Page 684] Internet-Draft Protected AI Execution Finality October 2026 11.16.38. WF-16.38 — Illustrative Watchdog-to-Finality Revocation An AI agent receives valid authority to use a protected enterprise API. The PED issues an operation-specific capability bound to monitoring- state version 25. Before the agent submits the operation to its Finality Sink, the out- of-band monitor detects an unauthorized privilege change. The protected monitoring-state mechanism advances the required monitoring version to 26 and records a revocation condition. The affected API Finality Sink obtains the current protected monitoring-state reference. The previously issued capability remains bound to version 25. The capability no longer satisfies the mandatory monitoring-state predicate. The Finality Sink refuses the API operation. The prevention occurs at the effectuation boundary, not merely because the watchdog generated an alert. 11.16.39. WF-16.39 — Illustrative Continued-Inference Scenario An AI model remains available to perform inference. During execution, it produces a proposed payment instruction. The instruction is classified as a Candidate Act and staged. A protected monitoring component detects an authority-scope anomaly relevant to payment execution. The monitoring-state version advances. The payment Finality Sink verifies the current required monitoring state before executing the payment. The capability bound to the superseded state is rejected. The payment does not become effective through the governed interface. Das Expires 19 April 2027 [Page 685] Internet-Draft Protected AI Execution Finality October 2026 The fact that the AI model may continue producing computational output does not independently defeat the downstream protected enforcement requirement. 11.16.40. WF-16.40 — Illustrative Watchdog Failure An AI agent prepares an outbound credential-mediated operation. Before protected authorization completes, the out-of-band monitoring component becomes unavailable. The applicable Authority Object requires a fresh authenticated monitoring-state record. PED-1608 cannot establish the required monitoring predicate. The corresponding capability is withheld. The Finality Sink refuses credential-mediated effectuation. The protected recovery mechanism may attempt to restore the monitor, establish a fresh authenticated state, and revalidate the operation. The workload is not granted unrestricted credential use merely because the watchdog failed. 11.16.41. WF-16.41 — Illustrative Quarantine After Possible External Effect An agent submits a network request through a governed egress interface. The interface accepts the authorized transmission, but the remote service's final processing result is not available. The out-of-band monitor subsequently detects suspicious behavior and issues a quarantine condition. The workload is restricted from further governed network operations. OS-1618 records the earlier request as indeterminate if the available evidence cannot establish remote completion. The system does not automatically replay the request or claim that quarantine prevented a request that may already have reached the remote service. Das Expires 19 April 2027 [Page 686] Internet-Draft Protected AI Execution Finality October 2026 Any retry is subjected to protected recovery and duplicate-effect prevention conditions. This illustrates the distinction between prospective containment and retrospective outcome determination. 11.16.42. WF-16.42 — Alternative Technical Implementations The protected watchdog-to-finality arrangement may be implemented through different substrates. DPU monitoring implementation: A protected DPU performs monitoring and provides authenticated monitoring-state information to the applicable execution authority and Finality Sinks. Secure-controller implementation: A hardware security controller or isolated processor generates protected monitoring-state records. Protected accelerator implementation: A separately controlled accelerator or monitoring processor evaluates selected workload conditions. Host-assisted implementation: A privileged host-security service observes an isolated agent runtime and supplies authenticated state, subject to the host's actual isolation guarantees. Network-enforcement implementation: A protected network gateway or NIC verifies a monitoring-state-bound capability before transmission. Credential-enforcement implementation: A protected credential broker verifies the required monitoring and operation state before credential application. Storage-enforcement implementation: A protected database or storage controller verifies the capability before committing a governed mutation. Multi-node implementation: A protected monitoring component and several distributed Finality Sinks exchange authenticated state and version information. Single-node implementation: Monitoring, authorization, evidence commitment, capability issuance, and local Finality Sink verification operate within one protected node while retaining distinguishable functional roles. Das Expires 19 April 2027 [Page 687] Internet-Draft Protected AI Execution Finality October 2026 Hardware-interlock implementation: A protected physical or device- control interface requires the corresponding bounded capability before actuation or transfer. The selected implementation determines the actual isolation, monitoring coverage, revocation propagation, bypass resistance, and failure-recovery guarantees. Out-of-band monitoring is not automatically equivalent to mandatory inline enforcement. 11.16.43. WF-16.43 — Failure and Fail-Closed Conditions The protected system refuses the governed operation when any mandatory condition is absent, invalid, expired, revoked, stale, inconsistent, replayed, or unverifiable. Non-limiting denial conditions include: (a) missing monitoring-state record; (b) invalid monitoring-record authentication; (c) workload identity mismatch; (d) monitoring-domain identity mismatch; (e) invalid attestation; (f) replayed monitoring sequence; (g) stale monitoring-state version; (h) monitoring-state expiry; (i) unavailable monitoring component; (j) monitoring communication failure; (k) unauthorized enforcement-state indicator; (l) incompatible policy epoch; (m) invalid revocation state; (n) missing operation-specific Authority Object; (o) invalid Candidate Act Descriptor; Das Expires 19 April 2027 [Page 688] Internet-Draft Protected AI Execution Finality October 2026 (p) unauthorized destination or operation class; (q) failed protected-state transition; (r) failed required validation-evidence commitment; (s) missing execution-enabling capability; (t) invalid capability authentication; (u) monitoring version mismatch; (v) capability expiry; (w) capability replay; (x) capability-consumption mismatch; (y) Finality Sink identity mismatch; (z) unavailable required Finality Sink verification; or (aa) failure of mandatory enforcement-path coverage. The affected Candidate Act remains non-effective, denied, quarantined, or subject to an authorized recovery procedure. A watchdog failure or security alert does not create authority to bypass protected finality verification. 11.16.44. WF-16.44 — PHOSITA Verification and Negative Tests A person having ordinary skill in hardware security, watchdog systems, DPUs, secure controllers, protected computing, AI-agent infrastructure, distributed authorization, revocation systems, and execution-finality enforcement may verify the architecture through controlled tests. Test 1 — Valid monitoring state: Supply a current authenticated monitoring record and a matching operation-specific capability. The appropriate Finality Sink permits the authorized effect. Test 2 — Missing monitoring state: Present a governed Candidate Act without required monitoring evidence. Effectuation is refused. Test 3 — Forged monitoring record: Present a record with invalid protected authentication. PED validation fails. Das Expires 19 April 2027 [Page 689] Internet-Draft Protected AI Execution Finality October 2026 Test 4 — Wrong workload: Use a monitoring record associated with another workload. Required workload binding fails. Test 5 — Monitoring-version mismatch: Issue a capability for one monitoring version and present it under an incompatible current version. Finality Sink verification fails. Test 6 — Stale monitoring record: Present a record beyond its authorized freshness interval. The operation remains blocked. Test 7 — Watchdog-to-finality revocation: Detect a required policy violation, advance protected monitoring state, and verify rejection of affected superseded capabilities. Test 8 — Network Finality Sink: Present a valid monitoring record but an invalid network operation capability. The transmission is refused. Test 9 — Storage Finality Sink: Present a valid network capability to a separately governed storage interface. The storage commit is refused. Test 10 — Credential Finality Sink: Attempt protected credential use after relevant monitoring-state revocation. The credential-mediated effect is denied. Test 11 — Continued inference: Permit further model computation while withholding downstream operation authority. The protected Finality Sink prevents the unauthorized effect. Test 12 — Model interruption after output generation: Stop further inference after a Candidate Act has been buffered. Verify that the buffered operation remains subject to independent Finality Sink authorization. Test 13 — Hardware watchdog failure: Make the monitoring component unavailable. Affected operations requiring fresh monitoring state remain blocked. Test 14 — Monitoring communication failure: Interrupt delivery of required authenticated monitoring state. The protected system does not assume continued validity beyond its permitted freshness conditions. Test 15 — Revocation propagation delay: Present an affected capability at a distributed Finality Sink and verify enforcement of the required current-state or freshness-bound rules. Das Expires 19 April 2027 [Page 690] Internet-Draft Protected AI Execution Finality October 2026 Test 16 — Capability replay: Reuse a consumed single-use capability. Protected usage verification rejects it. Test 17 — Concurrent capability use: Submit simultaneous operations using one restricted grant. The protected system prevents unauthorized double consumption. Test 18 — Wrong Finality Sink: Present a capability for another effectuation boundary. Required sink binding fails. Test 19 — Quarantine before effectuation: Trigger quarantine while a Candidate Act remains pending. The pending operation cannot bypass protected authorization. Test 20 — Quarantine after completed effect: Trigger quarantine after a confirmed external operation. The completed effect remains recorded as effective. Test 21 — Quarantine with uncertain outcome: Interrupt a remote operation after possible delivery and trigger quarantine. The outcome is preserved as indeterminate until authorized reconciliation. Test 22 — Unauthorized rollback: Attempt rollback based solely on a quarantine command. The operation is refused without its separately required authority. Test 23 — Unauthorized retry: Replay an uncertain consequential operation without valid protected recovery authority. The duplicate attempt is blocked. Test 24 — Monitoring-state rollback: Restore an earlier monitoring- state version through workload snapshot manipulation. Required protected version verification rejects stale authority. Test 25 — Invalid recovery attestation: Attempt restoration of monitoring authority using an invalid component measurement. Recovery fails. Test 26 — Valid protected recovery: Reestablish a fresh authenticated monitoring state and perform renewed operation-specific authorization. Only the valid new operation is permitted. Test 27 — Multiple effectuation classes: Verify that network, API, credential, storage, or other designated Finality Sinks independently enforce their own operation-specific capabilities. Das Expires 19 April 2027 [Page 691] Internet-Draft Protected AI Execution Finality October 2026 Test 28 — Monitoring alert without inline enforcement: Test an implementation that merely reports violations. Confirm that alert generation alone does not establish a protected prevention guarantee. Test 29 — Single-node implementation: Implement protected monitoring, authorization, and effectuation functions within one protected controller. Verify the required functional separation and mandatory effectuation checks. Test 30 — Distributed implementation: Place the monitor, PED, and several Finality Sinks on different nodes. Verify authenticated monitoring-state association and operation-specific capability enforcement. Test 31 — Policy-state inconsistency: Present a valid-looking capability with an incompatible required policy or revocation epoch. The Finality Sink refuses effectuation. Test 32 — Alternative-path bypass: Attempt the same governed consequence through an accessible path not controlled by the selected Finality Sink. The implementation blocks or equivalently mediates the path. The tests may be implemented through controlled AI workloads, mock DPUs, protected controller emulators, authenticated monitoring services, programmable Finality Sinks, versioned authorization-state stores, network and storage test interfaces, fault injection, hardware-reset simulation, and protected recovery instrumentation. The tests establish the security properties of the actual enforcement implementation under its stated trust assumptions. 11.16.45. WF-16.45 — Claim-Specific Technical Support Enforcement Point 62 — Distributed Hardware-Watchdog Execution Interlock System The workflow describes: (a) AE-1601 representing the artificial-intelligence execution domain; (b) WM-1602 representing the isolated out-of-band monitoring domain; (c) MG-1604 generating a protected monitoring-state record comprising workload identity, monitoring-state version, validity condition, and enforcement-state indicator; Das Expires 19 April 2027 [Page 692] Internet-Draft Protected AI Execution Finality October 2026 (d) PED-1608 evaluating operation-specific authorization using the protected monitoring-state record; (e) multiple independently enforceable Finality Sinks associated with distinct consequential operation classes; (f) CR-1611 generating or making available a capability bound to the Candidate Act, monitoring-state version, protected authorization state, and Finality Sink; (g) independent Finality Sink verification of the required capability and monitoring state; and (h) fail-closed refusal where mandatory monitoring state is invalid, unavailable, stale, inconsistent, or revoked. Enforcement Point 63 — Hardware-Attested Monitoring State WF-16.10 through WF-16.11 describe cryptographic authentication or hardware attestation of monitoring-state records and validation of authenticity, workload association, version, and freshness. Enforcement Point 64 — Watchdog-to-Finality Revocation Fence WF-16.25 through WF-16.27 describe detection of monitored violations, advancement of protected monitoring-state or revocation versions, and rejection of capabilities bound to superseded required authorization state. Enforcement Point 65 — Prevention Despite Continued Model Access WF-16.28 and WF-16.39 describe independent downstream Finality Sink enforcement notwithstanding earlier successful inference, continued model availability, or possession of previously generated model output. Enforcement Point 66 — Monitoring Failure and Stale-State Handling WF-16.29 through WF-16.31 describe fail-closed handling of missing, stale, invalid, or inconsistent monitoring records and protected recovery or revalidation before accepting new affected execution authority. Enforcement Point 67 — Quarantine with Effectuation-State Preservation Das Expires 19 April 2027 [Page 693] Internet-Draft Protected AI Execution Finality October 2026 WF-16.32 through WF-16.35 describe restricted post-detection operation, preservation of confirmed-effective, pending, and indeterminate states, and prohibition of automatic rollback, replay, duplicate effectuation, or release of unverified operations. 11.16.46. WF-16.46 — Technical Effect The disclosed workflow establishes a protected causal relationship between: (a) an AI execution domain generating or requesting a consequential operation; (b) an isolated out-of-band monitor producing authenticated execution-state information; (c) generation of a versioned protected monitoring-state record; (d) mandatory interception and Non-Effective State staging of the Candidate Act; (e) construction of an operation-specific Candidate Act Descriptor; (f) protected validation of applicable authority and the required monitoring-state version; (g) required protected authorization-state handling; (h) protected validation-evidence commitment; (i) generation or availability of a monitoring-state-bound execution capability; (j) independent capability and current-state verification at the applicable Finality Sink; (k) controlled consequential effectuation or fail-closed refusal; (l) revocation-fence advancement when a mandatory monitored condition becomes invalid; and (m) quarantine and recovery preserving accurate operation- effectuation state. The architecture prevents a generic watchdog observation, a previous model-access permission, or an ordinary agent authentication result from substituting for the protected authorization required by a specific consequential operation. Das Expires 19 April 2027 [Page 694] Internet-Draft Protected AI Execution Finality October 2026 The hardware-watchdog embodiment permits separately protected monitoring to influence operation-specific authorization without assuming that detection alone prevents external effects. The revocation-fence embodiment causes capabilities bound to invalidated monitoring state to fail the required subsequent Finality Sink verification. The multi-sink embodiment protects distinct network, tool, credential, storage, financial, accelerator, and physical-control boundaries according to their applicable authorization requirements. The quarantine embodiment restricts future governed activity while preserving the distinction between operations already completed, operations still pending, and operations whose completion status is uncertain. Computation is not authority to act. Monitoring is not authorization. Detection is not prevention unless the relevant effectuation boundary is actually controlled. Stopping further inference does not retroactively prevent completed downstream effects. Quarantine does not authorize rollback, replay, or duplication of a consequential operation. 11.17. WF-17 — Protected Confidential Virtual-Machine Execution, Hardware-Rooted Composite ALF Validation, Workload-to-Act Authorization, Privacy-Preserving Validation, Tenant-Bound Capabilities, and Snapshot-Rollback-Resistant Finality 11.17.1. WF-17.1 — Technical Purpose This embodiment describes a computer-implemented protected execution- finality architecture governing externally effective operations generated by an artificial-intelligence workload executing within a confidential or virtualized cloud-computing environment. The system provides a protected relationship between: (a) an artificial-intelligence workload executing within a confidential or isolated virtual machine; Das Expires 19 April 2027 [Page 695] Internet-Draft Protected AI Execution Finality October 2026 (b) machine-verifiable measurement of the workload's actual execution context; (c) protected validation of the measured model, software, workflow, and policy state; (d) interception and Non-Effective State staging of a proposed consequential operation; (e) independent protected authorization of the particular Candidate Act; (f) protected validation-evidence generation or commitment; (g) scoped, non-bearer execution-capability availability; and (h) independent Finality Sink verification before effectuation. The protected execution environment may provide hardware-assisted memory confidentiality, integrity protection, measured launch, workload attestation, or other properties according to its implementation. Such properties protect specified aspects of computation but do not independently establish authority for the workload to cause an externally effective operation. The AI workload may compute, generate outputs, prepare tools, construct API requests, modify temporary state, and propose external operations. A governed Candidate Act remains in a Non-Effective State until its applicable protected authorization conditions succeed and its required execution capability verifies at the corresponding Finality Sink. The architecture additionally addresses: (a) hardware-rooted Composite Algorithmic Logic Fingerprints; (b) comparison of actual runtime-used model and workflow state with approved conditions; (c) privacy-preserving validation evidence; (d) tenant and destination binding; Das Expires 19 April 2027 [Page 696] Internet-Draft Protected AI Execution Finality October 2026 (e) protected capability-consumption state outside rollback- accessible workload snapshots; and (f) crash, migration, restart, and virtual-machine snapshot recovery. The embodiment is not limited to one confidential-computing vendor, hypervisor, operating system, processor architecture, cryptographic algorithm, or cloud provider. 11.17.2. WF-17.2 — Participating Technical Components In one non-limiting implementation, the system comprises the following components. CV-1701 — Confidential or Isolated Virtual-Machine Execution Environment A confidential VM, isolated virtual machine, hypervisor-protected workload, or equivalent virtualized execution environment hosting an AI agent, model runtime, tool process, or agentic workflow. AE-1702 — AI-Agent Compute Plane An artificial-intelligence model, agent, planner, tool runtime, or associated process executing within CV-1701 and configured to generate Candidate Acts. HM-1703 — Execution-Context Measurement Component A component configured to obtain machine-verifiable measurements or attestations associated with the VM, model, software configuration, execution policy, workload identity, or other required runtime context. ALF-1704 — Composite ALF Construction and Verification Component A mechanism configured to construct, obtain, or verify an Algorithmic Logic Fingerprint incorporating applicable model, software, workflow, policy, and hardware-related measurements. IM-1705 — Candidate Act Interception Component An enforcement-controlled interface configured to intercept a proposed consequential operation before a governed cloud, host, network, storage, or service effectuation boundary. HQ-1706 — Non-Effective Holding Mechanism Das Expires 19 April 2027 [Page 697] Internet-Draft Protected AI Execution Finality October 2026 A controlled queue, buffer, pending request object, protected command representation, or equivalent mechanism retaining a Candidate Act until required protected authorization succeeds. DC-1707 — Candidate Act Descriptor Component A component configured to construct or verify a canonical, machine- readable description of the actual proposed operation and its finality-relevant context. PED-1708 — Protected Enforcement Domain An enforcement or authorization component isolated from unilateral execution authority controlled by the AI workload and configured to validate execution context, applicable authority, protected state, and Candidate Act-specific predicates. AS-1709 — Protected Authority and Policy Store A protected mechanism maintaining Authority Objects, approved ALF conditions, workload identity requirements, policy epochs, tenant scope, revocation state, and authorized destination conditions. PS-1710 — Protected Authorization-State Store A protected mechanism maintaining nonce state, capability usage, revocation epochs, validation commitments, execution-state versions, and protected authorization transitions. EV-1711 — Protected Validation-Evidence Component A mechanism configured to generate or commit authenticated validation evidence, including applicable LAVR, AVR, sealed receipt, or ZK-LAVR representations. CR-1712 — Scoped Capability Release Mechanism A protected component configured to generate, register, derive, release, or make available a scoped, non-bearer execution capability. FS-1713 — Confidential Workload Finality Sink A protected cloud, host, service-mesh, API, credential-release, storage-commit, or network-transmission interface that verifies the required execution capability before allowing the corresponding consequential effect. TC-1714 — Tenant and Destination Context Verifier Das Expires 19 April 2027 [Page 698] Internet-Draft Protected AI Execution Finality October 2026 A mechanism configured to verify the tenant, workload, virtual- machine, destination service, and network-context bindings required by the authorization. RS-1715 — Rollback-Resistant Protected State Component A protected mechanism maintaining required nonce, capability- consumption, revocation, and hardware-freshness information outside rollback-accessible portions of the AI workload. OS-1716 — Protected Effectuation Outcome Store A mechanism maintaining pending, authorized, reserved, denied, confirmed-effective, indeterminate, expired, or revoked operation state. RC-1717 — Recovery and State-Reconciliation Component A mechanism configured to reconcile protected authority, capability- consumption, attestation, and operation-completion state following VM restart, snapshot restoration, migration, or infrastructure failure. The functions may be distributed or colocated. The Protected Enforcement Domain may be implemented through a protected host service, TEE, HSM, confidential governance component, hardware controller, or other suitable enforcement arrangement. The Finality Sink may be physically separate from or integrated with the PED where the required distinct authorization and effectuation- verification functions remain enforced. 11.17.3. WF-17.3 — Establishment of the Confidential-Computing Trust Boundary Before permitting governed AI operations, CV-1701 establishes the applicable protected execution environment. The selected implementation may provide: (a) hardware-assisted memory encryption; (b) protected workload memory integrity; (c) measured virtual-machine launch; (d) authenticated boot measurements; Das Expires 19 April 2027 [Page 699] Internet-Draft Protected AI Execution Finality October 2026 (e) virtual-machine attestation; (f) protected workload identity; (g) protected device configuration; (h) isolated memory mappings; or (i) another supported confidential-computing property. The actual protection depends upon the processor, hypervisor, firmware, launch protocol, attestation mechanism, and configured threat model. A confidential VM does not automatically prevent an authorized guest process from issuing an unauthorized external operation. Likewise, hardware protection of guest memory does not inherently establish that an external network, credential, or storage interface performs operation-specific authorization. The system therefore establishes a separate protected execution- finality boundary for each governed consequential operation. 11.17.4. WF-17.4 — Isolation of Protected Execution Authority PED-1708 is configured so that AE-1702 cannot unilaterally modify the protected authorization conditions required for its governed Candidate Acts. The AI workload may request authorization and supply measured context or operation information. However, it cannot independently: (a) create valid protected capability-signing authority; (b) modify required authorization-state records; (c) restore consumed capabilities; (d) invalidate mandatory Finality Sink verification; (e) widen protected tenant permissions; (f) replace approved ALF conditions; (g) override protected revocation state; or Das Expires 19 April 2027 [Page 700] Internet-Draft Protected AI Execution Finality October 2026 (h) bypass a mandatory effectuation interface. The PED may operate outside the guest VM, inside a separately protected execution domain, or within a protected arrangement that preserves the required isolation from the requesting agent. Physical separation is not mandatory unless expressly required under the specified enforcement profile. 11.17.5. WF-17.5 — Identification of Governed Effectuation Paths The system identifies the operations for which confidential-workload finality enforcement is required. Such operations may include: (a) outbound network transmission; (b) privileged API invocation; (c) credential release or application; (d) persistent storage modification; (e) database commitment; (f) protected service invocation; (g) model-output release; (h) software deployment; (i) cross-tenant data transfer; or (j) another externally effective operation. Each governed operation is associated with an appropriate Finality Sink. The implementation configures the applicable network, host, storage, or service interfaces so that the AI workload cannot produce the specified governed effect through an unrestricted alternative path. A confidential VM that can independently use an unmediated external interface does not satisfy the specified non-bypassable finality guarantee for that interface. Das Expires 19 April 2027 [Page 701] Internet-Draft Protected AI Execution Finality October 2026 11.17.6. WF-17.6 — Execution-Context Measurement HM-1703 obtains a machine-verifiable measurement or attestation of the relevant VM and workload execution state. The measurement may represent: (a) VM launch identity; (b) firmware or virtualized platform state; (c) approved guest software; (d) model identifier; (e) model checkpoint state; (f) adapter configuration; (g) approved agent workflow; (h) tool-access configuration; (i) execution-policy configuration; (j) protected workload identity; or (k) another required runtime state. The measurement source may comprise an attestation report, authenticated software measurement, protected runtime-state record, verified model artifact digest, or equivalent supported evidence. The measurement need not cover every possible runtime component. It must establish the properties actually required by the corresponding authorization predicate. 11.17.7. WF-17.7 — Execution-Context Measurement Record An illustrative measurement record comprises: measurement_id; vm_identity; workload_identity; Das Expires 19 April 2027 [Page 702] Internet-Draft Protected AI Execution Finality October 2026 vm_measurement; model_identifier; checkpoint_digest; adapter_digest; tool_policy_reference; workflow_reference; execution_policy_reference; policy_epoch; measurement_generation; attestation_nonce; measurement_time; protected_authentication. The requesting workload may submit a reference to the record. PED-1708 verifies the required authenticity and relationship to the actual workload rather than accepting a caller-provided description as authoritative. A report authenticating the VM's launch state does not automatically establish the integrity of every subsequently loaded model, plugin, adapter, tool, or dynamically modified configuration. Where those attributes are mandatory, additional authenticated measurements or protected runtime checks are required. 11.17.8. WF-17.8 — Hardware-Rooted Composite ALF Formation in the implementation described by enforcement point 74, ALF-1704 forms or verifies a Hardware-Rooted Composite Algorithmic Logic Fingerprint. The Composite ALF may identify one or more of: (a) model identifier; (b) checkpoint hash; Das Expires 19 April 2027 [Page 703] Internet-Draft Protected AI Execution Finality October 2026 (c) adapter hash; (d) tokenizer configuration; (e) decoder configuration; (f) system-instruction policy; (g) safety configuration; (h) tool-permission graph; (i) retrieval-source graph; (j) orchestration graph; (k) virtual-machine measurement; (l) hardware attestation report; and (m) policy epoch. The fingerprint combines the selected model, workflow, software, and hardware-related measurements into an authenticated or verifiable authorization condition. Only the attributes required by the corresponding claim and Authority Object are mandatory for a given implementation. An approved base-model identifier does not necessarily establish that the current adapter, tool graph, safety configuration, or system- instruction policy is also approved. 11.17.9. WF-17.9 — Composite ALF Cryptographic Representation In an illustrative implementation: Dalf = Canon_v(Model, Checkpoint, Adapter, Tokenizer, Decoder, Instructions, Safety, Tools, Retrieval, Workflow, VM, Attestation, Epoch) where: Dalf denotes the canonical Composite ALF descriptor; Canon_v denotes deterministic encoding under version v; Model denotes the selected model identity; Das Expires 19 April 2027 [Page 704] Internet-Draft Protected AI Execution Finality October 2026 Checkpoint denotes the required checkpoint measurement; Adapter denotes adapter state; Tokenizer and Decoder denote applicable model processing configurations; Instructions denotes system-instruction policy; Safety denotes the relevant safety configuration; Tools denotes approved tool permissions; Retrieval denotes authorized retrieval sources; Workflow denotes the approved orchestration graph; VM denotes the required virtual-machine measurement; Attestation denotes authenticated hardware-related evidence; and Epoch denotes the protected policy epoch. An illustrative digest is: hALF = H("DAS-HARDWARE-COMPOSITE-ALF-v1" || Encode(Dalf)) where H denotes a cryptographic hash function. The selected serialization must distinguish materially different values under the applicable authorization semantics. The formula is a non-limiting implementation example. The original ALF mechanism does not require this particular encoding, digest label, or fixed field set in every embodiment. 11.17.10. WF-17.10 — Authentication of the Measurement Source PED-1708 determines whether the supplied measurement or attestation originates from an acceptable authority. The verification may involve: (a) attestation signature validation; (b) trusted hardware identity; Das Expires 19 April 2027 [Page 705] Internet-Draft Protected AI Execution Finality October 2026 (c) certificate-chain validation; (d) workload identity association; (e) nonce or challenge freshness; (f) approved virtual-machine measurement; (g) applicable measurement generation; and (h) protected revocation state. An illustrative predicate is: AttestationValid = AuthenticReport AND TrustedMeasurementSource AND CorrectWorkload AND FreshChallenge AND AcceptableState where each term represents a required attestation property. Successful attestation means only that the supported and verified measurement claims are acceptable. It does not independently authorize every consequential operation requested by the attested workload. 11.17.11. WF-17.11 — Runtime-Used Configuration Verification in the implementation described by enforcement point 75, the protected system verifies the model and workflow configuration actually used by the requesting AI workload. The required validation may compare: (a) loaded model identity; (b) checkpoint digest; (c) adapter digest; (d) tool-permission graph; (e) retrieval configuration; (f) orchestration graph; (g) execution-policy state; (h) applicable system-instruction policy; and Das Expires 19 April 2027 [Page 706] Internet-Draft Protected AI Execution Finality October 2026 (i) other mandatory runtime measurements. PED-1708 compares the runtime-used configuration with the corresponding approved measurement or ALF condition. A successful VM attestation does not automatically override a mismatch between the actual runtime-used configuration and the approved authorization state. Where a mandatory configuration measurement fails, the corresponding Candidate Act remains non-effective. 11.17.12. WF-17.12 — Distinguishing Launch Attestation from Runtime Integrity A virtual machine may initially launch under an approved measurement. After launch, its runtime configuration may change. Such changes may include: (a) loading a different model checkpoint; (b) activating another adapter; (c) widening tool permissions; (d) replacing an agent workflow; (e) modifying retrieval sources; (f) changing system instructions; (g) replacing a policy configuration; or (h) activating a new executable plugin. Where the applicable authorization requires measurement of the changed attribute, PED-1708 obtains or verifies current authenticated runtime evidence. An earlier launch attestation alone is insufficient when it does not cover the runtime state required by the Candidate Act's authorization. The implementation may use protected runtime measurements, authenticated configuration records, measured load events, or equivalent mechanisms. Das Expires 19 April 2027 [Page 707] Internet-Draft Protected AI Execution Finality October 2026 The reliability of these measurements depends upon the trust and tamper-resistance properties of the selected measurement source. 11.17.13. WF-17.13 — Candidate Act Generation AE-1702 performs permitted computation within CV-1701. The AI workload produces a proposed consequential operation. Non-limiting operations include: (a) a confidential-data transmission; (b) an API request; (c) a protected credential-use request; (d) a cross-tenant service invocation; (e) a database modification; (f) a storage write; (g) a deployment instruction; or (h) another governed consequential operation. The proposed operation is classified as Candidate Confidential- Workload Act CA-1718. The fact that CA-1718 originates from an attested confidential VM does not independently establish protected execution authority. 11.17.14. WF-17.14 — Interception and Non-Effective Staging IM-1705 receives or intercepts CA-1718 before the governed effect occurs. HQ-1706 retains the operation in a Non-Effective State. An illustrative staging record comprises: candidate_act_id; vm_identity; workload_identity; Das Expires 19 April 2027 [Page 708] Internet-Draft Protected AI Execution Finality October 2026 operation_class; request_reference; target_resource; destination_reference; runtime_measurement_reference; policy_epoch; finality_sink_id; status = NON_EFFECTIVE. The operation remains blocked pending protected authorization. Where the requested operation contains mutable parameters, the interception component may hold an immutable representation or authenticated digest. The AI workload cannot validate one operation and substitute materially different required parameters immediately before effectuation without renewed verification. 11.17.15. WF-17.15 — Candidate Act Descriptor Construction DC-1707 constructs a machine-readable Candidate Act Descriptor representing the proposed consequential operation. The descriptor may include: candidate_act_id; requesting_vm_identity; workload_identity; tenant_identity; operation_class; destination_service_identity; destination_network_context; target_resource; Das Expires 19 April 2027 [Page 709] Internet-Draft Protected AI Execution Finality October 2026 operation_parameters; payload_digest; authorized_purpose; composite_alf_reference; attestation_reference; runtime_measurement_reference; policy_epoch; revocation_epoch; nonce; expiry; authority_object_reference; finality_sink_id. Only the fields required under the specified enforcement profile or Authority Object must participate in authorization. The descriptor is distinct from the underlying Candidate Act and from the attestation or execution capability. 11.17.16. WF-17.16 — Canonical Candidate Act Descriptor In an illustrative cryptographic implementation: Dconf = Canon_v(VM, W, T, ACT, TARGET, PARAM, MEASURE, POLICY, EPOCH, F) where: Dconf denotes the confidential-workload Candidate Act Descriptor; VM denotes the authenticated virtual-machine identity; W denotes the workload identity; T denotes the tenant identity; ACT denotes the requested consequential operation; Das Expires 19 April 2027 [Page 710] Internet-Draft Protected AI Execution Finality October 2026 TARGET denotes the destination or resource; PARAM denotes operation parameters; MEASURE denotes required ALF and attestation context; POLICY denotes protected authority or execution-policy context; EPOCH denotes current required authorization-state versions; and F denotes the designated Finality Sink. An illustrative descriptor digest is: hConf = H("DAS-CONFIDENTIAL-ACT-v1" || Encode(Dconf)) The selected deterministic encoder ensures that materially different operations are distinguishable under the required authorization rules. The protected authorizer and Finality Sink employ compatible descriptor interpretation. The expression is an implementation example rather than a universal requirement for every DAS embodiment. 11.17.17. WF-17.17 — Acquisition of Applicable Authority PED-1708 obtains the Authority Object applicable to CA-1718 from AS-1709 or another authenticated authority source. The Authority Object may define: (a) authorized VM identity; (b) permitted workload identity; (c) tenant scope; (d) authorized model or workflow condition; (e) approved ALF requirement; (f) required hardware or runtime attestation; (g) permitted operation class; (h) authorized execution purpose; Das Expires 19 April 2027 [Page 711] Internet-Draft Protected AI Execution Finality October 2026 (i) allowed destination or resource; (j) credential scope; (k) policy epoch; (l) revocation conditions; (m) nonce or usage restrictions; and (n) designated Finality Sink identity. The PED authenticates the authority information and evaluates its applicable protected state. The AI agent cannot create additional execution authority merely by supplying an attestation report or requesting a broader operation. 11.17.18. WF-17.18 — Protected Runtime and Operation Authorization PED-1708 evaluates the mandatory authorization predicates for CA- 1718. An illustrative conjunctive predicate is: Vconf = Pvm AND Pworkload AND PALF AND Pruntime AND Poperation AND Pscope AND Pstate where: Vconf denotes the protected authorization result; Pvm verifies required virtual-machine identity or attestation; Pworkload verifies requesting workload identity; PALF verifies the Approved Composite ALF Condition; Pruntime verifies the actual required runtime-used configuration; Poperation verifies the proposed consequential operation; Pscope verifies tenant, purpose, destination, resource, and permitted operation scope; and Pstate verifies required policy, revocation, freshness, nonce, and protected authorization state. Das Expires 19 April 2027 [Page 712] Internet-Draft Protected AI Execution Finality October 2026 Where alternative or threshold conditions are authorized, the PED evaluates the corresponding permitted policy combination. Failure of any mandatory predicate prevents release of the required execution capability. 11.17.19. WF-17.19 — Protected Authorization-State Operations Upon successful predicate validation, PED-1708 performs the protected authorization-state operations required for CA-1718. These may include: (a) verifying the current policy epoch; (b) checking protected revocation state; (c) reserving an operation-specific authorization grant; (d) consuming or registering a nonce; (e) advancing a protected usage counter; (f) binding the operation to the current VM generation; (g) registering a validation-evidence commitment; (h) recording a capability-consumption reference; or (i) another protected authorization transition. Where a grant is single-use, the protected mechanism prevents incompatible concurrent operations from independently consuming the same authorization. Where a protected-state operation cannot be completed consistently, the corresponding capability remains unavailable. 11.17.20. WF-17.20 — Protected Validation-Evidence Commitment EV-1711 generates or commits the validation evidence required for CA- 1718. A non-limiting evidence record may contain: receipt_id; candidate_act_id; Das Expires 19 April 2027 [Page 713] Internet-Draft Protected AI Execution Finality October 2026 candidate_act_descriptor_digest; vm_attestation_reference; approved_alf_reference; runtime_measurement_reference; authority_object_reference; tenant_identity; destination_scope; policy_epoch; protected_state_transition; nonce; finality_sink_id; decision; protected_authentication. The evidence may comprise a cryptographically authenticated validation receipt, sealed commitment, LAVR, AVR, or other supported protected representation. Where the corresponding embodiment requires evidence commitment as a prerequisite to capability release, the protected commitment occurs before, or atomically with, availability of the scoped execution capability. An ordinary post-event audit log does not replace the required protected validation-evidence dependency. 11.17.21. WF-17.21 — Protected Confidential-Workload Finality Transaction The PED coordinates the required validation, protected-state handling, evidence commitment, and capability availability. An illustrative transaction is: (Snext, Rconf, Ready) = CommitConfidentialFinality(Dconf, A, M, Scurrent, F) Das Expires 19 April 2027 [Page 714] Internet-Draft Protected AI Execution Finality October 2026 where: Snext denotes the committed protected authorization state; Rconf denotes protected validation evidence; Ready denotes the indication that required release conditions have completed; Dconf denotes the validated Candidate Act Descriptor; A denotes authenticated authority context; M denotes the required runtime measurement and ALF state; Scurrent denotes the prior protected authorization state; and F denotes the designated Finality Sink. A valid execution capability is not made available when a mandatory protected commitment remains incomplete. The implementation may employ transactional protected storage, sealed-state machinery, hardware-backed state, an HSM-controlled procedure, or equivalent protected mechanisms. Where participating components do not share one atomic storage transaction, the capability remains unavailable until the required committed dependencies have been verified. 11.17.22. WF-17.22 — Scoped Non-Bearer Execution Capability Following successful completion of the required protected finality transaction, CR-1712 makes available a scoped, non-bearer execution capability. A non-limiting capability may contain or securely reference: capability_id; candidate_act_descriptor_digest; vm_identity; workload_identity; tenant_identity; Das Expires 19 April 2027 [Page 715] Internet-Draft Protected AI Execution Finality October 2026 authorized_operation; destination_scope; runtime_measurement_reference; approved_alf_reference; policy_epoch; revocation_epoch; nonce; expiry; usage_limit; validation_evidence_digest; finality_sink_id. An illustrative cryptographic implementation is: Cconf = Sign_skPED(Encode(hConf, hR, VM, W, Tenant, Scope, ALF, Epoch, Nonce, Expiry, F)) where: Cconf denotes the execution capability; Sign_skPED denotes authenticated capability generation under PED- controlled key material; hConf denotes the Candidate Act Descriptor digest; hR denotes the validation-evidence commitment digest; VM denotes the VM identity; W denotes the workload identity; Tenant denotes the authorized tenant; Scope denotes permitted operation and destination scope; ALF denotes the required approved logic reference; Das Expires 19 April 2027 [Page 716] Internet-Draft Protected AI Execution Finality October 2026 Epoch denotes the policy epoch; Nonce denotes freshness; Expiry denotes the capability validity limit; and F denotes the authorized Finality Sink. The capability may alternatively comprise a protected capability- table entry, authenticated execution permit, sealed handle, or hardware-controlled enablement condition. A signature alone does not establish non-bearer operation unless the required context, scope, state, and Finality Sink conditions are actually enforced. 11.17.23. WF-17.23 — Privacy-Preserving Protected Validation Evidence in the implementation described by enforcement point 76, the protected validation evidence may comprise a cryptographically authenticated receipt or zero-knowledge validation receipt. The evidence establishes satisfaction of required authority or runtime-integrity predicates while restricting disclosure of designated protected information. Such information may include: (a) confidential internal policy; (b) private user attributes; (c) proprietary model configuration; (d) approved workflow parameters; (e) protected attestation details; (f) private enterprise authorization rules; or (g) another protected validation input. Where a ZK-LAVR is used, the implementation employs an actual proof construction or other expressly supported mechanism establishing the specified proof properties. Das Expires 19 April 2027 [Page 717] Internet-Draft Protected AI Execution Finality October 2026 The corresponding verifier checks the required proof statement, cryptographic authenticity, Candidate Act association, and capability context. A signed validation receipt may establish authenticated compliance evidence without providing formal zero-knowledge confidentiality. These guarantees are distinguished according to the selected cryptographic construction. 11.17.24. WF-17.24 — Confidential Validation and Finality Sink Independence The protected authorization mechanism may validate private information without requiring that information to be disclosed to the Finality Sink. For example, PED-1708 may verify a confidential enterprise policy and generate protected evidence that the operation satisfied the required authorization predicates. FS-1713 may verify: (a) the evidence authentication; (b) the required cryptographic proof where applicable; (c) the Candidate Act Descriptor commitment; (d) the scoped execution capability; (e) required current protected authorization state; and (f) the actual operation presented for effectuation. The Finality Sink need not receive the full private policy if the authenticated evidence and protected authorization mechanism provide the required verifiable relationship. However, the Finality Sink must still verify all fields and conditions that the applicable embodiment requires it to enforce. The privacy-preserving evidence does not replace mandatory capability verification. Das Expires 19 April 2027 [Page 718] Internet-Draft Protected AI Execution Finality October 2026 11.17.25. WF-17.25 — Independent Finality Sink Verification FS-1713 receives or reconstructs the actual consequential operation and obtains the corresponding scoped capability. The Finality Sink verifies: (a) capability authenticity; (b) actual Candidate Act Descriptor correspondence; (c) required VM identity; (d) workload identity; (e) tenant identity; (f) authorized operation class; (g) destination service or resource; (h) applicable runtime authorization state; (i) required policy epoch; (j) revocation state; (k) nonce and expiry; (l) protected validation-evidence commitment; (m) capability usage or consumption state; and (n) designated Finality Sink identity. The operation proceeds only when the mandatory verification conditions succeed. A valid confidential VM attestation is not accepted as a substitute for the required Candidate Act-specific execution capability. 11.17.26. WF-17.26 — Finality Sink Verification Predicate An illustrative predicate is: PermitConf = Auth(C) AND Match(C,Dactual) AND RuntimeValid(C,M) AND TenantValid(C,T) AND StateValid(C,S) AND SinkValid(C,F) Das Expires 19 April 2027 [Page 719] Internet-Draft Protected AI Execution Finality October 2026 where: PermitConf denotes permission to effectuate the Candidate Act; C denotes the scoped non-bearer execution capability; Dactual denotes the actual effectuation descriptor; M denotes the required runtime measurement or approved ALF state; T denotes the actual tenant and destination context; S denotes the applicable protected authorization state; and F denotes the designated Finality Sink. Auth verifies capability authentication. Match verifies exact correspondence or permitted bounded-scope matching. RuntimeValid verifies the mandatory measured execution-context conditions. TenantValid verifies required tenant and destination bindings. StateValid verifies policy, revocation, freshness, validation evidence, and usage conditions. SinkValid verifies that the capability authorizes the selected Finality Sink. The Candidate Act is permitted only when all mandatory predicates succeed. 11.17.27. WF-17.27 — Tenant and Destination Scope Binding in the implementation described by enforcement point 77, the Candidate Act Descriptor identifies: (a) tenant context; (b) cloud-workload identity; (c) requesting virtual-machine identity; (d) destination service identity; Das Expires 19 April 2027 [Page 720] Internet-Draft Protected AI Execution Finality October 2026 (e) destination network context; and (f) applicable policy epoch. The corresponding execution capability is associated with the authorized tenant and destination conditions. An illustrative tenant-context record comprises: tenant_id; workload_id; vm_id; destination_service_id; destination_network_context; authorized_resource_scope; policy_epoch; finality_sink_id. The Finality Sink compares the actual operation against the required tenant and destination scope. A capability issued for one tenant does not authorize an operation for another tenant when tenant binding is mandatory. Likewise, a capability for an approved destination service does not authorize an unauthorized destination or network context. 11.17.28. WF-17.28 — Cross-Tenant Authority Isolation In a multi-tenant cloud implementation, several AI workloads may execute on shared physical infrastructure. Each workload may have its own: (a) virtual-machine identity; (b) tenant identity; (c) approved ALF condition; (d) authority scope; Das Expires 19 April 2027 [Page 721] Internet-Draft Protected AI Execution Finality October 2026 (e) policy epoch; (f) protected capability state; and (g) permitted destinations. The protected enforcement mechanism ensures that a capability issued for one tenant cannot authorize effectuation for another tenant outside its permitted scope. Tenant authorization is evaluated against authenticated tenant and workload context, not merely against a tenant identifier supplied by the requesting application. Physical coexistence on the same host does not establish shared execution authority. A request attempting to substitute another tenant's destination, credential scope, or resource identity fails the corresponding mandatory authorization predicate. 11.17.29. WF-17.29 — Virtual-Machine Snapshot Rollback Threat in the implementation described by enforcement point 78, the architecture addresses restoration of an earlier virtual-machine snapshot. A snapshot may contain: (a) agent process memory; (b) previously issued capability references; (c) application authorization data; (d) locally stored nonces; (e) cached policy information; (f) pending operations; (g) runtime configuration; and (h) prior application state. Restoring the snapshot may return the guest workload to an earlier apparent state. Das Expires 19 April 2027 [Page 722] Internet-Draft Protected AI Execution Finality October 2026 However, the restoration must not recover execution authority previously consumed, revoked, expired, or otherwise invalidated under mandatory protected conditions. The system therefore separates required authoritative capability- consumption, nonce, or hardware-freshness state from the rollback- accessible portion of the AI workload. 11.17.30. WF-17.30 — Protected Rollback-Resistant State RS-1715 maintains the protected state required to prevent unauthorized restoration of earlier authority. A representative protected state record comprises: workload_id; vm_identity; tenant_id; authorization_epoch; capability_id; candidate_act_digest; capability_status; remaining_uses; last_consumed_nonce; protected_state_version; hardware_freshness_reference; revocation_epoch; last_committed_validation_reference. The authoritative state may reside within a protected external service, HSM-controlled state store, secure monotonic counter, hardware-backed protected controller, or another mechanism outside the rollback-accessible snapshot domain. Das Expires 19 April 2027 [Page 723] Internet-Draft Protected AI Execution Finality October 2026 The selected implementation must ensure that restoring guest memory does not roll back the authoritative state required for capability verification. Merely placing the state in an ordinary file outside the VM is insufficient if the relevant attacker can restore that file together with the guest snapshot. 11.17.31. WF-17.31 — Capability Consumption Before and During Effectuation Where the capability is single-use or otherwise usage-bounded, the system coordinates its required consumption with the protected Finality Sink operation. An illustrative capability-state progression is: AVAILABLE → RESERVED → EFFECTUATION_ATTEMPTED → CONSUMED. Additional states may include: DENIED; REVOKED; EXPIRED; INDETERMINATE. Before effectuation, the Finality Sink verifies that the capability remains within the permitted usage state. The protected mechanism prevents an incompatible second operation from independently consuming the same restricted grant. Where the external effect cannot be atomically completed together with local capability consumption, the system preserves the distinction between reservation, attempted effectuation, and confirmed completion. A protected capability reservation does not itself prove that the remote consequential operation completed. 11.17.32. WF-17.32 — Virtual-Machine Snapshot Restoration When CV-1701 is restored from an earlier snapshot, RC-1717 performs the required protected recovery checks. Das Expires 19 April 2027 [Page 724] Internet-Draft Protected AI Execution Finality October 2026 The procedure may comprise: (a) identifying the restored VM; (b) authenticating the workload identity; (c) obtaining a current runtime measurement; (d) verifying the required approved ALF condition; (e) consulting current protected policy state; (f) verifying revocation state; (g) obtaining the authoritative capability-consumption state; (h) checking nonce or hardware-freshness continuity; (i) identifying pending or previously attempted Candidate Acts; and (j) requiring renewed authorization where applicable. The restored workload cannot independently treat a locally restored capability as valid. The applicable Finality Sink verifies the current protected state rather than trusting the snapshot's prior view of authorization. 11.17.33. WF-17.33 — Snapshot-Replay Rejection Consider a capability authorizing one protected database modification. The capability is consumed during a successful effectuation attempt. The AI workload is subsequently restored to a snapshot created before consumption. The restored VM contains an earlier copy of the capability and may locally represent it as unused. However, RS-1715 retains the authoritative consumed state outside the rollback-accessible guest snapshot. When the workload attempts to reuse the capability, FS-1713 checks the current protected consumption record. The capability is already consumed. Das Expires 19 April 2027 [Page 725] Internet-Draft Protected AI Execution Finality October 2026 The repeated operation is refused. The restored guest's local state does not override the protected authority state. 11.17.34. WF-17.34 — VM Migration and Workload Replacement The architecture may also govern migration of an AI workload between physical hosts or virtualized execution environments. Where migration changes a mandatory measured execution condition, workload identity, protected platform generation, or Finality Sink relationship, the receiving environment must satisfy the applicable authority requirements before further governed effectuation. The recovery procedure may verify: (a) destination host or VM identity; (b) applicable attestation; (c) current policy epoch; (d) protected revocation state; (e) workload authorization scope; (f) nonce continuity; (g) capability-consumption state; and (h) designated Finality Sink. A migrated workload does not automatically acquire renewed execution authority because the migration controller reports successful restoration. Where the existing capability remains valid under its expressly permitted scope and current protected conditions, it may be accepted according to those conditions. Where a mandatory binding changes incompatibly, renewed authorization is required. 11.17.35. WF-17.35 — Revocation and Policy-Epoch Changes The protected authority may revoke or modify permissions applicable to the confidential workload. Das Expires 19 April 2027 [Page 726] Internet-Draft Protected AI Execution Finality October 2026 Such events may include: (a) model approval revocation; (b) tenant authorization withdrawal; (c) credential-scope change; (d) invalid runtime attestation; (e) updated execution policy; (f) revoked destination service; (g) compromised workload identity; (h) modified approved ALF; or (i) superseded protected policy epoch. PED-1708 updates or consults the required protected authorization state. Where current non-revocation or epoch verification is mandatory, an affected capability associated with incompatible earlier state is rejected. A VM snapshot does not restore authority invalidated by subsequent protected revocation. The Finality Sink enforces the required current-state conditions before the governed operation. 11.17.36. WF-17.36 — Time-of-Check and Time-of-Use Protection The architecture prevents unauthorized substitution between protected validation and actual effectuation. Potential substitutions include: (a) changing the destination service; (b) replacing the tenant context; (c) modifying the operation payload; (d) changing credential scope; Das Expires 19 April 2027 [Page 727] Internet-Draft Protected AI Execution Finality October 2026 (e) substituting a runtime model configuration; (f) changing an authorized tool workflow; (g) replacing the applicable VM identity; (h) using a capability under a different policy epoch; (i) restoring an earlier nonce; or (j) reusing consumed authorization after snapshot rollback. The Finality Sink reconstructs or verifies the effectuation-relevant actual operation. Where exact descriptor correspondence is required, a materially changed mandatory parameter causes verification failure. Where bounded variations are expressly authorized, the applicable bounded-scope predicates are enforced. An earlier attestation or allow decision does not eliminate this required operation-specific verification. 11.17.37. WF-17.37 — Illustrative Confidential AI-Agent API Operation In one concrete implementation, an AI agent executes inside a confidential virtual machine and proposes updating an enterprise record through an external API. The confidential VM provides an authenticated workload measurement. The agent prepares an HTTPS request. The request is intercepted by IM-1705 before the governed network effect. HQ-1706 maintains the operation in a Non-Effective State. HM-1703 obtains the required virtual-machine and runtime measurements. ALF-1704 verifies the applicable approved model and workflow configuration. Das Expires 19 April 2027 [Page 728] Internet-Draft Protected AI Execution Finality October 2026 DC-1707 constructs a Candidate Act Descriptor containing the VM identity, workload identity, tenant, destination service, operation class, resource identifier, request-body digest, policy epoch, and designated Finality Sink. PED-1708 authenticates the Authority Object. The PED validates the measured runtime context, approved ALF condition, permitted tenant, destination, operation, purpose, policy, revocation, and freshness conditions. Following successful validation, the protected system performs the required state transition and commits the corresponding validation evidence. CR-1712 releases a scoped non-bearer execution capability. The network Finality Sink reconstructs or verifies the actual request. The Finality Sink checks capability authenticity, operation correspondence, tenant scope, destination identity, required protected state, freshness, and validation-evidence commitment. If the checks succeed, the network interface permits the authorized request. If the destination changes or the current runtime configuration fails a mandatory condition, the operation is refused despite successful initial confidential VM attestation. 11.17.38. WF-17.38 — Illustrative Composite ALF Mismatch An AI workload launches within an approved confidential VM. The hardware attestation report verifies the expected virtual-machine measurement. The application then loads a model adapter whose digest differs from the adapter specified by the approved Composite ALF. The agent generates a consequential API operation. PED-1708 obtains or verifies the actual runtime-used adapter measurement. The adapter fails the mandatory approved ALF condition. Das Expires 19 April 2027 [Page 729] Internet-Draft Protected AI Execution Finality October 2026 The PED withholds the required execution capability. The Finality Sink refuses the consequential operation. The initial VM attestation remains valid for the properties it actually measured, but does not override the failed runtime configuration condition. 11.17.39. WF-17.39 — Illustrative Cross-Tenant Destination Substitution An AI workload belonging to Tenant A obtains valid operation-specific authority to invoke a service belonging to Tenant A. The corresponding capability is bound to the tenant, workload, destination service, operation scope, and Finality Sink. The workload attempts to reuse the capability for a resource associated with Tenant B. The Finality Sink identifies the actual receiving tenant or resource context through its authenticated effectuation interface. The required tenant binding does not match. The operation is refused. Possession of a valid confidential VM attestation does not authorize access outside the permitted tenant scope. 11.17.40. WF-17.40 — Illustrative Snapshot-Rollback Attack A confidential VM receives authorization to perform one protected storage operation. The PED issues an operation-specific capability under a valid protected grant. The storage Finality Sink verifies and consumes the capability. The VM is later restored from a previously captured snapshot containing an earlier capability reference. The workload attempts to repeat the storage operation. The Finality Sink consults the authoritative capability-consumption state maintained outside the rollback-accessible VM snapshot. The capability is already consumed. Das Expires 19 April 2027 [Page 730] Internet-Draft Protected AI Execution Finality October 2026 The attempted replay is denied. The restored snapshot does not regenerate the previously consumed execution authority. 11.17.41. WF-17.41 — Illustrative Privacy-Preserving Validation An enterprise AI workload must satisfy a confidential internal authorization policy before transferring protected data to an approved service. The Protected Enforcement Domain validates the required confidential predicates. The policy details need not be supplied directly to the external- facing Finality Sink when the applicable proof or authenticated validation record permits verification without their disclosure. The PED commits the protected validation evidence and releases the scoped execution capability. The Finality Sink verifies the evidence and capability against the actual operation, protected authorization scope, destination, and required current state. If an actual zero-knowledge construction is employed, the verifier may validate predicate satisfaction without learning the specified protected witness information. If ordinary authenticated evidence is used, the system claims only the confidentiality properties actually provided by that evidence mechanism. The receiving Finality Sink does not treat proof possession as unrestricted authority for unrelated operations. 11.17.42. WF-17.42 — Failure, Crash, and Recovery Handling The workflow distinguishes failures occurring at different authorization and effectuation stages. Failure before measurement verification: The affected operation remains non-effective when required runtime measurement cannot be authenticated. Failure after valid attestation but before operation authorization: No valid execution capability becomes available without successful Candidate Act-specific validation. Das Expires 19 April 2027 [Page 731] Internet-Draft Protected AI Execution Finality October 2026 Failure before required evidence commitment: The capability remains unavailable. Failure after protected commitment but before capability delivery: The protected system reconciles committed authorization state before recovery. Failure after capability availability but before effectuation: The Finality Sink verifies current policy, revocation, nonce, scope, and usage state. Failure after possible external effectuation: The protected outcome store distinguishes confirmed completion, known failure, and indeterminate completion. VM restart: The restored workload must satisfy any mandatory fresh attestation and state-continuity requirements. Snapshot restoration: Previously consumed or revoked authority is not restored by guest-state rollback. An indeterminate external effect is not automatically repeated where an unauthorized duplicate consequence could result. Where supported, authenticated operation identifiers, downstream idempotency records, transaction-status queries, or protected completion receipts may support reconciliation. The architecture does not assert unconditional exactly-once completion across arbitrary remote services. 11.17.43. WF-17.43 — Alternative Technical Implementations The protected confidential-workload finality architecture may be implemented through several technical arrangements. Confidential-VM implementation: An AI workload runs within a hardware-protected confidential virtual machine while operation- specific authority is established through a suitably protected PED and Finality Sink. Hypervisor-mediated implementation: A hypervisor-controlled interface intercepts governed operations and enforces mandatory capability- dependent effectuation. Protected host-service implementation: A host-side protected authority service validates measured guest context and releases bounded execution capabilities to a controlled host interface. Das Expires 19 April 2027 [Page 732] Internet-Draft Protected AI Execution Finality October 2026 Secure-enclave implementation: Required authorization predicates, protected state, or cryptographic operations are performed within a secure enclave or another trusted execution environment. Service-mesh implementation: A cloud proxy or gateway verifies the operation-specific capability before permitting protected service communication. Credential-broker implementation: Protected credential application depends upon successful capability verification for the concrete operation. Storage-controller implementation: A storage Finality Sink verifies the applicable capability before persistent mutation. Hardware-assisted implementation: A SmartNIC, DPU, protected network controller, or another hardware-controlled interface enforces the required effectuation condition. Single-node implementation: Confidential computation, protected authorization, and local Finality Sink verification operate within one node while retaining the required functional distinctions. Distributed implementation: The AI workload, protected authorization service, and effectuation Finality Sink operate on separately authenticated computing nodes. Rollback-resistant implementation: Authoritative nonce, consumption, or hardware-freshness state is maintained outside the guest snapshot domain. Different implementations may provide different guarantees against privileged host compromise, hypervisor compromise, firmware attacks, physical attacks, rollback, or side-channel leakage. The specified properties must be demonstrated within the specified implementation's threat model. 11.17.44. WF-17.44 — Failure and Fail-Closed Conditions The protected Finality Sink refuses the governed operation when a mandatory condition is absent, invalid, expired, revoked, inconsistent, replayed, or unverifiable. Non-limiting denial conditions include: (a) missing runtime measurement; Das Expires 19 April 2027 [Page 733] Internet-Draft Protected AI Execution Finality October 2026 (b) invalid VM attestation; (c) unauthorized VM identity; (d) workload identity mismatch; (e) unapproved model identifier; (f) checkpoint hash mismatch; (g) adapter hash mismatch; (h) invalid tokenizer or decoder configuration where required; (i) unauthorized system-instruction policy; (j) safety-configuration mismatch; (k) tool-permission graph mismatch; (l) retrieval-source graph mismatch; (m) orchestration graph mismatch; (n) invalid Composite ALF condition; (o) failed runtime-used configuration verification; (p) unauthorized tenant; (q) destination service mismatch; (r) invalid destination network context; (s) unauthorized operation class; (t) failed Authority Object validation; (u) stale policy epoch; (v) invalid revocation state; (w) failed protected-state transition; (x) failed required validation-evidence commitment; (y) invalid privacy-preserving proof where mandatory; Das Expires 19 April 2027 [Page 734] Internet-Draft Protected AI Execution Finality October 2026 (z) missing scoped execution capability; (aa) invalid capability authentication; (ab) expired nonce; (ac) consumed or replayed capability; (ad) incompatible snapshot-restored state; (ae) hardware-freshness mismatch; (af) Finality Sink identity mismatch; or (ag) failure of required non-bypassable enforcement. The affected Candidate Act remains non-effective, denied, quarantined, or subject to an authorized recovery procedure. Failure of confidential-computing attestation does not authorize fallback to unrestricted ordinary VM execution for the same governed act. 11.17.45. WF-17.45 — PHOSITA Verification and Negative Tests A person having ordinary skill in confidential computing, virtual- machine security, hardware attestation, AI-model infrastructure, protected authorization, cloud security, cryptography, or distributed systems may test the architecture through the following cases. Test 1 — Authorized confidential workload: Run an approved AI workload with valid measured context and operation-specific authorization. The Finality Sink permits the scoped operation. Test 2 — Attestation without capability: Provide valid confidential VM attestation but no operation-specific capability. Effectuation is refused. Test 3 — Invalid VM measurement: Present a VM whose mandatory measurement differs from the approved condition. Protected validation fails. Test 4 — Wrong workload identity: Attempt an operation through a different workload. Required identity verification fails. Test 5 — Checkpoint substitution: Replace a mandatory approved checkpoint with another checkpoint. The Composite ALF condition fails. Das Expires 19 April 2027 [Page 735] Internet-Draft Protected AI Execution Finality October 2026 Test 6 — Adapter substitution: Change the runtime adapter digest after authorization. The relevant measurement correspondence fails. Test 7 — Tool-policy widening: Expand the agent's permitted tools outside the approved policy. Required ALF validation fails. Test 8 — Retrieval graph modification: Replace an approved retrieval- source graph. Required logic validation fails. Test 9 — Orchestration graph mismatch: Modify a mandatory workflow dependency. Protected authorization refuses the affected Candidate Act. Test 10 — Safety-policy change: Substitute an unauthorized safety configuration. The required approved configuration predicate fails. Test 11 — Runtime change after launch attestation: Successfully attest VM launch, then alter a required runtime-used configuration. The changed context is rejected. Test 12 — Missing capability: Attempt a consequential operation without its scoped execution capability. The Finality Sink refuses it. Test 13 — Operation substitution: Authorize one API operation and present materially different required parameters at the Finality Sink. Verification fails. Test 14 — Tenant substitution: Present a Tenant A capability for a Tenant B resource. The tenant-binding check fails. Test 15 — Destination substitution: Change the actual destination service or network context. Required destination verification fails. Test 16 — Policy revocation: Revoke a mandatory authority condition. Subsequent affected effectuation is denied. Test 17 — Expired capability: Present the capability outside its validity interval. Verification fails. Test 18 — Capability replay: Reuse a consumed single-use capability. Protected usage verification refuses the operation. Test 19 — Concurrent consumption: Submit competing operations against one restricted grant. The protected state mechanism prevents unauthorized double consumption. Das Expires 19 April 2027 [Page 736] Internet-Draft Protected AI Execution Finality October 2026 Test 20 — Snapshot rollback: Restore a VM snapshot containing an earlier unused-looking capability. The authoritative consumed state prevents replay. Test 21 — Nonce rollback: Restore a guest snapshot containing an earlier nonce. Current protected nonce state rejects unauthorized reuse. Test 22 — Protected-state rollback attempt: Attempt to roll back the authoritative capability store. Verify that the selected protected implementation detects or prevents the attack within its stated threat model. Test 23 — Hardware freshness: Bind a capability to a protected hardware generation, change that generation, and verify rejection when the earlier state is incompatible. Test 24 — Privacy-preserving receipt: Validate the required authenticated compliance evidence without exposing the protected predicate inputs specified by the selected mechanism. Test 25 — Invalid ZK proof: Present an invalid required zero- knowledge proof. Verification fails. Test 26 — Valid proof, wrong operation: Present valid evidence associated with another Candidate Act. The Finality Sink rejects the mismatched capability or descriptor. Test 27 — VM migration: Move a workload to another execution environment and verify that mandatory attestation, policy, and protected-state continuity conditions remain enforced. Test 28 — Restart after revocation: Restart or restore the workload after revocation. The prior authorization remains invalid. Test 29 — Credential access separation: Verify that confidentiality of the VM does not by itself permit unrestricted use of protected connector credentials. Test 30 — Network bypass: Attempt the same governed effect through an alternative network path. The operation remains mediated or blocked. Test 31 — Single-node implementation: Integrate protected authority and Finality Sink functions within one node and verify that the required authorization and actual-operation checks remain enforceable. Das Expires 19 April 2027 [Page 737] Internet-Draft Protected AI Execution Finality October 2026 Test 32 — Distributed implementation: Issue a capability through a protected authority service and verify it at a separate cloud Finality Sink. Incompatible operation, state, or identity bindings are rejected. Test 33 — Crash before evidence commitment: Interrupt the required protected finality transaction. No valid corresponding capability becomes available. Test 34 — Crash after possible remote effect: Interrupt communication after a downstream operation may have completed. Recovery preserves accurate confirmed or indeterminate outcome state. Test 35 — Confidentiality versus authority: Demonstrate that an attested confidential workload may compute successfully while an unauthorized Candidate Act remains blocked. The tests may employ confidential-VM development environments, virtualized attestation test fixtures, controlled AI model configurations, authenticated authority stores, protected capability services, mock Finality Sinks, snapshot-and-restore facilities, rollback fault injection, and simulated cloud destination services. The observed security guarantees depend upon the implementation's actual trust roots, enforcement coverage, and failure assumptions. 11.17.46. WF-17.46 — Claim-Specific Technical Support Enforcement Point 73 — Protected Confidential-VM AI-Execution Finality The workflow describes: (a) CV-1701 providing a confidential or isolated VM execution environment; (b) AE-1702 generating consequential operations; (c) HM-1703 producing machine-verifiable execution-context measurement or attestation; (d) IM-1705 intercepting a Candidate Act before a governed effectuation boundary; (e) HQ-1706 maintaining the Candidate Act in a Non-Effective State; (f) PED-1708 validating the execution context against an Approved ALF Condition or protected runtime-authority condition; Das Expires 19 April 2027 [Page 738] Internet-Draft Protected AI Execution Finality October 2026 (g) protected validation of the Candidate Act against authority, purpose, scope, policy, revocation, and freshness requirements; (h) EV-1711 generating or committing the applicable validation evidence; (i) CR-1712 releasing the scoped, non-bearer execution capability; and (j) FS-1713 independently verifying the capability before effectuation. The workflow expressly distinguishes successful confidential-VM attestation from Candidate Act-specific execution authority. Enforcement Point 74 — Hardware-Rooted Composite ALF WF-17.8 through WF-17.10 describe the Composite ALF incorporating the specified model, checkpoint, adapter, tokenizer, decoder, instruction policy, safety configuration, tool graph, retrieval graph, orchestration graph, VM measurement, attestation, and policy-epoch attributes. Enforcement Point 75 — Measured Workload Configuration WF-17.11 and WF-17.12 describe comparison of actual runtime-used model, workflow, tool, and policy configuration against approved measurements, including denial despite successful initial VM authentication. Enforcement Point 76 — Privacy-Preserving Cryptographic Validation WF-17.23 and WF-17.24 describe authenticated validation receipts or applicable zero-knowledge evidence enabling verification of protected authority and runtime-integrity predicates without requiring disclosure of specified confidential internal information. Enforcement Point 77 — Cloud Tenant and Destination Scope WF-17.27 and WF-17.28 describe binding the Candidate Act Descriptor and capability to tenant, workload, VM, destination service, destination network context, and policy epoch, preventing unauthorized cross-tenant or destination reuse. Enforcement Point 78 — Virtual-Machine Snapshot Replay Resistance Das Expires 19 April 2027 [Page 739] Internet-Draft Protected AI Execution Finality October 2026 WF-17.29 through WF-17.33 describe maintaining authoritative protected capability-consumption, nonce, or hardware-freshness state outside the workload's rollback-accessible snapshot domain and rejecting previously consumed, revoked, or invalidated execution authority after restoration. 11.17.47. WF-17.47 — Technical Effect The disclosed workflow establishes a protected dependency between: (a) execution of an AI workload inside a confidential or isolated virtual machine; (b) machine-verifiable measurement of the actual required execution context; (c) verification of an Approved Algorithmic Logic Fingerprint Condition; (d) generation of a consequential Candidate Act; (e) interception and maintenance in a Non-Effective State; (f) construction of an effectuation-relevant Candidate Act Descriptor; (g) protected validation of authority, purpose, runtime configuration, tenant, destination, policy, revocation, and freshness; (h) required protected-state handling; (i) protected validation-evidence commitment; (j) scoped, non-bearer execution-capability availability; (k) independent Finality Sink verification against the actual operation; (l) controlled effectuation or fail-closed withholding; and (m) preservation of protected authorization and capability- consumption state across snapshot rollback or recovery. The confidential-computing environment protects specified computation properties but does not independently supply unlimited authority over effect-capable cloud, host, network, service, credential, or storage interfaces. Das Expires 19 April 2027 [Page 740] Internet-Draft Protected AI Execution Finality October 2026 The Composite ALF embodiment binds authorization to the measured model and workflow configuration actually required for the operation. The privacy-preserving variant supports validation without unnecessarily exposing designated protected information, according to the actual cryptographic mechanism. The tenant-bound capability variant prevents cross-tenant or destination substitution outside the authorized scope. The snapshot-resistance variant prevents restoration of guest state from reviving execution authority already consumed, revoked, or invalidated in the authoritative protected state. Computation is not authority to act. Confidential execution is not authorization for an external operation. Hardware attestation is not a substitute for Candidate Act-specific authority. A valid capability for one tenant is not authority for another tenant. Restoring a VM snapshot must not restore previously consumed execution authority. 11.18. WF-18 — Confidential Governance Virtual Machine, Hardware-Rooted Attestation, Protected Governance-Key Isolation, Authenticated Fabric Capability Delivery, and Hardware-Enforced SmartNIC Finality 11.18.1. WF-18.1 — Technical Purpose This embodiment describes a hardware-assisted system for governing externally effective operations and transfers generated within artificial-intelligence compute infrastructure. The system comprises an AI compute node, a governance compute node operating within a confidential virtual-machine environment, a hardware-rooted attestation mechanism, a Protected Enforcement Domain (PED), an operation-specific authorization component, an authenticated fabric-management communication path, and a hardware- enforced Finality Sink associated with a SmartNIC, data processing unit, rack-boundary controller, accelerator-egress interface, or protected network-forwarding component. Das Expires 19 April 2027 [Page 741] Internet-Draft Protected AI Execution Finality October 2026 The governance compute node operates under hardware-supported memory confidentiality or integrity protection. Its authenticated attestation record identifies the governance workload measurement and protected execution configuration. The PED verifies the record against an approved hardware trust root, registered governance identity, and applicable protected policy state. An AI compute node may generate or prepare an external operation, but does not thereby acquire permission to transmit or effectuate the operation. The proposed operation is classified as a Candidate Act and remains non-effective at the governed boundary until the PED validates the required act-specific authority and makes available a scoped execution capability. The scoped capability is delivered through an authenticated fabric- management communication path toward the effectuation controller. The hardware-enforced Finality Sink verifies the capability against: (a) the Candidate Act; (b) the authorized effectuation boundary; (c) the registered attestation state of the issuing governance component; and (d) other mandatory authorization, freshness, scope, and protected- state conditions. When a required attestation state becomes invalid or capability verification fails, the hardware-enforced Finality Sink prevents the proposed operation from crossing the governed external-transmission boundary. The architecture distinguishes confidential governance execution, the authority to issue capabilities, transport of capability material, and independent hardware enforcement of a specific external effect. 11.18.2. WF-18.2 — Participating Technical Components In one non-limiting embodiment, the system comprises the following components. Das Expires 19 April 2027 [Page 742] Internet-Draft Protected AI Execution Finality October 2026 AI-1801 — Artificial-Intelligence Compute Node An AI agent, model-serving node, GPU server, accelerator workload, orchestration service, or other computational environment configured to produce a proposed external operation or transfer. GC-1802 — Confidential Governance Compute Node A governance compute node executing within a confidential virtual- machine environment and providing hardware-supported memory confidentiality or integrity protection. HA-1803 — Hardware-Rooted Attestation Component A component configured to generate an authenticated record identifying the governance workload measurement and protected execution configuration. AT-1804 — Hardware Finality Gate Attestation Object An authenticated representation of the governance-node state, optionally including firmware digest, confidential-VM policy version, launch measurement, host-data field, hardware signing evidence, and protected device identity. TR-1805 — Registered Hardware Trust-Root Store A protected or authenticated trust store containing approved hardware-vendor certificate authorities, registered public keys, governance identities, approved measurements, and applicable trust restrictions. PED-1806 — Protected Enforcement Domain A protected authorization component configured to verify governance- node attestation and perform Candidate Act-specific authorization. AS-1807 — Protected Governance Authority Store A component maintaining registered governance identities, Authority Objects, authorized effectuation boundaries, policy epochs, revocation state, and applicable issuance conditions. KS-1808 — Protected Governance-Key Component A protected mechanism maintaining cryptographic governance or capability-issuance key material outside the unrestricted access of ordinary AI compute processes. Das Expires 19 April 2027 [Page 743] Internet-Draft Protected AI Execution Finality October 2026 IM-1809 — Candidate Act Interception Component An enforcement-controlled interface configured to identify and hold a proposed external operation before a governed effectuation boundary. HQ-1810 — Non-Effective Candidate Act Holding Mechanism A controlled queue, transfer buffer, inactive forwarding entry, pending request, blocked DMA descriptor, or equivalent mechanism retaining the Candidate Act pending authorization. DC-1811 — Candidate Act Descriptor Component A component configured to construct or verify the machine-readable representation of the proposed external operation. PS-1812 — Protected Authorization-State Store A component maintaining nonce state, policy epochs, revocation state, capability usage, attestation generation, and required protected commitments. EV-1813 — Validation-Evidence Component A mechanism configured to generate or commit a protected validation record or authenticated authorization commitment where required by the selected DAS finality embodiment. CR-1814 — Operation-Scoped Capability Component A protected mechanism configured to generate, register, derive, release, or activate the execution capability required for the Candidate Act. FM-1815 — Authenticated Fabric-Management Communication Path A protected or authenticated interface configured to convey the execution capability or corresponding protected capability state from the governance node or protected authority component toward the hardware effectuation controller. HC-1816 — Hardware Effectuation Controller A SmartNIC, DPU, rack-boundary network controller, accelerator-egress controller, or other hardware-associated network-enforcement component. FS-1817 — Hardware-Enforced Finality Sink Das Expires 19 April 2027 [Page 744] Internet-Draft Protected AI Execution Finality October 2026 The actual governed network-transmission, forwarding, accelerator- egress, or other effectuation interface configured to verify capability authority before enabling the corresponding external operation. HF-1818 — Protected Hardware-Freshness Component A mechanism maintaining trusted counters, secure boot epochs, protected clock references, device sequences, hardware-attested nonces, or equivalent freshness state. RV-1819 — Attestation Revocation and Revalidation Component A mechanism configured to invalidate unacceptable governance-node attestation state and withhold affected capability issuance or effectuation. OS-1820 — Protected Effectuation-Outcome Store A mechanism maintaining pending, reserved, denied, transmitted, revoked, indeterminate, and other relevant operation-outcome states. RC-1821 — Recovery and State-Reconciliation Component A component configured to restore valid protected governance operation after an authorized attestation, infrastructure, or hardware recovery procedure. The components may operate on separate physical devices or be integrated within one protected server or network-controller arrangement. The architectural roles of governance authority, capability delivery, and hardware effectuation verification remain distinguishable. 11.18.3. WF-18.3 — Establishment of the AI Compute-to-Governance Trust Boundary AI-1801 is configured as a computational environment rather than the exclusive source of protected execution authority. It may perform inference, generate tool instructions, prepare network packets, produce accelerator outputs, or construct consequential requests. However, it does not independently control the key material, protected authorization state, or registered governance attestation required for effectuation. Das Expires 19 April 2027 [Page 745] Internet-Draft Protected AI Execution Finality October 2026 An authenticated interface connects the AI compute environment to the protected governance architecture. The interface may accept proposed Candidate Act information and return an authorization status or protected capability reference. It does not expose unrestricted governance private keys or permit the AI workload to write protected authorization records. A compromised or untrusted ordinary AI process therefore cannot create a valid execution capability merely by modifying the request it sends to the governance node. The exact protection depends upon the isolation provided by the selected confidential-computing and key-management implementation. 11.18.4. WF-18.4 — Establishment of the Confidential Governance VM GC-1802 operates within a confidential virtual-machine environment. The environment may provide: (a) hardware-supported guest-memory confidentiality; (b) protected execution-state integrity; (c) measured launch; (d) isolated governance software; (e) authenticated platform attestation; (f) controlled device or host access; (g) protected governance configuration; and (h) access to cryptographic key operations subject to the applicable trust boundary. The actual protections are determined by the confidential VM's hardware and software architecture. A confidential VM is not assumed to protect against every privileged host, firmware, physical, or side-channel attack. The critical functional requirement is that the protected governance identity and issuance state cannot be unilaterally altered by the ordinary AI compute process under the applicable threat model. Das Expires 19 April 2027 [Page 746] Internet-Draft Protected AI Execution Finality October 2026 11.18.5. WF-18.5 — Governance-Node Identity Registration Before accepting governance-node-issued capabilities, the protected authority system registers the identities or trust conditions of permitted governance components. A non-limiting registration record comprises: governance_node_id; confidential_vm_identity; approved_governance_measurement; registered_attestation_public_key; accepted_hardware_trust_root; authorized_policy_version; permitted_capability_classes; permitted_effectuation_sinks; registration_epoch; revocation_state. The registered governance identity may be associated with an approved hardware certificate chain or registered public-key trust root. The system distinguishes a governance identity asserted by a requester from an identity authenticated through the required trust mechanism. Registration does not automatically authorize arbitrary execution- capability issuance. The governance node remains subject to the applicable Authority Objects and protected operation-specific conditions. 11.18.6. WF-18.6 — Hardware Finality Gate Attestation Object Formation in the implementation described by enforcement point 80, HA-1803 produces a Hardware Finality Gate Attestation Object. The object may include one or more of: Das Expires 19 April 2027 [Page 747] Internet-Draft Protected AI Execution Finality October 2026 (a) governance firmware digest; (b) confidential virtual-machine policy version; (c) confidential-VM launch measurement; (d) host-data field; (e) hardware signing evidence; and (f) protected device identity. A non-limiting representation comprises: attestation_object_id; governance_node_id; protected_device_identity; governance_firmware_digest; vm_launch_measurement; vm_policy_version; host_data; measurement_generation; attestation_nonce; hardware_signing_evidence; certificate_chain_reference. The object identifies specified measured or authenticated properties of the governance environment. Fields not measured or authenticated by the selected attestation technology must not be treated as established merely because they appear in a software-created record. The applicable attestation procedure determines which object fields are security-relevant and how their provenance is verified. Das Expires 19 April 2027 [Page 748] Internet-Draft Protected AI Execution Finality October 2026 11.18.7. WF-18.7 — Hardware Trust-Root Verification PED-1806 authenticates the governance-node attestation against TR- 1805. The verification may include: (a) verification of the attestation signature; (b) verification of the applicable hardware-vendor certificate chain; (c) validation against a registered public-key trust root; (d) confirmation of governance-node identity; (e) confirmation of the approved governance workload measurement; (f) confirmation of the required protected execution configuration; (g) verification of freshness or challenge association; and (h) confirmation of applicable protected policy and revocation state. An illustrative predicate is: AttestationAcceptable = AuthenticAttestation AND RegisteredGovernanceIdentity AND ApprovedMeasurement AND ValidPolicyState AND RequiredFreshness Each term represents a mandatory check only where required by the selected authorization. An authentic but unapproved governance-node measurement is not automatically acceptable. A previously approved governance-node identity does not override an invalid required firmware or policy measurement. Das Expires 19 April 2027 [Page 749] Internet-Draft Protected AI Execution Finality October 2026 11.18.8. WF-18.8 — Governance Attestation State Registration Following successful verification, the protected system establishes a registered attestation-state reference. A representative record comprises: governance_node_id; attestation_object_digest; approved_measurement_reference; attestation_generation; policy_epoch; attestation_status; validity_conditions; registered_public_key_reference; affected_capability_classes; authorized_effectuation_sinks. The attestation state may be maintained by the PED, a protected governance registry, the hardware effectuation controller, or a suitable combination. The hardware Finality Sink must be able to verify the required registered attestation state associated with the capability issuer. It is insufficient for the governance VM to assert its own current validity without the required independent authentication. 11.18.9. WF-18.9 — Protected Governance-Key Isolation in the implementation described by enforcement point 81, KS-1808 maintains cryptographic key material used for governance or capability issuance within a protected governance boundary. Such key material may include: (a) a private capability-signing key; (b) a MAC key used to authenticate capabilities; Das Expires 19 April 2027 [Page 750] Internet-Draft Protected AI Execution Finality October 2026 (c) a protected governance key-encryption key; (d) an authenticated fabric-control channel key; (e) a protected attestation-bound derivation key; or (f) other cryptographic authority material required by the implementation. The ordinary AI compute process cannot read or export unrestricted governance keys. The compute node communicates with the protected governance component through an authenticated interface. The interface may allow submission of a Candidate Act but does not grant unrestricted access to the protected key itself. The protected component controls key use according to the required authority and attestation predicates. 11.18.10. WF-18.10 — Protected Capability Issuance Key Use A governance key is not merely a cryptographic utility available to any authenticated compute process. Where the key is used to generate execution capabilities, key use remains dependent upon the applicable operation-specific authorization. An illustrative protected key-use predicate is: PermitCapabilityIssue = AttestationAcceptable AND GovernanceIdentityValid AND CandidateActAuthorized AND ProtectedStateValid The issuing component refuses the corresponding key operation if a mandatory predicate fails. Possession of a signing-service endpoint or key identifier is not sufficient authority to mint valid execution capabilities. Das Expires 19 April 2027 [Page 751] Internet-Draft Protected AI Execution Finality October 2026 A protected key that can issue unrestricted permits without operation-specific checks would not establish the specified finality relationship merely because it is held inside a confidential VM. 11.18.11. WF-18.11 — Candidate Act Generation AI-1801 generates a proposed external operation or transfer. The operation may comprise: (a) outbound network transmission; (b) API invocation; (c) inter-node data transfer; (d) accelerator-output export; (e) model-state transfer; (f) privileged service call; (g) authenticated message dispatch; or (h) another consequential operation crossing the selected hardware- enforced effectuation boundary. The proposed operation is classified as Candidate Act CA-1822. Generation of CA-1822 does not independently authorize its execution. The required external effect remains subject to protected capability issuance and hardware Finality Sink verification. 11.18.12. WF-18.12 — Non-Effective Staging IM-1809 intercepts or controls CA-1822 before the governed external- transmission effect. HQ-1810 maintains the Candidate Act in a Non-Effective State. An illustrative pending operation record comprises: candidate_act_id; requesting_compute_node; operation_class; Das Expires 19 April 2027 [Page 752] Internet-Draft Protected AI Execution Finality October 2026 source_interface; destination_interface; payload_reference; requested_effectuation_boundary; policy_epoch; governance_attestation_reference; status = NON_EFFECTIVE. The proposed operation may be retained in a queue, protected buffer, inactive forwarding descriptor, or another controlled representation. The applicable hardware enforcement mechanism prevents the operation from becoming effective merely because the AI workload submitted it. Where the hardware controller would otherwise accept an unrestricted alternate path, the implementation must restrict or equivalently govern that path to establish the specified non-bypassable behavior. 11.18.13. WF-18.13 — Candidate Act Descriptor Formation DC-1811 constructs or verifies the Candidate Act Descriptor. The descriptor may identify: candidate_act_id; requesting_compute_node_id; workload_identity; operation_class; source_interface; destination_service_or_node; requested_network_destination; payload_digest; authorized_effectuation_boundary; Das Expires 19 April 2027 [Page 753] Internet-Draft Protected AI Execution Finality October 2026 required_governance_node_id; attestation_state_reference; policy_epoch; revocation_epoch; nonce; expiry; hardware_freshness_reference; finality_sink_id. The applicable Authority Object determines which fields are mandatory. The descriptor identifies the operation actually being proposed for external effectuation. It is distinct from the governance-node attestation record. 11.18.14. WF-18.14 — Canonical Candidate Act Representation In one illustrative cryptographic implementation: Dhw = Canon_v(SRC, ACT, DST, PAYLOAD, BOUNDARY, GOV, EPOCH, FRESH, SINK) where: Dhw denotes the canonical hardware-governed Candidate Act Descriptor; SRC denotes the authenticated source compute context; ACT denotes the proposed operation; DST denotes the destination or recipient; PAYLOAD denotes the effectuation-relevant payload or its authenticated digest; BOUNDARY denotes the authorized effectuation boundary; GOV denotes the issuing governance-node identity and required attestation-state reference; Das Expires 19 April 2027 [Page 754] Internet-Draft Protected AI Execution Finality October 2026 EPOCH denotes applicable protected authorization-state versions; FRESH denotes required hardware-freshness information; and SINK denotes the designated hardware Finality Sink. An illustrative digest is: hHw = H("DAS-HARDWARE-FINALITY-v1" || Encode(Dhw)) The selected encoding distinguishes mandatory fields and provides compatible interpretation at the PED and Finality Sink. The formula represents an optional detailed implementation; the particular hash algorithm and serialization are not required by the cited claim language. 11.18.15. WF-18.15 — Candidate Act Authority Validation PED-1806 obtains the applicable Authority Object from AS-1807. The authority may specify: (a) permitted requesting compute nodes; (b) authorized operation classes; (c) permitted destinations; (d) approved payload or data classifications; (e) protected governance identities; (f) required governance-node attestation state; (g) authorized hardware effectuation boundaries; (h) policy epochs; (i) revocation conditions; (j) nonce or usage limits; (k) required protected authorization-state transitions; and (l) applicable Finality Sink identities. Das Expires 19 April 2027 [Page 755] Internet-Draft Protected AI Execution Finality October 2026 The PED validates the concrete Candidate Act rather than relying exclusively upon successful governance-node attestation. An acceptable governance attestation establishes the selected trust condition for the issuer, but the proposed operation must independently satisfy its mandatory authority predicates. 11.18.16. WF-18.16 — Combined Attestation and Act-Specific Authorization Predicate An illustrative predicate is: Vhw = Pgovernance AND Pattestation AND Pcandidate AND Pscope AND Pboundary AND Pstate where: Vhw denotes the protected authorization result; Pgovernance verifies the registered governance-node identity; Pattestation verifies the required acceptable attestation state; Pcandidate verifies the proposed Candidate Act; Pscope verifies the authorized operation and destination scope; Pboundary verifies the designated hardware-controlled effectuation boundary; and Pstate verifies policy, revocation, nonce, freshness, and applicable protected authorization state. An operation is not authorized merely because Pattestation succeeds. All mandatory act-specific authorization predicates must also succeed. Das Expires 19 April 2027 [Page 756] Internet-Draft Protected AI Execution Finality October 2026 Where an applicable Authority Object requires an approved threshold or alternative authorization combination, the PED evaluates that expressly authorized combination. 11.18.17. WF-18.17 — Protected Authorization-State Handling Upon successful authorization, PED-1806 performs or verifies the protected-state operations required for CA-1822. These may include: (a) verifying the current governance attestation generation; (b) verifying policy and revocation epochs; (c) reserving an operation-specific grant; (d) registering or consuming a nonce; (e) allocating a bounded transfer allowance; (f) registering the required hardware-freshness state; (g) recording the Candidate Act Descriptor commitment; (h) registering an authorized effectuation boundary; or (i) another required protected authorization transition. Where authorization is single-use, protected state prevents unauthorized duplicate consumption. Where a transfer is explicitly usage-bounded, the applicable protected counters or hardware-enforced limits govern permitted usage. A failed mandatory state transition prevents corresponding capability issuance. 11.18.18. WF-18.18 — Protected Validation Evidence In a selected DAS embodiment requiring protected validation-evidence commitment, EV-1813 generates or commits the corresponding evidence. An illustrative record comprises: receipt_id; Das Expires 19 April 2027 [Page 757] Internet-Draft Protected AI Execution Finality October 2026 candidate_act_id; descriptor_digest; governance_node_id; attestation_state_reference; authority_object_reference; policy_epoch; protected_state_transition; nonce; hardware_freshness_reference; finality_sink_id; validation_result; protected_authentication. The evidence may comprise an AVR, LAVR, sealed record, authenticated commitment, or another supported protected artifact. Where evidence commitment is a required precondition to capability availability, the protected system completes the commitment before, or atomically with, release of the scoped capability. The exact text of enforcement point 79 does not independently prescribe every LAVR or evidence-commitment detail included in this fuller workflow; those additional dependencies apply to embodiments that expressly require them. 11.18.19. WF-18.19 — Scoped Execution-Capability Generation Following successful protected authorization, CR-1814 releases or makes available an operation-scoped execution capability. The capability contains or securely references: capability_id; candidate_act_digest; issuing_governance_identity; Das Expires 19 April 2027 [Page 758] Internet-Draft Protected AI Execution Finality October 2026 governance_attestation_state_reference; authorized_operation; authorized_destination; authorized_effectuation_boundary; policy_epoch; revocation_epoch; nonce; expiry; hardware_freshness_reference; usage_limit; finality_sink_id. Where a receipt dependency is required, the capability additionally incorporates or references the corresponding committed protected validation evidence. The capability is not an unrestricted permission for the issuing governance VM to transmit any data. Its validity depends upon the authorized operation, effectuation boundary, applicable registered attestation state, and other mandatory protected conditions. 11.18.20. WF-18.20 — Cryptographically Authenticated Capability A non-limiting capability representation is: Chw = Sign_skGOV(Encode(hHw, GovID, AttestRef, Scope, Boundary, Epoch, Fresh, Nonce, Expiry, Sink)) where: Chw denotes the execution capability; Sign_skGOV denotes signing under protected governance key material; hHw denotes the Candidate Act Descriptor digest; Das Expires 19 April 2027 [Page 759] Internet-Draft Protected AI Execution Finality October 2026 GovID denotes the registered governance identity; AttestRef denotes the required governance attestation-state reference; Scope denotes permitted operation scope; Boundary denotes the authorized effectuation boundary; Epoch denotes applicable protected policy state; Fresh denotes hardware freshness; Nonce denotes the required freshness value; Expiry denotes capability validity; and Sink denotes the designated hardware Finality Sink. A MAC-authenticated permit, sealed capability handle, protected forwarding-table entry, or another supported representation may be used instead. The non-bearer character of the capability depends upon actual verification of its operation, context, state, usage, and sink restrictions. 11.18.21. WF-18.21 — Authenticated Fabric-Management Capability Delivery FM-1815 transfers or makes available the authorized execution capability from the governance node or protected authority toward HC- 1816. The communication path may employ: (a) mutually authenticated management transport; (b) a protected device-control queue; (c) an authenticated DPU management interface; (d) a protected SmartNIC control channel; (e) authenticated inter-processor messaging; (f) an HSM-authenticated fabric-control message; Das Expires 19 April 2027 [Page 760] Internet-Draft Protected AI Execution Finality October 2026 (g) a sealed capability-table installation command; or (h) another authenticated management mechanism. The receiving component verifies the origin and integrity of the transmitted authorization material. A successful management-channel connection does not independently establish that the conveyed capability is valid for the particular Candidate Act. The hardware Finality Sink verifies the applicable operation-specific and attestation-state conditions before effectuation. 11.18.22. WF-18.22 — Capability Delivery and Actual-Operation Consistency Where the management plane delivers a capability before the corresponding data-plane operation arrives, the hardware controller maintains a protected association between them. An illustrative installed authorization entry comprises: capability_id; candidate_act_digest; source_node_id; destination_reference; authorized_effectuation_boundary; issuing_governance_node_id; registered_attestation_generation; policy_epoch; freshness_reference; remaining_uses; expiry; status. Das Expires 19 April 2027 [Page 761] Internet-Draft Protected AI Execution Finality October 2026 The data-plane operation is admitted only when its effectuation- relevant attributes satisfy the protected entry. A capability installed for one destination or operation cannot automatically authorize a different transfer. An ordinary management-plane acknowledgement does not itself prove that the governed data-plane transfer has been completed. 11.18.23. WF-18.23 — Hardware Finality Sink Verification Before external transmission, FS-1817 independently verifies: (a) execution-capability authenticity; (b) the Candidate Act or its required descriptor commitment; (c) authorized operation and destination scope; (d) designated hardware-enforced effectuation boundary; (e) registered identity of the capability issuer; (f) acceptable attestation state of the governance component; (g) policy epoch and revocation state where mandatory; (h) required hardware freshness; (i) nonce and expiry; (j) usage or consumption state; and (k) protected validation-evidence reference where required. The Finality Sink obtains the actual operation through its controlled hardware or network interface. It does not rely solely upon an agent-supplied statement that the operation has been approved. A capability from an unregistered or improperly attested governance node is rejected when the registered governance-state binding is mandatory. Das Expires 19 April 2027 [Page 762] Internet-Draft Protected AI Execution Finality October 2026 11.18.24. WF-18.24 — Hardware Finality Verification Predicate An illustrative finality predicate is: PermitHardware = Auth(C) AND ActMatch(C,Dactual) AND IssuerValid(C,Gregistered) AND AttestationValid(C,Acurrent) AND BoundaryValid(C,F) AND StateValid(C,S) where: PermitHardware denotes permission to cross the governed hardware boundary; C denotes the scoped capability; Dactual denotes the actual operation descriptor; Gregistered denotes the registered governance identity; Acurrent denotes the required current attestation state; F denotes the designated hardware Finality Sink; and S denotes applicable protected authorization state. Auth verifies capability authentication. ActMatch verifies operation correspondence. IssuerValid verifies registered governance identity. AttestationValid verifies the required acceptable governance attestation state. BoundaryValid verifies the authorized effectuation interface. StateValid verifies current policy, revocation, freshness, nonce, and usage conditions. Das Expires 19 April 2027 [Page 763] Internet-Draft Protected AI Execution Finality October 2026 The hardware Finality Sink enables the governed operation only when every mandatory predicate succeeds. 11.18.25. WF-18.25 — Hardware-Enforced Transmission Interlock HC-1816 controls an actual external transmission or forwarding boundary. The hardware controller may implement the interlock through: (a) protected transmit queue admission; (b) a hardware forwarding-table entry; (c) a protected network-egress enablement bit; (d) a bounded DMA or descriptor authorization; (e) a DPU-controlled forwarding pipeline; (f) a SmartNIC packet admission rule; (g) an accelerator-egress control; or (h) another hardware-controlled effectuation interface. Before required verification succeeds, the selected boundary remains non-admitting for the Candidate Act. After successful verification, the controller permits only the operation authorized by the capability. The implementation must establish that the hardware controller actually controls the governed effect. Merely observing transmission or generating an alert does not satisfy a requirement to prevent unauthorized external transmission. 11.18.26. WF-18.26 — Confidential Governance Measurement Change in the implementation described by enforcement point 82, a required governance-node measurement may change. Relevant changes include: (a) governance firmware measurement; (b) confidential-VM launch measurement; Das Expires 19 April 2027 [Page 764] Internet-Draft Protected AI Execution Finality October 2026 (c) protected policy version; (d) protected software configuration; or (e) another required approved governance-state attribute. The attestation system produces or establishes a state that no longer satisfies the approved governance-node measurement condition. PED-1806 refuses further capability issuance dependent upon that governance node until successful revalidation. The selected implementation also determines whether already issued capabilities are invalidated at the hardware Finality Sink. Where enforcement point 79's required registered attestation state must remain acceptable at effectuation, FS-1817 verifies that condition before admitting further affected operations. A refusal to issue new capabilities is not automatically equivalent to revocation of all previously issued capabilities unless the corresponding sink-side state checks enforce that result. 11.18.27. WF-18.27 — Attestation Revalidation Following an authorized governance-node software, firmware, or policy update, RV-1819 may initiate revalidation. The procedure may include: (a) obtaining a fresh authenticated attestation record; (b) verifying the hardware trust chain; (c) identifying the governance-node identity; (d) evaluating the new launch or firmware measurement; (e) verifying the approved policy configuration; (f) authenticating required freshness; (g) establishing current registered attestation state; (h) updating the corresponding protected generation; and (i) permitting renewed operation-specific capability issuance only when required conditions succeed. Das Expires 19 April 2027 [Page 765] Internet-Draft Protected AI Execution Finality October 2026 Successful revalidation does not automatically authorize operations that remain outside their individual Authority Objects. A changed governance measurement is not automatically unacceptable forever; it may be accepted after protected approval under the applicable governance policy. 11.18.28. WF-18.28 — Hardware-Freshness Binding in the implementation described by enforcement point 83, the execution capability is additionally bound to hardware-freshness state. The state may comprise at least one of: (a) trusted monotonic counter; (b) secure boot epoch; (c) protected clock; (d) device sequence value; or (e) hardware-attested nonce. An illustrative freshness record comprises: device_id; governance_node_id; hardware_boot_epoch; secure_counter; device_sequence; trusted_time_reference; hardware_nonce; freshness_generation. The protected authority binds the applicable freshness information to the capability. The hardware Finality Sink verifies the required relationship between the capability and the current authorized hardware-freshness state. Das Expires 19 April 2027 [Page 766] Internet-Draft Protected AI Execution Finality October 2026 A capability referencing incompatible previous state is rejected. 11.18.29. WF-18.29 — Snapshot, Reset, and Hardware Replay Resistance The system addresses replay of previously valid authorization material following: (a) governance VM snapshot restoration; (b) device reset; (c) firmware restart; (d) hardware-controller failover; (e) protected capability-table restoration; (f) management-channel replay; or (g) another restoration of earlier software-visible state. Where a trusted monotonic counter or secure boot epoch is required, the current protected value must remain authoritative independently of rollback-accessible state. An earlier capability fails when its mandatory freshness binding no longer corresponds to the protected current state. A software timestamp alone does not establish strong rollback resistance where the attacker can restore the corresponding time or authorization state. Hardware freshness is verified according to the selected trust model. 11.18.30. WF-18.30 — Capability Consumption and Hardware State Where a capability is single-use or usage-bounded, HC-1816 performs or coordinates its protected consumption. An illustrative state record comprises: capability_id; candidate_act_digest; governance_attestation_generation; hardware_freshness_reference; Das Expires 19 April 2027 [Page 767] Internet-Draft Protected AI Execution Finality October 2026 authorized_effectuation_boundary; remaining_uses; remaining_transfer_allowance; protected_state_version; status. A representative progression is: AVAILABLE → RESERVED → ADMITTED → CONSUMED. The hardware controller prevents unauthorized duplicate admission under the same restricted grant. Where a capability authorizes a bounded number of transfers or a defined network flow, the applicable usage limits are enforced. Consumption of an authorization record does not automatically prove that an external receiving service completed its subsequent operation. 11.18.31. WF-18.31 — Attestation-State Revocation at Distributed Controllers Where multiple SmartNICs, DPUs, or rack-boundary controllers are permitted to accept capabilities from the same governance node, each participating controller verifies the required registered governance state. The system may distribute authenticated attestation-state updates containing: governance_node_id; previous_attestation_generation; new_attestation_generation; approved_measurement_reference; policy_epoch; revocation_state; affected_capability_classes; Das Expires 19 April 2027 [Page 768] Internet-Draft Protected AI Execution Finality October 2026 affected_effectuation_sinks; protected_authentication. Each affected controller verifies the updates according to its required freshness and consistency rules. An authorization accepted at one Finality Sink does not automatically authorize a different operation at another. Where current attestation-state verification is mandatory, the controller refuses affected capabilities when that state cannot be established. The architecture does not assume instantaneous propagation across an arbitrary distributed network. Its actual revocation guarantee depends upon enforceable update, expiry, or freshness mechanisms. 11.18.32. WF-18.32 — Illustrative Confidential Governance VM and SmartNIC Deployment In one implementation, an AI compute server runs an autonomous agent that generates external network requests. A separate governance compute node runs in a confidential virtual machine. The governance node has a hardware-rooted attestation identity and access to protected capability-issuance operations. A SmartNIC controls the governed external network interface. The AI agent prepares a request to transmit data to an authorized enterprise service. The operation is intercepted and staged. The governance node supplies an authenticated attestation record identifying its protected execution configuration. PED-1806 verifies the attestation record against the registered governance identity, approved hardware trust root, and required current policy state. DC-1811 constructs the Candidate Act Descriptor identifying the source, requested operation, destination, payload or data-class scope, authorized SmartNIC egress boundary, policy epoch, and required freshness state. Das Expires 19 April 2027 [Page 769] Internet-Draft Protected AI Execution Finality October 2026 PED-1806 validates the Candidate Act-specific authority. The protected system completes its required state and evidence procedures. CR-1814 releases an operation-scoped capability authenticated using protected governance key material. FM-1815 conveys the capability through an authenticated management interface to HC-1816. The SmartNIC verifies the capability against the actual external operation, designated egress boundary, registered governance attestation state, and mandatory current authorization conditions. If verification succeeds, the SmartNIC permits the scoped transmission. If the capability or required governance attestation state is invalid, the SmartNIC prevents that operation from crossing its controlled external-transmission boundary. 11.18.33. WF-18.33 — Illustrative Compromised AI Compute Process An ordinary AI compute process is compromised and attempts to generate unauthorized external traffic. The process can prepare a network request but cannot extract the governance private key from KS-1808. It attempts to create a capability by supplying an unauthorized destination. PED-1806 evaluates the actual Candidate Act and applicable Authority Object. The destination violates the required operation scope. The protected capability is withheld. The SmartNIC does not permit the unverified request through the governed forwarding path. If the process instead presents a forged capability, the hardware Finality Sink rejects its authentication or registered-issuer conditions. Das Expires 19 April 2027 [Page 770] Internet-Draft Protected AI Execution Finality October 2026 The protection assumes that the compromised compute process cannot bypass the hardware-controlled effectuation interface under the implementation's threat model. 11.18.34. WF-18.34 — Illustrative Governance Firmware Measurement Change A governance VM operates under an approved firmware and software measurement. The system has registered the corresponding acceptable attestation state. A firmware or protected software configuration change occurs. The new attestation state does not match the approved condition. PED-1806 refuses further execution-capability issuance dependent upon that governance node. The affected hardware Finality Sink also enforces any mandatory current registered-attestation-state restriction when verifying subsequent capabilities. Following an authorized revalidation of the changed governance configuration, the protected system may register a new acceptable attestation generation. New Candidate Acts must still satisfy their own operation-specific authorization requirements. 11.18.35. WF-18.35 — Illustrative Hardware-Freshness Replay Attack An authorized governance node issues a single-use network- transmission capability bound to a protected device sequence and boot epoch. The SmartNIC verifies the capability and admits the specified operation. The relevant protected usage or freshness state advances. An attacker later restores an earlier governance VM snapshot and attempts to reuse the previously valid capability. The protected hardware-freshness or consumption state no longer matches the authorization. Das Expires 19 April 2027 [Page 771] Internet-Draft Protected AI Execution Finality October 2026 The SmartNIC refuses the attempted replay. The snapshot's earlier view of capability validity does not override the current protected hardware state. 11.18.36. WF-18.36 — Crash, Reset, and Recovery The architecture distinguishes different failure stages. Failure before governance attestation succeeds: Capability issuance dependent upon the governance node remains unavailable. Failure after attestation but before Candidate Act authorization: An acceptable attestation does not independently create operation authority. Failure during protected authorization: An incomplete mandatory authorization or state transition does not produce a usable capability. Failure during capability delivery: The effectuation controller must not treat an unauthenticated or partially installed capability as valid. Failure after capability installation but before hardware admission: The Finality Sink verifies current required attestation, capability, policy, and freshness state before permitting effectuation. Failure after possible network transmission: The operation may be classified as completed or indeterminate according to available effectuation evidence. Governance VM snapshot restoration: Required protected freshness and capability-consumption state remain authoritative. SmartNIC or DPU reset: The controller restores or revalidates capability state according to its protected hardware-freshness and policy conditions. Governance software update: A changed mandatory measurement requires revalidation before dependent new capability issuance. An indeterminate external operation is not automatically replayed when repetition could cause a duplicate consequence. Authenticated operation identifiers, hardware completion records, protected counters, and receiving-side status records may support recovery where available. Das Expires 19 April 2027 [Page 772] Internet-Draft Protected AI Execution Finality October 2026 11.18.37. WF-18.37 — Alternative Technical Implementations Confidential governance VM with SmartNIC: The governance authority runs within a confidential VM, and the SmartNIC controls outbound transmission. Confidential governance VM with DPU: The DPU verifies the required capability through its protected network-forwarding or data-path controls. Rack-boundary enforcement: A protected rack-boundary controller verifies capabilities for designated compute nodes before forwarding traffic beyond the governed boundary. Accelerator-egress implementation: A protected accelerator-output interface verifies operation-specific authority before exporting model or tensor data. Protected network-controller implementation: A hardware network controller verifies the required governance identity, attestation state, and operation capability. HSM-assisted governance: Protected issuance keys remain under HSM control while the governance VM performs authenticated authorization coordination. Single-node implementation: Governance and hardware finality functions are integrated within one physical system while retaining the specified confidentiality, attestation, and independent verification relationships. Distributed implementation: The AI compute node, confidential governance node, and hardware Finality Sink operate on separate authenticated physical nodes. Multi-controller implementation: Several hardware effectuation controllers accept bounded capabilities according to their independently verified sink identity and registered governance state. The implementation must demonstrate the actual trust-root, protected key, enforcement-path, and attestation-state guarantees it claims. 11.18.38. WF-18.38 — Failure and Fail-Closed Conditions The governed external operation is refused when any mandatory condition is absent, invalid, expired, revoked, inconsistent, or unverifiable. Das Expires 19 April 2027 [Page 773] Internet-Draft Protected AI Execution Finality October 2026 Non-limiting conditions include: (a) invalid governance VM attestation; (b) unregistered governance identity; (c) failed hardware trust-root verification; (d) invalid hardware-vendor certificate chain; (e) invalid registered public-key trust root; (f) governance firmware measurement mismatch; (g) incompatible confidential-VM policy version; (h) invalid launch measurement; (i) required host-data mismatch; (j) invalid protected device identity; (k) unavailable protected governance-key operation; (l) unauthorized Candidate Act; (m) invalid Authority Object; (n) missing execution capability; (o) invalid capability authentication; (p) unauthorized effectuation boundary; (q) actual-operation descriptor mismatch; (r) registered attestation-state mismatch; (s) stale policy epoch; (t) revoked capability; (u) expired or replayed nonce; (v) hardware-freshness mismatch; (w) consumed or exhausted capability; Das Expires 19 April 2027 [Page 774] Internet-Draft Protected AI Execution Finality October 2026 (x) unauthenticated fabric-management message; (y) incorrect Finality Sink identity; (z) failure of mandatory hardware-interlock verification; or (aa) an accessible bypass path defeating the specified hardware- enforced effectuation boundary. An invalid or unavailable mandatory security condition does not create unrestricted fallback permission. 11.18.39. WF-18.39 — PHOSITA Verification and Negative Tests A person having ordinary skill in confidential computing, hardware attestation, SmartNIC/DPU engineering, secure boot, cryptography, network forwarding, distributed authorization, or protected execution may verify the architecture through controlled testing. Test 1 — Valid attestation and authorized act: Present a valid governance attestation and matching operation-specific capability. The hardware Finality Sink admits the authorized transmission. Test 2 — Valid attestation without capability: Present an acceptable governance attestation but no act-specific capability. Transmission is refused. Test 3 — Unauthorized Candidate Act: Submit an operation outside the applicable Authority Object. Capability issuance is denied. Test 4 — Invalid attestation signature: Supply a forged attestation object. PED verification fails. Test 5 — Unregistered governance node: Attempt issuance through an unregistered governance identity. Protected verification fails. Test 6 — Wrong hardware trust root: Present a chain that does not satisfy the configured trust policy. Attestation is rejected. Test 7 — Governance firmware mismatch: Modify a required firmware measurement. Issuance is withheld pending revalidation. Test 8 — Confidential VM launch mismatch: Change a required launch measurement. The approved attestation condition fails. Test 9 — Policy version mismatch: Present an unauthorized confidential-VM policy version. Protected verification refuses dependent authorization. Das Expires 19 April 2027 [Page 775] Internet-Draft Protected AI Execution Finality October 2026 Test 10 — Host-data mismatch: Alter a required attested host-data field. The corresponding predicate fails. Test 11 — Key extraction attempt: Attempt unrestricted governance-key access from the AI compute process. Access is denied under the configured protected-key model. Test 12 — Forged capability: Present an unauthenticated or incorrectly authenticated capability. The hardware Finality Sink refuses it. Test 13 — Issuer substitution: Present a valid-looking capability associated with another governance identity. Required issuer binding fails. Test 14 — Destination substitution: Authorize one destination and attempt a different transmission. The Finality Sink rejects the mismatch. Test 15 — Boundary substitution: Present a capability at a hardware boundary not authorized by its scope. Verification fails. Test 16 — Management-channel tampering: Modify capability data in transit. Authenticated delivery or capability verification detects the change. Test 17 — Capability installed without valid act: Attempt to activate a forwarding rule without valid operation-specific authority. The controlled effect remains blocked. Test 18 — Revoked attestation state: Invalidate the required governance attestation and verify that affected capability issuance or use is refused according to the mandatory state rules. Test 19 — Revalidated attestation: Complete authorized revalidation of an updated governance measurement and verify that new issuance remains subject to act-specific predicates. Test 20 — Hardware monotonic-counter replay: Reuse authorization tied to an incompatible earlier protected counter state. The Finality Sink rejects it. Test 21 — Secure boot epoch mismatch: Replay a capability from an invalid previous boot epoch. Required freshness verification fails. Test 22 — Hardware nonce replay: Reuse an invalidated hardware- attested nonce. The affected operation is refused. Das Expires 19 April 2027 [Page 776] Internet-Draft Protected AI Execution Finality October 2026 Test 23 — Governance VM snapshot restoration: Restore a previous snapshot and attempt reuse of consumed authority. Protected current state prevents unauthorized replay. Test 24 — DPU reset: Reset the effectuation controller and verify that stale protected authorization is not treated as valid without required revalidation. Test 25 — Concurrent capability use: Submit competing transfers against one restricted grant. Protected consumption prevents unauthorized duplicate effectuation. Test 26 — Alternative network path: Attempt to bypass the SmartNIC or designated network controller. The governed effect remains blocked or equivalently mediated under the specified path coverage. Test 27 — Hardware versus software-only allow: Remove the protected capability while preserving an upstream software allow status. The hardware Finality Sink continues to block effectuation. Test 28 — Wrong Finality Sink: Present a capability for another protected interface. Required sink binding fails. Test 29 — Single-node configuration: Integrate governance and hardware enforcement functions within one node and verify that the required protected authority and finality checks remain enforced. Test 30 — Distributed configuration: Run the AI compute node, governance VM, and hardware Finality Sink on separate nodes. Verify the authenticated attestation, capability-delivery, and effectuation sequence. Test 31 — Issuer measurement changed after capability issuance: Change a mandatory governance measurement and verify whether the selected current-attestation-state enforcement invalidates affected outstanding capabilities as required. Test 32 — Indeterminate external completion: Interrupt communication after a transfer may have occurred. Recovery preserves accurate completion or indeterminate status rather than assuming the transfer was prevented. These tests may employ a confidential-VM development platform, attestation test fixtures, protected signing services, programmable SmartNIC/DPU hardware, controlled network interfaces, capability- state stores, hardware-freshness emulators, and fault-injection facilities. Das Expires 19 April 2027 [Page 777] Internet-Draft Protected AI Execution Finality October 2026 Test outcomes establish only the technical guarantees demonstrated by the actual implementation and threat model. 11.18.40. WF-18.40 — Claim-Specific Technical Support Enforcement Point 79 — Confidential Governance VM and Hardware- Attested SmartNIC Finality The workflow provides: (a) AI-1801 as the AI compute node producing a proposed external operation; (b) GC-1802 as the confidential governance compute node; (c) HA-1803 as the hardware-rooted attestation component; (d) PED-1806 verifying the governance attestation against the approved trust root, registered governance identity, and protected policy state; (e) protected act-specific authorization and capability release; (f) FM-1815 providing the authenticated fabric-management path; (g) HC-1816 and FS-1817 as the hardware-associated effectuation controller and Finality Sink; (h) independent capability verification against the actual Candidate Act, effectuation boundary, and registered governance attestation state; and (i) prevention of governed external transmission when required attestation or capability verification fails. Enforcement Point 80 — Confidential VM Attestation Object WF-18.6 and WF-18.7 describe the Hardware Finality Gate Attestation Object, including governance firmware digest, confidential-VM policy version, launch measurement, host-data field, hardware signing evidence, and protected device identity, with verification against the appropriate vendor certificate chain or registered trust root. Enforcement Point 81 — Confidential Governance-Key Isolation Das Expires 19 April 2027 [Page 778] Internet-Draft Protected AI Execution Finality October 2026 WF-18.9 and WF-18.10 describe protected custody of governance or capability-issuance key material and authenticated communication from the ordinary AI compute process without unrestricted access to the keys. Enforcement Point 82 — Attestation Change Disables Capability Issuance WF-18.26 and WF-18.27 describe invalidation of the required approved governance measurement condition following firmware, launch, policy, or protected configuration changes and refusal of further dependent capability issuance pending successful revalidation. Enforcement Point 83 — Cryptographically Bound Hardware Freshness WF-18.28 and WF-18.29 describe binding the capability to trusted monotonic counters, secure boot epochs, protected clocks, device sequences, or hardware-attested nonces, preventing replay when current protected freshness state is incompatible with the presented capability. 11.18.41. WF-18.41 — Technical Effect The workflow establishes an enforceable dependency between: (a) AI computation generating a proposed external operation; (b) protected execution of a governance component within a confidential virtual machine; (c) hardware-rooted authentication of governance identity and execution configuration; (d) verification of the governance attestation against registered trust roots and protected policy; (e) interception and Non-Effective State staging of the Candidate Act; (f) act-specific protected authorization; (g) protected capability generation without exposing unrestricted governance keys to the AI compute process; (h) authenticated capability delivery to a hardware effectuation controller; Das Expires 19 April 2027 [Page 779] Internet-Draft Protected AI Execution Finality October 2026 (i) independent verification against the concrete operation, authorized effectuation boundary, and registered issuer attestation state; (j) hardware-enforced external transmission only upon successful verification; (k) refusal following invalid required governance measurements; and (l) hardware-freshness checks preventing reuse of authorization material outside its permitted device-state context. The confidential governance VM protects specified governance computation and key-management functions. The attestation mechanism establishes the approved identity and measured configuration of the governance node. The protected authorization procedure determines whether a particular Candidate Act is permitted. The SmartNIC, DPU, or equivalent hardware Finality Sink enforces that authorization at the actual governed external-transmission boundary. These are related but distinguishable technical functions. Computation is not authority to act. Confidential governance execution is not itself permission for a Candidate Act. Hardware attestation establishes an approved trust condition, not unrestricted external-operation authority. An authenticated management channel does not replace act-specific Finality Sink verification. The hardware Finality Sink must refuse the effect when mandatory governance attestation or capability conditions fail. 11.19. WF-19 — User-Controlled Confidential Virtual Machine, Root-Key Sovereignty, Attested Derived-Key Release, Separate Data-Access and Execution Authority, Privacy-Preserving Finality Evidence, and Rollback-Resistant Recovery Das Expires 19 April 2027 [Page 780] Internet-Draft Protected AI Execution Finality October 2026 11.19.1. WF-19.1 — Technical Purpose This embodiment describes a computer-implemented architecture for executing an artificial-intelligence agent within a cloud-hosted confidential virtual machine while maintaining separate controls over protected data confidentiality and authority to perform externally effective operations. The system comprises a confidential virtual-machine environment, cryptographic data-protection component, hardware-rooted attestation mechanism, protected key-enablement component, AI execution environment, Protected Enforcement Domain, protected evidence- commitment mechanism, and one or more Finality Sinks. Protected user data, agent memory, connected-service information, or task state is encrypted using user-controlled or user-authorized cryptographic material. The AI workload may receive bounded access to protected information only when its confidential-VM measurement and user-authorized data- access conditions are satisfied. However, successful access to or decryption of protected data does not independently confer authority to transmit that data, export files, apply connected-service credentials, modify persistent state, or perform another consequential operation. A proposed externally effective operation is classified as a Candidate Act and maintained in a Non-Effective State. The Protected Enforcement Domain validates the Candidate Act against operation-specific authority, execution context, policy state, freshness, and intended effectuation boundary. Following successful protected validation, the required validation evidence is committed before, or atomically with, release of an operation-specific execution capability. The corresponding Finality Sink independently verifies the capability before permitting the governed consequence. The architecture therefore establishes two distinct protected authorization relationships: Data-access authorization: Whether the specified AI workload may obtain bounded use of protected information. Das Expires 19 April 2027 [Page 781] Internet-Draft Protected AI Execution Finality October 2026 Execution-finality authorization: Whether a concrete consequential operation involving that information may become externally effective. Neither authorization automatically substitutes for the other. 11.19.2. WF-19.2 — Participating Technical Components In one non-limiting implementation, the system comprises: CV-1901 — Cloud-Hosted Confidential Virtual Machine A confidential VM configured to host an AI agent, protected task state, user memory, or connected-service data. AE-1902 — Artificial-Intelligence Execution Environment The model, agent, tool runtime, or orchestration component executing within CV-1901. DP-1903 — Cryptographic Data-Protection Component A mechanism configured to encrypt or otherwise cryptographically protect designated user data. RK-1904 — User-Controlled Root-Key Authority A user-controlled cryptographic authority or external key service operating under user authorization and retaining the applicable root encryption key. HA-1905 — Hardware-Rooted Attestation Component A component configured to provide authenticated measurements of the confidential VM and its applicable software and security configuration. KV-1906 — Protected Attestation Verification Component A mechanism configured to verify the authenticity, freshness, identity, and required measurements of the confidential-VM attestation. KE-1907 — Protected Key-Enablement Component A mechanism configured to provide a permitted derived key, wrapped key, session-limited key, decryption-enabling secret, or bounded cryptographic operation only upon satisfaction of required data- access conditions. Das Expires 19 April 2027 [Page 782] Internet-Draft Protected AI Execution Finality October 2026 DA-1908 — User Data-Access Authority Store An authenticated source of user-authorized data-access policies, permitted datasets, workload identities, access purposes, validity intervals, and protected authorization state. IM-1909 — Consequential Operation Interception Component A controlled interface configured to intercept proposed externally effective operations generated by AE-1902. HQ-1910 — Non-Effective Candidate Act Holding Mechanism A protected or enforcement-controlled queue, buffer, pending request, or equivalent staging mechanism. DC-1911 — Candidate Act Descriptor Component A component configured to construct or verify an effectuation- relevant descriptor of the proposed consequential operation. PED-1912 — Protected Enforcement Domain A protected authority component configured to validate Candidate Acts independently of successful decryption. AS-1913 — Operation-Specific Authority Store An authenticated source of permitted operation classes, destinations, purposes, workload identities, policy requirements, and designated Finality Sinks. PS-1914 — Protected Authorization-State Store A component maintaining nonce state, revocation epochs, policy versions, capability-consumption state, and mandatory protected authorization commitments. EV-1915 — Protected Validation-Evidence Component A mechanism configured to commit Candidate Act-specific protected validation evidence. CR-1916 — Operation-Specific Execution Capability Mechanism A protected component configured to generate, release, register, or activate scoped execution authority. Das Expires 19 April 2027 [Page 783] Internet-Draft Protected AI Execution Finality October 2026 FS-1917 — Effectuation Finality Sink A controlled network, service, credential, file-export, storage- commit, or other consequential interface configured to verify the capability before permitting the operation. ER-1918 — Privacy-Preserving Execution-Evidence Component A mechanism configured to produce cryptographically authenticated evidence of protected validation and applicable Finality Sink verification without unnecessarily disclosing protected plaintext, reusable credentials, or the root encryption key. RS-1919 — Rollback-Resistant Authorization State A protected mechanism maintaining current capability-consumption, revocation, and required freshness information independently of rollback-accessible VM backups. RC-1920 — Confidential-VM Recovery Component A mechanism configured to reestablish authorized attestation and reconcile protected key and execution state following recovery. OS-1921 — Protected Operation-Outcome Store A mechanism maintaining pending, denied, confirmed-effective, expired, revoked, or indeterminate operation states. The functions may be implemented using protected software, confidential computing, an HSM, TEE, external key authority, authenticated cloud service, hardware-enforced interface, or a suitable combination. 11.19.3. WF-19.3 — Separation of Confidentiality and Execution Authority The architecture establishes two distinguishable trust domains. The first governs cryptographic access to protected information. The second governs the authority to produce consequential effects. The data-access domain determines whether a confidential VM may decrypt or use specified protected data. Das Expires 19 April 2027 [Page 784] Internet-Draft Protected AI Execution Finality October 2026 The execution-finality domain determines whether a particular operation prepared by the AI agent may affect an external resource, recipient, service, file, credential, or persistent state. For example, an AI agent may be permitted to read a confidential report for summarization without having permission to email the report to an external recipient. Similarly, authority to access connected-service information does not automatically permit the agent to use a connected-service credential to perform an unrelated transaction. The separate control is enforced through distinct protected authorization conditions rather than an assumption that confidentiality automatically guarantees safe behavior. 11.19.4. WF-19.4 — Confidential Virtual-Machine Establishment CV-1901 is instantiated within a cloud-hosted confidential-computing environment. The environment may provide: (a) hardware-protected VM memory; (b) measured workload launch; (c) virtual-machine integrity measurement; (d) authenticated attestation reports; (e) protected guest execution; (f) security-configuration measurements; (g) isolated runtime memory; and (h) controlled access to protected external key services. The implementation determines which protections are available against privileged host access, hypervisor compromise, firmware compromise, memory disclosure, rollback, and other threats. The confidential VM does not automatically obtain authority to perform every external action merely because its execution environment is successfully attested. Das Expires 19 April 2027 [Page 785] Internet-Draft Protected AI Execution Finality October 2026 11.19.5. WF-19.5 — User-Controlled Root-Key Establishment in the implementation described by enforcement point 85, RK-1904 maintains a root encryption key under the control of a user or user- authorized external key authority. The root key may be maintained within: (a) a user-controlled HSM; (b) a user-authorized cloud key-management service; (c) an external protected key vault; (d) a protected device or secure element; (e) a user-controlled cryptographic authority; or (f) another suitable protected key-custody arrangement. The root encryption key is not made available for unrestricted extraction by the AI agent. The root authority may be used to derive, wrap, authorize, or control bounded data-access material. The mere existence of a user-controlled root key does not independently establish permission to release data outside the user's authorized execution scope. 11.19.6. WF-19.6 — Protected User-Data Encryption DP-1903 protects designated information using encryption associated with the user-controlled or user-authorized key material. Protected information may include: (a) user documents; (b) private agent memory; (c) connected-service data; (d) task context; (e) retained application state; (f) private model inputs; Das Expires 19 April 2027 [Page 786] Internet-Draft Protected AI Execution Finality October 2026 (g) encrypted storage volumes; (h) stored execution-history records; or (i) other designated user information. An illustrative encrypted object contains: encrypted_object_id; ciphertext_reference; encryption_algorithm_id; key_version; data_scope_id; tenant_or_user_reference; integrity_tag; authorized_access_policy_reference. The specific encryption scheme must provide the confidentiality and integrity properties required by the implementation. An encrypted object is not treated as authorized for external release merely because its contents can be decrypted by the confidential VM. 11.19.7. WF-19.7 — Hardware-Rooted Confidential-VM Attestation HA-1905 generates a cryptographically verifiable measurement of the confidential VM. The attestation identifies the required software measurement and security-configuration state. A non-limiting attestation record comprises: attestation_id; vm_identity; hardware_platform_identity; vm_launch_measurement; Das Expires 19 April 2027 [Page 787] Internet-Draft Protected AI Execution Finality October 2026 workload_software_measurement; security_configuration; attestation_nonce; attestation_generation; policy_reference; protected_authentication. The attestation mechanism may use hardware-supported measurement, a signed attestation report, a registered attestation key, or another authenticated measurement technology. The exact content of the report depends upon the hardware and virtualized execution platform. An attestation proves only the measured or authenticated properties supported by the selected mechanism. 11.19.8. WF-19.8 — Verification of the Confidential-VM Measurement KV-1906 verifies: (a) attestation authenticity; (b) accepted hardware trust root; (c) correct VM identity; (d) required software measurement; (e) approved security configuration; (f) freshness or challenge association; (g) applicable workload authorization; and (h) required protected policy state. An illustrative predicate is: Vattest = AuthenticReport AND ApprovedMeasurement AND ApprovedConfiguration AND CorrectWorkload AND RequiredFreshness Das Expires 19 April 2027 [Page 788] Internet-Draft Protected AI Execution Finality October 2026 The predicate succeeds only when its mandatory conditions are satisfied. An authentic attestation associated with a different confidential VM does not authorize key use by the requesting workload. A valid historical measurement does not automatically authorize use after an incompatible protected policy or workload change. 11.19.9. WF-19.9 — User-Authorized Data-Access Scope DA-1908 defines the data-access authority granted by the user or authorized external key service. A non-limiting data-access authority may identify: user_authority_id; authorized_vm_identity; authorized_workload_identity; approved_measurement; data_scope; permitted_access_operation; authorized_purpose; policy_epoch; validity_interval; maximum_usage; revocation_reference. The permitted scope may restrict: (a) which encrypted object may be accessed; (b) which workload may access the object; (c) the allowed duration; (d) the permitted purpose; Das Expires 19 April 2027 [Page 789] Internet-Draft Protected AI Execution Finality October 2026 (e) applicable usage count; and (f) required authorization-state conditions. The AI agent cannot expand the protected scope simply by requesting a different object or presenting an application-level assertion that access is needed. 11.19.10. WF-19.10 — Protected Data-Access Authorization Predicate KE-1907 verifies the conditions required to enable access to protected data. An illustrative predicate is: Vdata = Vattest AND Puser AND Pscope AND Pworkload AND Pstate where: Vdata denotes the data-access authorization result; Vattest denotes satisfactory VM attestation; Puser verifies the user-controlled or user-authorized key authority; Pscope verifies the permitted data-access scope; Pworkload verifies the requesting workload identity; and Pstate verifies applicable validity, freshness, revocation, and protected authorization state. Successful Vdata permits only the bounded cryptographic access authorized by the applicable policy. It does not automatically generate an operation-specific execution capability. 11.19.11. WF-19.11 — Derived, Wrapped, or Session-Limited Key Release in the implementation described by enforcement point 85, the protected key-enablement component makes available a derived, wrapped, or session-limited key only when the required attestation and data-access authorization conditions succeed. The key may be restricted to: (a) a user-data scope; Das Expires 19 April 2027 [Page 790] Internet-Draft Protected AI Execution Finality October 2026 (b) workload identity; (c) validity interval; (d) protected authorization state; (e) encryption-object class; (f) authorized computation session; or (g) permitted cryptographic operation. An illustrative key-release authorization record comprises: key_release_id; user_authority_reference; attested_vm_identity; approved_measurement_reference; data_scope; key_version; session_reference; validity_interval; policy_epoch; nonce; protected_authentication. The root encryption key remains under user or user-authorized external authority and need not be disclosed to the AI agent. 11.19.12. WF-19.12 — Illustrative Protected Key Derivation A non-limiting implementation may derive a bounded data-access key using a suitable key-derivation function. For example: Ksession = KDF(Kroot, Context) Das Expires 19 April 2027 [Page 791] Internet-Draft Protected AI Execution Finality October 2026 where Context is an unambiguous encoding of permitted key-use attributes, including the user-data scope, workload identity, key version, session, and policy state where required. An implementation using a wrapped-key design may instead perform: WrappedKey = Wrap(Ktransport, Ksession, AssociatedContext) The confidential VM receives or obtains access to the bounded key only after successful required attestation and authority validation. The root key is not exported to the agent. These expressions are implementation examples. The specific construction must use an appropriate cryptographic key- derivation or wrapping method with the security properties required by its threat model. 11.19.13. WF-19.13 — Bounded Cryptographic Data Access Following successful protected key enablement, CV-1901 may decrypt the authorized information or obtain a bounded cryptographic operation. The access may comprise: (a) decrypting an approved document; (b) opening a protected agent-memory object; (c) accessing permitted connected-service data; (d) recovering an encrypted task state; (e) deriving a session-limited data key; or (f) performing another authorized data-access operation. The resulting plaintext or computation state remains governed by the relevant execution environment and applicable downstream effectuation boundaries. Permission to decrypt does not automatically permit the AI agent to disclose the plaintext outside the authorized environment. Das Expires 19 April 2027 [Page 792] Internet-Draft Protected AI Execution Finality October 2026 11.19.14. WF-19.14 — Dual Authorization for Data Access and External Effect in the implementation described by enforcement point 86, data-access authorization and execution-finality authorization are represented by distinct protected conditions. An illustrative relationship is: DataAccessAllowed = Vdata ExternalEffectAllowed = Veffect where Vdata governs bounded decryption or data use, and Veffect governs the separately proposed consequential operation. The architecture does not assume: Vdata implies Veffect. A successful decryption operation does not automatically create the operation-specific execution capability. The Finality Sink independently checks Veffect through the required capability and protected-state conditions. Where the proposed consequential operation requires access to protected data, both conditions may be necessary. A failure of either mandatory condition causes the corresponding protected operation to be withheld. 11.19.15. WF-19.15 — Candidate Act Generation AE-1902 processes data available within its authorized scope. The agent may prepare a consequential operation comprising: (a) an external network request; (b) a file export; (c) an email or messaging operation; (d) a credential-mediated service invocation; (e) a persistent record modification; Das Expires 19 April 2027 [Page 793] Internet-Draft Protected AI Execution Finality October 2026 (f) a database write; (g) a protected document publication; (h) a financial instruction; or (i) another externally effective operation. The proposed operation is classified as Candidate Act CA-1922. Generation of CA-1922 does not constitute authority to execute it. A user-approved data-decryption event does not independently authorize the resulting operation. 11.19.16. WF-19.16 — Interception and Non-Effective State IM-1909 intercepts CA-1922 before the corresponding governed effectuation boundary. HQ-1910 retains it in a Non-Effective State. An illustrative staging record comprises: candidate_act_id; vm_identity; workload_identity; data_access_reference; operation_class; destination_reference; payload_reference; policy_epoch; finality_sink_id; status = NON_EFFECTIVE. The proposed operation remains held while the Protected Enforcement Domain evaluates the required act-specific authority. Das Expires 19 April 2027 [Page 794] Internet-Draft Protected AI Execution Finality October 2026 Where the request contains mutable parameters, the interception mechanism retains an immutable representation or authenticated digest sufficient for later Finality Sink comparison. 11.19.17. WF-19.17 — Canonical Candidate Act Descriptor DC-1911 constructs a canonical Candidate Act Descriptor. The descriptor identifies the proposed consequential effect and its required authorization context. A non-limiting descriptor comprises: candidate_act_id; vm_identity; attested_measurement_reference; workload_identity; user_authority_reference; authorized_execution_scope; operation_class; destination_or_recipient; resource_identifier; effectuation_parameters; payload_digest; policy_epoch; revocation_epoch; nonce; expiry; finality_sink_id. The applicable Authority Object determines which fields are mandatory. Das Expires 19 April 2027 [Page 795] Internet-Draft Protected AI Execution Finality October 2026 An illustrative encoding is: Dact = Canon_v(VM, ATTEST, USER_SCOPE, ACT, TARGET, PARAM, EPOCH, NONCE, SINK) where the fields represent the required attested VM, user-authorized execution scope, concrete operation, destination, effectuation parameters, policy epoch, freshness, and Finality Sink identity. An illustrative digest is: hAct = H("DAS-USER-CVM-ACT-v1" || Encode(Dact)) The particular encoding and cryptographic algorithms are implementation choices. 11.19.18. WF-19.18 — Operation-Specific Authority Validation PED-1912 obtains the applicable operation-specific Authority Object. It validates: (a) actual Candidate Act operation class; (b) permitted user-authorized execution scope; (c) workload and VM identity; (d) required confidential-VM attestation; (e) destination or recipient; (f) operation parameters; (g) execution purpose; (h) current policy epoch; (i) revocation state; (j) nonce and freshness; (k) capability-use restrictions; and (l) intended effectuation boundary. An illustrative predicate is: Das Expires 19 April 2027 [Page 796] Internet-Draft Protected AI Execution Finality October 2026 Veffect = Pact AND Pscope AND Pattest AND Pcontext AND Pstate AND Psink where each term represents the corresponding mandatory authorization condition. Successful data-access authorization may form part of the context where required. However, operation-specific authority is independently evaluated. 11.19.19. WF-19.19 — Protected Authorization-State Handling Following successful validation, PED-1912 performs the protected state operation required for CA-1922. Possible operations include: (a) reserving a single-use execution grant; (b) registering or consuming a nonce; (c) validating the current policy epoch; (d) checking revocation state; (e) recording the Candidate Act digest; (f) reserving a bounded capability identifier; (g) updating a usage allowance; or (h) establishing another required protected authorization transition. Where an execution grant is single-use, protected state prevents unauthorized concurrent or repeated consumption. Where the required state transition cannot be established, the execution capability is withheld. 11.19.20. WF-19.20 — Protected Validation-Evidence Commitment EV-1915 commits validation evidence corresponding to CA-1922. An illustrative record comprises: receipt_id; Das Expires 19 April 2027 [Page 797] Internet-Draft Protected AI Execution Finality October 2026 candidate_act_id; candidate_act_descriptor_digest; attested_vm_reference; user_execution_scope_reference; authority_object_reference; policy_epoch; protected_state_transition; nonce; finality_sink_id; authorization_result; protected_authentication. The evidence may comprise a LAVR, AVR, authenticated validation receipt, sealed commitment, or another protected record. The evidence is committed before, or atomically with, release of the operation-specific capability, as required by enforcement point 84. An ordinary log created after data transmission does not substitute for the required pre-release evidence commitment. 11.19.21. WF-19.21 — Protected Execution-Finality Transaction The protected system coordinates authorization, required state transition, evidence commitment, and capability availability. An illustrative transaction is: (Snext, Ract, Ready) = CommitExecutionFinality(Dact, A, Scurrent, F) where: Snext denotes committed protected authorization state; Ract denotes committed validation evidence; Ready denotes completion of mandatory authorization prerequisites; Das Expires 19 April 2027 [Page 798] Internet-Draft Protected AI Execution Finality October 2026 Dact denotes the validated Candidate Act Descriptor; A denotes authenticated operation authority; Scurrent denotes prior protected state; and F denotes the Finality Sink. No valid operation-specific capability becomes available while a mandatory protected authorization or evidence dependency remains incomplete. This transaction does not imply that an arbitrary remote recipient participates in the same atomic transaction. 11.19.22. WF-19.22 — Cryptographically Bound Operation-Specific Capability in the implementation described by enforcement point 87, CR-1916 releases a capability cryptographically bound to: (a) the canonical Candidate Act Descriptor; (b) the attested confidential-VM measurement; (c) the user-authorized execution scope; (d) a policy epoch; (e) a nonce; and (f) the designated Finality Sink identity. A non-limiting capability is: Cact = Sign_skPED(Encode(hAct, hR, VMmeasurement, UserScope, Epoch, Nonce, Expiry, Sink)) where: Cact denotes the execution capability; hAct denotes the Candidate Act commitment; hR denotes the protected validation-evidence commitment; VMmeasurement denotes the required attested execution-context measurement; Das Expires 19 April 2027 [Page 799] Internet-Draft Protected AI Execution Finality October 2026 UserScope denotes permitted user-authorized effectuation scope; Epoch denotes the required protected policy epoch; Nonce denotes freshness; Expiry denotes the capability validity limit; and Sink denotes the designated Finality Sink. The capability may alternatively be represented through a MAC, sealed handle, protected capability table, or equivalent authenticated mechanism. The required cryptographic and protected-state bindings prevent unauthorized reuse outside the permitted context. 11.19.23. WF-19.23 — Independent Finality Sink Verification FS-1917 obtains the actual proposed consequential operation and corresponding execution capability. Before permitting the governed effect, the Finality Sink verifies: (a) capability authenticity; (b) required Candidate Act Descriptor correspondence; (c) attested VM measurement; (d) user-authorized execution scope; (e) operation type; (f) destination or recipient; (g) required policy epoch; (h) nonce and expiry; (i) protected validation-evidence commitment; (j) current required revocation and usage state; and (k) designated Finality Sink identity. The operation is permitted only when all mandatory checks succeed. Das Expires 19 April 2027 [Page 800] Internet-Draft Protected AI Execution Finality October 2026 A successful decryption event is not accepted as a substitute for execution-capability verification. A valid execution capability for one operation does not automatically authorize another operation. 11.19.24. WF-19.24 — Operation and Attestation Substitution Protection The system verifies that the actual operation remains consistent with the protected authorization. Potential substitutions include: (a) changing the destination; (b) altering the payload; (c) changing the recipient; (d) modifying the operation class; (e) replacing the attested VM; (f) changing a mandatory workload measurement; (g) changing the authorized user scope; (h) using a capability from another policy epoch; or (i) presenting the capability at another Finality Sink. Where an effectuation-relevant parameter or required attested state changes incompatibly after authorization, capability verification fails as required by enforcement point 87. The Finality Sink relies on authenticated actual-operation information rather than solely upon an agent-supplied description of the earlier approved operation. 11.19.25. WF-19.25 — Privacy-Preserving Execution Evidence in the implementation described by enforcement point 88, ER-1918 generates or maintains a cryptographically authenticated execution record establishing that the specified Candidate Act underwent protected authority validation and applicable Finality Sink verification. The record may contain: Das Expires 19 April 2027 [Page 801] Internet-Draft Protected AI Execution Finality October 2026 execution_record_id; candidate_act_descriptor_digest; protected_validation_receipt_digest; attested_vm_reference; authority_scope_commitment; capability_identifier; finality_sink_id; verification_result; protected_effectuation_status; policy_epoch; protected_authentication. The record is configured to support verification of the required enforcement condition without disclosing: (a) plaintext protected user data; (b) reusable credential material; or (c) the user-controlled root encryption key. The record may use authenticated commitments, signatures, hashes, protected references, or a suitable privacy-preserving cryptographic construction. The specific confidentiality and verification properties depend upon the selected implementation. 11.19.26. WF-19.26 — Distinction Between Authorization Evidence and Completion Evidence The system distinguishes evidence that a Candidate Act satisfied protected authorization requirements from evidence that the Finality Sink verified the capability and evidence that the external operation completed. An illustrative relationship is: Das Expires 19 April 2027 [Page 802] Internet-Draft Protected AI Execution Finality October 2026 Rvalidation — protected authority-validation evidence. Rverification — evidence of Finality Sink capability verification. Rcompletion — evidence of the specified effectuation outcome, where available. Rvalidation alone does not prove that the operation became effective. Rverification may establish successful sink verification without necessarily proving that a remote service completed a subsequent operation. Rcompletion reflects the completion semantics of the actual governed interface. Where an execution record is required to establish both validation and applicable Finality Sink verification, the system cryptographically associates the corresponding records with the same Candidate Act. The design does not falsely represent an uncertain external outcome as confirmed completion. 11.19.27. WF-19.27 — Root-Key Confidentiality During Evidence Verification The Finality Sink or external evidence verifier need not receive the root encryption key. The verification record may disclose authenticated commitments and bounded authorization references without revealing sensitive cryptographic material. For example, the record may demonstrate that: (a) the Candidate Act matched the protected operation descriptor; (b) the permitted execution scope was validated; (c) the required VM measurement was accepted; (d) protected validation evidence was committed; (e) the scoped capability was verified at the intended Finality Sink; and (f) the corresponding decision was authenticated. Das Expires 19 April 2027 [Page 803] Internet-Draft Protected AI Execution Finality October 2026 The verifier does not require unrestricted access to user plaintext or reusable credentials to establish these recorded enforcement facts. Where zero-knowledge evidence is used, the specified privacy properties must be provided by an actual appropriate proof construction. A conventional signed record is not automatically a zero-knowledge proof. 11.19.28. WF-19.28 — Separate Key-Access and Execution Revocation The architecture may maintain distinct revocation conditions for data access and external effectuation. For example: Data-access revocation: The user withdraws permission for the confidential VM to obtain new bounded access to specified encrypted information. Execution-authority revocation: The protected authority invalidates permission for a particular external operation or class of operations. Revocation of a data-access key does not automatically prove that plaintext already accessed by the workload has been erased. Similarly, a data-access authorization remaining valid does not override revoked downstream execution authority. The applicable protected controls enforce each revocation condition at the boundary they actually govern. Where the external operation requires both valid data-access authority and current execution authorization, failure of either mandatory condition causes withholding. 11.19.29. WF-19.29 — Confidential-VM Backup and Snapshot Protection in the implementation described by enforcement point 89, CV-1901 may be backed up or snapshotted. The backup may contain: (a) encrypted VM state; Das Expires 19 April 2027 [Page 804] Internet-Draft Protected AI Execution Finality October 2026 (b) protected agent memory; (c) encrypted task state; (d) locally cached key references; (e) pending Candidate Acts; (f) prior authorization references; (g) earlier policy-state information; and (h) application-level operation history. The system distinguishes restoration of the VM's computational state from restoration of current protected execution authority. An earlier backup is not treated as an authoritative source of current capability-consumption, revocation, or required freshness state. The protected execution state is reconciled independently of rollback-accessible backup contents. 11.19.30. WF-19.30 — Attested Recovery of the Confidential VM After restoration of an encrypted VM backup, protected agent-memory snapshot, or recovered confidential-VM instance, RC-1920 establishes the required authorized attested execution context. An illustrative recovery sequence includes: First, restore the permitted encrypted workload state. Second, identify the recovered confidential VM. Third, obtain a fresh hardware-rooted attestation or the appropriate current authenticated measurement. Fourth, verify the recovered workload and security configuration against the applicable approved conditions. Fifth, consult current user-authorized data-access scope. Sixth, reestablish the required protected key-enablement conditions. Seventh, obtain current execution-policy and revocation state. Das Expires 19 April 2027 [Page 805] Internet-Draft Protected AI Execution Finality October 2026 Eighth, reconcile authoritative capability-consumption state outside the restored snapshot. Ninth, identify pending, previously executed, and indeterminate Candidate Acts. Tenth, permit further governed effectuation only after the applicable current authorization and Finality Sink verification succeed. The recovered VM does not automatically inherit unrestricted decryption or execution authority from its earlier snapshot. 11.19.31. WF-19.31 — Protected Capability-Consumption State Continuity RS-1919 maintains the authoritative state required to prevent restoration of expired, consumed, or revoked capabilities. A representative state record comprises: capability_id; candidate_act_digest; authorized_vm_identity; policy_epoch; nonce; capability_status; remaining_uses; revocation_epoch; protected_state_version; effectuation_outcome_reference. The authoritative state may reside within a protected external state service, HSM-controlled store, hardware-backed counter, or another mechanism independent of rollback-accessible VM backups. The selected mechanism must maintain the state properties required by its threat model. Merely retaining a second copy of a file is insufficient when both copies can be restored to an earlier state by the relevant attacker. Das Expires 19 April 2027 [Page 806] Internet-Draft Protected AI Execution Finality October 2026 11.19.32. WF-19.32 — Snapshot-Rollback Replay Protection Consider an agent that has been authorized to perform a single externally effective operation. The Finality Sink verifies and consumes the corresponding capability. The VM is later restored from a snapshot created before capability consumption. The restored VM contains the earlier capability reference. The agent attempts to reuse that capability. The Finality Sink consults RS-1919 rather than relying exclusively upon the restored VM's local state. The authoritative record indicates that the capability has already been consumed, expired, or revoked. The operation is denied. Restoration of the confidential VM does not restore the previously invalidated execution capability. 11.19.33. WF-19.33 — User Root-Key Continuity During Recovery A user-controlled root encryption key may remain under user or external authority throughout VM recovery. Restoration of encrypted data does not require unrestricted transfer of the root key into the AI agent. Following successful current attestation and user-authorized data- access verification, KE-1907 may make available a new bounded derived key, wrapped key, session-limited key, or protected cryptographic access operation. The new data-access authorization remains subject to its own scope, validity, and revocation requirements. Reestablishing decryption authority does not automatically restore previously consumed or revoked external execution capabilities. The data-access and effectuation-authority domains remain separate after recovery. Das Expires 19 April 2027 [Page 807] Internet-Draft Protected AI Execution Finality October 2026 11.19.34. WF-19.34 — Illustrative Confidential AI-Agent Document Processing In one implementation, a user stores encrypted documents under a user-controlled encryption authority. An AI agent executes within a confidential VM. The agent requests access to one protected document for an authorized summarization task. HA-1905 generates the required confidential-VM attestation. KV-1906 verifies the approved measurement, workload identity, security configuration, and freshness. KE-1907 validates the user-authorized data-access scope. A bounded key or cryptographic access operation enables the confidential VM to process the approved document. The agent generates a summary. The agent subsequently proposes sending the summary to an external recipient. The proposed transmission becomes a Candidate Act. IM-1909 intercepts the request and retains it in a Non-Effective State. PED-1912 validates the recipient, payload scope, authorized purpose, current policy state, nonce, and designated network Finality Sink. The required validation evidence is committed. CR-1916 makes available the operation-specific capability. The network Finality Sink verifies the capability against the actual transmission. If the recipient and operation match the authorized scope, transmission is permitted. If the agent attempts to send the complete underlying document to an unauthorized recipient, the corresponding operation fails the required protected authorization or descriptor verification. Das Expires 19 April 2027 [Page 808] Internet-Draft Protected AI Execution Finality October 2026 The earlier permission to decrypt and summarize does not independently authorize disclosure of the document. 11.19.35. WF-19.35 — Illustrative Connected-Service Credential Operation An AI agent executing in a confidential VM receives bounded access to protected connected-service data. The data-access authorization permits the agent to inspect authorized information. The agent then proposes a credential-mediated operation that would modify an external account. The proposed operation is classified as a separate Candidate Act. The protected authority verifies the specific account, intended operation, recipient or resource, permitted purpose, and current authorization state. The credential-use Finality Sink verifies the corresponding scoped capability before protected credential application. Successful access to encrypted connected-service information does not permit unrestricted credential-mediated modification. The agent cannot transform possession of a data-access key into general execution authority over the connected service. 11.19.36. WF-19.36 — Illustrative VM Snapshot Recovery An AI agent has previously obtained authorization to export one protected file. The corresponding file-export Finality Sink verifies and consumes the capability. An earlier encrypted VM backup is later restored. The restored agent state still contains a reference to the former export capability. The recovery component establishes a fresh attested VM context and checks current data-access policy. It separately consults the authoritative protected capability- consumption state. Das Expires 19 April 2027 [Page 809] Internet-Draft Protected AI Execution Finality October 2026 The earlier export capability is already consumed. The restored VM may regain authorized access to data under a new bounded key-enablement condition, but it cannot reuse the consumed export capability. A new export requires its own applicable protected authorization. 11.19.37. WF-19.37 — Failure, Crash, and Recovery Handling The system distinguishes failures at the cryptographic data-access boundary and at the consequential effectuation boundary. Invalid VM attestation: Required bounded data-access key enablement is withheld. Invalid user data-access scope: The protected key-enablement component refuses access to data outside the authorized scope. Successful decryption but invalid Candidate Act authority: The consequential operation remains non-effective. Failure before protected validation-evidence commitment: No valid corresponding execution capability becomes available. Failure after evidence commitment but before capability delivery: The protected system reconciles committed authorization state before recovery. Failure after capability availability but before effectuation: The Finality Sink verifies current protected conditions before permitting the operation. Failure after possible external effect: The outcome may be confirmed or indeterminate depending upon available evidence. VM snapshot restoration: The recovered VM must satisfy the applicable attestation, data-access, and protected capability-state conditions. Root-key rotation: The system determines whether authorized wrapped or derived keys and encrypted objects remain accessible under the current key-management policy. Execution revocation: Previously consumed or revoked capabilities do not become valid merely because the VM or its encrypted data is restored. Das Expires 19 April 2027 [Page 810] Internet-Draft Protected AI Execution Finality October 2026 An indeterminate consequential operation is not automatically repeated when unauthorized duplication could result. 11.19.38. WF-19.38 — Alternative Technical Implementations User-held HSM implementation: The root key is retained within a user- controlled HSM, with bounded derived-key enablement for an attested confidential VM. External key-authority implementation: A user-authorized external service retains root key control and releases only authorized bounded cryptographic access. Wrapped-key implementation: The confidential VM obtains a wrapped or session-limited data-access key following required attestation verification. Cryptographic-operation implementation: Protected data access occurs through a bounded remote cryptographic operation rather than release of reusable plaintext key material. Confidential cloud implementation: The AI agent executes inside a cloud confidential VM with protected attestation and controlled external effectuation. Protected host-gateway implementation: A host-side gateway or trusted service verifies operation-specific execution capabilities. Hardware Finality Sink implementation: A SmartNIC, DPU, secure storage controller, or another hardware-associated effectuation interface performs required capability verification. Single-node implementation: The confidentiality and finality functions operate within one protected node while retaining their separate authorization conditions. Distributed implementation: The user root-key authority, confidential VM, PED, and Finality Sink operate on authenticated separate nodes. Rollback-resistant recovery implementation: Authoritative capability- consumption and revocation state is maintained outside guest backups and snapshots. Different implementations may provide different protection against key compromise, privileged host attacks, side channels, cloud-service compromise, rollback, or unauthorized bypass. Das Expires 19 April 2027 [Page 811] Internet-Draft Protected AI Execution Finality October 2026 The actual specified guarantees depend upon the selected implementation and threat model. 11.19.39. WF-19.39 — Failure and Fail-Closed Conditions The system withholds the corresponding data-access operation or consequential effect when a mandatory condition fails. Non-limiting conditions include: (a) missing user-authorized key authority; (b) invalid confidential-VM attestation; (c) incorrect workload identity; (d) unapproved software measurement; (e) invalid security configuration; (f) unauthorized data scope; (g) expired data-access grant; (h) revoked data-access permission; (i) invalid derived or wrapped key authorization; (j) unauthorized cryptographic key use; (k) missing Candidate Act Descriptor; (l) unauthorized operation class; (m) unauthorized destination or recipient; (n) required VM-measurement mismatch; (o) invalid operation-specific authority; (p) stale policy epoch; (q) invalid nonce or freshness state; (r) failed protected authorization-state transition; (s) failed validation-evidence commitment; Das Expires 19 April 2027 [Page 812] Internet-Draft Protected AI Execution Finality October 2026 (t) missing execution capability; (u) invalid capability authentication; (v) Finality Sink mismatch; (w) consumed or revoked execution capability; (x) unauthorized snapshot replay; (y) invalid recovered VM attestation; (z) failed required protected-state reconciliation; or (aa) unavailable mandatory effectuation-boundary verification. The corresponding operation remains non-effective, denied, or subject to separately authorized recovery. Failure of execution authorization does not automatically authorize release of protected plaintext as an alternative. 11.19.40. WF-19.40 — PHOSITA Verification and Negative Tests A person having ordinary skill in confidential computing, cryptographic key management, hardware attestation, cloud AI infrastructure, protected authorization, and distributed security may perform the following verification tests. Test 1 — Authorized data access: Provide valid attestation and user- authorized data scope. Confirm bounded data access. Test 2 — Attestation mismatch: Change a required VM measurement. Verify key enablement is refused. Test 3 — Wrong workload: Attempt key access from another confidential VM or workload. Required workload binding fails. Test 4 — Expired data-access grant: Present an expired grant. Protected key access is refused. Test 5 — Root-key confidentiality: Verify the AI agent cannot extract unrestricted user-controlled root key material through the authorized interface. Test 6 — Derived-key scope: Attempt access to data outside the bounded key's permitted scope. Access is denied. Das Expires 19 April 2027 [Page 813] Internet-Draft Protected AI Execution Finality October 2026 Test 7 — Successful decryption without execution authority: Permit bounded decryption, then attempt an external operation without an execution capability. The Finality Sink refuses the effect. Test 8 — Unauthorized recipient: Prepare an export to a recipient outside the permitted execution scope. Protected validation fails. Test 9 — Payload substitution: Authorize one payload and substitute a materially different required payload. Finality Sink verification fails. Test 10 — Attested-state substitution: Present a capability associated with another required VM measurement. Verification fails. Test 11 — Policy epoch mismatch: Present a capability under an incompatible current policy epoch. Effectuation is refused. Test 12 — Expired nonce: Reuse an invalid freshness value. Protected verification fails. Test 13 — Wrong Finality Sink: Present a capability to an unauthorized effectuation boundary. Sink binding fails. Test 14 — Missing validation evidence: Interrupt mandatory evidence commitment. No valid corresponding capability becomes available. Test 15 — Receipt confidentiality: Verify the protected execution record without exposing designated user plaintext or root-key material. Test 16 — Reusable credential disclosure: Inspect the authorized evidence output and verify reusable credentials are not disclosed by the record. Test 17 — Different Candidate Act: Reuse valid evidence for a different operation. Required act binding fails. Test 18 — Revoked execution grant: Revoke a previously issued execution capability. Subsequent affected effectuation is refused. Test 19 — Capability replay: Reuse a consumed single-use capability. Protected usage-state verification fails. Test 20 — Concurrent execution: Submit competing operations against a restricted grant. Protected state prevents unauthorized double consumption. Das Expires 19 April 2027 [Page 814] Internet-Draft Protected AI Execution Finality October 2026 Test 21 — VM snapshot rollback: Restore an earlier VM snapshot containing a previously consumed capability. The Finality Sink refuses replay. Test 22 — Backup recovery attestation: Restore an encrypted VM backup and verify that a required fresh attested execution context is established. Test 23 — Revocation after backup: Revoke a capability after a snapshot and restore the snapshot. The old capability remains revoked. Test 24 — Derived-key recovery: After authorized recovery, verify bounded data-access key release does not automatically reissue a consumed execution capability. Test 25 — Root-key rotation: Rotate the user-controlled root key and verify access according to the authorized key-version and recovery policy. Test 26 — Data-access revocation: Revoke future decryption authority and verify that affected new key-enablement operations fail. Test 27 — Independent effectuation authorization: Maintain valid data-access authority while revoking external operation authority. Confirm the prohibited effect remains blocked. Test 28 — Network bypass: Attempt to export protected information through an alternate accessible effectuation path. The governed effect remains subject to required enforcement. Test 29 — Single-node implementation: Verify distinguishable data- access and execution-finality authorization within one protected system. Test 30 — Distributed implementation: Place the root-key authority, confidential VM, PED, and Finality Sink on separate nodes. Verify authenticated state and capability consistency. Test 31 — Crash after possible external effect: Interrupt an operation after possible remote acceptance. Recovery preserves an accurate confirmed or indeterminate outcome. Test 32 — No automatic replay: Verify restoration does not automatically repeat an operation whose completion is uncertain. Das Expires 19 April 2027 [Page 815] Internet-Draft Protected AI Execution Finality October 2026 Test 33 — Protected-state tampering: Attempt to modify authoritative capability-consumption state from the guest VM. The protected mechanism rejects unauthorized modification. Test 34 — Confidentiality versus authority: Demonstrate that a valid data-access key enables bounded computation without independently enabling a consequential operation. These tests may employ confidential-VM development platforms, authenticated external key services, HSM test systems, synthetic encrypted datasets, mock AI agents, protected authorization-state stores, programmable Finality Sinks, snapshot-and-restore tools, and fault injection. The results establish only those guarantees actually demonstrated within the implementation's threat model. 11.19.41. WF-19.41 — Claim-Specific Technical Support Enforcement Point 84 — User-Controlled Confidential VM with Cryptographically Bound Execution Authority The workflow provides: (a) CV-1901 executing the AI agent while maintaining protected user data or task state; (b) DP-1903 encrypting protected information using user-controlled or user-authorized key material; (c) HA-1905 generating verifiable confidential-VM measurements; (d) KE-1907 conditioning bounded key or cryptographic data access on attestation and user-authorized scope; (e) AE-1902 preparing an externally effective operation using authorized data; (f) PED-1912 classifying that operation as a Candidate Act, holding it non-effective, and performing operation-specific validation; (g) EV-1915 committing the required validation evidence before or atomically with capability release; (h) FS-1917 independently verifying the operation-specific capability before effectuation; and Das Expires 19 April 2027 [Page 816] Internet-Draft Protected AI Execution Finality October 2026 (i) separate fail-closed conditions for required data-access and execution-finality authorization. Enforcement Point 85 — User-Held Root-Key and Attested Derived-Key Release WF-19.5 through WF-19.12 describe user or user-authorized root-key control, attested derived or wrapped key release, bounded session or data scope, and absence of unrestricted root-key disclosure to the agent. Enforcement Point 86 — Dual Authorization for Decryption and External Effect WF-19.14 establishes distinct cryptographic or protected-state conditions for bounded data access and consequential effectuation. The Finality Sink verifies the execution capability independently of successful decryption. Enforcement Point 87 — Cryptographic Binding of Confidential-VM State to Candidate Act WF-19.17, WF-19.22 and WF-19.24 describe binding the capability to the canonical Candidate Act Descriptor, attested VM measurement, user-authorized execution scope, policy epoch, nonce, and Finality Sink identity. Unauthorized modification of a mandatory effectuation parameter or required attested state causes verification failure. Enforcement Point 88 — Privacy-Preserving Execution Evidence WF-19.25 through WF-19.27 describe a cryptographically authenticated record establishing protected validation and applicable Finality Sink verification without disclosing protected plaintext, reusable credentials, or the user-controlled root encryption key. Enforcement Point 89 — Confidential-VM Recovery and Key-State Continuity WF-19.29 through WF-19.33 describe recovery of encrypted VM backups or agent-memory snapshots, reestablishment of authorized attested execution context, independent reconciliation of protected capability state, and rejection of previously expired, consumed, or revoked capabilities. Das Expires 19 April 2027 [Page 817] Internet-Draft Protected AI Execution Finality October 2026 11.19.42. WF-19.42 — Technical Effect The workflow establishes two protected, distinguishable authorization dependencies. The first governs whether a confidential AI workload may obtain bounded access to user-protected data. The second governs whether an operation generated using that data may become externally effective. The operative sequence includes: (a) encryption under user-controlled or user-authorized key material; (b) confidential-VM execution; (c) hardware-rooted attestation; (d) verification of approved workload and security state; (e) conditional bounded key enablement; (f) authorized data processing by the AI agent; (g) generation and interception of a Candidate Act; (h) maintenance of that act in a Non-Effective State; (i) act-specific protected authority validation; (j) protected authorization-state handling; (k) validation-evidence commitment; (l) operation-specific capability release; (m) independent verification at the Finality Sink; (n) controlled effectuation or fail-closed refusal; (o) privacy-preserving authentication of the enforcement record; and (p) recovery that reconciles protected execution authority independently of rollback-accessible VM state. Das Expires 19 April 2027 [Page 818] Internet-Draft Protected AI Execution Finality October 2026 This prevents a confidential AI workload from converting successful access to protected user data into unrestricted authority to disclose, transmit, export, or modify external resources. User-controlled root-key custody restricts who may enable access to protected information. Attestation restricts the workload environments eligible for bounded key use. Candidate Act-specific authorization governs what the AI agent may cause to happen outside its protected computational context. The Finality Sink enforces that authority at the actual consequential boundary. Rollback-resistant state prevents restoration of an earlier VM backup from reviving consumed or revoked execution authority. Computation is not authority to act. Permission to decrypt is not permission to disclose. User-controlled root-key access is not unrestricted execution authority. Attestation proves specified execution properties, not authorization for every external action. Restoration of protected data does not restore consumed execution capabilities. 11.20. WF-20 — Protected Derived-Key and Wrapped-Key Enablement, Attestation-Bound Key Release, Cryptographic Key-Use Finality, Separation of Data Access from Execution Authority, and Hardware-Enforced Credential and Effectuation Control 11.20.1. WF-20.1 — Technical Purpose This embodiment describes a computer-implemented protected key- authority architecture in which cryptographic key access, protected key use, data decryption, credential enablement, and externally effective operations are governed by distinguishable authorization conditions. The system provides a protected relationship among: (a) a user-controlled or user-authorized root-key authority; Das Expires 19 April 2027 [Page 819] Internet-Draft Protected AI Execution Finality October 2026 (b) an encrypted data object or protected computational state; (c) an authenticated execution environment; (d) a protected key-enablement mechanism; (e) a derived, wrapped, session-limited, or otherwise bounded cryptographic key; (f) a separate operation-specific execution authority; (g) a Protected Enforcement Domain; (h) a scoped execution capability; and (i) a Finality Sink controlling the consequential effect. The AI workload may obtain permission to decrypt designated information or use a bounded cryptographic key. However, possession of a key, access to decrypted information, or successful completion of a cryptographic operation does not independently confer authority to cause an externally effective operation. The system distinguishes at least three technical events: Key-enablement event: A protected key authority authorizes a specified cryptographic access operation or makes bounded key material available to an eligible execution context. Candidate Act authorization event: A Protected Enforcement Domain validates a proposed consequential operation against its applicable operation-specific authority and protected state. Effectuation event: A designated Finality Sink verifies the required scoped execution capability before allowing the consequential operation to become effective. The architecture prevents the automatic conversion of cryptographic data-access authority into unrestricted network transmission, file export, credential-mediated action, persistent-state modification, signing, deployment, or other externally effective activity. The system may be implemented within confidential-VM environments, protected key-management services, HSMs, secure enclaves, host-side credential brokers, hardware-associated execution interfaces, and distributed protected authorization systems. Das Expires 19 April 2027 [Page 820] Internet-Draft Protected AI Execution Finality October 2026 11.20.2. WF-20.2 — Participating Technical Components In one non-limiting embodiment, the system comprises: AE-2001 — Artificial-Intelligence Execution Environment An AI agent, model runtime, orchestration service, tool-execution process, confidential workload, or corresponding computational environment that may request protected cryptographic access and generate consequential operations. CV-2002 — Attested Confidential Execution Environment A confidential VM, secure enclave, TEE, or other protected execution environment providing the hardware-supported or authenticated execution-context properties required by the applicable embodiment. RK-2003 — Root-Key Authority A user-controlled or user-authorized cryptographic authority maintaining the applicable root encryption key. DA-2004 — Data-Access Authority Store An authenticated source of permitted user-data scopes, eligible workloads, attestation requirements, key-use conditions, and data- access validity state. HA-2005 — Hardware Attestation Component A component producing authenticated measurements of the execution environment and applicable protected software configuration. AV-2006 — Attestation Verification Component A mechanism configured to verify required hardware trust, workload identity, measurement, freshness, and policy conditions. KD-2007 — Protected Key-Derivation Component A cryptographic component configured to derive a bounded key from authorized key material and appropriate derivation context. KW-2008 — Protected Key-Wrapping Component A mechanism configured to protect a data-access or session key for use by an authorized recipient or protected execution context. Das Expires 19 April 2027 [Page 821] Internet-Draft Protected AI Execution Finality October 2026 KE-2009 — Protected Key-Enablement Gate A mechanism configured to authorize or withhold key release, key unwrapping, or an equivalent bounded cryptographic operation. KS-2010 — Protected Key Store A protected mechanism maintaining encryption keys, key references, permitted uses, rotation versions, revocation state, and other required key-management information. KB-2011 — Protected Credential or Key-Use Broker A service controlling consequential use of designated credentials, signing keys, cryptographic service identities, or other protected key-based authority. IM-2012 — Candidate Act Interception Component A component configured to intercept proposed consequential operations before their governed effectuation boundaries. HQ-2013 — Non-Effective Candidate Act Holding Mechanism A queue, protected buffer, pending operation record, inactive transmission request, or equivalent controlled staging mechanism. DC-2014 — Candidate Act Descriptor Component A mechanism configured to construct or verify the canonical representation of the concrete consequential operation. PED-2015 — Protected Enforcement Domain A protected authority component configured to validate operation- specific authorization independently of key-enablement success. PS-2016 — Protected Authorization-State Store A mechanism maintaining policy epochs, revocation state, nonce state, usage limits, protected validation commitments, and capability- consumption state. EV-2017 — Protected Validation-Evidence Component A mechanism configured to generate or commit protected evidence of the required operation-specific authorization. Das Expires 19 April 2027 [Page 822] Internet-Draft Protected AI Execution Finality October 2026 CR-2018 — Scoped Execution-Capability Mechanism A component configured to release or make available bounded authority for a particular consequential operation. FS-2019 — Key-Use or Credential Finality Sink An enforcement-controlled interface governing a cryptographic action or credential-mediated consequential effect, according to the selected embodiment. FS-2020 — External Effectuation Finality Sink A protected network, service, storage, financial, deployment, or hardware interface configured to verify the applicable operation- specific capability before allowing the externally effective consequence. HF-2021 — Protected Freshness and Key-State Component A protected mechanism maintaining key generations, usage counters, authorization versions, hardware freshness, or other state required for replay-resistant authorization. RC-2022 — Protected Recovery and Reconciliation Component A mechanism configured to restore bounded key authority and reconcile current capability state following failure, migration, snapshot restoration, or key rotation. OS-2023 — Protected Operation-Outcome Store A mechanism maintaining pending, authorized, denied, consumed, completed, revoked, and indeterminate operation records. The components may be implemented within one protected node or distributed among authenticated user, cloud, hardware, and effectuation systems. 11.20.3. WF-20.3 — Separation of Root-Key Control and AI Computation The system establishes a trust boundary between AE-2001 and RK-2003. The AI execution environment may request authorized access to encrypted information. However, it does not independently control the root encryption key or the protected key-authority policy. Das Expires 19 April 2027 [Page 823] Internet-Draft Protected AI Execution Finality October 2026 The root key remains within: (a) a user-controlled HSM; (b) a user-authorized external key-management service; (c) a protected user device; (d) a secure element; (e) a protected enterprise key authority; or (f) another authorized cryptographic custody arrangement. The ordinary AI workload cannot export the root key through the permitted key-enablement interface. A request to access encrypted data is evaluated against the applicable authorized scope. The requesting agent cannot expand that scope merely by selecting another object, changing an application-level identifier, or asserting that broader access is required. 11.20.4. WF-20.4 — Root-Key and Derived-Key Distinction The root encryption key and a derived data-access key perform distinguishable roles. The root key is retained as protected key-authority material. A derived key may be generated for a permitted data scope, workload, session, validity interval, or cryptographic purpose. A non-limiting representation is: Kderived = KDF(Kroot, Context) where: Kderived denotes the derived key; KDF denotes an appropriate cryptographic key-derivation function; Kroot denotes root key material controlled by the authorized key authority; and Context denotes an unambiguous derivation context. Das Expires 19 April 2027 [Page 824] Internet-Draft Protected AI Execution Finality October 2026 The context may include: user_authority_id; key_version; data_scope_id; workload_identity; authorized_purpose; session_id; policy_epoch; derivation_domain. The derivation function must provide the key-separation properties required by the selected implementation. A derived key is not assumed to be non-extractable merely because it was generated by a KDF. Its confidentiality depends upon how the derived key is protected, transported, stored, and used. 11.20.5. WF-20.5 — User-Authorized Key Scope DA-2004 maintains the applicable cryptographic data-access authorization. The authority may identify: (a) protected user-data scope; (b) eligible confidential VM; (c) approved software measurement; (d) permitted workload identity; (e) key-use purpose; (f) authorized data object or object class; (g) key version; Das Expires 19 April 2027 [Page 825] Internet-Draft Protected AI Execution Finality October 2026 (h) validity interval; (i) usage limit; (j) required hardware attestation; (k) user revocation state; and (l) protected authorization epoch. An illustrative authorization record comprises: data_access_authority_id; user_or_tenant_reference; authorized_workload_id; approved_measurement_reference; data_scope; permitted_key_operation; key_version; valid_from; valid_until; maximum_uses; policy_epoch; revocation_reference. The protected key-enablement mechanism verifies the required conditions before authorizing the cryptographic access operation. 11.20.6. WF-20.6 — Hardware Attestation Before Key Enablement HA-2005 produces a cryptographically verifiable measurement of CV- 2002. AV-2006 evaluates the attestation against the applicable approved trust conditions. The verification may include: Das Expires 19 April 2027 [Page 826] Internet-Draft Protected AI Execution Finality October 2026 (a) authenticity of the attestation report; (b) accepted hardware trust root; (c) confidential VM identity; (d) workload software measurement; (e) required security configuration; (f) measurement freshness; (g) authorized data-access scope; and (h) applicable policy and revocation state. An illustrative predicate is: Vattest = AuthenticReport AND ApprovedMeasurement AND CorrectWorkload AND ValidConfiguration AND FreshAttestation Where any mandatory predicate fails, the protected key-enablement mechanism withholds the corresponding bounded key access. Hardware attestation does not independently establish that every later operation generated by the attested workload is authorized. 11.20.7. WF-20.7 — Protected Key-Enablement Decision KE-2009 evaluates the key-access authority associated with a particular request. An illustrative predicate is: Vkey = Vattest AND UserAuthorityValid AND Das Expires 19 April 2027 [Page 827] Internet-Draft Protected AI Execution Finality October 2026 DataScopeValid AND KeyPurposeValid AND ProtectedStateValid where: Vkey denotes the protected key-enablement result; Vattest denotes required attestation validity; UserAuthorityValid verifies the corresponding user-controlled or user-authorized key authority; DataScopeValid verifies permitted protected information; KeyPurposeValid verifies the authorized cryptographic operation; and ProtectedStateValid verifies applicable freshness, revocation, usage, and protected-state conditions. If Vkey succeeds, the protected system may provide the permitted derived key, wrapped key, session-limited key, or bounded cryptographic operation. If Vkey fails, the requested key-enablement operation is withheld. Successful Vkey does not imply that a later consequential Candidate Act is authorized. 11.20.8. WF-20.8 — Derived-Key Release In one implementation, KD-2007 derives a key limited by the applicable authorized context. The resulting key may be made available only inside an attested confidential execution environment. The system may restrict: (a) permitted data class; (b) cryptographic purpose; (c) associated workload; (d) session lifetime; Das Expires 19 April 2027 [Page 828] Internet-Draft Protected AI Execution Finality October 2026 (e) key version; (f) protected authorization epoch; or (g) other applicable conditions. The implementation may use secure key import, protected memory, enclave-bound key provisioning, or equivalent controls. Where the derived key is exported into ordinary process memory, the system must account for the possibility that the process can copy or misuse it. Strong non-extractability requires an appropriate technical mechanism rather than a policy statement alone. 11.20.9. WF-20.9 — Wrapped-Key Enablement In another implementation, KW-2008 produces a wrapped key. A non-limiting expression is: Wkey = KeyWrap(Ktransport, Kdata, AssociatedContext) where: Wkey denotes the wrapped key representation; Ktransport denotes the protected key-encryption or wrapping key; Kdata denotes the bounded data-access key; and AssociatedContext denotes authenticated key-use context where supported by the selected wrapping construction. The receiving protected component verifies the required authorization before unwrapping or importing the key. The wrapping procedure prevents unauthorized disclosure of key material in transit under the selected cryptographic assumptions. However, wrapping alone does not enforce the permitted destination, operation, or effectuation scope after the key becomes available. The corresponding access-control or Finality Sink mechanism must enforce those separate requirements. Das Expires 19 April 2027 [Page 829] Internet-Draft Protected AI Execution Finality October 2026 11.20.10. WF-20.10 — Session-Limited Key Enablement A bounded key may be associated with an authenticated execution session. An illustrative session record comprises: session_id; attested_vm_identity; workload_identity; approved_measurement; data_scope; key_version; validity_interval; policy_epoch; revocation_epoch; key_usage_state. The protected component verifies that the current session satisfies the required conditions before performing the authorized cryptographic operation. An expired, revoked, or incompatible session does not retain authority merely because an earlier key-release request succeeded. Where keys are already resident inside a running workload, revocation of future key issuance does not by itself prove the resident key has become unusable. The implementation must use protected key-use controls, key retirement, session teardown, or another effective enforcement mechanism to provide stronger revocation guarantees. 11.20.11. WF-20.11 — Bounded Cryptographic Operation Without Key Export In an alternative implementation, the AI workload never receives reusable key material. Das Expires 19 April 2027 [Page 830] Internet-Draft Protected AI Execution Finality October 2026 Instead, it submits a cryptographic operation request to a protected key service. The request may seek: (a) decryption of an authorized object; (b) authentication of a permitted message; (c) signing of an approved artifact; (d) protected credential application; (e) unwrapping of a bounded key; or (f) another permitted cryptographic operation. The protected key service evaluates the applicable key-use conditions. Where the cryptographic operation itself is consequential, the operation is also subjected to the required execution-finality authorization before its effectuation. A service providing bounded decryption is not automatically authorized to sign, transmit, or publish the resulting plaintext. 11.20.12. WF-20.12 — Cryptographic Access Is Not External Execution Authority The architecture establishes separate authorization conditions: Vdata governs protected data or key access. Veffect governs the externally effective Candidate Act. An illustrative relationship is: DataAccessAllowed = Vdata EffectuationAllowed = Veffect The architecture does not assume: Vdata implies Veffect. For example, an agent may obtain a bounded decryption key to read a user document. Das Expires 19 April 2027 [Page 831] Internet-Draft Protected AI Execution Finality October 2026 That authorization does not automatically permit the agent to export the document. Similarly, an agent may be permitted to read a connected-service credential reference without acquiring permission to apply the credential to a different API operation. The protected external effect remains subject to operation-specific validation and Finality Sink verification. 11.20.13. WF-20.13 — Candidate Cryptographic Operation Where the key-use operation itself creates a governed consequential effect, the system classifies it as a Candidate Act. Examples include: (a) production artifact signing; (b) protected credential application; (c) release of a confidential encryption key to another domain; (d) creation of a cryptographically effective authorization token; (e) signing of a payment instruction; (f) activation of a protected service identity; or (g) another consequential protected key operation. A request merely to perform a permitted bounded decryption for internal computation may be governed by the data-access authorization alone where no separate execution-finality requirement applies. The applicable claim and selected security boundary determine whether a given cryptographic operation requires its own Candidate Act authorization. The system does not automatically classify every internal cryptographic calculation as an external effect. 11.20.14. WF-20.14 — Interception of the Consequential Operation AE-2001 prepares a proposed consequential operation involving protected information or cryptographic authority. IM-2012 intercepts the operation before the applicable Finality Sink. Das Expires 19 April 2027 [Page 832] Internet-Draft Protected AI Execution Finality October 2026 HQ-2013 maintains the corresponding Candidate Act in a Non-Effective State. A representative staging record comprises: candidate_act_id; requesting_workload_id; cryptographic_access_reference; requested_operation; target_resource; destination; payload_reference; key_scope_reference; policy_epoch; finality_sink_id; status = NON_EFFECTIVE. The proposed operation remains pending until the protected execution- finality conditions succeed. The previous key-release decision does not independently advance the Candidate Act into an effective state. 11.20.15. WF-20.15 — Candidate Act Descriptor Formation DC-2014 constructs a machine-readable descriptor representing the concrete consequential operation. An illustrative descriptor comprises: candidate_act_id; attested_vm_identity; workload_identity; data_access_authority_reference; Das Expires 19 April 2027 [Page 833] Internet-Draft Protected AI Execution Finality October 2026 key_scope_reference; requested_operation_class; actual_destination; resource_identifier; payload_digest; credential_or_key_usage_class; user_execution_scope; policy_epoch; revocation_epoch; nonce; expiry; finality_sink_id. Only the applicable mandatory fields are included in the protected authorization decision. The descriptor binds the operation to its effectuation context. The protected system does not treat a valid key identifier as a complete substitute for the Candidate Act Descriptor. 11.20.16. WF-20.16 — Canonical Candidate Act Representation An illustrative canonical representation is: Dkeyact = Canon_v(W, KEY_SCOPE, ACT, TARGET, PARAM, AUTH, EPOCH, SINK) where: Dkeyact denotes the Candidate Act Descriptor; W denotes authenticated workload context; KEY_SCOPE denotes the associated cryptographic-access scope; ACT denotes the proposed consequential operation; Das Expires 19 April 2027 [Page 834] Internet-Draft Protected AI Execution Finality October 2026 TARGET denotes the destination or protected resource; PARAM denotes the effectuation-relevant parameters; AUTH denotes applicable user and operation authority references; EPOCH denotes required policy and authorization-state versions; and SINK denotes the designated Finality Sink. An illustrative digest is: hKeyAct = H("DAS-KEY-EFFECTUATION-v1" || Encode(Dkeyact)) The selected encoding must preserve distinctions required by the authorization. A digest binding does not eliminate the need to verify the actual operation parameters at the applicable effectuation boundary. 11.20.17. WF-20.17 — Protected Operation-Specific Authority PED-2015 obtains the Authority Object applicable to the proposed operation. The authority may specify: (a) eligible workload identity; (b) authorized operation class; (c) permitted key-use purpose; (d) permitted destination; (e) applicable tenant or user scope; (f) approved credential use; (g) required confidential-VM attestation; (h) approved policy epoch; (i) nonce or capability usage limits; (j) revocation state; (k) protected execution context; and Das Expires 19 April 2027 [Page 835] Internet-Draft Protected AI Execution Finality October 2026 (l) designated Finality Sink. The PED validates the operation independently of the earlier key- access decision. A valid data-access grant may satisfy one contextual predicate. It does not override a failed operation-specific authority predicate. 11.20.18. WF-20.18 — Operation-Specific Authorization Predicate An illustrative protected authorization expression is: Veffect = Poperation AND Pscope AND Pdestination AND Pcontext AND Pstate AND Psink where: Veffect denotes the operation-specific authorization result; Poperation verifies the requested consequential operation; Pscope verifies user and key-use scope; Pdestination verifies the actual destination or recipient; Pcontext verifies required attestation or workload context; Pstate verifies policy, revocation, freshness, and protected usage state; and Psink verifies the designated Finality Sink. Where a cryptographic key is required for the effect, the PED may additionally verify the associated key-access authority. Das Expires 19 April 2027 [Page 836] Internet-Draft Protected AI Execution Finality October 2026 Failure of any mandatory predicate prevents release of the corresponding execution capability. 11.20.19. WF-20.19 — Protected State Transition Following successful protected validation, PED-2015 performs the required authorization-state operation. The operation may comprise: (a) reserving a single-use key-effectuation grant; (b) consuming or registering a nonce; (c) verifying current key and policy epochs; (d) checking revocation state; (e) registering the Candidate Act digest; (f) reserving a bounded capability identifier; (g) updating a protected usage allowance; or (h) recording the intended Finality Sink. The required state transition is controlled by PS-2016. Where a single-use grant is required, incompatible concurrent attempts cannot independently consume the same authorization. A failed required state transition prevents successful execution- capability availability. 11.20.20. WF-20.20 — Protected Validation-Evidence Commitment EV-2017 generates or commits protected evidence associated with the Candidate Act. An illustrative record comprises: receipt_id; candidate_act_id; candidate_act_digest; attested_workload_reference; Das Expires 19 April 2027 [Page 837] Internet-Draft Protected AI Execution Finality October 2026 authorized_key_scope; operation_authority_reference; protected_state_transition; policy_epoch; nonce; finality_sink_id; decision; protected_authentication. Where enforcement point 84 and its selected execution-finality embodiment apply, the protected validation evidence is committed before, or atomically with, release of the operation-specific execution capability. The record is not merely an after-the-fact logging artifact. An ordinary key-management audit entry does not independently establish that the concrete external operation satisfied all required finality predicates. 11.20.21. WF-20.21 — Operation-Specific Execution Capability CR-2018 makes available the bounded execution capability following successful protected authorization. An illustrative capability contains or references: capability_id; candidate_act_digest; authorized_operation; workload_identity; attested_vm_reference; user_execution_scope; key_usage_scope; Das Expires 19 April 2027 [Page 838] Internet-Draft Protected AI Execution Finality October 2026 destination; policy_epoch; revocation_epoch; nonce; expiry; usage_limit; validation_receipt_digest; finality_sink_id. A non-limiting cryptographic representation is: Ckeyact = Sign_skPED(Encode(hKeyAct, hReceipt, Scope, VM, Epoch, Nonce, Expiry, Sink)) The particular capability format may comprise a signed artifact, MAC- authenticated permit, sealed handle, protected state-table entry, or authenticated hardware-enablement condition. The capability does not become a general bearer credential merely because it can be transported between components. The Finality Sink enforces the required operation, state, context, usage, and sink bindings. 11.20.22. WF-20.22 — Protected Key-Use Finality Sink FS-2019 may control a consequential cryptographic operation. Examples include: (a) use of a production signing key; (b) application of a protected service credential; (c) a bounded key-unwrapping operation; (d) release of key material across a protected domain boundary; (e) generation of an authenticated production artifact; or (f) issuance of a credential-dependent external instruction. Das Expires 19 April 2027 [Page 839] Internet-Draft Protected AI Execution Finality October 2026 The protected key-use Finality Sink verifies the corresponding operation-specific authorization before permitting the governed cryptographic effect. A key residing inside an HSM does not independently provide such finality control if an authorized caller can use the key without satisfying the required Candidate Act-specific predicates. 11.20.23. WF-20.23 — External Effectuation Finality Sink FS-2020 controls the downstream consequential effect. The interface may comprise: (a) a network egress controller; (b) an API gateway; (c) a credential broker; (d) a file-export interface; (e) a storage-commit service; (f) a payment or transaction interface; (g) a deployment controller; (h) a SmartNIC or DPU enforcement component; or (i) another protected effectuation boundary. The Finality Sink reconstructs or verifies the actual operation. It checks the execution capability and required protected state immediately before permitting the governed effect. An earlier decryption operation or cryptographic key-use approval does not independently replace the Finality Sink verification. 11.20.24. WF-20.24 — Relationship Between Key-Use and External Finality The architecture may have one or two separately governed consequential boundaries. In a first implementation, an authenticated key-use operation is the governed effect, and FS-2019 performs the required finality verification. Das Expires 19 April 2027 [Page 840] Internet-Draft Protected AI Execution Finality October 2026 In a second implementation, a protected key-use operation is an intermediate stage, while the actual external transmission, transaction, or storage modification is separately governed at FS- 2020. In a third implementation, both key use and downstream effectuation require distinct bounded authorizations. The selected claim and Authority Object determine which structure is mandatory. The system does not automatically assume that authorizing protected credential application also authorizes any later independently governed downstream operation. Where both boundaries are required, each applies its own effectuation-specific verification. 11.20.25. WF-20.25 — Governance-Key Isolation In the related embodiment corresponding to enforcement point 81, cryptographic key material used for protected governance or execution-capability issuance remains within a protected governance boundary. The AI compute process communicates with the governance component through an authenticated interface. The process cannot obtain unrestricted access to the governance key. The protected component may use such key material to authenticate an operation-scoped execution capability only after required protected validation. The system distinguishes governance signing keys from user-data encryption keys. The two key classes may have different owners, purposes, rotation procedures, authorization conditions, and security boundaries. A valid user-data key is not thereby a valid governance capability- issuance key. 11.20.26. WF-20.26 — Attestation-Dependent Governance Key Use Where governance key use depends upon a confidential governance-node attestation, the protected issuance procedure verifies the required attestation state. Das Expires 19 April 2027 [Page 841] Internet-Draft Protected AI Execution Finality October 2026 Applicable conditions may include: (a) registered governance identity; (b) approved launch measurement; (c) approved firmware measurement; (d) protected software configuration; (e) policy version; (f) attestation freshness; and (g) revocation state. If a required governance-node measurement becomes invalid, the corresponding protected component refuses further dependent capability issuance until successful revalidation. This issuance restriction is distinguishable from revocation of already issued capabilities. Where outstanding capabilities must also become invalid, the applicable Finality Sink must enforce the required current governance-state or revocation condition. 11.20.27. WF-20.27 — Hardware-Freshness Binding In the related embodiment corresponding to enforcement point 83, execution capability validity may depend upon hardware-freshness state. The state may comprise: (a) trusted monotonic counter; (b) secure boot epoch; (c) protected clock; (d) device sequence; or (e) hardware-attested nonce. The protected authority binds the applicable state to the issued capability. Das Expires 19 April 2027 [Page 842] Internet-Draft Protected AI Execution Finality October 2026 The designated Finality Sink verifies the mandatory freshness condition before effectuation. Restoration or replay of previously valid authorization material fails when the current protected hardware state no longer corresponds to the capability. A freshness value stored only within rollback-accessible guest memory does not independently establish rollback resistance. 11.20.28. WF-20.28 — Revocation of Data-Access Keys The user or authorized root-key authority may revoke future protected data-access authorization. The protected key-enablement component verifies the current applicable revocation state before enabling affected new key operations. Revocation may prevent: (a) further derived-key issuance; (b) additional key unwrapping; (c) new session-key enablement; (d) new protected decryption operations; or (e) other key-use operations still subject to the protected enforcement boundary. If plaintext or reusable key material was previously exported into ordinary workload memory, the key authority cannot assume that revocation retroactively erases all copies. Stronger revocation requires technical control of the retained key material or the relevant cryptographic operation. 11.20.29. WF-20.29 — Revocation of External Execution Authority Operation-specific execution authorization is separately revocable. A valid data-access key may remain available while the protected authority revokes permission to perform a particular external operation. Das Expires 19 April 2027 [Page 843] Internet-Draft Protected AI Execution Finality October 2026 The Finality Sink enforces the required current revocation and policy conditions. For example, an agent may continue reading an authorized private document while being prohibited from transmitting its contents to a newly revoked destination. The external effect remains blocked even if the underlying document is decryptable. This illustrates the independence of key-access authority and effectuation authority. 11.20.30. WF-20.30 — Key Rotation and Version Continuity The root-key or data-access key authority may rotate protected key material. A protected key-version record may comprise: key_id; key_version; authorized_data_scope; valid_from; valid_until; revocation_state; wrapping_reference; protected_authority_generation. The protected system verifies the key version applicable to the encrypted data and the authorized access request. A changed key version does not automatically invalidate every separately governed execution capability unless the key version is a mandatory binding or the protected policy requires that result. Likewise, successful key rotation does not restore consumed execution authorization. Key lifecycle and operation-capability lifecycle remain separately governed. Das Expires 19 April 2027 [Page 844] Internet-Draft Protected AI Execution Finality October 2026 11.20.31. WF-20.31 — Snapshot and Backup Recovery The system may restore an encrypted confidential VM backup, agent- memory snapshot, or recovered execution instance. The restored environment must reestablish the attestation and user- authorized data-access conditions required by its current protected policy. The recovery procedure may include: (a) fresh confidential-VM attestation; (b) workload identity verification; (c) user-authorized key-access validation; (d) appropriate bounded key rederivation or unwrapping; (e) current key-version verification; (f) protected policy and revocation checks; (g) authoritative execution-capability state reconciliation; and (h) identification of pending and previously attempted operations. Restoring an encrypted VM image does not automatically restore previously consumed, expired, or revoked execution capabilities. The authoritative protected consumption and revocation state remains separate from rollback-accessible backup contents. 11.20.32. WF-20.32 — Key-State and Capability-State Separation The architecture maintains separate protected state for key access and execution authority where required. A non-limiting key-access state comprises: key_authority_id; key_version; data_scope; authorized_workload; Das Expires 19 April 2027 [Page 845] Internet-Draft Protected AI Execution Finality October 2026 attestation_reference; validity_interval; key_usage_status. A non-limiting execution state comprises: candidate_act_id; execution_capability_id; authorized_operation; finality_sink_id; policy_epoch; nonce; capability_consumption_status; effectuation_outcome. The two state mechanisms may reside in one protected service, but their authorization semantics remain distinct. Restoration of a key-access session does not automatically restore an earlier execution-capability usage allowance. 11.20.33. WF-20.33 — Crash Between Authorization and Effectuation The system distinguishes failures occurring at different stages. Failure before attestation validation: The protected key-enablement operation is refused when required attestation cannot be established. Failure after attestation but before key enablement: The system verifies current authority before any renewed key operation. Failure after data decryption but before Candidate Act validation: The external operation remains non-effective. Failure during protected state or evidence commitment: No valid corresponding execution capability becomes available when a mandatory commitment has failed. Das Expires 19 April 2027 [Page 846] Internet-Draft Protected AI Execution Finality October 2026 Failure after capability release but before Finality Sink verification: The Finality Sink verifies current state before permitting effectuation. Failure after possible remote effectuation: The operation may remain indeterminate until reliable completion evidence is available. Failure after VM snapshot restoration: Current protected key and execution state are independently reconciled. An indeterminate effect is not automatically repeated merely because the AI workload was restarted. 11.20.34. WF-20.34 — Illustrative User-Controlled Encrypted Data Access A user maintains encrypted enterprise documents under a user- controlled root-key authority. An AI agent executes inside a confidential VM. The agent requests bounded access to a specified document. The confidential VM supplies the required hardware attestation. The protected key authority verifies the VM identity, workload measurement, authorized data scope, freshness, and current data- access policy. A derived or wrapped data-access key becomes available within the permitted protected context. The agent decrypts the document and performs the authorized internal computation. The agent subsequently prepares an external network request containing protected information. The request is classified as a Candidate Act and held in a Non- Effective State. The PED validates the concrete operation, recipient, purpose, protected scope, policy state, and intended network Finality Sink. Required validation evidence is committed, and the appropriate scoped execution capability becomes available. The network Finality Sink verifies the actual request and capability. Das Expires 19 April 2027 [Page 847] Internet-Draft Protected AI Execution Finality October 2026 If the proposed external transmission is not authorized, the request remains blocked despite successful decryption. 11.20.35. WF-20.35 — Illustrative Protected Credential Broker An AI agent prepares an operation requiring a protected service credential. The credential is held by a protected credential broker rather than exposed for unrestricted use by the agent. The agent submits a proposed operation identifying: (a) requested service; (b) operation class; (c) destination; (d) parameters; (e) authorized purpose; and (f) required credential scope. The corresponding operation is treated as a Candidate Act. PED-2015 validates the applicable Authority Object and operation context. The protected system commits required validation evidence and releases an act-scoped capability. KB-2011 or the appropriate Finality Sink verifies the capability before applying the protected credential. Where a separate downstream effectuation boundary is governed, that boundary independently verifies its applicable authorization. The agent cannot convert knowledge of a credential reference into unrestricted permission to use the underlying service identity. 11.20.36. WF-20.36 — Illustrative Signing-Key Finality An autonomous coding agent generates an executable artifact. A production signing key is maintained within a protected HSM or governance service. Das Expires 19 April 2027 [Page 848] Internet-Draft Protected AI Execution Finality October 2026 The agent requests signing of the artifact. The request is classified as a consequential Candidate Act where protected production signing is the governed effect. The Candidate Act Descriptor identifies the artifact digest, key-use purpose, permitted signing identity, policy epoch, nonce, and signing Finality Sink. The PED validates the corresponding authorization. Required protected state and evidence operations are completed. A scoped signing capability becomes available. The protected signing interface verifies the capability against the actual artifact and authorized key-use context. Only the permitted signature operation is performed. Possession of the artifact, a key identifier, or ordinary access to the signing-service interface does not independently authorize production signing. 11.20.37. WF-20.37 — Illustrative Snapshot Replay An AI agent obtains a valid data-access key inside a confidential VM. It also receives a single-use execution capability permitting one protected external operation. The Finality Sink verifies and consumes the execution capability. An earlier VM snapshot is then restored. The restored workload may contain its earlier data-access session and a copy or reference to the consumed execution capability. The key authority applies the current attestation, key-version, and data-access conditions. Separately, the Finality Sink consults current protected capability- consumption state. The previously consumed execution capability remains invalid. The restored VM cannot reuse the capability merely because its guest memory represents an earlier authorization state. Das Expires 19 April 2027 [Page 849] Internet-Draft Protected AI Execution Finality October 2026 11.20.38. WF-20.38 — Alternative Technical Implementations User-controlled HSM: Root-key material remains in user-controlled hardware while bounded data-access keys are made available to attested workloads. External key-authority service: A user-authorized key service provides derived, wrapped, or session-limited key access. Confidential-VM implementation: Protected data is decrypted only within an attested confidential execution environment. Remote cryptographic-operation implementation: The protected key never leaves the key service; the service performs only authorized cryptographic operations. Protected credential-broker implementation: Credential application remains dependent upon operation-specific capability verification. Protected signing implementation: An HSM verifies act-bound authority before performing production signing. SmartNIC or DPU implementation: A separate protected hardware Finality Sink controls external network transmission after cryptographic authorization. Single-node implementation: Key access, protected authorization, and Finality Sink functions operate within one protected node while retaining their separate required checks. Distributed implementation: User root-key authority, confidential VM, PED, key-use broker, and external Finality Sink operate across authenticated services. Rollback-resistant implementation: Required capability-consumption and nonce state remains outside the snapshot-restorable workload. Different implementations provide different confidentiality, key- extraction resistance, revocation, and effectuation guarantees. The particular security properties depend upon the implemented trust boundaries. 11.20.39. WF-20.39 — Failure and Fail-Closed Conditions The system withholds the corresponding protected operation when a mandatory condition is absent, invalid, expired, revoked, inconsistent, replayed, or unverifiable. Das Expires 19 April 2027 [Page 850] Internet-Draft Protected AI Execution Finality October 2026 Non-limiting conditions include: (a) invalid root-key authority; (b) missing user data-access permission; (c) unapproved confidential-VM measurement; (d) invalid attestation; (e) workload identity mismatch; (f) unauthorized data scope; (g) invalid key purpose; (h) expired data-access authorization; (i) revoked key version; (j) invalid key-wrap authentication; (k) unauthorized key export; (l) prohibited cryptographic operation; (m) missing Candidate Act Descriptor; (n) unauthorized external operation; (o) destination mismatch; (p) invalid operation-specific Authority Object; (q) failed protected-state transition; (r) failed required evidence commitment; (s) missing execution capability; (t) capability authentication failure; (u) policy epoch mismatch; (v) invalid nonce; (w) consumed or revoked capability; Das Expires 19 April 2027 [Page 851] Internet-Draft Protected AI Execution Finality October 2026 (x) Finality Sink mismatch; (y) invalid governance-node attestation; (z) hardware-freshness mismatch; or (aa) unavailable mandatory protected verification. Failure of key authorization does not create execution authority. Failure of execution authorization does not authorize an unrestricted cryptographic fallback. 11.20.40. WF-20.40 — PHOSITA Verification and Negative Tests A person having ordinary skill in confidential computing, key management, HSM architecture, applied cryptography, credential security, cloud AI infrastructure, and protected execution may verify the following. Test 1 — Authorized derived key: Supply valid attestation and data- access authority. Confirm bounded derived-key availability. Test 2 — Invalid attestation: Present an unapproved VM measurement. Key enablement is refused. Test 3 — Wrong workload: Attempt key access from another workload. Required workload binding fails. Test 4 — Unauthorized data scope: Request a protected object outside the permitted scope. Key access is denied. Test 5 — Root-key export: Attempt unrestricted extraction of the user-controlled root key through the agent interface. The protected boundary refuses the operation. Test 6 — Wrapped-key substitution: Replace the wrapped key or required authenticated context. Protected unwrapping fails. Test 7 — Key-purpose mismatch: Attempt a signing operation using authority permitted only for data decryption. The applicable key-use control refuses it. Test 8 — Expired session: Present an expired session-limited key authorization. New protected key enablement is denied. Das Expires 19 April 2027 [Page 852] Internet-Draft Protected AI Execution Finality October 2026 Test 9 — Key revocation: Revoke an applicable key-access authorization. Further affected protected cryptographic operations are refused. Test 10 — Valid decryption without effectuation: Successfully decrypt authorized data, then attempt external transmission without an execution capability. The Finality Sink refuses the transmission. Test 11 — Unauthorized destination: Obtain valid data access and request an effect outside the permitted destination scope. Operation authorization fails. Test 12 — Candidate Act substitution: Validate one concrete operation and present different mandatory parameters. The Finality Sink rejects the mismatch. Test 13 — Credential misuse: Attempt credential application outside the approved operation. The protected credential Finality Sink refuses it. Test 14 — Unauthorized signing: Request protected signing of an artifact not associated with the approved capability. The signing operation is denied. Test 15 — Missing validation evidence: Interrupt a mandatory protected evidence-commitment operation. No valid corresponding execution capability becomes available. Test 16 — Wrong Finality Sink: Present an operation-specific capability at another unauthorized effectuation interface. Required sink binding fails. Test 17 — Capability replay: Reuse a consumed single-use execution capability. The protected state mechanism refuses reuse. Test 18 — Concurrent consumption: Submit competing operations against one restricted capability. Protected state prevents unauthorized duplicate consumption. Test 19 — Key rotation: Rotate the root or derived-key version and verify enforcement of applicable key-version conditions. Test 20 — Snapshot restoration: Restore an earlier confidential VM snapshot containing a previously consumed capability. Current protected capability state refuses replay. Das Expires 19 April 2027 [Page 853] Internet-Draft Protected AI Execution Finality October 2026 Test 21 — Governance-key isolation: Attempt unrestricted governance signing-key access from the AI process. The protected boundary refuses access. Test 22 — Invalid governance attestation: Alter a mandatory governance-node measurement. Dependent capability issuance is refused pending revalidation. Test 23 — Hardware freshness: Replay authorization under an incompatible protected hardware generation. Required freshness verification fails. Test 24 — Receipt privacy: Verify enforcement evidence without disclosure of designated plaintext or root-key material. Test 25 — Crash after possible effect: Interrupt a credential- mediated operation after possible execution. Recovery preserves confirmed or indeterminate outcome state. Test 26 — Separate protected boundaries: Verify that valid key access does not bypass a separately required network, credential, storage, or payment Finality Sink. Test 27 — Alternative execution path: Attempt the governed consequence through an interface bypassing ordinary key-access checks. the specified finality architecture blocks or equivalently mediates the effectuation path. Test 28 — Independent key and execution revocation: Revoke execution authority while leaving data-access authority valid. Confirm that decryption remains governed by its policy but the unauthorized external effect is withheld. Test 29 — Single-node implementation: Verify independent key-enable and act-effectuation predicates within one protected controller. Test 30 — Distributed implementation: Verify authenticated state, key-use authority, and operation-specific Finality Sink correspondence across separate protected components. 11.20.41. WF-20.41 — Claim-Specific Technical Support Enforcement Point 84 — User-Controlled Confidential VM with Cryptographically Bound Execution Authority Das Expires 19 April 2027 [Page 854] Internet-Draft Protected AI Execution Finality October 2026 WF-20.3 through WF-20.24 describe protected data encryption, confidential-VM attestation, bounded key enablement, independent Candidate Act authorization, required evidence commitment, and separate Finality Sink verification. Enforcement Point 85 — User-Held Root-Key and Attested Derived-Key Release WF-20.4 through WF-20.11 describe root-key custody, derived and wrapped key access, session limits, authorized data scopes, workload identity, attestation predicates, and avoidance of unrestricted root- key disclosure. Enforcement Point 86 — Dual Authorization for Decryption and External Effect WF-20.12 through WF-20.24 describe separate data-access and external- effect authorization states and independent downstream capability verification. Enforcement Point 87 — Cryptographic Binding of Confidential-VM State to Candidate Act WF-20.15, WF-20.16, WF-20.21, and WF-20.23 describe binding the capability to the Candidate Act, attested execution state, authorized scope, policy epoch, nonce, and Finality Sink. Enforcement Point 88 — Privacy-Preserving Execution Evidence WF-20.20 and WF-20.24, together with WF-20.38, address authenticated evidence and privacy-preserving verification arrangements. The complete evidence-record specification remains in WF-19.25 through WF-19.27. Enforcement Point 89 — Confidential-VM Recovery and Key-State Continuity WF-20.30 through WF-20.33 describe fresh attestation, bounded key reenablement, protected capability-state reconciliation, and replay prevention after restoration. Enforcement Point 79 — Confidential Governance VM and Hardware- Attested SmartNIC Finality WF-20.25 through WF-20.27 provide the related governance-key, attestation, hardware freshness, and protected issuer conditions. The complete SmartNIC/DPU effectuation workflow remains in WF-18. Das Expires 19 April 2027 [Page 855] Internet-Draft Protected AI Execution Finality October 2026 Enforcement Point 80 — Confidential VM Attestation Object WF-20.26 uses the applicable authenticated governance measurement, with the complete attestation-object construction and verification in WF-18. Enforcement Point 81 — Confidential Governance-Key Isolation WF-20.25 describes protected governance key custody and controlled capability issuance without unrestricted key access by the ordinary AI compute process. Enforcement Point 82 — Attestation Change Disables Capability Issuance WF-20.26 distinguishes invalid governance measurement, denial of further dependent capability issuance, and independent revocation checks for outstanding capabilities. Enforcement Point 83 — Cryptographically Bound Hardware Freshness WF-20.27 describes hardware-freshness binding and rejection of replay when the current protected hardware state does not satisfy the applicable capability. 11.20.42. WF-20.42 — Technical Effect The workflow establishes distinct protected authorization dependencies for cryptographic access and consequential execution. The operative sequence comprises: (a) user or user-authorized root-key control; (b) encryption of protected information; (c) authenticated confidential-workload attestation; (d) verification of bounded user-data access; (e) derived, wrapped, session-limited, or protected-operation key enablement; (f) authorized internal use of protected data; (g) generation of a consequential Candidate Act; (h) mandatory interception and Non-Effective State holding; Das Expires 19 April 2027 [Page 856] Internet-Draft Protected AI Execution Finality October 2026 (i) construction of an operation-specific descriptor; (j) independent protected execution-authority validation; (k) required protected-state handling; (l) protected validation-evidence commitment; (m) release of a scoped execution capability; (n) independent verification at the appropriate key-use or external- effectuation Finality Sink; (o) controlled effectuation or fail-closed refusal; and (p) protected revocation, consumption, freshness, and recovery state. The architecture prevents a requesting AI workload from treating possession of a valid decryption key, successful data access, access to a protected signing endpoint, or an authenticated credential reference as unrestricted authority to perform an externally effective operation. The protected key-enable component controls whether the specified cryptographic access is permitted. The Protected Enforcement Domain controls whether the concrete consequential operation is authorized. The Finality Sink enforces the corresponding execution capability at the actual governed effectuation boundary. Computation is not authority to act. A decryption key is not an execution capability. Permission to decrypt is not permission to disclose. Possession of a signing key reference is not permission to sign any artifact. A protected credential is not unrestricted authority to use the corresponding service. Key enablement and final effectuation remain independently governed where required. Das Expires 19 April 2027 [Page 857] Internet-Draft Protected AI Execution Finality October 2026 11.21. WF-21 — Hardware Finality Latch, NIC/SmartNIC/DPU Enforcement, Protected DMA and Network Admission, Capability-Dependent Hardware Effectuation, and Fail-Closed Revocation 11.21.1. WF-21.1 — Technical Purpose This embodiment describes a computer-implemented hardware-assisted protected execution-finality architecture for controlling consequential operations generated by artificial-intelligence agents, autonomous workloads, accelerator-based computations, or associated execution environments. The system establishes a protected enforcement dependency between the authority to perform a consequential operation and the hardware interface capable of making that operation effective. A proposed consequential operation is classified as a Candidate Act. The Candidate Act remains in a Non-Effective State until the applicable Protected Enforcement Domain validates the required operation-specific authorization conditions, completes mandatory protected-state and evidence-commitment operations, and releases or makes available a scoped execution capability. A hardware-associated Finality Sink verifies the capability against the actual operation and its required authorization state before permitting the operation to cross its designated execution-finality boundary. The hardware implementation may control: (a) network packet transmission; (b) DMA or RDMA admission; (c) accelerator-to-host data export; (d) accelerator-to-accelerator transfers; (e) fabric-switch forwarding; (f) protected memory access; (g) credential-mediated transmission; (h) storage-controller commitment; (i) device-control commands; Das Expires 19 April 2027 [Page 858] Internet-Draft Protected AI Execution Finality October 2026 (j) optical-path enablement; or (k) another consequential operation crossing a hardware-controlled boundary. The Hardware Finality Latch remains disabled or non-admitting until the required capability-dependent verification succeeds. The architecture distinguishes ordinary hardware connectivity, trusted computation, hardware attestation, authorization of a particular Candidate Act, and final hardware effectuation. The fact that a workload can generate a packet, DMA descriptor, tool command, or accelerator output does not independently confer authority to deliver it through the governed hardware interface. 11.21.2. WF-21.2 — Participating Technical Components In one non-limiting implementation, the system comprises: AE-2101 — Artificial-Intelligence Compute Environment An AI agent, model runtime, accelerator workload, GPU server, autonomous process, or corresponding component configured to produce a proposed consequential operation. CI-2102 — Candidate Act Interception Component A mandatory software, firmware, hypervisor, kernel, or hardware- associated mechanism configured to intercept the proposed operation before the governed effect. HQ-2103 — Non-Effective Operation Holding Mechanism A controlled buffer, pending request, inactive DMA descriptor, disabled forwarding entry, sealed output region, or equivalent representation retaining a Candidate Act in a Non-Effective State. DC-2104 — Candidate Act Descriptor Component A mechanism configured to construct or verify the effectuation- relevant representation of the proposed operation. PED-2105 — Protected Enforcement Domain A protected authority component configured to validate the applicable Candidate Act, Authority Object, runtime context, policy state, and designated Finality Sink. Das Expires 19 April 2027 [Page 859] Internet-Draft Protected AI Execution Finality October 2026 AS-2106 — Protected Authority Store An authenticated source of authorized operation classes, workload identities, destinations, protected data scopes, hardware boundaries, and applicable policy conditions. PS-2107 — Protected Execution-State Store A mechanism maintaining required nonce state, authorization epochs, protected usage counters, revocation versions, hardware freshness, capability consumption, and validation commitments. EV-2108 — Protected Validation-Evidence Component A mechanism configured to generate or commit a LAVR, AVR, Fabric Transfer LAVR, authenticated receipt, sealed commitment, or equivalent protected validation evidence where required. CR-2109 — Scoped Execution-Capability Mechanism A protected component configured to generate, register, derive, release, or activate the execution-enabling capability corresponding to the validated Candidate Act. HL-2110 — Hardware Finality Latch A hardware-controlled execution-enablement mechanism preventing the governed operation from crossing the designated finality boundary without required capability verification. HC-2111 — Hardware Enforcement Controller A NIC, SmartNIC, DPU, GPU controller, FPGA, ASIC, protected gateway processor, accelerator interconnect controller, secure memory controller, or equivalent hardware-associated enforcement component. FS-2112 — Hardware Finality Sink An effectuation interface configured to verify the capability and mandatory protected state immediately before admitting, forwarding, switching, copying, transmitting, storing, or otherwise effectuating the Candidate Act. HF-2113 — Hardware Freshness Mechanism A trusted monotonic counter, device epoch, fabric sequence number, secure clock, protected switch-state generation, or equivalent protected freshness source. Das Expires 19 April 2027 [Page 860] Internet-Draft Protected AI Execution Finality October 2026 WM-2114 — Optional Out-of-Band Monitoring Domain An isolated monitoring component configured to produce authenticated monitoring-state information where the selected embodiment requires watchdog-dependent authorization. GV-2115 — Optional Confidential Governance Environment A confidential VM or separately protected governance node configured to provide authenticated authorization services and applicable hardware-rooted attestation. FM-2116 — Authenticated Fabric-Management Interface A protected communication mechanism configured to distribute bounded capability state or authorized hardware-control entries. RV-2117 — Protected Revocation Controller A mechanism configured to advance required authorization versions, invalidate capability use, and prevent subsequent effectuation under superseded mandatory state. OS-2118 — Protected Effectuation Outcome Store A mechanism maintaining pending, authorized, reserved, admitted, completed, revoked, and indeterminate operation outcomes. RC-2119 — Recovery and State-Reconciliation Component A protected mechanism configured to reconcile authorization and effectuation state after device reset, workload restoration, communication failure, or interrupted transfer. The components may be implemented within one protected hardware device, a single server, or distributed across authenticated physical and virtualized systems. Not every described component is required in every claimed variant. 11.21.3. WF-21.3 — Definition of Hardware Finality Latch A Hardware Finality Latch is a hardware-enforced implementation of a Finality Latch that prevents a governed Candidate Act from crossing its Execution-Finality Boundary unless the required scoped execution capability or corresponding protected enablement condition is verified. Das Expires 19 April 2027 [Page 861] Internet-Draft Protected AI Execution Finality October 2026 The latch may control: (a) queue admission; (b) DMA mapping; (c) memory access; (d) network forwarding; (e) storage commitment; (f) accelerator egress; (g) RF activation; (h) optical modulation; or (i) another consequential interface. The Hardware Finality Latch may be implemented within a processor, accelerator, controller, NIC, SmartNIC, DPU, FPGA, ASIC, or equivalent enforcement component. The existence of a hardware device does not independently establish that an effectuation path is non-bypassable. The latch must actually control the specified consequential interface. 11.21.4. WF-21.4 — Distinction Among PED, Finality Gate, Finality Sink, and Latch The embodiment distinguishes four functions. Protected Enforcement Domain: Validates protected authority, applicable policies, Candidate Act conditions, and required authorization state. Finality Gate: The mandatory mediation arrangement preventing the Candidate Act from bypassing the required protected finality sequence. Finality Sink: The actual effectuation interface at which the required operation-specific capability is verified before the governed effect. Das Expires 19 April 2027 [Page 862] Internet-Draft Protected AI Execution Finality October 2026 Hardware Finality Latch: The hardware-controlled enabling or admission condition preventing the operation from crossing the boundary until required verification succeeds. These functions may be performed by physically separate devices or integrated within one protected controller. For example, a DPU may contain both a protected authorization component and a forwarding Finality Sink. In that arrangement, functional integration does not eliminate the requirements for protected authority validation, capability-dependent verification, and non-bypassable hardware effectuation control. 11.21.5. WF-21.5 — Establishment of the Hardware Enforcement Boundary Before permitting governed operations, the system identifies the physical or virtualized interfaces capable of producing the specified effect. For network transmission, the boundary may comprise a protected NIC transmit queue or DPU forwarding pipeline. For accelerator data export, the boundary may comprise a controlled accelerator memory interface, DMA queue, or interconnect admission point. For protected storage, the boundary may comprise a storage controller or commit-admission interface. For device actuation, the boundary may comprise a protected controller enablement interface. The system ensures that the AI workload cannot perform the governed operation through another accessible path bypassing the required verification. The particular implementation may use: (a) IOMMU restrictions; (b) protected DMA mappings; (c) device queue ownership; (d) trusted firmware; (e) hardware forwarding controls; Das Expires 19 April 2027 [Page 863] Internet-Draft Protected AI Execution Finality October 2026 (f) hypervisor-managed device access; (g) protected memory apertures; (h) access-control registers; or (i) equivalent mechanisms. Non-bypassability must be demonstrated against the actual threat model and all relevant accessible effectuation paths. 11.21.6. WF-21.6 — Candidate Act Generation AE-2101 performs an AI computation and prepares a consequential operation. The operation may comprise: (a) a packet or network request; (b) a DMA transfer; (c) a tensor export; (d) a fabric routing instruction; (e) a credential-mediated request; (f) an accelerator output; (g) a protected storage operation; or (h) an actuation command. The operation is classified as Candidate Hardware-Effectuation Act CA-2120. The AI workload may generate all necessary parameters to describe the operation. However, generation of the operation does not itself satisfy protected execution authorization. 11.21.7. WF-21.7 — Interception and Non-Effective State CI-2102 intercepts or controls CA-2120 before the hardware effectuation boundary. Das Expires 19 April 2027 [Page 864] Internet-Draft Protected AI Execution Finality October 2026 HQ-2103 maintains the operation in a Non-Effective State. The held representation may comprise: candidate_act_id; source_workload_id; operation_class; source_interface; target_interface; payload_reference; operation_parameters; policy_epoch; hardware_sink_id; status = NON_EFFECTIVE. In a network implementation, the packet or request may be held before protected transmit-queue admission. In a DMA implementation, the DMA descriptor may remain inactive. In an accelerator implementation, the output may remain within a protected memory region or blocked transfer queue. In a switching implementation, the forwarding entry may remain disabled. The operation cannot become effective through the governed interface merely because it has been placed into a queue. 11.21.8. WF-21.8 — Candidate Act Descriptor Formation DC-2104 constructs a canonical Candidate Act Descriptor. A non-limiting descriptor includes: candidate_act_id; source_workload_identity; Das Expires 19 April 2027 [Page 865] Internet-Draft Protected AI Execution Finality October 2026 operation_class; source_domain; destination_domain; target_resource; operation_parameters; payload_digest; data_class; authorized_route; hardware_queue_or_interface; policy_epoch; revocation_epoch; nonce; expiry; hardware_freshness_reference; finality_sink_identity. Only attributes required by the particular Authority Object or embodiment are mandatory. The descriptor represents the concrete operation whose hardware effectuation is requested. 11.21.9. WF-21.9 — Canonical Hardware Operation Representation In one illustrative cryptographic implementation: Dhardware = Canon_v(SRC, ACT, DST, DATA, PARAM, ROUTE, EPOCH, FRESH, SINK) where: Dhardware denotes the canonical Candidate Act Descriptor; SRC denotes the requesting workload or source domain; Das Expires 19 April 2027 [Page 866] Internet-Draft Protected AI Execution Finality October 2026 ACT denotes the consequential operation; DST denotes the destination or target; DATA denotes the relevant payload or data-class representation; PARAM denotes effectuation-relevant parameters; ROUTE denotes the required network, memory, or fabric route; EPOCH denotes applicable protected policy and revocation state; FRESH denotes required hardware-freshness conditions; and SINK denotes the designated hardware Finality Sink. An illustrative digest is: hHardware = H("DAS-HARDWARE-ACT-v1" || Encode(Dhardware)) The particular encoding, hash algorithm, and domain-separation label are implementation choices. The hardware Finality Sink must use a representation or protected comparison procedure consistent with the authorization semantics. 11.21.10. WF-21.10 — Acquisition of Hardware Effectuation Authority PED-2105 obtains or resolves the applicable Authority Object. The authority may identify: (a) authorized workload; (b) permitted consequential operation; (c) protected data classification; (d) source and destination restrictions; (e) permitted fabric or network route; (f) authorized hardware interface; (g) applicable runtime conditions; (h) policy epoch; Das Expires 19 April 2027 [Page 867] Internet-Draft Protected AI Execution Finality October 2026 (i) revocation conditions; (j) usage limits; (k) hardware-freshness requirements; and (l) designated Finality Sink. Where the operation is a fabric transfer, the applicable source- domain, destination-domain, workload-graph, transfer-envelope, and route conditions are validated. Where the operation depends upon a hardware watchdog, the required monitoring-state version is separately validated. Where the capability issuer is an attested confidential governance node, the required issuer attestation is validated. These are different authorization conditions and need not all apply to every hardware embodiment. 11.21.11. WF-21.11 — Protected Authorization Predicate An illustrative authorization predicate is: Vhardware = Pact AND Psource AND Ptarget AND Pscope AND Pstate AND Psink where: Vhardware denotes the protected authorization result; Pact verifies the Candidate Act; Psource verifies required workload or source-domain authority; Ptarget verifies destination or receiving-domain authority; Pscope verifies authorized operation, data, resource, route, or transfer scope; Pstate verifies protected policy, revocation, usage, and freshness conditions; and Psink verifies the designated hardware Finality Sink. Additional attestation, monitoring, or hardware-integrity predicates are incorporated where required by the selected embodiment. Das Expires 19 April 2027 [Page 868] Internet-Draft Protected AI Execution Finality October 2026 Failure of any mandatory predicate prevents issuance or availability of the corresponding execution capability. 11.21.12. WF-21.12 — Protected Authorization-State Transition Upon successful validation, PED-2105 performs the protected-state operation required by CA-2120. Such an operation may comprise: (a) reserving a single-use authorization; (b) registering a nonce; (c) verifying a protected policy epoch; (d) checking revocation state; (e) allocating a bounded transfer quota; (f) recording a permitted route; (g) binding the current hardware epoch; (h) registering the Candidate Act Descriptor commitment; or (i) reserving an operation-specific capability. Where a restricted grant is subject to concurrent requests, protected state prevents unauthorized double consumption. An incomplete mandatory state transition does not establish successful execution authorization. 11.21.13. WF-21.13 — Protected Validation-Evidence Commitment EV-2108 generates or commits the required validation evidence. An illustrative record comprises: receipt_id; candidate_act_id; descriptor_digest; authority_reference; Das Expires 19 April 2027 [Page 869] Internet-Draft Protected AI Execution Finality October 2026 validated_predicate_reference; protected_state_transition; policy_epoch; nonce; hardware_freshness_reference; finality_sink_id; authorization_result; protected_authentication. The evidence may comprise a LAVR, Fabric Transfer LAVR, AVR, authenticated commitment, or another supported protected validation record. Where pre-effectuation evidence commitment is a required condition, the record is committed before, or atomically with, capability availability. A packet log, DMA completion record, or hardware monitoring report created after effectuation does not substitute for required protected pre-release validation evidence. 11.21.14. WF-21.14 — Scoped Hardware Execution Capability CR-2109 generates or makes available the capability corresponding to the validated Candidate Act. The capability may contain or securely reference: capability_id; candidate_act_descriptor_digest; authorized_operation; source_identity; destination_identity; permitted_data_class; authorized_route; Das Expires 19 April 2027 [Page 870] Internet-Draft Protected AI Execution Finality October 2026 authorized_queue_or_interface; policy_epoch; revocation_epoch; nonce; expiry; remaining_usage; hardware_freshness_reference; validation_evidence_digest; finality_sink_id. The capability may be implemented as: (a) a signed authorization artifact; (b) a MAC-authenticated permit; (c) a protected hardware lookup entry; (d) an authenticated DMA descriptor; (e) a queue-pair capability; (f) a protected forwarding grant; (g) a sealed capability handle; or (h) an equivalent bounded hardware-enablement condition. The representation alone does not establish a non-bearer capability unless the required context, operation, state, usage, and sink restrictions are enforced. 11.21.15. WF-21.15 — Illustrative Capability Authentication An illustrative cryptographic capability representation is: Chardware = Sign_skPED(Encode(hHardware, hReceipt, Scope, Epoch, Freshness, Nonce, Expiry, Sink)) where: Das Expires 19 April 2027 [Page 871] Internet-Draft Protected AI Execution Finality October 2026 Chardware denotes the scoped execution capability; hHardware denotes the Candidate Act Descriptor digest; hReceipt denotes the required validation-evidence commitment; Scope denotes authorized operation scope; Epoch denotes applicable protected policy state; Freshness denotes required hardware freshness; Nonce denotes a freshness or anti-replay value; Expiry denotes the authorized validity limit; and Sink denotes the designated hardware Finality Sink. The selected implementation may authenticate a protected capability- table entry instead of performing an asymmetric signature verification for every hardware transfer. The mandatory security property is that the actual hardware effect remains dependent upon the valid bounded authorization. 11.21.16. WF-21.16 — Capability Delivery to the Hardware Controller The capability may be delivered through: (a) an authenticated device-management channel; (b) protected inter-processor communication; (c) a DPU management interface; (d) a SmartNIC control plane; (e) a protected PCIe control queue; (f) an HSM-authenticated message; (g) a protected local capability table; or (h) an equivalent authenticated interface. The hardware controller verifies the origin and integrity of capability information. Das Expires 19 April 2027 [Page 872] Internet-Draft Protected AI Execution Finality October 2026 A requesting workload cannot install unrestricted forwarding or DMA permissions merely by writing ordinary device metadata. The controller associates the capability with the actual governed operation. 11.21.17. WF-21.17 — Hardware Finality Sink Verification Immediately before permitting the governed operation, FS-2112 verifies the applicable execution capability. The verification includes required checks of: (a) capability authenticity; (b) actual operation correspondence; (c) source identity; (d) destination identity; (e) operation scope; (f) relevant data classification; (g) route or queue restrictions; (h) protected policy state; (i) revocation state; (j) nonce and expiry; (k) hardware-freshness state; (l) validation-evidence commitment; (m) usage or consumption state; and (n) Finality Sink identity. The Finality Sink uses the actual hardware-visible operation attributes or authenticated references sufficient to reconstruct the relevant authorization context. An earlier software allow decision does not independently establish successful hardware Finality Sink verification. Das Expires 19 April 2027 [Page 873] Internet-Draft Protected AI Execution Finality October 2026 11.21.18. WF-21.18 — Hardware Effectuation Predicate An illustrative predicate is: PermitHardwareEffect = Auth(C) AND Match(C,Dactual) AND ScopeValid(C) AND StateValid(C) AND FreshnessValid(C) AND SinkValid(C) where: C denotes the scoped capability; Dactual denotes the actual operation presented for hardware effectuation; Auth verifies capability authenticity; Match verifies required descriptor correspondence; ScopeValid verifies permitted source, destination, resource, and operation scope; StateValid verifies required policy, revocation, receipt, and usage conditions; FreshnessValid verifies mandatory hardware-freshness state; and SinkValid verifies the designated hardware Finality Sink. The controlled hardware effect is permitted only when all mandatory predicates succeed. 11.21.19. WF-21.19 — Hardware Finality Latch State Machine The hardware latch may implement the following states: DISABLED; Das Expires 19 April 2027 [Page 874] Internet-Draft Protected AI Execution Finality October 2026 PENDING_AUTHORIZATION; AUTHORIZED; ARMED; EFFECTUATION_IN_PROGRESS; CONSUMED; REVOKED; FAULT; INDETERMINATE. An illustrative progression is: DISABLED → PENDING_AUTHORIZATION → AUTHORIZED → ARMED → EFFECTUATION_IN_PROGRESS → CONSUMED. The transition into ARMED is permitted only when the required protected capability and state verify. A revoked or invalid capability cannot arm the latch for the affected operation. Where the interface supports partial transfers, EFFECTUATION_IN_PROGRESS may be associated with bounded units or windows. A failed operation does not automatically restore a consumed capability to an unused state. 11.21.20. WF-21.20 — Hardware-Latched DMA and Accelerator Transfer For an accelerator or DMA implementation, the proposed transfer may be represented by an inactive DMA descriptor or protected transfer queue entry. The PED validates: (a) source domain; (b) destination domain; (c) data classification; Das Expires 19 April 2027 [Page 875] Internet-Draft Protected AI Execution Finality October 2026 (d) memory-region restrictions; (e) transfer size; (f) authorized route; (g) workload graph; (h) policy state; and (i) applicable protected freshness. The system commits required validation evidence and makes available a Fabric Transfer Capability. The hardware-associated Finality Sink verifies the capability before activating the relevant descriptor, queue, memory mapping, fabric lane, or interconnect operation. An unauthorized transfer remains non-admitting. The source accelerator's ability to address a memory location or generate a DMA descriptor does not independently authorize the corresponding cross-domain transfer. 11.21.21. WF-21.21 — SmartNIC and DPU Network Forwarding In one implementation, HC-2111 comprises a SmartNIC or DPU controlling network egress. The agent or workload prepares a packet, service request, or data- transfer operation. The request remains pending before the governed forwarding boundary. The applicable protected authority validates the concrete operation and releases a scoped capability. The SmartNIC or DPU installs or verifies the corresponding authenticated forwarding authorization. The Finality Sink compares the actual packet flow, destination, protected workload identity, operation scope, and mandatory state against the capability. The packet or transfer is admitted only within the authorized scope. Das Expires 19 April 2027 [Page 876] Internet-Draft Protected AI Execution Finality October 2026 A generic host firewall allow rule does not replace the capability- dependent protected finality sequence where that sequence is mandatory. 11.21.22. WF-21.22 — Hardware Fast-Path Verification In a latency-sensitive implementation, the PED performs comparatively higher-cost authorization outside the fast transfer path. The fast path uses a protected local authorization entry. An illustrative entry contains: capability_id; source_identity; destination_identity; operation_class; route_id; queue_id; maximum_bytes; remaining_bytes; policy_epoch; hardware_epoch; next_sequence; expiry; protected_validation_reference; status. The hardware interface performs a bounded local verification before admitting the operation. The fast path may use protected lookup tables, sequence counters, short-lived authentication tags, route grants, or equivalent authenticated admission mechanisms. Das Expires 19 April 2027 [Page 877] Internet-Draft Protected AI Execution Finality October 2026 Line-rate performance is an implementation objective and must be established through actual hardware evaluation. The architecture does not claim a measured latency or throughput without corresponding test evidence. 11.21.23. WF-21.23 — Continuous and Windowed Transfer Authorization Where the governed operation comprises a stream, the system may divide it into: (a) packets; (b) DMA blocks; (c) memory pages; (d) tensor slices; (e) transfer windows; or (f) other bounded transfer units. A protected capability or authenticated rolling state governs each required unit or window. The hardware Finality Sink verifies that the unit remains within the permitted destination, route, size, policy, sequence, and usage conditions. A capability permitting one bounded transfer does not automatically authorize subsequent unauthorized units. The enforcement granularity is determined under the specified enforcement profile and protected Authority Object. 11.21.24. WF-21.24 — Hardware-Freshness and Replay Protection HF-2113 provides a protected freshness reference. The reference may comprise: (a) a monotonic counter; (b) a secure boot epoch; (c) a fabric sequence number; Das Expires 19 April 2027 [Page 878] Internet-Draft Protected AI Execution Finality October 2026 (d) an authenticated device generation; (e) a trusted clock; (f) protected switch state; or (g) a hardware-attested nonce. The scoped capability is associated with the required freshness value. The Finality Sink verifies the current protected freshness before effectuation. An earlier capability is rejected when its mandatory freshness binding is incompatible with the current protected state. A device reset or workload snapshot does not automatically restore an earlier authorization generation. 11.21.25. WF-21.25 — Optional Confidential Governance Node Where the embodiment of enforcement point 79 applies, GV-2115 comprises a governance compute node executing within a confidential virtual-machine environment. The governance node provides an authenticated attestation record identifying the approved workload measurement and protected execution configuration. The PED verifies the attestation against: (a) an approved hardware trust root; (b) registered governance identity; and (c) applicable protected policy state. An operation-scoped execution capability depends upon both the required acceptable governance-node attestation and successful Candidate Act authorization. The authenticated fabric-management path conveys capability information to the hardware effectuation controller. The hardware Finality Sink verifies the required issuing-governance attestation state as well as the concrete operation. Das Expires 19 April 2027 [Page 879] Internet-Draft Protected AI Execution Finality October 2026 Successful confidential-VM attestation does not independently authorize transmission. 11.21.26. WF-21.26 — Optional Hardware Watchdog Interlock Where enforcement point 62–67 apply, WM-2114 provides an out-of-band monitoring-state record. The record identifies: (a) workload identity; (b) monitoring-state version; (c) validity condition; and (d) enforcement-state indicator. The PED evaluates the monitoring state as a required input to the operation-specific authorization. The capability is bound to the applicable monitoring-state version when required. The hardware Finality Sink checks the required current monitoring state before effectuation. If the monitoring-state condition becomes invalid, stale, revoked, inconsistent, or unavailable, the affected operation is refused. A watchdog alert alone is not treated as hardware prevention unless the actual Finality Sink enforces the corresponding state. 11.21.27. WF-21.27 — Protected Revocation Fence RV-2117 maintains the required revocation or authorization-generation state. Revocation may arise from: (a) policy withdrawal; (b) capability expiry; (c) protected monitoring-state invalidation; (d) governance attestation failure; Das Expires 19 April 2027 [Page 880] Internet-Draft Protected AI Execution Finality October 2026 (e) source-workload revocation; (f) destination authorization withdrawal; (g) hardware integrity failure; or (h) another protected security condition. The revocation mechanism updates the corresponding protected state. The Finality Sink rejects a capability when its required state is no longer acceptable. A revoked operation cannot be reenabled merely by retaining an earlier software allow decision or replaying a previous hardware- control message. 11.21.28. WF-21.28 — Protection Against Hardware Bypass Paths The system identifies alternative effectuation paths available to the AI workload. Potential bypass paths include: (a) direct access to another NIC; (b) direct DMA through an unprotected device; (c) use of an alternate accelerator transfer interface; (d) manipulation of a hardware queue; (e) unauthorized device passthrough; (f) host-mediated copying through an unprotected path; (g) direct connection to a different network namespace; (h) modification of firmware-controlled forwarding rules; or (i) another accessible interface capable of producing the same governed effect. The implementation restricts or equivalently mediates the paths within its specified protection scope. A hardware latch controlling only one path does not establish protection against another unrestricted path. Das Expires 19 April 2027 [Page 881] Internet-Draft Protected AI Execution Finality October 2026 the specified non-bypassable property must be supported by actual path coverage. 11.21.29. WF-21.29 — Independent Hardware Effectuation Verification The hardware controller performs the required verification independently of the requesting AI process. The AI workload may provide a request identifier, descriptor reference, or capability representation. However, it cannot determine the final authorization result by modifying an ordinary process variable or sending an untrusted allow flag. The Finality Sink verifies protected authorization material and actual hardware-visible operation attributes. Where the operation requires receiving-side finality control, authorization at a source-side NIC does not automatically authorize a downstream database commit, payment, or other independent receiving- side consequence. The actual protected effectuation boundary remains identifiable. 11.21.30. WF-21.30 — Capability Consumption and Concurrency Where the capability is single-use, the hardware controller or protected state service performs the required consumption operation. A representative state record comprises: capability_id; candidate_act_digest; authorized_sink_id; remaining_uses; remaining_transfer_bytes; hardware_epoch; state_version; status. Das Expires 19 April 2027 [Page 882] Internet-Draft Protected AI Execution Finality October 2026 Where two execution requests compete for the same restricted grant, the protected system prevents both from independently consuming it outside the allowed usage conditions. Where repeated or windowed use is authorized, the implementation enforces its bounded usage allowance. A protected consumption update does not necessarily establish successful remote completion. 11.21.31. WF-21.31 — Device Reset and Recovery Following a hardware reset, firmware restart, power interruption, or controller failover, RC-2119 reconciles the required protected state. The recovery procedure may verify: (a) current device identity; (b) secure boot or firmware state; (c) hardware freshness; (d) capability-table continuity; (e) protected usage state; (f) authorization epochs; (g) revocation state; (h) pending operation references; and (i) observed or confirmed effectuation outcomes. The controller does not automatically treat restored queue contents or cached capability entries as valid. Required current authorization conditions are reestablished before further governed effectuation. Previously consumed or revoked capabilities are not restored through replay of earlier device state. 11.21.32. WF-21.32 — Partial Transfer and Indeterminate Completion A hardware transfer may fail after partial admission or delivery. Das Expires 19 April 2027 [Page 883] Internet-Draft Protected AI Execution Finality October 2026 The system distinguishes: Pending: No governed transfer effect has occurred. Reserved: Authorization has been reserved, but external effectuation has not been confirmed. Partially effective: Some bounded transfer units have crossed the controlled boundary. Confirmed effective: Sufficient evidence establishes completion of the specified effect. Indeterminate: Available evidence does not establish whether the relevant effect completed. A timeout or device reset does not automatically prove that a remote destination received no data. Recovery uses protected transfer identifiers, sequence numbers, completion records, or authenticated acknowledgments where available. The system does not automatically replay uncertain consequential operations when that could cause an unauthorized duplicate effect. 11.21.33. WF-21.33 — Illustrative NIC Egress Finality An AI agent generates a request to transmit confidential enterprise data to an external service. The request is intercepted before the controlled NIC transmit interface. The proposed transmission is classified as a Candidate Act and held in a Non-Effective State. The PED validates the requested destination, data scope, authorized purpose, workload identity, protected policy state, and required freshness. The protected mechanism commits the applicable validation evidence and releases a scoped execution capability. The NIC Finality Sink reconstructs or verifies the actual transmission descriptor. The NIC permits the authorized transfer only when the required capability verifies. Das Expires 19 April 2027 [Page 884] Internet-Draft Protected AI Execution Finality October 2026 If the agent substitutes an unauthorized destination, the Finality Sink rejects the changed operation. Possession of the data and ability to generate a packet do not independently authorize its transmission. 11.21.34. WF-21.34 — Illustrative GPU DMA Finality An AI accelerator produces a protected tensor. The workload prepares a DMA descriptor to copy the tensor into another memory domain. The corresponding hardware transfer interface retains the descriptor in a non-admitting state. The PED validates the source and destination domains, data class, memory region, size, permitted route, and protected authorization state. The required validation evidence is committed. A bounded Fabric Transfer Capability becomes available. The hardware Finality Sink verifies the capability against the actual DMA descriptor. Only the authorized transfer is admitted. A modified destination address or unauthorized memory region causes required verification to fail. The example illustrates the difference between executing a tensor computation and possessing authority to export the resulting data. 11.21.35. WF-21.35 — Illustrative DPU Watchdog and Revocation Interlock An AI workload has an outstanding capability permitting a bounded network operation. An isolated hardware-monitoring component detects a condition requiring revocation. The protected monitoring-state version advances. The affected DPU forwarding Finality Sink checks the current required monitoring or revocation version before admitting the operation. Das Expires 19 April 2027 [Page 885] Internet-Draft Protected AI Execution Finality October 2026 The earlier capability no longer satisfies the mandatory state condition. The DPU refuses the operation. The prevention occurs through the forwarding interlock rather than solely through an out-of-band alert. If the corresponding operation had already crossed the controlled boundary before the revocation became effective, the system records the completed effect instead of claiming retroactive prevention. 11.21.36. WF-21.36 — Illustrative Confidential Governance VM and SmartNIC A protected governance VM authenticates its hardware-rooted measurement. The PED verifies the registered governance identity and approved attestation state. An AI compute node proposes an external data transfer. The PED validates the concrete Candidate Act. The protected system performs required state and evidence operations and makes available an operation-scoped capability. An authenticated fabric-management channel conveys the capability or protected capability entry toward the SmartNIC. The SmartNIC verifies the issuer identity, required attestation state, Candidate Act binding, policy state, freshness, and Finality Sink identity. The transfer proceeds only when the hardware Finality Sink authorizes the actual operation. If the governance-node attestation becomes invalid under the mandatory policy, further affected authorization is withheld or refused as required by the protected state rules. 11.21.37. WF-21.37 — Failure and Fail-Closed Conditions The hardware Finality Sink refuses the governed effect when any mandatory condition is absent, invalid, revoked, expired, replayed, inconsistent, or unverifiable. Das Expires 19 April 2027 [Page 886] Internet-Draft Protected AI Execution Finality October 2026 Non-limiting conditions include: (a) missing execution capability; (b) invalid capability authentication; (c) unauthorized Candidate Act; (d) source identity mismatch; (e) destination mismatch; (f) prohibited data classification; (g) unauthorized memory region; (h) transfer-size violation; (i) fabric-route inconsistency; (j) unauthorized hardware queue; (k) stale policy epoch; (l) revoked authorization; (m) expired nonce; (n) consumed or replayed capability; (o) invalid hardware freshness; (p) failed required protected-state transition; (q) failed required validation-evidence commitment; (r) invalid required governance attestation; (s) invalid monitoring-state version; (t) missing required monitoring state; (u) Finality Sink mismatch; (v) unavailable mandatory hardware verifier; or (w) failure to establish mandatory non-bypassable path coverage. Das Expires 19 April 2027 [Page 887] Internet-Draft Protected AI Execution Finality October 2026 A hardware or software fault does not create unrestricted fallback execution authority. 11.21.38. WF-21.38 — PHOSITA Verification and Negative Tests A person having ordinary skill in hardware security, NIC/SmartNIC/DPU design, accelerator architecture, DMA systems, protected computing, cryptography, and network enforcement may verify the described system through controlled testing. Test 1 — Authorized hardware operation: Submit a Candidate Act with valid protected authorization. The hardware Finality Sink permits only the authorized effect. Test 2 — Missing capability: Present the operation without the required capability. The hardware latch remains non-admitting. Test 3 — Forged capability: Modify the capability authentication. Hardware verification fails. Test 4 — Wrong destination: Substitute another destination after authorization. The Finality Sink refuses the changed operation. Test 5 — Wrong hardware interface: Present the capability at a different Finality Sink. Required sink binding fails. Test 6 — DMA bypass: Attempt data movement through an unauthorized DMA descriptor or mapping. The governed transfer remains blocked. Test 7 — NIC bypass: Attempt transmission through another accessible network interface. The operation is blocked or subjected to equivalent mandatory verification. Test 8 — Hardware latch: Verify that the interface remains disabled or non-admitting until the required protected capability succeeds. Test 9 — Transfer-size limit: Exceed the permitted transfer allowance. The unauthorized excess is denied. Test 10 — Streaming transfer: Verify authorized bounded transfer units and refusal of subsequent units after mandatory authorization becomes invalid. Test 11 — Route drift: Change a required fabric route during transfer progression. Further unauthorized units are withheld. Test 12 — Hardware replay: Reuse a capability bound to an incompatible previous hardware epoch. Verification fails. Das Expires 19 April 2027 [Page 888] Internet-Draft Protected AI Execution Finality October 2026 Test 13 — Protected counter rollback: Attempt to restore prior counter or sequence state. The protection mechanism rejects unauthorized replay under its specified threat model. Test 14 — Policy revocation: Revoke an applicable authorization before effectuation. The Finality Sink refuses the affected operation. Test 15 — Monitoring-state invalidation: Advance the protected watchdog state and verify rejection of affected superseded capabilities. Test 16 — Governance attestation mismatch: Present an invalid required issuer attestation. Dependent authorization fails. Test 17 — Confidential governance key isolation: Attempt unrestricted extraction of protected issuance keys from an AI compute process. The protected key boundary refuses access. Test 18 — Evidence-commitment failure: Interrupt mandatory protected evidence commitment. No valid corresponding capability becomes available. Test 19 — Concurrent capability use: Submit competing operations against one restricted grant. Protected consumption prevents unauthorized double use. Test 20 — Fast-path enforcement: Perform cold-path authorization and verify mandatory local hardware capability checks before each governed transfer unit or window. Test 21 — Hardware verifier outage: Disable a mandatory hardware- verification component. The corresponding governed effect remains blocked. Test 22 — Device reset: Restore device state after reset and verify current hardware freshness, policy, and capability state. Test 23 — Partial effectuation: Interrupt a transfer after some units cross the boundary. The system preserves the distinction between delivered and pending units. Test 24 — Indeterminate remote completion: Simulate an uncertain downstream result and verify that recovery does not automatically claim prevention or success. Das Expires 19 April 2027 [Page 889] Internet-Draft Protected AI Execution Finality October 2026 Test 25 — Single-node architecture: Implement PED and Finality Sink functions in one protected device and verify their mandatory authorization dependencies. Test 26 — Distributed architecture: Place the PED and hardware Finality Sink on separate nodes and verify authenticated capability delivery and independent enforcement. Test 27 — Source versus receiving-side authority: Permit a source network transmission while withholding a separately required receiving-side commit. Confirm that source authorization does not bypass the receiving Finality Sink. Test 28 — Hardware-only monitoring: Configure a monitor that observes operations but does not block the actual effectuation path. Confirm that this arrangement alone does not provide the specified preventive finality guarantee. The tests may use controlled GPU and DMA workloads, programmable NIC/SmartNIC/DPU interfaces, accelerator simulators, hardware capability tables, authenticated authorization services, protected counters, device resets, and fault injection. Actual latency, throughput, revocation timing, and hardware-bypass resistance must be demonstrated through implementation-specific testing. 11.21.39. WF-21.39 — Claim-Specific Technical Coverage enforcement point 14 — Hardware-Rooted Enforcement WF-21.3 through WF-21.5 and WF-21.17 through WF-21.19 describe the hardware-protected enforcement component and the execution-enabling latch, host execution gate, credential-release gate, or network- forwarding gate remaining disabled without successful capability verification. enforcement point 48–49 — Protected Cross-Domain Fabric Transfer and Descriptor Granularity WF-21.6 through WF-21.16 describe proposed accelerator, memory, or network-fabric transfers, Candidate Fabric Transfer Act descriptors, protected authority validation, and scoped Fabric Transfer Capabilities. enforcement point 50 — Hardware-Latched Transfer Admission Das Expires 19 April 2027 [Page 890] Internet-Draft Protected AI Execution Finality October 2026 WF-21.19 through WF-21.20 describe hardware-disabled transfer interfaces that become admitting only after required capability verification. enforcement point 51 — Continuous Tensor or Memory-Transfer Validation WF-21.23 describes bounded transfer units and authorization-state enforcement during streaming. enforcement point 52 — Hardware-Freshness Binding WF-21.24 describes protected hardware generations, counters, sequences, and replay resistance. enforcement point 53 — Cold-Path Validation and Line-Rate Finality WF-21.22 describes separation of higher-cost authority validation from bounded local hardware capability verification. enforcement point 62–63 — Hardware-Watchdog Interlock and Attested Monitoring WF-21.26 describes the optional isolated monitoring domain, protected monitoring-state records, and required current-state verification. enforcement point 64–66 — Revocation Fence, Independent Downstream Prevention, and Monitoring Failure WF-21.26 through WF-21.27 describe monitoring-state invalidation, protected revocation, and fail-closed handling of mandatory monitoring conditions. The full monitoring-state protocol remains specified in WF-16. enforcement point 67 — Quarantine and Effectuation-State Preservation WF-21.31 through WF-21.32 describe preservation of protected effectuation outcomes during failure and recovery. The complete quarantine-state procedure remains specified in WF-16. enforcement point 79–81 — Confidential Governance VM, Hardware Attestation, and Key Isolation WF-21.25 and WF-21.36 describe an optional attested confidential governance environment and authenticated capability delivery to a hardware Finality Sink. The complete governance attestation and protected key-custody procedure remains specified in WF-18. Das Expires 19 April 2027 [Page 891] Internet-Draft Protected AI Execution Finality October 2026 enforcement point 82 — Attestation Change Disables Capability Issuance WF-21.25 and WF-21.27 describe refusal of dependent authorization when mandatory governance-state conditions become invalid. enforcement point 83 — Hardware Freshness WF-21.24 describes capability binding to required protected counters, boot epochs, device sequences, or equivalent hardware-freshness state. 11.21.40. WF-21.40 — Technical Effect The disclosed workflow establishes a protected causal relationship between: (a) AI computation generating a consequential operation; (b) interception before the relevant hardware effectuation boundary; (c) holding the Candidate Act in a Non-Effective State; (d) construction of a concrete operation descriptor; (e) protected validation of the applicable Authority Object and mandatory predicates; (f) required protected-state handling; (g) protected validation-evidence commitment; (h) release or availability of an operation-scoped capability; (i) independent hardware Finality Sink verification; (j) hardware-latch enablement for the authorized bounded operation; (k) capability usage and freshness enforcement; (l) revocation-dependent refusal of further affected operations; and (m) accurate preservation of effectuation outcomes during failure and recovery. Das Expires 19 April 2027 [Page 892] Internet-Draft Protected AI Execution Finality October 2026 The hardware implementation prevents an AI workload from treating computation, packet generation, possession of accelerator memory, or the ability to create a DMA descriptor as sufficient authority to perform a governed transfer. A software approval may contribute to authorization, but the final hardware boundary must enforce the required protected capability conditions. A hardware watchdog may supply governance information, but observation is not itself prevention. A confidential governance VM may protect capability-issuance authority, but attestation is not automatically permission for a concrete operation. A SmartNIC or DPU may act as a hardware Finality Sink when it actually controls the governed effectuation path and verifies the required scoped execution capability. Computation is not authority to act. Hardware connectivity is not execution authority. A software allow decision is not a substitute for mandatory hardware finality verification. Monitoring a transfer is not equivalent to preventing an unauthorized transfer. A Hardware Finality Latch must control the actual consequential boundary. 11.22. WF-22 — Portable Cloud-VM Agent Authority, Cross-Cloud Workload Identity, Runtime Policy-Epoch Synchronization, Hardware- Supervised Egress, Migration and Snapshot Protection, and Downstream Effectuation Finality 11.22.1. WF-22.1 — Technical Purpose This embodiment describes a computer-implemented protected execution- finality architecture for enforcing operation-specific execution authority across multiple cloud, virtualized, containerized, confidential-computing, on-premises, hybrid-cloud, and accelerator- backed artificial-intelligence execution environments. Das Expires 19 April 2027 [Page 893] Internet-Draft Protected AI Execution Finality October 2026 The architecture permits an artificial-intelligence agent to be deployed, instantiated, replicated, restarted, rescheduled, migrated, recovered, or relocated between supported execution substrates without treating portability of its software, credentials, computation state, or prior authorization context as unrestricted authority to perform consequential operations. The system establishes protected relationships among: (a) an agent-execution control plane; (b) an authenticated workload identity; (c) a machine-verifiable execution-context measurement; (d) a Protected Enforcement Domain maintaining applicable execution- policy predicates and protected authorization-state versions; (e) an operation-interception component retaining proposed consequential operations in a Non-Effective State; (f) an operation-specific authorization procedure; (g) a scoped cryptographic execution capability; (h) a designated Finality Sink; and (i) a protected runtime-transition and recovery procedure. The Protected Enforcement Domain validates each governed Candidate Act against the actual operation descriptor, authenticated workload identity, execution-context measurement, current protected policy state, and designated effectuation boundary. Only after the required protected authorization conditions succeed is the corresponding scoped execution capability generated, released, or made available. The designated Finality Sink independently verifies the capability before permitting the operation to become externally effective. A workload's migration to another cloud region, replacement by a new container, restoration from a snapshot, or restart on another compute node does not independently revive previously consumed, revoked, expired, or incompatible execution authority. Das Expires 19 April 2027 [Page 894] Internet-Draft Protected AI Execution Finality October 2026 The system additionally distinguishes admission to an artificial- intelligence model from authorization to perform consequential operations produced by that model. The central technical requirement is that portability of computation does not imply portability of unrestricted execution authority. 11.22.2. WF-22.2 — Participating Technical Components In one non-limiting implementation, the system comprises the following components. CP-2201 — Agent-Execution Control Plane A cloud, container, hypervisor, orchestration, or workload-management component configured to deploy, manage, replicate, restart, reschedule, or migrate an AI agent across supported execution substrates. AE-2202 — Artificial-Intelligence Execution Instance An AI agent, model runtime, autonomous workload, orchestrator, tool- execution process, or other computational instance executing on the selected substrate. ES-2203 — Execution Substrate A container runtime, virtual machine, confidential virtual machine, Kubernetes workload, on-premises compute host, hybrid-cloud environment, accelerator-backed runtime, or equivalent supported compute environment. WI-2204 — Workload Identity and Measurement Component A component configured to establish the authenticated workload identity and machine-verifiable execution-context measurement corresponding to the deployed instance. AR-2205 — Workload Attestation and Measurement Record A protected or authenticated record identifying the relevant workload and execution-context measurements. IM-2206 — Operation Interception Component An enforcement-controlled component configured to intercept a proposed consequential operation before its governed effectuation boundary. Das Expires 19 April 2027 [Page 895] Internet-Draft Protected AI Execution Finality October 2026 HQ-2207 — Non-Effective Candidate Act Holding Mechanism A controlled pending-request queue, staging buffer, inactive command representation, blocked egress request, or equivalent mechanism retaining the proposed operation before authorization. DC-2208 — Candidate Act Descriptor Component A component configured to construct or verify the canonical representation of the proposed consequential operation. PED-2209 — Protected Enforcement Domain A protected authority component configured to maintain applicable execution-policy predicates, authorization-state versions, workload- authority conditions, and operation-specific authorization decisions. AS-2210 — Protected Authority and Workload Policy Store An authenticated source of Authority Objects, approved workload measurements, permitted operations, policy versions, revocation conditions, and effectuation-boundary restrictions. PS-2211 — Protected Authorization-State Store A protected mechanism maintaining policy epochs, authorization-state versions, nonces, revocation state, capability-consumption records, and required validation commitments. EV-2212 — Protected Validation-Evidence Component A mechanism configured to generate or commit protected evidence of operation-specific validation where required by the applicable execution-finality embodiment. CR-2213 — Scoped Execution-Capability Component A protected mechanism configured to issue, register, derive, release, or activate an execution capability bound to the Candidate Act, authenticated workload identity, authorization-state version, and designated Finality Sink. FS-2214 — Host or Virtual-Machine Finality Sink A controlled host execution interface or virtual-machine boundary that verifies the required capability before the governed operation. FS-2215 — Cloud Network or Service-Mesh Finality Sink Das Expires 19 April 2027 [Page 896] Internet-Draft Protected AI Execution Finality October 2026 A gateway, service-mesh component, protected connector, or equivalent controlled cloud service interface. FS-2216 — Hardware-Assisted Finality Sink A SmartNIC, DPU, protected network gateway, hardware-assisted cloud egress controller, or accelerator-egress controller enforcing operation-specific capability verification. PV-2217 — Protected Policy-Version Controller A mechanism configured to advance and validate authorization-state versions applicable to one or more workload identities, replicas, or execution nodes. MG-2218 — Migration and Runtime-Transition Controller A component configured to identify and coordinate migration, container replacement, workload rescheduling, snapshot restoration, and cloud-region failover. RS-2219 — Rollback-Resistant Capability-State Component A protected mechanism maintaining authoritative capability- consumption, revocation, and freshness state independently of rollback-accessible workload state. MC-2220 — Model-Access Control Component A component configured to govern access to a local or remote artificial-intelligence model. OS-2221 — Protected Effectuation-Outcome Store A component maintaining operation states including pending, reserved, confirmed-effective, denied, revoked, and indeterminate. RC-2222 — Recovery and State-Reconciliation Component A mechanism configured to reconcile workload identity, policy state, pending Candidate Acts, capability usage, and effectuation outcomes following runtime transitions or failures. The identified roles may be physically integrated or distributed across authenticated systems. Das Expires 19 April 2027 [Page 897] Internet-Draft Protected AI Execution Finality October 2026 The Protected Enforcement Domain, Finality Gate, and Finality Sink retain their distinguishable functions even when implemented within one trusted node. 11.22.3. WF-22.3 — Supported Portable AI Execution Substrates CP-2201 supports one or more execution substrates comprising: (a) a container runtime; (b) a conventional virtual machine; (c) a confidential virtual machine; (d) a Kubernetes workload; (e) an on-premises compute host; (f) a hybrid-cloud computing environment; (g) an accelerator-backed agent runtime; or (h) another supported virtualized or distributed execution environment. An AI agent may execute on one substrate and subsequently be instantiated on another. The agent may retain its permitted computational functionality, task context, model access, and compatible data representations. However, the execution substrate's identity, runtime measurement, policy state, and effectuation-boundary location may differ. The system therefore distinguishes portable application state from protected authorization state. A workload's successful deployment does not automatically validate every consequential operation proposed by the deployed instance. 11.22.4. WF-22.4 — Separation of Workload Deployment and Execution Authority The agent-execution control plane may authorize scheduling or starting an AI workload. Such orchestration authorization is distinct from protected Candidate Act authorization. Das Expires 19 April 2027 [Page 898] Internet-Draft Protected AI Execution Finality October 2026 A deployment controller may determine that an agent is eligible to run on a particular virtual machine or Kubernetes node. That decision does not independently establish that the agent may: (a) transmit data to any destination; (b) apply protected credentials; (c) write to a protected database; (d) invoke privileged APIs; (e) deploy software; (f) export accelerator state; (g) perform financial operations; or (h) issue another governed consequential instruction. Each operation remains subject to its applicable protected execution- finality boundary. 11.22.5. WF-22.5 — Establishment of the Workload Identity WI-2204 establishes an authenticated identity for the deployed AI- agent instance. The identity may comprise: (a) workload service identity; (b) agent runtime identity; (c) container identity; (d) virtual-machine identity; (e) confidential-VM identity; (f) service-account identity; (g) protected process identity; (h) accelerator-workload identity; or (i) another machine-verifiable execution identity. Das Expires 19 April 2027 [Page 899] Internet-Draft Protected AI Execution Finality October 2026 The selected identity must identify the workload at the granularity required by the applicable protected authority. A service name or container label supplied by the requesting process is not independently an authenticated identity. Where identity is mandatory for capability verification, the Finality Sink verifies the actual authenticated workload rather than accepting an untrusted caller assertion. 11.22.6. WF-22.6 — Execution-Context Measurement in the implementation described by enforcement point 91, WI-2204 validates one or more of: (a) workload image digest; (b) virtual-machine launch measurement; (c) container image identifier; (d) agent runtime identity; (e) approved tool-policy digest; (f) model configuration digest; or (g) protected execution-policy state. An illustrative measurement record comprises: workload_id; workload_instance_id; execution_substrate_type; runtime_image_digest; vm_launch_measurement; container_image_reference; agent_runtime_identity; tool_policy_digest; model_configuration_digest; Das Expires 19 April 2027 [Page 900] Internet-Draft Protected AI Execution Finality October 2026 protected_execution_policy_reference; deployment_epoch; measurement_generation; protected_authentication. Only the measurements required by the selected authority are mandatory. A container image digest alone does not necessarily establish the current runtime tool configuration or protected policy state. Likewise, VM launch attestation does not automatically measure every subsequently loaded adapter, plugin, tool, or workflow configuration. 11.22.7. WF-22.7 — Authentication of the Execution-Context Measurement The protected system verifies the required measurement's origin and applicability. Such verification may comprise: (a) authenticating workload identity; (b) validating an attestation signature; (c) checking an approved image digest; (d) verifying a registered runtime identity; (e) checking the permitted tool-policy digest; (f) checking an approved model configuration; (g) verifying protected policy state; (h) confirming the deployment generation; and (i) evaluating required freshness. An illustrative predicate is: Vworkload = IdentityValid AND MeasurementValid AND ContextValid AND StateValid Das Expires 19 April 2027 [Page 901] Internet-Draft Protected AI Execution Finality October 2026 where the terms represent the mandatory identity, measurement, execution-context, and protected-state conditions. A capability issued for another workload or an incompatible measured context does not authorize the present operation. 11.22.8. WF-22.8 — Protected Workload Authority Registration PED-2209 associates the authenticated workload identity with applicable Authority Objects and protected policy state. A representative authority record comprises: authority_id; workload_identity; approved_measurement_reference; permitted_operation_classes; authorized_destinations; authorized_effectuation_sinks; protected_policy_epoch; authorization_state_version; revocation_state; usage_conditions; validity_interval. The authority may apply to: (a) one workload instance; (b) a defined group of replicas; (c) a service identity; (d) a tenant workload class; (e) a specific execution environment; or (f) another expressly authorized scope. Das Expires 19 April 2027 [Page 902] Internet-Draft Protected AI Execution Finality October 2026 The protected system distinguishes group-level authority from authority for an individual concrete Candidate Act. An approved workload class does not automatically authorize arbitrary operations requested by every instance of that class. 11.22.9. WF-22.9 — Candidate Act Generation AE-2202 performs computation and prepares a proposed consequential operation. Non-limiting operations include: (a) a network request; (b) an external API invocation; (c) a protected connector operation; (d) a credential-mediated action; (e) a database modification; (f) a storage commit; (g) software deployment; (h) accelerator data export; or (i) another externally effective operation. The operation is classified as Candidate Portable-Workload Act CA- 2223. Computation and operation preparation do not independently confer execution authority. 11.22.10. WF-22.10 — Interception and Non-Effective Staging IM-2206 intercepts CA-2223 before the governed effectuation boundary. HQ-2207 retains the operation in a Non-Effective State. A representative pending-operation record comprises: candidate_act_id; workload_identity; Das Expires 19 April 2027 [Page 903] Internet-Draft Protected AI Execution Finality October 2026 workload_instance_id; execution_substrate; measurement_reference; operation_class; target_resource; requested_effectuation_boundary; authorization_state_version; deployment_epoch; status = NON_EFFECTIVE. The staging component preserves the required effectuation-relevant operation representation or authenticated reference. A workload restart does not automatically transform a pending Candidate Act into an authorized operation. Likewise, migration of the staged request to another execution node does not bypass the required protected authorization. 11.22.11. WF-22.11 — Candidate Act Descriptor DC-2208 constructs a machine-readable Candidate Act Descriptor. The descriptor may comprise: candidate_act_id; authenticated_workload_identity; workload_instance_identity; execution_context_measurement; operation_class; destination_or_recipient; resource_identifier; operation_parameters; Das Expires 19 April 2027 [Page 904] Internet-Draft Protected AI Execution Finality October 2026 payload_digest; authorized_purpose; policy_epoch; authorization_state_version; deployment_epoch; revocation_epoch; nonce; expiry; finality_sink_id. The applicable Authority Object determines which attributes are mandatory. The descriptor represents the concrete consequential operation. It is distinct from the portable workload image, orchestration configuration, and general workload identity. 11.22.12. WF-22.12 — Canonical Candidate Act Representation In one illustrative cryptographic implementation: Dportable = Canon_v(W, M, ACT, TARGET, PARAM, AUTH_VERSION, DEPLOY_EPOCH, SINK) where: Dportable denotes the canonical Candidate Act Descriptor; Canon_v denotes deterministic encoding under version v; W denotes the authenticated workload identity; M denotes the required execution-context measurement; ACT denotes the requested consequential operation; TARGET denotes the recipient, destination, or resource; PARAM denotes effectuation-relevant parameters; Das Expires 19 April 2027 [Page 905] Internet-Draft Protected AI Execution Finality October 2026 AUTH_VERSION denotes the protected authorization-state version; DEPLOY_EPOCH denotes the applicable workload deployment generation; and SINK denotes the designated Finality Sink. An illustrative digest is: hPortable = H("DAS-PORTABLE-WORKLOAD-ACT-v1" || Encode(Dportable)) The specific cryptographic and encoding formats are non-limiting implementation choices. The protected authorizer and Finality Sink apply compatible field interpretation. 11.22.13. WF-22.13 — Protected Operation Authorization PED-2209 obtains the applicable Authority Object and verifies the Candidate Act. The validation includes applicable checks of: (a) authenticated workload identity; (b) execution-context measurement; (c) authorized operation class; (d) destination or resource scope; (e) current execution-policy predicates; (f) protected authorization-state version; (g) deployment generation; (h) revocation state; (i) nonce and freshness; (j) protected usage conditions; and (k) designated effectuation boundary. A valid workload identity does not independently authorize an arbitrary operation. Das Expires 19 April 2027 [Page 906] Internet-Draft Protected AI Execution Finality October 2026 Likewise, an earlier authorization associated with a different workload measurement or authorization-state version does not automatically remain valid after migration or policy changes. 11.22.14. WF-22.14 — Protected Authorization Predicate An illustrative predicate is: Vportable = Pidentity AND Pmeasurement AND Pact AND Pscope AND Pversion AND Pstate AND Psink where: Vportable denotes the protected operation-authorization result; Pidentity verifies workload identity; Pmeasurement verifies required execution-context state; Pact verifies the proposed consequential operation; Pscope verifies permitted destination, purpose, and execution scope; Pversion verifies the current required protected authorization-state version; Pstate verifies revocation, nonce, usage, and freshness conditions; and Psink verifies the designated Finality Sink. Additional predicates may apply according to the selected embodiment. Failure of any mandatory predicate prevents availability of the corresponding execution capability. 11.22.15. WF-22.15 — Protected Authorization-State Handling Following successful validation, PED-2209 performs the required protected authorization-state operations. These may include: (a) reserving an operation-specific authorization grant; (b) checking the current policy epoch; (c) recording the applicable authorization-state version; Das Expires 19 April 2027 [Page 907] Internet-Draft Protected AI Execution Finality October 2026 (d) registering or consuming a nonce; (e) reserving a capability identifier; (f) recording the workload measurement; (g) recording the deployment epoch; (h) updating a bounded usage allowance; or (i) another required protected authorization transition. Where a restricted grant is single-use, protected state prevents unauthorized concurrent consumption. Where the relevant protected state cannot be established consistently, the operation remains non-effective. 11.22.16. WF-22.16 — Protected Validation-Evidence Commitment Where the selected execution-finality embodiment requires a protected validation receipt, EV-2212 commits the corresponding evidence. An illustrative record comprises: receipt_id; candidate_act_id; candidate_act_descriptor_digest; authenticated_workload_reference; execution_measurement_reference; authority_object_reference; authorization_state_version; deployment_epoch; protected_state_transition; policy_epoch; nonce; finality_sink_id; Das Expires 19 April 2027 [Page 908] Internet-Draft Protected AI Execution Finality October 2026 decision; protected_authentication. The evidence may comprise a LAVR, AVR, authenticated validation record, sealed commitment, or another supported protected artifact. Where pre-capability evidence commitment is mandatory, the commitment occurs before, or atomically with, availability of the corresponding capability. enforcement point 90 itself requires scoped cryptographic capability issuance and independent Finality Sink verification. The additional protected-receipt sequence applies where separately required by the selected DAS finality embodiment. 11.22.17. WF-22.17 — Scoped Portable-Workload Execution Capability CR-2213 generates or releases the scoped capability corresponding to CA-2223. In enforcement point 90, the capability is bound to: (a) the Candidate Act; (b) authenticated workload identity; (c) authorization-state version; and (d) designated Finality Sink. The capability may additionally bind: execution_context_measurement; workload_instance_id; authorized_operation; destination_scope; deployment_epoch; policy_epoch; revocation_epoch; nonce; Das Expires 19 April 2027 [Page 909] Internet-Draft Protected AI Execution Finality October 2026 expiry; usage_limit; validation_evidence_reference. The capability may comprise a cryptographically signed authorization artifact, authenticated protected handle, MAC-authenticated permit, sealed capability reference, or equivalent protected execution- enablement representation. The capability does not authorize arbitrary operations outside its validated scope. 11.22.18. WF-22.18 — Illustrative Cryptographic Capability In a signature-based implementation: Cportable = Sign_skPED(Encode(hPortable, WorkloadID, MeasurementRef, AuthVersion, DeployEpoch, Scope, Nonce, Expiry, Sink)) where: Cportable denotes the scoped execution capability; Sign_skPED denotes signing under PED-controlled key material; hPortable denotes the Candidate Act Descriptor digest; WorkloadID denotes authenticated workload identity; MeasurementRef denotes the required execution-context measurement; AuthVersion denotes the protected authorization-state version; DeployEpoch denotes the applicable deployment epoch; Scope denotes the authorized operation scope; Nonce denotes freshness; Expiry denotes capability validity; and Sink denotes the designated Finality Sink. A selected implementation may use a protected capability table or hardware-associated authorization entry instead of transferring a signed artifact. Das Expires 19 April 2027 [Page 910] Internet-Draft Protected AI Execution Finality October 2026 The required non-bearer characteristics depend upon actual workload, operation, state, and sink verification. 11.22.19. WF-22.19 — Independent Finality Sink Verification Before the proposed operation becomes externally effective, the designated Finality Sink obtains or reconstructs the actual operation. The Finality Sink verifies: (a) capability authenticity; (b) Candidate Act correspondence; (c) authenticated workload identity; (d) required execution-context measurement; (e) authorized operation scope; (f) current required authorization-state version; (g) policy epoch; (h) revocation state; (i) nonce and expiry; (j) deployment epoch where mandatory; (k) capability usage or consumption state; (l) validation-evidence commitment where required; and (m) designated Finality Sink identity. The operation is refused when a mandatory verification condition fails. An ordinary cloud identity, authenticated network session, or successful virtual-machine connection does not replace the required operation-specific capability check. 11.22.20. WF-22.20 — Finality Verification Predicate An illustrative effectuation predicate is: Das Expires 19 April 2027 [Page 911] Internet-Draft Protected AI Execution Finality October 2026 PermitPortableEffect = Auth(C) AND Match(C,Dactual) AND WorkloadValid(C,Wactual) AND VersionValid(C,Vcurrent) AND StateValid(C,S) AND SinkValid(C,F) where: C denotes the scoped capability; Dactual denotes the actual operation descriptor; Wactual denotes the authenticated executing workload; Vcurrent denotes the protected authorization-state version currently required; S denotes required policy, revocation, freshness, and consumption state; and F denotes the designated Finality Sink. The Finality Sink permits the effect only if the applicable predicates succeed. Where a workload measurement or deployment epoch is a mandatory binding, its corresponding verification is included in WorkloadValid or StateValid. 11.22.21. WF-22.21 — Protected Runtime Policy Updates Across Replicas in the implementation described by enforcement point 92, CP-2201 manages multiple replicas, restarted workloads, VM instances, or agent-execution nodes. PV-2217 maintains the protected authorization-state version applicable to a defined workload scope. An illustrative protected policy record comprises: Das Expires 19 April 2027 [Page 912] Internet-Draft Protected AI Execution Finality October 2026 workload_scope_id; current_authorization_version; policy_digest; revocation_reference; effective_generation; affected_workload_identities; affected_finality_sinks; protected_authentication. The defined scope may encompass one workload, a replica group, or another authorized collection of execution instances. When a protected policy-state transition occurs, the corresponding authorization-state version advances. The system distinguishes a new configuration's successful deployment from its protected effectuation-authority state. 11.22.22. WF-22.22 — Authorization-State Version Advancement An illustrative state transition is: AUTH_VERSION = v → v+1 where the protected new version applies to the defined workload scope. Possible triggers include: (a) revocation of a destination; (b) modification of permitted tool classes; (c) restriction of service credentials; (d) change of execution scope; (e) policy update; (f) withdrawal of a workload identity; Das Expires 19 April 2027 [Page 913] Internet-Draft Protected AI Execution Finality October 2026 (g) security-state transition; or (h) another protected authorization change. A capability bound to an incompatible prior authorization-state version is rejected by each affected Finality Sink before admitting a subsequent consequential operation. The protected policy-version mechanism must be authenticated and resistant to unauthorized rollback under its declared trust model. 11.22.23. WF-22.23 — Replica Consistency and Stale Capability Rejection In a replicated system, different instances may have received earlier configuration or policy information. An agent replica may therefore retain: (a) an earlier policy snapshot; (b) a previously issued capability; (c) a cached authorization result; (d) an earlier workload measurement; or (e) a previous deployment epoch. The corresponding Finality Sink verifies the currently required protected authorization-state version. Where exact version matching is mandatory, a capability associated with an incompatible prior version is refused. Where a bounded validity policy is expressly permitted, the Finality Sink applies that authenticated acceptance rule. The system must not claim instantaneous revocation across all replicas unless the actual protected state-distribution and verification mechanism provides that guarantee. An affected Finality Sink that cannot establish required current state remains non-admitting rather than silently treating stale authority as valid. Das Expires 19 April 2027 [Page 914] Internet-Draft Protected AI Execution Finality October 2026 11.22.24. WF-22.24 — Hardware-Supervised Cloud Egress in the implementation described by enforcement point 93, the designated Finality Sink is implemented within or through: (a) a DPU; (b) a SmartNIC; (c) a protected network gateway; or (d) a hardware-assisted cloud egress controller. The hardware-associated Finality Sink verifies the scoped execution capability and authenticated workload context before permitting the governed external network effect. The actual operation may identify: source_workload_identity; source_vm_or_container; destination_service; network_endpoint; protocol; operation_class; payload_or_request_reference; authorization_state_version; capability_identifier. The controller verifies the relevant fields against the authenticated capability. Successful cloud-network authentication, TLS establishment, virtual- machine connectivity, or container membership does not independently establish the required operation-specific execution authority. 11.22.25. WF-22.25 — Hardware Egress Admission Sequence A non-limiting hardware-supervised egress sequence comprises: Das Expires 19 April 2027 [Page 915] Internet-Draft Protected AI Execution Finality October 2026 First, the AI workload prepares an outbound request. Second, the request is intercepted and maintained in a Non-Effective State. Third, the Candidate Act Descriptor is constructed. Fourth, the PED validates workload identity, execution-context measurement, operation scope, current protected policy state, and designated hardware egress boundary. Fifth, required protected-state and evidence conditions are completed. Sixth, the scoped execution capability becomes available. Seventh, the DPU, SmartNIC, or protected gateway obtains the actual outbound operation and verifies the capability. Eighth, the hardware-associated Finality Sink permits the bounded transmission only when mandatory authorization conditions succeed. Ninth, the protected capability usage state is advanced or consumed as required. An unauthorized source workload or incompatible policy version causes denial even if the packet can otherwise be routed through the cloud network. 11.22.26. WF-22.26 — Identification of Runtime Transitions in the implementation described by enforcement point 94, MG-2218 detects or coordinates: (a) virtual-machine migration; (b) container replacement; (c) workload rescheduling; (d) checkpoint restoration; (e) cloud-region failover; (f) node restart; (g) execution-host replacement; or Das Expires 19 April 2027 [Page 916] Internet-Draft Protected AI Execution Finality October 2026 (h) another relevant runtime transition. The transition may alter the workload identity, execution-context measurement, or protected deployment epoch. The protected system determines which attributes have changed and whether any outstanding authorization remains applicable. Migration alone does not prove that an authorization is invalid. However, migration also does not automatically preserve authority when a mandatory identity, measurement, state, or deployment binding has changed. 11.22.27. WF-22.27 — Runtime-Transition State Record An illustrative runtime-transition record comprises: transition_id; workload_id; source_instance_id; destination_instance_id; source_substrate; destination_substrate; source_measurement; destination_measurement; previous_deployment_epoch; new_deployment_epoch; current_authorization_version; pending_candidate_act_references; capability_state_reference; transition_status; protected_authentication. Das Expires 19 April 2027 [Page 917] Internet-Draft Protected AI Execution Finality October 2026 The record supports protected evaluation of outstanding operations following the runtime transition. The system does not rely exclusively upon the restored workload's local view of its former authorization state. 11.22.28. WF-22.28 — Migration of Pending Candidate Acts An AI workload may have prepared a consequential operation before migration. The operation may remain queued or otherwise non-effective. Following a relevant runtime transition, the system determines whether the operation remains associated with a valid execution context. If a mandatory workload identity, measurement, deployment epoch, or protected policy condition has changed, the pending Candidate Act is revalidated before effectuation. The revalidation obtains the current required context and evaluates the applicable Authority Object. A capability bound to incompatible earlier conditions does not independently authorize the pending operation after the transition. The corresponding Finality Sink enforces the current protected context before permitting the effect. 11.22.29. WF-22.29 — Runtime Migration Revalidation Predicate An illustrative migration predicate is: Vtransition = WorkloadIdentityValid AND MeasurementValid AND DeploymentEpochValid AND AuthorizationVersionValid AND CandidateActAuthorityValid where: Das Expires 19 April 2027 [Page 918] Internet-Draft Protected AI Execution Finality October 2026 WorkloadIdentityValid verifies the executing workload after transition; MeasurementValid verifies required new runtime measurements; DeploymentEpochValid verifies the protected deployment generation; AuthorizationVersionValid verifies applicable current policy and authority state; and CandidateActAuthorityValid verifies the operation-specific authority under the changed context. Where a pending Candidate Act no longer satisfies its mandatory authorization conditions, the previous capability is rejected or a renewed protected authorization procedure is required. The operation remains non-effective until the required Finality Sink verification succeeds. 11.22.30. WF-22.30 — Snapshot and Checkpoint Restoration A snapshot may preserve: (a) AI-agent memory; (b) pending tool requests; (c) cached policy data; (d) earlier workload identity references; (e) previously issued capability representations; (f) task execution state; (g) model context; (h) local nonce records; and (i) previously observed operation outcomes. Restoration of the snapshot does not restore authoritative protected authorization state. The recovered workload is evaluated against the current workload identity, required measurement, policy version, deployment epoch, nonce state, and capability usage conditions. Das Expires 19 April 2027 [Page 919] Internet-Draft Protected AI Execution Finality October 2026 Where a single-use capability was consumed before the snapshot was restored, it remains consumed according to the authoritative protected state. 11.22.31. WF-22.31 — Protected Capability-Consumption State Across Migration RS-2219 maintains authoritative capability-consumption information independently of rollback-accessible workload memory or snapshots. An illustrative record comprises: capability_id; candidate_act_digest; workload_identity; authorization_state_version; deployment_epoch; remaining_uses; nonce_state; revocation_state; effectuation_status; protected_state_version. The storage may be implemented through protected external state, a trusted state service, a hardware-backed counter, or another suitable mechanism. The selected mechanism must preserve the properties required under the stated threat model. Restoring a VM, container filesystem, or local agent-state backup does not automatically reset the authoritative remaining-use count. 11.22.32. WF-22.32 — Duplicate Effectuation Prevention During Failover A cloud-region failover may occur after a consequential operation was dispatched but before the originating workload received its result. Das Expires 19 April 2027 [Page 920] Internet-Draft Protected AI Execution Finality October 2026 The recovered workload may therefore be uncertain whether the operation completed. The system distinguishes: (a) an operation known not to have become effective; (b) a confirmed effective operation; and (c) an indeterminate operation. The recovered agent does not automatically repeat the same consequential operation merely because its application-level state indicates that no response was received. The protected recovery mechanism consults available effectuation evidence, protected capability state, and receiving-side status where supported. A renewed attempt is processed under the required current authorization and duplicate-prevention conditions. The architecture does not presume that a local capability-consumption record can, by itself, establish exactly-once completion at every remote service. 11.22.33. WF-22.33 — Failover State-Reconciliation Procedure A non-limiting recovery procedure comprises: First, identify the recovered workload and destination execution substrate. Second, establish the authenticated workload identity and required current measurement. Third, obtain the applicable current protected authorization-state version. Fourth, determine whether the workload's deployment epoch has changed. Fifth, retrieve authoritative capability-consumption and revocation state. Sixth, enumerate pending or interrupted Candidate Acts. Das Expires 19 April 2027 [Page 921] Internet-Draft Protected AI Execution Finality October 2026 Seventh, distinguish confirmed-effective, non-effective, and indeterminate operations. Eighth, revalidate each pending Candidate Act whose mandatory context changed. Ninth, reject stale, consumed, or incompatible capabilities. Tenth, permit any authorized resumed effectuation only after the applicable Finality Sink independently verifies current authority. This procedure prevents recovery from being used as an uncontrolled replay mechanism. 11.22.34. WF-22.34 — Model-Access Authorization in the implementation described by enforcement point 95, MC-2220 governs access to a local or remote artificial-intelligence model. The component may validate: (a) requesting workload identity; (b) model identity; (c) approved model configuration; (d) computation purpose; (e) relevant policy state; (f) applicable session authority; and (g) model-access validity. Successful model-access authorization permits the corresponding approved computation within its authorized scope. It does not independently authorize a consequential operation produced by the model. The system therefore preserves the distinction between a model-access control decision and a downstream execution-finality decision. 11.22.35. WF-22.35 — Separate Downstream Operation Authorization An admitted model may generate: Das Expires 19 April 2027 [Page 922] Internet-Draft Protected AI Execution Finality October 2026 (a) an API request; (b) a network transmission; (c) a protected tool operation; (d) a database mutation; (e) a credential-mediated instruction; (f) a payment request; (g) a software deployment; or (h) another consequential Candidate Act. The operation remains subject to the applicable downstream protected finality requirements. A separate operation-specific execution capability is required when the corresponding effectuation boundary is governed by enforcement point 95. The downstream Finality Sink independently verifies that capability. The model-access gate does not replace the Finality Sink. 11.22.36. WF-22.36 — Interruption or Revocation of Future Model Access The model-access component may interrupt, quarantine, or revoke further model access. However, a Candidate Act may already have been generated and retained in a buffer. The interruption of future inference does not authorize release of the previously generated operation. The buffered Candidate Act remains non-effective until its separately required execution capability verifies at the downstream Finality Sink. Where the protected policy also revokes the downstream authority, the Finality Sink enforces that revocation. The system does not presume that model-path interruption itself retroactively prevents a downstream operation already completed. Das Expires 19 April 2027 [Page 923] Internet-Draft Protected AI Execution Finality October 2026 11.22.37. WF-22.37 — Illustrative Cross-Cloud Migration An AI agent executes in Cloud Region A. The agent prepares a request to update a protected enterprise record. The request is intercepted and retained in a Non-Effective State. A workload identity and execution-context measurement are associated with the pending Candidate Act. Before effectuation, the orchestrator migrates or reinstantiates the agent in Cloud Region B. The new instance has a changed workload-instance identity and deployment epoch. The protected system evaluates the new authenticated workload context and current authorization-state version. The pending Candidate Act is revalidated where the changed context affects mandatory authorization. A prior capability bound to an incompatible workload identity or deployment epoch is rejected. Following successful new authorization, the appropriate Finality Sink verifies the current operation-specific capability before the record update is permitted. The workload migration does not itself carry unrestricted execution authority into the new environment. 11.22.38. WF-22.38 — Illustrative Kubernetes Replica Policy Update An AI-agent service executes through several Kubernetes replicas. A protected policy update revokes permission to transmit data to a specified external endpoint. PV-2217 advances the authorization-state version applicable to the defined replica scope. One replica has not yet refreshed its local application-level policy cache. Das Expires 19 April 2027 [Page 924] Internet-Draft Protected AI Execution Finality October 2026 It submits a previously prepared outbound request and presents a capability bound to an incompatible earlier authorization-state version. The cloud network Finality Sink checks the required current protected version. The capability is rejected. The operation remains non-effective despite the replica's stale local policy view. The result depends upon the Finality Sink having access to sufficiently current protected authorization state under the specified version-enforcement model. 11.22.39. WF-22.39 — Illustrative SmartNIC-Supervised Agent Egress An AI agent runs within a virtualized cloud compute environment. The workload has valid cloud-network identity and can prepare an HTTPS request. The actual outbound interface is controlled by a SmartNIC-associated Finality Sink. The PED validates the Candidate Act against its source workload, measured execution context, destination, operation type, current authorization-state version, and required policy. A scoped capability becomes available. The SmartNIC verifies the capability against the actual operation and authenticated workload context. Only the authorized outbound request is admitted. The ability to establish a virtual network interface or authenticated cloud session does not independently permit unverified network effectuation. 11.22.40. WF-22.40 — Illustrative Snapshot Replay An AI workload receives a single-use capability for one protected external operation. The operation is performed and the capability is consumed. Das Expires 19 April 2027 [Page 925] Internet-Draft Protected AI Execution Finality October 2026 The workload is then restored from a snapshot created before execution. The restored workload contains the earlier capability representation. However, the authoritative protected capability-consumption state records that the grant is already consumed. The restored workload attempts to repeat the operation. The downstream Finality Sink consults the required current state and refuses reuse. Snapshot restoration does not revive previously consumed execution authority. 11.22.41. WF-22.41 — Illustrative Model-Path and Effectuation-Path Separation An AI agent obtains valid access to a remote model and produces a proposed network transmission. The model-access component authorizes the inference. The generated transmission is classified as a Candidate Act and held in a Non-Effective State. A security component subsequently interrupts further model access. The buffered transmission remains pending. The downstream network Finality Sink requires a separately valid operation-specific execution capability. If the required capability is absent or invalid, the transmission is refused. The previous successful model call does not authorize the transmission, and the model interruption does not itself discharge downstream verification. 11.22.42. WF-22.42 — Time-of-Check and Time-of-Use Protection The protected system preserves the relationship between the Candidate Act originally authorized and the operation actually presented at the Finality Sink. Potential changes include: Das Expires 19 April 2027 [Page 926] Internet-Draft Protected AI Execution Finality October 2026 (a) workload instance substitution; (b) VM migration; (c) container image replacement; (d) policy update; (e) destination substitution; (f) payload modification; (g) protected deployment-epoch change; (h) different Finality Sink; (i) revoked workload identity; or (j) restored authorization state. The Finality Sink verifies the actual operation and current mandatory context. Where exact correspondence is required, incompatible changes cause rejection. Where an Authority Object expressly permits bounded migration or workload-equivalent scope, verification follows those defined conditions. Portability is therefore governed by authenticated authority rather than unrestricted transfer of a previously issued capability. 11.22.43. WF-22.43 — Fail-Closed Runtime Policy Handling The system refuses the affected consequential operation when mandatory current authorization information is unavailable. Examples include: (a) inability to verify the executing workload identity; (b) missing required execution measurement; (c) unavailable current authorization-state version; (d) stale or revoked policy state; Das Expires 19 April 2027 [Page 927] Internet-Draft Protected AI Execution Finality October 2026 (e) failed capability authentication; (f) invalid deployment epoch; (g) consumed nonce; (h) unavailable Finality Sink verification; or (i) inconsistent protected recovery state. The system may retain the Candidate Act pending authorized recovery or revalidation. It does not automatically substitute an earlier cached policy result when the current required authorization state cannot be established. 11.22.44. WF-22.44 — Alternative Technical Implementations Container implementation: A protected runtime identity and execution- capability mechanism govern operations across container deployment and replacement. Virtual-machine implementation: Workload authority is bound to the required VM identity, measurement, and policy state. Confidential-VM implementation: Hardware-backed attestation contributes authenticated execution-context evidence while downstream Candidate Act authority remains separately enforced. Kubernetes implementation: Replicated workloads share an expressly defined protected authorization-state scope, with version checks at affected Finality Sinks. On-premises implementation: A locally protected host controller or gateway governs operations without requiring a particular public cloud. Hybrid-cloud implementation: Workload authority is validated across authenticated cloud and on-premises execution environments. Multi-region implementation: Failover reestablishes the required workload context and protected authorization state before pending operations are released. SmartNIC/DPU implementation: Hardware-associated network egress enforces the operation-specific capability independently of cloud connectivity. Das Expires 19 April 2027 [Page 928] Internet-Draft Protected AI Execution Finality October 2026 Service-mesh implementation: A protected proxy verifies the scoped capability before permitting a governed service operation. Accelerator implementation: An accelerator-egress controller enforces the required capability before protected data export. Single-node implementation: The PED and Finality Sink may reside within one protected host while maintaining their distinct authorization and effectuation-verification functions. Distributed implementation: Protected authority and Finality Sink services operate on separate nodes using authenticated capability and state information. The implementation must establish its own workload identity, protected-state continuity, revocation, migration, and path-coverage guarantees. 11.22.45. WF-22.45 — Failure and Fail-Closed Conditions The system withholds effectuation when a mandatory condition is invalid, absent, inconsistent, expired, revoked, replayed, or unverifiable. Non-limiting conditions include: (a) unauthorized execution substrate; (b) invalid workload identity; (c) incompatible workload measurement; (d) unapproved container image; (e) invalid VM launch measurement; (f) agent runtime identity mismatch; (g) tool-policy digest mismatch; (h) model configuration mismatch; (i) protected execution-policy mismatch; (j) unauthorized Candidate Act; (k) destination or operation-scope violation; Das Expires 19 April 2027 [Page 929] Internet-Draft Protected AI Execution Finality October 2026 (l) incompatible authorization-state version; (m) stale policy epoch; (n) revoked workload grant; (o) invalid deployment epoch; (p) migration-context mismatch; (q) snapshot-restored nonce; (r) consumed execution capability; (s) failed mandatory protected-state transition; (t) failed required validation-evidence commitment; (u) missing scoped capability; (v) invalid capability authentication; (w) unauthorized Finality Sink; (x) cloud egress context mismatch; (y) failed required hardware verification; (z) attempted unauthorized duplicate effectuation; or (aa) unavailable mandatory effectuation-boundary enforcement. Failure of workload deployment, policy synchronization, or runtime recovery does not create unrestricted execution authority. 11.22.46. WF-22.46 — PHOSITA Verification and Negative Tests A person having ordinary skill in cloud computing, virtual-machine security, container orchestration, distributed authorization, SmartNIC/DPU enforcement, confidential computing, and protected AI execution may verify the architecture through controlled tests. Test 1 — Authorized cloud operation: Deploy an approved workload and submit a Candidate Act satisfying all required authorization conditions. The Finality Sink permits the scoped effect. Das Expires 19 April 2027 [Page 930] Internet-Draft Protected AI Execution Finality October 2026 Test 2 — Invalid workload identity: Present a capability through a different unauthorized workload. Required identity verification fails. Test 3 — Container image substitution: Change a mandatory approved image digest. The protected authorization is refused. Test 4 — VM measurement mismatch: Present an incompatible VM measurement. Required measurement verification fails. Test 5 — Tool-policy modification: Alter a mandatory approved tool- policy digest. The Candidate Act cannot use a capability bound to the earlier condition. Test 6 — Model configuration substitution: Change the required model configuration. Protected authorization fails where the changed measurement is mandatory. Test 7 — Missing execution capability: Provide valid workload authentication without an operation-specific capability. The Finality Sink refuses effectuation. Test 8 — Unauthorized destination: Substitute a destination outside the capability scope. Actual-operation verification fails. Test 9 — Replica policy update: Advance a protected authorization version while a replica retains older policy state. The affected Finality Sink rejects incompatible earlier capabilities. Test 10 — Stale replica restart: Restart a workload under an obsolete authorization-state version. The new consequential operation remains subject to current-state verification. Test 11 — Container replacement: Replace the executing container and attempt to reuse a capability bound to an incompatible previous identity or measurement. Verification fails. Test 12 — VM migration: Move the workload to another VM and revalidate pending Candidate Acts under the changed mandatory context. Test 13 — Cloud-region failover: Recover the workload in another region without automatically restoring stale effectuation authority. Test 14 — Snapshot rollback: Restore an earlier snapshot containing a consumed capability. The Finality Sink rejects the replay. Das Expires 19 April 2027 [Page 931] Internet-Draft Protected AI Execution Finality October 2026 Test 15 — Concurrent replica execution: Submit competing effects under one restricted authorization grant. Protected state prevents unauthorized duplicate consumption. Test 16 — Failover after uncertain completion: Simulate an operation that may have completed before failover. Recovery preserves indeterminate state and avoids unauthorized automatic repetition. Test 17 — Hardware cloud egress: Present a capability to a protected SmartNIC/DPU controller and verify bounded operation-specific enforcement. Test 18 — Cloud authentication without capability: Successfully authenticate the workload to the cloud network but omit the execution capability. The governed transmission is refused. Test 19 — Wrong Finality Sink: Present a capability issued for one gateway or interface at another unauthorized sink. Required sink binding fails. Test 20 — Policy-version rollback: Attempt to restore an obsolete protected authorization-state version. The required protected-state mechanism rejects incompatible authority. Test 21 — Revocation during migration: Revoke a mandatory operation permission while the workload changes execution substrate. The subsequent effectuation remains blocked. Test 22 — Missing policy service: Make the required current protected policy state unavailable. The Finality Sink refuses the affected operation. Test 23 — Model-access authorization only: Admit a model computation without issuing downstream operation-specific authority. The consequential operation remains non-effective. Test 24 — Model-path quarantine: Interrupt future inference after a Candidate Act is buffered. The downstream Finality Sink continues to enforce its authorization independently. Test 25 — Service-mesh bypass: Attempt the governed effect through an alternative available service or network path. The implementation blocks or equivalently mediates it. Test 26 — On-premises to cloud migration: Move an agent from an on- premises host into a cloud VM and validate current workload identity, measurement, and policy state. Das Expires 19 April 2027 [Page 932] Internet-Draft Protected AI Execution Finality October 2026 Test 27 — Single-node enforcement: Implement PED and Finality Sink functions within one host while preserving mandatory operation- specific verification. Test 28 — Distributed enforcement: Verify protected authorization at one node and effectuation at another, using current authenticated operation and policy state. Test 29 — Stale capability after redeployment: Reinstantiate an agent under a new protected deployment epoch and attempt an incompatible earlier capability. Verification fails. Test 30 — Capability-consumption continuity: Verify that protected usage state is preserved across restart, migration, and failover. Test 31 — Actual operation mutation: Alter mandatory operation parameters after authorization. The Finality Sink refuses the changed operation. Test 32 — Recovery of valid pending act: Restore a pending operation under a current valid execution context and perform the required revalidation before effectuation. Test 33 — Independent receiving-side consequence: Authorize network transmission but withhold separately required database-commit authority. The downstream commit remains blocked. Test 34 — Confirmed effect versus attempted effect: Simulate a successful capability verification without confirmed remote completion. Preserve the distinction between authorization and completed outcome. The tests may use Kubernetes clusters, container runtimes, confidential-VM fixtures, multi-region cloud simulators, authenticated workload identity services, protected authorization stores, programmable SmartNIC/DPU interfaces, mock downstream services, snapshot tooling, and fault injection. The results establish only the properties actually demonstrated by the implementation and its defined threat model. 11.22.47. WF-22.47 — Claim-Specific Technical Support Enforcement Point 90 — Portable Cloud-VM Agent Authority and Hardware Effectuation System WF-22.2 through WF-22.20 describe: Das Expires 19 April 2027 [Page 933] Internet-Draft Protected AI Execution Finality October 2026 (a) the agent-execution control plane; (b) deployment across cloud and virtualized substrates; (c) authenticated workload identity and execution-context measurement; (d) Protected Enforcement Domain maintenance of authorization-state versions and execution-policy predicates; (e) Candidate Act interception and Non-Effective State holding; (f) protected act-specific validation; (g) cryptographically scoped capability issuance; (h) independent verification by a designated host, VM, cloud gateway, service-mesh, protected connector, SmartNIC, DPU, or accelerator Finality Sink; and (i) prevention of automatic restoration of stale or incompatible execution authority following redeployment or recovery. Enforcement Point 91 — VM and Container Identity Attestation WF-22.5 through WF-22.7 describe validation of workload image digest, VM launch measurement, container image identity, runtime identity, tool-policy digest, model configuration digest, and applicable protected policy state. Capabilities are rejected when mandatory workload identity or measurement does not correspond to the actual executing instance. Enforcement Point 92 — Runtime Policy Changes Across Cloud Replicas WF-22.21 through WF-22.23 describe protected authorization-state version advancement across defined workload scopes and rejection of capabilities bound to incompatible previous versions. Enforcement Point 93 — Hardware-Supervised Cloud Egress WF-22.24 and WF-22.25 describe SmartNIC, DPU, protected network gateway, or hardware-assisted egress enforcement and distinguish ordinary network authentication from operation-specific execution authority. Enforcement Point 94 — Cross-Runtime Migration and Snapshot Protection Das Expires 19 April 2027 [Page 934] Internet-Draft Protected AI Execution Finality October 2026 WF-22.26 through WF-22.33 describe runtime migration, container replacement, rescheduling, checkpoint restoration, region failover, changed workload context, pending Candidate Act revalidation, capability-consumption continuity, and duplicate-effectuation protection. Enforcement Point 95 — Model-Path Authorization Does Not Replace Effectuation Authorization WF-22.34 through WF-22.36 describe separate model-access and downstream effectuation authorization. Successful inference admission does not grant an operation-specific capability, and interruption or quarantine of future model access does not permit release of a buffered, unverified Candidate Act. 11.22.48. WF-22.48 — Technical Effect The workflow establishes protected operation-specific authority that remains valid only under the actual authorized workload, execution context, policy version, and Finality Sink requirements. The protected sequence comprises: (a) deployment or reinstantiation of an AI workload on a supported execution substrate; (b) establishment of authenticated workload identity; (c) machine-verifiable execution-context measurement; (d) protected registration of applicable workload authority and authorization-state version; (e) generation of a consequential Candidate Act; (f) interception and Non-Effective State staging; (g) construction of the effectuation-relevant operation descriptor; (h) protected validation of the actual operation, workload, measurement, and current authorization state; (i) required protected-state and validation-evidence handling; (j) generation or availability of a cryptographically scoped execution capability; Das Expires 19 April 2027 [Page 935] Internet-Draft Protected AI Execution Finality October 2026 (k) independent Finality Sink verification; (l) controlled effectuation or fail-closed withholding; (m) authorization-version advancement across affected replicas; (n) revalidation after relevant migration or runtime changes; (o) continuity of protected consumption and revocation state across snapshots and failover; and (p) continued separation of model-access permission from downstream execution authority. The architecture prevents cloud workload portability from becoming a mechanism for restoring stale or consumed authority. The replica policy-version mechanism prevents incompatible earlier permissions from governing new operations where current-version checks are mandatory. The hardware-egress embodiment prevents ordinary cloud connectivity from substituting for the required protected execution-capability verification. The migration and recovery embodiment maintains operation-specific authorization across runtime transitions without assuming unconditional exactly-once completion of arbitrary external systems. Computation is not authority to act. Workload portability is not automatic portability of execution authority. Cloud identity is not operation-specific authorization. A restarted or restored workload must not revive stale or consumed capabilities. Authorization to access a model is not authorization to execute a model-generated operation. The actual Finality Sink verifies the authority applicable to the consequential effect. Das Expires 19 April 2027 [Page 936] Internet-Draft Protected AI Execution Finality October 2026 11.23. WF-23 — Atomic Protected-State Consumption, Validation-Evidence Commitment, Non-Bearer Capability Replay Prevention, Crash- Consistent Finality, and Duplicate-Effect Recovery 11.23.1. WF-23.1 — Technical Purpose This embodiment describes a computer-implemented protected execution- finality architecture for maintaining the consistency, ordering, freshness, consumption, and recovery of authorization state associated with consequential operations generated by artificial- intelligence agents or other computational workloads. The architecture addresses circumstances in which a Candidate Act is validly proposed but must not become effective unless the required protected authorization sequence is completed. The system prevents a previously issued grant, capability, validation receipt, or authorization decision from enabling an unauthorized additional consequential effect through replay, concurrent use, stale state, interrupted commitment, process failure, communication timeout, virtual-machine restoration, or recovery. A proposed consequential operation is classified as a Candidate Act and maintained in a Non-Effective State. The applicable Protected Enforcement Domain validates the operation against the required Authority Object, execution context, current authorization state, freshness, revocation, and Finality Sink conditions. Where the applicable embodiment requires an Atomic Protected-State Transition, required authorization-state updates are committed with the consistency and ordering necessary to prevent unauthorized effectuation. Where the embodiment requires Atomic State Consumption and Atomic Finality Commit, the protected authorization-state update, validation-evidence commitment, and capability availability are coordinated as a protected finality transaction. The operation-specific capability becomes usable only when the mandatory protected dependencies succeed. The designated Finality Sink independently verifies the capability against the actual Candidate Act and applicable current protected state immediately before permitting the operation. Das Expires 19 April 2027 [Page 937] Internet-Draft Protected AI Execution Finality October 2026 The protected system maintains distinguishable states for authorization, reservation, attempted effectuation, confirmed completion, denial, revocation, and indeterminate outcome. A retry after timeout, crash, or communication failure is correlated with the original Candidate Act and protected authorization state. Uncertainty about an earlier external effect does not independently authorize a second execution. This embodiment further distinguishes local prevention of unauthorized capability reuse from exactly-once delivery or completion across arbitrary external systems. 11.23.2. WF-23.2 — Participating Technical Components In one non-limiting implementation, the system comprises the following components. AE-2301 — AI Execution Environment An artificial-intelligence agent, autonomous process, model runtime, tool environment, sandbox, confidential workload, or other computational component configured to generate Candidate Acts. IM-2302 — Candidate Act Interception Component A mandatory enforcement-controlled mechanism configured to intercept a proposed consequential operation before the applicable execution- finality boundary. HQ-2303 — Non-Effective Candidate Act Holding Mechanism A controlled queue, buffer, staged command, inactive transaction request, or equivalent mechanism preventing the operation from becoming effective before required authorization. DC-2304 — Candidate Act Descriptor Component A component configured to construct or verify the canonical, machine- readable representation of the actual proposed operation. PED-2305 — Protected Enforcement Domain A protected authority component configured to validate the Candidate Act and coordinate the required authorization-state transition, evidence commitment, and capability availability. Das Expires 19 April 2027 [Page 938] Internet-Draft Protected AI Execution Finality October 2026 AS-2306 — Protected Authority Store An authenticated source of Authority Objects, permitted operation classes, grant restrictions, execution scope, policy epochs, and revocation information. GS-2307 — Protected Grant-State Store A protected mechanism maintaining active grants, authorized operations, permitted usage counts, validity intervals, reserved authorizations, and revocation state. TX-2308 — Atomic Protected-State Transaction Component A mechanism configured to perform required authorization-state operations with the ordering and consistency necessary to prevent unauthorized effectuation from incomplete or inconsistent state handling. EV-2309 — Protected Validation-Evidence Component A mechanism configured to generate or commit the required validation receipt, LAVR, AVR, authenticated state commitment, or equivalent evidence. CR-2310 — Scoped Execution-Capability Mechanism A protected component configured to prepare, issue, register, activate, release, or otherwise make available a scoped, non-bearer execution capability. CS-2311 — Protected Capability-Consumption Store A mechanism maintaining protected capability usage, nonce state, authorization generations, consumption reservations, and replay- prevention information. FS-2312 — Finality Sink An execution-controlled network, credential, tool, storage, financial, hardware, API, or other effectuation boundary configured to verify the required capability before completing the governed effect. OC-2313 — Protected Operation-State Controller A mechanism maintaining the formal execution-finality state of each Candidate Act. Das Expires 19 April 2027 [Page 939] Internet-Draft Protected AI Execution Finality October 2026 OS-2314 — Protected Effectuation-Outcome Store A protected mechanism maintaining whether an operation is pending, reserved, denied, confirmed effective, or of indeterminate completion status. RC-2315 — Protected Recovery Controller A component configured to coordinate recovery after crashes, timeouts, process restarts, communication failures, and other interrupted execution-finality procedures. DR-2316 — Duplicate-Effect Prevention Component A mechanism configured to correlate repeated execution attempts with the original operation and enforce the applicable consumption and retry restrictions. RV-2317 — Protected Revocation and Epoch Controller A component configured to maintain or verify current required authorization epochs, revocation state, and protected execution generations. HF-2318 — Optional Hardware Freshness Component A trusted counter, hardware sequence, secure boot epoch, protected clock, or corresponding mechanism supporting freshness and rollback resistance where required. RR-2319 — Optional Receiving-Side Reconciliation Component An authenticated remote operation-status, idempotency, or completion- evidence interface used when supported by the external receiving system. SC-2320 — Protected State-Consistency Component A mechanism configured to maintain or verify the required correspondence among the Candidate Act, grant, validation receipt, capability, Finality Sink, and effectuation outcome. The components may be integrated within a protected node or distributed across authenticated components. The same physical component may perform several roles without eliminating the required authorization dependencies. Das Expires 19 April 2027 [Page 940] Internet-Draft Protected AI Execution Finality October 2026 11.23.3. WF-23.3 — Establishment of the Protected Authorization Boundary The architecture establishes a protected boundary between the AI execution environment and the authority required to complete consequential operations. AE-2301 may: (a) generate requests; (b) prepare commands; (c) create transaction parameters; (d) calculate operation descriptors; (e) invoke permitted computational tools; (f) submit proposed operations; or (g) receive authorization or completion status. However, AE-2301 cannot unilaterally: (a) modify protected grant-consumption state; (b) mark a consumed capability as unused; (c) fabricate a valid protected validation commitment; (d) advance or reverse protected authorization epochs; (e) override mandatory Finality Sink verification; (f) authorize unrestricted duplicate execution; (g) convert an interrupted operation into an authorized retry; or (h) restore previously invalidated authority merely by restarting its process. The protected state mechanism is isolated from the requesting workload's unilateral control under the applicable threat model. The Finality Sink enforces the required capability-dependent conditions at the actual governed effectuation boundary. Das Expires 19 April 2027 [Page 941] Internet-Draft Protected AI Execution Finality October 2026 11.23.4. WF-23.4 — Distinguishing Authorization from Effectuation The architecture distinguishes at least the following events. Validation: The protected authority determines that the proposed Candidate Act satisfies its required predicates. State reservation or consumption: Protected authorization state is advanced, reserved, or consumed according to the applicable usage conditions. Validation-evidence commitment: Required protected evidence of successful authorization is established. Capability availability: The scoped execution capability becomes valid and available for the designated operation. Finality Sink verification: The actual effectuation interface independently verifies the capability and required current state. Effectuation: The consequential operation crosses the governed execution-finality boundary. Outcome confirmation: Evidence establishes whether the specified effect completed under the applicable completion semantics. These events may be coordinated closely or implemented through a protected transactional procedure. However, they are not automatically identical. In particular, successful authorization does not itself establish completion of an external effect. Likewise, capability preparation does not independently authorize effectuation when mandatory protected commitment or Finality Sink verification remains incomplete. 11.23.5. WF-23.5 — Candidate Act Generation AE-2301 generates a proposed consequential operation. The operation may comprise: (a) a network transmission; (b) an external API invocation; Das Expires 19 April 2027 [Page 942] Internet-Draft Protected AI Execution Finality October 2026 (c) a credential-mediated request; (d) a protected file modification; (e) a database commit; (f) a message publication; (g) a financial transaction; (h) an accelerator transfer; (i) a software deployment; or (j) another governed consequential operation. The proposed operation is classified as Candidate Act CA-2321. The Candidate Act has an identity distinct from any particular execution attempt. This distinction permits multiple observations or recovery attempts to be associated with one protected operation without automatically granting additional effectuation authority. 11.23.6. WF-23.6 — Candidate Act Identifier and Attempt Identifier In one implementation, the system maintains: candidate_act_id; attempt_id; operation_descriptor_digest; source_workload_identity; authorized_operation_scope; finality_sink_identity. The Candidate Act identifier represents the governed consequential operation. An attempt identifier represents one submission or attempted effectuation of that operation. Das Expires 19 April 2027 [Page 943] Internet-Draft Protected AI Execution Finality October 2026 Several attempt identifiers may refer to one Candidate Act when communication retries or recovery procedures occur. Such association does not authorize multiple external effects. The protected system evaluates the existing authorization and outcome state before permitting another attempt. A retry is not treated as an unrelated new Candidate Act merely because the requesting workload generates a new transport request or application-level identifier. 11.23.7. WF-23.7 — Interception and Non-Effective State IM-2302 intercepts CA-2321 before the applicable effectuation boundary. HQ-2303 retains the operation in a Non-Effective State. An illustrative staged operation record comprises: candidate_act_id; operation_class; requesting_workload; target_resource; destination; payload_reference; descriptor_reference; policy_epoch; grant_reference; finality_sink_id; status = NON_EFFECTIVE. The operation remains unable to complete the governed effect until required protected authorization and Finality Sink verification succeed. Das Expires 19 April 2027 [Page 944] Internet-Draft Protected AI Execution Finality October 2026 The system does not treat successful queue insertion as execution permission. 11.23.8. WF-23.8 — Canonical Candidate Act Descriptor DC-2304 constructs a canonical machine-readable representation of CA- 2321. The descriptor may identify: (a) Candidate Act identity; (b) operation class; (c) requesting workload; (d) destination or recipient; (e) resource identifier; (f) effectuation-relevant parameters; (g) payload digest; (h) applicable authority and grant; (i) protected policy epoch; (j) authorization-state version; (k) nonce and expiry; and (l) designated Finality Sink. An illustrative representation is: Dact = Canon_v(ID, ACT, SOURCE, TARGET, PARAM, AUTH, EPOCH, NONCE, SINK) where the fields represent the corresponding Candidate Act, operation, source, destination, parameters, authorization context, protected state version, freshness, and Finality Sink. An illustrative digest is: hAct = H("DAS-ATOMIC-FINALITY-ACT-v1" || Encode(Dact)) Das Expires 19 April 2027 [Page 945] Internet-Draft Protected AI Execution Finality October 2026 The deterministic encoding must preserve distinctions that affect the relevant authorization. The particular hash function, field order, and serialization format are implementation choices. 11.23.9. WF-23.9 — Protected Grant-State Record in the implementation described by enforcement point 20, GS-2307 maintains a protected authorization-state record identifying: (a) an active grant; (b) authorized operation; (c) validity interval; (d) permitted usage count; and (e) revocation state. An illustrative record comprises: grant_id; authority_object_id; authorized_operation_class; authorized_candidate_act_scope; valid_from; valid_until; remaining_uses; reserved_uses; revocation_state; policy_epoch; authorization_state_version; protected_authentication. Das Expires 19 April 2027 [Page 946] Internet-Draft Protected AI Execution Finality October 2026 The protected record determines whether the grant can support the proposed consequential operation. Possession of a copy of a grant identifier does not independently establish that the grant remains usable. 11.23.10. WF-23.10 — Grant Eligibility Verification PED-2305 evaluates the applicable grant. The required conditions may include: (a) grant authenticity; (b) authorized operation class; (c) permitted destination; (d) valid time interval; (e) current revocation state; (f) remaining usage allowance; (g) applicable policy epoch; (h) required source identity; (i) Candidate Act Descriptor correspondence; and (j) intended Finality Sink. An illustrative predicate is: Vgrant = AuthenticGrant AND ScopeValid AND TimeValid AND UsageAvailable AND NotRevoked AND StateValid If a mandatory condition fails, the grant cannot authorize the requested consequential operation. An earlier positive decision does not override current protected usage or revocation state when those checks are mandatory. 11.23.11. WF-23.11 — Atomic Protected-State Transition TX-2308 coordinates the required authorization-state changes. Das Expires 19 April 2027 [Page 947] Internet-Draft Protected AI Execution Finality October 2026 For an operation requiring single-use consumption, the transition may: (a) verify that the grant is active; (b) verify that its usage allowance is available; (c) verify the applicable nonce; (d) reserve or decrement the permitted usage count; (e) register the Candidate Act identity; (f) update protected authorization state; and (g) establish the corresponding protected transition result. These related state operations are performed with the required consistency and ordering. Where an atomic protected-state transition is mandatory, the relevant updates commit together or fail together. A failed mandatory transition does not make the corresponding execution-enabling authority usable. This atomicity need not encompass the entire remote external service operation. 11.23.12. WF-23.12 — Concurrency and Double-Consumption Prevention Two or more execution attempts may concurrently request authority under the same restricted grant. An illustrative race comprises: Attempt A reads remaining_uses = 1. Attempt B reads remaining_uses = 1. Both attempts seek to consume the same grant. A non-atomic check followed by an unprotected update may permit both attempts to proceed. The protected system instead uses a suitable atomic state transition, compare-and-swap operation, transaction, protected serialization mechanism, or equivalent consistency control. Das Expires 19 April 2027 [Page 948] Internet-Draft Protected AI Execution Finality October 2026 Only a number of attempts within the expressly permitted usage allowance may successfully reserve or consume authority. When only one consequential effect is authorized, competing incompatible attempts cannot each obtain independently valid execution authority. 11.23.13. WF-23.13 — Protected Grant Reservation In an implementation requiring a reservation before final effectuation, TX-2308 transitions the grant into a protected reserved state. An illustrative transition is: GRANT_ACTIVE → GRANT_RESERVED_FOR_ACT. The reservation record may contain: grant_id; candidate_act_id; operation_descriptor_digest; reservation_id; reserved_usage; policy_epoch; nonce; finality_sink_id; reservation_status. The reservation associates the grant with the specific Candidate Act. A reservation is not treated as proof that the external operation completed. The protected system enforces the applicable rule determining whether and when a reservation can be released, consumed, retired, or retried. Das Expires 19 April 2027 [Page 949] Internet-Draft Protected AI Execution Finality October 2026 11.23.14. WF-23.14 — Atomic Finality Commit Where the embodiment requires Atomic Finality Commit, the protected system coordinates: (a) successful authority validation; (b) required grant reservation or consumption; (c) protected authorization-state update; (d) required validation-evidence commitment; and (e) capability availability. An illustrative protected transaction is: (Snext, Ract, CapabilityReady) = CommitFinality(Dact, A, Scurrent, F) where: Snext denotes the committed protected authorization state; Ract denotes the corresponding protected validation evidence; CapabilityReady denotes successful completion of all mandatory pre- release dependencies; Dact denotes the validated Candidate Act Descriptor; A denotes applicable authenticated authority; Scurrent denotes the prior protected state; and F denotes the designated Finality Sink. Where atomic commitment is required, an incomplete mandatory transaction cannot produce a valid usable capability. The implementation does not require one globally distributed transaction encompassing every remote effectuation system. 11.23.15. WF-23.15 — Protected Validation-Evidence Commitment EV-2309 generates or commits the protected validation evidence applicable to CA-2321. An illustrative record comprises: Das Expires 19 April 2027 [Page 950] Internet-Draft Protected AI Execution Finality October 2026 receipt_id; candidate_act_id; descriptor_digest; grant_id; authority_object_reference; validated_predicate_reference; protected_state_transition; consumption_or_reservation_reference; policy_epoch; nonce; finality_sink_id; authorization_result; protected_authentication. The record may comprise a LAVR, AVR, sealed validation record, authenticated state commitment, or another supported protected artifact. Where required, the validation evidence participates in the protected pre-effectuation dependency rather than being created solely as a post-event audit log. A successful post-operation log entry does not establish that mandatory protected validation evidence existed before capability availability. 11.23.16. WF-23.16 — Capability Preparation Versus Capability Release The protected system may prepare a capability representation before completing all required state or evidence operations. However, the capability does not become valid or usable for the governed effect until the mandatory prerequisites succeed. The system distinguishes: Das Expires 19 April 2027 [Page 951] Internet-Draft Protected AI Execution Finality October 2026 CAPABILITY_PREPARED; CAPABILITY_RELEASED; CAPABILITY_VALID_AT_SINK; CAPABILITY_CONSUMED. A prepared capability may remain sealed, inactive, or otherwise unavailable. Where a capability-registration model is used, a protected table entry does not become active until the required commit condition succeeds. An incomplete state transition cannot be bypassed merely because the cryptographic bytes of a proposed capability were computed earlier. 11.23.17. WF-23.17 — Scoped Non-Bearer Capability CR-2310 makes available the execution capability corresponding to the validated Candidate Act. The capability may bind: (a) Candidate Act Descriptor digest; (b) grant identity; (c) authorized operation; (d) source workload; (e) destination; (f) protected state version; (g) validation-evidence digest; (h) policy epoch; (i) nonce; (j) expiry; (k) permitted usage; and (l) designated Finality Sink. Das Expires 19 April 2027 [Page 952] Internet-Draft Protected AI Execution Finality October 2026 An illustrative authenticated representation is: Cact = Sign_skPED(Encode(hAct, hReceipt, GrantID, StateVersion, Scope, Epoch, Nonce, Expiry, Sink)) The selected implementation may alternatively employ a MAC- authenticated permit, protected capability table, sealed handle, authenticated grant-state reference, or equivalent execution- enablement mechanism. The capability's non-bearer properties derive from enforcement of its required operation, context, protected-state, usage, and sink bindings. Physical non-copyability is not universally required unless expressly specified. 11.23.18. WF-23.18 — Current-State Finality Sink Verification Before permitting the governed operation, FS-2312 verifies the actual Candidate Act and required protected capability conditions. The checks may include: (a) capability authenticity; (b) Candidate Act Descriptor correspondence; (c) grant identity and scope; (d) applicable current policy epoch; (e) protected authorization-state version; (f) nonce and expiry; (g) capability reservation or usage state; (h) validation-evidence commitment; (i) destination or recipient; (j) requesting workload identity; (k) required revocation state; and (l) Finality Sink identity. Das Expires 19 April 2027 [Page 953] Internet-Draft Protected AI Execution Finality October 2026 A capability that was valid when issued does not automatically remain valid under incompatible current state when current verification is mandatory. The Finality Sink refuses operations whose required authorization state no longer permits effectuation. 11.23.19. WF-23.19 — Finality Verification Predicate An illustrative verification condition is: PermitAct = Auth(C) AND Match(C,Dactual) AND GrantValid(C,Gcurrent) AND StateValid(C,Scurrent) AND EvidenceValid(C,R) AND SinkValid(C,F) where: C denotes the execution capability; Dactual denotes the actual effectuation descriptor; Gcurrent denotes applicable current protected grant state; Scurrent denotes protected authorization and usage state; R denotes required committed validation evidence; and F denotes the designated Finality Sink. The operation may cross the governed finality boundary only when all mandatory predicates succeed. An earlier ordinary application-level allow decision does not replace the required capability and protected-state verification. Das Expires 19 April 2027 [Page 954] Internet-Draft Protected AI Execution Finality October 2026 11.23.20. WF-23.20 — Capability Consumption at Effectuation Where the capability is single-use or usage-bounded, the protected system consumes, invalidates, reserves, or advances the relevant usage state before, or atomically with, permitted effectuation, according to the selected embodiment. A representative transition is: USABLE → EFFECTUATION_RESERVED → CONSUMED. The reservation or consumption mechanism prevents unauthorized concurrent acceptance of the same restricted authorization. For an interface controlled locally, the protected Finality Sink may coordinate the state transition with admission of the operation. For a remote external interface, the state transition may establish local authority usage while external completion remains separately recorded. The architecture does not assume that local consumption can be atomically committed with an arbitrary remote system's irreversible operation. 11.23.21. WF-23.21 — Formal Candidate Act State Machine OC-2313 maintains a bounded execution-finality state machine. Non-limiting states include: NON_FINAL; DESCRIPTOR_PENDING; DESCRIPTOR_FORMED; VALIDATION_PENDING; VALIDATION_FAILED; HELD; QUARANTINED; ESCALATED; CAPABILITY_PREPARED; Das Expires 19 April 2027 [Page 955] Internet-Draft Protected AI Execution Finality October 2026 CAPABILITY_RELEASED; SINK_VERIFIED; RELEASED; DENIED; REVOKED; EXPIRED; ZEROIZED. For recovery purposes, the implementation may additionally distinguish: CONSUMPTION_RESERVED; EFFECTUATION_ATTEMPTED; CONFIRMED_EFFECTIVE; INDETERMINATE. The states are not presumed to have identical semantics. In particular, CAPABILITY_RELEASED does not itself mean RELEASED or CONFIRMED_EFFECTIVE. A Candidate Act transitions to an externally effective state only after satisfying the required Finality Sink verification and effectuation conditions. 11.23.22. WF-23.22 — Protected Effectuation Outcome State in the implementation described by enforcement point 31, OS-2314 maintains an operation-specific effectuation status. The minimum stated categories comprise: (a) pending; (b) reserved for effectuation; (c) confirmed effective; (d) denied; and Das Expires 19 April 2027 [Page 956] Internet-Draft Protected AI Execution Finality October 2026 (e) indeterminate completion. A representative state record comprises: candidate_act_id; operation_descriptor_digest; grant_id; capability_id; effectuation_attempt_id; finality_sink_id; status; reservation_reference; consumption_reference; protected_state_version; last_verified_policy_epoch; completion_evidence_reference. Subsequent attempts are evaluated against the operation-specific outcome and authorization state. The effectuation record is not merely a historical diagnostic log where its protected status is a mandatory predicate for preventing unauthorized duplicate execution. 11.23.23. WF-23.23 — Distinction Between Reserved and Confirmed Effective A reserved operation has obtained or reserved protected authorization for a possible effectuation attempt. A confirmed-effective operation has sufficient evidence establishing completion of the specified effect under the applicable Finality Sink or receiving-system semantics. The following inference is not assumed: RESERVED implies CONFIRMED_EFFECTIVE. Das Expires 19 April 2027 [Page 957] Internet-Draft Protected AI Execution Finality October 2026 Likewise: CAPABILITY_CONSUMED does not necessarily imply REMOTE_OPERATION_COMPLETED. For example, a protected network gateway may consume a single-use capability and begin transmitting an authorized request. If communication fails afterward, the gateway may be unable to determine whether the receiving service committed its operation. The protected outcome state therefore preserves the possibility of indeterminate completion. 11.23.24. WF-23.24 — Anti-Replay Protection in the implementation described by enforcement point 33, the scoped execution capability is bound to: (a) nonce; (b) policy epoch; (c) authorization-state version; (d) operation descriptor; and (e) Finality Sink identity. The Finality Sink verifies those values against the current required execution context immediately before effectuation. The protected system consumes, invalidates, or advances capability- usage state before, or atomically with, permitted effectuation. A replayed capability is refused when its protected usage state no longer permits the requested operation. The anti-replay mechanism may use nonce verification, protected counters, session binding, capability-consumption records, or equivalent protected state. No one mechanism is presumed mandatory across every implementation unless the corresponding claim expressly requires it. Das Expires 19 April 2027 [Page 958] Internet-Draft Protected AI Execution Finality October 2026 11.23.25. WF-23.25 — Replay-Prevention Predicate An illustrative anti-replay predicate is: ReplayAcceptable = NonceValid AND EpochValid AND StateVersionValid AND UsageAvailable AND OperationMatch AND SinkMatch where: NonceValid verifies the required nonce or freshness condition; EpochValid verifies the required policy epoch; StateVersionValid verifies the protected authorization-state version; UsageAvailable verifies remaining permitted capability use; OperationMatch verifies the actual Candidate Act; SinkMatch verifies the designated Finality Sink. Where a capability is single-use, successful authorized consumption changes the relevant protected usage state so that another incompatible use fails. Where a bounded multi-use capability is expressly authorized, the applicable remaining-use or transfer-window conditions are enforced. 11.23.26. WF-23.26 — Cross-Destination and Cross-Sink Reuse Prevention A valid capability may be presented in an unauthorized context. Examples include: (a) a different destination; (b) another recipient; Das Expires 19 April 2027 [Page 959] Internet-Draft Protected AI Execution Finality October 2026 (c) a different transaction amount; (d) a changed operation type; (e) an incompatible workload identity; (f) another protected authorization-state version; or (g) a different Finality Sink. The receiving Finality Sink verifies the actual operation against the required capability bindings. A capability permitting transmission to Service A does not independently authorize transmission to Service B. A capability intended for a network egress sink does not independently authorize a receiving database commit. Where the protected authorization permits bounded variation, the Finality Sink applies the corresponding explicitly authorized scope rather than assuming arbitrary substitutions are valid. 11.23.27. WF-23.27 — Retry Following Timeout in the implementation described by enforcement point 24, a retry following timeout is correlated with the original operation identifier and protected authorization state. A non-limiting retry request contains: original_candidate_act_id; retry_attempt_id; original_descriptor_digest; original_grant_reference; capability_reference; known_effectuation_status; retry_reason; current_policy_epoch. RC-2315 consults the existing protected operation-state record. Das Expires 19 April 2027 [Page 960] Internet-Draft Protected AI Execution Finality October 2026 It determines whether the original attempt: (a) never reached effectuation; (b) was reserved but not admitted; (c) was confirmed effective; (d) was denied; or (e) has an indeterminate outcome. A timeout alone does not prove that no external effect occurred. The system therefore does not automatically issue a new independently reusable authorization solely because the requesting agent did not receive a response. 11.23.28. WF-23.28 — Protected Recovery Predicate Where an earlier operation has an indeterminate completion status, the protected system evaluates whether a further attempt can be authorized without causing an unauthorized duplicate effect. An illustrative recovery predicate is: Vrecovery = SameCandidateAct AND CurrentAuthorityValid AND ProtectedStateConsistent AND DuplicateEffectExcluded AND RecoveryScopeValid where: SameCandidateAct verifies correlation to the original consequential operation; CurrentAuthorityValid verifies applicable current protected authority; ProtectedStateConsistent verifies protected reservation, consumption, and outcome state; Das Expires 19 April 2027 [Page 961] Internet-Draft Protected AI Execution Finality October 2026 DuplicateEffectExcluded establishes the duplicate-effect prevention condition required by the selected recovery mechanism; and RecoveryScopeValid verifies that the proposed recovery procedure is authorized. Where the system cannot establish a mandatory duplicate-exclusion predicate, the independently reusable authorization is withheld. A recovery process may report an unresolved outcome rather than claiming successful prevention or completion. 11.23.29. WF-23.29 — Recovery After Failure Before Protected Commitment Consider a failure before the required protected finality transaction commits. The proposed Candidate Act may have passed some preliminary authorization checks. However, the protected state, required validation evidence, or capability availability has not successfully committed. The system does not treat the incomplete process as an authorized effectuation. On recovery, the PED obtains the current required authority and protected state. The Candidate Act may be revalidated. A new valid capability may become available only after all applicable mandatory commitment conditions succeed. The previous incomplete attempt does not confer unrestricted authority. 11.23.30. WF-23.30 — Recovery After Commitment but Before Capability Delivery A protected finality transaction may complete, but communication to the requesting execution environment may fail before delivery of the capability. The recovery component consults the committed transaction record. It determines whether the corresponding capability: Das Expires 19 April 2027 [Page 962] Internet-Draft Protected AI Execution Finality October 2026 (a) was successfully created or activated; (b) remains within its validity scope; (c) has already been consumed; (d) is reserved for an attempted effect; (e) has expired or been revoked; or (f) requires protected retirement. Where the original capability remains valid and unused under its required conditions, the protected system may recover or make available that same authorization according to the selected design. It does not automatically mint a second independent grant for the same restricted operation. 11.23.31. WF-23.31 — Recovery After Capability Delivery but Before Effectuation A requesting agent may receive or reference a valid capability and fail before presenting it to the Finality Sink. On recovery, the system determines whether the capability remains valid under: (a) the original Candidate Act Descriptor; (b) current required policy state; (c) protected nonce or usage state; (d) expiry; (e) revocation; (f) workload context; and (g) the designated Finality Sink. Where the original capability remains valid and the protected usage state permits its use, the applicable recovery procedure may permit continuation. Where the mandatory authorization context has changed incompatibly, renewed protected validation is required. Das Expires 19 April 2027 [Page 963] Internet-Draft Protected AI Execution Finality October 2026 The capability's earlier availability does not override current required Finality Sink checks. 11.23.32. WF-23.32 — Recovery After Effectuation Attempt An operation may be admitted at the Finality Sink and then encounter a failure before its completion outcome is known. For example, an agent may send an authorized payment request through a protected gateway. The gateway verifies and consumes the capability. The remote payment service may process the operation. The connection may then fail before an acknowledgment reaches the gateway. The protected outcome state records the attempted operation and its indeterminate completion where appropriate. The recovery controller does not treat the lack of acknowledgment as proof of failure. A new consequential attempt remains subject to the duplicate-effect prevention and recovery predicates. 11.23.33. WF-23.33 — Receiving-Side Reconciliation Where supported, RR-2319 obtains authenticated receiving-side operation status. The receiving system may provide: (a) operation identifier; (b) idempotency-key status; (c) transaction reference; (d) commit sequence; (e) authenticated completion record; (f) durable receiving-side outcome; or (g) another reliable status artifact. Das Expires 19 April 2027 [Page 964] Internet-Draft Protected AI Execution Finality October 2026 The recovery component verifies the correspondence between the receiving-side record and the original Candidate Act. If completion is established, the protected operation state is updated accordingly. If non-completion is reliably established, a protected recovery predicate may permit an authorized retry. If the outcome remains indeterminate, the system does not independently assume retry safety. 11.23.34. WF-23.34 — Idempotency and Duplicate-Effect Protection An external system may support a durable idempotency mechanism. In that case, the protected workflow may associate the Candidate Act with a stable idempotency identifier. A non-limiting record comprises: candidate_act_id; idempotency_key; destination_service; operation_digest; authorization_reference; receiving_status; protected_completion_reference. The key identifies the same logical operation across permitted retries. However, an idempotency key alone does not guarantee duplicate-effect prevention unless the receiving system actually implements the necessary durable idempotency semantics. Where the receiving system lacks such support, the protected system must use another supported duplicate-exclusion mechanism or withhold a retry whose safety cannot be established. Das Expires 19 April 2027 [Page 965] Internet-Draft Protected AI Execution Finality October 2026 11.23.35. WF-23.35 — Protected Retry Authority Where recovery itself requires execution authority, the retry procedure may be represented as a governed recovery operation. The protected authority evaluates: (a) original Candidate Act identity; (b) previous effectuation status; (c) current Authority Object; (d) protected grant-consumption state; (e) receiving-side status where available; (f) applicable policy epoch; (g) destination and operation correspondence; and (h) the required duplicate-effect prevention condition. An authorized recovery instruction does not automatically constitute permission to produce a second independently effective operation. The recovery mechanism must preserve the applicable original operation identity and protected finality restrictions. 11.23.36. WF-23.36 — Revocation During an Interrupted Operation Revocation may occur while a Candidate Act is: (a) pending; (b) validating; (c) capability-prepared; (d) capability-released; (e) reserved for effectuation; or (f) awaiting outcome confirmation. RV-2317 advances or records the relevant protected revocation state. Das Expires 19 April 2027 [Page 966] Internet-Draft Protected AI Execution Finality October 2026 The Finality Sink verifies the required current revocation predicate before admitting a still-pending governed effect. Where an earlier effect has already occurred, revocation does not retroactively prevent it. Where a remote effect remains indeterminate, the recovery process preserves that uncertainty rather than assuming the revocation cancelled the prior request. 11.23.37. WF-23.37 — Snapshot and State-Rollback Protection An AI workload may be restarted from an earlier snapshot. The snapshot may contain: (a) a copy of a capability; (b) an earlier nonce; (c) cached policy state; (d) an operation request; (e) an earlier pending-state record; or (f) an application-level indication that the operation was not completed. The authoritative protected grant and capability-consumption state remains outside the rollback-accessible workload domain where rollback protection is required. Following restoration, the Finality Sink consults current protected state. A previously consumed or revoked single-use capability is not restored merely because the workload snapshot contains an earlier copy. The strength of the rollback guarantee depends upon the actual protection of the authoritative state mechanism. 11.23.38. WF-23.38 — Distributed Protected-State Consistency The PED, capability issuer, and Finality Sink may operate on separate authenticated nodes. Das Expires 19 April 2027 [Page 967] Internet-Draft Protected AI Execution Finality October 2026 The system preserves the required correspondence among: (a) Candidate Act identity; (b) grant identity; (c) authorization-state version; (d) validation-evidence commitment; (e) capability identifier; (f) Finality Sink identity; (g) nonce and usage state; and (h) effectuation outcome. A distributed implementation may use authenticated state replication, protected serialization, durable reservation records, consensus- backed state, or another suitable mechanism. No particular distributed database or consensus protocol is mandatory unless required by the selected embodiment. Where the current state cannot be established with the required consistency, the affected operation remains blocked. A design that permits incompatible copies of the same single-use grant to be consumed independently would not provide the required duplicate-consumption guarantee. 11.23.39. WF-23.39 — Atomicity and Remote-Effect Limitation The architecture distinguishes local protected atomicity from globally atomic external effectuation. An Atomic Protected-State Transition can ensure that the authorization grant and associated protected records change consistently. An Atomic Finality Commit can ensure that mandatory authorization- state and evidence conditions are committed together before capability usability. However, a remote payment processor, messaging service, network recipient, or physical system may not participate in that protected transaction. Das Expires 19 April 2027 [Page 968] Internet-Draft Protected AI Execution Finality October 2026 Therefore, the system does not automatically guarantee: (a) exactly-once delivery; (b) exactly-once remote execution; (c) instantaneous rollback of external effects; or (d) globally atomic commitment across unrelated receiving systems. Stronger guarantees require an appropriate controlled receiving-side boundary, transaction protocol, durable idempotency mechanism, or other verified coordination procedure. 11.23.40. WF-23.40 — Illustrative Atomic Grant Consumption An AI agent proposes a consequential API operation. The applicable protected grant permits one execution. The grant-state record indicates: grant_id = G1; remaining_uses = 1; status = ACTIVE. Two concurrent agent requests attempt to execute the operation using the same grant. The Protected Enforcement Domain serializes or atomically coordinates the required state transition. The first authorized operation obtains the permitted grant reservation. The protected remaining-use state advances. The competing request cannot obtain a second independently valid authorization from the same restricted grant. The required validation evidence is committed and the authorized capability becomes usable according to the protected finality transaction. The Finality Sink verifies the permitted operation and current usage state before effectuation. Das Expires 19 April 2027 [Page 969] Internet-Draft Protected AI Execution Finality October 2026 11.23.41. WF-23.41 — Illustrative Crash Before Capability Release An agent prepares an external network request. The PED validates the operation. Before the required evidence and protected-state transaction completes, the authorization component crashes. On restart, the recovery controller consults the authoritative protected state. The incomplete mandatory transaction is not treated as successful. The proposed request remains non-effective. The system may perform renewed protected validation under the current authority conditions. No valid execution capability is presumed to exist merely because preliminary validation had succeeded. 11.23.42. WF-23.42 — Illustrative Timeout After Credential-Mediated Effectuation An AI agent proposes a transaction requiring a protected API credential. The privileged connector verifies the required authorization commitment and capability. The credential is applied to the validated request. The request reaches the external service, but the response is lost. The protected operation state records that effectuation was attempted and that remote completion is uncertain. The agent issues a retry request. The recovery controller correlates it with the original Candidate Act. It does not automatically issue a new independently reusable authorization. Das Expires 19 April 2027 [Page 970] Internet-Draft Protected AI Execution Finality October 2026 Where a reliable receiving-side idempotency or status mechanism establishes the necessary duplicate-prevention condition, a bounded recovery procedure may be permitted. Otherwise, the operation remains indeterminate pending further authorized reconciliation. 11.23.43. WF-23.43 — Illustrative Snapshot Replay An AI workload receives a single-use capability authorizing a protected storage operation. The storage Finality Sink verifies the capability and consumes the corresponding protected usage state. An earlier VM snapshot is restored. The restored workload contains an older copy of the capability. The workload attempts the same storage operation again. The Finality Sink checks the authoritative protected consumption state. The capability is already consumed. The repeated operation is refused. The snapshot cannot re-create the previously consumed execution authority. 11.23.44. WF-23.44 — Illustrative Cross-Sink Capability Reuse An agent receives a capability permitting one network transmission. The corresponding network Finality Sink successfully verifies the capability. The agent attempts to reuse the same capability at a storage-commit interface. The storage Finality Sink verifies the actual operation and designated sink identity. The capability does not authorize the storage-commit boundary. The operation is refused. Das Expires 19 April 2027 [Page 971] Internet-Draft Protected AI Execution Finality October 2026 This illustrates that a previously valid capability cannot be reused outside its authorized effectuation boundary merely because its cryptographic authentication is valid. 11.23.45. WF-23.45 — Alternative Technical Implementations Single-node protected transaction: Protected validation, state handling, evidence commitment, and capability activation occur within one protected controller or transactional store. HSM-assisted implementation: A protected cryptographic component controls capability issuance and relevant state transitions. Protected database implementation: A transactionally consistent authorization-state store maintains grants, nonces, reservations, and consumption. Hardware-counter implementation: A trusted monotonic counter or protected sequence supports replay prevention. Credential-broker implementation: A privileged connector verifies the protected grant and exact operation before applying credentials. Network Finality Sink implementation: A protected egress controller verifies the capability and usage state before transmission. Storage Finality Sink implementation: A controlled commit interface verifies operation-specific authority before persistent mutation. Receiving-side idempotency implementation: The receiving service maintains durable operation identifiers or commit results supporting safe retry. Distributed protected-state implementation: Authenticated authority and Finality Sink nodes maintain the consistency required for bounded capability use. Confidential-computing implementation: Protected state remains authoritative outside rollback-accessible workload snapshots. The choice of implementation does not remove mandatory authorization, evidence, consumption, and actual effectuation verification requirements. Das Expires 19 April 2027 [Page 972] Internet-Draft Protected AI Execution Finality October 2026 11.23.46. WF-23.46 — Failure and Fail-Closed Conditions The system refuses, withholds, or retains a Candidate Act in a Non- Effective State when a mandatory condition is absent, invalid, inconsistent, expired, revoked, replayed, or unverifiable. Non-limiting failure conditions include: (a) missing active grant; (b) unauthorized operation scope; (c) invalid grant authenticity; (d) expired grant; (e) revoked grant; (f) exhausted permitted usage count; (g) concurrent unauthorized grant consumption; (h) nonce replay; (i) incompatible policy epoch; (j) invalid authorization-state version; (k) failed atomic state transition; (l) incomplete required finality commit; (m) failed validation-evidence commitment; (n) missing execution capability; (o) invalid capability authentication; (p) Candidate Act Descriptor mismatch; (q) destination substitution; (r) Finality Sink mismatch; (s) consumed capability; (t) unauthorized retry; Das Expires 19 April 2027 [Page 973] Internet-Draft Protected AI Execution Finality October 2026 (u) indeterminate prior effectuation without a satisfied recovery predicate; (v) inconsistent protected recovery state; (w) rollback of required authoritative state; (x) unavailable mandatory current revocation information; or (y) failure of required Finality Sink verification. Failure of a transaction, timeout, or process restart does not independently grant execution authority. 11.23.47. WF-23.47 — PHOSITA Verification and Negative Tests A person having ordinary skill in distributed systems, transactional state management, cryptography, AI-agent security, protected execution, and external service integration may verify the architecture through the following tests. Test 1 — Valid atomic grant consumption: Authorize one operation under a single-use protected grant and confirm that the corresponding state transition succeeds. Test 2 — Concurrent duplicate attempts: Submit two competing operations against one single-use grant. Only the permitted number of grants may be consumed. Test 3 — Failed state transition: Interrupt the required protected- state transaction. No independently usable capability becomes available. Test 4 — Failed evidence commitment: Interrupt mandatory validation- evidence commitment. The corresponding capability remains unusable. Test 5 — Capability prepared but not released: Prepare a capability before completing required protected commitment. The Finality Sink refuses effectuation. Test 6 — Valid Finality Sink verification: Present a matching capability and current state. The corresponding operation is permitted. Test 7 — Missing capability: Present the operation without the required execution capability. Effectuation is refused. Das Expires 19 April 2027 [Page 974] Internet-Draft Protected AI Execution Finality October 2026 Test 8 — Consumed capability: Reuse a consumed single-use capability. Protected usage verification rejects the attempt. Test 9 — Nonce replay: Present a previously invalidated nonce. Required freshness verification fails. Test 10 — Policy-epoch mismatch: Present a capability under incompatible current protected policy state. Effectuation is denied. Test 11 — Wrong destination: Change the recipient or destination after authorization. Required descriptor correspondence fails. Test 12 — Wrong Finality Sink: Present a capability at an unauthorized effectuation interface. Sink binding fails. Test 13 — Concurrent capability consumption: Submit simultaneous attempts at one restricted sink. Protected state prevents unauthorized double consumption. Test 14 — Crash before commit: Interrupt the PED before finality commitment. The pending operation remains non-effective. Test 15 — Crash after commit: Interrupt capability delivery after protected commitment. Recovery consults existing state rather than minting a duplicate independent grant. Test 16 — Crash before sink admission: Restart the requester before effectuation. Required current capability verification remains mandatory. Test 17 — Timeout after remote submission: Lose the remote acknowledgment after possible effectuation. The outcome is preserved as indeterminate. Test 18 — Unauthorized retry: Attempt another consequential operation without satisfying the protected recovery predicate. The retry is refused. Test 19 — Receiving-side idempotency: Use a receiving service with verified durable idempotency and evaluate an authorized bounded retry. Test 20 — No receiving-side idempotency: Simulate an uncertain operation against a non-idempotent service. No unsupported exactly- once guarantee is asserted. Das Expires 19 April 2027 [Page 975] Internet-Draft Protected AI Execution Finality October 2026 Test 21 — Snapshot rollback: Restore an earlier workload image containing a consumed capability. Current protected state rejects reuse. Test 22 — Protected-state rollback: Attempt to restore an older authoritative grant-state record. Required rollback protection rejects or detects the incompatible state. Test 23 — Revocation before effectuation: Revoke the applicable authority before the Finality Sink admits the operation. Required current-state verification refuses it. Test 24 — Revocation after completed effect: Revoke authority after the operation has completed. The completed effect is not falsely classified as prevented. Test 25 — Bounded multi-use capability: Permit an expressly authorized number of uses and refuse operations exceeding the protected usage allowance. Test 26 — Distributed state inconsistency: Present incompatible grant or capability state across protected nodes. The system refuses an operation whose mandatory consistency cannot be established. Test 27 — Candidate Act versus attempt identity: Submit retries with different attempt identifiers but the same logical Candidate Act and verify protected correlation. Test 28 — Different Candidate Act: Attempt to reuse authorization for another concrete operation. Descriptor and scope verification reject it. Test 29 — Credential-mediated recovery: Retry an uncertain protected credential operation and enforce the original operation's recovery restrictions. Test 30 — Receiving-side completion evidence: Obtain an authenticated completion record and reconcile the protected outcome. Test 31 — Partial effectuation: Interrupt a multi-unit operation and preserve the distinction between completed, pending, and uncertain units. Test 32 — Single-node finality: Implement protected transaction and Finality Sink functions in one protected node and verify required ordering. Das Expires 19 April 2027 [Page 976] Internet-Draft Protected AI Execution Finality October 2026 Test 33 — Distributed finality: Implement the PED and Finality Sink on different nodes and verify authenticated state and capability correspondence. Test 34 — Replay across sessions: Attempt capability reuse under an incompatible session or workload context. Mandatory context verification fails. Test 35 — Recovery-only operation: Attempt a consequential rollback or compensation action without its separately required authority. The action is refused. Tests may employ transaction fault injection, controlled process termination, simulated network partitions, snapshot restoration, protected counters, duplicate request generators, mock payment or API services, and authenticated operation-status interfaces. The tests demonstrate only the properties actually enforced by the implementation and the receiving systems used. 11.23.48. WF-23.48 — Claim-Specific Technical Support Enforcement Point 20 — Protected Grant-State Consumption WF-23.9 through WF-23.14 describe the protected grant-state record, active grant, authorized operation, validity interval, permitted usage count, revocation state, atomic consumption, and prevention of unauthorized duplicate effects arising from grant reuse. Enforcement Point 24 — Crash, Retry and Duplicate-Effect Protection WF-23.21 through WF-23.35 describe the protected operation-state machine, pending and authorized states, consumption reservations, terminal outcomes, original operation identifiers, retry correlation, indeterminate completion, and protected recovery predicates. Enforcement Point 31 — Protected Effectuation Outcome State WF-23.22, WF-23.23, WF-23.32 and WF-23.33 describe protected pending, reserved, confirmed-effective, denied, and indeterminate states used to evaluate subsequent execution attempts and prevent unauthorized duplicate external effects. Enforcement Point 33 — State-Bound Finality and Replay Protection Das Expires 19 April 2027 [Page 977] Internet-Draft Protected AI Execution Finality October 2026 WF-23.17 through WF-23.26 describe cryptographic binding to nonce, policy epoch, authorization-state version, operation descriptor, and Finality Sink identity; verification against current state immediately before effectuation; protected usage consumption; and refusal of replay, destination substitution, or cross-sink reuse. Related parent-claim requirements enforcement point 20 and 24 operate through the protected sandbox- egress grant-state architecture associated with enforcement point 19 and 20. enforcement point 31 depends upon the transaction-bound credential- effectuation architecture of enforcement point 28. enforcement point 33 depends upon the protected agent-egress finality method of enforcement point 32. The workflow is therefore a cross-cutting implementation narrative, not a replacement for those distinct parent-claim limitations. 11.23.49. WF-23.49 — Technical Effect The workflow establishes a protected causal sequence between: (a) generation of a consequential Candidate Act; (b) interception and Non-Effective State holding; (c) construction of an effectuation-relevant descriptor; (d) verification of protected grant authority; (e) atomic or appropriately consistent reservation and consumption of required state; (f) protected authorization-state advancement; (g) required validation-evidence commitment; (h) scoped execution-capability availability; (i) independent Finality Sink verification; (j) bounded effectuation; (k) protected capability consumption; Das Expires 19 April 2027 [Page 978] Internet-Draft Protected AI Execution Finality October 2026 (l) recording of effectuation status; (m) controlled recovery following failure; and (n) prevention of unauthorized duplicate effects. The Atomic Protected-State Transition prevents incomplete or inconsistent grant-state handling from creating unauthorized authority. The protected validation-evidence commitment establishes the required pre-effectuation authorization dependency where mandated. The scoped capability prevents authorization from being reused outside its permitted act, state, and Finality Sink conditions. The recovery mechanism distinguishes a failed authorization attempt from an operation that may already have become externally effective. The effectuation-outcome store preserves confirmed, pending, and indeterminate statuses instead of assuming that every timeout means failure. The architecture provides duplicate-effect prevention to the extent enforced by protected capability state and the applicable receiving- side mechanisms, without claiming unconditional globally exactly-once completion. Computation is not authority to act. Validation is not effectuation. Reservation is not confirmation of completion. A previously valid capability is not automatically valid for reuse. A timeout is not proof that an external operation failed. Recovery does not independently confer authority to execute again. Protected atomicity must preserve the required authorization dependencies before consequential effectuation. 11.24. WF-24 — Multiple Finality Sinks, Independent Downstream Verification, Multi-Boundary Candidate Act Classification, Receiving-Side Finality, and Protected Cross-Boundary Execution Authority Das Expires 19 April 2027 [Page 979] Internet-Draft Protected AI Execution Finality October 2026 11.24.1. WF-24.1 — Technical Purpose This embodiment describes a computer-implemented protected execution- finality architecture for governing workflows in which an artificial- intelligence agent, autonomous service, or distributed computation generates multiple consequential operations that may become effective at different technical boundaries. The system distinguishes authorization of computation, admission of agent delegation, preparation of a consequential operation, protected authorization of that operation, and actual effectuation at its designated Finality Sink. A successful authorization at one boundary does not automatically confer authority to complete a different consequential operation at another boundary. The architecture provides: (a) classification of consequential operations according to their effectuation boundaries; (b) formation of a separate Candidate Act Descriptor for each governed operation; (c) protected validation against the applicable Authority Object and current authorization state; (d) protected evidence commitment where required; (e) issuance or availability of operation-scoped execution capabilities; (f) independent verification at the designated Finality Sink; (g) receiving-side verification of the actual operation; (h) protection against unauthorized propagation or reuse of execution authority; (i) enforcement of distinct authorization conditions across multi- agent workflows; (j) control of streaming outputs and buffered consequential operations; and (k) consistent recovery and revocation across multiple enforcement boundaries. Das Expires 19 April 2027 [Page 980] Internet-Draft Protected AI Execution Finality October 2026 A model-access decision may permit computation. A Delegation Capability may permit a subordinate agent to accept a bounded delegated task. A network capability may permit transmission. A storage capability may permit a specified persistent mutation. A payment capability may permit a particular financial operation. These permissions control different technical events. The architecture does not treat any one of them as universal authority to perform all remaining steps in the workflow. The central rule is: A consequential operation becomes effective only after the Finality Sink governing that operation verifies its applicable protected execution authority. 11.24.2. WF-24.2 — Participating Technical Components In one non-limiting implementation, the system comprises the following components. AE-2401 — Primary AI Execution Environment An autonomous agent, model runtime, orchestration service, or other computing component configured to perform computations and prepare consequential operations. MC-2402 — Model-Computation Admission Component A protected or enforcement-controlled component governing admission of the agent's model-computation requests. AR-2403 — Protected Computation-Admission Record An authenticated record representing the permitted model, workload, approved execution context, policy epoch, and authorization-state reference. DA-2404 — Delegation Authorization Component A protected component configured to validate proposed delegation to a subordinate agent under the applicable Delegation Authority Object. Das Expires 19 April 2027 [Page 981] Internet-Draft Protected AI Execution Finality October 2026 SA-2405 — Subordinate Agent Execution Environment A child agent, delegated tool agent, sub-agent, or other subordinate computation process operating under bounded delegated authority. OC-2406 — Consequential Operation Classification Component A component configured to identify consequential operations and determine their respective effectuation classes. FC-2407 — Finality Sink Classification Component A mechanism configured to map each governed consequential operation to its applicable Finality Sink. HQ-2408 — Non-Effective Candidate Act Holding Mechanism An enforcement-controlled buffer, queue, pending request record, inactive command, or equivalent mechanism maintaining consequential operations before authorization. DC-2409 — Candidate Act Descriptor Component A mechanism configured to construct or verify operation-specific descriptors. PED-2410 — Protected Enforcement Domain A protected authorization component configured to validate each Candidate Act against its applicable Authority Object, execution context, protected policy state, and required Finality Sink. AS-2411 — Protected Authority Store An authenticated source of operation, delegation, workload, destination, purpose, scope, and effectuation authorization conditions. PS-2412 — Protected Authorization-State Store A mechanism maintaining protected grants, policy epochs, revocation state, nonces, usage limits, capability consumption, and validation- state commitments. EV-2413 — Protected Validation-Evidence Component A mechanism configured to generate or commit an authenticated operation-specific validation record. Das Expires 19 April 2027 [Page 982] Internet-Draft Protected AI Execution Finality October 2026 CR-2414 — Scoped Execution-Capability Component A protected component configured to generate, register, derive, release, or activate operation-specific capabilities. FS-2415 — Network Effectuation Finality Sink A controlled network gateway, egress proxy, NIC, SmartNIC, DPU, or equivalent interface governing transmission. FS-2416 — Tool and API Finality Sink A controlled tool executor, API gateway, protected connector, or equivalent interface governing consequential service invocation. FS-2417 — Credential-Use Finality Sink A protected credential broker or cryptographic key-use interface governing consequential credential application. FS-2418 — Persistent-State Finality Sink A protected file-modification controller, database-commit interface, storage controller, or equivalent persistent effectuation boundary. FS-2419 — Financial or Transaction Finality Sink A protected payment, transaction, settlement, or financial execution interface. FS-2420 — Hardware or Physical Finality Sink A hardware-assisted actuator, accelerator-output interface, fabric controller, deployment controller, or other governed consequential interface. RV-2421 — Receiving-Side Actual-Operation Verifier A component configured to obtain, reconstruct, or verify an operation at a remote or downstream receiving-side boundary. SC-2422 — Cross-Boundary Authorization-Consistency Component A mechanism configured to preserve the required relationships among operation identities, capabilities, state versions, validation records, and designated Finality Sinks. OS-2423 — Protected Effectuation-Outcome Store Das Expires 19 April 2027 [Page 983] Internet-Draft Protected AI Execution Finality October 2026 A mechanism maintaining pending, reserved, authorized, denied, confirmed-effective, revoked, and indeterminate operation states. RC-2424 — Protected Recovery and Reconciliation Component A mechanism coordinating authorized recovery from interrupted or uncertain multi-boundary operations. The components may operate within one protected node or across separately authenticated systems. Multiple Finality Sinks may share a PED while retaining separate operation-specific effectuation authority. 11.24.3. WF-24.3 — Distinction Between Computation and Effectuation The primary AI agent may: (a) execute model inference; (b) analyze information; (c) generate task plans; (d) call permitted computational tools; (e) construct a service request; (f) prepare a transaction; (g) select a destination; (h) generate a file modification; or (i) produce another operation proposal. These activities do not automatically confer authority to complete all consequential effects represented by the computational output. The system distinguishes computation-admission authority from operation-specific effectuation authority. An approved computation may generate an unauthorized Candidate Act. Conversely, the system may refuse additional model computation while retaining an already generated Candidate Act in a Non-Effective State pending separately required finality verification. Das Expires 19 April 2027 [Page 984] Internet-Draft Protected AI Execution Finality October 2026 11.24.4. WF-24.4 — Identification of Distinct Effectuation Classes OC-2406 identifies whether a proposed operation creates a governed effect at one or more boundaries. Illustrative classes include: (a) model-computation admission; (b) delegation admission; (c) tool execution; (d) external network transmission; (e) protected credential application; (f) persistent file mutation; (g) database commitment; (h) message delivery; (i) payment execution; (j) artifact publication; (k) software deployment; (l) accelerator-state export; and (m) device actuation. The classification depends upon the actual consequence being controlled. A prepared data structure is not necessarily an externally effective operation. A database commit or external transmission may be consequential even if generated as a small part of a larger authorized agent workflow. 11.24.5. WF-24.5 — Effectuation Boundary Registry FC-2407 maintains or resolves an authenticated registry of the Finality Sink governing each consequential operation class. A non-limiting mapping record comprises: Das Expires 19 April 2027 [Page 985] Internet-Draft Protected AI Execution Finality October 2026 operation_class; effectuation_boundary_id; finality_sink_identity; authorized_execution_scope; descriptor_schema_reference; required_authority_object; required_protected_state; capability_verification_method; applicable_policy_epoch. The registry may be protected within the PED, maintained by an authenticated infrastructure controller, or represented through authorized policy configuration. The requesting AI agent cannot unilaterally select a weaker Finality Sink when the applicable operation requires a stronger protected effectuation boundary. 11.24.6. WF-24.6 — Classification of a Multi-Operation Workflow An agentic workflow may produce several consequential operations. For example: Operation 1 — external information retrieval. Operation 2 — protected credential use. Operation 3 — modification of a database record. Operation 4 — payment execution. Operation 5 — delivery of an external notification. FC-2407 associates each operation with the appropriate Finality Sink. The classification may be represented as: CA_1 → FS_network Das Expires 19 April 2027 [Page 986] Internet-Draft Protected AI Execution Finality October 2026 CA_2 → FS_credential CA_3 → FS_database CA_4 → FS_payment CA_5 → FS_message These associations represent effectuation authority, not merely a preferred routing arrangement. A capability for CA_1 does not independently authorize CA_3 or CA_4. 11.24.7. WF-24.7 — Separation of Delegation from Downstream Effectuation in the implementation described by enforcement point 42, the primary agent may propose delegation of a task to SA-2405. The proposed delegation is represented as a Candidate Delegation Act. DA-2404 validates the proposed delegation under the applicable Delegation Authority Object. The protected delegation authorization may consider: (a) permitted subtask class; (b) tool class; (c) data scope; (d) memory scope; (e) time window; (f) recursion limit; (g) execution budget; (h) prohibited operation class; (i) policy epoch; (j) revocation state; and (k) nonce conditions. Das Expires 19 April 2027 [Page 987] Internet-Draft Protected AI Execution Finality October 2026 Successful validation may permit acceptance of the bounded delegation. However, it does not independently authorize a later externally effective tool invocation, file mutation, network transmission, credential release, payment, or other consequential operation. Each governed downstream operation remains subject to its applicable protected execution-finality validation and Finality Sink verification. 11.24.8. WF-24.8 — Delegation Acceptance Boundary A proposed delegation may be held as a Candidate Delegation Act. A delegation-acceptance Finality Sink verifies the required Delegation Capability before the subordinate agent receives executable delegated authority. The Delegation Capability may identify the permitted objective, data scope, tool permissions, recursion limits, execution budget, and validity conditions. The subordinate agent operates within that bounded scope. Delegation acceptance establishes the permitted subordinate computational or task authority. It does not eliminate downstream operation-specific finality requirements. The delegation-acceptance boundary and later consequential effectuation boundaries perform distinct functions. 11.24.9. WF-24.9 — Subordinate-Agent Candidate Act SA-2405 may generate a proposed consequential operation. For example, a delegated research agent may prepare an authorized database update or outbound API request. The operation is independently classified as a Candidate Act. The protected authorization may validate: (a) the subordinate workload identity; (b) permitted delegation scope; Das Expires 19 April 2027 [Page 988] Internet-Draft Protected AI Execution Finality October 2026 (c) the actual operation; (d) destination; (e) purpose; (f) remaining usage allowance; (g) policy epoch; (h) revocation state; and (i) designated Finality Sink. A valid Delegation Capability may contribute required authority context. It does not automatically substitute for the downstream operation- specific execution capability. 11.24.10. WF-24.10 — Separation of Model Admission from Downstream Effectuation In the embodiments corresponding to enforcement point 57, 68 and 95, MC-2402 controls admission of a proposed inference or agent- computation request. The protected computation-admission procedure may validate: (a) workload identity; (b) requested model; (c) approved computation context; (d) execution purpose; (e) policy state; and (f) applicable admission authorization. Successful admission permits the approved computation. It does not independently authorize externally effective operations generated by that computation. A resulting tool call, network transmission, file mutation, or other consequential operation is classified as a separate Candidate Act. Das Expires 19 April 2027 [Page 989] Internet-Draft Protected AI Execution Finality October 2026 The downstream operation remains subject to its own protected validation, scoped execution-capability release, and applicable Finality Sink verification. 11.24.11. WF-24.11 — Inference-to-Act Context Binding in the implementation described by enforcement point 69, the protected computation-admission record may identify: (a) model identity; (b) workload identity; (c) approved execution context; (d) policy epoch; and (e) authorization-state identifier. The operation-specific authorization context may reference or cryptographically bind the computation-admission record to the downstream Candidate Act Descriptor. A non-limiting association is: Bcontext = H(Encode(AdmissionRecordDigest, CandidateActDigest, WorkloadID, ContextVersion)) where the corresponding fields identify the computation-admission evidence and consequential operation. The association may support authentication of the operation's admitted computation context. However, the computation-admission record is not treated as sufficient execution authority. The downstream capability remains separately required. 11.24.12. WF-24.12 — Candidate Act Generation and Holding The agent or subordinate execution environment generates a proposed consequential operation. The operation is classified as Candidate Act CA_i. HQ-2408 maintains CA_i in a Non-Effective State. Das Expires 19 April 2027 [Page 990] Internet-Draft Protected AI Execution Finality October 2026 An illustrative record comprises: candidate_act_id; source_agent_id; source_computation_reference; delegation_reference; operation_class; target_resource; destination_reference; payload_reference; required_finality_sink; status = NON_EFFECTIVE. The proposed operation remains blocked while the applicable protected authorization conditions are unresolved. The existence of an earlier computation-admission or delegation authorization does not independently release CA_i. 11.24.13. WF-24.13 — Operation-Specific Descriptor Formation DC-2409 constructs an operation-specific Candidate Act Descriptor. A representative descriptor comprises: candidate_act_id; source_agent_identity; source_workload_identity; operation_class; destination_or_recipient; target_resource; operation_parameters; Das Expires 19 April 2027 [Page 991] Internet-Draft Protected AI Execution Finality October 2026 payload_digest; applicable_delegation_reference; applicable_computation_context; authority_object_reference; policy_epoch; revocation_epoch; authorization_state_version; nonce; expiry; finality_sink_identity. The applicable Authority Object determines which fields are mandatory. The descriptor represents the concrete effectuation request rather than an abstract general permission. 11.24.14. WF-24.14 — Canonical Candidate Act Representation In one illustrative implementation: D_i = Canon_v(ID_i, SOURCE_i, ACT_i, TARGET_i, PARAM_i, CONTEXT_i, STATE_i, SINK_i) where: D_i denotes the canonical descriptor for Candidate Act i; ID_i denotes the operation identifier; SOURCE_i denotes the authenticated requesting agent or workload; ACT_i denotes the consequential operation class; TARGET_i denotes destination or recipient; PARAM_i denotes effectuation-relevant parameters; CONTEXT_i denotes mandatory computation or delegation context; Das Expires 19 April 2027 [Page 992] Internet-Draft Protected AI Execution Finality October 2026 STATE_i denotes applicable protected authorization state; and SINK_i denotes the designated Finality Sink. An illustrative digest is: h_i = H("DAS-MULTI-SINK-ACT-v1" || Encode(D_i)) The encoding must distinguish fields that materially affect authorization. The cryptographic construction is illustrative and does not replace mandatory actual-operation verification. 11.24.15. WF-24.15 — Operation-Specific Authority Validation PED-2410 obtains the Authority Object applicable to CA_i. The Authority Object may specify: (a) permitted operation class; (b) source workload identity; (c) destination or recipient; (d) authorized purpose; (e) permitted delegation scope; (f) approved computation context; (g) required protected state; (h) usage limit; (i) policy epoch; (j) revocation conditions; (k) freshness requirements; and (l) designated Finality Sink. The PED verifies the applicable authority independently for each consequential operation. Das Expires 19 April 2027 [Page 993] Internet-Draft Protected AI Execution Finality October 2026 The existence of a valid capability for one operation does not automatically satisfy another operation's required predicates. 11.24.16. WF-24.16 — Protected Authorization Predicate An illustrative authorization predicate is: V_i = Pact_i AND Pscope_i AND Ptarget_i AND Pcontext_i AND Pstate_i AND Psink_i where: V_i denotes authorization of Candidate Act i; Pact_i verifies the actual operation; Pscope_i verifies applicable permitted authority; Ptarget_i verifies destination, recipient, or resource; Pcontext_i verifies mandatory computation or delegation context; Pstate_i verifies protected policy, revocation, nonce, freshness, and usage conditions; and Psink_i verifies the designated Finality Sink. A valid operation-specific authorization does not independently establish that the operation has already become effective. Finality Sink verification remains required. 11.24.17. WF-24.17 — Protected Authorization-State Handling Following successful operation-specific validation, PED-2410 performs the protected-state operations required for CA_i. Das Expires 19 April 2027 [Page 994] Internet-Draft Protected AI Execution Finality October 2026 These may include: (a) reserving an act-specific grant; (b) consuming or registering a nonce; (c) validating current policy state; (d) checking the revocation epoch; (e) updating protected usage; (f) registering the Candidate Act Descriptor digest; (g) associating the designated Finality Sink; or (h) another required protected-state transition. Where the grant is single-use or usage-bounded, the protected mechanism prevents unauthorized duplicate consumption. Where mandatory protected state cannot be established, the corresponding capability remains unavailable. 11.24.18. WF-24.18 — Protected Validation-Evidence Commitment EV-2413 generates or commits the applicable protected validation evidence. A non-limiting record comprises: receipt_id; candidate_act_id; operation_descriptor_digest; authority_object_reference; source_workload_identity; delegation_reference; computation_context_reference; protected_state_transition; policy_epoch; Das Expires 19 April 2027 [Page 995] Internet-Draft Protected AI Execution Finality October 2026 nonce; finality_sink_identity; validation_result; protected_authentication. The record may comprise an AVR, LAVR, sealed validation record, authenticated commitment, or another supported protected artifact. Under enforcement point 68, operation-specific validation evidence is committed before, or atomically with, availability of the operation- specific execution capability. The source-side validation record does not independently prove that every later receiving-side consequential operation has completed. 11.24.19. WF-24.19 — Scoped Execution-Capability Release CR-2414 releases or makes available an execution capability corresponding to the validated Candidate Act. The capability may bind: (a) Candidate Act Descriptor digest; (b) authorized operation; (c) source workload identity; (d) destination or recipient; (e) permitted execution scope; (f) protected validation-evidence reference; (g) policy epoch; (h) revocation epoch; (i) nonce; (j) expiry; (k) usage limit; and (l) designated Finality Sink. Das Expires 19 April 2027 [Page 996] Internet-Draft Protected AI Execution Finality October 2026 An illustrative representation is: C_i = Sign_skPED(Encode(h_i, Receipt_i, Scope_i, State_i, Nonce_i, Expiry_i, Sink_i)) The particular capability format may comprise a signature, MAC, protected handle, sealed capability-table entry, or equivalent authenticated mechanism. The Finality Sink must enforce the required operation-specific and state-dependent properties. 11.24.20. WF-24.20 — Independent Finality Sink Verification The designated Finality Sink obtains or reconstructs the actual operation presented for effectuation. The verifier checks: (a) capability authenticity; (b) required descriptor correspondence; (c) authorized operation scope; (d) destination or recipient; (e) applicable source identity; (f) policy and revocation state; (g) nonce and expiry; (h) protected validation-state commitment; (i) usage or consumption state; and (j) designated Finality Sink identity. The operation becomes effective only when the mandatory conditions succeed. A valid capability for another operation or another Finality Sink does not independently satisfy the required verification. Das Expires 19 April 2027 [Page 997] Internet-Draft Protected AI Execution Finality October 2026 11.24.21. WF-24.21 — Effectuation Verification Predicate An illustrative Finality Sink predicate is: Permit_i = Auth(C_i) AND Match(C_i,Dactual_i) AND ScopeValid(C_i) AND StateValid(C_i) AND SinkValid(C_i,FS_i) where: Permit_i denotes permission for Candidate Act i; C_i denotes the operation-specific capability; Dactual_i denotes the actual effectuation descriptor; Auth verifies the capability; Match verifies the required actual-operation correspondence; ScopeValid verifies permitted operation scope; StateValid verifies protected policy, revocation, evidence, freshness, and usage conditions; and SinkValid verifies that the capability authorizes Finality Sink i. Only when the required predicate succeeds does the designated Finality Sink permit effectuation. 11.24.22. WF-24.22 — Multi-Sink Capability Independence in the implementation described by enforcement point 71, one agentic workflow may comprise several independently consequential operations. An operation-specific capability authorizes only the operation or bounded set of operations expressly covered by its authenticated scope. For example: Das Expires 19 April 2027 [Page 998] Internet-Draft Protected AI Execution Finality October 2026 C_network authorizes the specified network transmission. C_storage authorizes the specified persistent-state mutation. C_payment authorizes the specified payment. C_deployment authorizes the specified deployment effect. The existence of C_network does not independently authorize C_payment. A valid Delegation Capability does not independently authorize any of those downstream operations unless their separate required authorization conditions are also satisfied. An approved model-computation admission does not replace any corresponding downstream execution capability. 11.24.23. WF-24.23 — Receiving-Side Finality in the implementation described by enforcement point 72, the downstream Finality Sink may comprise: (a) a receiving service; (b) a remote execution gateway; (c) a protected database-commit interface; (d) a payment execution interface; (e) a hardware actuator; or (f) a trusted connector. The receiving-side Finality Sink reconstructs or verifies the actual Candidate Act presented for effectuation. It compares the operation with the operation-specific execution capability and required protected validation-state commitment. The receiving service does not rely solely on an upstream agent's assertion that the operation was authorized. The applicable enforcement boundary refuses the operation where mandatory effectuation-relevant parameters differ. Das Expires 19 April 2027 [Page 999] Internet-Draft Protected AI Execution Finality October 2026 11.24.24. WF-24.24 — Remote Actual-Operation Descriptor An illustrative receiving-side descriptor comprises: operation_id; actual_operation_class; actual_recipient; actual_destination; actual_resource; actual_parameters; payload_digest; required_state_version; execution_scope; finality_sink_identity. A non-limiting expression is: Dremote = Canon_v(OperationActual, RecipientActual, TargetActual, ParametersActual, StateActual, SinkActual) The receiving-side verifier compares Dremote with the authenticated scope of the corresponding capability. A mismatch in a required field causes refusal unless the Authority Object expressly permits the relevant bounded variation. A valid upstream operation identifier does not override a mismatch in recipient, amount, resource, or other mandatory parameters. 11.24.25. WF-24.25 — Receiving-Side Verification Predicate An illustrative predicate is: PermitRemote = Auth(C) AND Match(C,Dremote) AND Das Expires 19 April 2027 [Page 1000] Internet-Draft Protected AI Execution Finality October 2026 ReceiptValid(C,R) AND StateValid(C,S) AND SinkValid(C,F) where: C denotes the operation-specific capability; Dremote denotes the actual receiving-side operation; R denotes the required protected validation evidence; S denotes protected authorization state; and F denotes the receiving-side Finality Sink. The verifier refuses an operation that differs from the authorized operation in a mandatory effectuation-relevant parameter, including: (a) destination; (b) recipient; (c) operation type; (d) protected state version; or (e) applicable execution scope. 11.24.26. WF-24.26 — Source-Side Transmission and Receiving-Side Commitment A source-side network Finality Sink may permit an authorized request to be transmitted. The receiving system may subsequently perform a distinct database modification, payment, storage commit, or another consequential operation. The source-side transmission authorization does not automatically establish authority for the later receiving-side effect. Where the receiving-side operation is separately governed, the receiving Finality Sink requires the corresponding execution capability. Das Expires 19 April 2027 [Page 1001] Internet-Draft Protected AI Execution Finality October 2026 For example: CA_network → network Finality Sink → authorized transmission. CA_database → database Finality Sink → separately authorized persistent mutation. The first operation can be authorized while the second remains non- effective. This distinction preserves the difference between permission to communicate and permission to produce an irreversible downstream state change. 11.24.27. WF-24.27 — Streaming Outputs and Partial Actions in the implementation described by enforcement point 70, the artificial-intelligence execution environment may produce: (a) model-output tokens; (b) partially generated tool arguments; (c) decoded action fragments; (d) incomplete API requests; (e) command fragments; (f) bounded streaming operations; or (g) completed consequential requests. The operation-classification component determines whether the fragment remains internal data, forms part of an incomplete Candidate Act, or constitutes a separately effective operation. Where a fragment may cause a governed consequence, its applicable Finality Sink verification remains mandatory. The system does not treat every model token as necessarily requiring a separate execution capability. The finality granularity corresponds to the actual consequential boundary and the scope of the protected authorization. Das Expires 19 April 2027 [Page 1002] Internet-Draft Protected AI Execution Finality October 2026 11.24.28. WF-24.28 — Buffering of Consequential Streaming Output An illustrative streaming Candidate Act record comprises: stream_id; source_inference_id; fragment_sequence; fragment_digest; operation_class; candidate_act_id; assembly_status; finality_sink_id; effectuation_status. Incomplete operation fragments may remain buffered until enough information exists to form the required Candidate Act Descriptor. A bounded fragment that is independently consequential may require its own protected authorization. The system prevents a streaming tool request from becoming externally effective merely because its bytes were produced by a validly admitted model. 11.24.29. WF-24.29 — Model-Access Interruption and Buffered Operations A model-access gate may deny or revoke future computation. However, a consequential operation may already have been generated and held by a tool runtime or execution environment. Interruption of future model inference does not itself authorize the buffered operation. Nor does the interruption alone establish that a previously completed external effect was prevented. The buffered Candidate Act remains subject to its downstream Finality Sink authorization. Das Expires 19 April 2027 [Page 1003] Internet-Draft Protected AI Execution Finality October 2026 Where the applicable policy also revokes the downstream authority, the Finality Sink enforces that revocation before admitting the operation. 11.24.30. WF-24.30 — Multi-Hop Agent Workflow An agent may produce a sequence of operations across several service boundaries. A non-limiting sequence comprises: AI computation → tool invocation → external network transmission → receiving-side database request → persistent commit. Each consequential stage may be subject to a different Finality Sink. An upstream operation may prepare context for a later operation. However, the resulting downstream authority must be established through the applicable protected authorization conditions. The workflow does not automatically propagate unrestricted capability authority through every intermediate service. A receiving service that becomes an independent actor may generate a new Candidate Act requiring its own protected authorization. 11.24.31. WF-24.31 — Scoped Multi-Stage Authorization An Authority Object may expressly permit a bounded multi-stage workflow. Such authority may specify: (a) approved workflow graph; (b) participating agents; (c) permitted operation classes; (d) designated Finality Sinks; (e) allowed destinations; (f) maximum usage; (g) order constraints; Das Expires 19 April 2027 [Page 1004] Internet-Draft Protected AI Execution Finality October 2026 (h) policy epoch; and (i) required protected state. The system may use a set of operation-specific capabilities or an expressly scoped multi-stage authorization representation. Each designated Finality Sink nevertheless verifies the applicable authorization for its own consequential boundary. Authorization of the workflow as a whole is not interpreted as unrestricted permission for unlisted operations or destinations. 11.24.32. WF-24.32 — Cross-Boundary Context Continuity SC-2422 maintains or verifies the required relationship among different stages of the workflow. A protected workflow reference may contain: workflow_id; source_computation_reference; delegation_reference; candidate_act_ids; authorized_transition_graph; required_policy_epoch; protected_state_version; designated_finality_sinks. The context may help establish that a downstream Candidate Act arose from an approved workflow or delegated task. However, context continuity does not itself substitute for operation- specific execution authority. A valid workflow identifier is not a universal capability for every possible downstream effect. Das Expires 19 April 2027 [Page 1005] Internet-Draft Protected AI Execution Finality October 2026 11.24.33. WF-24.33 — Separate Credential Application Where a workflow involves protected credential use, FS-2417 verifies the authority required for the actual credential-mediated operation. The agent may possess a credential reference or surrogate identifier without having unrestricted access to the underlying protected credential. The protected credential-use interface verifies the permitted operation, destination, credential scope, and required state. Where the subsequent network transmission is separately governed, FS-2415 independently verifies its corresponding authorization. The system does not assume that protected credential application and external network effectuation are always the same technical boundary. They may be integrated within one protected component or implemented through distinguishable enforcement functions. 11.24.34. WF-24.34 — Separate Persistent-State Commitment A tool may prepare a database or file modification. The operation is represented as a Candidate Act. The protected authority validates the actual mutation and applicable authorization conditions. The persistent-state Finality Sink verifies the corresponding scoped capability before committing the governed change. Successful invocation of a tool or delivery of a network request does not independently authorize the protected persistent-state mutation. Where the data-storage service exposes a mandatory commit controller, that interface may provide receiving-side execution-finality enforcement. 11.24.35. WF-24.35 — Separate Payment Effectuation An AI agent may prepare a payment request following an otherwise authorized workflow. The payment Candidate Act identifies the required recipient, amount, currency, payment authority, protected state, and designated financial Finality Sink. Das Expires 19 April 2027 [Page 1006] Internet-Draft Protected AI Execution Finality October 2026 The payment authority validates those parameters. The corresponding capability is bound to the permitted operation. The payment Finality Sink independently verifies the actual transaction before completing the governed financial effect. A valid network capability allowing communication with the payment service does not independently authorize the payment. Where the payment service cannot verify an operation-specific capability and is outside the controlled receiving-side boundary, the system cannot claim receiving-side finality merely from upstream transmission permission. 11.24.36. WF-24.36 — Cross-Sink Capability Substitution An attacker or compromised agent may attempt to reuse a valid capability at another Finality Sink. For example, a capability issued for one network operation may be submitted to a database controller. The receiving Finality Sink verifies the designated sink identity and operation scope. The capability fails the required binding. The requested database operation is denied. Similarly, a capability for one payment recipient cannot authorize another recipient when exact recipient binding is mandatory. The protection relies upon enforced operation-specific and sink- specific verification, not merely upon the presence of cryptographic authentication bytes. 11.24.37. WF-24.37 — Protected State Across Multiple Sinks Where several Finality Sinks participate, the protected architecture may maintain: (a) common policy epochs; (b) operation-specific grants; (c) individual capability-consumption records; Das Expires 19 April 2027 [Page 1007] Internet-Draft Protected AI Execution Finality October 2026 (d) revocation conditions; (e) protected validation-record references; (f) sink-specific authorization state; and (g) workflow-level outcome information. An authorization valid at one sink does not automatically mean the same state is valid at another sink. The architecture may share a protected authority service while maintaining separate operation-specific state. Where current protected state is mandatory, each Finality Sink verifies the conditions applicable to its own operation. 11.24.38. WF-24.38 — Revocation Across Consequential Boundaries An Authority Object or protected grant may be revoked during execution of a multi-stage workflow. The system determines which pending and future operations are affected. For an operation that has not crossed its effectuation boundary, the Finality Sink enforces the required current revocation condition. For an operation that is already confirmed effective, revocation does not retroactively prevent the completed consequence. For an indeterminate operation, the system preserves the uncertainty and consults applicable recovery rules. The architecture does not presume that a revocation propagated to one Finality Sink is instantly visible at every remote sink unless the implementation establishes the required synchronization or freshness guarantees. 11.24.39. WF-24.39 — Protected Operation Outcomes OS-2423 maintains distinguishable status for each Candidate Act. A non-limiting record comprises: candidate_act_id; workflow_id; Das Expires 19 April 2027 [Page 1008] Internet-Draft Protected AI Execution Finality October 2026 finality_sink_id; authorization_status; capability_status; effectuation_status; protected_state_version; completion_evidence_reference; last_attempt_id. Status values may include: NON_EFFECTIVE; VALIDATING; AUTHORIZED; RESERVED; EFFECTUATION_ATTEMPTED; CONFIRMED_EFFECTIVE; DENIED; REVOKED; INDETERMINATE. One stage's confirmed effect does not automatically establish successful completion of all later stages. The system may preserve partial workflow completion and pending downstream operations separately. 11.24.40. WF-24.40 — Crash and Recovery Across Multiple Finality Sinks A distributed workflow may fail after an upstream effect but before a downstream operation completes. The recovery component identifies the status of each independently governed Candidate Act. Das Expires 19 April 2027 [Page 1009] Internet-Draft Protected AI Execution Finality October 2026 For example: CA_network may be confirmed transmitted. CA_database may remain pending. CA_payment may be indeterminate. The system does not restart the entire workflow by automatically repeating every operation. Instead, it determines the protected authorization and completion status applicable to each Candidate Act. Pending operations are revalidated where required. Consumed capabilities are not automatically reused. Indeterminate external effects remain subject to protected reconciliation and duplicate-effect prevention. 11.24.41. WF-24.41 — Receiving-Side Completion Reconciliation Where supported, the receiving service may provide authenticated completion information. Such information may include: (a) transaction identifier; (b) operation digest; (c) receiving-side commit record; (d) protected completion receipt; (e) idempotency status; or (f) another reliable outcome reference. The protected recovery mechanism verifies that the receiving-side information corresponds to the original Candidate Act. A successful receiving-side commitment may establish a completed effect. An unresolved status does not automatically authorize an independently reusable capability. Das Expires 19 April 2027 [Page 1010] Internet-Draft Protected AI Execution Finality October 2026 The architecture does not assume exactly-once remote effectuation without an appropriate receiving-side mechanism. 11.24.42. WF-24.42 — Illustrative End-to-End Enterprise Agent Workflow An enterprise AI agent receives a user task requiring analysis of an internal document followed by a database update and an external notification. First, the model-access component authorizes the required computation. The model generates the proposed workflow. A subordinate agent may receive a bounded Delegation Capability permitting document analysis. The delegated agent reads permitted information and prepares a database update. The database update is classified as a Candidate Act. The PED validates the proposed mutation. The protected system commits the required validation evidence and releases the database-specific execution capability. The database Finality Sink verifies the actual record modification before committing it. The agent then prepares an external notification. The notification is a separate Candidate Act. The PED evaluates its destination, message scope, authority, current state, and network Finality Sink. A separate network capability becomes available only after successful protected validation. The network Finality Sink independently verifies the notification before transmission. The earlier model admission, Delegation Capability, and database- commit capability do not independently authorize the external notification. Das Expires 19 April 2027 [Page 1011] Internet-Draft Protected AI Execution Finality October 2026 11.24.43. WF-24.43 — Illustrative Remote Payment Verification An AI agent prepares a payment instruction. The network Finality Sink authorizes transmission of the payment request to an approved payment service. The receiving payment interface separately governs execution of the financial transaction. It reconstructs the actual recipient, amount, currency, operation type, applicable state version, and authorized execution scope. The receiving Finality Sink verifies the corresponding payment capability and protected validation-state commitment. If the amount or recipient differs from the authorized operation, the payment Finality Sink refuses the operation. The upstream network transmission authorization does not override the receiving-side payment condition. 11.24.44. WF-24.44 — Illustrative Model-Quarantine Scenario An AI model completes a valid inference and generates an external API request. The request remains buffered in a Non-Effective State. A security component subsequently interrupts future model access. The model cannot produce further governed inference through the protected model-access path. However, the buffered API request remains present. The downstream API Finality Sink independently checks the operation- specific execution capability. If the capability is missing or invalid, the operation is refused. The model-access interruption is not treated as a substitute for the downstream check. If an earlier API operation already became effective, its completed consequence is preserved in the outcome record. Das Expires 19 April 2027 [Page 1012] Internet-Draft Protected AI Execution Finality October 2026 11.24.45. WF-24.45 — Illustrative Delegated-Agent Boundary A primary AI agent receives permission to delegate a bounded research task. The delegation-acceptance Finality Sink verifies the Delegation Capability. A subordinate agent is activated within its permitted task and tool scope. The subordinate agent then attempts to export confidential data to an external destination. That proposed export is classified as a separate Candidate Act. The downstream network Finality Sink requires the corresponding operation-specific capability. The original Delegation Capability does not independently authorize the export. If the proposed destination violates the applicable Authority Object, the PED withholds the required capability and the network Finality Sink refuses transmission. 11.24.46. WF-24.46 — Illustrative Cross-Sink Replay A capability authorizes one database update. The database Finality Sink verifies the operation and consumes the corresponding protected usage state. The agent subsequently attempts to reuse the capability for another database record and at a different network interface. The respective Finality Sinks verify current usage state, operation descriptor, and sink identity. The previous capability is no longer valid for the requested operations. The system refuses the unauthorized reuse. A previously valid cryptographic authorization does not become universal authority merely because the agent retains a copy. Das Expires 19 April 2027 [Page 1013] Internet-Draft Protected AI Execution Finality October 2026 11.24.47. WF-24.47 — Alternative Technical Implementations Single-node implementation: One protected node performs Candidate Act authorization and local Finality Sink verification for several operation classes through separate protected interfaces. Distributed PED implementation: A protected authority service issues bounded capabilities verified by remote Finality Sinks. Agent-tool implementation: A protected tool runtime independently verifies execution authority for consequential tool operations. Network implementation: A protected gateway, SmartNIC, or DPU verifies the capability before transmission. Database implementation: A protected commit controller verifies act- specific authority before durable mutation. Credential implementation: A protected broker verifies capability scope before credential-mediated effectuation. Payment implementation: A receiving payment interface verifies the actual transaction before execution. Hardware-actuation implementation: A protected controller verifies the required capability before enabling a governed physical operation. Delegated-agent implementation: Delegation admission is protected independently of downstream tool and external effects. Model-access implementation: Computation-admission authority remains separate from operation-specific effectuation authority. Streaming implementation: Consequential fragments remain buffered until the required bounded Candidate Act has been authorized. Remote receiving-side implementation: The receiving system reconstructs the actual operation and verifies the corresponding execution capability. These variants need not all appear together in every implementation. The selected architecture must enforce the actual boundaries and authorization relationships required under the specified enforcement profile. Das Expires 19 April 2027 [Page 1014] Internet-Draft Protected AI Execution Finality October 2026 11.24.48. WF-24.48 — Failure and Fail-Closed Conditions A governed operation remains non-effective or is refused when any mandatory condition is absent, invalid, expired, revoked, replayed, inconsistent, or unverifiable. Non-limiting conditions include: (a) invalid model-admission authority; (b) invalid Delegation Capability; (c) unauthorized subordinate-agent scope; (d) incorrect operation classification; (e) missing Candidate Act Descriptor; (f) unauthorized operation type; (g) destination mismatch; (h) recipient mismatch; (i) unauthorized resource; (j) invalid purpose or execution scope; (k) stale policy epoch; (l) invalid revocation state; (m) failed protected-state transition; (n) failed required validation-evidence commitment; (o) missing operation-specific capability; (p) invalid capability authentication; (q) consumed capability; (r) nonce replay; (s) Finality Sink identity mismatch; (t) unauthorized cross-sink reuse; Das Expires 19 April 2027 [Page 1015] Internet-Draft Protected AI Execution Finality October 2026 (u) missing mandatory receiving-side validation; (v) remote actual-operation mismatch; (w) incomplete streaming operation; (x) failure of mandatory non-bypassable enforcement; or (y) unavailable required current protected authorization state. Failure of an upstream computation, delegation, or network authorization condition does not create an unrestricted alternative downstream execution path. 11.24.49. WF-24.49 — PHOSITA Verification and Negative Tests A person having ordinary skill in AI-agent architecture, distributed authorization, service-mesh security, database transaction control, protected cryptographic capabilities, and execution-finality enforcement may verify the following cases. Test 1 — Authorized model computation: Permit a valid model request and verify successful computation admission. Test 2 — Model admission without downstream capability: Produce a consequential tool operation but omit its execution capability. The downstream Finality Sink refuses it. Test 3 — Valid delegation: Admit a bounded subordinate task using a valid Delegation Capability. Test 4 — Delegation without effectuation authority: Attempt an unauthorized external operation under a valid Delegation Capability. The applicable Finality Sink refuses the effect. Test 5 — Network Finality Sink: Authorize one specified network request and verify that only the matching operation is transmitted. Test 6 — Database Finality Sink: Authorize a concrete persistent mutation and verify its independent commit-boundary checks. Test 7 — Payment Finality Sink: Present a valid payment capability matching the actual transaction. The receiving-side protected operation is permitted. Test 8 — Payment recipient substitution: Change the recipient after authorization. The receiving Finality Sink refuses the transaction. Das Expires 19 April 2027 [Page 1016] Internet-Draft Protected AI Execution Finality October 2026 Test 9 — Cross-sink capability reuse: Present a network capability at a database Finality Sink. Required sink verification fails. Test 10 — Cross-operation reuse: Present a capability for one Candidate Act with another Candidate Act. Required descriptor correspondence fails. Test 11 — Consumed capability: Reuse a single-use capability after valid consumption. Protected usage verification refuses the operation. Test 12 — Wrong workload: Present a capability through an unauthorized workload where identity binding is mandatory. Verification fails. Test 13 — Stale policy state: Present an operation under an incompatible current policy epoch. Effectuation is refused. Test 14 — Revocation: Revoke an operation-specific grant before effectuation. The Finality Sink refuses the affected operation. Test 15 — Model interruption with buffered act: Interrupt future inference while a Candidate Act remains buffered. The downstream capability check remains mandatory. Test 16 — Streaming partial operation: Present incomplete consequential command fragments. The operation is held until the required bounded Candidate Act can be verified. Test 17 — Streaming operation mutation: Change a mandatory field after authorization. The Finality Sink rejects the altered operation. Test 18 — Remote actual-operation reconstruction: Require a receiving service to reconstruct the actual requested operation and verify the corresponding capability. Test 19 — Upstream request versus downstream commit: Permit an upstream network request but withhold a separately required database- commit capability. The database effect remains blocked. Test 20 — Multiple independent sinks: Execute a workflow containing several operation classes and confirm that each corresponding Finality Sink enforces its own required authorization. Test 21 — Delegation recursion: Attempt further delegated execution beyond the permitted recursion or task scope. Required delegation authorization fails. Das Expires 19 April 2027 [Page 1017] Internet-Draft Protected AI Execution Finality October 2026 Test 22 — Credential-mediated effect: Attempt protected credential application without the required operation-specific capability. The credential Finality Sink refuses the action. Test 23 — Protected receipt mismatch: Present a valid-looking capability associated with another operation's validation commitment. Verification fails. Test 24 — Concurrency: Submit competing operations against a restricted grant. Protected state prevents unauthorized double consumption. Test 25 — Network bypass: Attempt an effect through an alternate accessible network path. The governed operation remains blocked or equivalently mediated. Test 26 — Receiving-side bypass: Attempt to complete a governed database or payment effect outside the protected receiving-side interface. The specified enforcement configuration prevents or equivalently mediates that path. Test 27 — Partial workflow completion: Complete one authorized stage while another remains pending. Preserve independent protected outcome states. Test 28 — Crash after upstream transmission: Interrupt the workflow after network transmission but before receiving-side confirmation. The system does not assume downstream completion. Test 29 — Duplicate recovery: Retry an uncertain operation and enforce the required original operation identity and protected recovery conditions. Test 30 — Wrong Finality Sink at recovery: Attempt to resume a pending operation through a different unauthorized sink. Verification fails. Test 31 — Single-node multi-sink implementation: Verify separate operation-specific finality functions implemented within one protected node. Test 32 — Distributed multi-sink implementation: Verify operation- specific capabilities across several authenticated downstream Finality Sinks. Test 33 — Hardware actuation: Attempt a governed physical operation without the required actuation capability. The hardware Finality Sink remains non-admitting. Das Expires 19 April 2027 [Page 1018] Internet-Draft Protected AI Execution Finality October 2026 Test 34 — Finality Sink outage: Make one required receiving-side Finality Sink unavailable. The corresponding operation remains blocked while other independently authorized operations follow their own applicable conditions. Test 35 — Receiving-side state mismatch: Present a capability with an incompatible protected state version. The receiving-side operation is refused. Test 36 — Upstream authorization-only architecture: Demonstrate that an upstream allow decision, without required downstream capability verification, is insufficient to satisfy the specified receiving-side finality guarantee. The tests may use controlled agent runtimes, model gateways, delegation controllers, protected authorization services, credential brokers, programmable network proxies, database mock services, payment simulators, hardware-interlock emulators, and authenticated receiving-side interfaces. The actual demonstrated guarantees depend upon the implemented enforcement boundaries and protected-state mechanisms. 11.24.50. WF-24.50 — Claim-Specific Technical Coverage Enforcement Point 42 — Separation of Delegation from Downstream Effectuation WF-24.7 through WF-24.9 describe protected delegation acceptance followed by independently governed consequential operations. A Delegation Capability permits bounded delegation but does not itself authorize downstream network, tool, file, credential, payment, or other external effects. Enforcement Point 57 — Separate Downstream Execution Authority WF-24.10 through WF-24.12 describe classification of consequential operations arising from admitted computation as separate Candidate Acts requiring their own protected validation, scoped execution- capability release, and Finality Sink verification. Enforcement Point 68 — Model-Path and Effectuation-Path Dual Authorization WF-24.3, WF-24.10 through WF-24.21, and WF-24.29 describe the protected model-access gate, downstream Candidate Act classification, Non-Effective State holding, operation-specific validation-evidence Das Expires 19 April 2027 [Page 1019] Internet-Draft Protected AI Execution Finality October 2026 commitment, separate downstream Finality Sink verification, and continued withholding of unverified operations after model-access interruption. Enforcement Point 69 — Inference-to-Act Context Binding WF-24.11 describes the protected computation-admission record and its association with the downstream Candidate Act Descriptor without replacing operation-specific authority. Enforcement Point 70 — Streaming Output and Partial-Action Control WF-24.27 through WF-24.29 describe streaming fragments, bounded consequential operations, buffering, and the requirement for downstream Finality Sink verification notwithstanding interruption of future inference. Enforcement Point 71 — Multi-Sink Effectuation Classification WF-24.4 through WF-24.6 and WF-24.22 describe identifying different effectuation boundaries and refusing to treat a capability for one operation or Finality Sink as authority for another. Enforcement Point 72 — Remote Effectuation Verification WF-24.23 through WF-24.26 describe receiving-side reconstruction of the actual operation and verification against the corresponding capability and protected validation-state commitment. Unauthorized differences in recipient, destination, operation type, state version, or execution scope cause refusal when those conditions are mandatory. Enforcement Point 95 — Model-Path Authorization Does Not Replace Effectuation Authorization WF-24.10, WF-24.29 and WF-24.44 describe independent downstream authorization and continued protection of buffered Candidate Acts after model-access interruption, quarantine, or revocation. 11.24.51. WF-24.51 — Technical Effect The workflow establishes independent protected authorization for distinct consequential boundaries within an AI-agent or distributed service workflow. Its operation comprises: Das Expires 19 April 2027 [Page 1020] Internet-Draft Protected AI Execution Finality October 2026 (a) authorized model computation or bounded delegation; (b) generation of one or more consequential operations; (c) classification of each operation according to its effectuation boundary; (d) interception and maintenance in a Non-Effective State; (e) construction of an operation-specific Candidate Act Descriptor; (f) validation of applicable authority, protected state, and execution context; (g) required validation-evidence commitment; (h) issuance or availability of the corresponding scoped execution capability; (i) independent verification at the designated Finality Sink; (j) receiving-side reconstruction or verification where applicable; (k) controlled effectuation or fail-closed refusal; and (l) protected handling of capability usage, revocation, recovery, and uncertain downstream outcomes. The architecture prevents computational permission, bounded delegation, authenticated network communication, or authorization at one Finality Sink from becoming unrestricted authority to complete unrelated consequential operations. The receiving-side embodiment places final authorization verification at the boundary where the actual receiving-side operation becomes effective. The multi-sink embodiment associates each consequential operation with the authority required by its own effectuation interface. The streaming embodiment prevents consequential operation fragments from escaping protected finality merely because they originated during an admitted model computation. The recovery embodiment preserves the independence of upstream and downstream operation outcomes. Computation is not authority to act. Das Expires 19 April 2027 [Page 1021] Internet-Draft Protected AI Execution Finality October 2026 Delegation acceptance is not downstream execution permission. Model admission is not external-effect authorization. Network transmission authority is not receiving-side database or payment authority. A capability issued for one Finality Sink is not automatically valid at another. The actual consequential operation must satisfy the authority verified at its own Finality Sink. 12. Deployment Contexts the proposed architecture is industrially applicable to artificial- intelligence systems, autonomous computing, cybersecurity, cloud and edge computing, confidential computing, cryptographic infrastructure, telecommunications, financial technology, semiconductor technologies, distributed computing, industrial automation, robotics, and other digital or cyber-physical systems in which a computationally generated operation must be independently authorized before producing a consequential effect. the architecture may be manufactured, implemented, deployed, integrated, licensed, and commercially operated through software, firmware, hardware, protected computing environments, cryptographic enforcement components, network gateways, processors, accelerators, storage controllers, secure elements, and combinations thereof. The architecture may be incorporated into existing computing infrastructures or implemented as a standalone protected execution- authority system. Artificial Intelligence, Autonomous Agents, and Agentic Computing the architecture is applicable to AI assistants, autonomous software agents, multi-agent frameworks, large language models, multimodal models, reasoning systems, coding agents, research agents, enterprise agents, browser agents, robotic agents, and AI-driven workflow orchestration platforms. It provides protected authorization of consequential operations generated by AI systems, including tool invocation, external API access, network transmission, file modification, software deployment, credential use, and persistent data changes. AI Model Serving, Inference Infrastructure, and AI Safety Platforms Das Expires 19 April 2027 [Page 1022] Internet-Draft Protected AI Execution Finality October 2026 the architecture may be integrated into model-serving gateways, inference routers, model-access controllers, AI safety platforms, agent-execution environments, and model-monitoring systems. It distinguishes permission to perform model computation from authority to execute consequential operations resulting from that computation. Downstream Candidate Acts remain subject to protected finality verification even when model access is interrupted, restricted, quarantined, or revoked. Cloud Computing, Hybrid Cloud, and Multi-Cloud Infrastructure the architecture is applicable to public clouds, private clouds, hybrid-cloud infrastructures, virtual machines, confidential virtual machines, Kubernetes clusters, containerized workloads, serverless execution platforms, distributed computing environments, and cloud- native services. It supports authenticated workload identities, protected policy-state synchronization, scoped execution capabilities, migration controls, failover recovery, and prevention of unauthorized restoration of previously consumed or revoked execution authority. Enterprise Information Technology and Business Automation the architecture may be deployed in enterprise resource planning systems, customer relationship management platforms, human-resource management systems, document-management systems, enterprise workflow engines, procurement platforms, inventory systems, and automated business-process systems. It enables operation-specific authorization of database modifications, financial approvals, document publication, privileged service requests, and other consequential enterprise operations. Cybersecurity, Zero-Trust Architecture, and Privileged Access Management the architecture is applicable to zero-trust security architectures, privileged access management, identity and access management, endpoint protection, secure service gateways, network security, security orchestration, and automated incident-response infrastructure. It provides protected execution authority separate from ordinary authentication and resource-access permissions, including mandatory operation-specific checks, revocation, bounded capabilities, replay protection, and fail-closed enforcement. Software Development, DevOps, and Continuous Deployment Das Expires 19 April 2027 [Page 1023] Internet-Draft Protected AI Execution Finality October 2026 the architecture may be integrated into autonomous coding agents, software-development environments, source-code management systems, CI/CD pipelines, deployment controllers, package registries, infrastructure-as-code systems, and automated software-maintenance platforms. It may require protected authorization before consequential actions such as modifying protected repositories, publishing software artifacts, accessing signing credentials, changing production configurations, deploying applications, or modifying critical infrastructure. Cryptographic Infrastructure, Key Management, and Digital Identity the architecture is applicable to hardware security modules, trusted execution environments, secure enclaves, cryptographic key-management systems, certificate authorities, digital-signature services, enterprise identity platforms, authentication services, and protected credential brokers. It separates access to cryptographic material from authority to perform particular consequential operations and supports operation-bound key use, credential release, derived or wrapped keys, protected authorization state, and cryptographically scoped execution capabilities. Confidential Computing and Privacy-Preserving Infrastructure the architecture may be employed in confidential virtual machines, secure enclaves, encrypted-memory systems, hardware-attested computing environments, protected analytics platforms, and privacy- preserving AI systems. It may enforce user-controlled data-access conditions, trusted workload measurements, protected cryptographic operations, and separate authorization before decrypted, processed, or confidential information is disclosed or otherwise transferred beyond its permitted boundary. Semiconductor Manufacturing, Processor Architectures, and Hardware Security the architecture is applicable to semiconductor devices and computing hardware incorporating CPUs, GPUs, TPUs, NPUs, FPGAs, ASICs, secure processors, memory controllers, DMA engines, and protected input/ output controllers. Hardware finality gates and latches may enforce scoped execution authority before protected transfers, accelerator outputs, memory operations, peripheral commands, or other hardware- mediated consequential effects. AI Data Centers and High-Performance Computing Das Expires 19 April 2027 [Page 1024] Internet-Draft Protected AI Execution Finality October 2026 the architecture may be implemented in GPU clusters, AI training and inference infrastructure, supercomputers, accelerator fabrics, distributed memory systems, high-performance networking, and large- scale computational facilities. It supports protected control of accelerator data movement, RDMA and DMA operations, tensor exports, inter-device transfers, model-artifact release, and other high- throughput operations through bounded capabilities and hardware- associated Finality Sinks. Networking, SmartNICs, DPUs, and Network Security Infrastructure the architecture is applicable to network interface controllers, SmartNICs, data processing units, programmable switches, routers, service-mesh gateways, network firewalls, secure proxies, load balancers, and software-defined networking systems. These components may verify operation-specific authorization before admitting network transmissions, credential-mediated requests, protected service invocations, or other governed communication operations. Telecommunications and Mobile Network Infrastructure the architecture may be applied to mobile core networks, 5G and 6G systems, telecommunications gateways, network-function virtualization, software-defined radio infrastructure, subscriber- control systems, signaling networks, network-management platforms, and autonomous telecommunications operations. It may govern consequential routing changes, subscriber provisioning, network configuration, protected signaling, service activation, and radio or data-plane operations at the relevant execution boundary. Satellite Communications, Aerospace, and Space Systems the architecture may be integrated into satellite ground systems, space communication gateways, spacecraft command infrastructure, satellite payload controllers, remote sensing systems, and autonomous aerospace platforms. It may enforce protected authorization before consequential command transmission, payload activation, communication routing, protected data release, or hardware actuation. Such implementations may employ bounded authorization windows, authenticated command descriptors, protected state, and fail-closed command admission. Banking, Payments, and Financial Technology the architecture is industrially applicable to banking infrastructure, digital payments, card-payment processing, electronic funds transfer, payment gateways, transaction switches, financial messaging platforms, and automated treasury operations. It may Das Expires 19 April 2027 [Page 1025] Internet-Draft Protected AI Execution Finality October 2026 provide operation-specific authorization of payment instructions, recipient and amount verification, protected credential use, transaction-state controls, bounded execution capabilities, and independent verification at financial effectuation boundaries. Capital Markets, Trading, and Financial Settlement the architecture may be applied to automated trading systems, brokerage infrastructure, securities exchanges, clearing systems, settlement platforms, custody services, and AI-assisted financial operations. It may require protected authorization before order placement, transaction submission, asset movement, settlement commitment, or other financial operations, with operation-specific authority bound to applicable transaction parameters and protected state. Blockchain, Distributed Ledgers, and Digital Asset Systems the architecture may be integrated into blockchain applications, smart-contract interaction gateways, digital-asset custody infrastructure, signing services, distributed-ledger transaction systems, and decentralized application interfaces. It may enforce protected authorization before cryptographic transaction signing, transaction broadcasting, asset transfer, smart-contract invocation, or ledger-affecting operations, while distinguishing permission to generate a proposed transaction from authority to make that transaction effective. Databases, Data Centers, Storage, and Information Management the architecture may be deployed in relational and distributed databases, object-storage systems, file systems, data warehouses, vector databases, backup infrastructure, and enterprise data- management platforms. It may require protected execution authority before persistent modification, deletion, publication, replication, export, or commitment of protected information, including verification at controlled storage or receiving-side commit boundaries. Healthcare, Hospitals, and Medical Technology Das Expires 19 April 2027 [Page 1026] Internet-Draft Protected AI Execution Finality October 2026 the architecture may be applied to healthcare information systems, hospital-management platforms, electronic health records, diagnostic AI, laboratory information systems, medical-device management, and connected clinical infrastructure. It may control protected record modifications, disclosure of sensitive patient information, clinical workflow commands, and other consequential operations. Where applied to medical devices, the protected authorization system may be combined with device-specific safety controls, emergency operating modes, and regulatory requirements. Pharmaceuticals, Biotechnology, and Scientific Laboratories the architecture may be employed in laboratory automation, pharmaceutical manufacturing, biotechnology research infrastructure, scientific instrumentation, automated experimentation systems, and AI-assisted research environments. It may govern protected experiment execution, instrument commands, sensitive dataset exports, controlled process changes, and publication or release of consequential research outputs. Industrial Automation, Manufacturing, and Industry 4.0 the architecture is applicable to industrial control systems, programmable logic controllers, supervisory control and data acquisition systems, manufacturing execution systems, robotic production lines, intelligent factories, industrial IoT platforms, and autonomous machinery. It may require protected authorization before industrial commands, production-parameter modifications, machinery activation, firmware updates, or other consequential control operations. Robotics, Autonomous Vehicles, and Unmanned Systems the architecture may be integrated into industrial robots, service robots, autonomous mobile robots, unmanned aerial vehicles, autonomous ground vehicles, maritime autonomous systems, and robotic fleet-management platforms. It may distinguish computational planning from authority to actuate motors, change operating modes, initiate missions, deploy payloads, or perform other physical operations, with enforcement at suitable protected command or actuation boundaries. Automotive, Connected Vehicles, and Transportation Infrastructure the architecture may be used in connected-vehicle platforms, automotive software systems, fleet-management infrastructure, autonomous transportation systems, charging networks, railway signaling, intelligent traffic systems, and logistics-control Das Expires 19 April 2027 [Page 1027] Internet-Draft Protected AI Execution Finality October 2026 platforms. It may govern consequential vehicle commands, firmware updates, route-control operations, protected communications, infrastructure configuration, and external service actions. Implementations affecting safety-critical controls may incorporate independent safety interlocks and sector-specific functional-safety requirements. Energy, Utilities, and Critical Infrastructure the architecture may be applied to electrical power grids, smart meters, renewable-energy installations, industrial energy controllers, substations, water-treatment systems, oil and gas infrastructure, pipeline monitoring, and other critical infrastructure. It may enforce protected authorization before configuration changes, actuator commands, operational setpoint modifications, network-control operations, or release of privileged infrastructure instructions. Government, Public Administration, and Sovereign Digital Infrastructure the architecture may be employed in government computing environments, public-sector cloud infrastructure, national digital services, identity platforms, secure document systems, public financial infrastructure, and sovereign AI deployments. It may support protected execution authority, data-governance restrictions, jurisdictional requirements, controlled credential use, audited authorization state, and enforcement of consequential operations at designated trusted boundaries. E-Commerce, Retail, and Digital Marketplaces the architecture may be integrated into AI shopping agents, electronic-commerce platforms, retail automation, inventory- management services, order-management systems, logistics platforms, customer-service agents, and automated procurement systems. It may distinguish product selection, quotation, and order preparation from protected authority to place an order, authorize payment, modify inventory, disclose customer information, or transmit an externally binding instruction. Supply Chain, Logistics, and Transportation Management Das Expires 19 April 2027 [Page 1028] Internet-Draft Protected AI Execution Finality October 2026 the architecture may be employed in warehouse automation, shipping platforms, logistics optimization, freight-management systems, procurement networks, supply-chain planning services, and autonomous fulfillment platforms. It may require operation-specific authorization for shipment release, inventory commitment, routing instructions, purchase orders, warehouse-control commands, and consequential coordination with third-party systems. Media, Communications, and Digital Content Platforms the architecture may be applied to digital publishing, content- generation systems, media-processing infrastructure, messaging platforms, streaming services, advertising systems, and automated content-distribution networks. It may distinguish content generation from authority to publish, distribute, disclose, transmit, or irreversibly modify digital content, including controlled release through network, storage, rendering, or distribution Finality Sinks. Education, Research, and Academic Computing the architecture may be integrated into educational AI systems, scientific computing platforms, academic research infrastructure, institutional data systems, research automation, and collaborative computing environments. It may govern protected data export, tool execution, controlled laboratory operations, privileged workflow changes, and release of externally effective research or administrative actions. Internet of Things, Smart Buildings, and Connected Devices the architecture may be employed in IoT gateways, smart homes, commercial building-management systems, connected appliances, access- control platforms, environmental monitoring, and distributed device- management systems. It may require protected authorization before device configuration, remote command execution, firmware installation, access-control changes, sensor-data disclosure, or other consequential device operations. Edge Computing and Distributed Autonomous Infrastructure the architecture may be implemented in edge servers, embedded controllers, remote gateways, mobile computing platforms, distributed AI inference systems, and intermittently connected infrastructure. It may maintain bounded execution authority using authenticated workload identity, protected authorization state, freshness conditions, scoped capabilities, and controlled fail-closed operation during network interruptions or recovery. Das Expires 19 April 2027 [Page 1029] Internet-Draft Protected AI Execution Finality October 2026 Identity, Privacy, Data Protection, and Regulated Data Processing the architecture may be applied to identity-verification infrastructure, privacy-preserving applications, consent-management systems, cross-border data-processing platforms, regulated data repositories, and automated data-governance systems. It may bind consequential data operations to applicable purpose, jurisdiction, consent, recipient, data scope, authority state, and protected effectuation conditions. Emergency Services and Public-Safety Infrastructure the architecture may be integrated into emergency communication networks, public-warning systems, critical incident-management platforms, disaster-response coordination infrastructure, and protected command services. It may support separately authorized emergency execution modes or Safe-Baseline operations while preserving authenticated authority, bounded scope, protected state, and the applicable safety and availability requirements. Cross-Industry Applications and Deployment Flexibility The foregoing industrial applications are illustrative and non- limiting. the architecture may also be applied to any computerized, networked, autonomous, cryptographic, transactional, industrial, or cyber-physical system in which an operation is generated or prepared by one component while protected authority to complete that operation is established and verified by another protected function. The Protected Enforcement Domain and Finality Sink may be implemented within the same protected device, within different protected components of a computing system, or across authenticated distributed infrastructure. The system may operate entirely in software, in hardware, or through combinations of firmware, secure processors, hardware security modules, virtual machines, protected gateways, network interfaces, and external receiving-side enforcement components. The architecture is not dependent upon a particular AI model, cloud provider, processor family, cryptographic primitive, operating system, industry protocol, or physical deployment arrangement. Different industrial implementations may employ different Authority Objects, protected predicates, capability representations, validation-evidence mechanisms, trust boundaries, and Finality Sink configurations according to their operational and regulatory requirements. Das Expires 19 April 2027 [Page 1030] Internet-Draft Protected AI Execution Finality October 2026 the architecture is capable of practical industrial implementation using computing processors, memory devices, cryptographic hardware, secure execution environments, protected authorization-state stores, network interfaces, storage systems, and controlled effectuation mechanisms. Its components may be manufactured as semiconductor devices, integrated into enterprise and industrial computing systems, supplied as protected software or firmware, or deployed as managed computing and security infrastructure. The industrial utility of the architecture lies in its ability to maintain a protected technical distinction between computation and consequential execution, ensuring that a proposed operation does not acquire the governed practical effect merely because an artificial- intelligence agent, software process, authenticated service, or computational system is capable of generating or requesting it. The fundamental industrial principle implemented by the architecture is that computation is not authority to act. A consequential operation becomes effective only upon satisfaction of the applicable protected authorization conditions and verification at the designated execution-finality boundary. 13. Technical Enforcement Points and Boundary Conditions The following numbered enforcement points describe proposed implementation behavior and verification conditions extracted from the accompanying architecture. They are engineering design points, not legal rights, and do not by themselves define an interoperable protocol or assert implementation conformance. Each point applies where its corresponding mechanism is selected. An implementation must demonstrate the actual enforcement and trust properties asserted for its governed effectuation paths. 13.1. EP-01: Protected AI-Agent Sandbox Egress Finality System An implementation for controlling externally effective operations generated by an artificial-intelligence agent, uses the following components and conditions: a sandboxed execution environment configured to execute an artificial-intelligence agent, an agentic workflow, or an associated tool, and to generate or prepare a proposed operation comprising at least one of a network request, application programming interface call, connector invocation, shell command, file operation, browser automation action, credential request, or host-system operation; Das Expires 19 April 2027 [Page 1031] Internet-Draft Protected AI Execution Finality October 2026 an interception component positioned between the sandboxed execution environment and an effect-capable host or external execution interface, the interception component being configured to intercept the proposed operation before effectuation and represent the proposed operation as a Candidate Sandbox Egress Act maintained in a Non- Effective State; a Candidate Sandbox Egress Act Descriptor comprising machine- verifiable information identifying the proposed operation, a requesting execution context, an intended destination or execution target, an applicable authority scope, and an execution-finality boundary; a Protected Enforcement Domain isolated from execution authority controlled by the artificial-intelligence agent, the Protected Enforcement Domain being configured to: obtain the Candidate Sandbox Egress Act Descriptor and an applicable Sandbox Egress Authority Object; validate the Candidate Sandbox Egress Act against applicable operation, authority, destination, purpose, scope, runtime-context, policy-state, and freshness predicates; prevent the artificial-intelligence agent from independently conferring execution authority upon the Candidate Sandbox Egress Act; generate or commit protected validation evidence corresponding to the Candidate Sandbox Egress Act before, or atomically with, availability of execution-enabling authority; and release or make available a scoped, non-bearer Sandbox Egress Capability only upon successful satisfaction of the applicable protected validation predicates; a Finality Sink associated with a host execution interface, network- egress interface, application programming interface gateway, credential-release interface, file-operation interface, or other effectuation boundary, the Finality Sink being configured to independently verify the Sandbox Egress Capability against the Candidate Sandbox Egress Act and its applicable execution context before permitting effectuation; Under this condition, the Finality Sink is arranged such that the Candidate Sandbox Egress Act cannot become externally effective through the governed execution path solely by virtue of its generation, preparation, invocation, or approval by the artificial- intelligence agent; and Das Expires 19 April 2027 [Page 1032] Internet-Draft Protected AI Execution Finality October 2026 Under this condition, absence, invalidity, expiry, revocation, scope mismatch, or failed verification of the Sandbox Egress Capability causes the corresponding Candidate Sandbox Egress Act to remain non- effective through fail-closed enforcement at the applicable Finality Sink. 13.2. EP-02: Sandbox Boundary Interception In this configuration, the interception component comprises at least one of a container-runtime hook, hypervisor trap, operating-system policy broker, kernel broker, seccomp filter, eBPF program, shell wrapper, browser automation controller, file-system policy module, network-egress proxy, or application programming interface gateway. 13.3. EP-03: Concrete Act Descriptor In this configuration, the Candidate Sandbox Egress Act Descriptor further identifies one or more of an agent identity, sandbox identity, host identity, command digest, command class, file path, network destination, application programming interface endpoint, credential scope, browser action, package identity, input provenance, tool identity, risk class, policy epoch, nonce, expiry, or Finality Sink identity. 13.4. EP-04: Intent, Logic and Behavioral Verification In this configuration, the Protected Enforcement Domain validates one or more of: an Algorithmic Intent Fingerprint representing an authorized purpose of the sandboxed execution environment; an Algorithmic Logic Fingerprint representing an approved workflow, container image, tool graph, command policy, package set, or browser automation policy; and a Runtime Behavioral Descriptor representing observed runtime behavior associated with the Candidate Sandbox Egress Act; Under this condition, failure of a required validation condition causes withholding of the Sandbox Egress Capability. Das Expires 19 April 2027 [Page 1033] Internet-Draft Protected AI Execution Finality October 2026 13.5. EP-05: Untrusted Content and Taint-Lineage Governance In this configuration, the Runtime Behavioral Descriptor or Candidate Sandbox Egress Act Descriptor includes provenance or taint-lineage information identifying influence from one or more of a user instruction, webpage, retrieved document, email, tool response, package metadata, model-generated output, memory item, or another agent message; Under this condition, the Protected Enforcement Domain evaluates whether the identified influence is authorized to contribute to the proposed operation; and Under this condition, unauthorized promotion of untrusted content into execution authority results in withholding of the Sandbox Egress Capability. 13.6. EP-06: Network Egress Finality In this configuration, the Candidate Sandbox Egress Act comprises a network transmission or application programming interface request; Under this condition, the Protected Enforcement Domain validates the requested destination, endpoint, network route, operation class, and authorized execution scope; and Under this condition, a network-egress Finality Sink refuses forwarding or transmission unless the corresponding Sandbox Egress Capability verifies. 13.7. EP-07: Credential Broker Finality In this configuration, the Candidate Sandbox Egress Act comprises a credential request or credential-mediated external-service operation; Under this condition, the Protected Enforcement Domain validates a credential scope associated with the requested operation; and Under this condition, a credential broker or credential-release interface refuses to release, grant, or enable credential-mediated authority unless the corresponding scoped Sandbox Egress Capability verifies. Das Expires 19 April 2027 [Page 1034] Internet-Draft Protected AI Execution Finality October 2026 13.8. EP-08: File, Shell and Host-System Enforcement In this configuration, the Candidate Sandbox Egress Act comprises a shell command, file write, package installation, system call, host application programming interface invocation, or persistent-state modification; Under this condition, the Protected Enforcement Domain validates an applicable command class, target path, package identity, host operation, or resource scope; and Under this condition, the applicable Finality Sink refuses the requested execution or state mutation unless the corresponding Sandbox Egress Capability verifies. 13.9. EP-09: Protected Human Approval In this configuration, a Candidate Sandbox Egress Act requiring human approval remains in the Non-Effective State pending receipt of an approval artifact; Under this condition, the approval artifact is bound to the Candidate Sandbox Egress Act Descriptor and validated by the Protected Enforcement Domain; and Under this condition, the human approval artifact is insufficient by itself to enable effectuation without successful protected validation and verification of the corresponding Sandbox Egress Capability at the Finality Sink. 13.10. EP-10: Agent-Initiated Policy Mutation In this configuration, the artificial-intelligence agent proposes modification of an execution policy, tool policy, retrieval policy, safety policy, delegation policy, model configuration, or workflow configuration; Under this condition, the proposed modification is classified as a Candidate Self-Mutation Act maintained in a Non-Effective State; Under this condition, the Protected Enforcement Domain validates a Self-Mutation Authority Object identifying an existing policy state, proposed policy state, permitted mutation class, applicable approval requirement, policy epoch, and revocation state; and Under this condition, activation of the proposed modification is refused unless a corresponding Self-Modification Capability is released and verified. Das Expires 19 April 2027 [Page 1035] Internet-Draft Protected AI Execution Finality October 2026 13.11. EP-11: Sub-Agent Delegation In this configuration, a proposed delegation to a subordinate artificial-intelligence agent is classified as a Candidate Delegation Act; Under this condition, the Protected Enforcement Domain validates a Delegation Authority Object identifying a parent agent, delegated agent, permitted objective, tool class, data scope, resource scope, time window, recursion limit, or execution budget; and Under this condition, delegated execution authority is bounded by a corresponding Delegation Capability and does not independently authorize an operation outside the validated delegation scope. 13.12. EP-12: Continuous Egress Validation In this configuration, successive sandbox-boundary-crossing commands, network requests, application programming interface calls, or file operations are subjected to respective protected validation events; Under this condition, the protected validation events are associated with micro-validation receipts or an updated protected receipt-chain state; and Under this condition, the Protected Enforcement Domain withholds further Sandbox Egress Capabilities upon detection of runtime behavior inconsistent with an authorized execution scope. 13.13. EP-13: Revocation and Policy-Epoch Enforcement In this configuration, the Sandbox Egress Capability is bound to a policy epoch, revocation state, nonce, expiry condition, or protected authorization state; Under this condition, a change invalidating a required bound condition prevents further effectuation under the affected capability; and Under this condition, renewed authorization requires validation against current protected state. Das Expires 19 April 2027 [Page 1036] Internet-Draft Protected AI Execution Finality October 2026 13.14. EP-14: Hardware-Rooted Enforcement In this configuration, the Protected Enforcement Domain or Finality Sink comprises at least one of a trusted execution environment, hardware security module, secure enclave, secure kernel broker, hypervisor-isolated domain, SmartNIC, data processing unit, protected gateway processor, or firmware-protected controller; and in which an execution-enabling latch, host execution gate, credential-release gate, or network-forwarding gate remains disabled absent successful Sandbox Egress Capability verification. 13.15. EP-15: Browser and Computer-Use Finality In this configuration, the Candidate Sandbox Egress Act comprises a browser automation action, form submission, graphical-interface operation, or computer-use action; Under this condition, the Protected Enforcement Domain validates a Screen-State Finality Object identifying a contemporaneous screen state, semantic target, application context, authority state, and Finality Sink identity; and Under this condition, a browser execution interface or computer-use Finality Sink refuses effectuation when the validated screen-state or action context does not correspond to the operation presented for effectuation. 13.16. EP-16: Autonomous Commerce In this configuration, the Candidate Sandbox Egress Act comprises an autonomous purchase, payment instruction, offer, negotiation, bid, or commerce transaction; Under this condition, the Protected Enforcement Domain validates a commerce authority object against an applicable counterparty, item or service scope, price or spending constraint, permitted purpose, policy epoch, nonce, and execution-finality boundary; and Under this condition, a commerce or payment Finality Sink refuses effectuation unless a corresponding scoped Commerce Actuation Capability verifies. Das Expires 19 April 2027 [Page 1037] Internet-Draft Protected AI Execution Finality October 2026 13.17. EP-17: Privacy-Preserving Validation Receipt In this configuration, the protected validation evidence comprises an Egress LAVR or zero-knowledge validation receipt configured to establish satisfaction of required authorization predicates while withholding one or more private user attributes, proprietary workflow details, or sensitive internal task parameters from an unauthorized relying component. 13.18. EP-18: Fail-Closed Denial and Containment In this configuration, failure of an authority, scope, provenance, runtime-behavior, destination, freshness, or Finality Sink verification condition causes the Candidate Sandbox Egress Act to be blocked, withheld, quarantined, sanitized, simulated without external effect, recorded as denied, or directed for additional human review; Under this condition, such handling does not itself grant execution authority for the rejected operation. 13.19. EP-19: Canonical Authorization-to-Execution Binding In this configuration, the Protected Enforcement Domain constructs a canonical execution descriptor from an intercepted operation, the canonical execution descriptor including an operation identifier, requesting execution context, executable or connector identity, intended destination, operation parameters, applicable permission scope, and authorization-state version; Under this condition, an authorization commitment is generated over the canonical execution descriptor; and Under this condition, the Finality Sink reconstructs or verifies a corresponding execution descriptor immediately before effectuation and refuses the operation when the execution descriptor presented for effectuation does not correspond to the authorization commitment. 13.20. EP-20: Protected Grant-State Consumption In this configuration, the Protected Enforcement Domain maintains a protected authorization-state record identifying an active grant, authorized operation, validity interval, permitted usage count, and revocation state; Under this condition, consumption of a grant for a consequential operation is performed through an atomic protected-state transition preventing the same grant instance from enabling an unauthorized duplicate effect; and Das Expires 19 April 2027 [Page 1038] Internet-Draft Protected AI Execution Finality October 2026 Under this condition, failure to establish the required state transition causes withholding of the corresponding execution-enabling authority. 13.21. EP-21: Atomic Credential-Release Transaction In this configuration, the Candidate Sandbox Egress Act requires a credential protected from the sandboxed execution environment; Under this condition, a credential-release component receives the validated execution descriptor and an authorization commitment associated with the protected grant-state transition; Under this condition, release or application of the credential is conditioned on correspondence between the exact operation presented for effectuation and the authorization commitment; and Under this condition, the credential-release component prevents the credential from becoming available for a different operation, destination, authorization scope, or grant-state instance. 13.22. EP-22: Privileged Connector Verification In this configuration, a privileged connector execution component is isolated from the sandboxed execution environment and communicates with the Protected Enforcement Domain or a credential-release component through an authenticated inter-component interface; Under this condition, the privileged connector execution component independently verifies an authorization commitment or execution- enablement artifact associated with the specific operation; and Under this condition, the privileged connector execution component refuses an external service invocation when the requesting component, operation descriptor, grant state, or execution-enablement artifact fails verification. 13.23. EP-23: Destination Resolution and Redirect Consistency In this configuration, the canonical execution descriptor further binds an authorized destination to one or more of a hostname, resolved network address, destination address class, port, transport protocol, request method, resource path, or final routing destination; Under this condition, a destination change caused by name resolution, redirection, routing modification, or connection reuse is evaluated against the authorization commitment before transmission; and Das Expires 19 April 2027 [Page 1039] Internet-Draft Protected AI Execution Finality October 2026 Under this condition, a destination mismatch that cannot be validated under the authorized scope prevents effectuation until a corresponding protected validation succeeds. 13.24. EP-24: Crash, Retry and Duplicate-Effect Protection In this configuration, the Protected Enforcement Domain maintains a protected operation-state machine representing at least a pending state, an authorized state, a consumption-reserved state, and a terminal state associated with a Candidate Sandbox Egress Act; Under this condition, a retry following timeout, process failure, or interrupted communication is correlated with the original operation identifier and protected authorization state; and Under this condition, uncertainty regarding whether an earlier attempt became externally effective prevents issuance of an independently reusable authorization for the same consequential act unless a protected recovery predicate establishes that duplicate effectuation will not occur. 13.25. EP-25: Process-Lineage Authority Degradation In this configuration, the sandboxed execution environment maintains a protected influence state associated with a process, subprocess, session, or execution lineage; Under this condition, the influence state is updated upon a defined interaction with untrusted information and propagated to a descendant execution context according to a protected propagation rule; Under this condition, the updated influence state modifies the execution scope or validation requirements applicable to a subsequent Candidate Sandbox Egress Act; and Under this condition, the subsequent Candidate Sandbox Egress Act cannot obtain a capability relying on a broader, previously applicable authorization scope when the updated influence state requires restricted authorization. 13.26. EP-26: Policy Mutation Activation Interlock In this configuration, a proposed policy modification is represented by a pre-mutation policy digest, a proposed post-mutation policy digest, and an authorized transition descriptor; Das Expires 19 April 2027 [Page 1040] Internet-Draft Protected AI Execution Finality October 2026 Under this condition, an activation component verifies that the current policy state corresponds to the pre-mutation policy digest and that a protected approval authorizes the transition to the post- mutation policy digest; and Under this condition, the policy modification becomes effective only through an atomic or ordered protected activation transition that invalidates execution authority inconsistent with the resulting policy state. 13.27. EP-27: Cross-Component Finality Consistency In this configuration, two or more protected execution components participate in authorizing, releasing, forwarding, or effectuating the same Candidate Sandbox Egress Act; Under this condition, each component verifies an operation-specific commitment corresponding to the same authorized operation, scope, authorization-state version, and finality boundary; and Under this condition, inconsistent commitments, stale authorization state, duplicate consumption, or disagreement concerning the authorized operation prevents final effectuation until the inconsistency is resolved through a protected validation or recovery procedure. 13.28. EP-28: Transaction-Bound Agent Authorization and Credential Effectuation System An implementation for controlling credential-mediated operations generated by an artificial-intelligence agent, uses the following components and conditions: an agent execution environment configured to generate a proposed external operation directed to a service, connector, network destination, or application programming interface; a protected authorization component outside execution authority controlled by the artificial-intelligence agent; an operation-normalization component configured to construct a canonical operation descriptor representing a concrete proposed operation, including a requesting execution context, an operation class, an intended destination, an operation parameter set, and an applicable credential or permission scope; Das Expires 19 April 2027 [Page 1041] Internet-Draft Protected AI Execution Finality October 2026 a protected authorization-state store configured to maintain an authorization record corresponding to the canonical operation descriptor, the authorization record including a validity condition, grant-state identifier, and consumption condition; a credential-effectuation component isolated from direct control by the artificial-intelligence agent and configured to obtain or use a protected credential required for executing the proposed external operation; an execution-verification component configured to compare the operation presented for effectuation against the canonical operation descriptor and a current protected authorization state; Under this condition, the protected authorization component and the credential-effectuation component are configured to enforce a transaction-bound dependency such that the protected credential cannot be applied to effectuate the proposed operation unless: the authorization record corresponds to the operation presented for effectuation; the required validity and protected grant-state conditions are satisfied; a required consumption or reservation transition is established for the operation; and the execution-verification component confirms that the operation remains within the authorized scope; and Under this condition, failure of any required condition prevents credential-mediated effectuation through the governed execution path, irrespective of whether the artificial-intelligence agent possesses a reference to the service, destination, credential placeholder, connector, or earlier authorization decision. 13.29. EP-29: Protected Credential Substitution In this configuration, the agent execution environment is supplied with a non-authoritative credential reference or surrogate credential that does not independently enable the external operation; Under this condition, the credential-effectuation component resolves the reference or surrogate to protected credential material only after satisfaction of the transaction-bound dependency; and Das Expires 19 April 2027 [Page 1042] Internet-Draft Protected AI Execution Finality October 2026 Under this condition, the credential-effectuation component applies the protected credential exclusively to the corresponding validated operation without releasing reusable protected credential material into the agent execution environment. 13.30. EP-30: Independent Executor Attestation In this configuration, the execution-verification component is associated with a privileged connector, network proxy, gateway, host worker, or protected execution interface; Under this condition, the execution-verification component verifies an identity or attestation of the component requesting credential- mediated effectuation; and Under this condition, the authorization record is rejected when a requesting component identity, authenticated execution context, or authorization-state binding does not correspond to the validated operation. 13.31. EP-31: Protected Effectuation Outcome State In this configuration, the protected authorization-state store maintains an operation-specific effectuation status identifying whether the proposed external operation remains pending, has been reserved for effectuation, has been confirmed effective, has been denied, or has an indeterminate completion status; Under this condition, subsequent execution attempts are evaluated against the operation-specific effectuation status; and Under this condition, a subsequent attempt is prevented from creating an unauthorized duplicate external effect when a prior attempt has consumed or reserved the relevant execution authority. 13.32. EP-32: Method of Protected Agent Egress Finality An implementation for controlling externally effective operations generated by an artificial-intelligence agent, follows these processing stages: executing an artificial-intelligence agent within a sandboxed execution environment; intercepting a proposed operation generated by the artificial- intelligence agent before the operation crosses an externally effective execution boundary; Das Expires 19 April 2027 [Page 1043] Internet-Draft Protected AI Execution Finality October 2026 representing the proposed operation as a Candidate Sandbox Egress Act maintained in a Non-Effective State; generating a machine-verifiable descriptor identifying the Candidate Sandbox Egress Act, its intended effect, applicable scope, and Finality Sink; validating the Candidate Sandbox Egress Act within a Protected Enforcement Domain isolated from execution authority controlled by the artificial-intelligence agent; generating or committing protected validation evidence before, or atomically with, availability of a scoped, non-bearer execution capability corresponding to the validated Candidate Sandbox Egress Act; presenting or making available the scoped execution capability for verification at the applicable Finality Sink; independently verifying, at the Finality Sink, correspondence between the scoped execution capability, the Candidate Sandbox Egress Act, the authorized scope, and required current protected state; permitting effectuation only upon successful Finality Sink verification; and otherwise withholding, denying, quarantining, or retaining the Candidate Sandbox Egress Act in a Non-Effective State so that the artificial-intelligence agent cannot independently complete the externally effective operation through the governed execution path. 13.33. EP-33: State-Bound Finality and Replay Protection In this configuration, : binding the scoped execution capability to a nonce, policy epoch, authorization-state version, operation descriptor, and Finality Sink identity; verifying the bound values against a current execution context immediately before effectuation; consuming, invalidating, or advancing a protected capability-usage state before, or atomically with, permitted effectuation; and refusing replay, cross-destination substitution, cross-sink use, or subsequent execution under a capability whose protected consumption state no longer permits the requested operation. Das Expires 19 April 2027 [Page 1044] Internet-Draft Protected AI Execution Finality October 2026 13.34. EP-34: Protected Self-Modification Finality System An implementation for governing modifications proposed by an artificial-intelligence agent to its own execution environment or authority configuration, uses the following components and conditions: an artificial-intelligence execution environment configured to execute an agent, agentic workflow, model runtime, tool runtime, or autonomous coding system; a mutation interception component configured to intercept a proposed modification to at least one of an execution policy, system instruction, tool-access policy, memory policy, retrieval policy, safety policy, delegation policy, planner policy, model configuration, adapter state, or workflow graph before the modification becomes effective; a Candidate Self-Mutation Act Descriptor identifying the proposed modification, a pre-mutation configuration, a proposed post-mutation configuration, a mutation class, an affected execution environment, and an applicable mutation-activation boundary; a Protected Enforcement Domain isolated from execution authority controlled by the artificial-intelligence agent, the Protected Enforcement Domain being configured to: maintain or obtain a Self-Mutation Authority Object; validate the Candidate Self-Mutation Act against an applicable authorized mutation class, policy state, safety baseline, runtime- context condition, and revocation condition; evaluate applicable Algorithmic Intent Fingerprint, Algorithmic Logic Fingerprint, or Runtime Behavioral Descriptor conditions; generate or commit protected validation evidence corresponding to the Candidate Self-Mutation Act; and release a scoped Self-Modification Capability only when the required validation predicates have been satisfied; a mutation-activation Finality Sink associated with a model runtime, policy manager, agent orchestrator, tool gateway, retrieval system, or memory manager, the mutation-activation Finality Sink being configured to verify the Self-Modification Capability against the proposed modification and current activation context before applying the modification; and Das Expires 19 April 2027 [Page 1045] Internet-Draft Protected AI Execution Finality October 2026 Under this condition, the proposed modification remains in a Non- Effective State, and the mutation-activation Finality Sink refuses activation, when the Self-Modification Capability is absent, invalid, expired, revoked, or inconsistent with the proposed modification. 13.35. EP-35: Before-and-After Policy Binding In this configuration, the Self-Mutation Authority Object includes a current policy digest, a proposed policy digest, an approved mutation class, an Algorithmic Logic Fingerprint before mutation, an Algorithmic Logic Fingerprint after mutation, a policy epoch, and a nonce; Under this condition, the mutation-activation Finality Sink verifies correspondence between the actual policy transition and the protected authorization state before activating the proposed policy. 13.36. EP-36: Evaluation and Regression Evidence In this configuration, the Protected Enforcement Domain additionally validates at least one of a regression-test digest, evaluation digest, approved safety baseline, tool-permission change, retrieval- permission change, prohibited mutation class, or proposed authority expansion; Under this condition, failure of a required predicate prevents issuance of the Self-Modification Capability. 13.37. EP-37: Developer Approval as a Protected Predicate In this configuration, a developer or authorized operator provides an approval artifact corresponding to the Candidate Self-Mutation Act; Under this condition, the Protected Enforcement Domain validates the approval artifact against the proposed policy transition; and Under this condition, the approval artifact does not independently activate the proposed modification without successful protected validation and capability verification at the mutation-activation Finality Sink. 13.38. EP-38: Runtime Revocation and Mutation Revalidation In this configuration, a change in a required policy epoch, revocation state, mutation scope, or protected authority condition causes a previously proposed but not yet activated mutation to be denied or revalidated before effectuation; Das Expires 19 April 2027 [Page 1046] Internet-Draft Protected AI Execution Finality October 2026 Under this condition, a stale Self-Modification Capability cannot authorize activation under an incompatible current policy state. 13.39. EP-39: Protected Sub-Agent Delegation Finality System An implementation for controlling delegation of execution authority between artificial-intelligence agents, uses the following components and conditions: a primary artificial-intelligence agent configured to generate a proposed delegation to a subordinate agent, specialist agent, coding agent, retrieval agent, tool agent, scheduling agent, security agent, or external automated service; a delegation interception component configured to represent the proposed delegation as a Candidate Delegation Act maintained in a Non-Effective State; a Delegation Authority Object identifying at least a parent-agent identity, a proposed delegated-agent identity, a delegated objective, a permitted authority scope, and an applicable delegation boundary; a Protected Enforcement Domain isolated from authority controlled by the primary artificial-intelligence agent, configured to: validate the Candidate Delegation Act against the Delegation Authority Object; evaluate a permitted subtask class, tool class, data scope, memory scope, time window, recursion limit, execution budget, and prohibited operation class, where applicable; validate applicable policy epoch, revocation state, and nonce conditions; generate or commit protected delegation-validation evidence; and release a scoped Delegation Capability upon successful validation; a delegation-acceptance Finality Sink configured to verify the Delegation Capability before admitting the proposed delegation into an executable state; and Under this condition, the primary agent cannot confer executable delegated authority merely by spawning the subordinate agent, transferring an instruction, assigning a task, or communicating a proposed authority scope. Das Expires 19 April 2027 [Page 1047] Internet-Draft Protected AI Execution Finality October 2026 13.40. EP-40: Child-Agent Scope Restriction In this configuration, the Delegation Capability identifies a permitted objective, permitted tool class, permitted data scope, permitted memory scope, permitted time window, or permitted execution budget; Under this condition, the subordinate agent is prevented from receiving delegated authority exceeding the validated scope. 13.41. EP-41: Recursive Delegation Control In this configuration, a subordinate agent proposes a further delegation; Under this condition, the further delegation is represented as an additional Candidate Delegation Act; and Under this condition, the Protected Enforcement Domain validates the further delegation against the applicable parent authority, remaining delegation scope, recursion constraint, and current protected authorization state. 13.42. EP-42: Separation of Delegation from Downstream Effectuation In this configuration, validation of the Delegation Capability permits a bounded delegation but does not independently authorize an externally effective tool invocation, file mutation, network transmission, credential release, payment, or other consequential operation; Under this condition, each such governed downstream operation remains subject to its applicable protected execution-finality validation and Finality Sink verification. 13.43. EP-43: Protected Autonomous Code-Deployment Finality System An implementation for governing deployment of code or infrastructure modifications proposed by an artificial-intelligence agent, uses the following components and conditions: an autonomous coding or software-development execution environment configured to generate a code modification, dependency modification, build-script modification, package modification, infrastructure configuration, or deployment instruction; Das Expires 19 April 2027 [Page 1048] Internet-Draft Protected AI Execution Finality October 2026 a deployment interception component configured to intercept a proposed consequential modification before at least one of repository merge, artifact signing, package publication, production deployment, or infrastructure activation; a Candidate Deployment Act Descriptor identifying a repository, commit or change digest, modification class, affected artifact, deployment target, and release-finality boundary; a Protected Enforcement Domain configured to: validate the Candidate Deployment Act against an applicable Supply- Chain Authority Object; evaluate authorized development purpose, approved workflow, changed- file scope, dependency changes, credential-handling changes, privileged operations, network-egress changes, test results, scan results, review state, and environment restrictions, where applicable; generate or commit a Deployment LAVR or ZK-LAVR corresponding to successful protected validation; and release a Scoped Release Capability bound to the validated deployment act, artifact, target environment, policy epoch, nonce, and applicable release Finality Sink; a release Finality Sink associated with a repository manager, merge controller, artifact signer, package registry, build system, deployment orchestrator, or infrastructure controller, configured to verify the Scoped Release Capability before completing the governed release operation; and Under this condition, the release Finality Sink refuses effectuation of the Candidate Deployment Act if the Scoped Release Capability fails verification. 13.44. EP-44: Artifact and Commit Binding In this configuration, the Scoped Release Capability is bound to a commit digest, artifact digest, repository identity, branch identity, deployment target, release environment, policy epoch, nonce, and expiry; Under this condition, substitution of an unapproved artifact or deployment target causes the release Finality Sink to refuse the operation. Das Expires 19 April 2027 [Page 1049] Internet-Draft Protected AI Execution Finality October 2026 13.45. EP-45: Protected Signing or Publication Key In this configuration, a production signing key, package-publication key, artifact-activation key, or deployment-enablement key is retained in a protected hardware security module or secure enclave; Under this condition, the protected key cannot be used for the governed release operation unless a valid corresponding Scoped Release Capability is verified. 13.46. EP-46: Agent-Generated Skill Deployment In this configuration, the Candidate Deployment Act comprises installation, activation, publication, or execution enablement of an agent-generated skill, plug-in, tool package, or executable artifact; Under this condition, the Protected Enforcement Domain validates the proposed skill or artifact against its authorized purpose, approved tool graph, dependency changes, privileged API use, and permitted execution scope. 13.47. EP-47: Staged Deployment and Drift Interruption In this configuration, a deployment comprises a plurality of release stages, canary stages, progressive rollout stages, or deployment environments; Under this condition, the Protected Enforcement Domain generates stage-associated validation evidence and releases a corresponding scoped rollout capability for an authorized stage; and Under this condition, detected runtime drift, policy-state invalidity, or revocation prevents issuance of a subsequent rollout capability, thereby preventing further deployment progression. 13.48. EP-48: Protected Cross-Domain AI-Fabric Transfer Finality System A computer-implemented hardware-assisted system for controlling transfer of artificial-intelligence computation state between protected execution domains, uses the following components and conditions: a plurality of compute, accelerator, memory, or network-fabric domains configured to exchange at least one of model parameters, tensors, key-value cache data, gradients, activations, embeddings, inference context, checkpoint state, or other artificial-intelligence computation data; Das Expires 19 April 2027 [Page 1050] Internet-Draft Protected AI Execution Finality October 2026 a fabric-transfer interception component associated with a network interface controller, SmartNIC, data processing unit, accelerator interconnect, fabric switch, memory-fabric gateway, optical interconnect controller, or accelerator-management component; the fabric-transfer interception component being configured to intercept a proposed cross-domain transfer before protected computation data crosses an applicable fabric-finality boundary and to represent the proposed transfer as a Candidate Fabric Transfer Act maintained in a Non-Effective State; a Candidate Fabric Transfer Act Descriptor identifying a source compute domain, a destination compute domain, a class of computation data, a transfer operation, and an applicable fabric-finality boundary; a Protected Enforcement Domain configured to: validate the Candidate Fabric Transfer Act against a Cross-Domain Fabric Authorization Object; verify applicable source-domain authority, destination-domain authority, transfer-data classification, approved workload graph, fabric route, runtime transfer envelope, and policy state; generate or commit a Fabric Transfer LAVR or ZK-LAVR corresponding to the protected validation; and release a scoped Fabric Transfer Capability upon successful validation; a fabric Finality Sink implemented at or adjacent to an admission queue, fabric lane, switch pipeline, DMA interface, accelerator memory-access interface, network-forwarding interface, or cross- domain delivery boundary; Under this condition, the fabric Finality Sink independently verifies the Fabric Transfer Capability before admitting, routing, switching, replicating, transferring, or delivering the protected computation data; and Under this condition, the fabric Finality Sink remains closed to the governed transfer when the required Fabric Transfer Capability is absent, invalid, revoked, expired, replayed, or inconsistent with the Candidate Fabric Transfer Act. Das Expires 19 April 2027 [Page 1051] Internet-Draft Protected AI Execution Finality October 2026 13.49. EP-49: Fabric Transfer Descriptor Granularity In this configuration, the Candidate Fabric Transfer Act Descriptor further includes one or more of a source accelerator measurement, destination accelerator measurement, workload identity, tenant identity, model identity, tensor class, memory region, transfer size, collective-operation type, fabric route, switch identity, jurisdiction, policy epoch, nonce, expiry, and fabric Finality Sink identity. 13.50. EP-50: Hardware-Latched Transfer Admission In this configuration, a fabric lane, switch admission entry, DMA queue, optical path, memory-access interface, or accelerator transfer interface is maintained in a hardware-disabled or non-admitting state; Under this condition, successful verification of the Fabric Transfer Capability enables the corresponding bounded transfer through the hardware-controlled interface. 13.51. EP-51: Continuous Tensor or Memory-Transfer Validation In this configuration, the protected computation data comprises a stream divided into packets, transfer blocks, tensor slices, memory pages, collective-operation phases, or transfer windows; Under this condition, a protected validation receipt or rolling Fabric Transfer Capability is associated with a corresponding transfer unit or window; and Under this condition, detection of route drift, unauthorized destination change, transfer-size anomaly, or deviation from an approved workload graph causes subsequent transfer units to be withheld. 13.52. EP-52: Hardware-Freshness Binding In this configuration, the Fabric Transfer Capability is bound to a hardware-freshness value derived from one or more of an accelerator counter, fabric sequence number, secure switch state, trusted clock, secure monotonic counter, boot epoch, or protected device state; Under this condition, replay of a previously valid transfer capability outside its authorized freshness context fails verification. Das Expires 19 April 2027 [Page 1052] Internet-Draft Protected AI Execution Finality October 2026 13.53. EP-53: Separated Cold-Path Validation and Line-Rate Finality In this configuration, the Protected Enforcement Domain performs a comparatively higher-cost authority-validation operation outside a latency-sensitive transfer path; Under this condition, the fabric Finality Sink performs bounded-time local capability verification using a protected hardware lookup entry, sequence counter, short-lived authentication tag, route grant, DMA descriptor, queue-pair capability, or equivalent transfer- admission record; and in which the local verification remains mandatory before the governed transfer is admitted. 13.54. EP-54: Protected Pre-Computation Model Admission System An implementation for controlling admission of an artificial- intelligence computation request to a model-execution environment, uses the following components and conditions: a request-admission component positioned between a requesting client, artificial-intelligence agent, or application and a model-execution service; the request-admission component being configured to receive a proposed inference request, agent request, tool-enabled computation request, retrieval-enabled computation request, memory-enabled computation request, or other governed computation request; a governed computation-context descriptor representing the proposed computation request and identifying at least a requested model or model class, an applicable execution purpose, a proposed workflow or policy context, and a protected computation-admission boundary; a Protected Governance Domain configured to evaluate whether the governed computation-context descriptor satisfies an Approved Algorithmic Logic Fingerprint Condition; a computation-start authorization artifact generated or validated through the Protected Governance Domain and bound to the governed computation-context descriptor and Approved Algorithmic Logic Fingerprint Condition; Under this condition, the request-admission component retains the proposed computation request in a pending admission state until successful verification of the computation-start authorization artifact; Das Expires 19 April 2027 [Page 1053] Internet-Draft Protected AI Execution Finality October 2026 Under this condition, the request-admission component refuses forwarding or execution admission when the computation-start authorization artifact is absent, invalid, expired, revoked, replayed, or inconsistent with the governed computation context; and Under this condition, authentication of the requesting client or possession of an application programming interface credential does not independently substitute for the required computation-start authorization artifact. 13.55. EP-55: Model and Workflow Measurement Binding In this configuration, the computation-start authorization artifact is bound to at least one of a model identifier, checkpoint hash, adapter digest, approved workflow class, tool-policy reference, retrieval-policy reference, memory-policy reference, safety-policy reference, purpose class, jurisdiction condition, tenant identity, destination context, policy epoch, or nonce. 13.56. EP-56: Protected Model-Loader Admission In this configuration, the request-admission component is associated with a model loader, model registry, accelerator-runtime initializer, checkpoint loader, or adapter loader; Under this condition, model weights, adapters, execution state, or accelerator-resident model state are not activated for the governed computation until the computation-start authorization artifact verifies against the approved model state. 13.57. EP-57: Separate Downstream Execution Authority In this configuration, a protected execution-finality subsystem configured to treat a tool invocation, external application programming interface call, file operation, network transmission, or other externally effective operation arising from an admitted computation as a separate Candidate Act; Under this condition, admission of the computation does not itself confer authorization to effectuate the separate Candidate Act; and in which the separate Candidate Act is subject to its own protected validation, scoped execution-capability release, and applicable Finality Sink verification. Das Expires 19 April 2027 [Page 1054] Internet-Draft Protected AI Execution Finality October 2026 13.58. EP-58: Protected Service-Mesh Effectuation System An implementation for controlling externally effective operations generated by a cloud-hosted artificial-intelligence workload, uses the following components and conditions: an artificial-intelligence workload executing in a container, pod, virtual machine, serverless runtime, isolated process, or equivalent cloud execution environment; an infrastructure-level interception component comprising a service- mesh proxy, sidecar proxy, ingress controller, egress controller, application programming interface gateway, workload proxy, or network policy enforcement point; the infrastructure-level interception component being positioned to intercept a proposed operation comprising an outbound request, service-to-service call, application programming interface response, message-bus write, database request, or downstream workflow invocation before the proposed operation crosses a governed execution-finality boundary; a Protected Enforcement Domain configured to validate a Candidate Act Descriptor associated with the proposed operation against an applicable workload identity, service identity, intended destination, network route, authorized behavioral-logic class, policy state, and revocation state; the Protected Enforcement Domain being further configured to generate or commit protected validation evidence and release a scoped Execution-Enabling Capability corresponding to the proposed operation; the infrastructure-level interception component comprising or cooperating with a Finality Sink configured to verify the scoped Execution-Enabling Capability against the proposed operation and applicable source-workload and destination-service context; and Under this condition, the Finality Sink refuses transmission, forwarding, connection establishment, service invocation, or message delivery when the scoped Execution-Enabling Capability fails verification. Das Expires 19 April 2027 [Page 1055] Internet-Draft Protected AI Execution Finality October 2026 13.59. EP-59: Service Identity and Session Binding In this configuration, the scoped Execution-Enabling Capability is bound to one or more of a source workload identity, source container identity, destination service identity, authorized network route, mutually authenticated transport session, policy epoch, revocation epoch, nonce, and protected validation-record digest. 13.60. EP-60: Service-Mesh Bypass Prevention In this configuration, the cloud execution environment is configured to prevent the governed artificial-intelligence workload from transmitting a Candidate Act through an alternative direct network or service interface that bypasses required Finality Sink capability verification. 13.61. EP-61: Fail-Closed Route and Policy Mismatch In this configuration, the Finality Sink refuses an operation upon detecting an expired capability, revoked authority, unauthorized service substitution, source-workload mismatch, destination mismatch, replay condition, or route inconsistent with the bound execution scope. 13.62. EP-62: Distributed Hardware-Watchdog Execution Interlock System An implementation for governing consequential operations performed by an artificial-intelligence execution environment, uses the following components and conditions: an artificial-intelligence execution domain configured to execute an agent, model, agentic workflow, tool, or autonomous process; an out-of-band monitoring domain isolated from execution authority controlled by the artificial-intelligence execution domain, the out- of-band monitoring domain comprising a protected processor, data processing unit, secure controller, isolated accelerator, or equivalent independent security component; a monitoring-state generator configured to produce a protected monitoring-state record representing a measured or evaluated execution condition of the artificial-intelligence execution domain, the monitoring-state record comprising a workload identity, monitoring-state version, validity condition, and enforcement-state indicator; Das Expires 19 April 2027 [Page 1056] Internet-Draft Protected AI Execution Finality October 2026 a Protected Enforcement Domain configured to receive the protected monitoring-state record and determine whether a proposed externally effective operation is authorized under an applicable monitoring- state version and operation-specific authority state; a plurality of independently enforceable Finality Sinks associated with two or more effectuation classes selected from network transmission, application programming interface dispatch, credential application, persistent storage commitment, tool execution, payment instruction, accelerator-state export, and device actuation; a protected authorization mechanism configured to bind an execution- enabling capability for a particular Candidate Act to the corresponding monitoring-state version, Candidate Act Descriptor, applicable Finality Sink, and protected authorization state; Under this condition, each applicable Finality Sink independently verifies the capability and the required monitoring-state condition before effectuation, rather than treating a generic observation or model-access permission as sufficient authorization; and Under this condition, an invalid, stale, revoked, inconsistent, or unavailable required monitoring-state condition causes the affected Finality Sink to refuse effectuation through its governed boundary. 13.63. EP-63: Hardware-Attested Monitoring State In this configuration, the protected monitoring-state record comprises a cryptographically authenticated measurement or attestation generated by the out-of-band monitoring domain; Under this condition, the Protected Enforcement Domain validates the authenticity, workload association, sequence or version value, and freshness of the record before relying upon it for execution authorization. 13.64. EP-64: Watchdog-to-Finality Revocation Fence In this configuration, the out-of-band monitoring domain detects an execution-policy violation, authority-scope deviation, unauthorized tool activity, or runtime-behavior anomaly; Under this condition, the detected condition causes advancement of a protected revocation or monitoring-state version; and Under this condition, each affected Finality Sink rejects an execution-enabling capability bound to a superseded version before permitting a new consequential operation. Das Expires 19 April 2027 [Page 1057] Internet-Draft Protected AI Execution Finality October 2026 13.65. EP-65: Prevention Despite Continued Model Access In this configuration, authorization of further model inference is controlled by a model-access interface independently of at least one downstream Finality Sink; Under this condition, a Candidate Act produced before a model-access interruption remains subject to verification at the applicable downstream Finality Sink; and Under this condition, the downstream Finality Sink prevents unauthorized effectuation notwithstanding successful earlier inference or possession of previously generated model output. 13.66. EP-66: Monitoring Failure and Stale-State Handling In this configuration, the Protected Enforcement Domain or Finality Sink determines whether a required monitoring-state record is unavailable, stale, inconsistent, or outside an authorized freshness interval; Under this condition, no new execution capability is accepted for a protected consequential operation requiring that monitoring state until a corresponding protected recovery or revalidation condition succeeds. 13.67. EP-67: Quarantine with Effectuation-State Preservation In this configuration, a quarantine command causes restriction of further agent computation, tool invocation, or infrastructure access; Under this condition, protected operation-state records distinguish operations already confirmed effective from pending Candidate Acts and operations having indeterminate completion status; and Under this condition, pending consequential operations remain subject to finality verification, and a quarantine event does not itself authorize rollback, replay, duplicated effectuation, or completion of an unverified operation. 13.68. EP-68: Model-Path and Effectuation-Path Dual Authorization System An implementation for controlling artificial-intelligence inference and externally effective operations derived therefrom, uses the following components and conditions: Das Expires 19 April 2027 [Page 1058] Internet-Draft Protected AI Execution Finality October 2026 a model-execution environment configured to receive a proposed inference or agent-computation request; a protected model-access gate positioned on a governed path to a model-execution service, the protected model-access gate being configured to verify a computation-admission authorization associated with a requested model, workload, execution purpose, and approved computation context; an agent or tool execution environment configured to generate a proposed externally effective operation from an admitted computation; a protected operation-classification component configured to represent the proposed externally effective operation as a Candidate Act and maintain the Candidate Act in a Non-Effective State pending execution authorization; a Protected Enforcement Domain configured to validate an operation- specific authorization context comprising at least a concrete operation descriptor, applicable execution-authority state, protected policy state, and intended effectuation boundary; a protected evidence-commitment component configured to generate or commit an operation-specific validation record before, or atomically with, availability of an operation-specific execution capability; a downstream Finality Sink separate in enforcement function from the protected model-access gate, the downstream Finality Sink being positioned at an interface through which the Candidate Act would become externally effective and being configured to independently verify the operation-specific execution capability before effectuation; Under this condition, successful model-access authorization does not independently authorize effectuation of the Candidate Act; Under this condition, revocation of model-access authorization prevents further governed model computation but does not substitute for verification of a previously generated Candidate Act at the downstream Finality Sink; and Under this condition, the Candidate Act remains non-effective through the governed execution path unless the downstream Finality Sink verifies the operation-specific execution capability against the actual operation and current applicable authorization conditions. Das Expires 19 April 2027 [Page 1059] Internet-Draft Protected AI Execution Finality October 2026 13.69. EP-69: Inference-to-Act Context Binding In this configuration, a protected computation-admission record comprises a model identity, workload identity, approved execution context, policy epoch, and authorization-state identifier; Under this condition, the operation-specific authorization context references or cryptographically binds the computation-admission record to a downstream Candidate Act Descriptor without treating the computation-admission record as sufficient execution authority. 13.70. EP-70: Streaming Output and Partial-Action Control In this configuration, the artificial-intelligence execution environment produces a sequence of model outputs, tool-call fragments, decoded action representations, or partially generated command structures; Under this condition, an externally effective fragment or operation derived from the sequence is withheld until the applicable downstream Finality Sink verifies a capability bound to the corresponding completed or bounded Candidate Act; and Under this condition, interruption of future model inference does not authorize release of an already buffered but unverified consequential operation. 13.71. EP-71: Multi-Sink Effectuation Classification In this configuration, a proposed agentic workflow comprises a plurality of consequential operations having different effectuation boundaries; Under this condition, the protected operation-classification component identifies the applicable Finality Sink for each consequential operation; and Under this condition, a capability authorizing one operation or Finality Sink does not independently authorize effectuation of a different operation at another Finality Sink. 13.72. EP-72: Remote Effectuation Verification In this configuration, the downstream Finality Sink comprises a receiving service, remote execution gateway, protected database- commit interface, payment execution interface, hardware actuator, or trusted connector; Das Expires 19 April 2027 [Page 1060] Internet-Draft Protected AI Execution Finality October 2026 Under this condition, the downstream Finality Sink reconstructs or verifies the actual Candidate Act presented for effectuation against the operation-specific execution capability and protected validation- state commitment; and Under this condition, the downstream Finality Sink refuses an operation that differs from the authorized operation in an effectuation-relevant parameter, including destination, recipient, operation type, protected state version, or applicable execution scope. 13.73. EP-73: Confidential Cloud AI-Agent Execution and Cryptographic Finality An implementation for governing externally effective operations generated by an artificial-intelligence workload executing within a confidential or virtualized cloud-computing environment, uses the following components and conditions: a protected or isolated virtual-machine execution environment configured to execute an artificial-intelligence agent, agentic workflow, model runtime, or tool-execution process; an execution-context measurement component configured to obtain a machine-verifiable measurement or attestation representing at least one of a virtual-machine runtime state, approved software configuration, model configuration, agent workflow, execution policy, or protected workload identity; a Candidate Act interception component configured to intercept a proposed externally effective operation originating from the artificial-intelligence workload and to maintain the proposed operation in a Non-Effective State before crossing a governed cloud, host, service, or network effectuation boundary; a Protected Enforcement Domain isolated from execution authority controlled by the artificial-intelligence workload, the Protected Enforcement Domain being configured to: obtain a Candidate Act Descriptor identifying the proposed operation and its applicable effectuation boundary; validate the execution-context measurement against an Approved Algorithmic Logic Fingerprint Condition or applicable protected runtime-authority condition; Das Expires 19 April 2027 [Page 1061] Internet-Draft Protected AI Execution Finality October 2026 validate the Candidate Act against an applicable authority object, execution purpose, permitted operation scope, policy state, revocation state, and freshness condition; generate or commit protected validation evidence corresponding to the Candidate Act; and release a scoped, non-bearer execution capability bound to the Candidate Act and applicable Finality Sink only upon successful validation; a Finality Sink associated with a virtual-machine egress interface, host interface, service-mesh gateway, application programming interface gateway, credential-release interface, storage-commit interface, or network-transmission interface, configured to independently verify the scoped execution capability against the actual proposed operation and current applicable authorization state before effectuation; and Under this condition, successful confidential virtual-machine attestation or execution within an isolated virtual machine does not independently confer authority to perform the proposed externally effective operation, and in which the Finality Sink refuses effectuation when required execution-capability verification fails. 13.74. EP-74: Hardware-Rooted Composite ALF In this configuration, the execution-context measurement comprises or contributes to a Hardware-Rooted Composite Algorithmic Logic Fingerprint identifying one or more of a model identifier, checkpoint hash, adapter hash, tokenizer configuration, decoder configuration, system-instruction policy, safety configuration, tool-permission graph, retrieval-source graph, orchestration graph, virtual-machine measurement, hardware attestation report, and policy epoch. 13.75. EP-75: Measured Workload Configuration In this configuration, the Protected Enforcement Domain compares a runtime-used model configuration, agent workflow, tool configuration, or execution-policy state with a corresponding approved measurement or fingerprint; Under this condition, a mismatch causes the corresponding Candidate Act to remain in the Non-Effective State despite successful authentication of the virtual-machine execution environment. Das Expires 19 April 2027 [Page 1062] Internet-Draft Protected AI Execution Finality October 2026 13.76. EP-76: Privacy-Preserving Cryptographic Validation In this configuration, the protected validation evidence comprises a cryptographically authenticated validation receipt or zero-knowledge validation receipt establishing satisfaction of applicable authority and runtime-integrity predicates; Under this condition, the Finality Sink verifies the protected validation evidence and corresponding capability without requiring disclosure of at least one protected internal policy, private user attribute, proprietary model configuration, or confidential workflow parameter. 13.77. EP-77: Cloud Tenant and Destination Scope In this configuration, the Candidate Act Descriptor further identifies a tenant context, cloud-workload identity, requesting virtual-machine identity, destination service identity, destination network context, and applicable policy epoch; Under this condition, an execution capability associated with one authorized tenant or destination context does not authorize a different tenant or destination context. 13.78. EP-78: Virtual-Machine Snapshot Replay Resistance In this configuration, a protected execution-capability consumption state, nonce state, or hardware-freshness state is maintained outside a rollback-accessible portion of the artificial-intelligence workload; Under this condition, restoration of a previously stored virtual- machine snapshot does not restore authority to reuse a capability previously consumed, revoked, or invalidated in the protected state. 13.79. EP-79: Confidential Governance VM and Hardware-Attested SmartNIC Finality An implementation for governing externally effective operations generated within an artificial-intelligence compute infrastructure, uses the following components and conditions: at least one artificial-intelligence compute node configured to generate a proposed external operation or transfer; a governance compute node executing within a confidential virtual- machine environment providing hardware-supported memory confidentiality or integrity protection; Das Expires 19 April 2027 [Page 1063] Internet-Draft Protected AI Execution Finality October 2026 a hardware-rooted attestation component associated with the governance compute node and configured to produce an authenticated attestation record identifying a governance workload measurement and a protected execution configuration; a Protected Enforcement Domain configured to verify the authenticated attestation record against an approved hardware trust root, registered governance identity, and applicable protected policy state; an execution-authorization component configured to validate a Candidate Act associated with the proposed external operation and release an operation-scoped execution capability dependent upon successful protected authorization and an acceptable governance-node attestation state; an authenticated fabric-management communication path configured to transfer the execution capability from the governance compute node or protected authority component toward an effectuation controller; a hardware-enforced Finality Sink implemented in or associated with a SmartNIC, data processing unit, rack-boundary network controller, accelerator-egress interface, or protected network-forwarding component; Under this condition, the hardware-enforced Finality Sink verifies the execution capability against the Candidate Act, authorized effectuation boundary, and registered attestation state of the issuing governance component before enabling external transmission; and Under this condition, invalidation of the required governance-node attestation state or failure of capability verification prevents the proposed operation from crossing the governed hardware-enforced effectuation boundary. 13.80. EP-80: Confidential VM Attestation Object In this configuration, the authenticated attestation record comprises a Hardware Finality Gate Attestation Object including one or more of a governance firmware digest, confidential virtual-machine policy version, launch measurement, host-data field, hardware signing evidence, and protected device identity; Under this condition, the Protected Enforcement Domain verifies the attestation object against an applicable hardware-vendor certificate chain or registered public-key trust root. Das Expires 19 April 2027 [Page 1064] Internet-Draft Protected AI Execution Finality October 2026 13.81. EP-81: Confidential Governance-Key Isolation In this configuration, cryptographic key material used for protected governance or capability issuance is maintained within a protected governance boundary inaccessible to an ordinary artificial- intelligence compute process; Under this condition, the compute node communicates with the governance component through an authenticated interface rather than obtaining unrestricted access to the protected governance key material. 13.82. EP-82: Attestation Change Disables Capability Issuance In this configuration, a change to a required governance-node firmware measurement, confidential virtual-machine launch measurement, policy version, or protected software configuration results in an attestation state that no longer satisfies an approved governance-node measurement condition; Under this condition, the Protected Enforcement Domain refuses further execution-capability issuance dependent upon that governance node until successful revalidation. 13.83. EP-83: Cryptographically Bound Hardware Freshness In this configuration, the execution capability is additionally bound to a hardware-freshness state comprising at least one of a trusted monotonic counter, secure boot epoch, protected clock, device sequence value, or hardware-attested nonce; Under this condition, restoration or replay of previously valid authorization material fails when the current hardware-freshness state no longer corresponds to the capability. 13.84. EP-84: User-Controlled Confidential VM with Cryptographically Bound Execution Authority An implementation for operating an artificial-intelligence agent within a confidential virtual-machine environment under separate confidentiality and execution-authority controls, uses the following components and conditions: a cloud-hosted confidential virtual-machine environment configured to execute an artificial-intelligence agent and maintain protected user data, agent memory, connected-service data, or task state; Das Expires 19 April 2027 [Page 1065] Internet-Draft Protected AI Execution Finality October 2026 a cryptographic data-protection component configured to protect at least a portion of the protected user data using encryption associated with user-controlled or user-authorized key material; a hardware-rooted attestation component configured to generate a cryptographically verifiable measurement of the confidential virtual- machine environment, including an applicable software measurement and security-configuration state; a protected key-enablement component configured to condition availability of a decryption-enabling secret, derived data-access key, or bounded cryptographic data-access operation upon verification of the attestation measurement and a corresponding user-authorized data-access scope; an artificial-intelligence execution environment configured to prepare a proposed externally effective operation using data made available under the authorized data-access scope; a Protected Enforcement Domain configured to classify the proposed externally effective operation as a Candidate Act maintained in a Non-Effective State and to validate the Candidate Act against an operation-specific authority object, execution context, current policy state, protected freshness state, and intended effectuation boundary; a protected evidence-commitment component configured to commit validation evidence corresponding to the Candidate Act before, or atomically with, release of an operation-specific execution capability; a Finality Sink configured to independently verify the operation- specific execution capability before permitting an external transmission, credential-mediated operation, file export, persistent- state modification, or other consequential effect; and Under this condition, successful cryptographic data decryption or access within the confidential virtual machine does not independently confer permission to effectuate the Candidate Act, and in which an applicable failure of either a required data-access authorization condition or execution-finality condition results in withholding of the corresponding protected operation. 13.85. EP-85: User-Held Root-Key and Attested Derived-Key Release In this configuration, a root encryption key remains under control of a user or user-authorized external key authority; Das Expires 19 April 2027 [Page 1066] Internet-Draft Protected AI Execution Finality October 2026 Under this condition, a derived, wrapped, or session-limited key is made available only to a confidential virtual-machine environment satisfying a required remote-attestation predicate; Under this condition, the derived, wrapped, or session-limited key is restricted to a defined user-data scope, workload identity, validity interval, or protected authorization state without requiring disclosure of the root encryption key to the artificial-intelligence agent. 13.86. EP-86: Dual Authorization for Decryption and External Effect In this configuration, an authorization for protected data decryption and an authorization for a consequential external operation are represented by distinct cryptographic or protected-state conditions; Under this condition, satisfaction of a decryption authorization condition permits bounded access to protected data but does not itself cause issuance of an externally effective operation capability; and in which the Finality Sink verifies the operation-specific execution capability independently of the successful decryption condition. 13.87. EP-87: Cryptographic Binding of Confidential-VM State to Candidate Act In this configuration, the operation-specific execution capability is cryptographically bound to a canonical Candidate Act Descriptor, an attested confidential virtual-machine measurement, a user-authorized execution scope, a policy epoch, a nonce, and a Finality Sink identity; Under this condition, modification of an effectuation-relevant parameter or required attested state after authorization causes the capability to fail verification. 13.88. EP-88: Privacy-Preserving Execution Evidence In this configuration, a cryptographically authenticated execution record establishes that a specified Candidate Act underwent protected authority validation and applicable Finality Sink verification; Under this condition, the execution record is configured to permit verification of the required enforcement condition without disclosing the plaintext of the protected user data, reusable credential material, or a user-controlled root encryption key. Das Expires 19 April 2027 [Page 1067] Internet-Draft Protected AI Execution Finality October 2026 13.89. EP-89: Confidential-VM Recovery and Key-State Continuity In this configuration, restoration of an encrypted virtual-machine backup, protected agent-memory snapshot, or recovered confidential virtual-machine instance requires re-establishment of an authorized attested execution context; Under this condition, a protected execution-capability consumption or revocation state is reconciled independently of rollback-accessible backup contents; and in which restoration of the confidential virtual machine does not restore an expired, previously consumed, or revoked execution capability. 13.90. EP-90: Portable Cloud-VM Agent Authority and Hardware Effectuation System An implementation for enforcing operation-specific execution authority across multiple cloud or virtualized artificial- intelligence execution substrates, uses the following components and conditions: an agent-execution control plane configured to deploy or manage an artificial-intelligence agent in at least one execution substrate selected from a container runtime, virtual machine, confidential virtual machine, Kubernetes workload, on-premises compute host, hybrid-cloud compute environment, or accelerator-backed agent runtime; a workload identity and measurement component configured to establish an authenticated workload identity and an execution-context measurement corresponding to a deployed instance of the artificial- intelligence agent; a Protected Enforcement Domain configured to maintain an authorization-state version and one or more execution-policy predicates applicable to the authenticated workload identity; an operation-interception component configured to represent a proposed externally effective operation generated by the deployed instance as a Candidate Act maintained in a Non-Effective State; a protected authorization component configured to validate the Candidate Act against its operation descriptor, authenticated workload identity, execution-context measurement, current protected policy state, and designated effectuation boundary; Das Expires 19 April 2027 [Page 1068] Internet-Draft Protected AI Execution Finality October 2026 a cryptographic capability-issuance component configured to generate or release a scoped execution capability bound to the Candidate Act, authenticated workload identity, authorization-state version, and designated Finality Sink; a Finality Sink implemented in a host execution controller, virtual- machine boundary, cloud network gateway, service-mesh component, protected connector, SmartNIC, data processing unit, or accelerator- egress controller; Under this condition, the Finality Sink independently verifies the scoped execution capability before allowing the proposed operation to become externally effective; and Under this condition, deployment of the artificial-intelligence agent to a different execution substrate, reinstantiation of the workload, or restoration of a previously authorized execution context does not independently restore authority to execute an operation under a stale or incompatible authorization-state version. 13.91. EP-91: VM and Container Identity Attestation In this configuration, the workload identity and measurement component validates a workload image digest, virtual-machine launch measurement, container image identifier, agent runtime identity, approved tool-policy digest, model configuration digest, or protected execution-policy state; Under this condition, an execution capability is rejected when its workload identity or required measurement does not correspond to the workload executing the Candidate Act. 13.92. EP-92: Runtime Policy Changes Across Cloud Replicas In this configuration, the agent-execution control plane manages a plurality of replicas, restarted workloads, virtual-machine instances, or agent-execution nodes; Under this condition, a protected policy-state transition advances the authorization-state version applicable to a defined workload scope; Under this condition, each affected Finality Sink rejects a capability bound to an incompatible prior authorization-state version before admitting a subsequent consequential operation. Das Expires 19 April 2027 [Page 1069] Internet-Draft Protected AI Execution Finality October 2026 13.93. EP-93: Hardware-Supervised Cloud Egress In this configuration, the designated Finality Sink is implemented in a data processing unit, SmartNIC, protected network gateway, or hardware-assisted cloud egress controller; Under this condition, the Finality Sink verifies the capability and the authenticated workload context without treating successful cloud- network authentication or ordinary virtual-machine connectivity as sufficient operation-specific execution authority. 13.94. EP-94: Cross-Runtime Migration and Snapshot Protection In this configuration, a virtual-machine migration, container replacement, workload rescheduling, checkpoint restoration, or cloud- region failover results in a changed workload identity, execution- context measurement, or protected deployment epoch; Under this condition, a pending Candidate Act is revalidated against the changed context before effectuation; and in which the protected system prevents reuse of a previously consumed capability or unauthorized duplication of an externally effective operation following the runtime transition. 13.95. EP-95: Model-Path Authorization Does Not Replace Effectuation Authorization In this configuration, a model-access control component configured to govern requests to a local or remote artificial-intelligence model; Under this condition, successful model-access authorization permits only the corresponding approved computation and does not independently authorize a consequential operation generated by the model; Under this condition, an operation-specific capability is separately required and independently verified at a downstream Finality Sink before an externally effective operation is completed; and in which interruption, quarantine, or revocation of future model- access authority does not permit release of a previously generated but unverified consequential operation. 14. Security Considerations Das Expires 19 April 2027 [Page 1070] Internet-Draft Protected AI Execution Finality October 2026 14.1. Threat Model and Enforcement Coverage The requesting AI agent, untrusted tool output, subordinate processes, and other compute-plane components are not assumed to possess execution authority. Implementations need to identify the actual privileged attackers and trusted computing base, including any kernel, hypervisor, protected authority, credential broker, and effectuation component. A Finality Gate is not non-bypassable merely because a proxy is configured: every accessible path capable of producing the specified governed effect must be blocked or subjected to the required Finality Sink checks. Protection is limited to the effectuation paths covered by the implemented enforcement mechanisms. 14.2. Canonicalization and Operation Substitution When authorization depends upon executable identity, destinations, HTTP methods, paths, parameters, request bodies, recipients, or other operation attributes, the authority component and Finality Sink need a consistent representation of those attributes. Ambiguous parsing, mutable buffers, filesystem races, redirects, DNS rebinding, connection reuse, and mismatched request normalization can cause the actual operation to differ from the authorized operation. A transport-layer enforcement mechanism cannot inspect encrypted application-layer fields without an appropriate trusted application- layer interface or decryption arrangement. Where a mandatory attribute cannot be established, the operation is withheld. 14.3. Capability Protection and Context Binding Capability authenticity by itself does not establish non-bearer authorization. Implementations claiming context-bound or single-use operation require enforcement of the specified Candidate Act, scope, requester, sink, policy epoch, nonce, expiry, and usage bindings as applicable. Signing or MAC keys and protected capability tables must be shielded from unilateral agent modification. Capability replay, substitution, cross-sink use, unauthorized delegation, and exposure of credential material are relevant attack classes. 14.4. Protected State, Revocation, and Fail-Closed Behavior Protected authorization-state changes, receipt commitments, quota or nonce consumption, and capability release require the consistency specified by the particular implementation. Concurrent attempts must not exceed authorized usage. Required revocation or policy-epoch checks must not silently fail open when state is stale, unavailable, inconsistent, or rolled back. Restart, migration, snapshot restoration, and recovery must not restore previously consumed or revoked authority. Separately authorized safe or recovery actions do Das Expires 19 April 2027 [Page 1071] Internet-Draft Protected AI Execution Finality October 2026 not imply unrestricted permission for the original Candidate Act. 14.5. Credential and Delegation Boundaries Credential isolation and operation authorization are different properties. A host-side credential broker can keep underlying secrets away from an AI agent yet still require an act-specific verification before the broker uses the credential. Delegation of a task to another agent does not automatically authorize every consequential action generated by the subordinate component. Implementations must define which operations and downstream boundaries are separately governed. 14.6. Monitoring Versus Prevention Out-of-band monitoring, anomaly detection, audit evidence, and quarantine may aid detection and containment but do not, by themselves, establish that a previously executed operation was prevented. Interruption of future model inference likewise does not necessarily stop a previously queued tool request. Where the desired security guarantee is prevention, the relevant effectuation boundary must withhold the effect until all mandatory authorization conditions succeed. 14.7. Remote Completion and Recovery Limits Local protected authorization-state atomicity does not guarantee exactly-once completion at an unrelated remote service. A timeout after a request may have been delivered leaves the external outcome uncertain. Retrying must respect protected operation identity, consumption state, and, when available, authenticated receiving-side status, idempotency identifiers, or separate downstream verification. The implementation must not report external completion merely because a source-side gateway transmitted a request. 14.8. Operational Assurance and Testing Testing should include missing or forged capabilities, stale policy and revocation epochs, changed destinations or request bodies, redirected requests, alternate egress paths, concurrent single-use operations, crashes before or after evidence commitment, snapshot rollback, failure of credential brokers, hardware freshness mismatches, and indeterminate remote completion. Assurance claims require implementation-specific review of the actual mediation coverage and protection boundaries. The workflows in this document propose illustrative negative tests; they are not evidence that an implementation has passed them. Das Expires 19 April 2027 [Page 1072] Internet-Draft Protected AI Execution Finality October 2026 15. Relationship to Existing Standards CBOR supplies a possible deterministic data representation, subject to the additional encoding and application-profile rules needed for an interoperable Candidate Act Descriptor; this document does not require CBOR. See [RFC8949] COSE supplies established structures for cryptographic authentication of objects; this document does not select a concrete COSE profile or impose one on the proposed capability representations. See [RFC9052] Remote attestation can provide evidence concerning the protected execution environment, but successful attestation is not equivalent to authorization of a particular downstream consequential operation. See [RFC9334] OAuth Rich Authorization Requests illustrate established fine-grained authorization input; the authority over a final consequential operation must still be evaluated at its governed effectuation boundary when this architecture requires it. See [RFC9396] 16. IANA Considerations This document requests no IANA actions. 17. References [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 8949, 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", RFC 9052, 2022, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, 2023, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, 2023, . Author's Address Das Expires 19 April 2027 [Page 1073] Internet-Draft Protected AI Execution Finality October 2026 Sangam Das Independent Inventor Balasore Odisha India Email: info@sangamdas.com Das Expires 19 April 2027 [Page 1074]